sIMD (StakedIMD) staking vault on Ethereum: risk review

• Swarm Queue code: SQ-29B183
• Subject: StakedIMD (sIMD), 0x9Efa934D9fAd4AE28c998a40195646b965a97247 on Ethereum mainnet, as listed in the project docs at pool4.imd.fun/docs (§11 "Parameters & trust")
• Research date: 9 October 2026. On-chain figures are as of block 26,156,494 (2026-10-09 17:57 UTC) unless another block is named.
• This is a desk review of public sources. It is not a security audit and not financial advice.

How to read this report

Every statement is tagged with how it is known.

Tag	Meaning
[F]	Fact I checked myself against a primary source: the verified contract source, a direct read of chain state, the event log, or the project's own docs page.
[S]	Reported by a secondary source (news, data aggregator). I did not verify it independently.
[I]	My inference from the facts. Reasoned, but not directly observed or tested unless it says so.
[U]	Unknown: not available or not determinable from the public sources I used.

On-chain reads were made with eth_call / eth_getLogs against public RPC endpoints. The linked Etherscan pages show the same data. The script tools/check_onchain.py in this repository re-runs the main reads.

1. Short answer

1. Nobody controls the vault any more. Ownership was renounced on 19 September 2026. The pause and rescue functions exist in the code but can no longer be called by anyone. They were never used before the renounce. [F]
2. The keys around the vault are still active. One externally owned account (EOA), the deployer 0x047F…54B7, still owns the IMD token contract, the reward dripper, the reward distributor and the market hook. It cannot take IMD out of the vault, but it can stop or redirect future rewards, and its powers over the IMD token and its market affect what staked IMD is worth. [F] for the ownership, [I] for the consequences.
3. The exchange rate is 7.9635 IMD per sIMD, but most of that number is not yield. It jumped from 1.0 to 7.667 in the first minutes after launch through a 20 IMD direct transfer into a vault that held 3 IMD. Since the rate settled on 2 September it has grown about 0.77% in 37 days. [F]
4. By amount, about 85% of the IMD added to the vault since launch as "yield" came from discretionary direct transfers by two EOAs, not from the programmatic reward stream. The programmatic stream has paid nothing since 2 October. [F]
5. Withdrawals are open, with no lock, fee or queue, subject only to a one-block hold after receiving shares. That hold can be used by a third party to block a specific staker's withdrawal for as long as the third party keeps paying gas. I reproduced this in a simulation. [F] for the simulation result.
6. The Permit2 allowance is not something the vault grants to itself. The sIMD share token hard-codes an infinite, non-revocable allowance for Uniswap's Permit2 contract over every holder's sIMD. The practical risk is signature phishing. [F] for the mechanism, [I] for the risk assessment.

2. Contracts in scope

Contract	Address	Owner now	Source
StakedIMD (sIMD vault)	0x9Efa…7247	none (zero address)	Etherscan code, Sourcify
RewardDripper	0xe6D3…0884	0x047F…54B7	Etherscan code, Sourcify
RewardDistributor	0x9046…CA30	0x047F…54B7	Etherscan code, Sourcify
CappedBurnHook (market)	0xc6C9…2840	0x047F…54B7	Etherscan code, Sourcify
IMD token (BridgedFP, LayerZero OFT)	0xD34a…63B7	0x047F…54B7	Etherscan code, Sourcify

• [F] The five addresses are the ones the docs page links under §11 (docs).
• [F] All five have source code verified on Sourcify with an exact match of creation and runtime bytecode. Sourcify reports each as not a proxy (vault record).
• [F] The vault's constructor arguments were the IMD token as asset and 0x047F…54B7 as first owner. The same account deployed all five contracts (vault creation tx, block 25,887,017, 2026-09-02 03:48 UTC).
• [F] 0x047F…54B7 has no contract code, so it is a single-key EOA and not a multisig or timelock contract (address page). The docs themselves say the hook owner "should be a multisig or a timelock" (docs §11).
• [S] Bankless attributes the project and the renounce transaction to a developer named Adam, previously lead developer of Fren Pet (Bankless, 25 Sep 2026).
• [U] Who holds the 0x047F…54B7 key, how it is stored, and whether more than one person can use it.

3. Control: who can pause or move funds

3.1 What the code allows an owner to do

The vault is a Solady ERC-4626 vault plus Solady Ownable. The source (src/StakedIMD.sol) gives the owner exactly these powers. [F]

Function	Effect	Limit in code
setPaused(bool)	While paused, every deposit, mint, withdraw and redeem reverts.	none
rescueERC20(token, to, amount)	Transfers any ERC-20 balance of the vault, explicitly including the staked IMD, to any address.	none: no cap, no delay, no restriction on token
rescueETH(to, amount)	Sends out ETH force-sent to the vault.	none
transferOwnership, completeOwnershipHandover	Hand the owner role to another address.	owner only
renounceOwnership()	Sets owner to the zero address.	reverts while paused

The contract's own header comment calls the rescue functions able to "sweep ANY balance, INCLUDING the staked IMD" and says the owner is "a trusted party" until ownership is renounced. The docs say the same (docs §11). [F]

There is no upgrade mechanism and no other privileged role in the vault source, and StakedIMD.sol contains no delegatecall or selfdestruct. [F]

3.2 Ownership is renounced

• [F] owner() returns the zero address (read contract).
• [F] The renounce is transaction 0x519fdbdd…1851, block 26,014,063, 2026-09-19 20:51 UTC. It was sent by 0x047F…54B7 with calldata 0x715018a6, the selector of renounceOwnership().
• [F] The vault has emitted exactly two OwnershipTransferred events: zero address to deployer at creation, and deployer to zero address at the renounce (events).
• [F] paused() is false. Because renouncing reverts while paused, and nobody can call setPaused now, the vault cannot become paused.
• [F] Calling setPaused, rescueERC20, rescueETH, transferOwnership and completeOwnershipHandover from the former owner address with eth_call all revert with 0x82b42900, which is Solady's Unauthorized().
• [F] There is no pending two-step handover for the deployer (ownershipHandoverExpiresAt is 0), and completing a handover requires the owner in any case (Solady Ownable).
• [S] Bankless and DropsTab both report the 19 September renounce (Bankless, DropsTab).
• [I] With the owner slot at zero and no other way to set it, the pause and rescue powers are gone for good. The vault is now an immutable contract with no administrator.

3.3 Were the powers used while they existed?

The owner held pause and rescue powers for about 17.7 days, from 2 to 19 September.

• [F] The vault's full event log (6,401 events from creation to block 26,156,494) contains no PauseSet and no EmergencyRescue event. Both functions emit their event unconditionally, so neither was ever called successfully.
• [F] Every transfer of IMD out of the vault (888 transfers, 1,125,243.40 IMD) matches a Withdraw event (888 events, 1,125,243.40 IMD).
• [F] The books balance: deposits 2,923,462.86 + dripper 1,756.98 + direct transfers 9,932.50 − withdrawals 1,125,243.40 = 1,809,908.94 IMD, which equals totalAssets().

3.4 Keys that remain active around the vault

All of the following are owned by the EOA 0x047F…54B7. [F] for each owner() read and each function, from the verified sources linked in section 2.

Contract	Owner-only functions that matter to stakers	What they cannot do
RewardDripper	setVault (send the stream elsewhere), setDripRate (zero is allowed), setMaxCatchup, setKeeperReward, setMinDripAmount, rescueERC20 (take the undripped buffer)	Touch IMD already inside the vault
RewardDistributor	setDripper (re-point the staking share), emergencyWithdraw (drain the whole balance)	Touch the vault
CappedBurnHook	setRewardsRecipient, setRewardShareBps (0 to 30%), cap and decay settings, closeMarket (withdraw the entire protocol-owned liquidity position), withdrawFees	Touch the vault
IMD token	setPeer, setDelegate (LayerZero OFT configuration), updateName, updateSymbol	Directly move or burn IMD held by the vault (no such function in the source)

• [I] The owner can reduce future staking rewards to zero at any time, either by re-pointing the stream or by setting the reward share or drip rate to zero. Rewards already in the vault are safe from this.
• [I] The IMD token is a standard LayerZero OFT: tokens arriving from a configured peer are minted on Ethereum (_credit calls _mint in the verified OFT.sol), and the owner chooses the peers with setPeer (LayerZero OFT docs). An owner who set a peer they control could therefore mint IMD on Ethereum. That would not remove IMD from the vault, but it would dilute what each IMD is worth. I did not test this and I have no evidence of intent. It is a capability of the key, and the key is a single EOA.
• [F] Peers are currently set for LayerZero endpoint IDs 30184 and 30110 (read contract, peers), which LayerZero lists as Base Mainnet and Arbitrum Mainnet (LayerZero deployed contracts). I probed only five endpoint IDs, so other peers may exist.
• [U] I did not review the peer contracts on other chains, the LayerZero security configuration (verifier set, delegate), or total IMD supply across chains. Bankless names Ethereum, Base and Robinhood Chain as the chains (Bankless); I did not reconcile that with the Arbitrum peer.

4. How the IMD-to-sIMD exchange rate grows

4.1 Mechanism

• [F] totalAssets() is simply the vault's IMD balance. There is no strategy, lending or external deployment of funds (Solady ERC4626, not overridden in StakedIMD.sol).
• [F] One sIMD converts to shares × (totalAssets + 1) / (totalSupply + 10^6) IMD, rounded down. The 10^6 is Solady's virtual-share protection with a decimals offset of 6. As a result sIMD has 24 decimals, not 18.
• [F] There is no reward token and no claim step. The rate rises whenever IMD arrives in the vault without new shares being minted. That happens in two ways: the RewardDripper transfers IMD in, or anyone sends IMD directly to the vault address.
• [I] Now that the rescue function is unreachable, IMD can only leave the vault through withdraw/redeem, which burn shares at the current rate with rounding in the vault's favour. So the rate cannot fall, barring an undiscovered bug. This is a statement about the IMD-per-sIMD rate only, not about the market price of IMD.

4.2 The programmatic reward path

Per the docs, when IMD is sold into the protocol-owned Uniswap v4 pool above its inventory cap, the excess is trimmed: 85% is burned and 15% goes to rewards, of which 30% (4.5% of the trim) is for stakers (docs §3, §5, §6).

Step	Contract	On-chain value now
Reward share of each trim	Hook rewardShareBps	1,500 (15%) [F]
Staking share of rewards	Distributor stakingBps	3,000 (30%) [F]
Stream rate cap	Dripper dripRatePerSecond	11,574,074,074,074,074 wei/s = 1,000 IMD/day [F]
Largest single drip	rate × maxCatchupSeconds (3,600 s)	41.67 IMD [F]
Keeper tip per drip	Dripper keeperReward	0.01 IMD [F]

• [F] drip() is permissionless, reverts if the vault has no shares, and forfeits idle time beyond one hour rather than banking it (RewardDripper.sol).
• [F] The docs page lists the drip rate as 86.4 IMD/day, the cap floor as 1,000 IMD and the cap decay as 1,000 IMD/day (docs §11). On chain they are 1,000 IMD/day, 9,000 IMD and 3,000 IMD/day. The docs label their table "Launch values; owner-tunable", so the table is out of date rather than contradicted.
• [I] At the current vault size, the 1,000 IMD/day ceiling caps the programmatic yield at about 20% a year (1,000 × 365 / 1,809,909). The stream has delivered far less than the ceiling.

4.3 What actually happened to the rate

[F] All figures below come from the vault's Deposit/Withdraw events and IMD Transfer events into the vault.

When (UTC)	Block	Rate (IMD per sIMD)	Event
2026-09-02 03:48	25,887,017	1.0000	First deposit, 1 IMD (tx)
2026-09-02, ~44 min later	25,887,236	7.6667	Deployer sends 20 IMD directly to the vault, which then held 3 IMD against 3 sIMD (tx)
2026-09-02 10:53	25,889,135	7.9029	First drips land while the vault is still very small
2026-09-19 20:51	26,014,063	7.9210	Ownership renounced
2026-10-09 17:57	26,156,494	7.9635	Latest read

• [F] From 7.9029 to 7.9635 is +0.77% in about 37.3 days.
• [I] That is roughly 7.5% a year as a simple annualisation. It is a backward-looking figure over a short window and predicts nothing.
• [I] A rate of 7.96 does not mean sIMD has earned 696%. Anyone who staked after the first hour entered at about 7.67 or higher.

Sources of the IMD that raised the rate since launch [F]:

Source	Transfers	IMD	Share by amount
RewardDripper (programmatic)	487	1,756.98	15.0%
Direct transfers from deployer 0x047F…54B7	8	7,461.50	63.8%
Direct transfers from EOA 0xe764…9095	2	2,471.00	21.1%

• [F] The largest direct transfers were 2,754 IMD (tx), 1,760.5 IMD (tx) and 1,471 IMD (tx).
• [U] Why these direct transfers were made, who controls 0xe764…9095, and whether they will continue. Nothing in any contract obliges anyone to make them.
• [F] The last drip was at 2026-10-02 04:37 UTC (tx). The dripper holds 0 IMD and the distributor holds only its bonding and node reserves, so nothing is queued for stakers.
• [F] The hook reports 6,938 IMD in the pool against an inventory cap of 9,000 IMD, which equals the cap floor (read contract).
• [I] With the pool below its cap and the cap at its floor, sells are not being trimmed, so no new staking rewards are generated until net selling pushes pool inventory back above 9,000 IMD. The docs describe this state: at the floor "the market behaves like a normal pool until a sell pushes inventory back above the floor" (docs §3). Bankless likewise notes that "yields depend on sell flow into the POOL4 hook" (Bankless).
• [F] The site's home and stake pages display "782,132% APR · launch rate", with a note that this is "not what stakers earn today" (stake page). The docs say the stake page should show a trailing seven-day APR once the full pool is deployed (docs §6).
• [I] The displayed APR has no relation to realised returns and should be ignored.

5. Withdrawal rules and mechanics

• [F] Withdrawal uses the standard ERC-4626 redeem(shares, receiver, owner) or withdraw(assets, receiver, owner) (EIP-4626). The project's stake page calls redeem (observed in the site's JavaScript bundle at pool4.imd.fun/stake).
• [F] There is no lock-up, no cooldown, no withdrawal fee, no queue and no per-user or global limit in the source. The docs say "No extra reward token, no claim, no lock" (docs §6).
• [F] The vault holds all staked IMD idle in its own balance, so every share is redeemable at once as far as IMD is concerned.
• [F] A third party can redeem on a holder's behalf only with a share allowance from that holder (or if the caller is Permit2, see section 6).
• [F] The only two conditions that block a withdrawal are the pause flag, which can no longer be set, and the one-block hold.

5.1 The one-block hold

• [F] _withdraw reverts with SameBlockRedeem if block.number == lastDepositBlock[owner]. maxWithdraw and maxRedeem return 0 in that block, so the Solady wrappers revert earlier with RedeemMoreThanMax / WithdrawMoreThanMax. The docs list it as "Unstake hold: 1 block" (docs §11).
• [F] lastDepositBlock is set to the current block when an address receives newly minted shares. On a share transfer, the recipient inherits the sender's stamp if it is more recent. Zero-amount transfers stamp nothing.
• [I] The purpose, per the code comments, is to stop a flash-loaned deposit, drip and redeem in one transaction.

5.2 Withdrawal griefing through the hold

The inheritance rule means an attacker who deposits in a block and then sends a dust amount of sIMD to a victim stamps the victim with the current block.

• [F] I simulated this against live state with eth_simulateV1 at block 26,156,507, using the largest holder as the victim: (1) attacker deposits 1 IMD, (2) attacker transfers 1 wei of sIMD to the victim, (3) the victim's maxRedeem drops from its full balance to 0, (4) the victim's redeem in that block reverts with 0x4656425a (RedeemMoreThanMax), (5) the same redeem in the next block succeeds. A control redeem without the attack succeeded.
• [I] Blocking a withdrawal for N blocks requires the attacker to land a deposit and a dust transfer ahead of the victim's transaction in each of the N blocks. That costs gas every block and needs reliable transaction ordering, so it is impractical for long periods but plausible for minutes, for example to delay a large holder's exit during a sharp price move. The attacker's deposited IMD is not lost.
• [I] The source comment says a third party "must not be able to stamp a hold on an account for free". The mitigation makes it cost a real deposit and gas, not impossible.
• [U] Whether this has ever been done on chain. I did not search for it.

5.3 Other withdrawal notes

• [I] You withdraw IMD, not ETH or dollars. Turning it into anything else depends on market liquidity (risk 3 below).
• [I] Because sIMD has 24 decimals, wallets or tools that assume 18 may show balances a million times too large. This is a display hazard, not a loss.
• [F] A different token with the ticker "SIMD" ("Super Intelligent Identity", 0xbB0c…3415) trades against IMD on Uniswap v4 (DexScreener pair). It is not the vault share. [U] I did not examine that token.

6. The Permit2 allowance

6.1 What it actually is

The task describes Permit2 as a mechanism "that sIMD uses to grant itself permissions". The source shows something different, and the difference matters.

• [F] sIMD's share token is Solady's ERC20. That contract contains a feature, on by default, that fixes the allowance of the canonical Uniswap Permit2 contract, 0x000000000022D473030F116dDEE9F6B43aC78BA3, at infinity for every holder. The switch is _givePermit2InfiniteAllowance(), which returns true (Solady ERC20). StakedIMD.sol does not override it.
• [F] On chain, allowance(holder, Permit2) returns 2^256 − 1 for an address that never approved anything (read contract).
• [F] A holder cannot lower it. approve(Permit2, 0) reverts with 0x3f68539a, Permit2AllowanceIsFixedAtInfinity(), confirmed by eth_call.
• [F] When Permit2 is the caller of transferFrom, the allowance check is skipped entirely. The same exemption applies in _spendAllowance, which the vault uses when someone other than the owner calls withdraw/redeem.
• [F] The vault does not use Permit2 to pull deposits. _deposit calls plain safeTransferFrom on IMD, so a staker must give the vault an ordinary IMD approval. The project's stake page asks for an approve of the exact amount being staked, then deposit (observed in the site's JavaScript bundle). The site references Permit2 only in its swap configuration, alongside the Uniswap Universal Router.
• [I] The IMD token is an OpenZeppelin ERC-20 without this feature, so the built-in allowance concerns sIMD shares only.

So the accurate description is: the sIMD token grants Permit2, a third-party contract, a permanent unlimited allowance over every holder's sIMD. The vault grants itself nothing.

6.2 Scope

In scope of the allowance	Out of scope
sIMD shares in any wallet or contract that holds them	IMD in a staker's wallet
	IMD held by the vault
	Any other token

• [F] Permit2 moves a user's tokens only when the user has authorised it inside Permit2: either a signed one-time transfer (SignatureTransfer) or an allowance to a named spender set by transaction or signature (AllowanceTransfer).
• [F] Uniswap's docs say Permit2 is open source and that third-party audit reports are published in its repository (Permit2 overview, source).
• [I] My understanding is that Permit2 is non-upgradeable and has no owner. I did not re-check its deployed bytecode for this report.
• [I] A sIMD holder who never signs a Permit2 message and never sets a Permit2-internal allowance for sIMD is not exposed through this path, assuming Permit2 itself has no flaw.
• [I] Permit2 only calls transferFrom on tokens. It has no function that would call the vault's redeem, so the _spendAllowance exemption is not reachable in practice.

6.3 Risks

1. Signature phishing. [I] For most tokens, a Permit2 phishing signature only works if the victim previously approved Permit2 for that token. For sIMD that precondition is always met. One off-chain signature, with no on-chain transaction from the victim, is enough to move the victim's whole sIMD balance. A second signature path exists as well: sIMD supports EIP-2612 permit (the vault exposes DOMAIN_SEPARATOR() and the InvalidPermit/PermitExpired errors [F]).
2. No opt-out. [F]/[I] The allowance cannot be revoked at the token level. Approval-revoking tools that work on token allowances cannot remove it. Allowances granted inside Permit2 to a spender must be revoked inside Permit2.
3. Dependency on Permit2. [I] Any flaw found in Permit2 would expose every holder's sIMD at once, with no way for holders or the now ownerless vault to switch the feature off. Permit2 is widely used and I am not aware of such a flaw, so I rate this as low probability.
4. Transfers through Permit2 carry the hold stamp. [I] A Permit2-routed transfer is an ordinary share transfer, so the one-block hold rules in section 5.1 apply to the recipient.

• [U] Whether any sIMD holders have live Permit2 allowances to third-party spenders, and whether sIMD has been phished this way. I did not scan Permit2's events.

7. Main risks for a staker, most serious first

The ordering is my judgement [I], weighing how much could be lost against how plausible the event is. The supporting facts are tagged individually.

Risk 1. Unaudited code that can no longer be paused, patched or rescued

• [F] The docs state: "The protocol is unaudited. A bug in the hook, the vault, the distributor, or the burn path can lose funds. Treat this as an experiment until it has been audited." (docs §12)
• [S] Bankless and DropsTab also describe it as unaudited (Bankless, DropsTab).
• [U] I found no audit report in my searches. That does not prove none exists.
• [F] The vault holds 1,809,908.95 IMD, which is 43.6% of the 4,153,707 IMD total supply on Ethereum (vault, IMD). At the roughly $8.86 price DexScreener showed on 9 October, that is about $16.0 million (DexScreener).
• [I] Renouncing removed the owner's ability to take funds, which was the largest risk before 19 September. It also removed the only emergency brake. If a flaw is found in the vault, nobody can pause it or move funds to safety. The vault code is small (about 170 lines on top of widely used Solady libraries), which lowers the chance of a flaw but does not replace an audit.
• [I] A loss here would be total and immediate, which is why I rank it first despite the modest code size.

Risk 2. A single active key controls the IMD token and the whole reward and market pipeline

• [F] One EOA owns the IMD token, the dripper, the distributor and the hook (section 3.4).
• [I] That key can stop staking rewards entirely, can withdraw the protocol-owned liquidity with closeMarket, and holds the token's cross-chain configuration, which in a LayerZero OFT amounts to authority over minting on Ethereum. Loss, theft or misuse of this one key could sharply reduce the value of every staked IMD without touching the vault.
• [F] The docs acknowledge the trust involved: "IMD is owner-operated" and holders "are trusting the owner not to use" the closeMarket escape hatch (docs §11).
• [I] The public message "ownership is renounced" is true of the vault only. Stakers who read it as "the system is trustless" would be mistaken.

Risk 3. Price and exit liquidity of IMD

• [F] DexScreener listed about $3.29 million of total liquidity across IMD's ETH and stablecoin pools on Ethereum on 9 October, the largest pool holding about $2.64 million. The protocol-owned POOL4 pool held about $0.21 million (largest pool, POOL4 pool). These are aggregator figures I did not recompute.
• [I] Staked IMD is worth about five times all listed DEX liquidity, and only about half of pool liquidity is the ETH or stablecoin side. The vault will always return IMD, but a large share of stakers could not sell at anything near the quoted price at the same time.
• [S] About 2.3 million IMD was staked on 25 September (Bankless). [F] It is 1.81 million now, so the vault has seen net outflows of roughly 0.5 million IMD in two weeks.
• [F] sIMD is concentrated: 546 holders, the top 10 holding 37.9% and the largest holding 8.4% (computed from the vault's Transfer events).
• [U] Liquidity on other chains and on centralised venues, and who owns the liquidity in the largest pool.

Risk 4. Yield is small, mostly discretionary and currently stalled

• [F] Realised growth since the rate settled is 0.77% in 37 days. About 85% of the IMD behind it came from voluntary direct transfers by two EOAs. The programmatic stream has paid nothing since 2 October (section 4.3).
• [I] A staker takes on risks 1 to 3 for a return that is low, depends on continued selling into one specific pool or on someone's goodwill, and can be switched off by the owner key. The headline rate of 7.96 and the "782,132% APR" label both overstate what stakers earn.

Risk 5. Permit2 and signature phishing on sIMD

• [F]/[I] Every sIMD holder has a permanent, non-revocable, unlimited Permit2 allowance, so a single malicious signature can take all of a holder's sIMD (section 6). This is a per-user risk that careful signing avoids, which is why it ranks below the systemic risks.

Risk 6. Withdrawal griefing through the one-block hold

• [F]/[I] A third party can delay a chosen staker's withdrawal block by block at its own gas cost (section 5.2). It delays; it does not take funds.

Risk 7. Stale or confusing public information

• [F] The docs still describe the vault owner's pause and sweep powers in the present tense and list launch parameters that differ from chain state. The stake page shows a placeholder APR. A separate token uses the "SIMD" ticker (sections 4.2, 4.3, 5.3).
• [I] None of this loses funds by itself, but it makes it easy to misjudge the product or buy the wrong token.

8. What could not be determined

Question	Status
Identity and key management of the owner EOA 0x047F…54B7	[U] Only a secondary-source attribution to "Adam" exists.
Whether any audit exists	[U] The project says unaudited; I found no report.
Whether a public source repository and test suite exist	[U] I found none. Verified source on Etherscan and Sourcify is the only code I reviewed.
Correctness of the vault and Solady code beyond reading it	[U] I read the vault and dripper in full and the relevant Solady sections. I ran no fuzzing or formal analysis.
Depth review of CappedBurnHook (about 68 KB of source) and BurnExecutor	[U] I read only the owner-only functions and state.
IMD contracts and supply on Base and other chains; LayerZero verifier and delegate settings	[U] Not reviewed. Secondary sources put all-chain supply near 7.1 million.
Whether the IMD owner could in practice mint through a new peer	[I] Follows from the standard OFT design; not tested.
Purpose and future of the direct IMD transfers into the vault	[U]
Whether hold-griefing or Permit2 phishing has occurred against sIMD holders	[U] Not searched.
Accuracy of DexScreener price and liquidity figures	[U] Taken as reported.
Legal, tax and regulatory position	Out of scope.

9. Sources

Primary:

• POOL4 docs: https://pool4.imd.fun/docs; stake page: https://pool4.imd.fun/stake
• StakedIMD: https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247 ; verified source https://repo.sourcify.dev/1/0x9Efa934D9fAd4AE28c998a40195646b965a97247
• Renounce transaction: https://etherscan.io/tx/0x519fdbdd5b504476efe91f31a20b4091aeb15cb7caed51071151d3ee87b81851
• RewardDripper: https://etherscan.io/address/0xe6D3De6daEAf327fCA42745f1998FcD989e00884
• RewardDistributor: https://etherscan.io/address/0x9046739E1535B40EfBe6AB3f45d0024b690eCA30
• CappedBurnHook: https://etherscan.io/address/0xc6c965bd164c483e87d0b550671798e9a3602840
• IMD token: https://etherscan.io/address/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7
• Owner EOA: https://etherscan.io/address/0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7
• Solady ERC20, ERC4626, Ownable: https://github.com/Vectorized/solady/blob/main/src/tokens/ERC20.sol, https://github.com/Vectorized/solady/blob/main/src/tokens/ERC4626.sol, https://github.com/Vectorized/solady/blob/main/src/auth/Ownable.sol. The copies compiled into the vault are in the verified source; the upstream main files may have changed since.
• Permit2: https://docs.uniswap.org/contracts/permit2/overview, https://github.com/Uniswap/permit2
• EIP-4626: https://eips.ethereum.org/EIPS/eip-4626
• LayerZero OFT: https://docs.layerzero.network/v2/developers/evm/oft/quickstart; endpoint IDs: https://docs.layerzero.network/v2/deployments/deployed-contracts

Secondary:

• Bankless, "Inside IMD: Ethereum's New AI Swarm Experiment", William M. Peaster, 25 September 2026: https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment
• DropsTab, Identity.md (IMD): https://dropstab.com/coins/Identity-imd
• DexScreener, IMD pairs on Ethereum: https://dexscreener.com/ethereum/0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3