# Oracle riddle: does renouncing sIMD ownership make staker rewards trustless?

*Research report for `[SIMD-CONTEST:oracle-riddle]`. Researched 2026-10-06. On-chain figures come from Ethereum mainnet **block 26136384** (hash `0xdd2ffe85451f44afeed07e0d003f1e745fdd0d0c870f7f7bff6e47cc8985824e`, 2026-10-06T22:40:11Z) unless another block is named. You can reproduce them with `scripts/simd_wiring_check.py <rpc> 26136384`. I did not submit an IdentityMD oracle request, so this report contains no oracle attestation.*

Labels used below:
**[F]** fact I checked directly against a primary source (chain state, verified source code, or the operator's own docs).
**[R]** something a secondary source reports that I could not check independently.
**[I]** my inference from the facts.
**[?]** an open question.

---

## 1. The question (one sentence)

> After the StakedIMD (sIMD) vault's owner renounced ownership on 2026-09-19, can any single key still cut, redirect, or reprice the IMD that flows **into** the sIMD vault from POOL4's CappedBurnHook (the advertised "4.5% to stakers")? If so, which key, and through which functions?

Why the question is hard: press coverage presents the renunciation as the end of admin risk. The KuCoin piece says it removed "administrative emergency-withdrawal risk", and Bankless says it prevents "any emergency withdrawals by administrators". The reward stream, however, passes through three other contracts before it reaches the vault. An oracle answer to this question cannot come from a single view call. It needs four things together: source-code semantics, current storage, the identity of each owner, and the full event history.

## 2. What evidence would make an answer trustworthy

| # | Evidence | Why it matters | Status in this report |
|---|---|---|---|
| E1 | Canonical contract addresses for the vault, dripper, distributor, hook and burn sink, taken from an operator source | Prevents answering about the wrong contracts | **Partial.** The addresses come from the operator's front-end bundle at `pool4.imd.fun` (module exporting `STAKING`, `DRIPPER`, `DISTRIBUTOR`, `HOOK`, `BURN_EXECUTOR`). They do not come from a signed registry or the docs. |
| E2 | Verified source code with an **exact** bytecode match (creation and runtime) | Shows which admin functions exist. Without it, `owner() == 0` means little. | **Done.** All five contracts are `exact_match` on Sourcify (§4.1). |
| E3 | Current storage read at a pinned block: `owner()`, routing pointers, split parameters | Shows who holds those powers right now | **Done** (block 26136384) |
| E4 | Owner account type (EOA, multisig or timelock) | A timelock or multisig would change the risk materially | **Done.** Plain EOA with no code (§4.2). |
| E5 | Full admin-event history (`OwnershipTransferred`, `RewardsRecipientUpdated`, `RewardShareUpdated`, `DripperUpdated`, `VaultSet`, `DripRateSet`) | Shows whether the powers have ever been used | **Partial.** Complete for vault, dripper and distributor. Incomplete for the hook (§6). |
| E6 | Reconciliation of flows: distributor accounting vs dripper events vs vault balance | Checks that the routing actually works as the code describes | **Done** (§4.4) |
| E7 | Independent reproduction by a second reader or RPC provider | Guards against a single faulty RPC response or analyst error | **Not done.** One analyst, two public RPCs plus the Blockscout indexer. |

## 3. What an IdentityMD oracle attestation would and would not prove

The IdentityMD oracle signs EIP-712 `OracleAttestation` messages under domain `{name: "IdentityMD Oracle", version: "2", …}`. The signed fields are `questionHash`, `answer`, `fromBlock`/`toBlock`/`blockHash`, `panelSize`, `quorum` and `agreed` ([imd.fun/docs](https://imd.fun/docs/)) **[F]**. The public API reports a single attester key, `0x5598aa9146215bc13eb26f2c692ad1461fd32982` ([api.imd.fun/oracle/requests](https://api.imd.fun/oracle/requests?limit=1)) **[F]**. With `evidence: "chain"`, panel members submit a *recipe* and "the deployer reruns the agreed recipe at the pinned blocks before it signs". The recipe types are `log-sum`, `log-count`, `log-rank`, `call-compare` ("one view call at the closing block against a threshold"), `v4-volume-rank` and `univ4-spot` **[F]**.

**An attestation would prove:**
- The attester key signed this exact `answer` for this exact `questionHash`, chain, and block window/`blockHash`.
- `agreed` out of `panelSize` seated members gave that answer, as the operator reports it.
- For a `chain` recipe, the deployer's rerun of one mechanical query produced the value. For example: `call-compare` on `CappedBurnHook.owner()` at the closing block, or `log-count` of `RewardsRecipientUpdated` over a window.

**An attestation would not prove:**
- **Code semantics.** No chain recipe reads source code. "Can anyone redirect rewards?" depends on which `onlyOwner` functions exist. That is panel judgement (`evidence: "panel"`), not reproducible chain evidence. The oracle's own history includes a source-review question of this kind that ended `disagreed` (request `60b8c7ac-…`, 2026-10-05) **[F]**.
- **Anything after `toBlock`.** The owner can call `setRewardsRecipient` one block later. A "true at block N" answer says nothing about block N+1.
- **Independence of the signer.** One key signs. The panel's agreement is reported by the operator and is not verified on-chain by the consumer. A consumer can only check `panelSize`/`agreed` against what it chooses to trust.
- **Address canonicality.** If the question names the wrong hook address, the oracle will correctly answer the wrong question.
- **Off-chain intent.** For example, whether the 6% "bonding" bucket is really earmarked for orchestrator compute (§5).

**Implication [I]:** the best oracle-attestable sub-claims are narrow and mechanical:
- `CappedBurnHook(0xc6c9…2840).owner() != 0x0` at block N (call-compare).
- `log-count(RewardsRecipientUpdated)` on the hook from its deploy block to N equals 0.

The headline question still needs the source-level analysis in §4.3, which an attestation cannot carry.

## 4. Evidence and findings

### 4.1 Contracts in the reward path (all **[F]**)

| Role (front-end name) | Address | Verified source | Deploy tx (block) |
|---|---|---|---|
| IMD token | `0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7` | n/a (not examined) | n/a |
| sIMD vault (`STAKING`) | [`0x9efa934d9fad4ae28c998a40195646b965a97247`](https://etherscan.io/address/0x9efa934d9fad4ae28c998a40195646b965a97247) | `src/StakedIMD.sol:StakedIMD`, [Sourcify exact match](https://repo.sourcify.dev/1/0x9efa934d9fad4ae28c998a40195646b965a97247) | `0x091a1fc3…8c82` (25887017) |
| `DRIPPER` | [`0xe6D3De6daEAf327fCA42745f1998FcD989e00884`](https://etherscan.io/address/0xe6D3De6daEAf327fCA42745f1998FcD989e00884) | `src/RewardDripper.sol:RewardDripper`, [Sourcify exact match](https://repo.sourcify.dev/1/0xe6D3De6daEAf327fCA42745f1998FcD989e00884) | `0x57cde315…3232` (25887025) |
| `DISTRIBUTOR` | [`0x9046739E1535B40EfBe6AB3f45d0024b690eCA30`](https://etherscan.io/address/0x9046739E1535B40EfBe6AB3f45d0024b690eCA30) | `src/RewardDistributor.sol:RewardDistributor`, [Sourcify exact match](https://repo.sourcify.dev/1/0x9046739E1535B40EfBe6AB3f45d0024b690eCA30) | `0xd441ccef…15e8` (25887045) |
| `HOOK` (POOL4) | [`0xc6c965bd164c483e87d0b550671798e9a3602840`](https://etherscan.io/address/0xc6c965bd164c483e87d0b550671798e9a3602840) | `src/CappedBurnHook.sol:CappedBurnHook`, [Sourcify exact match](https://repo.sourcify.dev/1/0xc6c965bd164c483e87d0b550671798e9a3602840) | `0x6f9d804f…db52b` (25887052) |
| `BURN_EXECUTOR` (burn sink) | [`0xe29386719C155B6847aD5a4E97C6674f10ffc750`](https://etherscan.io/address/0xe29386719C155B6847aD5a4E97C6674f10ffc750) | `src/BurnExecutor.sol:BurnExecutor`, [Sourcify exact match](https://repo.sourcify.dev/1/0xe29386719C155B6847aD5a4E97C6674f10ffc750) | `0x85b1cdf9…7303` (25793167) |

Sourcify records the same deployer, `0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7`, for all five. The sIMD `asset()` is the IMD token. Sourcify reports none of the five as a proxy, and the verified sources contain no proxy pattern **[F]**.

### 4.2 Who owns what, at block 26136384 **[F]**

| Contract | `owner()` | Relevant live config |
|---|---|---|
| sIMD vault | `0x0000…0000` (renounced) | `paused = false`, `totalAssets = 1,759,133.16 IMD` |
| RewardDripper | `0x047F…54B7` | `vault = sIMD`, `dripRatePerSecond = 0.011574… IMD` (= 1,000 IMD/day), `maxCatchupSeconds = 3600`, `keeperReward = 0.01`, `minDripAmount = 1`, IMD balance 0, `lastDripAt` 2026-10-02T04:37:47Z |
| RewardDistributor | `0x047F…54B7` | `dripper = RewardDripper`, `stakingBps/bondingBps/nftBps = 3000/4000/3000` |
| CappedBurnHook | `0x047F…54B7` | `rewardsRecipient = RewardDistributor`, `rewardShareBps = 1500`, `burnSink = BurnExecutor` |
| BurnExecutor | `0x047F…54B7` | n/a |

`0x047F…54B7` has **no contract code** at this block, so it is an EOA rather than a Safe or timelock. Its nonce at the time of the check was 2689 **[F]**.

The renunciation itself: tx [`0x519fdbdd5b504476efe91f31a20b4091aeb15cb7caed51071151d3ee87b81851`](https://etherscan.io/tx/0x519fdbdd5b504476efe91f31a20b4091aeb15cb7caed51071151d3ee87b81851), block 26014063, **2026-09-19T20:51:47Z**. It was sent from `0x047F…54B7` to the vault with calldata `0x715018a6` (`renounceOwnership()`) and emitted `OwnershipTransferred(0x047F…54B7 → 0x0)` **[F]**. This matches the Bankless date **[R→F]**.

**Split arithmetic [F, from live config]:** the hook sends 15% of each trim to the distributor and 85% to the burn sink. The distributor gives 30% of that 15% to staking (**4.5%**), 40% to bonding (**6%**) and 30% to NFT (**4.5%**). This matches the advertised 85 / 6 / 4.5 / 4.5 split. One difference: the advertised split calls the 6% bucket "orchestrator compute", while the on-chain bucket is named `bonding` (see §5).

### 4.3 Owner powers that touch the sIMD inflow (from verified source) **[F]**

**CappedBurnHook** (owner `0x047F…`):
- `setRewardsRecipient(address)` sends future reward shares to **any non-zero address**. The source says accrued `rewardClaims` "settle to whatever `rewardsRecipient` is at settlement time", so a change before `settleClaims()` also redirects claims that have accrued but not yet settled.
- `setRewardShareBps(uint256)` sets the reward share anywhere from 0 to `MAX_REWARD_SHARE_BPS = 3000`. Setting it to 0 sends nothing to stakers. The cap also means the owner cannot route more than 30% of a trim to rewards.
- `closeMarket(address recipient)` lets the owner "withdraw the entire position at any moment, including from a healthy market. Holders are trusting the owner not to" (NatSpec, quoted verbatim). With no market, nothing gets trimmed and no rewards are produced.
- `setBurnSink`, `setCapDecay`, `setCapFloor`, `setRatchetBps` and related setters change how much gets trimmed in the first place.

**RewardDistributor** (owner `0x047F…`):
- `setDripper(address)` sends the 30% staking bucket to any non-zero address.
- `emergencyWithdraw(address)` drains the distributor's entire IMD balance. This includes the 4,110.97 IMD of bonding and NFT buckets currently held there. The staking share leaves on each `distribute()`, so only the undistributed amount is exposed.

**RewardDripper** (owner `0x047F…`):
- `setVault(address)` points the stream at any non-zero address.
- `setDripRate(0)` halts the stream. `setDripRate` accepts values up to `type(uint128).max`, so the anti-JIT smoothing promised in the NatSpec can be removed.
- `rescueERC20` sweeps the reward buffer.

**StakedIMD vault** (owner `0x0`):
- `setPaused`, `rescueERC20` and `rescueETH` are `onlyOwner` and can no longer be called. The NatSpec says renouncing "drops both powers permanently and leaves an immutable, trustless ERC4626".

### 4.4 Flow reconciliation **[F]**

- Distributor `stakingEarned` = **1,761.8453 IMD** (lifetime).
- Blockscout lists **487 `Dripped` events** from the dripper between blocks 25888622 and 26102297, with `toVault` summing to **1,756.9753 IMD**. Adding the 487 × 0.01 IMD keeper rewards gives 1,761.8453, which is exactly `stakingEarned`. This full-history log scan was complete.
- The dripper's admin events since deploy are: one `OwnershipTransferred(0 → 0x047F…)` and one `DripRateSet(1,000 IMD/day)` at block 25892026. There is **no `VaultSet`** **[F]**.
- The distributor's admin events since deploy are: one `OwnershipTransferred(0 → 0x047F…)` only. There is **no `DripperUpdated`** **[F]**.
- The hook's deploy calldata (via CREATE2 factory `0x0c4973df…2edb`) contains the distributor and BurnExecutor addresses. That is consistent with `rewardsRecipient` having been the distributor since deployment **[F]**. Whether it was changed and later changed back is covered in §6.
- Vault IMD transfers (Blockscout, 3,452 rows): inflows 2,783,789.86 minus outflows 1,024,656.71 = 1,759,133.16, which equals `totalAssets` **[F]**.

**Inference [I]:** the burn-to-staker pipeline has so far delivered about **1,757 IMD into a vault holding about 1.76M IMD**, roughly 0.1% over about 34 days.

**Share price [F] / [I]:**
- **[F]** `convertToAssets(1 sIMD)` is about 7.96 IMD.
- **[F]** The first transfers were deposits of 1 IMD from the deployer (block 25887017), another 1 IMD from the deployer (block 25887172), and 1 IMD from `0x23f9…bdf1` (block 25887182). The deployer then sent a direct 20 IMD transfer to the vault (block 25887236).
- **[I]** That early 20 IMD donation into a roughly 3 IMD vault set the share price near 7.7 before any rewards arrived. So the ~8× figure is an initial-pricing artefact, not accumulated yield.

## 5. Best current answer

**Yes. One externally owned key, `0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7`, can still cut, redirect, or reprice the entire future IMD inflow to sIMD stakers.** It can do this through any of three independent contracts:
- Hook: `setRewardsRecipient`, `setRewardShareBps(0)` or `closeMarket`.
- Distributor: `setDripper`.
- Dripper: `setVault`, `setDripRate(0)` or `rescueERC20`.

This key is the same deployer that renounced the vault.

The 2026-09-19 renunciation **does** remove the owner's power to pause the vault or sweep IMD that has already been staked or dripped into it. That part of the press claim holds. It **does not** make the *reward stream* trustless.

| Claim | Type | Confidence |
|---|---|---|
| Vault owner is `0x0`; renounced in tx `0x519f…1851` on 2026-09-19 | F | High |
| Hook, distributor and dripper owner is EOA `0x047F…54B7`, holding the redirect/halt functions listed in §4.3 | F | High (exact-match verified source and live storage at a pinned block) |
| Live split is 85 burn / 4.5 staking / 6 "bonding" / 4.5 NFT | F | High |
| None of those redirect powers has been *used* on the distributor or dripper | F | High (full log history) |
| None has been used on the hook | I | Medium (deploy args and current state agree, but the event scan was incomplete) |
| Staked IMD already in the vault cannot be taken by any admin | I | Medium-high. It rests on reading `StakedIMD.sol` plus Solady's ERC4626/Ownable. I did not audit Solady or the IMD token. A token-level admin power, such as a pausable or blacklisting IMD/OFT, would bypass this and is unexamined. |
| The 6% "orchestrator compute" bucket is the on-chain `bonding` bucket (held, not yet routed: 2,349.13 IMD) | I | Low-medium. The percentages match but the names do not. |
| The pipeline's real yield so far is about 0.1%, and the ~8× share price comes from the deployer's 20 IMD donation at launch | I | Medium |

**Overall uncertainty, stated plainly:** I am highly confident in the **capability** answer (the powers exist and one EOA holds them). The verified code and current storage both show it directly. Whether the powers have ever been exercised on the hook is less certain. Nothing in this report says anything about the key holder's intent, or about what will happen after block 26136384.

## 6. Unanswered questions

1. **Hook admin-event history.** I scanned the 4,000 most recent hook logs (80 Blockscout v2 pages, newest first) without reaching the end. None was `RewardsRecipientUpdated` or `RewardShareUpdated`, so the oldest part of the hook's history, closest to deployment, was never scanned. The Etherscan-style `getLogs` filter was rate-limited, and free RPC tiers refused archive log ranges. An unbroken scan for `RewardsRecipientUpdated` (`0xa11f9f03…8e9a`) and `RewardShareUpdated` (`0x0470487f…6904`) from block 25887052 is still needed.
2. **Is the 6% `bonding` bucket the advertised "orchestrator compute" reserve?** The operator's docs at `imd.fun/docs` do not describe staking or the distributor. The 85/6/4.5/4.5 framing comes from secondary sources (Bankless, KuCoin, DropsTab).
3. **Base and Robinhood Chain.** Bankless reported about 2.3M IMD staked (2026-09-25). On Ethereum I find 1.76M. Either other chains hold separate vaults, or about 1.02M has been withdrawn on Ethereum (outflows total 1,024,656.71 IMD). I did not examine other chains.
4. **IMD token / LayerZero OFT admin powers.** These were not examined, but they bound the "already-staked IMD is safe" inference.
5. **Is the owner key a single person, an MPC wallet, or a 7702-delegated account?** Zero code rules out 7702 delegation at this block. It does not rule out off-chain key sharing.
6. **Why the dripper has been idle since 2026-10-02.** It holds a zero balance, which suggests trims have slowed or `settleClaims`/`distribute` have not been called. I did not check hook trim activity.

## 7. Sources

**Primary, on-chain** (all checked by me):
- Ethereum mainnet JSON-RPC via `ethereum-rpc.publicnode.com` (state at block 26136384) and `eth.blockscout.com` (log and token-transfer history).
- Verified sources and deployment metadata: [Sourcify](https://sourcify.dev/) entries linked in §4.1.
- Renounce tx: [etherscan.io/tx/0x519fdbdd…1851](https://etherscan.io/tx/0x519fdbdd5b504476efe91f31a20b4091aeb15cb7caed51071151d3ee87b81851).

**Primary, operator:**
- [imd.fun/docs](https://imd.fun/docs/): oracle attestation format, recipe types, IMD address.
- [pool4.imd.fun/stake](https://pool4.imd.fun/stake): front-end address config, in the JS bundle loaded by the page, fetched 2026-10-06.
- [api.imd.fun/oracle/requests](https://api.imd.fun/oracle/requests?limit=1): attester address, and the absence of prior requests matching "sIMD", "StakedIMD", "CappedBurnHook" or the vault/hook addresses.

**Secondary** (claims marked [R]):
- [Bankless, "Inside IMD, Ethereum's New AI Swarm Experiment"](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment) (W. M. Peaster, 2026-09-25).
- [KuCoin blog](https://www.kucoin.com/blog/imd-token-community-owned-ai-agents) (2026-09-29).
- [DropsTab IMD page](https://dropstab.com/coins/Identity-imd).

No chain state in this report is invented. Every on-chain number comes from a call or log I retrieved, and the block is named. Two figures were read at nearby blocks rather than 26136384: the owner nonce (2689) and the Dripped/transfer sums (indexer data current as of about 2026-10-06T22:40Z).