# sIMD (StakedIMD) staking vault on Ethereum: risk review - Swarm Queue code: SQ-29B183 - Subject: `StakedIMD` (sIMD), [`0x9Efa934D9fAd4AE28c998a40195646b965a97247`](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247) on Ethereum mainnet, as listed in the project docs at [pool4.imd.fun/docs](https://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`](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247) | none (zero address) | [Etherscan code](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247#code), [Sourcify](https://repo.sourcify.dev/1/0x9Efa934D9fAd4AE28c998a40195646b965a97247) | | RewardDripper | [`0xe6D3…0884`](https://etherscan.io/address/0xe6D3De6daEAf327fCA42745f1998FcD989e00884) | `0x047F…54B7` | [Etherscan code](https://etherscan.io/address/0xe6D3De6daEAf327fCA42745f1998FcD989e00884#code), [Sourcify](https://repo.sourcify.dev/1/0xe6D3De6daEAf327fCA42745f1998FcD989e00884) | | RewardDistributor | [`0x9046…CA30`](https://etherscan.io/address/0x9046739E1535B40EfBe6AB3f45d0024b690eCA30) | `0x047F…54B7` | [Etherscan code](https://etherscan.io/address/0x9046739E1535B40EfBe6AB3f45d0024b690eCA30#code), [Sourcify](https://repo.sourcify.dev/1/0x9046739E1535B40EfBe6AB3f45d0024b690eCA30) | | CappedBurnHook (market) | [`0xc6C9…2840`](https://etherscan.io/address/0xc6c965bd164c483e87d0b550671798e9a3602840) | `0x047F…54B7` | [Etherscan code](https://etherscan.io/address/0xc6c965bd164c483e87d0b550671798e9a3602840#code), [Sourcify](https://repo.sourcify.dev/1/0xc6C965Bd164c483e87d0B550671798e9A3602840) | | IMD token (`BridgedFP`, LayerZero OFT) | [`0xD34a…63B7`](https://etherscan.io/address/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7) | `0x047F…54B7` | [Etherscan code](https://etherscan.io/address/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7#code), [Sourcify](https://repo.sourcify.dev/1/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7) | - **[F]** The five addresses are the ones the docs page links under §11 ([docs](https://pool4.imd.fun/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](https://sourcify.dev/server/v2/contract/1/0x9Efa934D9fAd4AE28c998a40195646b965a97247?fields=all)). - **[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](https://etherscan.io/tx/0x091a1fc3d622891e091e3581dd1d5cf092be50d9458a36e5debbe834884c8c82), 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](https://etherscan.io/address/0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7)). The docs themselves say the hook owner "should be a multisig or a timelock" ([docs §11](https://pool4.imd.fun/docs)). - **[S]** Bankless attributes the project and the renounce transaction to a developer named Adam, previously lead developer of Fren Pet ([Bankless, 25 Sep 2026](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment)). - **[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](https://github.com/Vectorized/solady) ERC-4626 vault plus Solady `Ownable`. The source ([`src/StakedIMD.sol`](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247#code)) 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](https://pool4.imd.fun/docs)). **[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](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247#readContract)). - **[F]** The renounce is transaction [`0x519fdbdd…1851`](https://etherscan.io/tx/0x519fdbdd5b504476efe91f31a20b4091aeb15cb7caed51071151d3ee87b81851), 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](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247#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](https://github.com/Vectorized/solady/blob/main/src/auth/Ownable.sol)). - **[S]** Bankless and DropsTab both report the 19 September renounce ([Bankless](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment), [DropsTab](https://dropstab.com/coins/Identity-imd)). - **[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`](https://etherscan.io/address/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7#code)), and the owner chooses the peers with `setPeer` ([LayerZero OFT docs](https://docs.layerzero.network/v2/developers/evm/oft/quickstart)). 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`](https://etherscan.io/address/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7#readContract)), which LayerZero lists as Base Mainnet and Arbitrum Mainnet ([LayerZero deployed contracts](https://docs.layerzero.network/v2/deployments/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](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment)); 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](https://github.com/Vectorized/solady/blob/main/src/tokens/ERC4626.sol), 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](https://pool4.imd.fun/docs)). | 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`](https://etherscan.io/address/0xe6D3De6daEAf327fCA42745f1998FcD989e00884#code)). - **[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](https://pool4.imd.fun/docs)). 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](https://etherscan.io/tx/0xf1a98e8d03fe6fe77cf133a9337b609ff9b501fc1b88fac02c3a687ddde6f98b)) | | 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](https://etherscan.io/tx/0xf95308be32b779cb72002d63fd78347904f6fe6b48d8c903526683fa6e1c4c09)) | | 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`](https://etherscan.io/address/0xe764da9bdea91d845aac2c7d53a8dfe59a369095) | 2 | 2,471.00 | 21.1% | - **[F]** The largest direct transfers were 2,754 IMD ([tx](https://etherscan.io/tx/0x435a84616bc997ffc0621aa8f320d000c283f09385ba75a6aa9f57e3e6c372ee)), 1,760.5 IMD ([tx](https://etherscan.io/tx/0x8a7625b94d9fa4548601684277f488c96347bdca68ddab90a361a63fb6094ea1)) and 1,471 IMD ([tx](https://etherscan.io/tx/0x04c1afa947092885657709a70c63aeabf07b885c3ae12106dabcf4fb3d6aa2dd)). - **[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](https://etherscan.io/tx/0xe4b1e5fe9c4669fb0a4795054dd418e7eb4a964a52eb6e8661ceb2970b9db16e)). 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](https://etherscan.io/address/0xc6c965bd164c483e87d0b550671798e9a3602840#readContract)). - **[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](https://pool4.imd.fun/docs)). Bankless likewise notes that "yields depend on sell flow into the POOL4 hook" ([Bankless](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment)). - **[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](https://pool4.imd.fun/stake)). The docs say the stake page should show a trailing seven-day APR once the full pool is deployed ([docs §6](https://pool4.imd.fun/docs)). - **[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](https://eips.ethereum.org/EIPS/eip-4626)). The project's stake page calls `redeem` (observed in the site's JavaScript bundle at [pool4.imd.fun/stake](https://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](https://pool4.imd.fun/docs)). - **[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](https://pool4.imd.fun/docs)). - **[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`](https://etherscan.io/address/0xbB0c1F82A2ea0253ea3D91c2f05cADed82133415)) trades against IMD on Uniswap v4 ([DexScreener pair](https://dexscreener.com/ethereum/0x99de115f6fcf3a505e94a16175fbb34a304425f9a72a2e091c60fb723dc39a4e)). 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`](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3), at infinity for every holder. The switch is `_givePermit2InfiniteAllowance()`, which returns `true` ([Solady ERC20](https://github.com/Vectorized/solady/blob/main/src/tokens/ERC20.sol)). `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](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247#readContract)). - **[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](https://docs.uniswap.org/contracts/permit2/reference/signature-transfer)) or an allowance to a named spender set by transaction or signature ([AllowanceTransfer](https://docs.uniswap.org/contracts/permit2/reference/allowance-transfer)). - **[F]** Uniswap's docs say Permit2 is open source and that third-party audit reports are published in its repository ([Permit2 overview](https://docs.uniswap.org/contracts/permit2/overview), [source](https://github.com/Uniswap/permit2)). - **[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](https://pool4.imd.fun/docs)) - **[S]** Bankless and DropsTab also describe it as unaudited ([Bankless](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment), [DropsTab](https://dropstab.com/coins/Identity-imd)). - **[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](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247#readContract), [IMD](https://etherscan.io/address/0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7#readContract)). At the roughly $8.86 price DexScreener showed on 9 October, that is about $16.0 million ([DexScreener](https://dexscreener.com/ethereum/0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3)). - **[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](https://pool4.imd.fun/docs)). - **[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](https://dexscreener.com/ethereum/0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3), [POOL4 pool](https://dexscreener.com/ethereum/0x415829f72e9f54531c26eae76f107618540e898a45d6ae35959e143f5faca704)). 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](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment)). **[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: ; stake page: - StakedIMD: ; verified source - Renounce transaction: - RewardDripper: - RewardDistributor: - CappedBurnHook: - IMD token: - Owner EOA: - Solady ERC20, ERC4626, Ownable: , , . The copies compiled into the vault are in the verified source; the upstream `main` files may have changed since. - Permit2: , - EIP-4626: - LayerZero OFT: ; endpoint IDs: Secondary: - Bankless, "Inside IMD: Ethereum's New AI Swarm Experiment", William M. Peaster, 25 September 2026: - DropsTab, Identity.md (IMD): - DexScreener, IMD pairs on Ethereum: