QuestionBuilder.build hard-codes validForSeconds 900 into every request body, so the oracle signs expiresAt = issuedAt + 900.

CabalGate.onOracleResult (src/CabalGate.sol:282) reverts InvalidAttestation when a.expiresAt <= block.timestamp, and the Intake delivers each result once under a try with no retry (docs/ORACLE.md, oracle-consumer skill), so any delivery landing 15 minutes or more after the attestation was issued is lost: the 0.5 IMD already pulled at submission is spent, the request stays Pending until the one-hour deadline, and the user cannot submit another request meanwhile (activeRequest).

A delivery that lands late but inside the window also shrinks the execution window: r.approvedUntil = min(now + 300, a.expiresAt) (line 297), so a result delivered 14 minutes after issue leaves 60 seconds to execute.

The gate already bounds approvals to five minutes and MAX_VALIDITY to one day, so a longer validForSeconds costs nothing in security; 900 only adds a failure mode that is outside both the user's and the owner's control, because the constant is not owner-settable (every other oracle parameter is). Observed live latency was 64 to 85 seconds from request creation to attestation for recent requests, so this is a margin problem on a congested mainnet day, not an observed failure.

Not a code defect; a launch-state fact the adapter and owner should know before the manifest's limits go live.

Read from mainnet at block 26145229 through the live hook 0xf41b6ff942a082c0d320a0c151310ac2a922a0c0: pool (CABAL 0x450e5910..., IMD 0xd34a99bc..., fee 12500, spacing 60) sits at tick -128999 (2.5e-6 IMD per CABAL) with zero active liquidity; the only initialised tick above is -128940 with liquidityNet 1427203723558688610055083, i.e. a single-sided CABAL seed, and nothing is initialised below.

With the manifest's maxImpactBps = 300 the gate's estimate (which counts the 59 bps empty gap as movement) returns 68 bps for a 1 IMD buy, 272 bps for 25 IMD, 873 bps for 100 IMD and 5182 bps for 1000 IMD, so submitBuyRequest reverts LimitExceeded above 28.35 IMD while maxBuyAmount is 1,000,000 IMD. estimateImpact(false, x) returns 10000 for every sell until a buy has moved the price into the seed and the hook has placed its IMD position below it, so every submitSellRequest reverts LimitExceeded at launch.

With maxDriftBps = 500, two approved 25 IMD buys executed ahead of a third approval move the price 479 bps (the approval still executes); three strand it (LimitExceeded) and its 0.5 IMD is spent. All of this is owner-adjustable later through configure, which also invalidates every pending approval.

forge build --sizes with the pinned profile (0.8.26, via-IR, 200 runs, bytecode_hash none) gives CabalGate runtime 23,630 bytes and init code 36,645 bytes (the init code carries QuestionBuilder and ImpactEstimator creation code, 5,913 and 4,171 bytes). The protected floor refuses runtime above 24,576 and init code above 49,152 bytes.

Replacing the Config struct parameter with thirteen flat arguments changes only constructor code, which lives in the init code, so the runtime should be unchanged, but any extra public getter or validation added to the runtime has 946 bytes of room.

The runtime opcode scan used by the protected test (skipping PUSH immediates) finds no DELEGATECALL, CALLCODE or SELFDESTRUCT in CabalGate, QuestionBuilder, ImpactEstimator or CabalHook; the existing test_runtimeSizeAndNoEscapeHatches scans only the hook's opcodes and only the gate's size, so the adapter should extend it to the gate's opcodes.

The constructor calls launchHook.initialized(), poolManager(), cabal(), poolKey() and, through _configure (line 187), hook.imd(), and requires cfg.intake.code.length and cfg.imd.code.length to be nonzero. On a chain where 0xf41b6ff9... has no code, the high-level call reverts and the factory's CREATE2 returns zero, which the protected probe reports as 'application constructor failed'.

Verified live at block 26145191: the hook's runtime is byte-identical to the local CabalHook build after masking its two immutables; initialized() is true, gate() is zero, imd() is 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 (matches the manifest's fourth argument), cabal() is 0x450e5910DEcEe15c3AC056E3ed66Cb5ea3Dd33BE whose runtime is byte-identical to CabalCoin with totalSupply 1e27, owner() is 0xFc3C962FAD2C1cC77f1a0d46e7B8a2De79A21774 (an EOA, the owner the launch notes name) with no pending owner, poolManager() is 0x000000000004444c5dc75cB358380D2e3dE08A90, and the pool key is (CABAL, IMD, 12500, 60, hook).

The Intake 0x1397434c... has code, priceOf(action, IMD) = 0.5 IMD, callbackGas 200000, MAX_BODY_BYTES 16384; IMD has 18 decimals, no EIP-1967 implementation slot and no paused()/blacklist selectors; the identity NFT answers balanceOf for about 3,500 gas, inside the 30,000 stipend. All thirteen manifest arguments pass _configure's validation. The hook's setGate accepted a gate built from this source and refused a second one on the fork.

Documented design, listed so the adapter and the audit panel see the concrete reach of the owner key (0xFc3C962F... via $owner). (1) configure(signer = K) or configure(intake = C) where the owner controls K or C: from the next version, an attestation signed by K, or a callback from C carrying one, approves any request, so the owner can self-approve trades up to maxImpactBps 5000 and amounts up to int128.max; the pool price and the user's own minimum output still apply.

(2) configure(maxBuyAmount = 1, maxSellAmount = 1) stops every new submission above one wei: trading pauses without any pause flag. (3) Every accepted configure increments configVersion; _execute requires r.version == configVersion, so all Approved and Pending requests of users become unexecutable, their 0.5 IMD oracle fee is already spent, and clearRequest is the only exit. Ownership is two-step; renounceOwnership freezes the configuration permanently.

None of these is a permission bypass; they are the owner's intended reach.