The run-3 pre-audit fix lets an APPEAL letter retry an appeal the oracle never answered by redirecting from the newest plea to its original when that newest plea is an appeal with status Expired. But the common no-verdict ending is the 20-minute timeout with no Intake call: the gate only flips a Pending plea to Expired lazily (in _clearStale, expire or onPleaFailure), so at letter time the newest plea is still Pending and _appealTarget returns the stale appeal itself.

Letterbox._appeal then runs _settleOpen (which expires it via gate.expire inside the same transaction) and calls gate.appealFor(writer, , ...), whose _appeal reads pleas[appealId].status == Expired and reverts NotDenied, undoing the settle as well.

The site path appealAuto(originalId) succeeds in the identical state, and the gate explicitly allows the retry (_expire resets o.appealed), so the stated guarantee 'an APPEAL letter may retry an appeal the oracle never answered' holds only when the Intake delivered a failure callback. No funds are lost: the writer must first call settle(appealId) or gate.expire(appealId) in a separate transaction and send the letter again, paying the 4-hour appeal window against the clock.

Minimal fix: in _appealTarget treat a Pending appeal that is stale (block.timestamp > submittedAt + PENDING_EXPIRY or the Intake request completed) like an Expired one, i.e. if (p.isAppeal && (p.status == Expired || (p.status == Pending && _settleable(id)))) id = p.originalId;.

An appeal must be for at most the original amount (AmountTooLarge) and, through _checkAmount, for at least 1% of the seller's current balance (AmountTooSmall). Both bounds are evaluated against the balance at appeal time, so if the seller bought (or received) PLEA after the denial such that 1% of the new balance exceeds the original amount, no amount satisfies both checks and the appeal that the rules grant within 4 hours of a denial cannot be made at all.

For a site plea at the 1% minimum any increase in balance blocks the appeal; for a 20% letter plea a 20x increase does. The Letterbox has no way around it either: Letterbox._appeal clamps the amount down to 50% of the balance but never up, so the APPEAL letter and appealAuto revert AmountTooSmall.

The buyer of more PLEA shows more loyalty, not less, so this is the opposite of the fact-score's intent; the 0.5 IMD oracle fee of the denied plea is spent and the appeal right is lost.

Minimal fix that keeps every number: in _appeal check the minimum against the original plea's own balance basis instead of the current one, e.g. skip the MIN_SHARE_BPS floor for appeals (if (amount == 0) revert AmountTooSmall(); if (amount > MAX_SELL || amount > bal * MAX_SHARE_BPS / 10_000) revert AmountTooLarge();), since the original already satisfied the 1% rule when it was scored.

PleaLaunch's eleventh constructor parameter is bool mintOracleFee_. The evm-contracts launch recipe this task is judged against lists the supported argument encodings as 'address, uint8...uint256, bool (0/1) and bytes32' and 'decimal/hex static words'.

The manifest encodes it as the word "true", which is neither a decimal nor a hex static word. test/LaunchManifest.t.sol does not exercise this argument through a manifest parser: it hardcodes MINT_ORACLE_FEE = true and only reads constructorArgs[11] (the Letterbox hash) from the file, so nothing in the repository proves the deployer's manifest step accepts "true".

If the deployer's argument parser is as the recipe states, the whole launch is refused at the manifest step, after the build is accepted. The adapter should write "1" (the value the ABI encodes for true) unless it has evidence the parser accepts the word; the rest of the file (keys, order, counts, $owner usage, $contract references pointing backward, notes under 4,000 characters) matches the schema.

Seam: boundary x precision x invariant. _requireWorthTheFee (src/Letterbox.sol:349-352) enforces the 0.70 IMD minimum against latestPrice() at submission, and the comment at lines 347-348 states the invariant 'so the fee can never eat a sale'.

But _deliver recomputes minOut (line 333) from _price() at delivery time, which is a different hourly checkpoint whenever the plea's 20-minute verdict window plus 7-minute sale window crosses an hour boundary and any trade happens in the new hour.

If the price fell by more than ~50.7% between the two checkpoints (value0.985 < 0.35 IMD while minOut = 0.95value is still met by the pool), gate.executeSellFor succeeds, returns out < AUTO_SELL_FEE (0.35e18) and the checked subtraction reverts with Panic(0x11). deliver and the writer's own SELL letter both hit the same line, so the approval cannot be sold at all; after 7 minutes it lapses, the writer is put in the 4-hour lapsed cooldown, and the oracle fee plus the fee PLEA (about 0.275 IMD worth) are lost, while a hand sale through the gate with any minOut would have been possible for a non-escrowed plea.

Concrete numbers from the attached test (real PoolManager, no mocks): snapshot P_H values the plea at 0.72 IMD; 110 approved cap-sized gate sales inside hour H move spot below 49% of P_H (each 2.5M PLEA sale moves spot about 1%); the first trade of hour H+1 checkpoints the crashed price; the verdict arrives 16 minutes after the plea; at delivery the escrow is worth 0.3017 IMD, minOut = 0.2866 IMD, the pool pays about 0.297 IMD, and 0.297e18 - 0.35e18 underflows.

Reachability needs a >50% move between consecutive hourly checkpoints (a launch-hour crash or a sybil of ~75-110 approved sellers), so the impact is limited to the writer's fees and sale opportunity: low. Fix suggestions that keep every agreed number: cap the fee at the sale (fee = out < AUTO_SELL_FEE ? out : AUTO_SELL_FEE) or revert with a named error before the swap when minOut < AUTO_SELL_FEE, so the status/settle path stays clean.

Seam: boundary x invariant. A letter plea passes when 20% of the balance is worth >= 0.70 IMD at the snapshot (balance >= 3.5 IMD) and the plea fee cap maxFeePlea = 0.25*1.1/price + 1 (0.275 IMD worth on Sepolia, where the 0.5 oracle fee is minted) is <= 10% of the balance (balance >= 2.75 IMD).

An appeal by letter buys 0.25 tip + 0.35 wall share = 0.60 IMD, capped at +10% = 0.66 IMD worth, so the same 10% rule (line 293) needs a balance >= 6.6 IMD; on the mainnet path (oracle fee bought too) a letter needs >= 8.25 IMD and an appeal >= 12.1 IMD.

Every writer in the gap [3.5, 6.6) IMD (or [8.25, 12.1) on mainnet) therefore gets a DENIED status that says 'send APPEAL before HH:MM UTC' (src/Letterbox.sol:496-503) and then has both Letterbox appeal paths revert FeeTooHigh, while the gate's own appeal(originalId, amount, text) for the identical amount succeeds when the IMD is paid directly.

The brief lists the 0.70 IMD minimum as the up-front refusal; the 10% fee-share bound is not among the agreed numbers and is what blocks the agreed 'APPEAL letter' flow for small holders. Measured in the fixture: a wallet that bought 5 IMD holds PLEA worth 4.81 IMD at the snapshot; the letter plea succeeds (need 28), the appeal's maxFeePlea is worth 0.646 IMD = 13.4% of the balance, and 'APPEAL ...' reverts FeeTooHigh(maxFeePlea, bal).

Suggested fix without changing fees or shares: evaluate the 10% bound on the plea fee only, or raise the appeal path's bound so an appeal is allowed whenever its original letter was (e.g. compare against the greater of 10% of balance and the original plea's amount), or make status() not invite an APPEAL letter the Letterbox will refuse.

Seam: access x asymmetry. The rule 'the PLEA owner does not play' is enforced against the live plea.owner() at the moment closeSeason runs (_dropOwner, src/Seasons.sol:308-313) and at the moment points are recorded (record, src/Seasons.sol:154). PLEA inherits plain OpenZeppelin Ownable (src/PLEA.sol:13), whose transferOwnership(address) is one-step: the new owner never has to accept.

So the owner can hand ownership to any wallet, including the running season's leader, right before (or in the same bundle as) closeSeason. That wallet is then dropped from the top 10: its IMD share rolls over (rollover = amountIn - paid) and its PLEA bonus share is burned (_payBonus skips it, then burns the unpaid rest). Its future pleas also earn no points (record reverts OwnerExcluded) until it moves ownership away.

The victim cannot refuse or front-run it. The owner gains nothing directly (the share is not redistributed), so this is a griefing power rather than theft; it is reported because the brief names the owner exclusion as a guarantee for players and because it costs the attacker only the allow power, which is all PLEA ownership controls after launch.

Minimal fix that keeps the agreed design: make PLEA use Ownable2Step (the excluded address can then only change with the new owner's acceptOwnership), or have Seasons read the owner once (e.g. at CabalGate.begin) instead of at every close/record.

Asymmetry between the documented entry point and its guard. burn(uint256) is public and documented as 'Burns the caller's own tokens'; its _update(from, address(0), v) call reaches the generic branch of the transfer rule because to == address(0) is neither the pool manager nor the gate nor the Letterbox, and a normal holder is not _exempt.

So while restricted() is true (before trading opens and for the whole life of the Cabal) only the hook, gate, Seasons, distributor, Letterbox, pool manager and allow-listed senders can burn.

Burning is value-destroying for the caller, so nothing is lost and no bypass exists; this is recorded so the author can decide whether the ABI should keep promising a burn it refuses (either let to == address(0) through for everyone, or document that burn is for the court's contracts only). Also note that before init sets poolManager, a burn hits the to == poolManager (== address(0)) branch instead and is refused for anyone but the gate and hook.

Trust assumption to document (access x economics). onOracleResult(intakeId, a, sig) locates the plea by pleaOfIntake[intakeId], verifies that a is signed by the oracle signer for this gate, consumes a.requestId, and applies a.answer to that plea. Nothing ties a to the plea: a.questionHash is never compared with anything derived from question(id)/body(id), and a.requestId (the oracle's UUID) is never compared with intakeId.

Therefore any valid, unexpired attestation for this gate can be delivered as the callback of any other pending plea of this gate, and the only party that cannot do that is a stranger (msg.sender must be the Intake). The Intake writer is already trusted to call onPleaFailure without a signature, so this is consistent with the stated design, but it means the oracle signer's guarantee on chain is 'a panel scored some plea of this gate', not 'this plea'.

If a binding is wanted, the gate can store keccak256(body(id)) per plea and require a.questionHash to equal the oracle's canonical hash of it, which needs the off-chain canonicalisation to be reproducible on chain; otherwise keep it as a documented trust in the Intake.

Run 3 raised the plea maximum from 35% to 50% of the seller's balance and moved the fact-score share bands to 20%/35% (CabalGate._checkAmount, CabalGate._factScore). The suite's amount-limit test kept bal * 35 / 100 + 1 as a 'too large' input and still expects AmountTooLarge. In this fixture alice holds about 8.77M PLEA (a 50 IMD buy), so 35% + 1 is about 3.07M PLEA, above the 2.5M MAX_SELL: the assertion passes for the cap, not for the share rule it was written for.

No test in the suite asserts that 50% + 1 wei of a sub-5M balance is refused, that exactly 50% is accepted, or that the fact score steps 18 -> 11 -> 5 just above 20% and 35% (grep for factScore assertions shows only whole-score equalities). I checked these edges with a scratch test on a 1.71M PLEA balance and the code behaves as specified (50% + 1 -> AmountTooLarge, 50% accepted, bands 18/11/5), so this is a coverage note, not a code defect.

Note that the band threshold is computed as floor(amount * 10000 / bal) <= 2000, so amounts up to about 20.01% still score 18; a test must step by one basis point plus one wei, not by one wei.

_requireWorthTheFee (lines 349-352) guarantees amount*snapshot >= 0.70 IMD only when the plea is opened. deliver runs up to ~27 minutes later (20-minute verdict + 7-minute window) against the pool's spot price, and the gate only enforces out >= 95% of the snapshot current at delivery.

If spot has fallen by more than 50% since the plead-time snapshot, executeSellFor returns out < 0.35e18 and out - AUTO_SELL_FEE underflows: deliver (and the writer's SELL letter) revert with panic 0x11 instead of a named error, the approval lapses after 7 minutes, the writer keeps the escrow and the tip via settle but has paid the oracle fee and the fee PLEA and carries a 4-hour lapse cooldown.

Funds are never lost or misdirected (settle refunds everything), and reaching the state needs a >50% spot drop in under two hours, which only gate-approved sales (<1% price impact per 2.5M PLEA sale) can cause; so this is a robustness note, not a loss. Control flow is otherwise correct: the escrow is closed before the external call and the whole call reverts atomically.

Merged from audit_math and audit_flow (same root cause). _requireWorthTheFee (src/Letterbox.sol:349-352) enforces amount*snapshot >= 0.70 IMD only when the plea is opened, against hook.latestPrice() of that hour. _deliver recomputes minOut (line 333) from _price() at delivery, which is the next hourly checkpoint whenever the 20-minute verdict window plus the 7-minute sale window crosses an hour boundary and any trade happens in the new hour.

When that checkpoint is below ~49.5% of the plead-time one, minOut = 0.95*value < 0.35e18, the gate's sale passes its own slippage check, executeSellFor returns out < AUTO_SELL_FEE and the checked subtraction reverts with Panic(0x11). deliver and the writer's SELL letter both hit this line, so the approval cannot be sold at all; after 7 minutes the writer is Lapsed (4-hour cooldown), the oracle fee is spent (minted on Sepolia, real IMD on mainnet) and the fee PLEA was sold, while a non-escrowed plea could have sold through the gate with any minOut. settle still refunds the escrow and the tip, so nothing is misdirected: low.

Reaching it needs a >50% fall between two consecutive hourly checkpoints, which only gate-approved sales can produce.

I confirmed the price move is reachable on the real PoolManager in test/scratch/Judge.t.sol (Bisect2Test): 110 wallets that bought 100 IMD each one day earlier, each approved for min(35% of balance, 2.5M PLEA) and sold through gate.executeSell inside one hour, leave spot at 38% of the hour's checkpoint (logged 'spot / P_H bps: 3834'); the underflow then follows arithmetically from line 337 (0.72 IMD * 0.38 * 0.9825 ~ 0.27 IMD < 0.35 IMD, with minOut ~ 0.26 IMD satisfied).

Fix that keeps every number: revert with a named error before the swap when minOut < AUTO_SELL_FEE, or cap the fee at the sale (fee = out < AUTO_SELL_FEE ? out : AUTO_SELL_FEE).

A letter plea needs 20% of the balance to be worth >= 0.70 IMD (balance >= 3.5 IMD at the snapshot) and the plea fee cap maxFeePlea = (0.25 IMD * 1.1)/price + 1 to be <= 10% of the balance (balance >= 2.75 IMD).

An appeal by letter buys the 0.25 tip plus the 0.35 wall share = 0.60 IMD, capped at +10% = 0.66 IMD worth of PLEA, and the same 10% rule at line 293 then needs a balance >= 6.6 IMD (on the mainnet path, where the 0.5 oracle fee is bought too: letter >= 8.25 IMD, appeal >= 12.1 IMD).

Every writer in the gap gets a DENIED status that says 'send APPEAL before HH:MM UTC' (src/Letterbox.sol:496-503) and then has both Letterbox appeal paths revert FeeTooHigh, while gate.appeal(originalId, amount, text) for the identical amount succeeds when the IMD is paid directly. The brief lists the 0.70 IMD minimum as the up-front refusal; the 10% fee-share bound is what blocks the agreed 'APPEAL letter' flow for small holders.

Fix without changing fees or shares: apply the 10% bound to the plea fee only, or allow an appeal whenever its original letter was allowed (compare against max(10% of balance, original plea amount)), or make status() not invite an APPEAL letter the Letterbox will refuse.

'The PLEA owner does not play' is enforced against the live plea.owner() at closeSeason (_dropOwner, src/Seasons.sol:308-313) and at record (src/Seasons.sol:154). PLEA inherits plain OpenZeppelin Ownable (src/PLEA.sol:13), whose transferOwnership is one-step: the new owner never accepts.

The owner can therefore hand ownership to the running season's leader right before closeSeason (or in the same bundle): that wallet is dropped from the top 10, its IMD share rolls over, its PLEA bonus share is burned (_payBonus skips it and burns the unpaid rest), and its later pleas earn no points (record reverts OwnerExcluded) until it moves ownership away.

The owner gains nothing directly (the share is not redistributed), so this is a griefing power rather than theft, reported because the brief names the owner exclusion as a guarantee for players and the fix is small: Ownable2Step for PLEA, or Seasons reading the excluded owner once (e.g. at CabalGate.begin) instead of at every close/record. Trust assumption to document otherwise.

While reproducing finding 1 on the real PoolManager, the 1 IMD buy that opens hour H+1 reverted inside PleaHook.afterSwap with panic 0x11 (arithmetic underflow/overflow), after _payFees emitted FeesTaken and after exactly one PoolManager.extsload (the getSlot0 read at the top of _applyCap, src/PleaHook.sol:685), i.e. in _applyCap's ratchet/trim arithmetic or _pleaIn, before any further external call.

Logged hook state just before that swap: lastCapDecayAt 1800182699 (block.timestamp 1800183660), inventoryCap 796,487,828e18, pleaInMarket 439,432,295e18, capDecayPerDay 34,763,965e18, capDecayRemainder 34,763,965199999999999963095 (one second short of a full day's rate), market liquidity 2080886472306681101043009, tick -107060, refTick -120721, wallGuardTick -120721.

I could not isolate the trigger in the time budget: Bisect2Test::test_F and Bisect3Test::test_F (PLEA forced to currency0, as in the panicking run) in the same scratch file perform the same steps (Letterbox plea, 110 sales ending at 38% of the checkpoint, next-hour buy) with the whale setup moved into setUp, and there the buy succeeds, as do later buys and sells; the only remaining differences are harness-side (which contract deployed the fixture, and the gas the test had consumed before the swap).

So this is at most a single reverted swap in a specific state, not a persistent block of the pool, and it may be a harness artefact. Reported so the author can run the deterministic sequence against _applyCap (src/PleaHook.sol:682-724); severity low pending isolation, and it should be dropped if the author cannot reproduce it outside this harness.