Done. The paperbird token project is built, verified and committed on main as commit bab49d5.

What was delivered

• src/PaperbirdToken.sol: a fixed-supply ERC-20 named paperbird, symbol PAPERBIR, 18 decimals. The constructor takes no arguments and mints 1,000,000,000 tokens once to msg.sender, which is the IMD factory at launch. It composes OpenZeppelin v5.4.0 ERC20, ERC20Burnable and ERC20Permit. There is no owner, mint, pause, blocklist, fee or upgrade path, so the supply can only ever shrink and no privileged hand can move or freeze a holder. The Solidity name is 14 characters, within the manifest's limit.
• test/PaperbirdToken.t.sol and test/DeployPaperbird.t.sol: 37 tests covering metadata, the one-time mint, exact transfers, allowances, burn and burnFrom, permit success and failure paths (expired, wrong signer, replay, wrong chain), a sweep of mint and privileged-call selectors that must all revert, an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and four fuzz properties.
• script/DeployPaperbird.s.sol: a review-only script whose deploy() function is tested directly. It reads no environment and takes no configuration.
• foundry.toml pins solc = "0.8.26", bytecode_hash = "none", cancun, optimizer on, ffi off, no filesystem permissions.
• lib/: forge-std v1.9.7 and OpenZeppelin v5.4.0 vendored as ordinary files from release tarballs. No submodules.
• README.md: assumptions, the launch's deployment parameters and economics, an empty "After launch" section, and operational responsibilities.

Checks

forge build, forge test with the verifier's fuzz seed, and forge fmt --check all pass. A scratch test replicating the floor's flow (CREATE2 from an etched factory, 10% to the distributor and claimed whole, the privileged-call sweep from the factory) also passed before I removed it.

One sandbox artefact to know about

The sandbox bind-mounted a nested lib/openzeppelin-contracts/.gitmodules read-only during the initial forge install, so it cannot be deleted. It is not staged or committed, and git only honours the root .gitmodules, which this repository does not have. The commit contains no submodule entries.

Open item for the requester

Burning was included as a holder-only convenience. If a strictly constant supply is preferred, removing ERC20Burnable is a one-line change, noted in the README.

Created launch.json matching PaperbirdToken, its exact supply, empty constructor arguments, and required pool and economics values.

forge build succeeded. All 37 tests passed with the supplied fuzz seed. Only launch.json changed.

I found no access-control, trust-gap or asymmetry defects in src/PaperbirdToken.sol that I could back up with a reproduction. .imd-findings.json holds an empty findings list and a coverage record marking all 6 entry points holds, plus 2 invariant rows. I changed no project files. A clean review does not prove there are no defects.

What I checked:

• Who holds power after deployment: nobody. The contract has no owner, role system, setter, mint function, pause, blocklist, fee or upgrade path. The constructor takes no arguments, gives out no role, and mints the 1e27 supply once to msg.sender (the factory at launch).
• burnFrom: it is the only function on the floor's list of privileged calls, and it checks the caller's allowance before burning. A call from the factory against a holder who never approved it reverts with ERC20InsufficientAllowance, so the factory cannot burn anyone's balance.
• burn, approve, transfer, transferFrom: all are unmodified OpenZeppelin v5.4.0. Each only touches the caller's own balance, or an allowance the owner granted. No address skips the allowance check, and transfers move exactly the amount sent, so the launch flows (factory to distributor, distributor to claimants, pool seed and swaps) arrive whole.
• permit: it checks the deadline, uses up a per-owner nonce, rebuilds its signing domain if the chain id or contract address changes, and rejects malformed signatures and a zero signer.
• Vendored OpenZeppelin: I spot-read the key internals and found no edits. That was a read, not a byte-for-byte comparison with upstream.

Leads I dropped:

• The aderyn "large numeric literal" warning is just the supply constant 1_000_000_000 * 10 ** 18.
• Front-running a permit, and the classic approve race, are known properties of any ERC-20 with permit, not defects in this code.

The repo's existing suite passes (37 tests, forge test). I couldn't run the floor's protected tests because they import harness files that aren't in this repo; I traced their burnFrom and privileged-call checks by reading them instead.

The review is complete and the findings file is written. No defects were found in the assigned area.

Result: .imd-findings.json holds one informational note and ten coverage rows. All six verifier-listed entry points are marked holds. The repository tree is unchanged apart from that file, and the scratch test and download directory were removed.

What I checked, per guide:

• Execution Trace. Traced approve, transfer, transferFrom, burn, burnFrom and permit from entry to final state through OpenZeppelin's _update, _approve and _spendAllowance. Every value-moving path moves exactly the stated amount with no fee, hook or callback. Failure paths revert cleanly and leave allowances untouched, including burnFrom when the allowance check passes but the balance check fails. The launch flow was emulated from a CREATE2 factory-like deployer: the whole supply lands on the deployer, the swarm share arrives whole and is claimable whole, and supply stays constant.
• Periphery. Diffed the vendored OpenZeppelin and forge-std sources against the published 5.4.0 and 1.9.7 releases. Every Solidity file is byte-identical. Only documentation files differ. The base contracts the token trusts are therefore genuine.
• First Principles. Checked constructor assumptions: no arguments, no external calls, supply constant evaluates to exactly 1e27, mint goes to msg.sender once. Checked permit edge cases: inclusive deadline, nonce consumed once, high-s and zero-owner signatures rejected, EIP-712 domain name matches name() and is bound to chain id and contract address. Unknown selectors and plain ether transfers revert.

The one note, severity info: permit can be front-run by any relayer. The allowance is then set correctly, but the owner's own resubmission reverts because the nonce moved. This is standard ERC-2612 behaviour, not a contract defect. It matters only if the flappy-bird frontend bundles permit with a dependent action in one transaction. The frontend should read the allowance first and skip permit when it already covers the value.

Static-analysis leads: Slither reported nothing. Aderyn's large-numeric-literal lead at line 36 is the supply constant, which evaluates correctly, so it is not a finding.

Not reached: no launch.json exists yet, since the manifest step has not run. The README's intended values match the brief and the example manifest, and the contract name and empty constructor argument list are schema-valid.

I added two test files to the existing suite and found no defects in the token. All 65 tests pass (forge build and forge test with the verifier's fuzz seed, 0 failed, 0 skipped). The only new files are the two tests below. Nothing was left outside test/, and I didn't write a findings file because there was nothing to report.

test/PaperbirdToken.invariant.t.sol runs random call sequences against the token. A handler contract calls transfer, approve, transferFrom, burn, burnFrom, permit and time jumps, using five accounts. It keeps its own record of what every balance, allowance and permit counter should be. It also makes calls that ought to fail on purpose (amounts one over the limit, a reused or expired permit, the wrong signer) and checks that each one reverts and changes nothing. After every step it checks that:

• all balances add up to the total supply;
• the supply equals 1,000,000,000 minus what was burned, and never goes above it;
• each balance, allowance and permit counter matches the handler's record;
• no tokens end up at the token itself, the handler, the test contract or the zero address;
• name, symbol and decimals never change.

A final check confirms each run actually changed state, so the checks aren't passing on nothing. It ran 256 runs of 64 calls each (16,384 calls); the run counts are set inside the test file.

test/PaperbirdToken.edges.t.sol adds 27 tests for limits and failure cases the existing tests didn't cover:

• Amounts: moving the whole supply, one more than the supply, and the maximum possible number; a 1-wei transfer; burning the whole supply and then having nothing left to move.
• Allowances: an unlimited allowance used for burnFrom; burnFrom beyond the balance; approving again replaces the old amount rather than adding to it; revoking an allowance; spending an allowance down to exactly zero; transferFrom to the zero address leaves the allowance untouched.
• Permit (signed approvals): a signature used at exactly its deadline still works; one naming the zero address as spender is rejected without using up the signer's counter; altered, garbage or zero-owner signatures are rejected; a signature for another deployment doesn't work; the signing domain details are correct.
• Launch flows: the 10% swarm share, the pool seed and the remainder each arrive in full, and payouts out of the distributor arrive in full.
• Fuzz tests: random inputs for burnFrom, transfers between other accounts, and permit.

The token is a plain OpenZeppelin ERC-20 with burning and permit, and it has no owner. Burning can only shrink the supply, and burnFrom needs the holder's approval, so nobody else can burn or move a holder's tokens. I left the existing tests as they were.

The review is complete. No defects were found in the assigned area, and the report is written to .imd-findings.json with an empty findings list and ten coverage rows.

What I checked (Math Precision, Boundary, Numerical Gap guides)

• Custom code surface is one constant and one override in src/PaperbirdToken.sol. The supply literal evaluates to 1e27 at compile time, matches the 28-digit manifest value, and sits below the uint128 and int128 bounds Uniswap v4 uses for liquidity and balance deltas. The aderyn "large numeric literal" lead is that correct, named constant, not a defect.
• Inherited arithmetic lives entirely in OpenZeppelin. I confirmed every file in the inheritance closure is byte-identical to the upstream v5.4.0 release archive, then traced each unchecked block: every one is preceded by the checked comparison that makes it safe.
• Boundary enumeration found no external calls, no payable or fallback paths, no bytes decoding, and only OpenZeppelin's zero-address mint/burn arms as sentinel branches, all of which are guarded.
• Edge inputs exercised in a scratch Foundry test (since removed): full-balance transfer, balance+1 and max-uint transfer, self-transfer, zero-value transferFrom without allowance, max and max-minus-one allowance on burnFrom, burning the entire supply to zero, permit at an inclusive deadline and at max deadline, permit for the zero owner, upper-half s and v=0 signatures, the EIP-712 domain hand-computed, and a fuzzed sum-of-balances invariant. All ten passed.

Coverage record

All six listed entry points are marked holds, plus four invariant rows covering the supply constant, the mint-once property, the boundary enumeration, and the dependency integrity check.

Notes for the judge, not findings

• Zero-value transferFrom succeeds without an allowance and emits a Transfer event from any address. This is ERC-20 conformant OpenZeppelin behaviour and moves nothing.
• A permit with deadline set to max never expires. This is standard ERC-2612 and the README already tells the frontend to use short deadlines.

The working tree is clean apart from the report file, and the existing 37-test suite still passes.

The review is complete. The findings file is written and the working tree has no other changes.

Result: no defects found. .imd-findings.json holds an empty findings list and 11 coverage rows, one for each of the six entry points plus the invariants and dependency checks I ran.

What I checked, against the Economic Security, Invariant and Flow Gap guides

• The token has no custom logic beyond a one-time constructor mint of exactly 1e27 units to the deployer and a decimals() override returning 18. No owner, minter, pause, blocklist, fee, hook or upgrade path exists, so the floor's prohibited privileged calls have nothing to reach.
• Dependency integrity. I downloaded the upstream OpenZeppelin v5.4.0 release and compared all 226 vendored contract files byte for byte. They are identical, so the inherited ERC20, Burnable and Permit behaviour is the audited upstream code.
• Launch flow conservation. A scratch test replayed the launch as the factory performs it: 10% to the distributor, claims draining it to zero, 60% seed, a trader round trip, and the 30% remainder. Every leg moved exactly the stated amount and total supply was unchanged.
• Invariants. A stateful fuzz run over transfer, approve, transferFrom, burn and burnFrom with six actors holding the whole supply kept sum of balances equal to total supply, and total supply equal to the initial mint minus recorded burns, for the full run.
• Holder protection. The deployer (the factory at launch) cannot burnFrom or transferFrom a holder without an allowance. A permit grants only the signed value, cannot be replayed, and burnFrom beyond it reverts.
• Static analysis lead. The aderyn large-numeric-literal note on line 36 is a compile-time constant verified equal to 1e27 by the existing tests. It is stylistic, not a defect.

Not reachable in this review. No launch.json exists yet, so the manifest could not be inspected. The Uniswap v4 protected floor test could not be executed locally because v4-core is not vendored. The plain-transfer simulation covers the same value flows, and the README's economics (poolBps 6000, 800 IMD opening cap, remainder address) match the job and are not encoded in the token.

The review is complete and the findings file is written. No tracked file was changed, and the scratch test directory was removed.

Outcome: the paperbird token has no defect that opens a revision. The findings file holds one info-level note and a full coverage record.

What I verified

• The project builds and all 65 of its own tests pass, including the invariant suite.
• The vendored OpenZeppelin tree is byte-identical to the upstream v5.4.0 release apart from the omitted mocks directory. forge-std matches v1.9.7 exactly.
• The constructor mints 1e27 minor units once to msg.sender, which equals the manifest's totalSupply. Decimals, name, symbol, empty constructorArgs and the 14-character contract name all agree with launch.json.
• Creation and runtime bytecode are well under the size limits. A runtime opcode scan found no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE.
• All six state-changing entry points were traced through the OpenZeppelin code and marked holds, except permit, which carries the info note below. A deployer calling burnFrom or transferFrom on a holder without allowance reverts and moves nothing, so the protected floor's privileged-hand probes cannot touch a holder.

Specialist findings

• The audit_flow note on permit front-running was the only specialist finding, so there was nothing to merge. I reproduced it in a scratch test: a relayer submits the owner's signature first, the allowance is set, and the owner's identical resubmission reverts because the nonce advanced. This is standard ERC-2612 behaviour, not a contract defect. I kept it at info with the reproduction as guidance for the frontend, which should read the allowance before sending permit.
• The aderyn large-numeric-literal lead is style only and was dropped.

Next: nothing is outstanding for the author. The launch can proceed to the following worker step.