Skip to main content

Message Design Patterns

Each design pattern functions as a distinct omnichain building block, capable of being used independently or in conjunction with others.

Message PatternDescription
ABone way data transfer from source to destination (A -> B)
ABAa nested send call from Chain A to Chain B that sends back again to the source chain (A -> B -> A)
Composeda message that transfers from a source to destination chain and calls an external contract (A -> B1 -> B2)
Composed ABAtransfers data from a source to destination, calls an external contract, and then calls back to the source (A -> B1 -> B2 -> A)
Batch Senda single send that calls multiple destination chains

This modularity allows for the seamless integration and combination of patterns to suit specific developer requirements.

note

You can refer to Design Patterns Repo to see example implementations of the patterns discussed here.

AB Pattern

The AB message type refers to a one way send call from a source to destination blockchain.

OFT Example OFT Example

In the OApp Quickstart, we use this design pattern to send a string from Chain A to store on Chain B (A -> B).

ABA Pattern

The ABA message pattern extends this simple logic by nesting another _lzSend call within the destination contract's _lzReceive function. You can think of this as a ping-pong style call, pinging a destination chain and ponging back to the original source (A -> B -> A).

ABA Light ABA Dark

This pattern demonstrates vertical composability, where the nested message contains both handling for the message receipt, as well as additional logic for a subsequent call that must all happen within one atomic transaction.

info

This message pattern can also be considered an ABC type call (A -> B -> C), as the nested _lzSend can send to any new destination chain.


This is particularly useful when actions on one blockchain depend on the state or confirmation of another, such as:

  • Conditional Execution of Contracts: A smart contract on chain A will only execute a function if a condition on chain B is met. It sends a message to chain B to check the condition and then receives a confirmation back before proceeding.

  • Omnichain Data Feeds: A contract on Chain A can fetch data from the destination (Chain B) to complete a process back on the source.

  • Cross-chain Authentication: A user or contract might authenticate on chain A, ping chain B to process something that requires this authentication, and then receive back a token or confirmation that the process was successful.

Composed Pattern

A composed message refers to an application that invokes the Endpoint method, sendCompose, to deliver a composed call to a destination contract via lzCompose.

Composed Light Composed Dark

This pattern demonstrates horizontal composability, which differs from vertical composability in that the external call is now containerized as a new message packet; enabling the application to ensure that certain receipt logic remains separate from the external call itself.

info

Since each composable call is created as a separate message packet via lzCompose, this pattern can be extended for as many steps as your application needs (B1 -> B2 -> B3, etc).


This pattern can be particularly powerful for orchestrating complex interactions and processes on the destination chain that need contract logic to be handled in independent steps, such as:

  • Omnichain DeFi Strategies: A smart contract could trigger a token transfer on the destination chain and then automatically interact with a DeFi protocol to lend, borrow, provide liquidity, stake, etc. executing a series of financial strategies across chains.

  • NFT Interactions: An NFT could be transferred to another chain, and upon arrival, it could trigger a contract to issue a license, register a domain, or initiate a subscription service linked to the NFT's ownership.

  • DAO Coordination: A DAO could send funds to another chain's contract and compose a message to execute specific DAO-agreed upon investments or funding of public goods.

Composed ABA

The Composed ABA design pattern enables sophisticated omnichain communication by allowing for an operation to be performed as part of the receive logic on the destination chain (B1), a follow-up action or call containerized as an independent step within lzCompose (B2), which then sends back to the source chain (A).

ComposedABA Light ComposedABA Dark

info

This message pattern can also be considered a Composed ABC type call (A -> B1 -> B2 -> C), as the nested _lzSend can send to any new destination chain.


This pattern demonstrates a complex, multi-step, process across blockchains where each step requires its own atomic logic to execute without depending on separate execution logic. Here are some use cases that could benefit from a Composed ABA design pattern:

  • Omnichain Data Verification: Chain A sends a request to chain B to verify a set of data. Once verified, a contract on chain B executes an action based on this data and sends a signal back to chain A to either proceed with the next step or record the verification.

  • Omnichain Collateral Management: When collateral on chain A is locked or released, a corresponding contract on chain B could be called to issue a loan or unlock additional funds. Confirmation of the action is then sent back to chain A to complete the process.

  • Multi-Step Contract Interaction for Games and Collectibles: In a gaming scenario, an asset (like an NFT) could be sent from chain A to B, triggering a contract on B that could unlock a new level or feature in a game, with a confirmation or reward then sent back to chain A.

Batch Send

The Batch Send design pattern, where a single transaction can initiate multiple _lzSend calls to various destination chains, is highly efficient for operations that need to propagate an action across several blockchains simultaneously.

Batch Send Light Batch Send Dark

This can significantly reduce the operational overhead associated with performing the same action multiple times on different blockchains. It streamlines omnichain interactions by bundling them into a single transaction, making processes more efficient and easier to manage for example:

  • Simultaneous Omnichain Updates: When a system needs to update the same information across multiple chains (such as a change in governance parameters or updating oracle data), Batch Send can propagate the updates in one go.

  • DeFi Strategies: For DeFi protocols that operate on multiple chains, rebalancing liquidity pools or executing yield farming strategies can be done in batch to maintain parity across ecosystems.

  • Aggregated Omnichain Data Posting: Oracles or data providers that supply information to smart contracts on multiple chains can use Batch Send to post data such as price feeds, event outcomes, or other updates in a single transaction.