Layer zero reconciliation links a recorded source action to its observed destination result
A reliable Layer zero message record keeps the starting state, packet identity, source transaction and intended destination effect together. After sending, follow the same packet through source emission, destination verification and execution instead of treating one status label as final. Then compare the receiving application's actual state with the result you intended. A successful source transaction proves that the source call completed; it does not prove that destination logic ran. If the records diverge, stop at the first unsupported state and investigate that boundary. This evidence-first method keeps a delayed message, a failed receive and an application mismatch from becoming one vague cross-chain problem.
Contents
Preserve one packet identity from source receipt to destination state, then investigate the first point where the records stop agreeing.
Source and destination records answer different questions
On EVM chains, a PacketSent event from the configured Endpoint V2 proves that the source call produced a packet. Destination records show whether that same packet reached verification and execution.
On the source chain, PacketSent records the encoded packet, execution options and selected send library. On the destination chain, PacketVerified shows that the endpoint committed the payload hash after the configured DVNs met the pathway's verification rule. During a normal receive, PacketDelivered records successful destination delivery. The receiving application's storage or emitted events must still confirm that the intended business state appeared.
The components behind the evidence trail
The application, endpoints, message libraries, DVNs and Executor have different roles in sending, verifying, executing and interpreting the packet.
The sending application supplies the destination endpoint ID, receiver, payload and execution options. Its endpoint advances the outbound nonce, constructs the packet GUID and passes the packet to the chosen send library. A successful send returns a MessagingReceipt containing the GUID, nonce and fee charged. Those values should enter the record directly from the receipt rather than from a dashboard label.
The V2 endpoint interface defines PacketSent, PacketVerified and PacketDelivered for separate points in the message lifecycle. The send library coordinates the configured verification and execution workers. DVNs verify the packet under the receiving pathway's rules, while the Executor submits the verified payload for destination execution. None of these roles defines the application's intended state change.
The receiving application interprets the payload and applies its own logic. That separation matters during reconciliation: protocol verification establishes an accepted payload hash, while application storage and events establish what the receiver actually did. Both directions also have their own pathway settings, so evidence from an outbound action does not establish anything about a later return action.
Which fields keep one message trace intact?
A durable trace keeps the source transaction hash, source endpoint ID, sender, destination endpoint ID, receiver, nonce and GUID together. Retain the payload or its hash and the execution options when access controls permit it. On the destination side, attach the verification and delivery transactions only after their origin fields, receiver and payload hash match the source packet.
The nonce is meaningful inside its messaging channel, not as a universal message number. Another sender, receiver or endpoint pair may use the same numeric nonce. The GUID gives the packet a wider identifier, but it does not replace the surrounding route fields or the application's starting state. Record the expected destination change in observable terms, such as a specific storage value, application event or balance change.
A reconciliation card for one packet
Use one compact record when the action is useful only after a stated destination condition becomes observable.
- Capture the relevant starting state and describe the intended destination change before sending.
- Save the source transaction, route fields, payload details and execution options from the completed send.
- Add the GUID, nonce and charged fee from the MessagingReceipt.
- Match destination verification and delivery evidence against the same origin, receiver and payload.
- Compare the receiving application's state with the recorded acceptance condition before closing the entry.
On the normal path, one identity set connects the source receipt to verification, execution and the intended application state. In the edge case, PacketVerified exists but the required destination state does not. Preserve the original packet record and treat destination execution as the recovery boundary. A later attempt belongs beneath that record; it must not overwrite the starting state or masquerade as a new successful send.
Cost inputs in the same record
Keep the pre-send quote beside the sender, destination, payload, execution options and payment mode used to request it. The selected send library, configured send-side DVNs and Executor also contribute to the quote. Obtain a fresh quote before sending and repeat it whenever the sender, destination, payload, options, payment mode or pathway configuration changes.
After sending, the MessagingReceipt supplies the fee charged for that packet. Keep it separate from the preliminary quote, the source transaction cost and any later destination transaction cost. A manual execution attempt uses a destination-chain transaction and therefore creates another cost record. Combining that amount with the original messaging fee would hide where the expense occurred and make two execution attempts look like one action.
When does the destination state match the recorded intent?
The destination matches only when the packet evidence and the receiving application's observable state satisfy the condition recorded before the send.
For a plain application message, that condition may be a receiver event or a particular storage transition. An OFT transfer calls for a comparison between the source-side debit, the destination-side credit and any application receipt fields that describe the delivered amount. The packet status cannot supply those application-specific facts because its events describe messaging progress rather than every effect produced by receiver logic.
Composed actions need an additional boundary. The initial receive may complete before a separate lzCompose call executes its follow-up logic. Record the first receiver result and the composed call independently, even when both contribute to one user intent. Closing the record at the first delivery would miss a failed or pending follow-up action.
How should one mismatch be bounded?
Bound a mismatch at the last pair of records that agree, then inspect the next expected transition without changing the original packet identity.
If PacketVerified matches the source packet but the expected destination state is absent, the verification boundary has already passed. Inspect the destination execution transaction, receiver trace and any LzReceiveAlert for that packet. Insufficient execution resources and receiver logic errors require different corrections, but both remain destination-execution problems. Sending another source packet would create a new GUID and complicate the comparison.
Retry only after identifying the failed condition and confirming that you still have the original payload bytes needed for execution. Continue waiting when the next protocol action is genuinely pending. A retry continues the original packet's history, while a new send creates another action with its own starting state and reconciliation record.
Still have questions?
Does a fee quote identify the packet that was sent?
No. A quote estimates the fee for supplied messaging parameters before the endpoint creates the sent packet. The completed send returns the GUID, nonce and charged fee in its MessagingReceipt. Use that receipt to identify the packet, while keeping the earlier quote only as a record of the destination, payload, options and payment mode that were priced.
Why retain payload bytes when the record already has a hash?
The hash can confirm that a known payload matches a commitment, but it cannot reconstruct or explain the original bytes. Retaining the exact payload lets an operator reproduce the hash, decode the receiver input and compare later execution data with the original action. Store it with the packet identity rather than as an unattached message sample.
When should a composed call receive its own reconciliation entry?
A composed call needs its own entry whenever the intended result depends on separate lzCompose execution. The initial destination receive and the follow-up call are distinct execution steps, even when they share a wider application purpose. Record the composed transaction, target, index and resulting application state instead of treating the first delivery as proof that every follow-up action completed.
Is a dashboard status enough to close the packet record?
No. A dashboard status is a useful view, but the underlying source receipt, destination events and application state should agree before the record closes. Match the GUID and route fields first, then confirm the receiving application reached the stated condition. An indexer's delayed or simplified label does not alter the on-chain packet state.
Should source and destination timestamps be collapsed into one completion time?
Source and destination times should remain separate because they describe different transactions on different chains; when a business record needs one completion time, use the destination transaction that established the required application state and retain the source send time alongside it.
Where does an off-chain update fit in the evidence trail?
An off-chain update is a downstream application record, not proof of protocol delivery. Attach it after the matching destination transaction and application state. PacketDelivered does not guarantee that an indexer, database or notification service processed the change. If the on-chain state is correct but the external record is missing, investigate that consumer without resending the packet.
ยท updated