1. A message has a source and destination domain
Cross-chain protocols move messages between separately governed domains. A message normally identifies its source chain, sender or mailbox, destination chain, recipient and payload. The same payload bytes on a different chain do not have the same meaning automatically. Record domain identifiers rather than relying on chain names displayed by a bridge interface.
Authentication may use a light client, validity proof, validator set or multisignature. These models have different assumptions. A green status label from a relayer does not by itself reveal which proof or signer set authorized the message.
2. Nonces prevent accidental duplication
Many messaging systems attach a nonce or unique identifier to each sender and destination. The receiving contract can reject a message that was already executed. Replay protection must cover the relevant domain and version; a simple payload hash may not be enough if the same message is valid in another context.
When debugging, compare the message ID, nonce, source transaction and destination execution. Never retry by manually calling the recipient with copied calldata unless the protocol documents that route. A duplicate call could trigger a second action if the recipient contract does not enforce its own idempotence.
3. Proof acceptance is not destination success
A relay may deliver a proof to the destination contract, which then verifies origin and marks the message executable. The recipient call can still revert because of gas, paused state, changed permissions or invalid payload arguments. Keep proof status and execution status as separate records.
If a retry is supported, use the official retry function and inspect the target and value. A relayer's failure may be recoverable without changing the message. Paying an arbitrary address for a “manual unlock” is not a documented recovery path.
4. Upgrade and validator changes are part of the trust model
Bridge contracts, mailboxes and validator sets can be upgraded. A source that was safe under one implementation may have different rules after an upgrade. Check who can change the verifier, pause messages or alter domain configuration. Look for timelocks, governance records and emergency procedures.
Save contract addresses by network and implementation version. When an official migration changes the endpoint, update allowlists and integration code deliberately. Do not infer that two contracts are equivalent because they share a brand or interface.
5. Inspect payloads before signing
A cross-chain approval may contain token transfers, arbitrary contract calls or a batch of operations. Read the payload target, method and amount. If the wallet cannot render the message clearly, obtain an independently decoded representation from trusted source code and compare the bytes or typed fields.
The destination recipient may be a proxy that forwards calls. Confirm the expected behavior and avoid signing a message designed only to “test” a bridge. Use separate keys for experiments where possible, and never reveal recovery secrets to support staff.
Worked example: authenticated but reverted
A source transaction publishes a message to a destination mailbox. The verifier accepts the proof, but the recipient contract is paused, so execution reverts. The message is authentic and may be retryable; it is not equivalent to a completed token transfer. The operator records the source hash, message ID, proof result and destination revert before following the official pause or retry process.
This distinction prevents a user from sending a duplicate transfer while the original message is still pending resolution.
FAQ
Does a successful bridge deposit prove the withdrawal path works?
No. The two directions can use different contracts, proof timing and emergency controls. Test the documented withdrawal route with an amount you can afford to lose and record every network and contract address.
Practical record for this topic
When documenting a message, write the source domain, source sender, destination domain, recipient, nonce, payload hash, verifier contract and execution result on separate lines. This prevents a relayer status from being mistaken for a destination transfer. If a retry is possible, include the exact official function and the condition that makes it valid. Never publish a real user payload that exposes addresses or business relationships without permission.