Most bridge audits stop where the Solidity ends.
They review lock/mint, burn/unlock, merkle proofs, light-client updates, and the verifyMessage path that gates value on the destination chain. That work matters. It is also incomplete.
Cross-chain systems do not fail only inside one contract. They fail in the gap between “a proof verified on-chain” and “the message that was verified is the message the product meant to accept.” Relayers, oracles, guardians, offchain signers, and receiving-side handlers sit in that gap. They rarely get the same attention as the bridge bytecode.
This note is for protocol security leads, founders shipping interoperability, and anyone scoping a bridge review who still treats the destination verifier as the whole story.
What “verified” usually means
On the receiving chain, “verified” almost always means one of:
- A light-client / consensus proof that a source-chain event occurred
- A Merkle / inclusion proof against a committed root
- A threshold of guardian or validator signatures over a message digest
- An optimistic challenge window that expired without a fraud proof
Those checks answer a narrow question: was this payload authorized by the bridge’s chosen trust model?
They do not automatically answer:
- Was the source event the economic event the product thinks it is?
- Can the same logical transfer be delivered twice under different wrappers?
- Who can change the set of people allowed to attest?
- What happens if the receiver trusts a message type the sender never intended?
If your threat model ends at require(verified), you are protecting the proof system—not the product.
Where the failure modes actually live
### 1. Message identity that is not stable
Receivers often key idempotency on (srcChainId, nonce) or a hash of the encoded payload.
Problems show up when:
- Encoding is not canonical (ordering, padding, optional fields)
- The same economic action can be packaged as two message types
- A “retry” path re-emits with a new nonce after a partial success
- Refund / unwind messages share identifiers with deposit messages
The contract verified a message. The protocol needed this transfer exactly once.
Audit questions that matter: what is the idempotency key, where is it stored, and can two valid proofs map to the same user-facing outcome?
### 2. Relayers that are not just transport
Documentation says the relayer “cannot forge messages.” That is true under a correct proof scheme.
Relayers still choose:
- Which messages get delivered first
- Whether a message is delivered at all
- Whether competing messages race into the same receiver state
- Whether destination gas / fee markets can starve an unlock while a mint proceeds elsewhere
Censorship and ordering are not academic. They turn into stuck liquidity, forced liquidations, and governance theatre about “temporary” manual unlocks.
If a privileged operator can push a “rescue” mint without the normal proof path, write that down as a second bridge.
### 3. Guardian and oracle sets that drift
Many production bridges still depend on a multisig, guardian set, or offchain attestation committee for upgrades, pause, or message attestation.
Field pattern:
- The on-chain verifier looks rigorous
- The signer set is a Safe that also controls upgrades
- Membership changes without the same review cadence as contract upgrades
- Emergency pause can also authorize exceptional messages
A proof check that trusts seven keys is only as strong as how those keys are rotated, recovered, and monitored. That is signer-ops work, not a Solidity finding—and it decides whether “threshold signature” means decentralization or a shared admin.
### 4. Receiving handlers that over-trust the payload
Destination apps often treat a verified bridge message as an authenticated API call: mint, credit balance, open a position, update a price, whitelist a collateral type.
The bridge verified transport integrity. The handler still has to enforce:
- Asset mapping that cannot be remapped by a compromised config role
- Decimal / denomination checks across chains
- Caller restrictions so only the bridge endpoint can invoke the credit path
- Bounds on mint amounts relative to locked inventory or attested supply
We keep seeing handlers that check msg.sender == bridge and then decode an arbitrary amount and token with no inventory invariant. The message was verified. The economics were not.
### 5. Ambiguous finality on the source side
Light clients and optimistic designs inherit source-chain finality assumptions.
If the sender treats a soft confirmation as final, or if reorg depth is underestimated, the destination can mint against a state that later disappears. The reverse also happens: destination unlocks that assume source burn finality that operations staff later “fix” with a manual path.
Cross-chain risk is often a finality mismatch dressed up as a messaging feature.
A practical review boundary
When AN3 scopes interoperability, we force the diagram past the bridge contract:
- Message schema — fields, versioning, canonical encoding, what is signed vs what is implied
- Idempotency — exact key, storage, replay windows, retry semantics
- Actors — relayers, guardians, upgraders, pause admins, fee collectors: who can delay, reorder, or bypass
- Receiver invariants — inventory, mapping, decimals, authorization, and what a malicious-but-valid message can do
- Finality — source confirmation policy, reorg handling, and whether ops has a manual override
- Change control — how signer sets, endpoints, and message versions upgrade in production
If any row is “the partner handles that,” it is still in your blast radius.
Closing note
Bridge contract verification is necessary. It is not sufficient.
The expensive failures in 2025–2026 keep landing where proofs are correct and assumptions are wrong: unstable message identity, privileged delivery paths, drifting attestation sets, and receivers that treat a verified blob as a blank check.
Teams that review the whole path—source event, attestation, transport, and destination effect—find those gaps before liquidity does.
AN3 Intel · field notes on onchain interoperability risk.