sweepSurplus() is callable by anyone and treats every ETH claim (id 0) above floorReserve + (recipientAccrued - recipientCollected) as surplus and transfers it to BURN_HOOK.

The accounting it compares against is only created when the adapter delivers a receipt via onTrade, and the program is explicitly designed for receipts that arrive after the trade (receipt carries its own timestamp/blockNumber, onTrade only checks trade.timestamp <= block.timestamp, and the code reasons about 'late-delivered' receipts).

Whenever module-fee claims reach this contract before the matching receipt (claims credited by the hook at swap time, receipt delivered in a later transaction; or receipts of an adapter that GOVERNANCE has since replaced and that can no longer be delivered), any caller can move those claims out before they are accounted.

When the receipt is then delivered, recipientAccrued (and, for a large sell, floorReserve) increase with nothing backing them: _maybeCollect's internal collectFees reverts and defers, a manual collectFees(pending) reverts with CollectInvalid because held < amount, and the Rev5 check in collectFees lets the recipient take whatever IS held first, so the shortfall lands on the floor reserve (released funds stop at held - pending).

In the draw window the base onTrade additionally needs feeEth/1000 of claims to be present (ClausDrawFundingProgram.sol:54) and reverts the whole delivery if they were swept, so a repeated sweep blocks receipt delivery.

ASSUMPTION STATED: this is reachable only if claims can be present without a consumed receipt. The adapter/hook source is not in the repository, so the delivery ordering is unverified; if the adapter always transfers the claims and calls onTrade in the same transaction, the window does not exist and this reduces to the adapter-replacement case.

Verified property: the contract itself provides no ordering guarantee and no restriction on who sweeps or when. Minimal fix preserving the intended behaviour: make sweepSurplus privileged (GOVERNANCE/operator) or only allow it in stale mode (no qualifying activity for STALE_AFTER), the same gate releasable() already uses for draining the reserve once the program is retired; alternatively require claims to be older than a delivery grace period before they count as surplus.

With pending = recipientAccrued - recipientCollected, free = held > pending ? held - pending : 0 and reserveBacked = min(floorReserve, free), the condition held < amount + reserveBacked can never be true for an amount that passed the earlier amount <= pending check: if floorReserve >= held - pending the check becomes pending >= amount (already enforced), and if floorReserve < held - pending then held > floorReserve + pending >= floorReserve + amount.

When held < pending, free = 0 and the check degenerates to held >= amount. The guard therefore reduces to amount <= min(pending, held) and the floor reserve never reserves anything against collection, contradicting the NatSpec on collectFees ('never from the floor reserve') and the Rev5 comment ('only the backed part of the reserve blocks collection').

Consequence: in any shortfall (see the sweep finding, or an adapter that credits moduleFeeEth without delivering the claims) the recipient drains the claims that nominally back floorReserve, and floorReserve becomes a number with no ETH behind it; releaseFloor then silently releases less than floorReserve says. Not a fund-loss path on its own (requires a shortfall to exist), but the guard is dead code and the documented priority is not what the code enforces.

Fix: decide the intended priority explicitly. If the recipient should have priority, delete the dead computation and document it; if the floor should keep its backing, check held - amount >= floorReserve (or clamp amount to held - floorReserve).

onTrade accepts any receipt from whatever address the GOVERNANCE contract (0x180eAE78..., operator-controlled, has code on mainnet) currently maps to this program. Receipt fields (amount0/amount1 -> oracle price, moduleFeeEth -> recipientAccrued/floorReserve, buy/id/timestamp -> keeper buyTime) are not independently verifiable by this contract.

This is the documented TRUST line and not a bypass; it is recorded here because it can change behaviour after review: a new adapter can (a) seed and warm the oracle with synthetic prices over 1 day / 12 receipts and then set the sell extra or trigger floor releases, (b) credit moduleFeeEth without delivering claims (shortfall, see the collectFees guard finding), (c) deliver fabricated buys that invalidate or create keeper reigns.

Replay is keyed by id alone (drawReceiptConsumed[id], disclosed), so a replacement adapter must not reuse ids. No unprivileged amplifier was found; reported as a trust assumption only.

collectFees pays RECIPIENT by calling PoolManager.unlock, which reverts with AlreadyUnlocked when the manager is already unlocked (Uniswap v4 Lock semantics, verified from the v4 implementation, not from the repository).

If the adapter delivers receipts synchronously from the hook during a swap (i.e. inside the swapper's unlock), the internal attempt in _maybeCollect always fails, sets collectRetryAfter = now + 1 h and emits CollectionDeferred on every receipt that crosses the threshold; the recipient's fees are never pushed and must be pulled by calling collectFees from outside an unlock. If receipts are delivered by a separate transaction the path works.

No loss: collectFees is permissionless and the ETH stays claimable. Also note the 150_000 gas stipend: the deliverer (a trusted role) can starve the inner call so it reverts and defers; no unprivileged actor can. Documented as a liveness/gas observation that depends on the unverified delivery model.

_observe assumes receipts arrive in trade-time order: any receipt whose trade timestamp is at or below the last observed one is skipped for the oracle (the fee accounting, volume and keeper paths still run). Receipt delivery is not ordered: the verified TradeExtensionHost.execute (0xea04...7f91, source on Sourcify) lets anyone deliver any pending receipt in any order, outside swaps.

Whoever delivers a receipt with trade time T first permanently excludes every not-yet-delivered receipt with trade time <= T from the short/long averages and from the warm-up counter trackedObs. Because a block holds at most one observation, a deliverer who front-delivers their own sell receipt in each block makes the oracle sample only sell-side execution prices (below spot by the sell's own impact) and never the buys in those blocks; the reverse biases it upward.

The bias per observation is bounded by the spread of real execution prices inside a block and the 25%/hour step bound still applies, so the effect is a slow drift of emaLong (<= ~1.18%/hour) and a delayed warm-up, not a direct loss.

Seam: boundary (ordering guard) x invariant ('every qualifying receipt is one rate-bounded update'). A minimal fix that keeps the design: skip only receipts with ts < lastTime that are older than a short tolerance, or key the one-per-timestamp rule on receipt id order (ids are monotonic in the host) rather than on first delivery; alternatively process out-of-order receipts with dt = 0 handling instead of dropping them.

reserveBacked = min(floorReserve, held - pending) when held > pending, else 0. In every case the condition reduces to held < amount: if floorReserve <= held - pending then amount + floorReserve <= pending + (held - pending) = held; if floorReserve > held - pending then amount + (held - pending) <= held because amount <= pending.

So the extra term is dead code and the comment above it ('only the backed part of the reserve blocks collection') describes a check that does not exist. Behaviourally this means the fixed RECIPIENT's pending fees always take priority over the floor reserve when the two overlap on the same ERC-6909 claim balance.

That is consistent with the rev5 intent of never locking the recipient, and no value leaves the program to anyone but RECIPIENT, so this is an accuracy/clarity note rather than a loss. If the intent is instead that collection must leave the backed reserve intact, the guard should be held - amount >= floorReserve (or the reserve should be tracked on a separate claim).

Numerical lens: boundary (min/clamp) x invariant (held >= floorReserve + pending).

Not a defect; the design discloses these, and the audit brief asks that every post-review lever be named. Verified against Ethereum mainnet at the time of review:

1. BURN_HOOK is an EIP-1967 proxy whose implementation slot holds 0xa62f9b597225779b430024398b70374e8468ce14 (verified 'ProtectedHook') and whose admin slot holds 0x1f22e4b065b2f15fed5be556dc0fa636048d29bc; the admin can replace what happens to every ETH claim this program releases (floor releases and sweepSurplus both transfer claims to it).
2. GOVERNANCE 0x180e...e334 (verified 'ClausGovernance') has an 'operator' who alone selects which adapter/program the host runs, and a FOUNDER who can replace the operator; receipts reach onTrade through a factory-made ComputeProtectedProgram adapter that first takes gross*1000/1e6 as the compute share and forwards the remainder, which is what this program sees as moduleFeeEth.
3. The adapter staticcalls quote with 50,000 gas and falls back to a default plan (module share 1000 pips only) on any failure; measured cold-path quote cost here is ~23.8k gas with a warm oracle, hyperdrive active and the draw window read, so the Day 7 extra is currently within budget, but any future dependency making DRAW.endsAt() or the oracle reads costlier silently disables the extra.
4. Receipts are delivered by anyone through TradeExtensionHost.execute only while the PoolManager is locked, so collectFees' unlock() call is reachable (it would revert with AlreadyUnlocked if receipts were delivered inside a swap).
5. RECIPIENT and ATTESTER have no code on mainnet (EOAs as stated).
6. The DRAW window read on every receipt is live (startedAt 1793200595, endsAt 1793805395) and BUY_HODL_END = 1793837915; both windows close within days of this review, after which floorShare's reconstruction of the pre-deduction fee reduces to inner = r.

sweepSurplus() (lines 336-343) is permissionless and defines surplus as PoolManager ETH claims (id 0) held by the program minus floorReserve plus the recipient's pending fees. Both of those accounting terms are only credited inside onTrade -> _afterTrade (lines 205-207).

The receipt flow is asynchronous by design: receipts carry their own blockNumber/timestamp, onTrade only checks trade.timestamp <= block.timestamp, and the contract explicitly handles late-delivered and undelivered receipts (lines 195-198, 466-470). If the hook/adapter credits the module-fee claims to this program at swap time and the receipt is delivered in a later transaction, any address can call sweepSurplus() in between and move the not-yet-accounted claims to BURN_HOOK.

When the receipt then arrives, recipientAccrued (and floorReserve for a large sell) is credited with nothing behind it: collectFees reverts with CollectInvalid for that amount (line 266, held < amount) and the fixed RECIPIENT loses the fee permanently, while _maybeRelease silently caps or skips. The contract has no way to tell an unaccounted claim from rounding dust, and nothing rate-limits or delays the sweep.

ASSUMPTION: this depends on the adapter crediting claims before (not atomically with) onTrade; the adapter is selected by GOVERNANCE and its source is not in the repository and not verified on Sourcify, so this could not be confirmed. If claims are always transferred in the same call as onTrade, the window does not exist and this reduces to an informational note.

Minimal fix that preserves the intended dust sweep: only allow sweeping claims that were already present at the last receipt (e.g. snapshot held balance at the end of _afterTrade and let sweepSurplus move at most snapshot - reserved), or restrict sweepSurplus to be invoked from _afterTrade after accounting.

releasable() (lines 353-367) documents normal-mode release as requiring 'a real, sustained drawdown' where the rate-bounded short average is >15 percent below the long average for RELEASE_INTERVAL. The rate bound is 25 percent per elapsed hour of the short average, with dt the gap since the previous non-dust receipt.

After a 1 hour gap (common in a quiet pool) one receipt whose own execution price is >=22.5 percent below the long average moves emaShort by the full 15 percent in a single step (EMA target moves 2/3 of the gap, capped at 25 percent); after a 2 hour gap the cap is 50 percent. _trackDrawdown then stamps drawdownSince, and if no other non-dust receipt is delivered for the next hour (nothing an attacker needs to cause in a low-activity pool, and any such receipt is also rate-bounded upward), releaseFloor() sends RELEASE_MAX to BURN_HOOK every hour while the state persists.

The 'sustained' property is therefore one receipt plus absence of trades, not a persistent market move.

Impact is bounded: the ETH goes to the Buyback and Burn hook earlier than intended at 0.05 ETH per hour, and the attacker must actually execute a sell far below the average (paying the large-sell extra and slippage), so this is a design-strength note rather than a loss path.

Fix option within the design: require the drawdown to be observed across at least N receipts (e.g. trackedObs delta >= 2) or require block.timestamp - oracle.lastTime below a bound at release time so an isolated observation cannot carry the release.

With amount <= pending enforced at line 260: if held > pending and floorReserve <= held - pending the check is amount <= held - floorReserve, always true; if floorReserve > held - pending then reserveBacked = held - pending and the check becomes amount > pending, never true; if held <= pending then reserveBacked = 0 and the check is held < amount. So lines 263-265 reduce to 'held >= amount'.

The NatSpec at line 257 says ETH 'never' comes from the floor reserve and the rev5 comment says only the backed part of the reserve blocks collection, but in any shortfall state the recipient's pending is strictly senior and floorReserve keeps claiming ETH that is gone (floorReserve is not written down). _maybeRelease applies the same seniority (lines 386-387), so behaviour is internally consistent; the issue is documentation and dead logic, and that floorReserve becomes a phantom number after a shortfall.

No unprivileged profit path; informational.

sweepSurplus() can be called by anyone. It treats every id-0 claim the program holds above floorReserve + pending recipient fees as surplus and sends it to BURN_HOOK (line 341). Fee claims only get counted, as floorReserve or recipientAccrued, inside onTrade -> _afterTrade.

Receipt delivery is expected to happen late or out of order: the code handles 'late-delivered' receipts and only bounds trade.timestamp from above. The base onTrade also pays the draw share out of the program's existing claim balance, so the claims must already be held before the receipt arrives.

Whenever claims for a swap reach the program before its receipt (in an earlier transaction, or before onTrade in the same one, where the external DRAW_FUNDING.fund / BUY_HODL.fund calls can run code before _afterTrade), anyone can sweep them first. When the receipt then arrives, recipientAccrued and floorReserve grow with no claims behind them. collectFees reverts for the unbacked amount, and _maybeRelease/_maybeCollect silently do nothing.

In the draw or Buy&Hodl windows, the base contract's transfer of the draw/Buy&Hodl share can also revert for lack of balance, which reverts the whole onTrade, so the receipt cannot be delivered. The money is not stolen (it goes to the buyback hook), but the fixed RECIPIENT loses its fees and the floor accounting stops matching the claims.

Fix: record claims for receipts not yet delivered before treating anything as surplus (for example, let the adapter credit an 'expected' amount, or let only the adapter call sweepSurplus). At minimum, put sweepSurplus behind the same adapter check as onTrade, or a nonReentrant lock shared with onTrade.

_maybeCollect runs on every receipt and self-calls collectFees, which calls PoolManager.unlock. Uniswap v4 PoolManager.unlock reverts with AlreadyUnlocked if the manager is already unlocked. If the adapter delivers onTrade from inside a swap or hook callback (that is, during an unlock), every automatic collection reverts.

The try/catch swallows the error and sets collectRetryAfter = now + 1h, so the recipient is never paid automatically and the CollectionDeferred event repeats. The same catch path is also sensitive to gas. Solidity forwards min(150_000, 63/64 of remaining gas), so with a tight gas budget the inner call can run out of gas, leaving too little for the outer collectRetryAfter SSTORE.

The whole receipt then reverts. No funds are lost, because collectFees is permissionless and works outside an unlock.

Fix: skip the attempt when the manager is unlocked (check via exttload of the v4 lock slot), or drop automatic collection and rely on the permissionless call. Also check gasleft() comfortably exceeds the stipend plus the catch path before trying.

Privileged roles and dependencies that can change behavior after review.

1. GOVERNANCE 0x180e...e334 (a contract on mainnet, 6585 bytes, owner not determined) picks the adapter. That adapter's receipts are not checked against any on-chain swap: amounts, feeEth, moduleFeeEth and timestamp are taken as given, and the timestamp is only bounded above. Through the base onTrade, a forged receipt timestamped inside the draw window (startedAt 1793200595, endsAt 1793805395 on chain) with feeEth = 1000*X moves X of the program's claims, including floorReserve and the recipient's pending fees, to DRAW_FUNDING. Forged receipts can also inflate recipientAccrued or floorReserve, steer the oracle (and so sell fees and floor releases), and drive the keeper hall of fame.
2. BURN_HOOK 0x37Bf...FfF is an upgradeable proxy (DELEGATECALL in its bytecode, EIP-1967 admin slot = 0x1f22e4b0...29bc). It receives every sweep and release.
3. DRAW, DRAW_FUNDING and BUY_HODL have no DELEGATECALL or SELFDESTRUCT in their bytecode. quote() calls DRAW.endsAt() unguarded on every call, permanently, even after both windows end, because that operand is evaluated first.
4. ATTESTER (an EOA) alone decides keeper coverage.
5. RECIPIENT is an EOA, which could gain code via EIP-7702. Reentry during take() is blocked by _payment. None of these is a permission bypass. They are assumptions the deployment depends on.

sweepSurplus() (lines 336-343) is permissionless and defines surplus as the program's PoolManager ETH claims (id 0) minus floorReserve plus the recipient's pending fees. Both accounting terms are only credited inside onTrade -> _afterTrade (lines 205-207). The contract itself has no rule that the claims of a receipt arrive in the same call as the receipt.

If they ever arrive earlier, anyone can call sweepSurplus() in between; when the receipt lands, recipientAccrued (and floorReserve for a large sell) grow with nothing behind them: the internal _maybeCollect attempt reverts and defers, a manual collectFees(pending) reverts CollectInvalid (line 266, held < amount), and _maybeRelease silently caps.

Three specialists (permissions, economics, flow) reported this as medium under the stated assumption that the hook credits the program at swap time.

I verified the live path from the Sourcify-verified sources of the hook implementation 0xa62f9b59...ce14 (ProtectedHook, TradeExtensionHost) and of GOVERNANCE 0x180eAE78...e334 (ClausGovernance, ComputeProtectedProgram): at swap time FeeNftStakingHook._accrue mints the module share to the HOST's activeModule, i.e. the factory-made ComputeProtectedProgram adapter, not to this program; later anyone calls TradeExtensionHost.execute (only while the PoolManager is locked), which calls adapter.onTrade, which transfers programFee = moduleFeeEth - compute to this program and calls program.onTrade in the same call.

ClausGovernance.adapterFor(program) is set once by createAdapter and never changed. So with the pinned deployment the program never holds a receipt's claims before onTrade runs, and the only code that executes between the transfer and _afterTrade is the fixed DRAW_FUNDING.fund / BUY_HODL.fund calls in the base (windows end within days).

The specialists' medium therefore downgrades to low: the program's accounting invariant (held >= floorReserve + pending) depends on an external atomicity property it does not enforce, and any future adapter/host that credits claims ahead of delivery, or a direct claim transfer that is meant to be a receipt's money, re-opens the path.

Verified property: unprivileged actors cannot create the precondition against the pinned hook/adapter.

Assumption stated: the Sourcify sources match the deployed bytecode (Sourcify reports a match; I did not independently rebuild). Minimal fix preserving the dust-sweep intent: gate sweepSurplus to the adapter (same authority check as onTrade) or to stale mode, or snapshot the held balance at the end of _afterTrade and let sweepSurplus move at most snapshot minus reserved.

With pending = recipientAccrued - recipientCollected, amount <= pending enforced at line 260, free = held > pending ? held - pending : 0 and reserveBacked = min(floorReserve, free), the revert at line 266 is unreachable unless held < amount: (a) held <= pending: free = 0, reserveBacked = 0, check is held < amount; (b) held > pending and floorReserve <= held - pending: amount + floorReserve <= pending + held - pending = held; (c) held > pending and floorReserve > held - pending: amount + held - pending <= held because amount <= pending.

Lines 263-265 are therefore dead code and the guard reduces to amount <= min(pending, held). The NatSpec at line 257 ('never from the floor reserve') and the Rev5 comment at lines 261-262 ('only the backed part of the reserve blocks collection') describe a check that does not exist.

Consequence: in any shortfall (claims lost or moved while floorReserve/pending were already credited) the recipient drains the claims that nominally back floorReserve and floorReserve is never written down; _maybeRelease applies the same seniority at lines 386-387, so behaviour is internally consistent but the documented priority is not enforced. No unprivileged profit path: ETH still only goes to the fixed RECIPIENT.

Merged from audit_math, audit_permissions and audit_economics (same line, same mechanism).

Fix: decide the priority explicitly. If the recipient is senior, delete lines 263-265 and fix the comments; if the backed reserve must stay, check held - amount >= floorReserve (or cap amount at held - floorReserve).

_observe drops any receipt whose trade timestamp is at or below the last observed one (fee accounting, volume and keeper paths still run). Delivery order is not the trade order: verified from the Sourcify source of TradeExtensionHost (0xea0436...7f91), execute(trade, hookData, gasLimit) lets anyone deliver any pending receipt in any order outside swaps, and the adapter forwards them unchanged.

Whoever delivers a receipt with trade time T first permanently excludes every not-yet-delivered receipt with trade time <= T from emaShort/emaLong and from the warm-up counter trackedObs. Because a block holds at most one observation, a deliverer who always front-delivers the sell receipt of each block makes the oracle sample only sell-side execution prices (and vice versa).

The per-observation bias is bounded by the spread of real execution prices within a block and the 25%/hour step bound, so the effect is slow drift of emaLong (roughly <= 1.2% per hour of continuous biasing) and delayed warm-up, not a direct loss. Merged from audit_math; delivery-order freedom verified in the host source.

Fix within the design: order the one-per-timestamp rule by receipt id (ids are host-global and monotonic) instead of first delivery, e.g. keep lastId and skip only ts < lastTime older than a tolerance, or process out-of-order receipts with dt = 0.

releasable() documents normal-mode release as requiring 'a real, sustained drawdown' (line 350). The implementation only requires that the drawdown flag has been set for RELEASE_INTERVAL; the flag is set by _trackDrawdown from the current emaShort/emaLong, and emaShort only moves on receipts.

After a 1 hour gap the short average may step 25% in a single update (maxDelta at line 301), so one receipt whose own execution price is >= 22.5% below the long average moves emaShort below 85% of emaLong in one step.

If no further non-dust receipt is delivered for the next hour (a quiet pool, or a deliverer who simply withholds delivery, since delivery is permissionless and voluntary), releaseFloor() sends up to RELEASE_MAX every hour while the state persists, and nothing restores emaShort until another receipt is delivered. The 'sustained' property is one receipt plus absence of trades.

Impact is bounded: ETH moves to the protocol's own Buyback & Burn hook earlier than intended at <= 0.05 ETH per hour, and producing the receipt requires an actual sell at that execution price (slippage plus the large-sell extra), so this is a design-strength note. Note the deliverer angle verified in the host source: withholding later receipts is free for anyone, so 'no further receipts' is not only a market condition.

Fix options that keep the design: require at least two observations since drawdownSince, or require block.timestamp - oracle.lastTime below a bound at release time so an isolated observation cannot carry the release. Merged from audit_economics.

Not a defect; the brief asks that every post-review lever be named. Merged from audit_math, audit_permissions and audit_flow, corrected with the verified sources.

1. Receipt authenticity: receipts reach onTrade only via ClausGovernance.adapterFor(program), a ComputeProtectedProgram whose onTrade accepts calls only from the fixed TradeExtensionHost, whose execute checks the receipt against a hash recorded by the fixed hook at swap time. adapterFor is set once by createAdapter and cannot be changed, and receipt ids are host-global and monotonic. So, contrary to the specialists' assumption, the GOVERNANCE operator cannot forge or replace receipts and the 'adapter with overlapping ids' scenario cannot occur; the operator can only point the host's activeModule elsewhere, which stops new receipts to this program (existing pending receipts remain deliverable) and after STALE_AFTER = 2 days lets anyone drain floorReserve to BURN_HOOK at RELEASE_MAX per hour. FOUNDER can replace the operator.
2. BURN_HOOK 0x37Bf...FfF is an EIP-1967 proxy (admin 0x1f22...29bc, implementation ProtectedHook). Its admin can upgrade the hook that mints module fees, records receipts and receives every released/swept claim, which indirectly controls everything this program sees; this program cannot pause or retarget it.
3. The adapter staticcalls quote with 50,000 gas and uses a default plan on any failure; quote reads DRAW.endsAt() unguarded forever (base line 36), so a reverting or costlier DRAW silently disables the extra (quote) or blocks receipt delivery (floorShare line 228, base line 49). DRAW_FUNDING.fund / BUY_HODL.fund are called inside their windows with the whole receipt reverting on failure; a reverted receipt stays pending in the host and can be redelivered.
4. Delivery is permissionless and voluntary (TradeExtensionHost.execute, only while the PoolManager is locked): anyone chooses order and timing of receipts, which feeds the oracle (see the ordering finding) and the keeper subsystem; nobody is obliged to deliver. Because execute requires the manager to be locked, the internal collectFees -> unlock() path works (the specialists' 'AlreadyUnlocked' liveness finding does not apply to this host; verified by Harness test_autoCollectWorksOutsideUnlock), and the deliverer's gasLimit (10k..5M) bounds onTrade; I found no gas value at which delivery succeeds but collection is deferred.
5. ATTESTER (EOA 0x8aCA...4cFa) alone decides keeper wallets and the scan watermark; a wrong attestation (e.g. attestKeeper(id, address(0))) is irrevocable because buyAttested blocks re-attestation, and a late-delivered buy with id < lastAttestedBuy can never be attested. No fee or custody effect.
6. RECIPIENT is a fixed EOA that receives native ETH via take(); with EIP-7702 code it could re-enter, but collectFees is guarded by _payment and sweepSurplus/releaseFloor read already-updated balances, so no inconsistency was found.
7. The Buy & Hodl window (ends 1793837915) and the on-chain draw window close within days; afterwards floorShare reduces to inner = r.