Omnichain: How Transfers, Apps and Failed Sends Work

Omnichain systems connect assets and apps across blockchains by sending messages between them, so a transfer or action can start on one chain and finish on another. The term describes a way to coordinate separate networks, not one shared blockchain or a single universal protocol. A useful starting point is how omnichain systems coordinate assets and application state. The details vary by protocol.

How does an omnichain transfer work?

A transfer usually starts with a transaction on the source chain, the network where the user holds the asset. A contract may lock the original tokens or burn them, then send a message that identifies the destination and recipient. A relayer carries the message across; the destination system checks it and releases or creates the corresponding asset.

Some routes use a pool of tokens already held on the destination chain. In that case, a service may pay the recipient from that pool and settle the balance later. This can feel faster, but it relies on available liquidity. Other routes wait for the source transaction to reach finality, meaning it is settled enough that the protocol treats it as confirmed. Faster routes can involve different trust assumptions.

Fees can cover the source transaction, message delivery and destination execution. The destination chain may also need its own gas, the fee paid to run transactions there. Check whether the quoted amount includes it.

What can omnichain apps do?

An omnichain app can use messages to make a contract on one network trigger an action on another. For example, a user might deposit an asset on one chain and have a lending app update their position on a second. The app must pass enough information for the receiving contract to check which chain and sender the request came from.

Ethereum’s ERC-5164 proposal describes this as a dispatcher on the sending chain and an executor on the receiving chain. It also says messages may arrive in a different order from the order they were sent. Developers therefore need to design for delays and check each message before acting. An app deployed separately on several chains may look similar but still keep separate balances and rules; cross-chain messaging is what lets a system coordinate those parts.

What happens when an omnichain send fails?

A send has more than one stage. The source transaction can fail before it records a message. If it succeeds, delivery can still be delayed, or the destination contract can reject the message when it runs. A successful source transaction alone does not prove the destination action completed.

When a destination call fails, some systems allow a retry after the cause is fixed. Others may require a separate recovery step. The message ID or transaction record helps distinguish a send that never left the source from one waiting for delivery or one that failed during execution. Before sending a large amount, check the route’s recovery process and confirm the destination chain and token. The practical rule is simple: track the destination result, not just the source receipt.