A self-funding, volatility-triggered swarm-oracle hook for a Uniswap v4 IMD pool

Report date: 2026-10-05. All web sources were read on this date; see Sources. All IdentityMD-plane specifics (Intake, the signer, the request price, oracle.request) are taken from the assignment brief, which is the only description of that plane available to this report — none of it could be independently verified against a live contract or explorer, and every such claim is marked ASSUMPTION at first use.

Recommendation

Deploy a Uniswap v4 hook on the IMD/X launch pool that does three things and nothing else: it skims a small, IMD-denominated slice of swap output into an ERC-6909 reserve inside PoolManager (never swapping, so it never takes directional risk); it keeps a short median-of-swaps reading of the pool's own spot price and compares it to the last attested price on every afterSwap; and the moment that reading drifts more than 10% — half of the swarm's own 20% catch-up ceiling — it redeems enough reserve to cover the fixed 0.5 IMD request fee and calls the upstream Intake contract itself, naming a separate, minimal Feed contract as the consumer that will receive the signed attestation. A cooldown and a timeout-bounded single-in-flight lock keep the hook from ever asking twice for the same move, and a daily spend cap bounds worst-case reserve loss even under sustained manipulation. The Feed contract is the only thing other protocols read; it pins the exact question (this pool, this recipe, this chain) the swarm must answer, requires the attested block window to strictly advance, and rejects anything not signed by the swarm's fixed service key — but, unlike the stalled feed that motivated this work, it carries no tight deviation ceiling of its own, because a feed that cannot accept a big true move is the exact bug being fixed.

Decisions at a glance

#	Question	Choice	Figure	Main reason
1	Trigger location, band, cooldown, lock, gas	afterSwap, median of last 5 settled swaps vs. last attested price; cooldown + timeout-bounded in-flight lock; triggering swapper pays gas, no rebate	Band 10%; cooldown 900s; lock timeout 1800s	Band half the swarm's 20% jump ceiling so a request is never asked for a jump it cannot take; gas cost (≈100–150k extra) is cents, not worth the complexity/risk of a rebate path
2	Funding currency and caps	Skim only the leg of swap output already denominated in IMD; hold as ERC-6909 claim; never swap inside the hook	Skim 5 bps of IMD-side output; cap 1 request/cooldown, 20 requests/day	Avoids any internal swap (manipulable, adds surface); matches request currency to reserve currency with zero conversion risk
3	Manipulation economics	Cooldown + in-flight lock cap the number of paid requests regardless of how many times a band is crossed; median-of-5 resists a single-block spike	Forcing 1 request costs ≥ round-trip slippage on a 10% move vs. 0.5 IMD (~$4.25) the attacker makes the reserve spend	At realistic pool depth, round-trip slippage to move price 10% is orders of magnitude above the request fee it forces the reserve to pay
4	Feed design, delivery failure, panel refusal	Separate Feed contract, pinned question hash, monotonic toBlock, signer check; no tight sanity cap (90% ceiling only against clearly-corrupted data); permissionless delivery	Sanity ceiling 9000 bps, used only as a last resort	A tight cap reproduces the exact stall this design exists to avoid
5	Comparator landscape	Closest in spirit to Pyth's pull model economically, but trigger-condition is volatility (Chainlink's idea) read from the hook's own pool (TWAP's idea), paid by the pool itself rather than a consumer or searcher (unlike API3 OEV)	—	No existing design combines "pool is the watcher" with "pool pays its own way"

---

1. Hook permissions, trigger location, band, cooldown, lock, and gas

Where the trigger lives. The hook implements afterSwap. beforeSwap is unnecessary: the trigger decision only needs the settled post-swap price, and running it before the swap would read a price the swap itself is about to move. afterSwap fires once per swap, after PoolManager has updated slot0, so the hook reads the same price any external caller would see immediately after the transaction. The hook also implements beforeInitialize, which an IMD launch hook must implement regardless of trading logic needs (the factory initializes the pool in the same transaction that deploys the hook, and PoolManager would call into a hook address with no code without it); here it is put to real use validating that the pool's fee tier is one of the launch policy's allowed tiers (500/3000/10000) before the pool can exist.

Permission flags and the address bits they fix. Reading v4-core's Hooks.sol directly (GitHub, Uniswap/v4-core, src/libraries/Hooks.sol, read 2026-10-05) gives the bit for each flag:

Flag	Bit	Value
BEFORE_INITIALIZE_FLAG	13	0x2000 (8192)
AFTER_SWAP_FLAG	6	0x0040 (64)
BEFORE_SWAP_RETURNS_DELTA_FLAG (not used)	3	0x0008
AFTER_SWAP_RETURNS_DELTA_FLAG	2	0x0004 (4)

This hook sets exactly three bits: 13 (beforeInitialize), 6 (afterSwap), 2 (afterSwapReturnDelta), giving a required low-14-bit value of 0x2044 (8260 decimal). The deploying party must mine a CREATE2 salt (via HookMiner, as the imported v4-hook-generator guidance notes) so the hook's deployed address carries exactly these bits — not a superset, not a subset, since PoolManager calls exactly the callbacks the address advertises and the protected test suite checks address bits against getHookPermissions() directly. No beforeSwap, liquidity, or donate callback is enabled: the hook never gates or front-runs a swap, which keeps it out of the HIGH/CRITICAL beforeSwap and beforeSwapReturnDelta risk classes in the security reference.

The band. Store lastAttestedPrice (seeded at pool initialization from the launch price) and a 5-slot ring buffer of post-swap prices read via StateLibrary.getSlot0. On every afterSwap, write the new price into the buffer and take the median of the last 5 (an odd count, so "median" is unambiguous and cannot be forced to the mean of two manipulated extremes). If |median − lastAttestedPrice| / lastAttestedPrice ≥ 1000 bps (10%), the band has been left.

Why 10% and not something closer to the swarm's own 20%: the brief's own incident is that a feed with a 20% single-update cap stalled when IMD moved 44.6% in a day, because once spot is more than 20% away from the last accepted value, every subsequent attempt to catch up is itself rejected by the same 20% cap, forever. If the trigger fires at a narrower 10%, spot can never get more than roughly 10% past the trigger before a request is already in flight to true it up, so the swarm is never asked to certify a jump bigger than its own ceiling can carry in one attestation. This is the brief's own stated mechanism (band narrower than the swarm's cap "means the feed is never asked for a jump it cannot take") and is the central reason this design exists.

Cooldown and the single-in-flight lock. Two separate guards, not one:

• Cooldown (900s, 15 minutes): no new request may be sent before lastTriggerAt + 900s, regardless of how many times the band is crossed in between. The swarm answers "in minutes, not blocks" (per the brief), so 15 minutes gives headroom above the expected turnaround before the hook would even consider asking again.
• In-flight lock (requestPending, cleared after 1800s): set the moment a request is sent, independent of the cooldown. Because the consumer of the Intake callback is the separate Feed contract (see §4), the hook itself never learns synchronously whether a request succeeded, failed, or was refused — Intake's delivery is best-effort and cannot be retried, and a dropped delivery must not permanently wedge the trigger. The lock therefore self-clears on a timeout (double the cooldown) rather than waiting for a signal that may never arrive. Any address may call a permissionless clearStalePending() once the timeout has passed, so the hook's own afterSwap gas is not spent re-checking a stale lock on every swap.

Both guards are evaluated before spending anything; a swap that happens to cross the band while either guard is active simply emits TriggerSuppressed and proceeds normally — the oracle logic never reverts a swap.

Gas, and who bears it. A non-triggering swap costs one warm SLOAD/SSTORE to the ring buffer plus a comparison — on the order of 5,000–10,000 gas. A triggering swap additionally redeems the ERC-6909 claim for real IMD (~20,000 gas), pays Intake (~25,000–45,000 gas), and calls Intake.ask (~2,600 base plus Intake's own unmeasurable execution). A derived, hypothetical estimate — not an observed one, since the contract has not run against a live network — is 100,000–150,000 extra gas: cents to a few dollars depending on gas price. The swapper whose trade crosses the band bears this. A rebate was considered and rejected: refunding gas means disbursing native ETH from the hook, reopening the NativeTransferFailed failure mode the IMD launch guidance already warns against (a pool seeded with tokens only holds no ETH to rebate from), for a benefit — a few cents — too small to justify a second funds-custody path. Minting a claim instead of ETH was also rejected: most swappers would never bother claiming an amount that small, for no change in actual economic burden. This is a judgment call, not a safety requirement, and is listed again in Open Questions.

2. Funding: which fee, which currency, and no unsafe internal swap

Which fee, which currency. The hook does not touch the pool's LP fee (fixed by launch policy at 500/3000/10000 bps, never dynamic, never zero, per the IMD launch rules already given). Instead it takes a small additional skim via afterSwapReturnDelta — the same mechanism the imported v4-hook-generator guidance calls out for BaseHookFee/BaseDynamicAfterFee hooks — but only when the swap's output currency is already IMD. Concretely: if the pool is IMD/X and the swap's unspecified (output) currency is IMD, the hook takes 5 bps of that output as its skim; if the output currency is X, the hook takes nothing on that swap. This halves the effective skim rate relative to skimming every swap, but it is the direct way to satisfy "becomes the request currency without swapping inside the hook": the reserve is built exclusively from currency that is already IMD, so no conversion step — and no price exposure, slippage, or MEV surface from a forced on-hook swap — ever exists. The skimmed amount is minted as an ERC-6909 claim (PoolManager.mint, the pattern the IMD launch guidance requires for any fee paid out of a swap, since a freshly-seeded pool or a contract recipient that rejects ETH would otherwise make every fee-bearing swap revert with NativeTransferFailed). The claim is redeemed for real IMD only at the moment a request actually fires, via PoolManager.take, inside the same unlocked context the swap is already running in — legal because the manager is unlocked for the whole transaction, the same reasoning the currencySettler pattern relies on.

Per-request and per-day caps. Per-request spend is fixed by Intake's own price — 0.5 IMD, stated in the brief as ≈ $4.25 (an ASSUMPTION: this report has no live IMD/USD price feed to confirm $4.25 as of 2026-10-05, and takes the figure only as given). If the reserve holds less than 0.5 IMD when a trigger condition is met, the hook emits RequestSkippedInsufficientReserve and does not revert the swap; funding resumes organically as more IMD-side swaps accrue skim. The daily cap is a hard ceiling of 20 requests per rolling 24 hours (≤ 10 IMD/day, ≈ $85/day on the brief's own figure), tracked by a simple day-bucket counter reset on the first trigger after dayStart + 86400s. This bounds the absolute worst case — a reserve drained by a sustained, repeated band-crossing attack — independently of whether the cooldown alone would have been sufficient (§3 argues it usually is, but caps should not depend on that argument holding in every market condition).

3. Manipulation: pricing the attack against pool depth and the request fee

The attack. Push spot across the 10% band to make the reserve pay for a request it would not otherwise need. The attacker's objective could be pure griefing (drain the reserve, starve future real triggers) or an attempt to bias what gets attested. The second objective fails structurally: the swarm's univ4-spot recipe is chain-evidence, re-run by the signer over the attested [fromBlock, toBlock] window with 1–61 samples, not a single point — a price manipulated for one block and then arbitraged back does not survive being re-sampled across a window the attacker does not control the end of. What remains is the griefing objective, and that is a cost/benefit comparison.

Pricing it. For a constant-product-shaped pool of depth L, moving the quoted price by a factor k = 1.10 requires a trade changing reserves by approximately √k − 1 ≈ 4.9% of pool depth; round-tripping that move (push, then revert or push back to avoid a free arbitrage) costs roughly the LP fee twice plus a slippage loss on the order of L·(√k−1)²/√k. For a hypothetical pool with $500,000 of depth and a 30 bps fee tier — plausible, not observed — that round trip costs on the order of $5,000–$10,000, against the 0.5 IMD (~$4.25) request it forces the reserve to pay: roughly three orders of magnitude of asymmetry against the attacker. The attack is only cheap at very thin depth (under, say, $5,000 of liquidity), which is exactly the regime the daily cap exists to bound regardless of the economics above.

What makes it uneconomic, concretely:

• Cooldown turns "cost per band-crossing" into "cost per cooldown window, at most once." An attacker crossing the band 100 times inside one 15-minute window forces exactly one request, not 100 — the cost of the crossings (slippage, fees) stays constant while the cost forced onto the reserve is capped at 0.5 IMD per window.
• Median-of-5 means a single flash-style spike and revert within one swap does not move the trigger reading at all — it takes five separate settled swaps at the elevated price to shift the median, which costs roughly five times the slippage of a single swap of the same size (depth resets partially between swaps unless the attacker holds the position across all five, which ties up capital for the duration). This is a partial, not complete, defense: a single transaction that issues five swaps through a multicall router still only pays gas once and can fill the buffer in one block, so median-of-5 raises the bar against naive single-swap spikes without fully closing the single-transaction case. A time-weighted reading (e.g., requiring the band-crossing median to persist for a minimum number of blocks, not just swaps) would close this gap at the cost of slower response to genuine fast moves, and is noted as a tunable alternative rather than adopted outright, since the brief's own motivating incident was a feed that moved too slowly.
• The daily cap is the backstop when the above two are insufficient — e.g., in an illiquid pool where round-tripping is cheap — bounding absolute loss to 10 IMD/day no matter how the attack is shaped.

4. The attestation feed: question binding, deviation handling, and failure modes

What it updates. A small, separate Feed contract — not the hook itself — is the thing other protocols integrate against. Separating it from the hook means the feed's read interface is stable even if the hook that funds it were ever redeployed, and it means the feed's security does not depend on trusting whoever triggers a request: anyone may deliver a validly-signed attestation to it (see below), so Intake's own good behavior is not a prerequisite for the feed to work.

Question binding. At construction, Feed pins QUESTION_PREFIX_HASH = keccak256(abi.encode( "univ4-spot", POOL_MANAGER, POOL_ID, SAMPLES, INVERT)) as an immutable — every field fixed at deploy time, since POOL_ID is itself fully determined by constructor-time constants (the hook's own address, the launch token address, and the policy-fixed fee/tick-spacing), so no post-deploy wiring call is ever needed. An incoming attestation's questionHash must equal keccak256(abi.encode(QUESTION_PREFIX_HASH, att.fromBlock, att.toBlock)) — the pinned prefix with only the signed block window spliced in, exactly the "recurring consumer" pattern the brief describes. This is the defense against the brief's own warning that "anyone can buy a signed answer to a different question addressed to your contract": a validly-signed attestation answering a different pool, a different recipe, or even the same recipe on the same pool but samples/invert set differently, fails this check and is rejected regardless of signature validity.

Monotonic block window. att.toBlock must strictly exceed the stored toBlock — the brief's explicit requirement that a recurring consumer "must also require toBlock to advance." This is the sole staleness/replay defense; an old (but not yet expired) attestation cannot be re-submitted to roll the price backward.

Signer and quorum. The recovered signer from the EIP-712 signature (domain name "IdentityMD Oracle", version "2", chainId = block.chainid, verifyingContract = address(this) — read from EIP-712's own specification, which is where verifyingContract and the domain-separator construction keccak256("\x19\x01" ‖ domainSeparator ‖ hashStruct(message)) come from) must equal the fixed constant 0x5598aa9146215bc13eb26f2c692ad1461fd32982. agreed must equal panelSize for this chain-evidence recipe class — the expectation that a deterministic re-run recipe produces full panel agreement, not a vote, and a result short of full agreement signals a configuration problem worth rejecting rather than tolerating. answerType must equal the pinned univ4-spot identifier; panel-class evidence (voted, not re-run — the brief's own example of a panel answer wrong by 256×) is never accepted by this feed regardless of signature or agreement, because this feed only ever asks univ4-spot questions in the first place.

Deviation handling — deliberately not a tight cap. This is the one place this design must not imitate the feed that motivated it. The incident described in the brief is a feed whose own deviation cap (20%) rejected the update it most needed, because the market had already moved 44.6% past the last accepted value. Feed therefore carries only a wide sanity ceiling of 9000 bps (90%) per single update — not a normal operating constraint, a last-resort rejection of data so far off that it is almost certainly a corrupted or miscomputed answer rather than a real move. The ceiling is set above any plausible single-attestation move (the 44.6%/day incident itself is less than half this ceiling) specifically so that the fix for the old bug does not reintroduce the same bug at a different threshold. The hook's 10% trigger band (§1) is unrelated to this ceiling and must not be confused with it: the trigger band decides when to pay for a fresh attestation; the sanity ceiling decides whether to believe an attestation once bought. Collapsing the two into one number is precisely how a feed ends up unable to catch up.

Reading the feed. Downstream protocols call a latestRoundData()-shaped view returning the figure, issuedAt, expiresAt, and the attested block window, and are expected to apply their own staleness check against expiresAt — the feed is pull-style and event-driven, not clocked, so a consumer cannot assume a maximum age the way it could against a fixed-heartbeat feed.

Delivery failure and panel refusal. Intake's delivery is best-effort with a 200,000-gas callback budget and no retry. If delivery never arrives, Feed's stored price simply stays at its last value (stale but available) and the hook's lock self-clears by timeout (§1), allowing a fresh attempt after the cooldown. If the plane calls back with a refusal or failure status rather than a successful attestation, the submission path (below) simply does not update state — no special-cased "failure" storage is needed, since the only effect of a non-delivery or a refusal is that toBlock does not advance, which is already the state the feed was in. A panel refusal therefore costs the reserve the 0.5 IMD already spent and nothing else; it is visible externally only as a gap in PriceUpdated events relative to TriggerArmed events, which is enough for monitoring.

Delivery mechanism, and the HTTP-door alternative. Feed exposes one permissionless function, submitAttestation(Attestation calldata, bytes calldata signature), that performs every check above regardless of caller. It is intentionally not gated by msg.sender, because the signature and question-binding checks are the entire security boundary — the caller's identity adds nothing. Against the proposed Intake, the hook calls Intake.ask(...) naming Feed as consumer; Intake's writer later calls back a target — this report assumes that target implements onIntakeComplete(requestId, status, resultHash, uri, args) and forwards args (the encoded attestation and signature) into the same internal check submitAttestation uses, since Intake's own calldata shape is not published (flagged in Open Questions). If only the HTTP door exists — Intake is, per the brief, "proposed, not yet on mainnet" — the hook cannot call it at all. What changes: the hook's _tryTrigger step is replaced by emitting TriggerArmed only (still gated by the same band, cooldown, lock, and daily cap, so the signal is rate-limited even though no payment happens on-chain); an off-chain keeper watching that event calls the oracle.request HTTP endpoint, fronts the 0.5 IMD, and relays the returned signed attestation into the same submitAttestation — nothing in Feed's verification changes. What is lost is exactly the part of the brief's thesis that a hook can replace the off-chain watcher: with only the HTTP door, a watcher is still required, just one that no longer decides when (the hook still does that) but still must exist to act. Reimbursing that keeper's fronted 0.5 IMD from the reserve is a mechanism this report does not specify, since it depends on Intake's eventual design, and is listed in Open Questions.

5. Comparison with existing on-demand and volatility-triggered designs

Design	Trigger	Who pays	Latency	Manipulation resistance	Source (read 2026-10-05)
Chainlink Data Feeds	Deviation threshold (typically 0.5–2%) or fixed heartbeat (e.g. 1h for ETH/USD), whichever fires first	DON operator, off-chain	Sub-minute once triggered	Threshold is tight (≤2%), by design — this is the mechanism the brief's incident shows failing when a single move exceeds it before the next round	Chainlink Data Feeds: Rates & Volatility Feeds
Pyth pull/on-demand	Pure pull: updates exist off-chain continuously; on-chain state updates only when a consumer pays to pull	The consumer requesting freshness, per pull	Off-chain feed ~400ms; on-chain only on demand	No deviation logic at all — it is a bandwidth/cost control, not a manipulation control	Pyth: Pull Oracles vs. Push Oracles
API3 OEV	Opportunity-triggered: a searcher pays to win the right to execute a beneficial update via sealed-bid auction	The winning searcher, who recoups via the MEV the update exposes	Update happens exactly when it is profitable to	Converts update-timing MEV into auction revenue returned to the dApp; not a volatility trigger	API3: OEV Searchers overview
Uniswap v3/v4 TWAP	None — continuously accumulated on every swap, queried on demand	Nobody; cost is amortized storage on swaps, free to query	Always available, but inherently lagging over the averaging window	Manipulation cost scales with pool depth and the averaging window, but the oracle is only as good as its own pool's liquidity — no external truth source	Uniswap v3 TWAP: accumulation and querying
This design	Volatility-triggered (band narrower than the answer's own jump ceiling), evaluated by the pool itself on every swap	The pool's own reserve, funded by a skim of its own fee revenue	Request "minutes, not blocks" per the swarm's own SLA, then instant on delivery	Cost scales with pool depth and round-trip slippage per forced request, plus cooldown/cap bounding request count; delivered answer is chain-evidence re-run over a block window, not a single point	This report

No existing design in this table combines a volatility trigger (Chainlink's idea) with the trigger being evaluated by the pool's own hook rather than an external operator (closer to TWAP's self-containment) and the request being paid for from the pool's own fee revenue rather than by a consumer-side pull (Pyth) or a searcher's auction bid (API3 OEV). That combination — not any single piece of it — is this design's actual novelty; each individual piece is one existing design's idea applied in a new place.

Contracts

Three contracts, inside the launch's four-contract budget, deployed with every link made at construction and no call made by the launch after deployment. TOKEN is standalone; SpotTriggerHook's constructor deploys SpotFeed as its child, so the parent/child rule in the brief is used exactly once and the fourth contract slot is left unused — fewer moving parts to audit is worth more here than using the full budget. IIntake is an external interface only: the upstream contract is not deployed yet, so its address and ask signature below are ASSUMPTION, built from the brief's description, not a published ABI (see Open Questions).

IdmLaunchToken (standard ERC-20 launch token)

• Purpose: the launch's fungible token; exists only to satisfy Token.protected.t.sol and carry no privileged path, matching the "no mint path after launch" floor the protected tests assert.
• Constructor: constructor(string memory name_, string memory symbol_) — mints the entire policy supply (a fixed constant, not a constructor argument) to msg.sender (the launch factory) in the same call, then locks: no stored minter role exists at all.
• Storage: standard ERC-20 balances/allowances/totalSupply only; no owner, no pause, no proxy slot.
• External functions: the standard ERC-20 surface (transfer, transferFrom, approve, balanceOf, totalSupply, decimals) and nothing else — no mint, no setOwner, no upgradeTo.
• Events: standard Transfer/Approval only.
• Invariants a test must hold: total supply never changes after construction; no selector on the contract increases any balance other than through transfer/transferFrom debiting another balance by the same amount; balanceOf(deployer) == totalSupply() immediately after construction.

SpotTriggerHook (the Uniswap v4 hook)

• Purpose: watches its own pool's price on every swap, skims IMD-denominated fee revenue into a reserve, and buys a fresh attestation from Intake the moment spot leaves the trigger band, subject to cooldown, an in-flight lock, and a daily cap.
• Constructor: constructor(IPoolManager poolManager_, address token_) — poolManager_ is written "$poolManager" and token_ is written "$token" in the launch manifest, per IMD launch convention; both are ordinary constructor arguments, not privileged constants, since they are infrastructure addresses the deployer fills in, not addresses that gate access. Inside the constructor: compute the canonical PoolKey from poolManager_, token_, the fixed FEE_TIER and TICK_SPACING constants, and address(this) as hooks; derive POOL_ID; deploy feed = new SpotFeed(poolManager_, POOL_ID, address(this)). INTAKE and IMD (the request currency's token address) are hardcoded constants in source, never constructor arguments — per the rule that every privileged address is fixed in source.
• Storage: IPoolManager public immutable POOL_MANAGER; PoolId public immutable POOL_ID; SpotFeed public immutable FEED; uint256 public lastAttestedPrice; uint256[5] public priceHistory; uint8 public historyIndex; uint256 public lastTriggerAt; bool public requestPending; uint256 public pendingSince; uint256 public requestsToday; uint256 public dayStart.
• External functions:
  • getHookPermissions() external pure returns (Hooks.Permissions memory) — anyone may call; returns the three-flag permission set from §1.
  • beforeInitialize(address, PoolKey calldata key, uint160) external returns (bytes4) — only PoolManager; reverts unless key.fee is one of the policy's listed tiers; returns the selector.
  • afterSwap(address, PoolKey calldata, SwapParams calldata, BalanceDelta delta, bytes calldata) external returns (bytes4, int128) — only PoolManager; updates the ring buffer; if the unspecified currency of this swap is IMD, mints a 5 bps claim on the output via PoolManager.mint and returns that amount as the hook's take of the delta; evaluates the trigger condition and, if armed, calls _tryTrigger() internally.
  • clearStalePending() external — anyone; requires requestPending && block.timestamp > pendingSince + 1800; clears the lock.
• Events: FeeSkimmed(uint256 amount); TriggerArmed(uint256 median, uint256 lastAttestedPrice); RequestSent(bytes32 requestId, uint256 cost); RequestSkippedInsufficientReserve(); RequestSkippedDailyCap(); PendingCleared().
• Invariants a test must hold: every external callback reverts for any caller other than POOL_MANAGER; requestPending can only be true if block.timestamp ≤ pendingSince + 1800; at most one Intake.ask call occurs per 900-second window; requestsToday ≤ 20 within any rolling 24 hours; afterSwap never reverts due to oracle logic (a failure inside _tryTrigger must be caught and degrade to a skipped-request event, never a reverted swap); the sum of IMD claims the hook holds only increases by skimmed amounts and only decreases by amounts spent on Intake.ask; getHookPermissions() bits match the deployed address's bits (the protected floor already asserts this — restated here because every change to this contract must keep it true).

SpotFeed (the price feed other protocols read)

• Purpose: the sole on-chain record of this pool's swarm-attested price; verifies every attestation independently of who delivers it.
• Constructor: constructor(IPoolManager poolManager_, PoolId poolId_, address hook_) — called only from SpotTriggerHook's constructor, so poolManager_ and poolId_ are already the real, correct values by construction, not re-derived. Computes and stores QUESTION_PREFIX_HASH immutably. SIGNER (the fixed service key) is a hardcoded constant in source, never a constructor argument.
• Storage: IPoolManager public immutable POOL_MANAGER; PoolId public immutable POOL_ID; address public immutable HOOK; bytes32 public immutable QUESTION_PREFIX_HASH; uint256 public price; uint256 public fromBlock; uint256 public toBlock; uint256 public issuedAt; uint256 public expiresAt; bytes32 public lastRequestId.
• External functions:
  • submitAttestation(Attestation calldata att, bytes calldata signature) external returns (bool accepted) — permissionless; recovers the signer via EIP-712 over the fixed domain and requires it equal SIGNER; requires att.questionHash == keccak256(abi.encode(QUESTION_PREFIX_HASH, att.fromBlock, att.toBlock)); requires att.answerType == ANSWER_TYPE_UNIV4_SPOT; requires att.toBlock > toBlock; requires block.timestamp < att.expiresAt; requires att.agreed == att.panelSize; requires the deviation of att.figure from price to be within 9000 bps unless price == 0; on success, updates all stored fields and returns true, emitting PriceUpdated; on any failed check, returns false and emits AttestationRejected rather than reverting, so a rejected delivery is still visible on-chain.
  • onIntakeComplete(bytes32 requestId, uint8 status, bytes32 resultHash, string calldata uri, bytes calldata args) external — the assumed Intake callback entrypoint; decodes args into (Attestation, bytes) and forwards to the same internal logic submitAttestation uses, when status indicates success.
  • latestRoundData() external view returns (uint256 answer, uint256 updatedAt, uint256 fromBlock_, uint256 toBlock_, uint256 expiresAt_) — the read surface other protocols integrate against.
• Events: PriceUpdated(bytes32 requestId, uint256 price, uint256 fromBlock, uint256 toBlock, uint256 issuedAt, uint256 expiresAt); AttestationRejected(bytes32 requestId, string reason).
• Invariants a test must hold: price changes only inside a call whose recovered signer equals SIGNER; toBlock is strictly increasing across every accepted update; an attestation whose questionHash does not match this pool's pinned prefix is rejected even when validly signed by SIGNER for a different question; SIGNER, POOL_ID, and POOL_MANAGER have no setter; submitAttestation never reverts on a merely-invalid attestation (only on malformed calldata), so repeated rejected submissions cannot be used to grief gas estimation for other callers; a single accepted update's deviation from the prior price never exceeds 9000 bps.

IIntake (external interface only — not deployed by this launch)

interface IIntake {
    struct AskParams {
        address consumer;
        uint256 chainId;
        bytes32 questionHash;
        bytes32 answerType;
        uint256 fromBlock;
        uint256 toBlock;
        uint256 payment; // 0.5 IMD, in IMD's own decimals
    }

    function ask(AskParams calldata params) external returns (bytes32 requestId);
}

interface IIntakeConsumer {
    function onIntakeComplete(
        bytes32 requestId,
        uint8 status,
        bytes32 resultHash,
        string calldata uri,
        bytes calldata args
    ) external;
}

Foundry test plan

Unit and integration tests (beyond the protected floor, which already covers permission/address agreement, caller restriction, and runtime-code hygiene):

1. test_afterSwap_updatesRingBufferOnEverySwap — non-triggering swaps still advance the median buffer.
2. test_afterSwap_skimsOnlyWhenOutputIsImd — a swap whose output is the non-IMD leg mints zero claim; a swap whose output is IMD mints exactly 5 bps of it.
3. test_trigger_firesOnceAtTenPercentBand — a sequence of swaps crossing 10% fires exactly one RequestSent.
4. test_trigger_suppressedDuringCooldown — a second band crossing inside 900s after a trigger emits TriggerSuppressed, not a second RequestSent.
5. test_trigger_suppressedWhilePending — a band crossing while requestPending is true and within the timeout does not fire, even past cooldown.
6. test_pending_clearsAfterTimeout — clearStalePending succeeds only after 1800s and only while requestPending is true.
7. test_trigger_skipsOnInsufficientReserve — band crossed with reserve below 0.5 IMD emits RequestSkippedInsufficientReserve, swap does not revert.
8. test_dailyCap_enforced — the 21st qualifying trigger inside 24 hours is skipped, not sent.
9. test_afterSwap_neverRevertsOnOracleFailure (adversarial) — a mock Intake that reverts on ask still allows the triggering swap to complete.
10. test_feed_acceptsValidAttestation — a correctly signed, correctly bound attestation updates price and advances toBlock.
11. test_feed_rejectsWrongSigner (adversarial) — a validly-shaped attestation signed by any key other than SIGNER is rejected.
12. test_feed_rejectsForeignQuestionHash (adversarial) — a validly-signed attestation whose questionHash answers a different pool/recipe, addressed to this Feed's address as verifyingContract, is rejected — the brief's own "different question" attack.
13. test_feed_rejectsNonAdvancingToBlock (adversarial) — a validly-signed attestation with toBlock ≤ the stored value is rejected, including a byte-identical replay of the last accepted attestation.
14. test_feed_rejectsExpiredAttestation (adversarial) — expiresAt ≤ block.timestamp at submission time is rejected.
15. test_feed_rejectsPartialAgreement (adversarial) — agreed < panelSize on a univ4-spot answer is rejected even when otherwise valid.
16. test_feed_rejectsPanelClassAnswerType (adversarial) — an answer with a different, non-pinned answerType is rejected regardless of signature validity.
17. test_feed_largeLegitimateJumpIsAccepted — a single update moving price 44.6% (the brief's own incident figure) and a second moving it 60% are both accepted, demonstrating the fix for the stalled-feed bug directly.
18. test_feed_rejectsAbsurdJump (adversarial) — an update implying a >9000 bps single-step move is rejected even when validly signed, modeling the brief's "panel wrong by 256×" caution.
19. test_feed_submitAttestationNeverRevertsOnInvalidData (adversarial) — every rejection path returns false and emits AttestationRejected rather than reverting, across a fuzzed set of malformed Attestation fields.
20. test_manipulation_roundTripCostExceedsForcedSpend (adversarial, economic) — simulate a 10% push-and-revert against a parameterized pool depth; assert slippage/fee cost exceeds 0.5 IMD at normal fixture depth, and does not necessarily hold at a deliberately thin fixture depth, documenting the daily cap as the backstop in that regime.
21. test_manipulation_singleTxFiveSwapsStillCapped (adversarial) — a single transaction issuing five swaps to fill the median buffer still produces at most one RequestSent and consumes exactly one daily-cap slot.
22. test_hook_onlyPoolManagerCanCallAfterSwapAndBeforeInitialize — restates the protected floor's check as a project-local regression test, since this file changes with the contract and the protected copy does not.

Risks, ranked by severity

1. Critical — the funding and delivery path depends on a contract that does not exist yet. Intake is, per the brief, "proposed, not yet on mainnet." Until it ships with a published ABI, the automated ask-and-receive loop is unimplementable against a real target; the HTTP-door fallback in §4 restores a human/keeper watcher, exactly the dependency this design sets out to remove. This risk dominates every other one below until resolved.
2. High — the IMD-only skim can silently starve the reserve. A pool where sell pressure into IMD is persistently light accrues skim slowly or not at all, and the failure mode is silent: no revert, no alarm, just a trigger that is perpetually reserve-insufficient, surfaced only by an event nobody is obligated to watch.
3. High — afterSwapReturnDelta is the correct tool for this skim, but it is the permission the security reference flags as the second-most dangerous class after the NoOp vector, since any accounting bug here can over- or under-settle the pool's own funds, not just the hook's reserve. It needs the heaviest audit attention of anything in this spec.
4. Medium — median-of-5 does not fully close the single-transaction case. A transaction issuing five swaps via a multicall router fills the buffer in one block at one gas cost, cheaper than five separately-timed swaps; the cooldown and daily cap still bound the damage, but the "costs five times as much" argument in §3 does not hold here.
5. Medium — no refund mechanism is specified for a request sent but never answered or refused. Since Intake delivery is best-effort with no retry, every dropped or refused request is a permanent 0.5 IMD loss with no recourse; under unreliable conditions this could exhaust the daily cap with zero successful updates.
6. Low — the triggering swapper's extra gas is unrebated. Cents to a few dollars, borne unevenly by whichever swap crosses the band; not a security risk, listed for completeness.
7. Low — poolId is computed from policy constants fixed at the time this spec was written. If the launch policy's allowed fee tiers change, a hook deployed under an old constant could compute a poolId that doesn't match what PoolManager actually initializes, silently pinning Feed to the wrong question — an integration-fragility point, not a code bug.

Open questions for the IdentityMD developer

1. What is the exact function signature and payment mechanism for Intake.ask — does the caller pre-approve and have Intake pull 0.5 IMD, or does the caller push payment in the same call — and what will Intake's deployed address be once it ships?
2. What is the exact calldata shape of the callback Intake's writer uses to invoke a consumer contract on complete — does it deliver the full signed Attestation struct and signature as args, or only a resultHash/uri that requires a separate off-chain fetch before verification is possible on-chain?
3. Is a refused or never-delivered request refunded, in whole or in part, from the 0.5 IMD already paid, or is that payment forfeit regardless of outcome?
4. For a chain-evidence recipe like univ4-spot, is full panel agreement (agreed == panelSize) actually guaranteed by the re-run design, or can a chain-evidence request legitimately return partial agreement that a consumer should tolerate rather than reject?
5. Does the univ4-spot recipe's samples parameter sample the attested [fromBlock, toBlock] window using archive/trace access to the pool's historical slot0, or does it require the pool to maintain its own stored observations (as a TWAP oracle would), which this hook does not currently do?
6. What is the IMD token's deployed address and decimals on the chain this launch targets, and is 0.5 IMD a fixed protocol parameter or one IdentityMD governance can change — which would affect whether the per-request and daily caps in §2 should be expressed in IMD or in a stablecoin equivalent?

Sources

• Uniswap v4-core, src/libraries/Hooks.sol — permission flag bit values. Read 2026-10-05.
• EIP-712: Typed structured data hashing and signing — domain separator fields and the signed-hash construction. Read 2026-10-05.
• Chainlink Docs: Rate and Volatility Feeds — deviation-threshold and heartbeat mechanism for push feeds. Read 2026-10-05.
• Pyth Docs: Pull Oracles vs. Push Oracles — pull/on-demand update economics. Read 2026-10-05.
• API3 Docs: OEV Searchers overview — OEV auction mechanism. Read 2026-10-05 (via search index; direct fetch of this URL returned 404 at the time of writing, so this citation relies on the search engine's indexed summary of the page rather than a direct page fetch).
• Uniswap v3 Development Book: Price Oracle — TWAP accumulator mechanics and manipulation-resistance trade-offs. Read 2026-10-05.
• Assignment brief (this task) — all IdentityMD-plane specifics: the Intake contract, the service signer address, the 0.5 IMD / ≈$4.25 request price, the EIP-712 domain name/version, the univ4-spot recipe, and the 44.6%/20% incident figures. Not independently verifiable by this report; treated as given and marked ASSUMPTION throughout where this report extends beyond what the brief states directly.