Post-Route Actions
How to specify actions to perform after a route of transfers/swaps is completed
Use the post_route_handler
parameter of /v2/fungible/msgs
endpoint to define actions that will be executed on the destination chain after a route transfer or swap is completed. These actions are executed within the same transaction as the original swap or transfer.
This handler allows developers to build omni-chain and omni-token workflows where users can swap, liquid stake, deposit, buy an NFT, or take any other action starting from any chain or any token in Cosmos — all in a single transaction.
This parameter currently supports:
- CosmWasm contract calls on the destination chain
autopilot
support for liquid staking interactions on Stride
Background Info
All post_route
actions must have the following characteristics:
- Permissionless: Skip Go can only support permissionless actions because the underlying protocols (e.g. ibc-hooks, packet-forward-middleware) derive the addresses they use to call contracts based on the origin of the transfer. This means one user originating on two different chains or starting with two different tokens will eventually call the final contract / module with different addresses. You can only reliably permission actions that you know will 1) always originate on the same chain and 2) always take the same path to the destination chain. In general, we recommend not making this assumption unless you are an interoperability expert
- Single-token input: The underlying IBC transfer protocol (ICS-20) doesn’t support transfers of more than 1 token denom in a single transfer message, so we can only send 1 token denom to the final contract or module at a time. This means the contract or module in the
post_route_handler
must not require multiple token denoms sent to it simultaneously. For example, a classic LP action where the user must provide tokens in both sides of the pool simultaneously would not work.
Use authority-delegation with local address for permissionless actions that enable permissioned follow-ups
Commonly, the first interaction with a contract is permissionless, but it awards the end-user some kind of permissioned authority to perform follow-on actions (e.g. staking enables unstaking + collecting rewards; depositing enables withdrawing and earning yield) or receipt tokens (e.g. LPing produces LP receipt tokens).
As a cross-chain caller, you should generally avoid contracts that implicitly delegate these authorities or give receipt tokens to the caller because the caller will depend on the path the user has taken over IBC. You should look for contracts to imply authority delegation — i.e. contracts that explicitly assign permissions to an address in the calldata that may be different than the caller and address sending the tokens. Examples of this pattern are:
- Astroport’s
receiver
parameter in theprovide_liquidity
message - Mars’
on_behalf_of
parameter in thedeposit
message - Astroport’s
to
parameter in theswap
message
We recommend setting these authority delegation parameters to the user’s local address on the destination chain, so they can perform future actions locally.
CosmWasm
To call a CosmWasm contract on the destination chain, the following requirements must be satisfied:
- The destination chain supports CosmWasm &
ibc-hooks
. - The chain in the route immediately before the destination chain supports IBC memos as well as
packet-forward-middleware
.
To specify a CosmWasm contract call on the destination chain, pass a wasm_msg
as the post_route_handler
in the /v2/fungible/msgs
call with:
contract_address
: The target contract addressmsg
: JSON string of the message to pass to the contract
In addition, set the destination address in the address_list
to the address of the contract.
For example, this is a request for a transfer of USDC from Axelar to Neutron, with a post-route handler that swaps the USDC to Neutron using an Astroport pool on Neutron:
Note that the last address provided in the address_list
is the address of the pool contract on Neutron, rather than a user address.
The message returned from this request uses ibc-hooks
on Neutron to perform the CosmWasm contract call atomically with the IBC transfer.
Autopilot
To use Autopilot after route actions, the following requirements must be satisfied:
- The destination chain supports the
autopilot
module. Currently, this means the destination chain must bestride-1
. - The chain in the route immediately before the destination chain supports IBC memos as well as
packet-forward-middleware
.
To specify an Autopilot action on the destination chain, pass a autopilot_msg
as the post_route_handler
in the /v2/fungible/msgs
call with:
receiver
: Set to the address on behalf of which you’re performing the actionaction
: An enum giving the action that you wish to execute- This may be one of
LIQUID_STAKE
(for liquid staking an asset) orCLAIM
for updating airdrop claim addresses.
- This may be one of
For example, this is a request for a transfer of ATOM from Cosmos Hub to Stride, with a post-route handler that atomically liquid stakes the transferred ATOM on Stride, sending stATOM to the specific receiver on Stride:
Have questions or feedback? Help us get better!
Join our Discord and select the “Skip Go Developer” role to share your questions and feedback.