Squid Router Client Requirements
Squid has both off-chain and on-chain code.
The job of the off-chain code is to build complex bundles of transactions, which might involve swaps, NFT purchases, transfers, bridges etc. and might involve multiple chains.
The “product” of the Squid backend is a payload which can be executed by a user on the source chain only, to get their swap, bridge or purchase done in a single click. This payload is essentially a nested instruction set, where first the instructions for the source chain are executed, next an Axelar bridge and GMP message are made, with the next payload being an instruction set of the next chain, the final call on that chain might be another bridge, with the next payload to be next in line, an so on.
The job of the on-chain code is to be as generic as possible, being responsive to non-deterministic outcomes such as slippage on a DEX, so that the message can continue onwards on its route, utilising the full token output of the swaps before. If at any point on an intermediary or destination chain there is a failure, the Squid contracts have a fallback mechanism to transfer the bridged tokens to an off-chain provided fallback address.
All encoding for DEXs and other tools on a chain should be done by the Squid Backend. Only Axelar GMP and ITS should be specifically implemented on the Squid Router contract. This is to provide maximum flexibility to move fast and add new DEX or NFT marketplace integrations through backend code only.
https://github.com/0xsquid/cosmos-contracts/tree/main/contracts/multicall
e.g. bridgeCallGMP