Done. The Daemon (DAEMON) token is implemented, tested, documented, and committed on main as commit 57131b3.

What was delivered

• src/DaemonToken.sol: a self-contained ERC-20 with name Daemon, symbol DAEMON, 18 decimals, and a constant supply of 1,000,000,000 tokens minted once to the constructor's caller. No owner, no mint, no burn, no pause, no fees, no blocklist, no external calls, no receive or fallback.
• test/DaemonToken.t.sol: 39 tests covering success paths, typed-error failure paths, four fuzz tests for exact transfer and allowance accounting, CREATE2 deployment from a factory-like contract, the deploy script, and mirrors of the launch floor's admin-selector probes and bytecode opcode scan.
• script/DeployDaemonToken.s.sol: a deploy function the tests call directly, with a thin broadcast wrapper that reads no environment variables.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none" and cbor_metadata = false, and leaves ffi and filesystem access off.
• lib/forge-std: forge-std v1.9.6 vendored as ordinary files with no git metadata, confirmed by an empty gitlink listing.
• README.md documents assumptions, manifest deployment parameters, operational responsibilities, and a walk through the eth-security checklist.

Verification results

The deployed bytecode carries no metadata tail, so the launch's byte comparison will see only code.

Notes for the reviewer

• The token takes no constructor arguments and needs no launch-address exemptions, because ordinary transfers already move exactly the stated amount. The manifest's constructorArgs is an empty list.
• Slither and Mythril were not available in this environment and did not run. Explorer verification after deployment is an open item for the network's deployer.
• A git author identity was not configured in the workspace, so the commit was made with the account email passed on the command line rather than written to git config.

The review is complete. No defects were found in the Daemon token, and the findings file records that with full coverage.

Outcome: .imd-findings.json holds an empty findings list and nine coverage rows. All three verifier entry points are marked holds, plus rows for the constructor, supply constancy, the opcode scan, the launch flows, the deploy script, and the one aderyn lead.

What I checked, by guide:

• Execution trace. Each of approve, transfer and transferFrom was traced from entry to final storage write. Guards run before every write, the unchecked block is sound because the balance check precedes it, and a self-transfer re-reads the decremented slot so it cannot double-credit. A revert inside the balance move rolls back the allowance decrement atomically. The infinite-allowance sentinel fires only at exactly max; max minus one decrements normally.
• Periphery. There is none. The token imports nothing, inherits nothing and makes no external calls. An opcode scan of the deployed runtime found no CALL, STATICCALL, CREATE, CREATE2, DELEGATECALL, CALLCODE or SELFDESTRUCT, so no callback or reentrancy surface exists.
• First principles. The compiled method list is exactly the ten ERC-20 functions plus the supply constant. There is no receive or fallback, so ETH and unknown selectors revert. Storage is two mappings only. The constructor is the sole mint and credits msg.sender, which a CREATE2 factory test confirms. Launch flows reduce to exact transfers, so the design's choice to take no $factory, $poolManager or $launchNumber arguments is correct.

Verification run: the existing 39-test suite passes, and a scratch probe of 10 tests I wrote under test/scratch/ also passes. It covers fuzzed self-transfers, three-actor conservation, the sentinel boundary, zero-address paths, fallback absence and the extended opcode scan.

Not reached: the Uniswap v4 seed-and-swap harness in the protected test could not be executed here because v4-core is not vendored in this tree. Its only dependency on the token is exact transfer semantics, which were verified directly. The ERC-20 approve race and the aderyn large-literal note are standard behaviour and style respectively, and are not reported as defects.

The review is complete. The findings file holds an empty list and seven coverage rows, and no tracked file was changed.

Result: no defects in the Math Precision, Boundary, or Numerical Gap area. The token in src/DaemonToken.sol has almost no arithmetic surface. There is no runtime division, multiplication, downcast, or shift. The only arithmetic is three unchecked add and subtract lines, each preceded by the guard that makes it safe.

What I checked against each guide:

• Math Precision. The supply constant evaluates at compile time to exactly 1e27, divisible by 10^18 and by 10,000, so the swarm and pool basis-point splits in the launch harness are exact. It sits far below the int128 and uint128 limits the Uniswap v4 PoolManager imposes on deltas and liquidity. The aderyn "large numeric literal" lead is therefore not a defect. The unchecked subtractions in transfer and allowance spending both follow an explicit less-than check, so they cannot wrap.
• Boundary. There are no external calls, no payable or receive functions, no token-address parameters, and no bytes decoding. The only sentinel branches are the zero-address guards and the max-allowance early return. I walked both sides of each: zero amount to the zero address still reverts, zero amount from the zero address still reverts, and an allowance of max minus one is decremented normally and can never climb to the sentinel.
• Numerical Gap. The one early return, the max-allowance shortcut, skips the allowance decrement but not the balance check, so no invariant is bypassed. A stateful invariant run of 128,000 randomized transfer, approve, and transferFrom calls, including self-transfers and zero amounts, kept the sum of balances at exactly the constant supply with zero reverts.

Coverage rows mark all three ABI entry points as holds, plus rows for the conservation invariant, the supply constant, and the two boundary classes that turned out empty. The existing suite of 39 tests passes, and tracked files are formatter-clean. The scratch test lives under test/scratch/, which is gitignored and will not be kept.

Two behaviours are standard ERC-20 and OpenZeppelin v5 parity rather than defects, noted here so the judge does not mistake them for omissions: a zero-amount transferFrom with zero allowance succeeds and emits an event, and an owner spending their own balance through transferFrom still needs an allowance.

The economics review of the Daemon token is complete. No defects were found, and the findings file records that with full coverage.

Outcome. .imd-findings.json holds an empty findings list plus eight coverage rows, all holds: the three ABI entry points, the conservation invariant, the no-growth and no-privilege invariant, the launch-flow exactness, the economic-security checklist, and the one aderyn lead.

What I checked against the three guides.

• Economic Security: the contract has no external dependencies, no held value, no callbacks and no price logic. Sentinel addresses are rejected everywhere, and ERC-20 semantics match OpenZeppelin v5. There is nothing to sandwich, starve, or extract.
• Invariant: the only balance writers are the constructor mint and the symmetric subtract and add in the internal transfer. The total supply is a pure constant. A stateful fuzz with a ghost ledger ran 64 sequences of 200 random transfer, approve and transferFrom calls, including self-transfers and the max-allowance sentinel, with zero drift.
• Flow Gap: a replay of the launch flow confirmed that factory to distributor, distributor to seven claimants, factory to pool, pool to trader and back, and factory to remainder all arrive exactly, with no residue left at any hop.

Static analysis lead. The aderyn large-numeric-literal note on line 34 folds to exactly the manifest supply at compile time and is style only.

Limits. The protected launch test depends on Uniswap v4 code not vendored here, so I simulated the pool manager hops with plain transfers rather than running the real PoolManager. Since the token has no exemptions and no fees, that simulation exercises the same code path. The scratch tests were removed after running, and no tracked file was changed.

All 73 tests pass across the three suites, and formatting is applied. No defect was found in the implementation, so there is no findings file to write.

What I added (two new files under test/, the existing suite is untouched):

• test/DaemonToken.invariant.t.sol: a six-actor handler with ghost ledgers, run at 256 sequences of depth 64 with fail-on-revert enabled. Handlers cover clamped transfers, full-balance and one-wei transfers, approvals including the unlimited sentinel, clamped and unclamped transferFrom, zero-address receiver and spender, privileged-selector probes from every actor, and ether donations. Unclamped variants catch the revert and assert it is exactly the error the pre-state predicts, and that nothing changed. Invariants: supply constant, sum of balances equals supply, every balance matches the ledger, nobody holds more than it received, allowances match the ledger and the sentinel is never decremented, the zero address holds nothing, no ether, stable metadata, and ledger self-consistency.
• test/DaemonToken.edges.t.sol: 33 tests at 1000 fuzz runs for the paths the base suite missed. The zero address as caller for transfer and approve, which are the two revert paths an ordinary EOA cannot reach. Zero-amount calls through every function, including that zero-amount transferFrom from the zero address fails on the sender check rather than the allowance check. The boundary one below the unlimited sentinel is decremented while the sentinel is not. Round-trip, additivity, order independence, idempotence, self-transfer, and reverted calls leaving no trace. A fan-out to up to 64 holders arriving whole.

Grounding the harness. Before trusting the green run I pointed the invariant suite at three mutated copies of the token in scratch: a 1% fee on transfer, an inverted allowance decrement, and a hidden mint function. Each was caught within the first sequence by the conservation, allowance ledger, or privileged-selector checks respectively.

One correction during the work. My first version of the zero-address transferFrom test expected the wrong error. The contract's order of checks is correct and the test now pins it.

The new files are uncommitted in the working tree, as nothing in the task asked for a commit. Nothing outside test/ was changed, and no dependencies were installed.

Review complete. The findings file is in place at the repository root and no tracked file was changed.

Outcome. In the assigned area (Access Control, Trust Gap, Asymmetry) the Daemon token holds. I found no permission bypass, no privileged surface, and no asymmetry that moves or freezes value. I wrote one informational finding, not a defect against the stated design.

The one finding (info). A transferFrom with amount 0 passes the allowance guard at src/DaemonToken.sol:158 because 0 < 0 is false. Any caller can therefore emit a Transfer(victim, anyAddress, 0) event without the victim's approval. Balances and allowances are untouched, and this is exactly what OpenZeppelin v5 does, which the README names as the reference semantics. It is reported because that event is the primitive behind address-poisoning scams. The minimal change and its tradeoff (loss of OZ parity) are stated so the requester can decide.

What I verified.

• The compiled ABI has exactly three nonpayable functions, no receive or fallback, and the constructor hands the full supply to msg.sender and retains no role.
• The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, STATICCALL, CREATE, CREATE2 or SELFDESTRUCT, so there is no reentrancy or confused-deputy surface at all.
• Scratch probes confirmed the allowance guard holds for every non-zero amount, the zero-address sender is rejected, allowances are scoped to owner and spender, and self-transfers are conserved.
• A stateful fuzz across five actors ran 128,000 calls with zero reverts and the balance sum always equalled the supply, which justifies the unchecked addition.
• The existing 39 tests pass. The aderyn lead (large literal) is the constant 1e27 and is asserted by a test. Slither reported nothing.

Coverage record. Eight rows: approve holds, transfer holds, transferFrom points to finding 1, plus the constructor, the no-privileged-surface invariant, the no-external-call invariant, the supply-conservation invariant, and the deploy script, all holding.

Not reached. The protected launch floor test needs Uniswap v4 sources and environment variables that are not in this repository, so I did not execute it here; the token's exact transfers and standard return values satisfy what it checks by inspection. Slither and Mythril were not available to run locally.

One documentation nit, not filed. The README says 22 admin-style selectors were tried from both a stranger and the deployer, but the test tries 12 of them from the deployer only. It is harmless because the contract has no fallback, so every unknown selector reverts from any caller.

launch.json is written at the repository root and verified. It is the only new or changed file. I left it uncommitted in the working tree, since the prior submission commit was authored by the harness identity with the job id, which indicates the harness snapshots the tree itself.

What the manifest says

Judgment calls, all recorded in notes

• Fee tier. The request named no tier, so I used the standard 0.3% tier with its canonical tick spacing. Admission accepts any of the three tiers.
• Opening price. The pair token at that address is live on Ethereum mainnet as Identity.md with 18 decimals, so the cap of 500 IMD over 1e27 minor units gives 5e-7 IMD per DAEMON. The recorded sqrtPriceX96 assumes DAEMON sorts as currency0, which is the likelier CREATE2 outcome. The currency1 equivalent is also given in notes. The field is provenance only.
• No placeholders. The accepted token takes no constructor arguments and its transfers are exact, so no launch address exemptions are needed.

Verification

• forge build and forge test pass with all 39 accepted tests green.
• A scratch validator in test/scratch checked the manifest against the JSON Schema from the task using ajv draft 2020-12, plus every prose refinement: fee tier, canonical tick spacing, exact pair token, economics deep-equal to the job, supply equals one billion times ten to the eighteenth, initialPrice below 2^256 and within Uniswap v4 bounds and equal to the derived value, reserved names, notes length.
• The compiled ABI of DaemonToken has a zero-arity constructor, matching the empty constructorArgs.
• A scratch Foundry test fed the manifest's values through env vars, deployed the token via CREATE2 from a factory stand-in, and confirmed the supply is minted to the deployer, decimals and metadata match, and the swarm, pool and remainder legs arrive whole and sum to the supply.
• git status shows only the new launch.json.

One limitation. The protocol package holding the real LaunchManifest zod schema is not on the public npm registry, so validation used the schema text embedded in the task rather than the library itself.

Wrote .imd-findings.json: no substantiated defects; all three entry points marked holds.

All 73 Foundry tests passed, including 16,384 invariant calls. Protected integration tests could not run because service dependencies are absent. No source or configuration files changed.