IMD settlement pool depth, manipulation cost, and oracle feasibility

Read-only research, 12 October 2026. The specified settlement pool is not the POOL4 hook pool. It is a hookless Uniswap v4 ETH/IMD pool. The distinction materially changes the burn assumptions. A 5,000 IMD expiry cap is not established as safe with a 2× margin: it works comfortably in the repeated-arbitrage scenarios below, but fails the deliberately conservative quiet-window scenario. A provisional 700 IMD cap fits that latter model, subject to the stated payout, liquidity, and attacker assumptions; it is not an unconditional security bound. The oracle path supports Ethereum reads from all three consumer chains, including Sepolia when the signing domain is Sepolia. The requested full-body free API check does not pass the current endpoint's schema.

Evidence, time, and units

Unless explicitly stated otherwise, every pool state, balance, fee, tick, and depth figure below is at Ethereum block 26,174,693, timestamp 2026-10-12 06:47:59 UTC. Its hash and header are saved in block.json. The seven-day observation interval is 26,124,474–26,174,693, from 2026-10-05 06:47:59 UTC to the snapshot, inclusive. Start state is read at block 26,124,473. Logs include block/transaction hashes and log indices. Start block, v4 swaps, v3 swaps.

RPC reads used the contributor's http://127.0.0.1:36699/rpc/1; Robinhood reads used its /rpc/4663. Sepolia was not among the supplied endpoints, so existing Sepolia transactions were read through https://sepolia.gateway.tenderly.co. HTTP/API results are dated observations, not claims pinned to an Ethereum block. Exact inputs, responses, source snapshots, and calculations are included. No transaction was sent, no contract deployed, and nothing paid for.

Price throughout Parts A–B means ETH per IMD, P = 2^192 / sqrtPriceX96^2, because currency0 is native ETH and currency1 is IMD; both have 18 decimals. Block-pinned token decimal reads. An IMD price increase means a decrease in the Uniswap tick. “Liquidity” L is Uniswap’s raw liquidity parameter, not a token balance. Figures labeled observed come from chain/API reads; calculated figures derive from those reads; scenario/assessment figures depend on assumptions.

Part A — settlement pool depth

1. Pool identity, fees, and what the hook actually does

Observed settlement pool key:

Field	Value
PoolManager	0x000000000004444c5dc75cb358380d2e3de08a90
Pool ID	0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3
currency0	Native ETH, represented by the actual zero currency address
currency1	IMD 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7
Hook	Actual zero address: no hook
LP fee	10,000 pips = 1%
Tick spacing	200
Protocol fee, each direction	1,000 pips = 0.1%
Combined input fee, each direction	10,990 pips = 1.099%

The Initialize event is at block 25,640,607, transaction 0x95f51e…abd1. Independently hashing the ABI-encoded five-field key reproduces the exact requested pool ID. Thus the zero hook is an observed value, not a placeholder. Saved initialization and state, key/hash calculation.

Slot0's packed protocol fee is 4,097,000 = (1,000 << 12) + 1,000. Uniswap combines it with the LP fee as 1000 + 10000 − floor(1000×10000/1000000) = 10990; adding 1% and 0.1% without the overlap would be slightly wrong. The swap events and state reads support this current fee. ProtocolFeeLibrary primary source, saved source.

Consequently, buys and sells in the settlement pool have zero hook burn, zero hook trim, zero cap ratchet, and no hook-created liquidity bands. Ordinary LP liquidity and swap fees apply.

The separate POOL4 pool is 0x415829f72e9f54531c26eae76f107618540e898a45d6ae35959e143f5faca704. Its hook is 0xc6c965bd164c483e87d0b550671798e9a3602840, its LP fee is 1%, tick spacing 60, and current protocol fee 0. The hook's poolId() and poolKey() agree with its Initialize event at 25,887,097, transaction 0x6c0c47…6b87. Hook reads.

The following behavior is established by exact-match verified CappedBurnHook.sol, retrieved from Sourcify's contract record, with the extracted source and saved exact-match record:

• beforeInitialize and beforeAddLiquidity restrict initialization and adding liquidity to the hook. The main position is full range, ticks −887,220 to +887,220.
• afterSwap first redeems eligible older claims and collects the main position's LP fees into a separate fee ledger. It returns zero delta: there is no additional percentage tax deducted from the trader's quoted swap.
• A buy removes IMD from the main position. If its holdings are below the inventory cap, _applyCap lowers the cap by the configured share of the headroom, bounded by the decay allowance and cap floor. Current ratchet is 100%, decay allowance 3,000 IMD/day, and both cap and floor are 9,000 IMD. Since the cap is already at its floor, it currently cannot ratchet further down.
• A sell adds IMD. Only holdings above the cap are trimmed. The hook removes a proportional amount of main-position liquidity at the unchanged square-root price. Of the tokens removed, 85% is booked to the burn sink and 15% to rewards. The ETH removed alongside them is retained. This burns/redistributes protocol inventory, not a second debit from the seller. minTrimTokens is currently 0; integer rounding can leave a tiny residue.
• Burn claims are not proof of immediate supply destruction: _disperse books claims, and later settlement transfers to the configured burn sink, currently 0xe29386719c155b6847ad5a4e97c6674f10ffc750. The source's totalBurned counter therefore needs that qualification.
• A permissionless keeper's rebalance() closes a filled backstop, routes its acquired IMD through the same split, and deploys retained ETH in one single-sided band above the raw Uniswap tick, hence below the IMD/ETH price. This is a bid, not an IMD sell wall above the economic price. Rebalancing is not performed on every swap. Placement is bounded by spot, a lagged reference, and the deployment floor. The reference moves at most 200 ticks per block; the floor's current downward decay setting is 2,000 ticks/day. The rebalance threshold is 0.1 ETH, and the configured keeper tip is 0.002 ETH, subject to the source's work/value caps.

At the snapshot, the main position holds 25.820875 ETH + 6,667.640187 IMD. The backstop holds approximately 34.275191 ETH, at ticks 61,560–887,220; retained idle ETH is 0. Its first bid is at 0.002121372 ETH/IMD, 45.22% below the hook pool's current price. The main position reaches the 9,000 IMD cap at approximately 45.11% below its current price, assuming its liquidity stays fixed. Thus ordinary ±10% or ±20% moves from this state neither reach the bid nor trigger a main-position trim. The full week's 5,644 hook events contain 3,422 FeeCollected, 2,219 DeploymentFloorUpdated, 3 FeesWithdrawn, and zero Trimmed / BackstopSettled events. Raw events, summary. Marketing launch defaults are not substituted for these live settings.

2. Tick distribution and inventory within price bands

Observed: current sqrtPriceX96 = 1273142578241190075138874124048, tick 55,541, active L = 9,727,898,950,757,181,123,119. Calculated price: 0.003872621766527 ETH/IMD, or 258.222997310 IMD/ETH.

I enumerated every bitmap word over the valid tick domain for spacing 200, then read all 37 initialized ticks with getTickInfo. Summing their signed liquidity-net values reconstructs the active liquidity exactly and sums to zero over the full domain. The slot0 square-root price was independently checked directly in PoolManager storage, using keccak256(abi.encode(poolId, uint256(6))). Raw state, direct storage, full tick interval CSV. The storage layout and tick accessors are in Uniswap StateLibrary.

An independent reconstruction of 834 ModifyLiquidity events found 24 live positions and confirms the full-range position total below, rather than assuming matching endpoint ticks belong to the same positions. Liquidity events, reconstructed positions.

Liquidity is mixed, not exclusively full range: the −887,200/+887,200 full-range component has L = 7,474,526,437,908,911,333,736, 76.836% of current active liquidity; the remainder is concentrated. Near the ±20% band, the reconstructed intervals are:

Tick interval	Raw active L within interval
53,000–53,800	9,310,010,032,846,088,497,116
53,800–54,400	9,507,825,961,489,983,724,861
54,400–54,600	9,524,686,660,580,512,828,555
54,600–55,800 (current)	9,727,898,950,757,181,123,119
55,800–56,200	9,815,093,616,012,332,052,623
56,200–56,600	9,815,378,078,278,471,866,194
56,600–57,000	10,011,405,704,041,895,656,613
57,000–57,400	10,011,224,739,433,140,746,935
57,400–57,600	9,808,012,449,256,472,452,371
57,600–58,200	8,334,061,648,169,715,576,182

For a band [P₀(1−x), P₀(1+x)], the ETH column is principal on the lower IMD-price side, available to sellers before the lower boundary; the IMD column is principal on the higher IMD-price side, available to buyers before the upper boundary. This integrates the portions of positions inside the band, including portions of full-range positions. It does not count whole positions merely because they overlap the band, and excludes accrued fees.

Price band around snapshot	ETH principal within band	IMD principal within band	Combined value at P₀, ETH
±5%	15.395920	3,767.317627	29.985316
±10%	31.274620	7,272.870993	59.439698
±20%	64.149902	13,465.089644	116.295101
Entire tick domain	484.099160	158,343.477144	1,097.303557

Calculated depth and offline calculation. These are pool-specific principal amounts; the PoolManager's aggregate ERC-20/ETH balances would include other pools and cannot answer this question.

3. Single-swap inputs to move the price

Integrate each traversed tick segment with s = sqrt(IMD/ETH) = sqrtPriceX96 / 2^96. The following deltas are in raw token units; divide by 10^18 for the table:

• ETH-in, IMD-price up: net ETH = Σ L(1/s_end − 1/s_start), IMD out = Σ L(s_start − s_end).
• IMD-in, IMD-price down: net IMD = Σ L(s_end − s_start), ETH out = Σ L(1/s_start − 1/s_end).
• Gross input is net input divided by 0.98901, with integer swap rounding. Target s = s₀ / sqrt(P/P₀). Apply liquidity-net changes when crossing initialized ticks.

Target IMD price	Gross input required	Asset received	Input fee included
+10%	29.867659 ETH	7,272.870993 IMD	0.328246 ETH
+20%	57.722344 ETH	13,465.089644 IMD	0.634369 ETH
−10%	8,608.013431 IMD	31.274620 ETH	94.602068 IMD
−20%	18,709.836512 IMD	64.149902 ETH	205.621103 IMD

These are calculated for a single swap starting at block 26,174,693's state, without intervening liquidity changes or other trades. The hook adjustment is zero, because the specified pool has no hook. Independent integer TickMath/amount-delta calculations agree within 10⁻¹² input token; the displayed precision is much coarser. Validation, Uniswap SwapMath, SqrtPriceMath. Gross input is capital committed, not net economic loss.

Part B — persistence cost and expiry exposure

4. Other pools and observed gap convergence

The full addresses/IDs, fees, currencies and block-pinned active liquidity are in pool-census.csv. The economically relevant named venues are:

Venue	Fee at snapshot	Active L	Inventory/depth indication at block 26,174,693
v4 settlement 0xb07d…fb3	1.099% combined	9,727,898,950,757,181,123,119	484.099160 ETH + 158,343.477144 IMD principal
v4 POOL4 0x4158…a704	1%	414,926,865,300,641,902,347	60.096066 ETH including backstop + 6,667.640187 IMD principal
v4 0x8a40…a128	LP 1.0009%; combined 1.0999%	3,304,210,373,971,050,935,996	27.381879 ETH + 17,256.030978 IMD principal; concentrated
v3 IMD/USDC	0.3% total trader fee	148,624,798,518,661,496	Pool balances 67,339.159867 USDC + 20,012.884651 IMD, including fees/dust; not a principal-only tick integral
v3 IMD/USDT	0.3% total trader fee	0	Balances 29,465.769445 USDT + 430.522879 IMD do not imply active liquidity; current tick 887,271 is a stale/extreme, unusable spot

The full third v4 ID is 0x8a401476fa1fe38c951cfce60f8c033a47fafa87dd629f6a49fe4feef333a128; it was initialized at 26,147,020, within the observed week. Its initialization transaction, pool states, POOL4 distribution, third-pool distribution.

At the same block, POOL4 prices IMD at 0.003872565741 ETH and the third v4 pool at 0.003873708138 ETH. V3 IMD/USDC is 9.888677907 USDC/IMD. The canonical USDC/WETH 0.05% pool implies 2,562.396230 USDC/ETH, putting the v3 IMD quote about 0.35% below the settlement quote. This is a cross-venue consistency check, not an independent proof of fundamental fair value. ETH conversion state.

Discovery scope: Initialize-log scans found 66 native ETH/IMD v4 pools and 15 v4 IMD pools against WETH/USDC/USDT. Besides the three material ETH venues above, only five have nonzero active L: two native ETH dust pools (0xb3dd…2356, L 18,161,219,048,112,565, LP fee 51.5%; 0x770f…71ca, L 39,678,532,605,718,121, fee 98%), two USDC pools (L 1,433,123,391,474 and 4,113,383,908,307, fees 90%/89%), and one USDT pool (L 9,392,868,730,334, fee 65%). They are not competitive ±10% arbitrage routes. Standard v3 factory queries at fee tiers 100/500/3000/10000 found the two listed stablecoin pools plus drained WETH/IMD 0xd6a822d028bbf7b6edfa1533e110ee40c08551d9 and USDC/IMD 0x3a6a81b9950bcdfc01eff5ff599c31e919576a5f, both L 0. Standard v2 factory queries found no IMD pair against those three quote assets. This is not a census of every DEX, chain or CEX. Other v4 reads, v3 discovery, v2 reads.

Seven-day method: order all Swap logs by block/log index. A “large trade” changes the settlement price by at least 1% relative to its immediately preceding state. There were 396 such swaps, across 389 blocks. For each comparator, start an observation if its resulting absolute price gap exceeds 3%; measure the first subsequent swap taking the gap inside ±2.5%. That threshold accommodates round-trip fees; it does not mean exact equality. Observations can overlap and are not independent trials. Stablecoin conversions use the USDC/WETH end-of-block price at the initiating large trade, held fixed during that observation. No USDT depeg adjustment is assumed. Method, stablecoin method and saved conversion reads.

Comparator	Week swaps	Qualifying gaps / converged	Same-block convergence	Median / p90 / max blocks to converge, among closed
POOL4	3,422	60 / 60	58	0 / 0 / 2
v4 0x8a40…a128	1,762	13 / 13	6	67 / 659 / 659
v3 IMD/USDC	24,394	36 / 36	35	0 / 0 / 1
v3 IMD/USDT	336	337 / 114; 223 censored/unclosed	5	2,287 / 11,773 / 22,955

The settlement pool itself had 18,679 swaps. POOL4's maximum convergence time was 24 seconds, USDC's 12 seconds; the third v4 pool's median was 816 seconds, maximum 7,932 seconds. The USDT series is often stale or noncompetitive, and its current active liquidity is zero; its long observations also suffer from the fixed ETH/USD conversion assumption: its long delays are not a useful estimate of a functioning arbitrage service. Also, convergence can reflect movement in the reference or a reversal of the market, not restoration of a fixed fair price. These are measured gap-convergence times, not an assertion that every closing trade was arbitrage. v4 observations, stablecoin observations, summaries, stablecoin summary.

Two concrete trade sequences establish that cross-pool arbitrage is present:

• At 26,154,007, a 20.1 ETH buy raised settlement spot 6.1572%, opening a 5.9664% gap to POOL4. In the same block, 0x6d7a18…1364 bought 61.681765 IMD from POOL4 for 0.245931 ETH and sold that exact IMD quantity into settlement for 0.248412 ETH. The gap crossed below 2.5%. That is a visible two-venue arbitrage leg, before gas.
• At 26,158,678, a 9,404.968601 IMD sale moved settlement spot −9.7341% and opened a −9.7856% gap to POOL4. A later same-block transaction swapped across POOL4, the third v4 pool, settlement and USDC; the POOL4 gap narrowed to −2.2982%. It includes a settlement purchase of 34.277013 IMD for 0.108344 ETH followed by sale of that exact IMD amount for 270.489309 USDC.

By contrast, the third v4 pool's 659-block example ended when settlement fell back toward its stale quote; the closing transaction did not swap in that third pool. It should not be advertised as a 659-block arbitrage response. Overall, 41/60 POOL4, 6/13 third-pool and 33/36 USDC observations closed in transactions containing swaps in both relevant venues, still not proof of the sender's overall strategy.

5. Cost of controlling 31 of 61 samples

Definition: a 300-block inclusive endpoint span with 61 samples uses b_i = fromBlock + 5i, i = 0..60. Thirty-one consecutive samples span 150 blocks, approximately 30 minutes. They need not be consecutive, and only sampled end-of-block states count. Intrablock price excursions that arbitrage reverses before block end do not manipulate this median. The five-block lag delays the request; it does not make sampled prices manipulation-resistant.

The following estimates use snapshot P₀ as a stationary fair-price proxy, unchanged liquidity, fixed current fees, and an outsider who does not own/recover LP fees, withdraw liquidity, control the hook, or profit on other positions beyond the modeled expiry. They do not assume the actor must destroy the gross swap input. Independent hedging capacity, transaction placement and borrow funding are uncertain.

Scenario for 31 affected samples	+10%: ETH cost (IMD at P₀)	−10%: ETH cost (IMD at P₀)
Low, quiet hold: move once, no intervening arbitrage, sell/buy back the received asset after sample 31	0.637938 (164.730298)	0.710261 (183.405816)
Competition returns price to within 2.5% between samples; 1 initial + 30 restorative moves, outputs marked at fair	47.504610 (12,266.782816)	58.408531 (15,082.425988)
Complete return to fair between samples; 31 independent moves, outputs marked at fair	52.780006 (13,629.011291)	63.889767 (16,497.807101)
High modeled case: 31 complete resets, plus 1% external conversion cost and 0.005 ETH gas/ordering allowance per cycle	61.666180 (15,923.625863)	73.739899 (19,041.337758)

Low-case arithmetic: buy up 10% with 29.867659 ETH, receive 7,272.870993 IMD, then sell that IMD back through the unchanged pool for 29.229721 ETH: loss 0.637938 ETH. For down 10%, sell 8,608.013431 IMD, receive 31.274620 ETH, then buy back 8,424.607615 IMD: loss 183.405816 IMD. The final prices remain about +0.1023% / −0.1135% from P₀ because fees make the self-unwind incomplete. The table measures inventory loss, not a claim of exact final-price restoration. Gas/ordering costs are set to zero only in this conservative low-cost stress case.

Reset-case arithmetic: a single +10% move loses 29.867659 − 7272.870993×P₀ = 1.702581 ETH on a fair-price mark, including 0.328246 ETH fee and 1.374335 ETH price-impact loss. A −10% move loses 8608.013431×P₀ − 31.274620 = 2.060960 ETH, including 0.366358 ETH fee and 1.694602 ETH impact loss. Multiply by 31 only if a return to fair really happens between the controlled samples. Do not multiply the 29.87 ETH gross input by 31 and call that a loss.

The high +10% estimate decomposes into 18.906787 ETH pool/external fees, 42.604393 ETH adverse execution/impact loss, and 0.155 ETH gas/ordering allowance; the high −10% estimate is 21.052231 + 52.532668 + 0.155 ETH. Additional hook burns are 0 on the settlement trades. Routing offsets through POOL4 can pay its 1% fee, included in the illustrative external-fee allowance, but its inventory trim is not an additional seller tax. No relevant trim was observed during this week, and current ±20% hook-pool moves would not reach the cap.

Limits of this estimate: the low case is a stress assumption about absent/suppressed arbitrage, not an observed 30-minute opportunity; the evidence points to rapid competition. Conversely, the high case is not a mathematical upper bound: continuously defending every block for 150 blocks, rather than only 31 sampled endings, could entail about 151 resets, modeled at 300.373974 ETH up / 359.184670 ETH down with the same per-cycle allowances. Many interventions within a block, builder payments, changing fair value or liquidity can cost more. Sparse sample timing, LP fee recovery, coordinating other venues, or withdrawing liquidity can cost less. Historical convergence does not identify the future attacker's necessary number of resets. Scenario calculation and assumptions, script.

6. Maximum weekly open interest with a 2× margin

A payoff formula is necessary. For this recommendation assume the aggregate expiry payout sensitivity is bounded by 0.10 × OI IMD for a 10% settlement displacement, with exposure aggregated across linked accounts/contracts. This describes a bounded linear cash-settled exposure, not a digital option, leverage multiplier, or arbitrary payout schedule.

For cost C, a 2× margin requires C ≥ 2 × 0.10 × OI, so OI_max = C / 0.20. Use the cheaper direction and cheaper holding scenario, not gross input or the expensive competition case:

min(164.730298, 183.405816) / 0.20 = 823.651492 IMD.

Recommendation: at most 700 IMD per expiry under these assumptions, rounding below the model ceiling. At 700, a 10% displacement gives at most 70 IMD, and 164.730298 / 70 = 2.3533×. If cash P&L is converted to IMD using a manipulated lower settlement price, a conservative sensitivity can be 0.10/0.90 = 0.111111; then the same cheaper cost permits 741.286343 IMD, and 700 still leaves 2.1180×. These two payout conventions must not be confused.

At 5,000 IMD, the linear-model gain is 500 IMD and the required cost floor is 1,000 IMD; 164.73 < 1,000, and it is even below the gain itself. Repeated fair resets would make 5,000 look safe—three independent full upward resets cost about 1,318.94 IMD—but the sample count alone does not guarantee those resets. Thus 5,000 is too loose for a cap advertised as secure under the conservative scenario.

No unconditional nonzero cap is proved by this research. The 700 figure needs enforceable limits on payout sensitivity and minimum independent depth, plus re-evaluation before every expiry. Pool liquidity is withdrawable; an LP attacker can recover fees; an owner can close POOL4; price and fees can change. If the contract lacks these assumptions/controls, the only strictly defensible guaranteed exposure from the evidence alone is zero until a lower attack-cost bound is established. For a binary payout whose manipulation can swing the whole notional, even the quiet-case arithmetic gives only 164.730298/2 = 82.365149 IMD, not 700. The actual settlement contract and payoff were not supplied, so this distinction remains an explicit uncertainty.

Part C — oracle feasibility

7. Sepolia can read Ethereum; the consumer domain is the restriction

Yes, with a Sepolia callback/consumer. A Sepolia contract can call the v2 Intake's requestWithFailure with oracle chainId: 1, evidence: "chain", and this mainnet pool. The oracle body’s chain ID selects the evidence chain. The consumer/domain chain selects where the signed answer is usable. Let the Intake derive the consumer from the Sepolia callback, or explicitly set the consumer to that same Sepolia contract. Do not explicitly retain an Ethereum consumer address/domain from a production body when testing with Sepolia payment.

This is supported by an existing successful mainnet chain-evidence request paid on Sepolia: Intake transaction 0x992dc3…bc53, Sepolia block 11,894,376. It read USDC decimals at Ethereum window 26,171,704–26,171,753, with body chainId:1, evidence:"chain", consumer chain 11155111, and attained a signed answer. Request 951fc178…, attestation. This proves cross-chain evidence admission; it is not a test we performed or a claim that this exact 61-sample body has already run on Sepolia. That observed transaction need not use the failure-hook variant; v2 requestWithFailure submits the same body path and adds failure notification. Verified Sepolia Intake source record.

Observed testnet_only trigger: Sepolia payment whose resolved signing consumer is not a testnet. For example transaction 0x7bbd9e…d167, Sepolia block 11,896,237, had no callback or explicit testnet consumer, and was refused because the answer would be signed for chain 1. Another refusal, block 11,887,466, explicitly requested consumer 46630 and was refused for the same domain reason. The API tells the caller to name a callback or testnet consumer. These records refute the interpretation that merely reading mainnet triggers testnet_only. Saved decoded requests, Intake results.

Callbacks are asynchronous and can fail: the documented allowance is 200,000 gas on Ethereum/Robinhood and 1,000,000 on Sepolia, attempted once. requestWithFailure adds notification for refused/failed work, not a refund or guaranteed answer. Failure arguments are currently unsigned; clear only the consumer’s own pending request and do not settle money from a failure reason alone. Callback and failure documentation.

The best end-to-end pre-mainnet test is therefore a Sepolia consumer requesting this actual historical mainnet pool/window, signed for Sepolia, with success/failure handling and strict field checks. A local mainnet fork can separately test settlement arithmetic, but does not exercise the hosted panel, signer or callback delivery. This assignment performed neither test deployment nor payment; the recommendation is for a later authorized test.

8. Robinhood Chain and fixed Ethereum windows

Yes. The live capabilities API lists Intake 0xa43e6f75ee006411f79ac1c84120606c2330de82 on chains 1, 4663 and 11155111. oracle.request@oracle-1 costs 0.5 of that chain's IMD, with confirmation settings 3 / 2 / 2 respectively. Robinhood's IMD is 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127. A read at Robinhood block 86,482,389 also found deployed code at the Intake. Saved capabilities, Robinhood read.

For a Robinhood callback, use oracle body chainId:1, fixed Ethereum window:{fromBlock,toBlock}, and consumer domain chainId:4663. The documented absolute-window constraint is that toBlock is at least 5 blocks behind Ethereum's head when admitted/pinned. The attestation's message.chainId remains 1; its EIP-712 domain.chainId is 4663. No bridge of the pool or its reserves is required. This is documented support plus deployment evidence, not a new end-to-end Robinhood execution. Oracle body documentation, Intake documentation.

A consumer should verify the trusted signer under the correct IdentityMD Oracle v2 domain and its own address; its own pending request ID; the expected question hash; answer type uint256 (enum 3); evidence-chain ID 1; exact fromBlock/toBlock; panel size 5, quorum 5, and agreed ≥ 5; expiry/freshness; and replay protection. The question hash commits the requested definition, including pool, units and sampling rule. The signed attestation includes fromBlock, toBlock and the closing blockHash, plus panel counts and times. Merely seeing attested is insufficient: documented chain-reproduction handling can produce an attestation with agreed below quorum, so the consumer must enforce its own agreed check. Attestation format, real signed message example.

A Robinhood contract can check that these signed fields equal the values it expected. It cannot natively verify an Ethereum block hash with Robinhood's blockhash, or independently prove the 61 PoolManager states or correct median merely from this signature. That requires the oracle trust assumption or an additional Ethereum light-client/state-proof system. An immutable expiry-to-window rule prevents selecting a favorable historical window after observing prices. An hours-based window should not replace a precisely scheduled expiry window.

9. Exact free check: full body rejected; shortened draft accepted with different terms

The requested affirmative cannot honestly be confirmed. On the current API, POST /requests/check is a drafting endpoint, not the full oracle-body validator. I sent the exact uint256 / chain / toleranceBps 0 / panelSize 5 / quorum 5 / 61-sample median body in Appendix A. It returned HTTP 400, invalid_request, rejecting keys v, window, quorum, validForSeconds, definitions. Exact sent JSON, exact response.

I then sent the supported shortened shape, with the window, 61-sample median and 5-of-5 intention in the question text (Appendix B). It returned HTTP 200, blockers:[], suggestions:[], but drafted quorum 4 and window 24 hours, and omitted toleranceBps from the draft even though the proposal reported 0. That is not validation of the required 5-of-5 fixed-window body. The original full body conforms to the documented oracle-body field structure, but that fact is not a successful check or proof of admission. No paid quote, Intake request or other purchase was used to get around this limitation.

As a read-only feasibility check, I independently sampled the proposed fixed window 26,174,388–26,174,688, 61 blocks at spacing 5, and obtained median 3,968,458,827,655,281 wei ETH per IMD. This validates the local calculation, not a hosted oracle request. All 61 reads. The reference price at closing block and the window median need not equal the later snapshot price.

10. Recent actual attestations and unsuccessful requests

GET /oracle/requests?q=<full settlement pool ID>&limit=500 returned 44 requests at capture: 43 attested, 1 refused, 0 disagreed, 0 failed; the page was not truncated. Their creation dates span 2026-10-01 to 2026-10-12. 31 of them were created within the seven-day market interval. A broader IMD search for unsuccessful statuses returned 14 records; inspecting their details found no additional failed/disagreed request identifying this exact pool. These are search-coverage statements, not a guarantee that deleted requests or differently worded/unnamed pools are absent. Pool query results, broader search.

All timestamps below are UTC on 2026-10-12. Latency is attestedAt − createdAt; it excludes payment confirmation and callback delivery.

Request	Recipe / Ethereum window	Created → attested	Latency	Signed/reproduced value, wei ETH/IMD
6c789448…	univ4-spot median, 13 samples; 26,174,082–26,174,681	06:46:40.369 → 06:48:29.485	109.116 s	3,977,368,332,826,956
38e9b493…	univ4-spot closing spot, 1 sample; 26,173,647–26,173,946	04:19:27.820 → 04:20:48.648	80.828 s	4,047,213,747,175,071
fb772b77…	univ4-spot median, 13 samples; 26,173,346–26,173,945	04:19:25.018 → 04:20:47.886	82.868 s	4,133,370,597,761,554

These examples used panelSize 100 / quorum 67; they do not establish latency or success probability for 5/5 or 61 samples. The one refused pool request, 5924ecc6…, read window 26,103,765–26,105,765. Its reproduced median 2,874,627,056,511,882 exceeded the request's guard maximum 2,663,741,408,448,862, so it was refused despite an agreeing recipe. It was not a panel disagreement or chain-read failure. Saved refusal.

Reproduction, checks, and remaining uncertainty

The bundled Python scripts use the standard library only. README lists offline commands. Offline command results show all six reproduction commands passed; validation.json records tick conservation, direct-storage/StateView agreement, independent integer swap math, sample median checks, log duplicate/range checks, gap-closure arithmetic and the API rejection distinction. These are local checks, not independent assurance. Tick depth changes with LP actions; convergence metrics are observational; the cost scenarios omit unbounded MEV/coordination possibilities; the actual expiry payoff and controls were not supplied. Source verification attests bytecode/source correspondence, not economic safety. The hosted oracle still depends on its panel, signer and delivery service, and can be late or fail.

Appendix A — exact full-body free-check attempt

POST https://api.imd.fun/requests/check, Content-Type: application/json. No authentication or payment. The transport JSON below contains the exact field values sent (pretty-printed); the window ends five blocks before the snapshot head.

{
  "action": "oracle.request",
  "input": {
    "v": 1,
    "question": "What is the median spot price of Uniswap v4 ETH/IMD pool 0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3 on Ethereum PoolManager 0x000000000004444c5dc75cb358380d2e3de08a90 across the pinned window, expressed as integer wei of ETH per 1e18 raw IMD units, truncated toward zero?",
    "chainId": 1,
    "window": {
      "fromBlock": 26174388,
      "toBlock": 26174688
    },
    "answerType": "uint256",
    "evidence": "chain",
    "toleranceBps": 0,
    "panelSize": 5,
    "quorum": 5,
    "validForSeconds": 86400,
    "definitions": {
      "recipe": "Use univ4-spot with median aggregation and 61 samples.",
      "samples": "Read PoolManager slot0 at block fromBlock + floor(i*(toBlock-fromBlock)/60) for i=0..60 inclusive; take the median of 61 integer prices.",
      "price": "currency0 is native ETH, currency1 is IMD (18 decimals). Each price is floor(2^192 * 10^18 / sqrtPriceX96^2), in wei ETH per 1e18 raw IMD."
    }
  }
}

HTTP 400. Response body:

{
  "error": "invalid_request",
  "detail": "request: Unrecognized keys: \"v\", \"window\", \"quorum\", \"validForSeconds\", \"definitions\""
}

Appendix B — exact supported shortened check and its response

POST to the same free endpoint. Moving the requested terms into the question text did not make them structured constraints in the returned draft.

{
  "action": "oracle.request",
  "input": {
    "question": "What is the median spot price of Uniswap v4 ETH/IMD pool 0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3 on Ethereum PoolManager 0x000000000004444c5dc75cb358380d2e3de08a90 across the pinned window, expressed as integer wei of ETH per 1e18 raw IMD units, truncated toward zero? Use univ4-spot, invert false, samples 61, median of evenly spaced end-of-block prices; require quorum 5 of 5; fixed Ethereum blocks 26174388 through 26174688 inclusive.",
    "chainId": 1,
    "answerType": "uint256",
    "evidence": "chain",
    "toleranceBps": 0,
    "panelSize": 5
  }
}

HTTP 200. Exact response values:

{
  "action": "oracle.request",
  "request": {
    "v": 1,
    "question": "What is the median spot price of Uniswap v4 ETH/IMD pool 0xb07d640fd9e2eb9dc81b953c8e4fd006bdfeaf276010fb5418eb763ca15abfb3 on Ethereum PoolManager 0x000000000004444c5dc75cb358380d2e3de08a90 across the pinned window, expressed as integer wei of ETH per 1e18 raw IMD units, truncated toward zero? Use univ4-spot, invert false, samples 61, median of evenly spaced end-of-block prices; require quorum 5 of 5; fixed Ethereum blocks 26174388 through 26174688 inclusive.",
    "chainId": 1,
    "window": {
      "hours": 24
    },
    "answerType": "uint256",
    "evidence": "chain",
    "panelSize": 5,
    "quorum": 4,
    "validForSeconds": 86400
  },
  "proposed": {
    "answerType": {
      "value": "uint256",
      "confidence": 1
    },
    "evidence": {
      "value": "chain",
      "confidence": 1
    },
    "chainId": {
      "value": 1,
      "confidence": 0.98
    },
    "toleranceBps": {
      "value": 0,
      "confidence": 0.41
    },
    "head": {
      "value": 1,
      "confidence": 1
    }
  },
  "judged": true,
  "blockers": [],
  "suggestions": [],
  "online": 987,
  "limits": {
    "minPanelSize": 5,
    "maxPanelSize": 100
  },
  "chains": [
    {
      "id": 1,
      "name": "Ethereum mainnet"
    },
    {
      "id": 56,
      "name": "BNB Chain"
    },
    {
      "id": 4663,
      "name": "Robinhood Chain"
    },
    {
      "id": 8453,
      "name": "Base"
    },
    {
      "id": 42161,
      "name": "Arbitrum One"
    }
  ]
}

Verdict

A 5,000 IMD per-expiry cap is too loose to claim the requested robust 2× manipulation margin from this evidence: active arbitrage would probably make a sustained 10% displacement expensive, but that is an observed tendency, not an enforceable cost floor; the fixed-depth quiet-hold model costs only about 165–183 IMD. Use 700 IMD at most as a conditional pilot limit for the stated bounded linear payout assumptions, and no nonzero guaranteed limit without enforceable depth/payout controls. The oracle path is workable on Ethereum mainnet and Robinhood Chain, and also on Sepolia for a Sepolia-signed consumer reading Ethereum; testnet_only restricts where a testnet-paid answer is signed, not which chain it reads. The exact 5-of-5, 61-sample body still lacks a successful full-body free check because the current /requests/check interface rejects those structured fields; its accepted shorter draft silently supplies different window/quorum terms, so that draft must not be treated as production validation.