_insertPlea implements 'older plea wins ties' by assuming pleas are inserted in id order, but record(pleaId) and closeSeason(pleaIds) are permissionless and accept any order. Whoever records first wins an equal-score tie: a later plea takes rank 1 (and, with five tied entries, the fifth Laureate slot) from an earlier one.

The same mechanism affects _insertWallet: Entry.pleaId is 'the plea that last raised the total', which is the last recorded plea, so a wallet can lower its tie-break key by recording its pleas in reverse id order, and _better then ranks it above a wallet with equal points whose key is larger. Impact is limited to rank/eligibility among tied scores (Laureate NFT rank and the 25/18/14/... prize split between tied wallets).

Fix: compare pleaId on equal scores in _insertPlea (lower id wins, as _better already does), and set Entry.pleaId to the max plea id among the wallet's counted pleas rather than the last recorded.

The task accepts PleaLaunch.deployHook running after launch, but the launch policy lists 'minting after launch' and 'anything configured after deployment rather than in a constructor' as things to flag. Concretely:

1. PLEA's whole 1e9 supply is minted in init, called from deployHook in a later transaction (one-shot, launcher-only, fixed split 90% hook / 10% distributor; no further mint path exists).
2. PleaDistributor.setMerkleRoot (owner, once) decides who receives the 10% share; if never set, 100M PLEA is stuck.
3. PLEA.allow (owner, add-only) exempts senders from the transfer restriction while the Cabal watches; allowed senders still cannot send to the PoolManager or the gate, so they cannot sell, but can move PLEA to other wallets or venues.
4. PleaHook.owner receives 0.5% of every trade's IMD. There is no pause, freeze, blacklist, seizure, proxy, DELEGATECALL, CALLCODE or SELFDESTRUCT: the protected scanner over the six runtimes passes (test_noForbiddenOpcodes in test/scratch/Audit.t.sol). These are trust assumptions of the accepted design, not defects; listed for the adapter and the policy review.

Read in full: src/PLEA.sol, src/CabalGate.sol, src/Seasons.sol, src/Laureates.sol, src/PleaDistributor.sol, src/PleaLaunch.sol, src/PleaHook.sol, src/OracleAttestation.sol, src/interfaces/.sol, launch.json, script/.s.sol, test/utils/* and the test suite (105 tests pass on forge 1.8.3). launch.json matches the constructors (names unique, one argument per parameter in order, address arguments as $owner/$contract refs or static words, chain-agnostic timings 18000/118800 accepted off chain id 1).

Sizes: every runtime is under 24,576 bytes (PleaLaunch runtime 1,962, init code 25,800; PleaHook runtime 21,712 deployed later by create2). lib/ contains 305 plain tracked files, no submodules.

Could not be read (no source available): the IdentityMD Intake (0x1397...), imd/acc Stacker (0x293C...), TestIMD (0x2B69...), test IMD oracle asset (0x44a1...) and the Sepolia Uniswap v4 PoolManager (0xE03A...); their Sepolia bytecode was fetched and holds code (24009/2767/1904/6568/1821 bytes) and the Stacker bytecode contains credit(address,uint256) 0xef6506db while the Intake contains request(...)

0x380c2cda and requests(bytes32) 0x9d866985; the oracle signer 0x5598... is an EOA.

Reviewed and found sound: PLEA transfer rule paths (PoolManager/gate/hook/distributor/allowlist), hook fee and delta accounting for exact-in/exact-out buys and sells, gate sell routing (PartialFill, slippage, callbackExpected), appeal and cooldown windows, dead-man monotonicity, season bounds at death, closeSeason payouts and Laureate minting, hook permission flags vs PleaLaunch.FLAGS, CREATE2 commitment, oracle EIP-712 digest.

Not exercised: live Intake/Stacker behaviour, mainnet-length seasons with real clocks, fuzzing of hook liquidity math beyond the existing suite.

appeal() sets o.appealed = true (line 275) and only then pays the 0.5 oracle IMD + 0.35 pool IMD and asks the Intake. If the request completes without a verdict (panel refused or disagreed: requests(id).completed becomes true with no callback, or the callback reverts, or 20 minutes pass), the appeal plea is Expired by _clearStale/expire, but o.appealed is never reset.

Line 267 (if (o.appealed || o.isAppeal) revert AlreadyAppealed();) then refuses a second appeal although the Cabal never judged the first, while the seller is still inside the 4-hour denial cooldown, so they can neither appeal nor plead again.

A first-round plea that gets no verdict is cleared and can be re-submitted at once (no cooldown), so the two paths are asymmetric: the oracle failure costs an appellant 0.85 IMD plus their appeal right, but a first-round pleader only 0.5 IMD. Scratch test test/scratch/Review.t.sol::test_appealWithoutVerdictBurnsTheAppealRight reproduces it on this tree.

Minimal fix: clear pleas[o].appealed (via originalId) in _expire when the expired plea isAppeal, so an unjudged appeal can be re-filed within the original window.

The pot is Seasons' entire IMD balance (pot() = imd.balanceOf(this)), fed continuously by the hook's 0.25% prize fee on every trade. closeSeason(nextToClose) can be called any time after end + 1 hour but nothing forces it then, and the fee keeps flowing in from trades that belong to later seasons. Whatever has accumulated when someone finally closes season N is shared by season N's top 10, including every prize fee earned during seasons N+1, N+2, ... that are still running.

The README's promise is that each season's top 10 share 'the prize pot' with unpaid shares rolling forward; here paid shares roll backward: participants of the running season lose their fees to a leaderboard they were not competing on. No privileged actor is needed; a season-N winner simply benefits from nobody calling closeSeason, and because closing is permissionless the running season's participants have to race to protect their own pot.

Reproduced by test/scratch/Review.t.sol::test_lateCloseSeasonPaysNextSeasonsFeesToPreviousWinners.

Minimal fix: snapshot the pot when a season ends (e.g. record imd.balanceOf at the first fee or close after end through a per-season accrual: track accruedUpTo[season] by having closeSeason of season N use the balance recorded at the time season N ended plus rollover, or have the hook route the prize fee with the current season id so Seasons can bucket it).

seed() approves the Stacker (Sepolia 0x293C7134Ab8f6Bf1D8fF44Ed806575f8F1bAF477, verified to have code and the credit(address,uint256) selector) for type(uint256).max of IMD. The hook's IMD balance is not only the cashback in flight (at most 0.5% of one fill): it is also retainedImd, the buy wall's whole reserve between rebalances (appeal fees from fundWall, redeemed claims, closed-wall proceeds, Seasons.flushToWall leftovers).

The allowance is set once and can never be reduced (no owner function, no re-seed), so the external Stacker (its operator, an upgrade or a compromise) can transferFrom the entire wall reserve at any time. This is a documented external dependency, not a code defect: the design wants cashback paid as sIMD. Reported as the trust assumption the adapter asks for, with the concrete exposure.

A tighter variant would be safeIncreaseAllowance(stacker, amount) immediately before each credit and reset after, within the existing creditGas budget.

Access x asymmetry seam. closeSeason is permissionless and the only input the caller controls is which plea ids get recorded before the season is sealed. Once closed[season] is set, record() reverts SeasonClosed (src/Seasons.sol:125) and _tryRecord silently skips (src/Seasons.sol:262), so an approved plea that nobody recorded within CLOSE_GRACE (1 hour) after the season end loses its points and its Laureate eligibility forever.

A plea approved in the final minutes of a season has a window of as little as one hour, and the actor with the strongest incentive to call closeSeason at end+1h with an empty list is a rival in the top ten or top five. The points are not recoverable: the next closeSeason ignores ids whose season is closed.

The behaviour is documented in README (record within an hour), so this is recorded as a broken-guarantee edge rather than a design change request; a minimal mitigation is to let record() accept pleas for a closed season only for ranking display, or to lengthen CLOSE_GRACE to cover PENDING_EXPIRY plus one season of margin, both of which are the author's call.

Branch asymmetry in beforeSwap. While the Cabal lives an exact-input buy must name its recipient in hookData (RecipientRequired), so cashback, PLEA delivery and basisOf always go to the real buyer.

Once the Cabal is dead the same buy with empty hookData is accepted and trader falls back to sender, which for every generic Uniswap v4 router (Universal Router, PositionManager-style routers, the project's own BuyRouter shape) is the router contract, not the payer. afterSwap then calls stacker.credit(router, cashback) (src/PleaHook.sol:606) or transfers plain IMD to the router, and records basisOf[router].

The 0.5% cashback of every such trade is paid to the wrong party: it is minted as sIMD to a stateless router and is lost to the buyer (or sweepable by whoever can call the router's sweep). Minimal fix without changing any fee: keep RecipientRequired for buys regardless of alive (or require hookData for every swap), so a buyer never silently forfeits cashback.

Not defects; recorded so the judge has the privilege map.

1. PLEA owner ($owner, single-step OZ Ownable): add-only allowlist of senders exempt from the Cabal rule; an allowed wallet can transfer PLEA peer-to-peer (an OTC exit) but still cannot send to the PoolManager or the gate, and renounceOwnership only disables allow.
2. PleaDistributor owner ($owner): sets the Merkle root once; 100,000,000 PLEA (10%) are minted to the distributor at deployHook and are unreachable until a root is set; a wrong root strands them.
3. PleaHook.owner and PleaLaunch.owner are captured as PLEA.owner() inside the launch transaction and are immutable: the 0.5% owner fee keeps flowing to the original owner after any transferOwnership, and only that address may seed before START = 1791817200 (2026-10-12 15:00 UTC).
4. Oracle signer 0x5598... (an EOA on Sepolia, code length 0): every verdict rests on its key; there is no rotation path (OracleAttestationConsumer._setOracleSigner is never exposed), so a key rotation at IdentityMD makes the Cabal die after 33 hours and PLEA trade freely forever (fail-open).
5. The Intake 0x1397... is trusted to deliver each signed answer to the request that paid for it; see the next entry.
6. Anyone may call deployHook and, after START, seed; neither needs the owner. All six Sepolia dependency addresses in launch.json have code and the Intake and Stacker expose the selectors the interfaces use (checked with cast on a public Sepolia RPC); the PoolManager at 0xE03A... is a 48 kB runtime owned by 0x5b73...

Trust-gap note, already recorded by the previous contributor in ADAPTATION.md and retained here because it is the one place where the permission model relies on an external party's correctness rather than on a check. The attestation is verified against the gate's EIP-712 domain and its requestId is consumed, so a signed answer can settle at most one plea.

But the gate never checks a.questionHash against keccak of its own question(id)/body(id), and the oracle requestId is not tied to the Intake id the callback names, so the only thing routing a 45 to plea #7 rather than plea #8 is the Intake's own bookkeeping. No unprivileged actor can trigger it: msg.sender must be the Intake (src/CabalGate.sol:382).

Severity is therefore informational; if the protocol's canonical question document is defined, pinning questionHash = keccak256(bytes(body(id))) or the documented canonicalisation would close the gap without changing the ABI.

Economic / invariant (view-vs-intent divergence). The fact score is meant to reflect the seller's real position: holding time (0/5/9/14) and profit or loss (14/9/5/0) of what they hold. Both are read from PleaHook.basisOf(seller), which is only written by _updateBasis in afterSwap, i.e. only for PLEA that went through the pool with hookData = abi.encode(seller).

PLEA received from PleaDistributor.claim (the 10% share, 100,000,000 PLEA) has no basis.

Two consequences: (a) a pure distributor recipient scores at most 18 (share) + 5 or 9 (24h trend) = 23-27 -> need 43-47, and _open reverts CannotPass(47) in the common case, so the swarm share is effectively unsellable while the Cabal lives unless the holder first trades in the pool; (b) the holding-time and loss components are fully determined by the smallest hook buy: buying 1 wei of IMD sets imdSpent = 1, pleaHeld ~ 1.7e5 wei, avgBuyTime = now; fees make value < spent, so the same wallet immediately gets +14 'loss' on a position worth 1 wei while holding 1,000,000 free PLEA, and +14 holding time after 7 days: need drops from 47 to 19, the easiest possible plea.

The fact score is thus not a fact about the seller's 1,000,000 PLEA but about 1 wei of it. A whale who bought early at a low price can likewise reset avgBuyTime weighting only by buying a comparable amount, but can never be penalised for the free tokens. Fix options preserving the numbers: weight the basis by the seller's whole balance (treat PLEA without basis as spent 0 / held since the distributor claim), or exclude the profit/holding components when pleaHeld < amount.

Flow gap (execution x periphery x first principles). The gate promises 'a seven-minute window to sell through this gate' once approved, and the plea's amount is fixed at submission (p.amount). unlockCallback swaps exact-in with the extreme price limit and then requires the realised fill to equal the amount.

The pool is seeded with PLEA only, the hook is the only LP, and the only IMD in range is what buyers have paid in (plus the wall below the price), so whenever the market band holds less IMD than the sell needs (right after seeding, after a run of sells, or after a trim moved IMD to claims) the swap fills partially and the gate reverts for every call in the window.

The seller cannot reduce the amount (it is stored), cannot retry later (WindowLapsed), paid 0.5 oracle IMD for an approval it cannot use, and has to plead again (and the approval still earns season points, see finding 1).

Expected: either fill what the pool can take and return the rest, or let executeSell take an amount <= p.amount. Low because the seller's loss is the oracle fee and time, not principal, and the condition depends on pool state.

Precision x invariant seam. The hook records imdSpent as imdBasis + imdFee (src/PleaHook.sol:500), i.e. the gross IMD paid including the 1.5% IMD fee, and pleaHeld net of the 0.25% PLEA burn. factScore then compares pleaHeld * latest / Q96 with that gross figure.

Unless the checkpoint price has risen by more than about 1.75% plus the buyer's own price impact since the buy, value < spent holds for every buyer, so the component meant to reward holders who are actually losing money ('P/L') pays its maximum 14 points to anyone who just bought.

Measured in test/scratch/Fact.t.sol on the project's fixture: bob buys 10 IMD (fixing the hour's checkpoint), alice buys 50 IMD; alice's basis is spent = 50.000 IMD, value at the checkpoint = 48.673 IMD (2.65% short), factScore(alice, 10% of her balance) = 37 = 18 (share) + 0 (held < 1 day) + 14 ('loss') + 5 (no 24h history). When alice's own buy is the first trade of the hour (checkpoint = post-buy price) value = 49.608 IMD and the score is still 37.

The invariant the scorer assumes, 'a buyer at the current price is at break-even', is broken by the fee and burn truncation, which lowers need by 14 of the 45 judge points for every fresh buyer. Fix options that keep the agreed numbers: compare against the net basis (imdBasis, excluding imdFee) and/or value pleaHeld + burned; or give the 14 points only when the shortfall exceeds the round-trip fee.

Numbers only (the brief says to keep every number as it is; this is recorded so the author knows what the agreed constants do on this supply). inventoryCap starts at the seeded deposit, 899,999,100 PLEA, and may fall by at most CAP_DECAY_PER_DAY = 300,000 PLEA per elapsed day (unused allowance banks without bound), with CAP_FLOOR = 900,000 PLEA.

A trim (burn of pool PLEA above the cap) only fires when the pool's PLEA exceeds the cap, and the pool can never hold more than the deposit minus burns. Measured in test/scratch/Fact.t.sol: after 4,000 IMD of buys the pool holds 509.8M PLEA; after 365 further days the cap is still 790.5M PLEA; reaching the floor takes 2,996 days.

So trims can only occur while cumulative net buying has removed less than 300,000 x days PLEA from the pool (110M after a year, 11% of supply); otherwise the 'trims burn 100%' path is dormant and only the 0.25% per-trade burn and the wall's settle burns reduce supply. The trim path itself is correct (test/scratch/Trim.t.sol: a 171,753 PLEA sell-back after a 2-day ratchet burns 171,753 PLEA and returns the pool to the cap within 215 wei).

Decision for the author, not a code defect.

From audit_permissions (47b8cd47), checked against the code.

1. PLEA owner ($owner, single-step OZ Ownable): add-only allowlist of senders exempt from the Cabal rule; an allowed wallet can transfer peer-to-peer but still cannot send to the PoolManager or the gate.
2. PleaDistributor owner ($owner): sets the Merkle root once; 100,000,000 PLEA are unreachable until then and a wrong root strands them.
3. PleaHook.owner and PleaLaunch.owner are PLEA.owner() captured inside the launch transaction and immutable: the 0.5% owner fee keeps flowing to the original owner after any transferOwnership, and only that address may seed before START = 1791817200.
4. Oracle signer 0x5598... is a single key with no rotation path (_setOracleSigner is never exposed); a rotation makes the Cabal die after 33 hours and PLEA trade freely forever (fail-open).
5. The Intake is trusted to deliver each signed answer to the request that paid for it (next entry).
6. Anyone may call deployHook and, after START, seed.
7. PLEA.setLauncher's deployment-block fallback (kept per the brief) means the six constructors must run atomically; a separate-transaction deployment would let any caller register in PLEA's deployment block.

Second-round settlement of finding c4417c7f (cashback to the router after death). The fix makes every buy require an encoded recipient, which I confirmed: after DEADMAN a router buy with empty hookData reverts and a buy with abi.encode(alice) credits alice (test_C_buyEmptyDataRevertsAfterDeath).

The same fallback is still taken for sells. _payFees computes cashback = imdBasis * CASHBACK_BPS / BPS for every swap with an IMD fee, sells included (src/PleaHook.sol:530), and afterSwap then calls _payCashback(trader, cashback) and _updateBasis(trader, false, ...) (lines 501-508).

While the Cabal lives sells only reach the pool through the gate, which always encodes the seller, so the fallback is unreachable; once the Cabal is dead any wallet can sell through a generic Uniswap v4 router, and a router that does not forward hookData (the Universal Router and the project's own BuyRouter shape pass whatever the caller supplies; most front ends pass nothing) is the swap sender.

The 0.5% IMD cashback of every such sale is then minted as sIMD to the router and lost to the seller, and the seller's basisOf is never reduced while the router's goes to zero.

Severity stays low: the loss is the cashback of a post-death sale, not principal, and the seller can avoid it by encoding their address. Minimal fix that keeps every number: apply the same RecipientRequired rule to sells once the gate is no longer the only seller (i.e. revert whenever trader == address(0)), or document that post-death sells must encode the recipient. The brief's 'free selling after death' is preserved either way: only the hookData word is required.

Settlement of the four earlier advisory findings the author disputed as policy. I re-read each against the revised code and accept the author's position; they are recorded here so the record is complete and none of them reopens the work. (a) ee3aab4e, PartialFill: executeSell still swaps the whole approved amount exact-in to the price extreme and reverts unless pleaIn == amount (this line).

The author states the all-or-nothing contract is intentional and the oracle fee buys a judgment, not liquidity; the dust-funded variant that produced my reproduction is now closed by the basis-coverage rule in factScore (heldPlea >= amount), which I confirmed (test_F_factScoreCovered: a 1,000,000 PLEA distributor recipient with a 1e12-wei buy scores 23 before and after the buy and after 7 days).

An approved seller whose amount exceeds the IMD in the market band still cannot execute within the window; that is the documented behaviour. (b) bfc69ac0, 14 loss points for a fresh buyer: imdSpent is gross of the 1.5% fee and pleaHeld net of the burn, so value < spent for any buyer whose checkpoint price has not risen about 1.75% (src/CabalGate.sol:237-240). The author keeps the cost/value definition; I note only that it is a scoring choice, not an arithmetic defect.

(c) 75b7c738, closeSeason([]) at end + CLOSE_GRACE seals unrecorded approvals (src/Seasons.sol:50, :153, :321): documented settlement rule, timings fixed by the brief. (d) 831feb67, cap decay of 300,000 PLEA/day against a 900M deposit reaches the floor after 2,996 days: a parameter the brief preserves.

The fractional-budget correction (4db127f5) is confirmed fixed: test_E_capSameSecond (three same-second buys) keeps initialCap - inventoryCap <= CAP_DECAY_PER_DAY * elapsed / 1 day and lastCapDecayAt <= block.timestamp.

Settlement of b1646eff, d970e4be and 6af90e91, which the author confirmed as accepted assumptions and documents in ADAPTATION.md and the manifest notes. Re-checked against the revised code:

1. PLEA owner ($owner, single-step Ownable) holds an add-only sender allowlist (src/PLEA.sol:86); allowed wallets can transfer peer-to-peer but not to the PoolManager or the gate.
2. PleaDistributor owner sets the Merkle root once; 100,000,000 PLEA are unreachable until then.
3. PleaHook.owner and PleaLaunch.owner are PLEA.owner() captured in the launch transaction and immutable: the 0.5% owner fee follows the original owner after any transferOwnership, and only that address may seed before START = 1791817200.
4. The oracle signer is a single key with no rotation path; a rotation makes the Cabal die after 33 hours and PLEA trade freely (fail-open). (5) onOracleResult (src/CabalGate.sol:388-418) binds a verdict to the gate's domain and consumes requestId once but never compares questionHash or intakeId with the plea, so delivery to the right plea rests on the Intake (NotIntake blocks third parties). (6) seed() grants the Stacker an unlimited IMD allowance over the hook's whole ERC-20 balance, which includes retainedImd (appeal fees, closed-wall proceeds, Seasons.flushToWall leftovers); whoever controls the live Stacker can pull that reserve, after which the next rebalance's _settleImd reverts until retainedImd is reduced. (7) deployHook and post-START seed are permissionless; PLEA.setLauncher's deployment-block fallback (kept per the brief) requires the six constructors to run atomically in production. New this round and benign: Seasons.checkpoint() is public, so anyone may attribute a direct IMD donation to the running season; it only adds to the pot.