Boundary guide, payable-function check (msg.value > 0: where does it end up?). lzReceive is payable because LayerZero executors forward the native value requested by the sender's lzReceive option (gas, value). OFTCore._lzReceive (src/vendor/@layerzerolabs/oft-evm/contracts/OFTCore.sol:270-309) never reads msg.value, the adapter declares no receive() or fallback(), and by requirement it has no rescue function, so every wei that arrives this way is locked forever.

The author documents this in README.md ('Inbound execution value should be zero') and docs/SECURITY.md, but nothing enforces it: the value option is chosen per message by the Robinhood sender, and the adapter cannot stop an executor from attaching it.

The remaining lever is operational (enforced options and interface guidance); if the author wants an on-chain guard, reverting in _lzReceive when msg.value != 0 would make the packet retryable with zero value through the endpoint instead of silently stranding the ETH, at the cost of one extra check per receive.

Numerical Gap guide, view/write seam (the view's math omits a check the write applies). quoteOFT returns maxAmountLD = ZTO.totalSupply() and computes the receipt through _debitView only, which floors dust and checks slippage but never calls _toSD. quoteSend and send both call _toSD, which reverts with AmountSDOverflowed when amountLD / 1e12 > type(uint64).max, i.e. amountLD > 18_446_744_073_709_551_615e12.

So quoteOFT reports a sendable receipt for amounts the same contract will reject. Against the live token this is unreachable: ZTO.totalSupply() read on Ethereum mainnet is exactly 1e27 (1e15 shared units, about 1/18_000 of the cap), and the adapter never mints, so no holder can assemble an amount that trips the cap.

Recorded so integrators relying on quoteOFT limits know the real bound is min(totalSupply, type(uint64).max * 1e12); the README already says quoteOFT does not guarantee a valid uint64 packet amount.

Asymmetry between the two receive-side guards. The real path lzReceive() uses _getPeerOrRevert(_origin.srcEid), which reverts NoPeer when peers[eid] == bytes32(0) (OAppReceiver.sol:122, OAppCore.sol:69-73).

The pre-crime path lzReceiveAndRevert() instead filters packets with isPeer(srcEid, sender) (OAppPreCrimeSimulator.sol:50), which is a plain equality: for every eid that has no peer (every eid except 30416, and 30416 itself after the owner removes the peer with setPeer(30416, 0)) a packet whose origin.sender is bytes32(0) compares equal to the unset slot and is treated as trusted.

The simulation then runs _lzReceive -> _credit and releases custody to the recipient encoded in the attacker-chosen message before the mandatory SimulationResult revert. The same equality is used by allowInitializePath (OAppReceiver.sol:71), which returns true for Origin(eid, bytes32(0), n) whenever the peer slot is empty.

No state persists because lzReceiveAndRevert always reverts and the real endpoint never produces a zero sender, so the impact is limited to the pre-crime oracle: an off-chain pre-crime run (or any caller of lzReceiveAndRevert) is told that a packet lzReceive would reject executes successfully and drains custody, which inverts the purpose of the simulation.

It also means the 'trusted' set reported by isPeer() is wider than the set lzReceive enforces, so any future code or tooling that keys on isPeer() inherits a hole. Minimal fix that preserves upstream behaviour: in ZTOAdapter override isPeer to return _eid == ROBINHOOD_EID && _peer != bytes32(0) && peers[_eid] == _peer; (or at least _peer != bytes32(0)), and optionally override allowInitializePath the same way.

Branch asymmetry between the two writers of the endpoint delegate. The constructor path (OAppCore.sol:29) reverts InvalidDelegate when _delegate == address(0), but the owner-only setDelegate that the brief requires as the fallback registration path forwards any value, including zero, to endpoint.setDelegate. The production EndpointV2.setDelegate performs no validation either, so the owner can clear the delegate mapping.

With a zero delegate nobody can change send/receive libraries, DVN configuration or skip/clear/nilify packets for this OApp until the owner calls setDelegate again (the adapter itself exposes no other endpoint-config call). This is owner-only and fully recoverable, so it is a consistency note, not a permission bypass; it is reported because the author deliberately changed the constructor branch and left the fallback branch without the same check.

Fix: if (_delegate == address(0)) revert InvalidDelegate(); in setDelegate (or in a ZTOAdapter override).

Documented, intended power; recorded here as the trust boundary the launch relies on, not as a bypass. The onlyOwner guard holds and the eid restriction works, but the value of peers[30416] is the only authentication of inbound release requests.

Whoever controls the owner key can repoint the peer to any Robinhood contract they control, after which every message that contract emits (once verified by the configured DVNs) is honoured by lzReceive and _credit transfers the requested amount of locked ZTO to any recipient. The same call rejects all in-flight packets from the legitimate Robinhood OFT with OnlyPeer until the peer is restored, so a peer change while packets are pending strands those returns.

Independently, the LayerZero delegate (0xcecc..., set in the constructor on the real chain, changeable via setDelegate) can on the real EndpointV2 change the receive library and DVN set for this OApp, which is an equivalent route to forged inbound messages, and can clear or nilify verified packets so that burned Robinhood tokens are never released here.

Owner-controlled setMsgInspector and setEnforcedOptions can also halt all outbound sends (inspector revert / invalid enforced options), which is an outbound pause even though the brief says 'no pause'; inbound releases are unaffected. The live ZTO token (checked over RPC) is a minimal ERC-20 with only the nine standard selectors, 18 decimals and 1e27 supply, so no third-party token admin can freeze custody; the owner and delegate keys are the only privileged actors.

README 'Administrative trust' already states this.

The adapter uses OpenZeppelin Ownable (single step) rather than Ownable2Step. transferOwnership to a mistyped or non-controllable address, or renounceOwnership, is irreversible and leaves no account able to call setPeer, setDelegate, setEnforcedOptions or setMsgInspector.

Because the only remote is a single Robinhood OFT and there is no upgrade or rescue path by requirement, losing the owner means the peer can never be replaced if the Robinhood side must be redeployed, and the registered delegate keeps endpoint authority with no on-chain counterpart able to rotate it.

This matches 'standard OApp semantics' requested by the brief and is documented in the README; it is recorded as the trust assumption the judge should see, not as a defect requiring a design change. If the requester wants protection, Ownable2Step preserves the owner model while making the transfer confirmable; renounce can be overridden to revert.

DEPENDENCIES.json records per-file SHA-256 hashes and VENDORED.md says exactly two vendored files differ from upstream. Byte-for-byte that is false: the whole vendored tree under src/vendor/@layerzerolabs and src/vendor/@openzeppelin was reformatted (forge fmt style: import brace spacing, signature line wrapping, comment placement), so 30 of the 39 hashed files fail the recorded hash and diff against the npm tarballs reports differences in every LayerZero contract.

I downloaded the four npm tarballs named in DEPENDENCIES.json and compared each file with comments and whitespace stripped: only OFTAdapter.sol (explicit uint8 _localDecimals, no decimals() call) and OAppCore.sol (setDelegate guarded by _endpoint.code.length != 0) carry code changes, exactly as documented, so there is no hidden modification.

The defect is that the documented verification procedure cannot be followed: anyone checking provenance from the recorded hashes gets mismatches on files that are claimed unchanged and cannot distinguish a formatting change from a semantic one without re-deriving the comparison. Either record hashes of the files as vendored (and state that the tree is reformatted), or vendor the upstream bytes unchanged (foundry.toml already excludes src/vendor/** from fmt).

Documented as a privileged-power trust assumption, not a permission bypass: all guards hold and the brief requires this owner/delegate. The single EOA 0xcECc...A551 (live nonce 16, no code) is both Ownable owner and the LayerZero delegate registered by the constructor.

1. As owner it may call setPeer(30416, X) for any X; the next packet verified from X on eid 30416 passes lzReceive's peer check and _credit transfers any amount of locked ZTO to any recipient.
2. As delegate it may call EndpointV2.setReceiveLibrary / setConfig for the adapter and install a DVN set it controls, after which a forged packet from the real Robinhood peer verifies and releases custody with no change on the adapter at all.
3. As delegate it may call EndpointV2.clear / nilify / burn on a verified-but-unexecuted inbound packet, permanently stranding ZTO already burned on Robinhood.
4. As owner it may set a reverting msgInspector, which halts send() for everyone (a de facto pause despite the 'no pause' requirement; receives are unaffected). (5) renounceOwnership() removes setPeer/setDelegate forever while the endpoint-side delegate stays in force. None of this is reachable by an unprivileged actor; the README's 'Administrative trust' section covers peer and inspector powers but does not state that the delegate alone can replace the verification stack or drop packets. Mitigation is operational (hardware/multisig custody of the key, a two-step owner transfer), not a code change the brief allows.

Upstream asymmetry between the two ends of the mesh, reported for completeness because it strands value without a rescue path. OFT._credit maps address(0) to 0xdead before minting, but OFTAdapter._credit passes the decoded recipient straight to ZTO.transfer. The live ZTO at 0xd782...A68e is an OpenZeppelin-style ERC-20 (solc 0.8.26, 9 standard selectors, no fee or hook logic) whose transfer to address(0) reverts with ERC20InvalidReceiver.

A Robinhood user who sends with SendParam.to == bytes32(0) burns their tokens there, and the resulting inbound packet can never execute here: the endpoint keeps it as a verified payload, every retry reverts, and the matching ZTO stays locked in the adapter with no owner function able to release it.

Only the sender who chose a zero recipient is harmed, so this is informational; the fix, if wanted, is to mirror OFT's 0xdead redirect in a _credit override or to validate the recipient in a message inspector on the Robinhood side.

Area: Invariant (conservation: adapter custody == Robinhood OFT supply) and Flow Gap (execution x periphery x first principles). The home-side credit path transfers the unlocked amount straight to the decoded recipient. The live ZTO token at 0xd782bdea4ef02a0bd391eb9089470c8080f0a68e reverts on transfer to address(0) with its custom error InvalidReceiver(address) (selector 0x9cfea583; confirmed on a mainnet fork), and the vendored mock behaves the same (ERC20InvalidReceiver).

The upstream mint/burn OFT (src/vendor/@layerzerolabs/oft-evm/contracts/OFT.sol:86) handles this exact case by redirecting address(0) to 0xdead so the packet can always be executed; the adapter's _credit has no such handling.

Consequence: a Robinhood user who calls send with to = bytes32(0) burns their tokens on Robinhood, the LayerZero packet is verified and reaches the Ethereum endpoint, and every execution attempt reverts deterministically. The verified payload can only be cleared by the delegate via the endpoint, which marks it executed without calling lzReceive; the corresponding ZTO then sits in the adapter forever because the contract has no rescue function by requirement.

The bridge's conservation invariant (custody == remote supply) is therefore broken permanently by the stranded amount. Harm is to the sender who supplied a zero recipient, so severity is low; it is reported because the packet is wedged rather than rejected at source and because the upstream OFT treats the same input differently on the two ends of the mesh.

Fix options that preserve the agreed design: (a) mirror OFT.sol in ZTOAdapter by overriding _credit so a zero recipient releases to 0xdead (semantically a burn, keeps custody == supply); or (b) document that the Robinhood OFT front-end must reject to == bytes32(0). Option (a) is a two-line override in src/ZTOAdapter.sol and needs no vendor edit.

Area: Flow Gap (execution x periphery). lzReceive is payable because EndpointV2.lzReceive forwards msg.value from executor lzReceive options (gas, value). The adapter never uses msg.value, and the brief forbids any rescue function, so any value that arrives this way is locked forever.

Two ways value can arrive: a Robinhood sender adds an lzReceiveOption with value > 0 to extraOptions (self-harm, they paid for it in the source fee), or the Robinhood OFT owner sets enforced options with a non-zero value for the 30101 destination, in which case every inbound transfer strands a little ETH. README already instructs operators to use zero receive value; this is recorded so the author can decide whether to add a defensive check.

A minimal, design-preserving mitigation is to override _lzReceive in ZTOAdapter and revert when msg.value != 0, which converts the stranding into a retryable failure that surfaces the misconfiguration instead of silently accumulating unreachable ETH. No third party loses funds, so this is informational.

Area: Economic Security (break dependencies). Not a code defect; an observed live-chain state that the launch and pairing runbook must treat as mandatory.

A ZTOAdapter deployed on a mainnet fork (block 26131078, EVM cancun to execute the live PUSH0 bytecode) registered 0xcecc29b037f5064fcdf45a5c318f132ef76aa551 as delegate on EndpointV2 0x1a44076050125825900e736c501f859c50fE728c as required, but quoteSend for dstEid 30416 reverted with the endpoint string 'Please set your OApp's DVNs and/or Executor'.

The Ethereum endpoint has no default send config for the Robinhood eid, so no user can lock tokens and nothing is at risk, but the bridge is non-functional until the delegate sets send/receive libraries, DVNs, confirmations and executor for both directions (README step 4).

Because the failure is at quote time and reverts the whole send, there is no partial lock; this is recorded so the judge and author have the exact live symptom and do not read a 'Please set your OApp's DVNs' revert as an adapter bug.

Also confirmed live: ZTO has 18 decimals and totalSupply 1e27, so quoteOFT.maxAmountLD (1e27) is encodable in uint64 shared decimals (1e15 < 2^64), and ZTO transfer/transferFrom are lossless, return true, and do not decrement an infinite allowance, so the adapter's lossless-custody assumption holds for this token.