SMART CONTRACT SECURITY AUDIT: IMDSTR (Identity.MD Strategy) on Ethereum mainnet and Robinhood Chain

TARGET

• IMDSTR on Ethereum mainnet: token and strategy 0x0000198C940D8cD70Cb9ACeC5E3af8216ac57d2F, a UUPS proxy; implementation IMDSeatStrategy 0x16d3f65b708883df042d98e1c7a49b32a33e2a14 (Solidity 0.8.30, source verified on Etherscan). It is a fork of TokenWorks' NFTStrategy: an ERC-20 traded on a Uniswap v4 pool whose hook takes a fee on every trade. 87% of the fee fills a pot that can only buy identity.md NFTs (0x0000eC93127BAA929E58E97dd0095A2BFb38ec1D); bought NFTs are relisted at a multiple and the sale proceeds buy back and burn IMDSTR.
• The rest of the system on Ethereum: hook NFTStrategyHook 0xA16026A28aA581AA96713d20C608Da7F8db86444 (fee split 87% pot / 10% $IMD buy-and-burn / 3% fee address); launcher SingleNFTStrategyLauncher 0x1216eDc56A93CC8f7bE67E1cBaD264AB2803FCff ($IMD buy-and-burn TWAP to IMD's BurnExecutor 0xe29386719C155B6847aD5a4E97C6674f10ffc750, relist multiplier, Robinhood reserve); LayerZero V2 bridge IMDSTRAdapter 0x6BDca0523530D4B1Cc2e7e6043ce4c5adfC56C51 (locks IMDSTR, burns 1% of every bridge). Owner of all three: TimelockController 0xBd3ed9F4AbD9946cA6F59C8F13A3EbebDE1EA29D (48h delay). Uniswap v4 PoolManager 0x000000000004444c5dc75cB358380D2e3dE08A90.
• Robinhood Chain (chain id 4663, explorer robin.etherscan.io, RPC https://rpc.mainnet.chain.robinhood.com): IMDSTRRobinhood 0x0000198C940D8cD70Cb9ACeC5E3af8216ac57d2F (same address; a LayerZero V2 OFT, not a proxy, peer of the Ethereum adapter); RobinhoodStrategyHook 0x50c1927c08340b1BbC3fD3C448eEe9aaa937e444; RobinhoodLauncher 0xfdA3fB00662011287AFc6d0c958AC73D8e7Cae62 (bridges the pot share of fees to the Ethereum pot); owner and LayerZero delegate: TimelockController 0x16D3f65B708883DF042d98E1C7a49B32A33E2A14 (48h delay). PoolManager 0x8366a39CC670B4001A1121B8F6A443A643e40951. All sources verified on robin.etherscan.io.
• 0x16d3...2a14 is the strategy implementation on Ethereum and, at the same address, the timelock on Robinhood Chain (same deployer nonce on both chains). Do not mix them up.
• Deployer EOA 0x35da9c0303507ddf708e87f2568eddf12c47a059: the hook's 3% fee address, the seat operator (authorizeWorker / registerAgent for IMD seats) and the only proposer, executor and canceller on both timelocks.
• For comparison, TokenWorks' original: NFTStrategy implementation 0x31e9De22a08bafA9a8E292087bE9dace2E6442a2, hook 0x8fb66C6E0f3cbb25001e0f1C0352Cc888cFF6444.

GOAL

A professional security audit of IMDSTR on both chains, with a clear answer to the holder's question: what can go wrong with my IMDSTR, and what can the owner and the deployer key do to it.

WHAT TO DELIVER

1. Architecture summary: inheritance, roles, every privileged function on every contract above, who can call it now (read on-chain state: owners, timelock roles, delay and pending operations, the UUPS implementation slot, distributor allowlist, seat operator, hook fee address and fee, LayerZero peers per endpoint ID, delegate, enforced options, send/receive libraries, DVN configuration from the LayerZero endpoint).
2. Fund flows: trace the trade fee on both chains. Can the NFT pot be spent on anything other than identity.md NFTs (buyTargetNFT, getMaxPriceForBuy)? Can a relisted NFT be taken or sold below its multiple? Does the $IMD share only reach the BurnExecutor? Does the Robinhood pot share only reach the Ethereum pot?
3. Supply integrity: can IMDSTR be minted on Robinhood Chain without IMDSTR locked in the Ethereum adapter? Consider setPeer to an attacker contract, DVN/library changes and delegate powers, and compare IMDSTR totalSupply on Robinhood Chain with IMDSTR locked in the adapter at the same time, allowing for the 1% bridge burn and messages in flight.
4. Hook and pool: can anyone trade IMDSTR without paying the fee (other pools, routers, the distributor allowlist, direct PoolManager calls)? Can the fee be raised? Any reentrancy or accounting issue in the hook callbacks.
5. Owner risk: list every action the timelocks, the deployer EOA and the seat operator can take that affects holders, with impact and whether it is instant or behind the 48h delay, including UUPS upgrades and seat-operator signatures through ERC-1271 isValidSignature. Note the single-key risk.
6. Code review findings: standard pitfalls for NFTStrategy forks, Uniswap v4 hooks and LayerZero OFTs (shared decimals and dust, rate limits, compose message handling, reentrancy, approval behaviour, rounding in fee math, missing events), and anything specific to this implementation, especially where it differs from TokenWorks' original.
7. For each finding: severity, location (file and line in the verified source), description, exploit scenario, recommendation.
8. 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).