Cross-chain smart contracts are application contracts on different blockchains that coordinate through messages. Together they can maintain shared workflows, move value, or trigger remote actions without forcing the entire application onto one network.
This page explains their architecture, common patterns, ordering, and failure handling.
What are cross-chain smart contracts?
Cross-chain smart contracts run on two or more blockchains and exchange authenticated messages as one application. Each contract follows its local chain's rules. The application defines how a remote event changes local state.
The design is similar to application services running in different data centers. Each service owns local state, and a message tells another service what happened. The services do not share one transaction or one database lock.
A cross-chain application may synchronize positions, move a token, request remote data, or act after a transfer. Its application logic spans chains.
How do cross-chain smart contracts work?
The source contract sends an encoded instruction through a messaging protocol. A verification system confirms the packet, then an execution service delivers it. The destination validates the sender and applies its own logic.
With LayerZero, an Omnichain Application, or OApp, owns that business logic. The Endpoint coordinates message state and delivery. The application configures trusted peers and verification for each pathway, then supplies or enforces execution options for its messages.
Verification and execution are separate stages. An authentic message can still fail during the destination call because of gas, state, or application errors.
What patterns do cross-chain applications use?
Architecture starts with deciding where state is authoritative and how messages flow.
| Pattern | State model | Good fit |
|---|---|---|
| Hub and spoke | One chain coordinates, others execute | Global limits, registries, or one canonical state |
| Point to point | Peers run equivalent logic | Symmetric applications without a central chain |
| Batch send | One transaction targets several chains | Configuration or state distribution |
| Request and response | Destination sends a result back | Workflows that need remote confirmation |
| Compose after receive | A second call follows message delivery | Transfer-then-act flows with isolated failure |
Every pattern remains asynchronous. A request-and-response flow needs at least two messages, and each chain finalizes its own transactions.
Are cross-chain transactions atomic?
Usually not across the full workflow. A source transaction can succeed before the destination transaction executes. Developers should therefore design for intermediate states and make each step safe to retry.
Some token standards provide local atomic guarantees. For an OFT transfer, the source debit is atomic with packet emission and the destination credit is atomic with delivery. That does not make an arbitrary multi-contract workflow globally atomic, and custom applications choose their own state transitions.
LayerZero delivery can be retried after an execution failure. The application must define any business-level expiry, compensation, and reconciliation for delays or partly completed actions.
How should ordering and duplicate handling work?
Messages should be independent by default unless state correctness requires a sequence. Ordered delivery can force a channel to process messages by nonce, but one blocked message can then hold later messages behind it.
Destination handlers should also be idempotent where possible, meaning that processing the same business instruction again does not apply the effect twice. Protocol-level replay protection and application-level business identifiers solve different problems. The first protects message delivery, while the second protects the application's own operation.
Rate limits, deadlines, pauses, and pathway permissions can contain failures. Monitoring should distinguish packet emission, source confirmations, verification and commit, destination execution, and any later composed execution.
Where do cross-chain smart contracts fit?
They are useful when a product needs shared behavior across ecosystems, not only asset transport. Examples include account state, remote settlement instructions, portfolio actions, and logic that follows a token.
Private blockchain interoperability applies the same coordination model across permissioned and public network boundaries. Cross-chain collateral management is a more specific workflow that connects collateral state on one chain with an obligation on another.
This page is not a rewrite of cross-chain messaging. Messaging explains how data moves and is verified. Cross-chain smart contracts explain how developers divide application state and safely act on that data.
FAQ
Can one smart contract run on multiple blockchains?
Contract code is deployed separately on each chain. The deployments behave as one application when they recognize one another as trusted peers and coordinate through messages.
Do cross-chain smart contracts share state instantly?
No. Remote state changes occur asynchronously when the verified message executes on the destination, after the configured source confirmations and verification steps. Applications need to tolerate that delay.
What happens when a destination call fails?
The source transaction generally remains complete. The application needs a retry, recovery, compensation, or expiry path for the destination action.
When should messages be processed in order?
Only when later state transitions depend on earlier ones. Independent messages are more resilient when they can execute without waiting for a blocked predecessor.
Build cross-chain smart contracts
Cross-chain smart contracts are reliable when state ownership, message authentication, asynchronous execution, and recovery are designed together. Start with the OApp documentation, or reach out to our team to discuss an application architecture.