Dependency on Third-Party APIs to Create the Right Payload
The Socket system of routes and controllers integrates swaps, bridges, and potentially other solutions that are vastly different from each other. The function arguments that are required to execute them may often seem like a black box of a payload for a typical end user. In fact, even when users explicitly provide a destination `token` with an associated `amount` for a swap, these arguments themselves might not even be fully (or at all) used in the route itself. Instead, often the routes and controllers accept a `bytes` payload that contains all the necessary data for its action. These data payloads are generated off-chain, often via centralized APIs provided by the integrated systems themselves, which is understandable in isolation as they have to be generated somewhere at some point. However, the provided `bytes` do not get checked for their correctness or matching with the other arguments that the user explicitly provided. Even the events that get emitted refer to the individual arguments of functions as opposed to what actually was being used to execute the logic.\\nFor example, the implementation route for the 1inch swaps explicitly asks the user to provide `fromToken`, `toToken`, `amount`, and `receiverAddress`, however only `fromToken` and `amount` are used meaningfully to transfer the `amount` to the SocketGateway and approve the `fromToken` to be spent by the 1inch contract. Everything else is dictated by `swapExtraData`, including even the true `amount` that is getting swapped. A mishap in the API providing this data payload could cause much less of a token `amount` to be swapped, a wrong address to receive the swap, and even the wrong destination token to return.\\n```\\n// additional data is generated in off-chain using the OneInch API which takes in\\n// fromTokenAddress, toTokenAddress, amount, fromAddress, slippage, destReceiver, disableEstimate\\n(bool success, bytes memory result) = ONEINCH\\_AGGREGATOR.call(\\n    swapExtraData\\n);\\n```\\n\\nEven the event at the end of the transaction partially refers to the explicitly provided arguments instead of those that actually facilitated the execution of logic\\n```\\nemit SocketSwapTokens(\\n    fromToken,\\n    toToken,\\n    returnAmount,\\n    amount,\\n    OneInchIdentifier,\\n    receiverAddress\\n);\\n```\\n\\nAs Socket aggregates other solutions, it naturally incurs the trust assumptions and risks associated with its integrations. In some ways, they even stack on top of each other, especially in those Socket functions that batch several routes together - all of them and their associated API calls need to return the correct payloads. So, there is an opportunity to minimize these risks by introducing additional checks into the contracts that would verify the correctness of the payloads that are passed over to the routes and controllers. In fact, creating these payloads within the contracts would allow other systems to integrate Socket more simpler as they could just call the functions with primary logical arguments such as the source token, destination token, and amount.
Consider allocating additional checks within the route implementations that ensure that the explicitly passed arguments match what is being sent for execution to the integrated solutions, like in the above example with the 1inch implementation.
```\\n// additional data is generated in off-chain using the OneInch API which takes in\\n// fromTokenAddress, toTokenAddress, amount, fromAddress, slippage, destReceiver, disableEstimate\\n(bool success, bytes memory result) = ONEINCH\\_AGGREGATOR.call(\\n    swapExtraData\\n);\\n```\\n