Datachain security record

The TOKI protocol's cross-chain functionality allows users to include arbitrary data in the `to` parameter and `ExternalInfo.payload` field when initiating transactions like `transferPool()`, `transferToken()`, `withdrawRemote()`, and `withdrawLocal()` in `Bridge.sol`. This data is intended for callbacks on the destination chain via the `ITokiOuterServiceReceiver(to).onReceivePool()` call in `_outServiceCallCore`. However, this mechanism presents significant problems: 1. **Unvalidated and Unrestricted Input:** The protocol does not sufficiently validate or restrict the data provided in the `to` parameter or `ExternalInfo.payload`. This lack of sanitization means that the data sent across chains might not fall within the capabilities of the destination chain in terms of block size, gas usage, and other properties. This can lead to unexpected results, failed transactions, and potentially locked tokens on the destination chain. Although the protocol adopts fallback and retry mechanisms, these are not always sufficient to handle such scenarios. 2. **Inaccurate Gas Cost Estimation:** The `RelayerFeeCalculator` contract uses a fixed `premiumBPS` along with oracle-derived prices to estimate relayer fees. This approach fails to accurately account for the dynamic and unpredictable gas costs associated with executing arbitrary code in the user-provided callbacks. The fixed premium is unlikely to be sufficient to cover the actual gas costs, especially if users intentionally or unintentionally provide expensive callbacks. 3. **The `try...catch` Block Fails to Catch Out-of-Gas Exceptions**: If a transaction depletes all of its gas in an external call within a `try` statement, there will not be enough gas remaining to catch out-of-gas exceptions or to execute the `catch` block. The Toki protocol, however, relies on catching exceptions on the destination side of intra-blockchain communications to capture failed calls and append them to the retry queue. This can result in cases where an external call within a `try` block on the destination side runs out of gas without leaving any trace in the protocol, since the transaction has failed.