UCS03 - ZKGM

ucs03-zkgm-0 is the most advanced and recommended protocol to use for

• message passing
• transfers (assets and NFTs)
• intents
• storage proofs
• staking and governance

It’s the most gas-efficient version and suitable for almost all use cases.

Protocol

Open Filling

A groundbreaking protocol improvement on IBC and trust-minimized bridging in general, is that ucs03-zkgm-0 allows arbitrary filling of orders by any party.

Tip

Read more on filling and counterparty risk here.

For packet submissions and transfers, the protocol allows a different filler from the Union IBC contracts. In the case of an alternative filler, the assets are not minted but transferred from the filler’s account. This allows a transfer to be filled before chains have been finalized or client updates processed. Instead, fillers can rely on preconfirmations to reduce the risk of reorgs.

Theoretically, a filler can submit the transfer to the destination side before the transaction is included on the source, given that they protect themselves against double-spend attacks.

The Acknowledgement, which may contain arbitrary payloads, is used to encode information on the filler and repay the filler for the service by unlocking assets from the vault.

Open filling is opt-in for any protocol, allowing for the same optimizations that ucs03-zkgm-0 leverages to increase transfer speeds.

Rate Limiting

ZKGM incorporates rate limiting capabilities through a token bucket mechanism to manage token consumption:

• Each token has a configurable capacity and refill rate
• Transactions are rate-limited based on token amounts
• Rate limiting can be toggled on/off for specific deployment needs
• Administrators can adjust bucket parameters as needed

Immutable Packet

A fundamental design principle of the ZKGM protocol is that packets are fully constructed off-chain and remain immutable once sent. Unlike traditional cross-chain messaging protocols, ZKGM never injects or modifies fields during on-chain processing—it only verifies the packet’s integrity and processes it as submitted.

This immutability offers several powerful capabilities:

1. Mempool Inspection and Intent Filling: Market makers can observe pending transactions in the mempool and identify ZKGM packets before they’re included in a block. This enables near-instant filling of orders, reducing latency to the theoretical minimum.

2. Deterministic Multi-Chain Execution: The packet’s immutability combined with deterministic salt derivation creates a verifiable and predictable execution chain. When a packet contains a Forward instruction:

   • The next packet’s salt is derived deterministically: deriveForwardSalt(salt) = tintForwardSalt(keccak256(salt))
   • This derived salt is used for the next hop’s packet
   • Each subsequent forwarded packet’s salt is similarly derived
   • The entire chain of packet execution becomes deterministic and verifiable

   This determinism allows market makers to:

   • Predict and validate the entire multi-chain execution path
   • Simulate the outcome across all chains before execution
   • Execute packets atomically across chains with confidence
   • Verify the authenticity of packets in a chain without requiring on-chain storage

Use Cases

Flash Loans Across Chains: A trader can construct a sequence of packets representing a complex cross-chain arbitrage:

• Packet 1: Borrow assets on Chain A
• Packet 2: Execute swap on Chain B
• Packet 3: Repay loan on Chain A with profit

A market maker can detect these packets in the mempool, validate the profitability, and execute all steps atomically, effectively enabling cross-chain flash loans.

Cross-Chain Limit Orders: A user can create a packet representing a limit order with specific execution parameters. Market makers can monitor the mempool and execute only when market conditions match the user’s requirements, providing decentralized cross-chain limit order capabilities.

Preemptive Bridging: Services can monitor user interactions with dApps and predict upcoming cross-chain transfers. By the time the user initiates the transfer, the assets can already be pre-positioned on the destination chain through intent filling, creating an instant bridging experience.

Definition

The zkgm protocol abstracts away multiple facets of IBC assets transfer protocol (ics20). We employ versioning in this protocol to ensure backward compatibility with future upgrades (not relying on the IBC channel upgrade feature). Each instruction has a version and opcode to allow for protocol evolution. Its features include:

• batching
• forward/callback envelopes
• channel multiplexing
• fungible assets transfer
• non-fungible assets transfer
• staking and governance

Packet

The zkgm protocol uses two main structures for packet handling:

ZkgmPacket

struct ZkgmPacket {
    bytes32 salt;          // Unique packet identifier
    uint256 path;          // Channel routing information
    Instruction instruction; // The instruction to execute
}

Fields:

• salt: A unique bytes32 identifier used for deterministic packet hashing

  • For regular packets: keccak256(abi.encodePacked(sender, user_provided_salt))
  • For forwarded packets: Uses a tinting mechanism to track packet chain
    • Magic value: 0xC0DE00000000000000000000000000000000000000000000000000BABE
    • Tinting applied as: salt | magic_value (bitwise OR)
    • previous_salt is the salt of the packet being forwarded
    • Next hop salt derived as: keccak256(previous_salt) | magic_value
    • This creates a verifiable chain of salts across hops while preventing salt collisions
  • For batch instructions: Each sub-instruction uses keccak256(index, batch_salt)
    • Where index is the instruction’s position in the batch (0-based)
    • And batch_salt is the parent packet’s salt

• path: A uint256 that tracks packet routing and asset origins

  • Composed of compressed uint32 channel IDs in 32-bit segments
  • Format: prevDstChannel0 | nextSrcChannel0 << 32 | prevDstChannel1 << 64 ...
  • Supports up to 3 hops (256/32/2 - 1), one hop is a placeholder for the final channel ID.
  • Updated during:
    • Packet forwarding (appending channel pairs)
    • Asset origin tracking
    • Return path validation

• instruction: The Instruction to execute

Tip

The salt replaces the traditional IBC sequence number for packet identification. This allows:

• Unique packet identification without maintaining sequence state on-chain
• Deterministic computation of future packet hashes for filling (e.g., for forwarded packets)
• Prevention of packet collisions in a stateless manner
• Market Makers protection against reorgs (using preconf to have a guarantee that initiating tx is included at some point)

Instruction

struct Instruction {
    uint8 version;    // Protocol version
    uint8 opcode;     // Instruction type
    bytes operand;    // Instruction-specific data
}

Fields:

• version: Protocol version number as uint8

  • Required for backward compatibility
  • Allows dispatching between different versions
  • Each instruction type specifies required version
  • Current supported versions:
    • INSTR_VERSION_0 (0x00)
    • INSTR_VERSION_1 (0x01)
    • INSTR_VERSION_2 (0x02)

• opcode: Instruction type identifier as uint8

  • 0x00: Forward
  • 0x01: Call
  • 0x02: Batch
  • 0x03: TokenOrder
  • 0x04: Stake
  • 0x05: Unstake
  • 0x06: WithdrawStake
  • 0x07: WithdrawRewards

• operand: Instruction-specific data as bytes

  • Forward: Path, timeouts and instruction to forward
  • Call: Sender, callback mode and contract call data
  • Batch: Array of instructions to execute atomically
  • TokenOrder: Transfer details like tokens, amounts and parties
  • Stake/Unstake/WithdrawStake/WithdrawRewards: Staking operation parameters

Note

The version field is embedded in every instruction. One may think that this value is redundant for recursive packets. The reality is that upgrade propagation may take time (optimistic rollups for instance) and having every instruction specifying their version will allow to dispatch from a higher version to a lower one. This is specifically true for packet forwarding (chain A running version X forwarding to a chain B running version Y).

Instructions

0x00 - Forward

The forward instruction uses opcode 0x00 and requires version INSTR_VERSION_0.

struct Forward {
    uint256 path;              // Channel sequence as (prevDst,nextSrc) pairs
    uint64 timeoutHeight;      // Block height timeout
    uint64 timeoutTimestamp;   // Unix timestamp timeout
    Instruction instruction;    // Instruction to forward
}

Fields:

• path: A uint256 that encodes the forwarding route

  • Composed of (prevDst,nextSrc) channel ID pairs
  • Each pair uses 64 bits (32 bits per channel ID)
  • Must match valid channel connections
  • Used to verify packet routing path

• timeoutHeight: Block height timeout as uint64

  • After this height, packet cannot be executed
  • Set to 0 to disable height timeout
  • Must be greater than current height when executed

• timeoutTimestamp: Unix timestamp timeout as uint64

  • After this time, packet cannot be executed
  • Set to 0 to disable timestamp timeout
  • Must be greater than current time when executed

• instruction: The Instruction to forward

  • Can be Call, TokenOrder, or Batch
  • Will be executed on final destination chain
  • Cannot be another Forward instruction

Tip

The forward instruction can wrap Call, TokenOrder, or Batch instructions. The path parameter encodes pairs of (previous destination channel, next source channel) for routing. For example, to forward through a single hop, you need both the previous destination channel ID and the next source channel ID that form the connection between chains.

The protocol verifies that only these specific instructions can be forwarded and that the channel pairs are valid.

0x01 - Call

The call instruction uses opcode 0x01 and requires version INSTR_VERSION_0.

struct Call {
    bytes sender;            // Source chain sender address (must match msg.sender)
    bool eureka;            // Whether to use IBC-style callbacks
    bytes contractAddress;   // Target contract address on destination
    bytes contractCalldata;  // Call data for the target contract
}

Fields:

• sender: Source chain sender address as bytes

  • Must match transaction sender (msg.sender)
  • Prevents address impersonation
  • Used for callback routing in eureka mode

• eureka: Callback mode flag as bool

  • false: Standard fire-and-forget mode
  • true: IBC-style callback mode
  • Determines target contract interface
  • Controls acknowledgement handling

• contractAddress: Target contract address as bytes

  • Must be valid contract on destination chain
  • Must implement required interface based on eureka flag
  • Where message will be delivered

• contractCalldata: Contract call data as bytes

  • Arbitrary data passed to target contract
  • Interpreted by target contract’s implementation
  • Available in both standard and eureka modes

The multiplexcall instruction has two modes:

1. Standard Mode (eureka = false):

   • Target must implement IZkgmable interface
   • Calls onZkgm(path, sourceChannel, destChannel, sender, calldata) on target
   • Returns success acknowledgement immediately
   • Fire-and-forget style, no callback to sender

2. IBC Mode (eureka = true):

   • Calls onRecvPacket(packet, relayer, relayerMsg) on target
   • Packet contains path, sender and calldata
   • Target must return non-empty acknowledgement
   • Acknowledgement forwarded back to original sender

If the target contract is invalid or calls fail:

• Standard mode returns failure acknowledgement
• IBC mode propagates target’s error response

Tip

Example of a contract implementing IZkgmable:

contract MyContract is IZkgmable {
    event MessageReceived(
        uint256 path,
        uint32 sourceChannelId,
        uint32 destinationChannelId,
        address sender,
        bytes message
    );

    function onZkgm(
        uint256 path,
        uint32 sourceChannelId,
        uint32 destinationChannelId,
        bytes calldata sender,
        bytes calldata message
    ) external {
        // Verify caller is zkgm contract
        require(msg.sender == address(zkgm), "Only zkgm");

        // Verify that the sourceChannelId and sender are authorized...

        // Process the cross-chain message
        emit MessageReceived(
            path,
            sourceChannelId,
            destinationChannelId,
            address(bytes20(sender)),
            message
        );
    }
}

0x02 - Batch

The batch instruction uses opcode 0x02 and requires version INSTR_VERSION_0.

struct Batch {
    Instruction[] instructions;  // Array of instructions to execute
}

Fields:

• instructions: Array of Instructions to execute atomically
  • Only specific instructions allowed (Call, TokenOrder, Stake, Unstake, WithdrawStake)
  • Executed in sequential order
  • All must succeed or entire batch reverts
  • Individual acknowledgements collected in array
  • Minimum 2 instructions required

This allows atomic composition of transfers, contract calls, and staking operations in a single transaction.

Tip

In combination with forward envelopes or multiplexing, this batching mechanism is very useful to call contract before/after message execution (transfer an asset, swap it then stake the final asset).

0x03 - Token Order

The token order instruction has two versions:

1. Version 1 (INSTR_VERSION_1) - DEPRECATED:

struct TokenOrderV1 {
    bytes sender;             // Source chain sender address
    bytes receiver;           // Destination chain receiver address
    bytes baseToken;          // Token being sent
    uint256 baseAmount;       // Amount being sent
    string baseTokenSymbol;   // Token symbol for wrapped asset
    string baseTokenName;     // Token name for wrapped asset
    uint8 baseTokenDecimals;  // Token decimals for wrapped asset
    uint256 baseTokenPath;    // Origin path for unwrapping
    bytes quoteToken;         // Token requested in return
    uint256 quoteAmount;      // Minimum amount requested
}

2. Version 2 (INSTR_VERSION_2):

struct TokenOrderV2 {
    bytes sender;             // Source chain sender address
    bytes receiver;           // Destination chain receiver address
    bytes baseToken;          // Token being sent
    uint256 baseAmount;       // Amount being sent
    bytes quoteToken;         // Token requested in return
    uint256 quoteAmount;      // Minimum amount requested
    uint8 kind;               // Type of metadata (initialize, escrow, unescrow)
    bytes metadata;           // Token metadata based on type
}

TokenOrderV2: Advanced Token Mapping and Customization

The V2 version introduces a significantly more flexible metadata system with three types:

• TOKEN_ORDER_KIND_INITIALIZE (0x00): Provides full metadata implementation and initializer for custom token deployment

struct TokenMetadata {
    bytes implementation;    // Implementation contract address
    bytes initializer;       // Initialization data for proxy
}

• TOKEN_ORDER_KIND_ESCROW (0x01): Uses a metadata image hash for existing token identification
• TOKEN_ORDER_KIND_UNESCROW (0x02): Specifically for unwrapping operations

The key innovation in V2 is the ability to support 1:N token mappings, allowing the same source token to be represented by different implementations on the destination chain. This enables several powerful use cases:

1. Custom Token Implementations: Projects can map a token to their own implementation with specific features or behaviors. For example, a project could map USDC to a custom token that includes additional functionality like rebasing or built-in protocol-specific mechanics.

2. Upgradeability Management: Tokens can be deployed with specific upgradeability patterns chosen by the implementing protocol rather than being fixed to a single implementation pattern.

3. Enhanced Security Controls: Custom implementations can include additional security features like transfer limits, allowlists, or compliance mechanisms tailored to specific regulatory requirements.

This flexibility is achieved by allowing the specification of:

• A custom implementation contract address
• Custom initialization data
• A deterministic salt based on the metadata

Similarly to V1, in V2 the protocol uses CREATE3 to deploy the token contracts at deterministic addresses, ensuring that the same token metadata always results in the same deployed address.

Common Fields (both versions):

• sender: Source chain sender address as bytes

  • Must be valid address on source chain
  • Used for refunds on failure/timeout

• receiver: Destination chain receiver address as bytes

  • Must be valid address on destination chain
  • Where quote tokens will be sent on success
  • Must be specified by sender

• baseToken: Token being sent as bytes

  • Token identifier on source chain
  • Used to identify/create wrapped token
  • Must exist on source chain

• baseAmount: Amount being sent as uint256

  • Must be available from sender
  • Maximum amount to exchange

• quoteToken: Requested token as bytes

  • Token identifier on destination chain
  • What sender wants in exchange
  • Must exist on destination chain

• quoteAmount: Minimum amount requested as uint256

  • Minimum acceptable exchange amount
  • Difference (if less than baseAmount) is taken as fee by the relayer

The order can be filled in three ways:

1. Protocol Fill - If the quote token matches the wrapped version of the base token and base amount >= quote amount:

   • For new assets: Deploy wrapped token contract and mint quote amount to receiver
   • For returning assets: Unwrap base token and transfer quote amount to receiver
   • Any difference between baseAmount and quoteAmount is minted/transferred to the relayer as a fee
   • Rate limiting may be applied based on configuration

2. Market Maker Fill - Any party can fill the order by providing the quote token:

   • Market maker is specified in acknowledgement
   • Base token is transferred/minted to market maker
   • Market maker must handle quote token transfer on behalf of the protocol

3. Solver Fill - Smart contracts that implement the solver interface can programmatically fill orders:

   • Solver contracts are detected via interface support (ERC165 in Solidity, query in CosmWasm)
   • Solvers receive full context: packet, order, caller, relayer, relayerMsg, and intent flag
   • Solvers can implement complex logic like multi-hop swaps, arbitrage, or liquidity aggregation
   • On solver failure, the protocol return ACK_ERR_ONLYMAKER to allow other market makers to fill
   • Solvers use the same FILL_TYPE_MARKETMAKER acknowledgment type as regular market makers

The acknowledgement includes:

• Fill type (Protocol = 0xB0CAD0 or MarketMaker = 0xD1CEC45E)
• Market maker address for MM fills (empty for protocol fills)

If the order fails or times out:

• For new assets: Base token is minted back to sender
• For returning assets: Base token is transferred back to sender
• Outstanding balances are decreased

Solver Interface

TokenOrderV2 introduces support for solver contracts - smart contracts that can programmatically fill orders with custom logic. This enables sophisticated market-making strategies beyond simple token transfers.

Solidity Implementation:

interface ISolver {
    function solve(
        IBCPacket calldata packet,
        TokenOrderV2 calldata order,
        address caller,
        address relayer,
        bytes calldata relayerMsg,
        bool intent
    ) external;

    function allowMarketMakers() external returns (bool);
}

Solver contracts must:

1. Implement the ISolver interface
2. Support ERC165 interface detection for type(ISolver).interfaceId
3. Handle the solve() function call with all order context

CosmWasm Implementation:

pub enum SolverQuery {
    IsSolver,
}

pub enum SolverMsg {
    DoSolve {
        packet: Packet,
        order: CwTokenOrderV2,
        caller: Addr,
        relayer: Addr,
        relayer_msg: Bytes,
        intent: bool,
    },
}

CosmWasm solvers must:

1. Handle the SolverQuery::IsSolver{} query (return success to indicate solver capability)
2. Implement the SolverMsg::DoSolve execute handler
3. Perform the necessary token transfers or logic

Solver Detection:

The protocol automatically detects solver contracts:

• Solidity: Uses ZkgmLib.isSolver(address) which checks ERC165 interface support
• CosmWasm: Queries the contract with SolverQuery::IsSolver{} and checks if the query succeeds

Execution Flow:

When a quote token is detected as a solver:

1. The solver’s solve() function is called with full context
2. The solver can perform arbitrary logic (swaps, aggregation, etc.)
3. On success, normal market maker acknowledgment is returned
4. On failure, ACK_ERR_ONLYMAKER is returned, allowing other market makers to attempt filling

Use Cases:

• Multi-hop Swaps: Solvers can execute complex swap routes across multiple DEXs
• Liquidity Aggregation: Combine liquidity from multiple sources for better rates
• Arbitrage: Execute arbitrage opportunities while fulfilling user orders
• Custom Logic: Implement protocol-specific market making strategies
• Cross-chain Coordination: Coordinate actions across multiple chains

Example Solver Implementation:

contract MultiDEXSolver is ISolver, ERC165 {
    mapping(uint32 => mapping(bytes => bytes)) quoteTokenFor;
    mapping(uint32 => bytes) expectedBeneficiary;

    function solve(
        IBCPacket calldata packet,
        TokenOrderV2 calldata order,
        address caller,
        address relayer,
        bytes calldata relayerMsg,
        bool intent
    ) external override {
        require(!intent, "only finalized txs are currently supported");
        require(relayerMsg == expectedBeneficiary[packet.destinationChannelId], "unexpected beneficiaty");
        address quoteToken = quoteTokenFor[packet.destinationChannelId][order.baseToken];
        require(quoteToken != address(0), "unsupported token")

        address receiver = address(bytes20(order.receiver));

        findBestRouteAndTrade(
            order.baseToken,
            order.baseAmount,
            quoteToken,
            order.quoteAmount,
            receiver
        );
    }

    function supportsInterface(bytes4 interfaceId)
        public view override returns (bool)
    {
        return interfaceId == type(ISolver).interfaceId
            || super.supportsInterface(interfaceId);
    }
}

Token Order Kinds: Protocol Rules and Solver Communication

The kind field in TokenOrderV2 serves two critical purposes: protocol-level validation and solver communication. Understanding when and how to use each kind is essential for proper protocol operation.

Protocol Validation Rules

The protocol enforces strict validation rules based on the token order kind:

TOKEN_ORDER_KIND_INITIALIZE (0x00):

• Required when: Deploying a new wrapped token with custom metadata
• Metadata: Must contain valid TokenMetadata with implementation contract and initializer data
• Validation: Protocol verifies the wrapped token doesn’t already exist
• Use case: First-time token bridging with custom token contracts

TOKEN_ORDER_KIND_ESCROW (0x01):

• Required when: Sending tokens that will be escrowed (locked) on the source chain to receive quote tokens on the destination
• Metadata: Can contain arbitrary data for solver interpretation
• Validation: Protocol checks if the token has a V1 (metadata image = 0) or V2 (non-zero metadata image) representation
• Use case: Regular token transfers where base tokens are locked on source chain

TOKEN_ORDER_KIND_UNESCROW (0x02):

• Required when: Unwrapping tokens back to their original form
• Metadata: Can contain arbitrary data for solver interpretation
• Validation: Protocol verifies the token is being sent back through its origin path
• Use case: Returning wrapped tokens to their source chain

Solver Communication Channel

Beyond protocol validation, the kind and metadata fields create a powerful communication channel between users and solvers:

Arbitrary Metadata Threading:

// Example: User wants specific slippage tolerance for a solver
TokenOrderV2 memory order = TokenOrderV2({
    sender: abi.encodePacked(msg.sender),
    receiver: abi.encodePacked(recipient),
    baseToken: abi.encodePacked(token),
    baseAmount: amount,
    quoteToken: abi.encodePacked(solverContract),
    quoteAmount: minOutput,
    kind: TOKEN_ORDER_KIND_ESCROW,
    metadata: abi.encode(SlippageParams({
        maxSlippage: 300, // 3%
        deadline: block.timestamp + 3600,
        preferredDEX: "uniswap"
    }))
});

Solver Interpretation:

contract CustomSolver is ISolver {
    struct SlippageParams {
        uint256 maxSlippage;
        uint256 deadline;
        string preferredDEX;
    }

    function solve(
        IBCPacket calldata packet,
        TokenOrderV2 calldata order,
        address caller,
        address relayer,
        bytes calldata relayerMsg,
        bool intent
    ) external override {
        // Decode user preferences from metadata
        SlippageParams memory params = abi.decode(order.metadata, (SlippageParams));

        // Use the metadata to customize execution
        if (keccak256(bytes(params.preferredDEX)) == keccak256("uniswap")) {
            executeUniswapTrade(order, params);
        } else {
            executeBestRouteTrade(order, params);
        }
    }
}

Advanced Solver Use Cases

1. Multi-Step Execution Instructions:

struct MultiStepParams {
    uint8 steps;
    address[] intermediateTokens;
    uint256[] minOutputs;
    bytes[] customData;
}

// User encodes complex trading strategy in metadata
TokenOrderV2 memory order = TokenOrderV2({
    // ... other fields
    kind: TOKEN_ORDER_KIND_ESCROW,
    metadata: abi.encode(MultiStepParams({
        steps: 3,
        intermediateTokens: [USDC, WETH, TARGET_TOKEN],
        minOutputs: [1000e6, 0.5e18, 100e18],
        customData: [swapParams1, swapParams2, swapParams3]
    }))
});

2. Conditional Execution Logic:

struct ConditionalParams {
    uint256 triggerPrice;
    bool triggerAbove;
    uint256 maxDelay;
    bytes fallbackAction;
}

// Solver can implement limit order logic
TokenOrderV2 memory order = TokenOrderV2({
    // ... other fields
    kind: TOKEN_ORDER_KIND_ESCROW,
    metadata: abi.encode(ConditionalParams({
        triggerPrice: 2000e18, // Execute only if ETH > $2000
        triggerAbove: true,
        maxDelay: 3600,
        fallbackAction: abi.encode("refund")
    }))
});

Best Practices

For Protocol Compliance:

1. Always use TOKEN_ORDER_KIND_UNESCROW when unwrapping tokens
2. Use TOKEN_ORDER_KIND_INITIALIZE only for first deployment with custom metadata
3. Use TOKEN_ORDER_KIND_ESCROW for regular transfers and solver communication

For Solver Integration:

1. Define clear metadata schemas for your solver contract
2. Validate metadata format in your solver’s solve() function
3. Provide fallback behavior for invalid or missing metadata
4. Document your metadata schema for user integration
5. Consider versioning your metadata format for upgradability

Security Considerations:

1. Solvers should validate all metadata fields before execution
2. Never trust metadata without proper validation
3. Implement bounds checking for numeric parameters
4. Consider gas costs when decoding complex metadata structures
5. Provide clear error messages when metadata validation fails

This dual-purpose design makes TokenOrderV2 both protocol-compliant and highly extensible, enabling sophisticated use cases while maintaining security and predictability.

Tip

A user can split a big order over multiple packets to have a partial-filling like behavior. For instance, one could split a $100K order over 10 packets to allow different participants (usually market makers) to fill chunks of $10K.

Read more on filling here.

If any of the order in the orders list is failing on execution, the whole packet is reverted and a failure acknowledgement will be yield.

0x04 - Stake

The stake instruction uses opcode 0x04 and requires version INSTR_VERSION_0.

struct Stake {
    uint256 tokenId;                      // NFT token ID for the staking position
    bytes governanceToken;                // Governance token address
    bytes governanceTokenWrapped;         // Wrapped governance token address
    bytes sender;                         // Source chain sender address
    bytes beneficiary;                    // Address that will receive the staking NFT
    bytes validator;                      // Validator address to stake with
    uint256 amount;                       // Amount to stake
}

The stake instruction allows cross-chain staking of governance tokens with validators. The process:

1. Tokens are locked on the source chain
2. Staking is initiated on the destination chain
3. A staking position NFT is minted to the beneficiary
4. The NFT represents ownership of the staked position and can be used to manage it

0x05 - Unstake

The unstake instruction uses opcode 0x05 and requires version INSTR_VERSION_0.

struct Unstake {
    uint256 tokenId;                      // NFT token ID for the staking position
    bytes governanceToken;                // Governance token address
    bytes governanceTokenWrapped;         // Wrapped governance token address
    bytes sender;                         // Source chain sender address
    bytes validator;                      // Validator address to unstake from
}

The unstake instruction initiates the unbonding process for staked tokens. When successful:

1. The staking position enters the UNSTAKING state
2. The unstakingCompletion time is set
3. The NFT is returned to the sender
4. After completion time, tokens can be withdrawn

0x06 - Withdraw Stake

The withdraw stake instruction uses opcode 0x06 and requires version INSTR_VERSION_0.

struct WithdrawStake {
    uint256 tokenId;                      // NFT token ID for the staking position
    bytes governanceToken;                // Governance token address
    bytes governanceTokenWrapped;         // Wrapped governance token address
    bytes sender;                         // Source chain sender address
    bytes beneficiary;                    // Address that will receive the tokens
}

The withdraw stake instruction allows a user to claim their tokens after the unbonding period. On success:

1. The staking position enters the UNSTAKED state
2. The staked tokens are transferred to the beneficiary
3. Any rewards are also transferred
4. If there was slashing, the appropriate amount is burned

0x07 - Withdraw Rewards

The withdraw rewards instruction uses opcode 0x07 and requires version INSTR_VERSION_0.

struct WithdrawRewards {
    uint256 tokenId;                      // NFT token ID for the staking position
    bytes governanceToken;                // Governance token address
    bytes governanceTokenWrapped;         // Wrapped governance token address
    bytes validator;                      // Validator address
    bytes sender;                         // Source chain sender address
    bytes beneficiary;                    // Address that will receive the rewards
}

The withdraw rewards instruction allows claiming rewards without unstaking. On success:

1. The staking position remains in the STAKED state
2. Any accumulated rewards are transferred to the beneficiary
3. The NFT is returned to the sender

Implementations

UCS03 - EVM reference implementation Canonical UCS03 implementation in Solidity

UCS03 - CosmWasm reference implementation Canonical UCS03 implementation in Rust