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:
autopilot
support for liquid staking interactions on StrideAll post_route
actions must have the following characteristics:
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:
receiver
parameter in the provide_liquidity
messageon_behalf_of
parameter in the deposit
messageto
parameter in the swap
messageWe recommend setting these authority delegation parameters to the user’s local address on the destination chain, so they can perform future actions locally.
To call a CosmWasm contract on the destination chain, the following requirements must be satisfied:
ibc-hooks
.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 contractIn 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.
To use Autopilot after route actions, the following requirements must be satisfied:
autopilot
module. Currently, this means the destination chain must be stride-1
.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
LIQUID_STAKE
(for liquid staking an asset) or CLAIM
for updating airdrop claim addresses.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.