I built the curb (CURB) token and committed it as 41e7e23. forge build, forge test (19 tests, run with the verifier's fuzz seed) and forge fmt --check all pass with solc 0.8.26.

The token (src/CurbToken.sol, contract CurbToken):

• It's a standard ERC-20 built on OpenZeppelin v5.1.0. name() returns "curb", symbol() returns "CURB", and it has 18 decimals.
• The constructor mints all 1,000,000,000 tokens once to the deployer (the launch factory). It takes no constructor arguments.
• How I read "Curb": the brief says only "Curb", so I took it to mean the supply can be curbed but never grown. Holders can burn their own tokens, or use burnFrom up to an allowance the holder gave. Burning only ever lowers the total supply. If "Curb" meant something else, this is the part to change.
• There's no owner, minting, pause, blacklist or transfer fee. So the transfers to the distributor and the pool, claims and trades all move exactly the amount sent, and the deployer can't touch anyone's balance.

Tests (test/CurbToken.t.sol):

• Success cases: name, symbol and decimals; the supply going to the deployer; transfers and approved transfers; burns; the launch transfers arriving whole.
• Failure cases: sending more than the balance, sending to the zero address, spending beyond or without an allowance, and burning more than the balance.
• Other checks: the deployer can't burn a holder's tokens, the common admin and mint calls don't exist, and the built code contains none of the opcodes the launch refuses.
• Fuzz tests: total supply is conserved across transfers, burning only lowers it, and overspending always reverts.

Setup and docs:

• foundry.toml pins solc 0.8.26 and sets bytecode_hash = "none".
• forge-std v1.9.7 and OpenZeppelin are copied into lib/ as plain files, with no submodules, so the build needs no network.
• README.md covers the assumptions, deployment parameters and who is responsible for what. Its "After launch" section is empty because there's nothing to configure.
• There's no deploy script and no launch.json, since the factory and the manifest step handle those.

Things to know:

• The provided protected tests import files the verifier supplies (floor/OwnerChecks.sol, src/LaunchLiquidity.sol, Uniswap v4-core), which aren't in this repo. So I couldn't run those tests here. I checked the token against what they test instead.
• Git had no author set on this machine, so I made the commit as luigidelllebigocche with your account email. Change the author if you'd rather it be something else.
• Passing tests isn't an audit. An independent review should still happen before release.

Created launch.json matching CurbToken’s zero-argument constructor, exact supply, and required pool and economics values. Only launch.json changed.

forge build succeeded. All 19 tests passed with the supplied fuzz seed. Manifest fields and constructor ABI checks passed.

The review is complete and the result is clean: no defects found in CurbToken. The findings file holds an empty findings list and a coverage row for every entry point, plus the invariants and periphery I checked.

What I reviewed

• src/CurbToken.sol is a 24-line wrapper over OpenZeppelin 5.1.0 ERC20 and ERC20Burnable with no overrides. The constructor mints exactly one billion tokens with 18 decimals to the deployer and no other supply-increasing path exists in the compiled ABI.
• Execution Trace: traced approve, transfer, transferFrom, burn and burnFrom through _update, _transfer, _approve and _spendAllowance. Every value-moving path either reverts or moves exactly the requested amount. Infinite allowances are untouched, finite ones are reduced exactly.
• Periphery: read the vendored ERC20, ERC20Burnable and Context sources in full. The unchecked blocks are guarded by prior checks, and git shows the library tree unchanged from the accepted commit.
• First Principles: the only assumption the token makes is that the deployer is the factory, which the launch guarantees. No receive, fallback, owner, pause, blacklist, initializer or upgrade path exists. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.

How I checked it

• The author's 19 tests pass, including fuzz runs and the opcode scan.
• I wrote a scratch suite that replayed the protected floor's checks locally: the ten admin signatures from an attacker and the factory, the twelve privileged signatures from the factory, a factory transferFrom against a holder, the whole-arrival of the ten percent swarm share and its claim, ETH rejection and burnFrom allowance accounting. All seven passed. The scratch file was removed afterwards, and the working tree is clean apart from the findings file.
• The aderyn large-numeric-literal lead is a style note only. The literal evaluates to 1e27, which equals the manifest supply.

Coverage record: all five listed entry points are marked holds, with five additional rows for the supply, conservation, runtime, periphery and manifest invariants. No launch.json exists yet, so the manifest row records what it must contain when written: an empty constructorArgs list and the exact supply.

The review is complete and the findings file is written. No defects found.

Result: .imd-findings.json holds an empty findings list and ten coverage rows, all holds, one for each of the five listed entry points plus the constructor, the access-control surface, the trust-gap seams, the asymmetry pairs, and the aderyn lead.

What I checked, in the assigned area:

• Access control. The compiled ABI has exactly five state-changing functions, all inherited from OpenZeppelin v5.1.0, and no owner, role, initializer, upgrade path, receive or fallback. _msgSender is plain msg.sender, so no forwarder can impersonate a holder. The deployer, which is the factory under CREATE2, has no power beyond its own balance: burnFrom and transferFrom from it against a holder revert without allowance.
• Trust gap. There is no privileged actor, setter, fee recipient or paired pricing formula, so no seam exists where a permitted caller can extract value or treat one caller class differently from another.
• Asymmetry. burn and burnFrom are exact mirrors of the constructor mint through the same _update, and burnFrom spends allowance through the same _spendAllowance as transferFrom, including the infinite-allowance case. Storage is only OpenZeppelin's balances, allowances, supply, name and symbol, each written and read symmetrically.
• Launch floor. Supply is minted once to msg.sender as 1e27 units with 18 decimals, matching the brief. Transfers have no fee or caller-class branch, so the distributor, pool seed, claim and swap flows move exactly what they request. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Evidence run: the project's 19 tests pass, and six scratch probes under test/scratch/ mirroring the protected floor's privileged-call and supply-growth checks pass. The aderyn large-numeric-literal lead is a style note on a compile-time constant that equals the manifest supply, not a defect.

Not reached: the protected Token.protected.t.sol itself cannot run here because it imports Uniswap v4-core, which is not vendored. Its token-side assertions were reproduced in the scratch probes instead. No application contracts exist, so the owners floor has nothing to check.

The review is complete. The findings file is in place with an empty findings list and nine coverage rows, and the working tree is unchanged apart from it.

Result: no defects found in the math, boundary or numerical-gap areas.

The token in src/CurbToken.sol is a 25-line wrapper over OpenZeppelin v5.1.0 ERC20 plus ERC20Burnable, with no owner, no fee logic and no arithmetic of its own beyond the supply constant. I verified the vendored OpenZeppelin files match the upstream 5.1.0 text, including the Context base returning plain msg.sender.

What I checked against the three guides:

• Math Precision. The contract has no division, rate multiplication, fixed-point scale, downcast or oracle input. The only arithmetic is the constant 1_000_000_000 * 10 ** 18, which folds to exactly 1e27 and matches the README and manifest supply. The aderyn "large numeric literal" lead is a style lint, not a defect.
• Boundary. There are no external calls, no payable functions, no sentinel-address branches, no bytes decoding, and no receive or fallback. ETH sent with or without calldata reverts. Zero amounts, self-transfers, type(uint256).max amounts, max and max-minus-one allowances, zero-address sender, spender and receiver, and burning the whole supply all behave as the ERC-20 standard requires.
• Numerical Gap. The unchecked subtractions in _update and _spendAllowance are each preceded by a strict < revert, so sum-of-balances equals total supply and supply only decreases. A 2,000-run multi-actor fuzz over transfer, approve, transferFrom and burnFrom confirmed exact allowance and balance arithmetic. The 10/50/40 launch split of 1e27 has zero remainder and arrives whole to the wei.

All five ABI entry points are marked holds, plus four invariant rows covering the constructor mint, supply conservation, launch-flow exactness and decimals. The existing suite of nineteen tests and forge fmt --check also pass. The scratch tests I wrote under test/scratch/ were run and then removed, so nothing outside the findings file was left in the tree.

The review is complete. The findings file holds an empty list and a full coverage record, and the working tree is clean apart from that file.

Result: no defects in the Economic Security, Invariant or Flow Gap areas. The CURB token is a 24-line wrapper over OpenZeppelin v5.1.0 ERC20 plus ERC20Burnable, with no owner, no mint path after the constructor, no fees, no external calls and no callbacks.

What I verified:

• Supply and conservation. The constructor mints exactly 1e27 units to the deployer. A fuzz over random sequences of transfer, transferFrom, burn and burnFrom kept sum-of-balances equal to totalSupply and totalSupply at or below the initial supply on every run.
• Launch flow exactness. Factory to distributor to claimants, and factory to pool to trader and back, all moved exactly the requested amounts with supply unchanged. The protected floor's swarm, seed and swap checks have nothing in this token to trip on.
• Privilege. The deployer with no allowance cannot burnFrom or transferFrom a holder. Allowance semantics match OpenZeppelin exactly, including the infinite-allowance case.
• Boundaries. Zero-value and self transfers succeed, whole-balance transfer and burn succeed, transfer and approve to the zero address revert, raw ETH sent to the token reverts.
• Dependency integrity. All six vendored OpenZeppelin files the token inherits are byte-identical to the upstream v5.1.0 tag.
• ABI surface. The compiled ABI exposes only the five listed state-changing functions, no receive, fallback or payable function.
• Static-analysis lead. The aderyn large-numeric-literal note is style only. The literal evaluates to the manifest supply.

Two design points are trust assumptions rather than defects, and the README already states both. The brief says only "Curb", and the builder read it as holder-initiated burns, so burn and burnFrom exist. The standard ERC-20 approve race applies, and OpenZeppelin v5 ships no increaseAllowance helpers.

Coverage: all five entry points are marked holds, plus five rows for the invariants and integrity checks above. Nothing was left unreached. The scratch test I used was removed since no finding needed a proof.

Added failure-path and boundary tests, seven fuzz properties, and three stateful invariants covering balances, burns, and allowances.

Offline forge build and forge test pass with the required seed: 51 tests passed, including 32,768 invariant handler calls.

Only test/ changed. No defects found in these checks.

The review is complete and the findings file is written with an empty list and a full coverage record.

Outcome: no defects found. The four specialists and the test writer reported nothing, and nothing I checked produced a reproducible defect.

What I verified

• The token in src/CurbToken.sol is a 24-line wrapper over OpenZeppelin ERC20 and ERC20Burnable with a zero-argument constructor that mints the whole supply to the deployer.
• The six vendored OpenZeppelin files the token depends on are byte-identical to upstream v5.1.0, so the library behaviour is the published one.
• The project's own 51 tests pass, including the invariant suite.
• A scratch test I wrote and then removed deployed the token through CREATE2 from a deployer contract and confirmed the supply and deployer balance match the manifest, the swarm flow arrives whole, the deployer cannot pull or burn a holder's balance without allowance, the ten common mint and admin selectors all revert, the contract rejects ETH, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Compiled sizes are well under the limits, and the ABI exposes only the five listed entry points plus view functions.
• The manifest uses only schema keys, lowercase addresses, the exact supply string, an empty constructor argument list matching the constructor, and notes under the length cap.

Static analysis leads: Slither reported nothing. Aderyn's large-numeric-literal note on line 19 is a style remark about a correct compile-time constant and is not a defect.

Coverage: all five entry points are marked as holding, with four extra rows for the supply, no-growth, opcode and size invariants and the aderyn lead.