The requester asked for exactly this (no time-based fallback), so this is recorded as the trust assumption it is, with the concrete states that trigger it. released can only become true through InkVault.release(), which needs statsRoot set by setup(), which needs setInk(), which reverts NotFunded unless the vault already holds SEATS * PORTRAIT = 800,000,000e18 INK (src/InkVault.sol:164 and :178).

The launch draft sends 80% of supply to the vault via remainderTo, so supply must be exactly 1,000,000,000e18 (the figure the tests assume) or more; any smaller supply, a remainderTo that is not the live vault, or the single owner EOA 0x824E…06E3 never calling setInk/setup (or losing its key) leaves released == false permanently.

Every swap on the hook's pool then reverts TradingNotOpen forever; the factory-seeded single-sided INK position and any later deposits are untradeable, and the hook has no owner to intervene. There is also no way to re-point the hook at another vault. The adapter should verify the token supply/allocation against the 800M requirement before deploying.

Documented in the hook's own comment, so this is a design tradeoff rather than a defect, but the adapter and reviewers should know its concrete shape. The waiver is meant for "wallets holding an agent portrait".

Because the check reads tx.origin, (a) a bundler, relayer, aggregator operator or MEV searcher whose sending EOA holds one agent portrait (a 400,000 INK pull, or a marketplace purchase) pays no hook fee on any swap routed through its transactions, including swaps executed for third parties who hold nothing, so the 0.25% fee can be sold as a service; (b) ERC-4337 and multisig wallets that hold agent portraits never get the waiver because tx.origin is the bundler/relayer; (c) the one-block holding requirement (isAgentHolder: agentHolderSince < block.number) prevents same-block borrowing only.

Nothing in the hook can be changed later. If the requester wants the waiver to follow the trading wallet, the standard pattern is to use the sender passed to afterSwap when it is a known router and the router's msgSender(), or hookData signed by the holder.

INK hook fees are paid by InkHook.collectFees() to vault.liquidity() (InkLiquidity), where they sit until at least MIN_ADD = 400,000 INK has built up (160,000,000 INK of INK-side volume at 25 bps); then anyone may call addLiquidity(), which places all of it single-sided just past the current tick, bounded only by the release floor (floorTick + premium).

Nothing prevents the caller from first moving the price with a swap in the same transaction and placing the position where it suits them, then buying the newly listed INK back.

The protocol-level effect is that fee INK, which the launch describes as "added back to the pool as permanent liquidity", can be listed at a depressed price chosen by the caller instead of the market price; the IMD it earns on the way back goes to the LP positions/treasury, so the loss is to the pool's INK pricing rather than to a specific holder.

This was recorded as an accepted design assumption (finding 942e691ce965 in ADAPTATION.md) and is bounded by the floor and the 1.25% + 0.25% round-trip fees; it is restated here because the hook launch is what makes the fee INK flow exist. It cannot be fixed in the live InkLiquidity; the mitigation available to this launch is operational (a keeper calling addLiquidity promptly at quiet moments) or routing hook INK fees elsewhere, which would change the stated design.

Read in full: src/InkHook.sol (the contract this launch deploys), src/InkVault.sol, src/InkLiquidity.sol, src/InkPortraits.sol, src/InkRenderer.sol, src/InkFeeRouter.sol (not part of this launch), test/InkSystem.t.sol setup (launch simulation), test/helpers/ConfiguredLiquidity.sol, launch/*.json, ADAPTATION.md, README.md.

Checked against the Pashov guide: v4 callback authentication (onlyPoolManager on every state-changing hook entry and on unlockCallback; permissions match getHookPermissions and are validated in the constructor), swap-delta sign handling for all four exact-input/exact-output × direction cases (specifiedIs0 logic is correct and the fee is taken from the unspecified side), fee claim accounting (mint inside afterSwap offsets the hookDelta credit, net zero; collectFees burns and takes, net zero), overflow/cast bounds, reentrancy (unlock cannot nest; ERC20s are plain), rounding (fee < 400 wei of the unspecified side rounds to 0, dust), access control (no owner on the hook; vault/liquidity/portraits/renderer owners are the stated single EOA with Ownable2Step and guarded renounce), the vault's pull/reveal/admission accounting and the liquidity ladder/range math (no defect found beyond the recorded design assumptions).

Reached off-repository: the IMD token source (0xd34a…63b7, Sourcify exact match): a LayerZero OFT over plain OpenZeppelin ERC20 with owner-updatable name/symbol only; no transfer tax, pause or blacklist, so poolManager.take(IMD, treasury) and the fee router paths are not at risk from token behaviour.

Not reached within the budget: the IMD launch factory (its atomicity of hook deploy + initialize, the token it mints, its supply and the 10%/10%/80% split that the 800M INK vault requirement depends on), the deployed PoolManager/PositionManager bytecode on mainnet, the identity.md seat contract 0x0000ec93…ec1d, the deployed-bytecode equivalence of the four live contracts (SOURCE_PROVENANCE.json was taken as given), and the full existing test suite (not run; only the scratch proof was executed).

No finding above depends on anything unreached except where stated.

Facts the manifest step must get right, taken from the code: (1) permissions must be exactly ["beforeInitialize","beforeSwap","afterSwap","afterSwapReturnDelta"] (getHookPermissions, validated against the address bits in the constructor; a mismatched salt reverts deployment).

(2) constructorArgs has six entries in declaration order: "$poolManager", portraits 0x54fa3515848440ddde2aefe45a382bd868cacd15, vault 0x33c85714c7d78fdb253fe1cf761d2d5c3c12d747, imd (must be the pool's paired currency 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, which InkLiquidity.MAINNET_IMD also enforces on chain 1), treasury 0xbc10b3662231c830d2ee10bc6359db17bea4b3d4, "25".

(3) beforeInitialize reverts WrongPool unless one side of the key equals the constructor's imd, so an imd argument that differs from pool.pairedCurrency makes the factory's initialize fail; and it accepts any pool.fee/tickSpacing, so the policy's fee tier (the tests use 12500 / 200) is unconstrained by the hook.

(4) feeBps > 100 reverts FeeTooHigh; zero addresses for portraits/vault/treasury revert ZeroAddress; imd is not zero-checked (ETH pairing would be accepted by the constructor but is not this launch). (5) The hook has no owner, no initializer, no delegatecall/selfdestruct, no mint/pause/blacklist: nothing in the forbidden list is present.

(6) The token has no constructor arguments and must send 80% of supply (≥ 800,000,000e18) to the vault for setInk to succeed; see the trading-lock finding.

Asymmetry / trust gap (access x economics). The 0.25% hook fee is waived when portraits.isAgentHolder(tx.origin) is true, and InkPortraits.isAgentHolder (src/InkPortraits.sol:190) only requires agentBalanceOf[holder] > 0 && agentHolderSince[holder] < block.number. agentHolderSince is written only when a wallet's agent balance goes from 0 to 1.

So a portrait transferred in block N exempts its new holder from block N+1 on, and when it is handed back in block N+1 the original holder is exempt again from N+2.

The natspec claims the waiver 'can't be borrowed for a single swap'; it can be borrowed for a single swap with a one-block delay, and one of the 2,000 agent portraits can therefore serve an unbounded number of wallets, each paying zero hook fee on arbitrarily large swaps, with the portrait out of the lender's hands for only one block (a collateralised escrow makes the rental trustless for the lender; the renter must be an EOA because the hook reads tx.origin).

The fee is the launch's own revenue (IMD to the treasury, INK back to the pool), so every rented swap is fee revenue lost to a wallet class the design did not intend to exempt. This is a weakening of a stated guarantee, not a loss of principal, hence low.

Minimal fix that keeps the design: require a longer holding period in isAgentHolder (e.g. agentHolderSince[holder] + K < block.number with K of some hours) or checkpoint agentHolderSince on every receipt, so a round-trip rental costs the lender its own exemption for the same period.

Trust gap (access x economics), documented as a privileged power rather than a bypass. The hook pays its INK fees to whatever InkVault.liquidity() returns.

InkVault.setup (src/InkVault.sol:171-187) is onlyOwner, callable once, and accepts any contract for liquidity_ as long as it has code, returns ink() == ink and poolSet() == true (src/InkVault.sol:179-181); it does not bind to the InkLiquidity already deployed at 0xa53a3b0521e471f69c0351d9e6620848e749f37d, and nothing on-chain ties the two together (InkLiquidity.setPool checks the hook and vault, but the vault never checks InkLiquidity).

The same address receives, in release() (src/InkVault.sol:239-240), unclaimed * 400,000 INK (up to 800,000,000 INK, 80% of supply) plus every reroll and pull-expiry fee. On mainnet today (block ~26.23M) InkVault.owner() is the EOA 0x824E12b38CfF2D3e7ad9607a0212f7F9Eb6a06E3 (no code, no multisig), vault.ink() and vault.liquidity() are still zero and statsRoot is zero, so this call is still ahead.

The brief's guarantee 'INK fees are sent to the vault's liquidity contract, which adds them back to the pool; nothing is burned' therefore rests entirely on that one owner transaction naming the right contract. The hook's own immutables cannot enforce it because it was asked to read vault.liquidity().

Record for the judge/author as the trust assumption of this launch: a compromised or mistaken owner key at setup time redirects the release and all INK fees irrecoverably, and the hook has no way to notice. If the author wants the guarantee enforced in code, the minimal change is for the hook to compare vault.liquidity() against the known InkLiquidity address (an immutable) before paying out, which does not add any owner power.

Access x economics. setPremium is onlyOwner and allowed while positions.length == 0. Because addLiquidity() requires vault.released() and release() is the first call that creates positions, the owner can change the premium right up to the block before release(), including after INK holders have seen the planned 16,000-tick value in script/InkSteps.sol:37.

The premium fixes the price at which up to 800,000,000 INK (the unclaimed seats' share) is listed: premium 0 lists it at the opening price, 100,000 ticks lists it at e^(10) ~ 22,026x, where it will in practice never sell and the 10% pool seed is the only INK liquidity. The bound and the before-first-position rule are the only guards.

This is an intended owner power; it is recorded so the judge can weigh it against the brief's 'nobody can change any of these after deployment' (which is true of the hook, not of the listing price of the released INK).

route() forwards IMD to the treasury and INK to InkLiquidity, then unconditionally calls liquidity.addLiquidity() when InkLiquidity's INK balance is at least MIN_ADD (400,000 INK). InkLiquidity.addLiquidity() reverts NotReleased() (src/InkLiquidity.sol:166) until InkVault.release() has run. The router's IMD transfer to the treasury therefore reverts together with the INK listing, although the two are independent.

Anyone can put InkLiquidity over MIN_ADD before release by transferring 400,000 INK to it (the transfer is an ordinary ERC-20 transfer; the INK is simply added to the release ladder later, so the sender loses it).

Impact is bounded: no funds are lost, the IMD is only delayed until release(), and before release there are no pool fees to claim, so the practical window is IMD sent to the router by hand (or the factory's requester share if a trade ever occurred). It resolves on its own once release() runs. Reported for completeness of the control-flow trace; it needs no change to the hook launch.

A fix in the owner's separate router deployment would be to try addLiquidity only when vault.released() is true, or to tolerate its revert.

Economic Security guide, 'legitimate features turned against the protocol'. _revealNext() derives the pick from r = keccak256(abi.encode(entropy, pullId)) and pick = r % avail (src/InkVault.sol:345-347), where entropy is only blockhash(p.blockNumber + 1). Nothing else enters the draw.

The Ethereum proposer schedule is public one epoch ahead, so a puller who operates (or pays) the validator scheduled for slot N+1 pulls in block N and then builds candidate payloads for N+1 (reordering or adding/dropping its own transactions changes the block hash) until keccak256(abi.encode(hash, pullId)) % avail equals the inventory index of the portrait it wants.

The expected work is about avail hash evaluations, done off-chain for free; the proposer's block is still valid and earns its normal reward, so there is no cost beyond the pull's own 400,000 INK, which the puller would pay anyway. The valuable target is an agent portrait sitting in _inventory (one-of-a-kind, and it confers isAgentHolder perks: the hook fee waiver and half-price rerolls), which any holder can hand in via deposit() for exactly 400,000 INK.

Honest pullers lose the uniform chance the vault promises ('a random portrait'); the vault's INK backing is not affected. The brief itself says next-block randomness must not be described as manipulation-proof; this records the concrete cheapest path. The same seed source is used by revealTraits (src/InkVault.sol:448), where only the art is at stake.

Not a code defect; an operational economics note for the owner before release(). At release the pool's tick is still the opening tick (no swap can run before released() and nothing else moves slot0), so addLiquidity() always takes the ladder branch from start = floorTick +/- premium.

The live InkLiquidity 0xa53a3b0521e471f69c0351d9e6620848e749f37d reports premium() == 0 (read from mainnet during this review), so up to 800,000,000 INK will start one tick spacing above the opening price. The ladder's thin bottom band (about 2% of the released INK in band 0, rising to about a third in band 7) limits how much is sold at the lowest prices, and setPremium() is callable until the first position exists.

If INK changes hands outside this pool before release (for example the swarm's 10% allocation, if the launch policy leaves it transferable) and trades above the opening price, the first buyers after release() take the bottom bands below that outside price; the shortfall is IMD the permanent liquidity and the treasury (its share of LP and hook fees) would otherwise have captured.

The owner decides the premium; the accepted finding 942e691ce965 already covers the related spot-tick listing of fee INK.

Merged from audit_permissions 9f56e1a1d49e (hook) and extended to the vault, same root cause. The hook waives its 0.25% fee when portraits.isAgentHolder(tx.origin) is true; InkVault.pull()/deposit()/rerollTraits() price the half fee from the same view.

InkPortraits.isAgentHolder (src/InkPortraits.sol:190, agentBalanceOf[holder] > 0 && agentHolderSince[holder] < block.number) only requires the balance to have gone 0->1 in an earlier block, and agentHolderSince is written only on that 0->1 transition.

So a portrait transferred in block N exempts its new holder from N+1 on, can be handed back in N+1, and the original holder is exempt again from N+2 (its own since-block is rewritten on the return, so it loses nothing but one block).

One of the 2,000 agent portraits can thus serve an unbounded set of EOAs (a collateralised escrow makes the rental trustless), each paying zero hook fee on arbitrarily large swaps and the discounted reroll fee, against the natspec claim that the discount 'can't be borrowed for a single swap' and the brief's 'waived for wallets holding an agent portrait'. Impact is lost fee revenue (IMD to the treasury, INK to the pool), not loss of principal, hence low.

InkPortraits is live and unchangeable; a fix that keeps the design would be in the hook (e.g. read agentHolderSince(tx.origin) and require it to be at least K blocks old), which the author must weigh against 'keep the hook's logic as written'; otherwise record it as an accepted design limit.

From audit_economics 988fd71aef4b, reproduced by trace. _revealNext() derives the pick from r = keccak256(abi.encode(entropy, pullId)) and pick = r % avail (src/InkVault.sol:345-347) where entropy is only blockhash(p.blockNumber + 1); revealTraits (line 448) uses the same source.

The Ethereum proposer schedule is public one epoch ahead, so a puller who controls or pays the validator for slot N+1 pulls in block N and iterates candidate payloads for N+1 (reordering or adding its own transactions changes the hash) until the pick equals the inventory index of the portrait it wants, at about avail off-chain hash evaluations and no on-chain cost beyond the pull's own 400,000 INK.

The valuable target is an agent portrait handed in through deposit() (one-of-a-kind, confers the hook fee waiver and half-price rerolls). The vault's INK backing is unaffected; honest pullers lose the uniform chance the natspec promises.

This is the residual the brief itself names ('do not describe next-block randomness as manipulation-proof') and ADAPTATION.md records as 'builder-influenceable blockhash randomness'; it is kept here as the concrete cheapest path so the author decides knowingly. No contract in this launch can change it (InkVault is live).

From write_foundry_tests 1c7324b24e25, reproduced (the supplied proof fails on this code). _rangeFrom clamps only the far endpoint to maxUsableTick/minUsableTick; the near endpoint is computed from the spot tick without a clamp. With INK as currency0 and tick >= 887220 (maxUsableTick(60)), lower = 887280 > upper = 887220; with tick in [887160, 887219], lower == upper == 887220. For INK as currency1 the mirror holds at the bottom.

Downstream, addLiquidity() in its non-ladder branch calls _add(lower, upper, amount) -> _mintSingleSided -> TickMath.getSqrtPriceAtTick(887280), which reverts InvalidTick (MAX_TICK is 887272), or for the equal case LiquidityAmounts.getLiquidityForAmount0 divides by sqrtPriceB - sqrtPriceA == 0 and panics. The ladder branch is unaffected (it breaks on lower >= upper).

So fee INK that has accumulated in InkLiquidity (hook fees, reroll fees, LP fee INK) cannot be listed, and InkFeeRouter.route()/claimAndRoute() revert too (they call addLiquidity unconditionally at MIN_ADD), until the price leaves the last interval. No funds are lost and the state is recoverable, and the price region is only reached after every INK position has been bought out, so low. InkLiquidity is live and cannot be changed in this launch; recorded for the owner.

From audit_permissions 18d544e36573, reproduced by trace and confirmed against mainnet at block 26,235,376: InkVault.owner() is the EOA 0x824E12b38CfF2D3e7ad9607a0212f7F9Eb6a06E3 (no code), vault.ink(), vault.liquidity() and statsRoot are all zero, InkLiquidity.poolSet() is false. The hook pays its INK fees to whatever InkVault.liquidity() returns and release() (src/InkVault.sol:239-240) sends unclaimed * 400,000 INK to the same address.

InkVault.setup (lines 171-187) is onlyOwner, one-shot, and accepts any contract that has code, returns ink() == ink and poolSet() == true; it never compares liquidity_ with InkLiquidity 0xa53a3b0521e471f69c0351d9e6620848e749f37d, and the hook's immutables cannot, because the brief asks it to read vault.liquidity().

The brief's guarantee 'INK fees are sent to the vault's liquidity contract, which adds them back to the pool; nothing is burned' therefore rests entirely on that one owner transaction naming the right contract, and a mistaken or compromised owner key at setup time redirects the release and all later INK fees irrecoverably. Recorded as the launch's main privileged-power trust assumption (actor: vault owner; precondition: setup() not yet called, which is the live state).

If the author wants it enforced in code the minimal change is an immutable known-liquidity address in the hook checked against vault.liquidity() before _payOut, which adds no owner power but changes the hook, so it is the author's scope decision.

Merged from audit_permissions 492053862b91 and audit_economics 36b69178a124 (same state and setter), reproduced by trace and against mainnet: InkLiquidity.premium() == 0 at block 26,235,376. setPremium is onlyOwner and allowed while positions.length == 0; since addLiquidity() requires vault.released() and release() is the first call that creates positions, the premium can change until the block before release(), including after holders have seen the planned 16,000 ticks in script/InkSteps.sol:37.

The premium fixes the price at which up to 800,000,000 INK is listed: 0 lists the ladder from one tick spacing above the opening price (the first post-release buyer, who can bundle release() with a swap, takes band 0, about 8,000,000 INK, at roughly the opening price regardless of any outside price INK reached during the window); 100,000 lists it at about 22,000x, where it never sells and the 10% seed is the only INK liquidity.

Intended owner power within the bound; recorded so the judge can weigh it against 'nobody can change any of these after deployment', which is true of the hook but not of the released INK's listing price.

Operational remedy only: the owner calls setPremium(16000) (or the chosen value) before release(); no contract change.