MsgRequestAction across IBC, upload the file, and approve the finished action. The theory behind the flow, including why file bytes never touch the IBC channel, is on the interchain accounts concept page. Read it first if ICS-27 is new to you.
Before you start you need three things.
- The Go SDK installed. Its
icapackage assembles the packets. - An IBC connection between your controller chain and Lumera with a running relayer. See relayer setup.
- A funded key on the controller chain.
Step 1. Register the interchain account
Your controller chain’s ICA controller module opens a channel to Lumera and creates the account. On CosmWasm chains a contract can own the account through cw-ica-controller. Once the channel handshake completes, query the controller module for the host address. It is a normallumera1... address, controlled only by your chain.
Step 2. Fund the ICA address
The ICA address pays the fee escrow for every action it registers. Sendulume to it before you submit anything. Current fees are 10000 ulume base plus 10 ulume per KB, about 0.02 LUME per MB. Governance can change these parameters.
You can top the address up from any Lumera account, or over IBC from a treasury on the controller chain. On testnet, the faucet covers experimentation.
Step 3. Build and pack the MsgRequestAction
Create a Cascade client configured with the ICA owner settings.ICAOwnerHRP is the bech32 prefix of your controller chain.
Step 4. Send the packet from the controller chain
Submit the packet withMsgSendTx on the controller chain. BuildMsgSendTx assembles it for you, and your controller chain signer broadcasts it. You can also submit the same packet data through your controller chain’s CLI if you prefer scripts.
MsgRequestAction and executes it, and the ICA address pays the escrow.
Step 5. Extract the action ID from the acknowledgement
The IBC acknowledgement carries the registration result back to the controller chain.ica package also ships ParseTxHashJSON, ExtractPacketInfoFromTxJSON, and DecodePacketAcknowledgementJSON for decoding CLI transaction output.
Step 6. Upload the file
The ICA address has no user-held private key, so uploads authenticate with an application level keypair instead. Generate the keypair on the controller side. The public key travels with the action asapp_pubkey, and the private key signs the upload. Pass the ICA options to Upload.
WithICASendFunc takes the callback the SDK invokes when it needs to send an ICA message from your controller chain. The file itself streams over gRPC directly to SuperNodes. It never crosses the IBC channel.
Track progress with SubscribeToEvents, or poll GetAction until the state moves from PENDING through PROCESSING to DONE. A FAILED action refunds the escrowed fee.
Step 7. Download the file
Downloads are authenticated too. Sign the request with a controller chain key by passing the signer address.Step 8. Approve the action
Cross-chain actions support a final confirmation step. After the action reachesDONE, build a MsgApproveAction, pack it, and send it through the same ICA path. The action then moves to APPROVED.
APPROVED.
The sdk-go examples directory contains runnable samples for the ICA request and approve flows.
Operational notes
- Control plane isolation. IBC packets carry only metadata and fee escrow. File data moves on the direct gRPC data plane.
- Data plane authentication. Uploads and downloads use application level signatures, independent of the ICA address.
- Relayer health. Every step that crosses IBC waits on the relayer. A backed up relayer stalls registrations and approvals, so keep ICA writes off any user-facing hot path.
Next steps
Relayer setup
Run the Hermes relayer this flow depends on.
Integration patterns
When contract driven ICA is the right choice, and when it is not.
Go SDK reference
Every ICA helper and Cascade option in one place.