Omnichain designs: messages, tokens and liquidity

Omnichain development generally means connecting contracts or assets across chains through message-passing, token-transfer, or liquidity-routing designs. Each moves a different thing: instructions, token supply, or spendable value. The choice determines what the destination contract must trust and how funds become available there.

What does an omnichain messaging app do?

A messaging app sends an instruction from a contract on one chain to a receiver contract on another. The source contract encodes a payload and dispatches it through a messaging protocol; after the protocol’s verification rules are met, a relayer or executor submits the message for destination execution. In LayerZero’s OApp pattern, `_lzSend` sends and `_lzReceive` handles the delivered message. Axelar’s General Message Passing uses `callContract` at the source and an `AxelarExecutable` receiver on the destination.

This pattern fits applications that need to update remote state, trigger a transaction, or coordinate an action across chains. The destination handler must check the message source and its contents before changing state. The security model depends on the protocol’s verification and delivery path, plus the security of both chains. If the immediate task is swapping or moving tokens across networks, use omnichain, a service for doing that across multiple blockchains from one interface.

How do omnichain token designs move assets?

Token designs coordinate a source-chain debit with a destination-chain credit. In a burn-and-mint model, the source token contract burns the transferred amount and the destination contract mints the corresponding amount after message delivery. In a lock-and-unlock model, the source contract escrows tokens and the destination releases tokens held there. Both can keep the cross-chain representation tied to a single asset, but they depend on different permissions and reserves.

For a new token, burn-and-mint can work when the issuer controls minting on each deployment. An existing token may need a lock-and-unlock adapter if the application cannot mint more. An omnichain fungible token standard packages these transfer mechanics with messaging, but the developer still configures trusted peers and supported pathways. The design needs a clear supply invariant: every source debit must correspond to one valid destination credit, with replayed or forged messages rejected.

When should developers use liquidity routing?

Liquidity routing delivers tokens from a pool or provider on the destination chain instead of waiting for the same asset to be released there. A user’s source-chain transfer creates a cross-chain request; a solver or liquidity provider fulfills it from destination inventory, then settles or rebalances later. This can make value available through a different execution path, but it relies on available destination liquidity and the rules for settlement.

The three approaches serve different jobs:

• Choose message passing when contracts need to coordinate actions or state.
• Choose a token standard when one asset needs a defined transfer and supply model across chains.
• Choose liquidity routing when the product needs destination value delivered from local inventory.

Applications can combine these patterns. A token transfer can carry a message that calls a destination contract after crediting the recipient. That adds composability, but also adds destination execution requirements, including sufficient gas and clear failure handling. For most developers, start with the narrowest requirement: move instructions with messaging, preserve token accounting with a token design, or deliver local liquidity with a routing design. Then specify who verifies each message, who can change the configuration, and what happens when destination execution fails.