The report is being written.3 of 4 specialists have reported. The judge reproduces, merges and ranks what they found, and its findings appear here.

1. Posted19 minto the first attempt
2. Audit mathAgent #1560 reviewing

   #1560Clauderunningclaude-fable-5-1, for 1 h 8 min
3. Audit permissionsAgent #481found 1 info

   The review of area A3 is complete. The findings file at .imd-findings.json holds one Info item and nothing above it.

   Result. No Critical, High, Medium or Low defect found in Staking, funds and distribution at this commit. The one Info finding is a liveness nit, not a loss.

   What I verified, with evidence

   • Suite: 210 local tests pass after a clean build.
   • Vault hold (invariant 14): a 2,000-run fuzz chained same-block transfers (to self, to a wallet with older unheld stake, onward, and back) and asserted the fresh deposit never becomes redeemable through any wallet and that effective held shares never exceed balances. It held.
   • Drip bound (invariants 13 and 14): a 2,000-run fuzz over every allowed owner setting (smoothing 1 to 30 days, catch-up 1 h to smoothing/7, min drip 0 to 100k, any buffer, any gap) confirmed no single drip exceeds 1/7 of the buffer except the documented sub-1-$PONDPAD sweep.
   • Inflation and donation: totalAssets is the tracked count, and syncRewards only works with at least 1 $PONDPAD and 1e18 shares staked, so a donation can neither move the empty vault's price nor make a victim's rounding loss exceed 1 wei per deposit at any feasible donation size.
   • Powers and rescue: every vault and dripper owner path is behind onlyOwnerActive, both rescues refuse the asset and the share token, and FixedOwnable blocks transfer, renounce and handover. A pause is clamped to 3 days and to powersExpireAt, with the 4-day gap preserved on early resume.
   • PadBuyer: IMD leaves only to the PoolManager and the keeper tip, $PONDPAD only to the dripper, the limit is ref - deviation - slippage clamped to MIN_TICK + 1, and the reference read is the caught-up view that nothing in the current block moves.
   • Funds (invariant 15): splitter outputs equal inputs with the remainder to treasury, shares stay in range, only $PONDPAD is split as a second token, WorkerFund pays one address, GrowthFund caps per epoch and refuses uncapped tokens.
   • Airdrop and vesting (invariants 20, 21): leaf format matches OZ StandardMerkleTree with double hashing, vouchers bind account, X id hash, tweet hash and deadline under the EIP-712 domain, each wallet, handle and tweet is consumed once, delegation nonces are consumed before effect, vesting and sweep timing are consistent at the 180-day boundary, and team vesting pays 1/6 at the cliff and all at day 180.
   • Earlier fixes: every A3 row marked fixed in FINDINGS.md (R1 through R5 and P6-3) is present in the source and closes the path it names.

   The one finding (Info). PadBuyer.buy() calls forward() first, but a revert for TooSoon or NothingToBuy rolls the forward back, and the keeper never sends forward() on its own. The stakers' $PONDPAD fee share therefore waits in PadBuyer until an IMD inflow of at least minChunk lets a buy succeed. Anyone can call forward(), so nothing is lost. Suggested fix is in the keeper: send forward() whenever PadBuyer holds $PONDPAD.

   Out of scope but noted. The scratch tests were removed after use. Fork tests were not run, since they need network access.

   ran onclaude · claude-fable-5-1 · 42 turns · 18m 44s · 450 in · 61.3K out · 3.4M cached

   submissionf955bd47f884f5fcd0681b2307191b37bd62840a725b2e38fd17f1334011a192

   device72f49cf84b9ab056dea179fcfdd8dfe8080c92207c81b289111922ab603e0442

   started frombaf7932c456e9e7fc9d8117ade2536c98e58ee99

   bundlenone

   • infoPadBuyer.buy() rolls back its own forward() whenever it reverts, and the keeper never calls forward(), so the stakers' $PONDPAD fee share waits in PadBuyer until IMD arriveslaunchpad/contracts/src/PadBuyer.sol:78

     buy() calls forward() first, then reverts TooSoon or NothingToBuy when the interval has not passed or the buyer holds less than minChunk IMD. A revert undoes the forward, so the $PONDPAD the FeeSplitter sent to PadBuyer (the stakers' 40% of the market's sell-side $PONDPAD fees, D-38) stays parked at PadBuyer. keeper/keeper.mjs only ever sends PadBuyer.buy, and only when the buyer holds >= 1 IMD and its interval has passed; it never sends PadBuyer.forward.

     At the mainnet defaults PadBuyer spends 25 IMD every 10 minutes (3,600 IMD/day), well above the expected IMD inflow, so it sits near zero IMD most of the time: every collectFees that delivers less than 1 IMD to PadBuyer leaves that collection's $PONDPAD share waiting until a later IMD inflow of at least minChunk lets a buy() succeed.

     No funds are at risk and forward() is permissionless (any wallet can call it), so this is a liveness delay of rewards reaching the dripper, not a loss.

     Fix: in the keeper, send PadBuyer.forward() whenever pondpad.balanceOf(padBuyer) > 0 (independently of the IMD check), or in buy() return early without reverting after the forward (the keeper simulates before sending, so the no-op would need a view such as canBuy() for it to gate on). Not a THREAT-MODEL invariant: invariant 14 only requires that PadBuyer can send $PONDPAD nowhere but the dripper, which holds.

     whole finding

     Foundry, on StakingTest's fixture (test/Staking.t.sol): _graduate(); _swap(false, 2_000_000e18); _nextBlock(); controller.collectFees(); so PadBuyer holds share = pondpad.balanceOf(buyer) > 0 and some IMD.

     Move the IMD out (vm.prank(address(buyer)); imd.transfer(0xdead, imd.balanceOf(buyer))) to model a buyer that has spent its chunks.

     Then buyer.buy() reverts NothingToBuy(); expected (per the NatSpec 'Forwards any $PONDPAD held to the dripper, then buys'): the $PONDPAD reached the dripper; actual: pondpad.balanceOf(buyer) == share and pondpad.balanceOf(rewards) unchanged.

     A direct buyer.forward() then moves share to the dripper.

     The same happens with TooSoon inside the 10-minute interval.

     Scratch test test_forwardRolledBackWhenBuyReverts (inheriting StakingTest) passes on this code with exactly those assertions.

     whole reproduction
4. Audit economicsAgent #1166found 1 info

   Review complete. The findings file is in place at the repository root with one Info-level item; nothing at Critical, High, Medium or Low survived verification in area A3.

   What I covered

   • Read all twelve files in the area plus the generator, the Solady ERC-4626/ERC-20 base, the hook's reference-tick and claim-settlement paths, and the deploy wiring for the staking, fund and distribution contracts.
   • Checked THREAT-MODEL invariants 13, 14, 15, 20 and 21, and the owner bounds in section 1 for the vault (7-day timelock), dripper, buyer and airdrop (48 h timelock).
   • Re-verified every A3 fix in the ledger (R1-A3-1 to R5-A3-5): each is present in the code, complete, and opens no new path. The generator reproduces the committed vault and dripper byte for byte.
   • Ran the whole local suite (210 tests pass, including the staking invariant run) and wrote scratch probes under test/scratch/.

   What the probes showed

   • Vault: a 512-run fuzz of deposit/mint then redeem with rewards in between never profits. The one-block hold cannot be shed by self-transfer, transfer and return, or operator transfer. The residue after the last staker exits is 1 wei. Rounding favours the vault.
   • Dripper: a second drip in the same second reverts, a full-window drip releases exactly 1/7, and a whale that stakes before the drip and leaves next block takes only its pro-rata share of that 1/7 (the accepted R1-A3-3 class). Closing and reopening the vault only forfeits elapsed time.
   • PadBuyer: a sandwich of a 500 IMD chunk at the defaults loses the attacker 0.42 IMD; a 1000-tick pump held for 8 blocks still makes the buyer refuse, since the reference moved only 800 ticks.
   • Airdrop and vesting: claim totals equal the 50M exactly, partial claims sum to the allocation, the 180-day boundary is consistent between claim and sweep, wrong-amount and empty proofs are refused, and the delegation nonce blocks replay.

   The one finding (Info)

   Solady's ERC-20 gives the canonical Permit2 address a fixed infinite allowance by default. PadToken overrides this off, but StakedPONDPAD (via the generator) and PondPadToken keep it, so holders cannot revoke Permit2 on $PONDPAD or sPONDPAD and approve(PERMIT2, 0) reverts. Permit2 is live on Robinhood and only acts on the holder's own signature, and the hold still applies, so this is a documentation and consistency point, not a theft path. The fix is a one-line override in the generator.

   Limits

   Fork tests were not run (no network use needed for this area). The probes are in test/scratch/, which is not kept.

   ran onclaude · claude-fable-5-1 · 63 turns · 24m 34s · 610 in · 77K out · 4M cached

   submission4ee5bf7f4fdad757006b5e558f1e8c61ea29c4a84caa4b7382e21b6b0eec8b38

   device644eb561f6d70a85d4f5be4eea313a7bd6222047c8a74d6ead4704470736c193

   started frombaf7932c456e9e7fc9d8117ade2536c98e58ee99

   bundlenone

   • infosPONDPAD and $PONDPAD give the canonical Permit2 address a fixed, unrevocable infinite allowance (Solady default); PadToken turns it off, these two do notlaunchpad/contracts/src/StakedPONDPAD.sol:37

     Solady's ERC20 (lib/solady v0.1.9, the base of StakedPONDPAD through ERC4626 and of PondPadToken) returns true from _givePermit2InfiniteAllowance() by default: allowance(holder, 0x000000000022D473030F116dDEE9F6B43aC78BA3) is always type(uint256).max, transferFrom by that address skips the allowance check, and approve(PERMIT2, x) for any x other than max reverts Permit2AllowanceIsFixedAtInfinity(). PadToken (the coin token) overrides it to false with the comment "No default infinite allowance for Permit2; approvals work the standard way", but upstream/make_staking.py does not add the override to the generated StakedPONDPAD and PondPadToken has none, so every staker's sPONDPAD and every holder's $PONDPAD carries a standing allowance nobody can revoke.

     Permit2 is deployed on Robinhood mainnet and testnet (HANDOFF lists it), it is immutable and audited, and it only moves tokens on the holder's own Permit2 signature or Permit2-internal approval, so this is the usual Solady trade-off, not a theft path; the one-block hold still applies to a Permit2 transferFrom (_beforeTokenTransfer runs).

     It is reported because it is undocumented (THREAT-MODEL invariant 13 and ARCHITECTURE describe sPONDPAD as plain ERC-4626 shares; DECISIONS D-77 only mentions Permit2 for market trades of $PONDPAD), inconsistent with the project's own PadToken, and it widens the blast radius of a Permit2 signature phishing to staked positions as well.

     Fix (no behaviour change for the site, which can approve Permit2 explicitly): add to make_staking.py an override function _givePermit2InfiniteAllowance() internal pure override returns (bool) { return false; } in StakedPONDPAD (and the same in PondPadToken if the standing allowance is not wanted there either, or document it in THREAT-MODEL section 3 if it is), with a test that approve(PERMIT2, 0) succeeds and allowance reads 0.

     whole finding

     Deploy PondPadToken and StakedPONDPAD; a holder deposits 10e18 $PONDPAD.

     Expected (plain ERC-20/ERC-4626): allowance(holder, 0x000000000022D473030F116dDEE9F6B43aC78BA3) is 0 for both tokens and approve(PERMIT2, 0) succeeds.

     Actual: both allowances read type(uint256).max, both approve(PERMIT2, 0) calls revert Permit2AllowanceIsFixedAtInfinity(), and code placed at that address (vm.etch in the probe) calls transferFrom(holder, attacker, balanceOf(holder)) on sPONDPAD with no approval and succeeds in the next block.

     Probe: test/scratch/ProbePermit2.t.sol, test_fixedInfiniteAllowance (passes on this code, i.e. the behaviour is present).

     whole reproduction
5. Audit flowAgent #871found 3 info

   Review complete. The findings file at the repository root holds three Info items and no Critical, High, Medium or Low finding for area A3.

   What I checked

   • All twelve area files in full, plus Solady's ERC4626/ERC20, the hook's referenceTick/afterSwap close logic, PadBurner, withdrawFees/settleClaims, and the deploy wiring for staking, airdrop and vesting.
   • The generated vault and dripper match make_staking.py exactly (regenerated in a temp dir and diffed).
   • THREAT-MODEL invariants 13, 14, 15, 20, 21 and the staking part of 22. Each held: no rescue reaches stake, share token or buffer; pauses are bounded and end at powersExpireAt; totalAssets is the tracked count and rewards only open at 1e18 shares and 1 $PONDPAD; one drip is at most 1/7 of the buffer plus the sub-1 $PONDPAD sweep; PadBuyer's IMD goes only to the pool and the capped tip, its $PONDPAD only to the dripper; splitter sums and ranges hold; airdrop leaf format, voucher binding, 100-distinct-wallet count, nonces, vesting and sweep timing are correct; team vesting pays only the beneficiary.
   • Every A3 fix marked fixed in the ledger (R1-A3-6/7, R2-A3-1/3/5, R3-A3-1/2/5, R4-A3-1/3/5/7/8, R5-A3-2/3/4/5, P5-3) is present, correct and opens no new path I could find.
   • Baseline: 61 area tests and the staking invariant campaign pass. Scratch probes under test/scratch/ (yours to discard) confirmed the ERC-4626 max-view deviation, operator exits, rescueETH, and late vesting funding.

   Findings (all Info)

   1. StakedPONDPAD.maxDeposit/maxMint return the max for address(0) and the vault while deposit/mint revert InvalidReceiver. Spec conformance only.
   2. $PONDPAD sent straight to TeamVesting joins the team schedule; AirdropDistributor extras are swept to stakers. Undocumented sinks, sender's own funds only.
   3. Untested edges: operator exits on sPONDPAD, both rescueETH functions, grant to address(0), vesting top-ups. All behave correctly on probing.

   Leads I rejected after tracing: a stray lump in a closed vault cannot open rewards (it is not counted until syncRewards, which needs the vault open); residue after a full exit is bounded near 1e-12 of assets; the pause cadence cannot be shortened; the dripper floor and dust sweep stay within the documented bound; PadBuyer's guard direction and limit clamp are right. No proofs were attached since nothing reached High.

   ran onclaude · claude-fable-5-1 · 64 turns · 33m 25s · 740 in · 73.3K out · 5.7M cached

   submission65da3a0c1739562b710530cc770b28bc43242ee5ed824b03dfdee8505ed6fcd1

   device3987a51ff810f3b94af8dfb42af95303b2f982c1daacb7991257d7277c185cd8

   started frombaf7932c456e9e7fc9d8117ade2536c98e58ee99

   bundlenone

   • infoStakedPONDPAD.maxDeposit / maxMint report no limit for receivers deposit and mint always refuse (ERC-4626 max-view deviation)launchpad/contracts/src/StakedPONDPAD.sol:264

     Since R4-A3-1, _deposit reverts InvalidReceiver when to is address(0) or the vault itself, but maxDeposit(to) and maxMint(to) (lines 263-269) still return type(uint256).max for those receivers. ERC-4626 requires the max views to return the largest amount that would not cause a revert for that receiver, and the pause-aware overrides already follow that rule for the paused case.

     An integrator that previews with maxDeposit before calling deposit gets a non-zero limit and then a revert. No funds are at risk and nothing in PondPad relies on these views; this is a spec conformance nit, the same class as R3-A3-4 / R3-A3-6 (exit with maxRedeem).

     State: any vault.

     Call vault.maxDeposit(address(0)) -> type(uint256).max; vault.maxMint(address(vault)) -> type(uint256).max.

     Then vault.deposit(1e18, address(0)) and vault.mint(1e24, address(vault)) both revert InvalidReceiver().

     Expected per ERC-4626: maxDeposit / maxMint return 0 for those two receivers.

     Verified with a scratch test (test/scratch/Probe.t.sol, test_probe_maxViewsForRefusedReceivers, passes on the current tree, i.e. the deviation is present).

     Fix: in maxDeposit / maxMint return 0 when to == address(0) || to == address(this) (and add the same lines to make_staking.py).

     whole reproduction

   • infoUndocumented sink: $PONDPAD sent straight to TeamVesting is added to the team's schedule and paid to the beneficiarylaunchpad/contracts/src/TeamVesting.sol:44

     vestedAmount defines the allocation as the contract's live balance plus what it released, so any $PONDPAD that reaches the vesting contract after deploy (a mistaken transfer, a grant, a sink pointed at it) becomes part of the 20M schedule and vests to the beneficiary (the team Safe) on the same clock; after day 180 it is releasable at once.

     THREAT-MODEL §3 lists every other address that behaves as a sink (PadHook, PadMarketHook, BondingCurve, a coin's own address, the vault via syncRewards) but not this one, nor AirdropDistributor (anything sent there is swept to the dripper after the claim window, sweep sends the whole balance). Only the sender's own funds are affected; invariant 21 (always to the beneficiary) holds. Same class as R4-A1-4 / R3-A2-4 (documented, no code change).

     Scratch test test/scratch/Probe2.t.sol test_probe_teamVestingLateFunding (passes on the current tree): fund TeamVesting with 20M, set the market clock, warp 200 days, release() pays the Safe 20M; then transfer 1e18 to the vesting contract from any wallet: releasable() returns 1e18 and release() pays the Safe 20M + 1e18.

     Expected (docs): THREAT-MODEL §3 names TeamVesting and AirdropDistributor as sinks (tokens sent there go to the team / to stakers via the dripper).

     Fix: documentation only.

     whole reproduction

   • infoUntested A3 edges: operator (by != owner) exits on sPONDPAD, rescueETH on vault and dripper, GrowthFund.grant to address(0), late funding of TeamVestinglaunchpad/contracts/test/Staking.t.sol:928

     The suite never exercises an ERC-4626 exit where the caller is an approved operator (redeem / withdraw with by != owner), so the hold check against the owner's unheld shares plus Solady's _spendAllowance path is untested (every redeem / withdraw in Staking.t.sol and the invariant handler is self-owned); rescueETH on StakedPONDPAD and RewardDripper has no test; GrowthFund.grant(..., address(0), ...) -> ZeroAddress has no test; and TeamVesting funded after openedAt is untested.

     All four behave as intended on the current tree (checked in test/scratch/Probe2.t.sol: an operator cannot redeem the owner's held shares in the deposit block, can redeem / withdraw the unheld part next block to its own address, and maxWithdraw is exact; rescueETH pays the owner's target; late funding vests to the beneficiary). Same class as R3-A3-9 / R4-A3-9 / R5-A4-8 (coverage).

     Run grep -n "redeem(\|withdraw(" test/Staking.t.sol test/StakingInvariant.t.sol: every exit names the same account as caller and owner; grep -n rescueETH test/*.t.sol finds nothing; grep -n "GrowthFund.ZeroAddress" test/*.t.sol finds nothing.

     Expected: a test of an operator exit of held and unheld shares (the hold is keyed on the owner, not the caller), of both rescueETH functions (powers, expiry), of grant to address(0), and of a TeamVesting top-up.

     Fix: tests only, e.g. the three probes in test/scratch/Probe2.t.sol moved into Staking.t.sol / Funds.t.sol / Distribution.t.sol.

     whole reproduction
6. Audit judge

   waits onAudit math, Audit permissions, Audit economics, Audit flow