Validity depends only on the current operator having signed, block.timestamp <= expiry (no on-chain maximum lifetime; type(uint256).max is accepted) and the nonce matching nonces[to], which only advances on a successful withdrawal.

(a) Once signed, the only on-chain ways to stop a voucher are the global pause (which only delays it until unpause) or a global setOperator rotation that invalidates every honest in-flight voucher too; ECONOMY.md §12 blocks withdrawals at risk >= 70, so a farm frozen after signing is still paid until expiry. (b) A corrected voucher at the same nonce does not supersede the first: whichever the holder submits first wins.

(c) If voucher n for a recipient expires or is withheld, vouchers n+1.. are dead until the operator re-signs n. Fix per decision (C): bumpNonce(address to) callable by guardian or operator, and expiry <= block.timestamp + MAX_VOUCHER_LIFETIME enforced in withdraw().

Both OpenZeppelin VestingWallets start at the launch block's timestamp and vest linearly from the first second with no cliff; release(token) is permissionless. ECONOMY.md §11.7 lists both slices as 'Liquid? No' and says 'the circulating float at launch is the 15 % in the pool'; §9 says 'team (3 y vest)' and gives no community duration, so the 365-day constant exists only in the script (its comment says 'unless overridden' although nothing can override it).

After one day 13,698.63 ECU (team) + 41,095.89 ECU (community) is releasable, about 1.7x the daily Exchange budget; after 30 days about 1.64 M. Fix per decision (B): team = VestingWalletCliff with 36-month duration and 12-month cliff, community = VestingWallet 12-month linear with no cliff, and record both in ECONOMY.md §9 and §11.7 (team 15 % 12m cliff / 36m, community 5 % 12m linear). The existing test_nothingHasVestedAtLaunch checks only the exact launch second.

Boundary x invariant: the invariant 'the four targets receive 50/15/5/5 of what the launch sends' is enforced only on the balance present at the first successful call. Anyone holding any ECU can transfer 1 wei to the Distributor and call distribute(): toVault = toTeam = toCommunity = 0, toListings = 1, distributed = true.

Whatever arrives afterwards (the 75 % remainder on mainnet if the launch's transfer to remainderTo is not in the same transaction as the first ECU any third party can obtain, e.g. a swarm claimant; or any later top-up) is locked permanently, because the latch cannot be reset and the contract has no sweep.

On the Sepolia dry run the full supply is minted to the Distributor in the token's constructor, so the window is closed there; the exposure is the mainnet flow and any multi-step funding.

Fix: restrict distribute() to a configured caller, or require received >= an expected minimum set in the constructor, or make the latch per-call (allow repeated distribute() over the current balance with the same fixed fractions), which also removes the stranding of later arrivals.

Both vesting wallets take start = block.timestamp of the deploy transaction, and OpenZeppelin VestingWallet treats any token that arrives later 'as if locked from the beginning' (vestedAmount uses balance + released). On the dry run deploy and distribute are seconds apart.

On mainnet the script's own NatSpec says the token step is skipped and the token is created later by the launch, so the vesting wallets and vault are deployed first and the 20 M ECU arrive at launch time T_launch > T_deploy.

Precision x boundary: the community slice is then immediately releasable in the amount 5_000_000e18 * (T_launch - T_deploy) / 365 days, and the team cliff ends at T_deploy + 365 days, i.e. (T_launch - T_deploy) earlier than the 12 months after launch that ECONOMY.md §9/§11.7 state. Thirty days between deploy and launch make 410,958.9 ECU of the 'Liquid? No' community slice releasable in the launch block, 30x the 13,698 ECU §11.7 budgets for day one.

Fix: read START_AT from the environment (no default) for the mainnet path, or set it to the expected launch time, and assert start >= block.timestamp in the script; the dry run can keep block.timestamp.

FarmVaultTest never warps before its first withdrawal, so block.timestamp is forge's default 1 and the condition block.timestamp >= windowStart + OUTFLOW_WINDOW (1 >= 86400) is false on the first withdrawal: windowStart never moves off 0 and the whole suite runs inside an accidental window [0, 86400).

In test_theWindowReopensAfterTwentyFourHours, opened == 0, so 'opened + 24 hours' is 86400 and the assertion windowStart() == opened + 24 hours holds without ever checking that a window is anchored at the first withdrawal's timestamp; an implementation that advanced windowStart by fixed 24-hour multiples instead of to block.timestamp would pass the same test.

The contract is correct at real timestamps (test/scratch/Leads.t.sol test_lead5 shows windowStart == 1_800_000_000 after the first withdrawal), but the test coverage claim is weaker than it reads.

Fix: vm.warp(1_800_000_000) in setUp (as Distribute.t.sol does) and assert windowStart() == block.timestamp after the first withdrawal.

The split is computed over the balance at call time and the one-shot flag is set permanently. The contract has no sweep, no second pass and no minimum-received floor, so the guarantee in the NatSpec and ECONOMY.md 11.7 ('no dust is stranded') only holds if the full launch share is present before the first successful call. If any ECU reaches the Distributor after distributed is set it is locked forever.

Both current launch paths deliver the full amount atomically with token creation (the dry run mints in the ECU constructor; the custom_token launch sends remainderTo in its factory transaction), so this is a fragility rather than a live exploit; it is also encoded as expected in test/Distributor.t.sol test_distributeRunsOnce, which asserts 75e18 is left stranded.

A launch where the remainderTo transfer lands in a later transaction than the pool (so an outsider can buy 1 wei and call distribute() first), or any operational mistake sending the slice in two transfers, loses the whole slice.

Minimal fix preserving the design: drop the one-shot flag (each call splits the current balance, so repeated calls are harmless and late arrivals are recoverable), or require received >= MIN_RECEIVED (e.g. a constructor argument) before consuming the shot.

The NatSpec says the bound 'bounds how long a leaked or mistaken signature stays live' (lines 74-76 and 39-40). The check compares expiry against the submitting block, so a voucher signed with expiry = now + 30 days is refused today and accepted on any day from now + 23 days to now + 30 days, as long as the nonce and epoch still match. A mistaken voucher is therefore not voided by the bound; the operator must still bumpNonce or the guardian must rotate.

The practical hazard is operational: the backend sees VoucherLifetimeTooLong, treats the voucher as dead, and does not bump the nonce; if the recipient's next legitimate voucher is delayed or withheld, the old one clears later. Impact is bounded by maxVoucherAmount and the window cap and requires the nonce to remain unspent, hence low.

Fix options that keep the design: bind the issue time into the signed struct (issuedAt, require expiry <= issuedAt + MAX_VOUCHER_LIFETIME and block.timestamp >= issuedAt), or document that the bound is relative to submission and that a refused voucher must be voided with bumpNonce.

Economic Security 'starve shared capacity': maxOutflowPerWindow is global, not per recipient, and ECONOMY.md 1 says the deposited bucket is always withdrawable, so the operator is expected to sign vouchers returning a player's own deposit.

A player who deposits 250_000e18 (the script's INITIAL_MAX_OUTFLOW_PER_WINDOW, 0.25 % of supply) and withdraws it in five 50_000e18 vouchers fills the window; every other recipient's voucher reverts OutflowCapExceeded until the window rolls, and the griefer ends with exactly what it started with. Repeating this on the first block of each window keeps the exit mostly closed for honest players at gas cost only.

No funds are lost and the operator can decline to sign (off-chain mitigation), so low; but the on-chain rule has no per-recipient fairness and no reservation, and nothing in the docs tells the backend to ration signatures against the on-chain window.

Fix options that keep the design: a per-recipient daily sub-cap alongside the global one, or an explicit backend rule to pace signed amounts against remainingInWindow(); and document that a full window is a deliberate failure mode.

The dry-run script passes block.timestamp, but on mainnet the vesting wallets are deployed by the launch factory from launch.json static constructor arguments, and the brief's launch recipe runs constructors with no post-deployment call to correct them.

VestingWalletCliff computes cliff = start + 365 days and VestingWallet vests linearly from start, so start = 0 (an unset word) yields releasable == full slice immediately for both wallets, and any start more than 365 days in the past skips the cliff entirely. The same applies to CommunityVesting.sol line 22. Nothing on chain enforces the 12 m cliff / 36 m and 12 m linear commitments in ECONOMY.md 9 and 11.7 against the argument.

Gate 2 demotes this (privileged misconfiguration), hence low; it is listed because the manifest review is the only remaining check.

Fix: a constructor guard such as require(startTimestamp + CLIFF > block.timestamp) would catch it, but the protected floor rehearses constructors on an empty chain whose timestamp may not be real time, so a safer option is a guard against startTimestamp == 0 plus a documented manifest check that the start word equals the intended launch time.

The check compares expiry with block.timestamp at submission. Nothing in the signed struct says when the voucher was issued, so a voucher signed today with expiry = now + 100 days is refused today (VoucherLifetimeTooLong) but accepted on any day from now + 93 days until now + 100 days, as long as the recipient's nonce has not moved and the operator epoch is unchanged.

The NatSpec at line 75 ('Bounds how long a leaked or mistaken signature stays live') and the brief's intent for finding 4 (a mistaken signature must not stay live indefinitely) are not met: the signature stays live for its whole stated life, only its usable slice is bounded. The existing test test_aVoucherCannotOutliveTheLifetimeBound only submits immediately and so cannot see this.

Fix: add an issuedAt (or validAfter) field to the signed struct and require expiry - issuedAt <= MAX_VOUCHER_LIFETIME and block.timestamp >= issuedAt; or document that the bound is on submission and rely on bumpNonce/rotation for revocation.

Brief items (A) and (B) ask for the LIQUIDITY_ADDRESS slice to be removed and for .env.example's wording to say the beneficiaries are Safes (transferable owners). The script no longer reads LIQUIDITY_ADDRESS, yet the example still presents it as 'The LP slice' that 'goes to whoever will create the Uniswap V4 pool', and line 11 still says the beneficiaries 'cannot be changed afterwards', which contradicts src/TeamVesting.sol:12 (transferOwnership kept) and README.md:160-163.

ADAPTATION.md:74-79 records that the file was left untouched because it was outside the previous worker's write paths; the deliverable the brief named is therefore still missing and the file a deployer copies first disagrees with the code. It also points at Base Sepolia RPC variables while README.md:181 runs the dry run with SEPOLIA_RPC_URL on chain 11155111, so the documented environment does not run the documented command.

Fix: drop LIQUIDITY_ADDRESS, reword lines 11-13 to 'owners of the two vesting wallets; Safes in production; transferable (two-step if adopted), never renounceable', and name the Sepolia RPC variable the README uses.

distribute() is one-shot by design and the contract has no sweep or owner, so any ECU that reaches the Distributor after the shot can never move again.

On the Sepolia dry run and in an atomic custom_token launch the full amount arrives before anyone can call distribute(), so no griefing path exists there; the exposure is operational: if the mainnet launch delivers the 75 % remainder in more than one transfer, or a holder later sends ECU to this address by mistake, the balance is frozen and the fixed-supply accounting in ECONOMY.md 11.7 no longer sums.

Recorded as a documented trust assumption rather than a code defect; if the launch's remainderTo transfer is not guaranteed to be a single transfer in the same transaction as the mint, distribute() should only be callable once the expected amount (passed as a constructor constant) is present, or a permissionless forward-to-listings of any later balance should exist.

The brief (C) asks for a 'rolling 24-hour outflow cap'. The implementation opens a window at the first withdrawal after the previous window elapsed and resets the counter to zero at the boundary.

A leaked operator key therefore waits until the last second of a window, fills the cap, and fills it again one second later in the new window: the bound a defender can rely on inside any 24-hour period is 2 x maxOutflowPerWindow, and the whole 2x can leave in two adjacent blocks before the guardian Safe can react.

The NatSpec (lines 211-213) and README state this 'at most two windows' worth' behaviour, so it is a documented design choice rather than a hidden one, but it halves the protection the brief named and the README's 'a week of it stays under gate 6' arithmetic (7 x 250,000 = 1.75 M) actually admits 8 x 250,000 = 2 M in 7 days + 1 s against the 2.25 M gate.

If a true rolling bound is wanted, either track a small ring of per-hour buckets, or require windowStart + OUTFLOW_WINDOW to elapse from the last withdrawal (a sliding reset), or document the 2x figure as the real blast radius and size the cap accordingly.

The check compares expiry with block.timestamp at submission. A voucher signed with expiry = T+30 days reverts VoucherLifetimeTooLong at T, which the backend will read as 'the chain rejected it', but the same signature clears at any block in [T+23d, T+30d] without any further action by the operator.

The NatSpec at lines 74-76 ('Bounds how long a leaked or mistaken signature stays live') is therefore not what the code does: it bounds how long before expiry a voucher may be submitted, and a signature with a long expiry stays live until that expiry. The epoch and bumpNonce mitigate it (rotating or bumping kills the dormant voucher), but only if the backend knows a dormant voucher exists; the natural reading of a VoucherLifetimeTooLong revert is that it is void.

Consequence: a voucher the backend considers refused is paid weeks later, to the signed recipient, for the signed amount, at a nonce the backend may by then consider free.

Fix: either bind a signed issuedAt into the struct and require expiry <= issuedAt + MAX_VOUCHER_LIFETIME and block.timestamp >= issuedAt, or document the rule that any voucher that reverts VoucherLifetimeTooLong must be voided with bumpNonce or superseded at the same nonce before the backend forgets it.

Task (D) rewrote section 11.7 and the 'circulating float at launch' paragraph. The community slice is 5 % of 100 M = 5,000,000 ECU vesting linearly over 365 days, so one 365th is 13,698.63 ECU per day (the figure AUDIT.md finding 6 and ADAPTATION.md both quote). On the Sepolia dry run, where the whole supply passes through the Distributor, the community wallet holds (100 M x 5/75) = 6,666,666.67 ECU and releases 18,264.84 ECU on day one.

'685' matches neither; it is roughly 1/20 of the real number (as if the slice were 250,000 ECU). The sentence is used to argue that day-one vesting barely moves the float relative to the Exchange budget B (~33,000 ECU/day); at the real 13,700 ECU/day it is 40 % of B, which changes that argument. test/Vesting.t.sol test_dayOneAmounts and test/Distribute.t.sol test_dayOneReleasesNothingForTheTeamAndOneDayForTheCommunity assert the real figures.

Fix: replace 685 with about 13,700 (and note the dry-run figure if it matters).

Task (B) keeps transferOwnership so a Safe can migrate, and disables renounce so the slice cannot be bricked.

The remaining way to lose the slice is the one AUDIT.md finding 3 described for the guardian: Ownable's transferOwnership takes effect immediately, so a typo, a Safe that only exists on another chain, or a contract that cannot transact becomes owner() at once, and release(token) -- which is permissionless -- pays every future vested amount to that address with no way back.

OpenZeppelin's vendored Ownable2Step keeps transferOwnership (the nominee must call acceptOwnership) and would satisfy the brief's 'transferOwnership stays' while closing this. This is a privileged mistake, not a bypass, so it is rated low; it is reported because the brief's stated reason for the renounce guard (do not strand the slice) applies equally here, and because the beneficiary in production is a Safe whose signers will perform exactly this migration.

distribute() is permissionless and one-shot, and the only guard against an empty shot is received == 0. If the token exists and anyone other than the Distributor holds even 1 wei of ECU before the launch's remainder transfer lands, that holder can send 1 wei to the Distributor and call distribute(). distributed is then true, the 1 wei is split, and the 75 % that arrives later can never leave: there is no sweep, no retry and no owner.

On the Sepolia dry run there is no exposure because ECU's constructor mints the whole supply straight to the Distributor. On mainnet the exposure depends on the custom_token launch: if the pool, swarm and remainderTo transfers are in the same transaction as the mint, nobody holds ECU before the Distributor does and there is no window; if the remainder is sent in a later transaction, any pool buyer can brick the launch's largest slice.

Suggested fix that keeps the one-shot design: require a minimum received in distribute() set in the constructor (for example the expected launch share), or make the shot fire only when the balance is at least a constructor-fixed expectedAmount; either keeps distribute() permissionless and still leaves no EOA holding the supply.