SMART CONTRACT SECURITY AUDIT: the $IMD token on Ethereum mainnet

TARGET

• $IMD on Ethereum mainnet: 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 (contract name BridgedFP, Solidity 0.8.26, source verified on Etherscan and Blockscout). It is a LayerZero V2 OFT: IMD on Ethereum is minted when FP is locked in the adapter on Base and burned when bridged back.
• Related contracts for context: FP token on Base 0xFF0C532FDB8Cd566Ae169C1CB157ff2Bdc83E105; FrenPetOFTAdapter on Base 0xab152db8aac047b6757ffcf495ffe88d7712690a; owner of the IMD contract 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7 (an EOA).

GOAL

A professional security audit of the IMD token contract, with a clear answer to the holder's question: what can go wrong with my IMD, and what can the owner do to it.

WHAT TO DELIVER

1. Architecture summary: inheritance, roles, every privileged function, who can call it now (read on-chain state: owner, peers per endpoint ID, delegate, enforced options, send/receive libraries, DVN configuration from the LayerZero endpoint).
2. Supply integrity: can IMD be minted on Ethereum without FP being locked on Base? Consider setPeer to an attacker contract, DVN/library changes, delegate powers, and compare IMD totalSupply on Ethereum with FP locked in the Base adapter at the same block.
3. Owner risk: list every action the owner EOA can take that affects holders, with impact and whether it is instant or time-locked. Note the single-EOA key risk.
4. Code review findings: standard OFT pitfalls (shared decimals and dust, rate limits, compose message handling, reentrancy, approval behaviour, missing events), and anything specific to this implementation.
5. For each finding: severity, location (file and line in the verified source), description, exploit scenario, recommendation.
6. A short plain-language summary for non-developers at the top.

Read-only: use public RPCs and explorers, no transactions. If a public RPC rate-limits you, say which data you could not fetch.

RULES OF ENGAGEMENT (mandatory)

• Read-only, black-box testing of public surfaces only. No load testing, no fuzzing at volume (max 1 request per second, max 300 requests total), no attempts to access other users' data, no credential guessing, no transactions, no payments, no signatures.
• Do not publish anything. Findings go only into the output files of this job.
• Every finding must be reproducible: exact URL or call, input, observed result, expected result, timestamp (UTC). If you cannot reproduce it, it does not go into the report.
• Severity: critical / high / medium / low / info, with one sentence on real-world impact.
• Clearly separate VERIFIED (you observed it) from SUSPECTED (reasoning only).