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) [F]. The public API reports a single attester key, 0x5598aa9146215bc13eb26f2c692ad1461fd32982 (api.imd.fun/oracle/requests) [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	src/StakedIMD.sol:StakedIMD, Sourcify exact match	0x091a1fc3…8c82 (25887017)
DRIPPER	0xe6D3De6daEAf327fCA42745f1998FcD989e00884	src/RewardDripper.sol:RewardDripper, Sourcify exact match	0x57cde315…3232 (25887025)
DISTRIBUTOR	0x9046739E1535B40EfBe6AB3f45d0024b690eCA30	src/RewardDistributor.sol:RewardDistributor, Sourcify exact match	0xd441ccef…15e8 (25887045)
HOOK (POOL4)	0xc6c965bd164c483e87d0b550671798e9a3602840	src/CappedBurnHook.sol:CappedBurnHook, Sourcify exact match	0x6f9d804f…db52b (25887052)
BURN_EXECUTOR (burn sink)	0xe29386719C155B6847aD5a4E97C6674f10ffc750	src/BurnExecutor.sol:BurnExecutor, Sourcify exact match	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, 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 entries linked in §4.1.
• Renounce tx: etherscan.io/tx/0x519fdbdd…1851.

Primary, operator:

• imd.fun/docs: oracle attestation format, recipe types, IMD address.
• 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: 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" (W. M. Peaster, 2026-09-25).
• KuCoin blog (2026-09-29).
• DropsTab IMD page.

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).