The README parameter table ('opening tick 129,000 +/- 300') and the launch brief ('refuses an opening tick more than 300 from 129000, and it is the single gate on all of it') both state that beforeInitialize refuses an opening price outside the tolerance. The constants LAUNCH_TICK (line 78) and LAUNCH_TICK_TOLERANCE (line 79) exist but nothing reads them: line 272 converts the price to a tick only to emit it in Launched.

The factory, or any price the policy resolves to, opens the pool at any tick. The brief is internally inconsistent (it also says 'It does not gate the opening price'), and the hook's own comment at lines 73-77 says the gate was removed deliberately after launch 1405; this is reported so the adapter and the requester settle which statement is the design, rather than ship a README and brief that promise a check the bytecode does not make.

If the policy's 2,500 IMD cap is the guarantee, the README table should say so; if the hook is meant to be the gate, the check is missing.

Scope: read in full as imported, before adaptation: src/pimd/PimdToken.sol (49 lines), src/pimd/PimdHook.sol (555), src/pimd/PimdEngine.sol (880), src/libraries/L2Block.sol (21), script/DeployPimd.s.sol (118); skimmed script/PimdRehearsal.sol, script/RehearsalSeeder.sol, script/RehearsePimd.s.sol and the test suite (86 local tests pass).

Reached on chain (Robinhood Chain 4663, robinhood-rpc.publicnode.com): the engine at 0xFFDB5Dd341F692a29b5a0d3D1577DF683C1bACa4, whose runtime bytecode is byte-identical to the compiled PimdEngine outside its 960 immutable bytes, and whose getters read poolManager 0x8366a39CC670B4001A1121B8F6A443A643e40951, imd 0x5F7Bb59365ce557C26dbcAa4EE9d39A4b95B7127, team = binder = 0x0960E8Bd80462e3842Bb6620c7C5289A44c4559B, bound false, drip 150 bps, minInterval 900, minBalance 1e24, fireTip 5e16, tipPerHolder 3e15, maxCatchup 21600, maxHolders 700, both script keepers enabled; the live PoolManager answers exttload on the engine's IS_UNLOCKED_SLOT, which equals keccak256('Unlocked')-1.

Not reached: the launch factory ($factory is resolved at launch and is not in this tree), so whether it calls modifyLiquidity directly from its own address, makes exactly one positive add, and performs no swap in the initialize block is assumed, not verified; the IMD token's source (only its code presence was checked); v4-core and v4-periphery are trusted as vendored.

Every fee calculation assumes IMD is currency0, so beforeInitialize requires currency1 == PIMD (line 259) and currency0 == IMD (line 262). The PoolManager requires currency0 < currency1. If the token address the factory deploys is numerically below IMD (0x5F7Bb593...), the only key the PoolManager accepts has PIMD as currency0 and is refused by line 259, and the key the hook wants is refused by the PoolManager with CurrenciesOutOfOrderOrEqual.

Nothing in this tree influences the token address: the token takes no constructor argument and the factory deploys it with plain CREATE; the CREATE2 salt mining exists only in test/pimd/PimdBase.t.sol and script/PimdRehearsal.sol. The probability that a uniformly distributed address sorts below 0x5F7B... is about 0x5F7B/0xFFFF = 37%. The README acknowledges this as 'a retry condition'.

It is reported because a paid launch whose pool can never open is a broken launch, and the adapter must either secure the ordering at the factory (salt or retry) or accept that roughly one launch attempt in three is lost.

The hook pushes 75% of every tax to the constant ENGINE_ADDRESS unconditionally (flush/flushHolders).

Which token's balances that IMD is dripped by is set after deployment by bind(), callable once by binder, which on the live engine is the team wallet 0x0960E8Bd80462e3842Bb6620c7C5289A44c4559B (bound == false today). bind validates hook_ only through four getters it calls on hook_ itself (lines 286-289), so any contract the binder writes passes, and token_ is then whatever that contract returns.

The binder may also pass alsoExclude, which marks arbitrary addresses as never payable with no way to reverse it.

The launch reference lists 'anything configured after deployment rather than in a constructor' as a medium for the adapter; here it cannot be removed because the engine is already deployed and is not to be redeployed, so it must be recorded as a trust assumption on the team wallet: the party that receives the 25% slice also holds a one-shot power over the 75% slice. Two concrete states follow.

(a) Before bind, every fire() reverts NotBound while flush() keeps delivering IMD to the engine; nothing but bind can ever release it (no owner, no rescue). (b) A bind to a binder-controlled token sends every future drip to holders of that token. Scratch test test/scratch/ZZBindTrust.t.sol reproduces (b): after binding a FakeHook whose token() is BinderCoin, one epoch over a 1,000 IMD pot paid 113.89 IMD to the BinderCoin holder.