Layer zero routes application messages through configurable verification paths
Layer zero is an omnichain messaging protocol that lets applications exchange data across supported blockchains through endpoint contracts. Each application sets a remote peer for the route and can override default message libraries and verifier configuration; each message carries its execution options. A destination endpoint accepts a payload as verified only after the configured Decentralized Verifier Networks (DVNs) satisfy that route's rules; a separate call then executes it in the receiving application.
The useful unit is a directional pathway, not a vague chain-to-chain connection. Its configuration and message state show what was authorized, which verifications arrived and whether destination logic completed.
A message is complete only after its configured verification rules pass and the destination application executes the matching payload.
Application messages and token actions
The protocol gives omnichain applications, or OApps, a common interface for sending bytes from one endpoint to another.
An OApp defines what those bytes mean. The payload might request a state update, carry instructions for a remote contract or coordinate another application-specific action. Endpoint V2 assigns the packet to the configured send library, while that library quotes and assigns work to the selected DVNs and Executor. This division keeps application logic separate from transport and lets each OApp choose its security configuration.
Token movement is one application of that messaging layer. An Omnichain Fungible Token (OFT) contract coordinates a debit on the source deployment with a credit on the destination deployment. The endpoint transports the instruction and verifies its payload, but the OFT contracts enforce token accounting. Other OApps can use the same transport for governance messages, state synchronization or contract calls without adopting the OFT model.
Applications can also attach execution options or request a composed follow-up call. Those features extend what happens after verification, yet the receiving contract still determines whether the payload is authorized and how it changes application state.
Directional pathways and peer scope
A pathway connects one local OApp to a remote peer through specific source and destination endpoint IDs. The reverse direction has its own settings. Configuration tooling may describe both directions together, but a working outbound path does not prove that the return path uses matching libraries, verifiers or confirmation requirements.
Each pathway can select its own send library, receive library and DVN configuration. The source send configuration must provide the verification work that the destination receive configuration expects. A missing required DVN or a send-side confirmation level below the destination requirement leaves the destination without enough evidence to commit the payload hash.
Endpoint IDs, often shortened to EIDs, identify Layer zero deployments used by pathways. They are not interchangeable with native chain IDs. The peer mapping adds another boundary by binding a remote EID to the OApp address that the receiver accepts as its counterpart.
Packet identity from send to receive
A send starts with a quote for the chosen destination, payload and options. After the application pays the quoted messaging fee, the source endpoint increments the outbound nonce and emits the encoded packet through its selected message library.
A successful send returns a messaging receipt containing a GUID and nonce. The GUID is the cross-chain tracking identity, while the nonce places the packet within its communication channel. Source and destination transaction records can therefore be correlated without treating a wallet address or transaction position as the message identity.
The packet header identifies the source endpoint, destination endpoint, sender, receiver and nonce. Verification also binds the message body through its payload hash. Changing the payload after dispatch would produce a different hash, so the destination cannot execute altered bytes against the stored verification record.
DVN rules for message acceptance
DVNs observe the source-chain packet and submit verification evidence under the route's selected message library. Required DVNs must all verify. An OApp may also configure optional DVNs and a threshold that determines how many of that optional set must agree. The destination receive library checks those conditions before committing the payload hash to Endpoint V2.
Confirmation requirements are part of this decision. A verifier waits for the configured source-chain confirmation level before reporting the packet, and the destination evaluates the evidence against its receive configuration. The live path settings matter more than a protocol-wide assumption because applications can replace defaults with custom choices.
Verification proves that the accepted packet matches the source event under the chosen security stack. It does not prove that the receiving application's business logic will accept the request.
Verification before destination execution
Verification and execution are separate phases. Once Endpoint V2 records a matching payload as verified, an Executor can call the destination endpoint to deliver it, or another caller can invoke the permissionless receive function. The receiving OApp checks the source EID and peer before processing the message. Execution options can request gas and value for that call, but destination logic must enforce any condition that cannot safely depend on a worker honoring a request.
A failed delivery with a reversible retry
Every changing input in this example is hypothetical: the source and destination EIDs, both OApp addresses, the peer mapping, the payload, the DVN set, the verification threshold and the execution gas request. The acceptance condition is that the receiver stores the submitted state value and the destination execution succeeds.
Before sending, the operator confirms that the remote peers match and that the source send configuration can satisfy the destination receive rules. The source transaction then commits the message, producing its GUID and nonce. The configured DVNs verify the payload, and the destination emits its verification record. An undersized gas request causes the later receive call to fail, so the receiver's state remains unchanged and an execution alert records the cause.
The smallest reversible response is to keep the verified packet and retry its destination execution with sufficient gas. Resending from the source would create another nonce and GUID without repairing the original delivery. After the retry succeeds, the receiver contains the submitted value, and the follow-up check ties that state change to the original GUID and destination transaction.
Observable states across the route
A confirmed source transaction establishes that the endpoint accepted and emitted the packet. It does not establish destination verification or application execution. The next meaningful boundary is the destination's verification record, which shows that the required DVN conditions were met and the matching payload hash was committed.
Completion requires a successful destination call and the expected application-level result. A destination transaction can reach Endpoint V2 yet fail inside the receiver because of insufficient gas, invalid payload parameters or application logic. Monitoring should therefore retain the source receipt, destination verification state and final receive outcome rather than collapsing them into one pending-or-complete label.
Nonces support channel accounting, but nonce assignment alone does not require every application to execute messages in order. An OApp that depends on ordered state transitions must use the appropriate execution option and receiver logic for that requirement.
Configuration mismatches that halt progress
A packet that remains unverified often points to the boundary between the source send settings and destination receive settings. The destination may expect a DVN that the source never assigned, a higher confirmation requirement or a different receive library. More waiting cannot supply work that was never configured.
Execution failures occur after verification. A wrong peer mapping, an unauthorized source or invalid application data can leave a packet verified while the receiving contract rejects it. Insufficient destination gas can produce the same high-level failure state for a different reason. Locating the last completed boundary separates verification trouble from receiver trouble and prevents an unrelated configuration change.
Recovery from the recorded failure state
A failed receive call does not erase a verified message. The endpoint restores the payload so a later attempt can process it.
A verified payload that fails during destination execution can be retried without sending it again from the source chain. A new Executor or permissionless caller may supply adequate resources, but the payload must still match the stored hash and pass the receiving application's checks.
An unverified packet needs a different response. Calling the receive function again cannot replace missing DVN evidence. The operator must inspect confirmations, send and receive configurations and assigned workers to identify the unmet condition. Altering a security configuration solely to unblock one packet also changes the route's trust assumptions.
Endpoint V2 exposes administrative message-state operations such as skip, clear, nilify and burn for specific channel conditions. These operations are not ordinary delivery retries and can suppress or remove a message. The OApp's authorized control and intended state transition must be understood before using one. A receive retry remains the narrower response when verification is complete and execution resources caused the failure.
Fees and execution resources
A messaging quote reflects the selected route rather than a fixed cross-chain price. Its inputs include the payload, destination EID, configured DVNs, Executor and serialized options. Worker fees compensate verification and delivery services, while the source transaction also consumes its chain's normal execution gas.
Execution options specify resources for destination calls, including gas and any value passed with the receive operation. An OApp can enforce baseline options and allow callers to add compatible extra options. The configured Executor may also impose a destination resource cap, so a larger request is not automatically valid.
The fee quote should be generated for the same payload and options used by the send. Changing either can change the required payment. A successful fee payment commits the packet, but it does not override peer checks, DVN thresholds or receiver logic at later stages.
Message completion evidence
A complete record begins with the intended source and destination EIDs, peer mapping and pathway configuration. The source receipt fixes the GUID and nonce. Destination verification then proves that the configured evidence accepted the matching payload, while the successful receive transaction shows that execution reached the OApp.
Application state provides the final check. An OFT transfer should show the intended source debit and destination credit effects, while a state message should show its defined receiver update. If a composed call is part of the operation, that follow-up outcome needs its own confirmation. For Endpoint V2, the GUID and nonce anchor these records to one message rather than a later retry or duplicate send.
Questions people ask about Layer zero
-
Is an endpoint ID the same as an EVM chain ID?
- No. A Layer zero endpoint ID identifies a protocol deployment and routing destination, while an EVM chain ID identifies a blockchain network for transaction signing and replay protection. Integrations must use the EID expected by Endpoint V2. Substituting a chain ID can select no valid pathway or direct configuration checks toward the wrong destination.
-
Does every message need the ZRO token?
- No. A messaging quote can include a native fee and, when the endpoint supports it, a ZRO-denominated fee component. Configured DVNs and the Executor still have worker costs that may require the source chain's native payment. The application should use the quote returned for its exact path, payload, options and selected payment mode.
-
Could an Executor change a message payload before delivery?
- An altered payload cannot satisfy the verification record for the original message. DVNs verify a payload hash, and the destination endpoint stores that hash before execution. The receive call must supply message bytes that match it. The Executor transports the verified message and provides execution resources; it does not gain authority to rewrite the accepted application data.
-
When should an application require ordered execution?
- Ordered execution is appropriate when a later message would be invalid or unsafe before an earlier nonce changes application state. The application must request and enforce that behavior through its execution configuration and receiver design. Independent messages may use unordered execution, which avoids making every later delivery wait behind one delayed or failing message.
-
Who controls token balances during an OFT transfer?
- The OFT contracts control token accounting on their respective chains. Layer zero transports and verifies the cross-chain instruction, while the source OFT applies its debit logic and the destination OFT applies its credit logic. The exact accounting model belongs to the token implementation, so endpoint verification should not be mistaken for protocol custody of user balances.
ยท updated