Lesson: Cross-chain consumer message-trust - where to actually look, and where it's a dead end

Date: 2026-06-11 Class: SEAMS / cross-chain message trust (consumer-side receive-handler) Source case: Venus Protocol OmnichainGovernanceExecutor (LayerZero v1), Arbitrum 0xc1858cCE6c28295Efd3eE742795bDa316D7c7526. WALK-CLEAN.

The 5-subclass checklist for ANY cross-chain consumer (reusable)

When auditing a _lzReceive/_handle/receiveWormholeMessages/_ccipReceive/nonblockingLzReceive consumer, verify ALL five. A gap in any one = potential takeover. Venus passed all five:

• (a) SOURCE: handler verifies srcChainId AND srcSender/peer/trustedRemote. For LZ v1 this is keccak256(_srcAddress)==keccak256(trustedRemote) in LzApp.lzReceive + the app's own srcChainId_==srcChainId.
• (b) REPLAY: nonce/dedup. LZ v1 endpoint enforces nonce ordering; GOOD apps ALSO add an app-level dedup (Venus: require(proposals[pId].id == 0)). Belt-and-suspenders.
• (c) TRUSTED-REMOTE CONFIG: the live mapping must be set, non-zero, correct-chain. ALWAYS cast read it - do not assume. LZ v1 packs abi.encodePacked(remoteAddr(20), localAddr(20)); the local half should equal the consumer itself.
• (d) CALLER: outer handler requires msg.sender == endpoint/router/mailbox; the inner non-blocking re-entry requires msg.sender == address(this).
• (e) COMPOSE/RETRY: lzCompose / retryMessage / VAA-resubmit paths must NOT skip checks. Venus made retryMessage STRICTER (onlyOwner + trustedRemote recheck) than the permissionless LZ base.

What WORKED (method)

• Reading the INHERITED base (LzApp/NonblockingLzApp) is mandatory. The consumer's own .sol often shows only srcChainId_==srcChainId and looks under-validated; the real source/caller gate lives in the LZ base. Do not call "MISSING SOURCE VALIDATION" until you've read the parent.
• Live cast reads of trustedRemoteLookup + srcChainId + endpoint turn a code-only WALK into a config-validated WALK. The seam is often a MISCONFIG (c), not a code bug - and only on-chain reads catch that.
• Forking mainnet and asserting vm.expectRevert on direct/forged/replay/retry calls gives REAL empirical proof of the defense (5 PASS = 5 reverts). Cheap, deterministic, no archive node needed.

What's a DEAD END (negative result, avoid re-mining)

• Well-built LZ v1/v2 OApps that inherit LzApp/OAppReceiver correctly are NOT exploitable via subclasses (a)/(d) - the base enforces them. Spending time forge-testing a textbook OFT/executor that inherits cleanly = low yield. Confirm inheritance is clean, cast-read the config, and MOVE ON.
• Subclass (b) replay is double-guarded on LZ (endpoint nonce + app dedup) - rarely the seam on LZ consumers.

Where the YIELD actually is (forward hunting pointers)

• Consumers that DON'T inherit a standard base and hand-roll lzReceive (custom integrations) - check (a)/(d) by hand.
• (c) MISCONFIG on a freshly-deployed or newly-added satellite chain: trustedRemote set wrong/unset, or srcChainId set to the wrong LZ id, BEFORE the team finishes wiring. cast-read every satellite the day it deploys.
• (e) COMPOSE on LZ v2 (lzCompose) and CCIP retry - the second-class paths are where a check the main path has gets dropped.
• Cross-bridge: a consumer that accepts messages from MULTIPLE bridges (e.g. LZ + a fallback) and only validates one path.

Scope rule (banked)

LayerZero's Immunefi program EXCLUDES "impacts to OApps as a result of their own misconfiguration." A consumer-side trustedRemote/srcChain bug is therefore NOT payable under LayerZero - it must be routed to the CONSUMER protocol's own bounty (here, Venus). Always map a consumer-side finding to the consumer's program, not the bridge's.