A channel orders messages by sequence number within one application relationship. This lets a destination chain apply related updates in the intended order, even when delivery is delayed. For an app that needs shared state across chains, the omnichain blockchain approach coordinates updates across networks rather than treating each network as a separate app.
- Ordering usually applies to one channel, not every message in the system.
- Strict order protects dependent updates but can make later messages wait.
- Check what happens when a message fails on its destination chain.
What does ordering guarantee inside a channel?
Ordering means the destination processes a channel’s messages according to their sequence numbers. A channel is a named path for messages between an application and its counterpart, often between two chains. The guarantee does not automatically order traffic on other channels.
For example, an app sends messages 41, 42, and 43 to update a shared position. If message 42 arrives first, strict ordering makes the destination wait rather than apply 42 before 41. Once 41 is accepted, it can process 42 and then 43.
This is different from confirming that a message is authentic or will arrive. A verifier checks that a message is valid; a relayer carries it; the destination app executes it. Ordering controls execution order only if the application or messaging system enforces that rule.
How does a message move from send to execution?
The sender assigns each message a channel sequence number, then commits the message on its source chain. A verifier, which checks the source record, attests to the message. A relayer submits it to the destination, where the receiver checks the sequence and executes the application action.
Suppose messages 41 and 42 are sent in that order, but 42 reaches the destination first. The receiver sees that 41 is missing and holds 42. After 41 arrives and succeeds, the receiver can accept 42. This check is often called a nonce check: a nonce is a number used once to track the next expected message.
Some applications enforce this sequence themselves; others rely on their messaging framework or a configured channel. Hyperlane and Axelar are examples of cross-chain messaging systems, but an app’s exact ordering behavior depends on its integration and settings. Check the receiver’s code or documentation for the rule that rejects, queues, or accepts an out-of-order message.
What happens if an earlier message gets stuck?
With strict ordering, one failed message can block later messages on that same channel. This is head-of-line blocking: the first item in line prevents the rest from moving. A destination contract may run out of gas, reject an outdated action, or hit a temporary condition that makes execution fail.
Before: message 41 asks the app to open a position, but execution fails; message 42 asks it to add funds. After: if 42 depends on the position created by 41, applying 42 first could corrupt app state. The channel should preserve the order while offering a way to retry or resolve 41.
Recovery rules matter. Find out whether a failed message can be retried with more destination gas, whether it can be skipped safely, and who can authorize that action. Skipping is risky when later messages assume the failed action already happened. If the app supports independent updates, separate channels can reduce blocking, but they also require clear rules for shared state.
How should you choose ordering for your app?
Choose strict ordering when each update depends on the previous update, such as sequential balance changes or a multi-step position update. Choose unordered delivery when messages are independent and can be applied in any order. The deciding question is whether processing message 42 before 41 could produce a wrong result.
Strict order has a cost: later messages wait during delays or retries, and retries consume destination-chain resources. Unordered processing can improve throughput, but the app must handle duplicates and stale updates. A common design uses sequence numbers even without strict ordering, so the receiver can detect repeats or ignore older state.
For a task you need to complete now, inspect the exact app channel and confirm its expected sequence, failure, and retry behavior before sending dependent actions. Test an out-of-order arrival and a failed execution on a test environment if available. The omnichain design helps coordinate state across chains, but the app’s channel rules determine whether updates stay safe.
Takeaway: Order messages when later actions depend on earlier ones, and plan recovery for the first failed message.