Implemented Cadence IMD (CADENCE): 1,000,000,000 tokens, 18 decimals, minted once to the deployer.

Included vendored dependencies, deployment documentation, and success, failure, fuzz, and invariant tests.

Verified:

• forge build passes.
• forge test passes all 26 tests.
• forge fmt --check passes.

Created launch.json matching CadenceToken, its empty constructor arguments, exact supply, and prescribed pool and economics.

Manifest checks and forge build passed. forge test: 26 passed, 0 failed.

Only launch.json is a submission change.

The review is complete and the findings file is written. The working tree is clean apart from the gitignored findings file.

Result: the token holds under all three assigned guides. CadenceToken is the stock OpenZeppelin v5.0.2 ERC-20 with a single constructor mint, and I verified the vendored ERC-20 sources are byte-identical to the upstream tag. There are no external dependencies, no transfer taxes, no privileged roles, and no exposed mint or burn, so none of the Economic Security, Invariant, or Flow Gap failure modes apply. I reproduced the launch flows the floor demands against a sync/settle delta stub and they move exact amounts. The project's own 26 tests, including the stateful invariant suite, pass.

One low finding, outside my area: the vendored dependency integrity manifest is wrong. DEPENDENCIES.md claims the vendored files are unmodified and tells reviewers to verify them with a checksum command, but that command fails on seven forge-std files. The differences are whitespace-only reformatting against upstream v1.9.7, so the test library's semantics are unchanged and no deployed code is affected. The fix is to regenerate the checksum file from the committed tree.

Coverage recorded for all three entry points as holds, plus four invariant rows covering supply fixity, constructor behaviour, bytecode opcode scan, and dependency checks.

Two items I could not verify from inside the tree and leave as open notes rather than findings: the README states the launch chain is Ethereum mainnet, which nothing in the task confirms, and no launch.json exists yet, so the manifest's empty constructorArgs and totalSupply of 10^27 remain for the manifest step to get right.

The review is complete and .imd-findings.json is written with one substantiated finding and full coverage.

Outcome. The token is correct for its brief. CadenceToken is a three-line wrapper over an unmodified OpenZeppelin v5.0.2 ERC-20 that mints exactly 1e27 units to the deployer once. I found no defect in the contract itself.

What I checked, in my area.

• Execution Trace: traced approve, transfer and transferFrom through _approve, _spendAllowance, _transfer and _update. Allowance is spent before the balance moves, so any failure rolls both back. Max allowance stays fixed, a zero from reverts on every amount, and a spender cannot exceed its allowance across calls. The standard ERC-20 approve race exists and is documented in the README.
• Periphery: every vendored OpenZeppelin file is byte-identical to the upstream v5.0.2 archive, whose SHA-256 matches the one recorded in DEPENDENCIES.md. _msgSender is plain msg.sender, so there is no forwarder path.
• First Principles: the constructor takes no arguments and makes no external calls. Deployed by CREATE2 from a factory, the factory holds 100% and neither the caller nor the transaction origin holds anything. The ABI exposes only the nine ERC-20 functions, and unknown selectors and plain ETH revert. A scratch test replicating the protected floor's opcode scan finds no DELEGATECALL, CALLCODE or SELFDESTRUCT in the compiled runtime.
• Static-analysis lead: the large literal at line 11 evaluates to exactly 1e27 and is not a defect.

The one finding, low severity. Seven vendored forge-std files were reformatted after lib/SHA256SUMS was recorded, so the integrity check the README prescribes fails:

sha256sum -c lib/SHA256SUMS
...
sha256sum: WARNING: 7 computed checksums did NOT match

I verified against the upstream v1.9.7 archive that the differences are whitespace only, so the test dependency is sound. The defect is that the shipped provenance record contradicts the claim in DEPENDENCIES.md that the vendored contents are unmodified, and an offline verifier cannot tell that from tampering. Regenerating the checksum file fixes it.

Verification run. Build succeeds, the existing 26 tests and the stateful invariant pass, forge fmt --check passes, and my seven scratch tests pass. The working tree is unchanged apart from ignored paths.

The review is complete and the findings file is written and valid.

Result for the assigned area (Math Precision, Boundary, Numerical Gap): clean. The token is the unmodified OpenZeppelin v5.0.2 ERC-20 with one constructor mint. There is no division, no downcast, no external call, no payable path and no bytes decoding anywhere in the token or its inherited code, so most of the three checklists have nothing to attach to. The items that do apply were traced and exercised:

• Supply literal. The aderyn lead on line 11 is a compile-time constant equal to exactly 1e27, which is one billion whole tokens at 18 decimals. Not a defect.
• Arithmetic in the inherited code. Every unchecked block in the transfer path is preceded by a guard, and all balances are bounded by the fixed supply. Full-supply, supply-plus-one and max-uint transfers behave exactly as specified.
• Boundary inputs. Zero amounts, self-transfers, the zero-address sender and receiver, exact-allowance spends, and the infinite-allowance sentinel at max and max-minus-one were all exercised in a scratch test. All nine evidence tests pass, alongside the project's existing 26.
• Launch arithmetic. The supply divides exactly into the 10/80/10 basis-point shares, and the token has no fee or hook, so the factory flows move exact amounts.
• Runtime bytecode. The same opcode scan the protected floor runs found no DELEGATECALL, CALLCODE or SELFDESTRUCT.

One low finding, outside my area. Seven vendored forge-std files were reformatted after their hashes were recorded, so the documented check sha256sum -c lib/SHA256SUMS fails and the claim in DEPENDENCIES.md that the files are unmodified is no longer true. I fetched both upstream archives: their hashes match DEPENDENCIES.md, every OpenZeppelin file is byte-identical to upstream, and the seven forge-std files differ only in whitespace. This touches test tooling only and not the deployed bytecode. The fix is to either restore the upstream bytes and keep the formatter off lib, or regenerate the hash list and correct the wording.

Coverage. All three listed entry points are recorded as holds, with six additional rows for the invariants and provenance checks above. The findings file validates as JSON and the working tree is otherwise unchanged, with the scratch test living in the ignored scratch directory.

The review is complete and .imd-findings.json is written. Nothing else is needed.

Result: the Cadence IMD token holds in the assigned area. No Access Control, Trust Gap or Asymmetry defect was found. One low finding outside the area was recorded.

What was checked

• Access control. src/CadenceToken.sol is OpenZeppelin v5.0.2 ERC20 with a single constructor mint to msg.sender. The compiled ABI exposes exactly three state-changing functions: approve, transfer, transferFrom. There is no owner, initializer, minter, pauser, blacklist, receive or fallback. Under a CREATE2 factory the whole supply lands on the factory, not on the factory's caller or the transaction origin. The deployer has no allowance bypass over other holders.
• Trust gap. No privileged actor, pricing formula or caller-class branch exists, so no access-times-economics or access-times-asymmetry seam can be built.
• Asymmetry. transfer and transferFrom share the same _update path and move identical amounts under fuzzing. Self-transfers, zero amounts, zero-address recipient and zero-address spender behave symmetrically. The missing Approval event on transferFrom is OpenZeppelin v5 behaviour and is documented in the README.
• Launch floor. Supply is fixed at 1e27 with 18 decimals, no path reaches _mint or _burn, and a corrected opcode scan of the runtime bytecode shows no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CREATE2. The existing 26 tests and 5 scratch tests I wrote all pass. Scratch files were removed.

The one finding (low, outside area). The repository documents sha256sum -c lib/SHA256SUMS as its provenance check and claims the vendored files are unmodified. The check fails for 7 forge-std files. The recorded hashes are the genuine upstream v1.9.7 hashes, but the committed files were re-wrapped by the formatter. The differences are whitespace only, so test behaviour is unaffected. The production OpenZeppelin files are byte-identical to upstream v5.0.2.

Coverage. All three listed entry points are marked holds, plus rows for the constructor roles, the fixed-supply invariant, the no-privileged-hand invariant, trust-gap seams, and dependency integrity. The protected Uniswap v4 integration test could not be run locally because it needs v4-core and the launch environment variables.

Added 19 failure-path and fuzz tests, and expanded stateful invariants across four actors.

Offline forge build and forge test passed: 45 tests, including 32,768 invariant calls.

Only two files under test/ changed. No implementation defects were found.

The review is complete and .imd-findings.json is written with one merged finding and a full coverage record. No files other than the findings output were changed.

Outcome. The token is a stock OpenZeppelin v5.0.2 ERC-20 with a single constructor mint, and it has no code defects. All four specialists reported the same root cause, which I reproduced and merged into one low-severity finding.

The one finding, low severity. The documented integrity check in DEPENDENCIES.md fails on the committed tree. Running sha256sum -c lib/SHA256SUMS reports seven forge-std files as FAILED. I downloaded the upstream v1.9.7 archive, whose hash matches the one recorded in the repository, and confirmed the drift is whitespace-only: with whitespace stripped, every local file hashes identically to upstream, and the diff shows only forge fmt line re-wrapping. The five OpenZeppelin files the token compiles against are byte-identical to the v5.0.2 archive, so the deployed bytecode is the stock implementation. The defect is a false provenance claim and a failing verification step, not a behavioural one. The fix is to restore the seven files byte-exact and exclude lib from formatting, or regenerate the hash list and reword the "unmodified" claim.

Coverage. All three entry points hold:

• approve, transfer and transferFrom are unmodified OpenZeppelin code with the expected zero-address, balance and allowance reverts, no fees, hooks or exemptions, so the swarm, seed and swap flows move exactly the stated amounts.
• The constructor mints exactly 10^27 units to msg.sender, matching the manifest's totalSupply, and the ABI exposes no mint, burn, owner or pause function.
• The constructor takes no arguments, matching the manifest's empty constructorArgs, and creation and runtime code are far under the size limits with no DELEGATECALL, CALLCODE or SELFDESTRUCT.

The project's own 45 tests, including the 128-run stateful invariant suite, pass. No proof file was needed since nothing reaches high or critical severity.