The IMDCred token is delivered and committed on main as commit 2220bd7. A fresh offline clone builds, passes all 27 tests, and passes the format check.

What was built

• src/IMDCred.sol is a fixed-supply ERC-20 built on OpenZeppelin v5.4.0 with EIP-2612 permit and a holder-only burn. The constructor takes no arguments and mints 1,000,000,000 tokens (18 decimals) once to msg.sender, which is the launch factory.
• There is no owner, mint, pause, blocklist, tax, exemption, burnFrom, or ether path. The runtime bytecode has no DELEGATECALL, CALLCODE or SELFDESTRUCT, no link references, and sits well under the EIP-170 limit.
• foundry.toml pins solc 0.8.26, evm_version cancun, optimizer on, and bytecode_hash none. ffi is off and fs_permissions is empty.
• Dependencies are vendored as ordinary files under lib/ with no submodules: forge-std v1.9.7 and the OpenZeppelin contracts directory.
• script/DeployIMDCred.s.sol offers a tested deploy() function and a broadcast wrapper for local or testnet use only.
• README.md documents the token parameters, launch values, supply split, the empty "After launch" section, operational responsibilities, assumptions, scope, and test coverage.

Tests in test/IMDCred.t.sol cover metadata and supply, CREATE2 deployment from a factory stand-in, launch flows arriving whole, ERC-20 success and failure paths, burn and over-burn, every common mint and privileged selector reverting from both a stranger and the deployer, the opcode scan, five permit cases, and two fuzz invariants. Tests read no environment variables.

Points to note

• The NFT game contracts described in the brief (mining, staking, revenue share, floor reserve, buyback) are not part of a custom token launch and are documented as a later contracts launch. The token is designed as their plain dependency.
• I could not run the protected floor test itself, since it imports the verifier's own v4 harness. Its individual checks are mirrored in my suite.
• One leftover file, a husky pre-commit hook inside the vendored OpenZeppelin folder, could not be deleted because the sandbox treats it as sensitive. It is inert plain text.
• No security tooling beyond forge build, forge test and forge fmt was available. Tests passing are not an audit.

Done. I wrote launch.json for the accepted IMDCred token and verified it against the tree.

What the manifest says

• Kind is custom_token, token contract IMDCred, name IMDCred, symbol IMDCRED, 18 decimals.
• Constructor arguments are empty, matching the accepted constructor in src/IMDCred.sol which takes none.
• Total supply is 1000000000000000000000000000 minor units, exactly what the constructor mints to msg.sender.
• Contracts list is empty, since the accepted tree contains only the token.
• Pool and economics are copied verbatim from the launch reference: IMD as paired currency, fee 12500, tick spacing 60, the provenance-only initial price, poolBps 9000 and a 500 IMD opening cap.
• Notes describe the token's fixed supply, no-admin design, holder-only burn, and that no application contracts ship in this launch.

Verification

• A JSON check confirmed only schema keys are present, the supply and economics match, the address is lowercase, and notes are well under the limit.
• forge build compiled cleanly and forge test passed all 27 existing tests.
• git status shows launch.json as the only new file; nothing else was changed.

The review is complete. .imd-findings.json holds an empty findings list and a coverage row for every listed entry point.

Outcome: no defects found in IMDCred for the Execution Trace, Periphery and First Principles areas.

What the token is. src/IMDCred.sol is 36 lines: OpenZeppelin ERC20 plus ERC20Permit, a constructor that mints the full one billion tokens with 18 decimals to the deployer, and a burn that only touches the caller's own balance. It has no owner, no mint path, no transfer hook, no tax, no exemptions, no receive or fallback.

What I verified.

• The vendored OpenZeppelin copy is byte-identical to the upstream v5.4.0 tag, and forge-std to v1.9.7, so the inherited transfer, allowance and permit logic is the audited upstream code with no hidden side effects.
• The project builds and all 27 of its tests pass, including the launch-flow test that moves the swarm share, pool seed and claims whole.
• Scratch probes confirmed permit fails across a chain-id change and succeeds again on the original chain, rejects high-s malleable signatures, and consumes a nonce only on success. Approving the zero address reverts, self-transfer conserves balance, and burning the full balance or supply behaves as documented.
• The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, the constructor takes no arguments and makes no external calls, and no common admin or freeze selector exists.

Static-analysis lead. The aderyn large-numeric-literal note at line 24 is a style remark about the supply constant. The constant evaluates to exactly the manifest supply and the project test asserts it, so it was not reported as a defect.

Coverage. All five listed entry points are marked holds, with three extra rows for the constructor and supply, vendored library integrity, and the aderyn lead. The scratch test directory was removed, so the tree is unchanged apart from the findings file.

The review is complete. No defects were found in the assigned area, and the findings file records that with a full coverage table.

Outcome. The findings file holds an empty list and nine coverage rows, one for each of the five state-changing entry points plus four invariants. Every row is holds. The tree is clean apart from that file. No git status output means the findings file is ignored or untracked as intended, and the scratch tests were removed.

What I checked, against the Access Control, Trust Gap and Asymmetry guides:

• Permission model. The token inherits only ERC20 and ERC20Permit from OpenZeppelin. The compiled ABI exposes no owner, role, mint, pause, blocklist, upgrade or initialize selector, and no receive or fallback. The storage layout contains only ERC20 state, the short-string fallbacks and permit nonces. The deployer keeps no power after its balance leaves it.
• Burn. burn in src/IMDCred.sol acts on the caller's own balance only. A spender holding an unlimited allowance, and the deployer calling a burnFrom selector, cannot touch another holder. Burning leaves allowances intact, and the balance check still binds a later transferFrom.
• Permit. Deadline, nonce, signer and high-s malleability checks are the unmodified OpenZeppelin ones. The EIP-712 domain name equals name(), the separator is rebuilt on a chain fork, and a signature for one spender cannot be redeemed by another.
• Asymmetry. Mint exists only in the constructor and burn only on the caller, both through the same _update. Approve and permit write the same allowance slot and both emit Approval. Transfer and transferFrom move exactly the requested amount with no exempt or taxed branch.
• Trust gap in the supply chain. The vendored OpenZeppelin contracts directory is byte-identical to the v5.4.0 release tarball, and forge-std to v1.9.7. This closes the only place a backdoor could hide in a thin composition like this one.

Tools run. forge build, the existing 27-test suite, forge fmt --check, and seven adversarial scratch tests I wrote for this area. All passed. Slither and aderyn output from the verifier reported nothing above the large-numeric-literal style note, which is not a defect.

Not findings, but worth passing to the game-contract builders. EIP-2612 permits can be front-run by anyone who sees the signature, so a contract that calls permit and transferFrom in one transaction should tolerate the permit already having been consumed. Permit uses ECDSA only, so smart-contract wallets must use approve. Both are inherent to the standard OpenZeppelin implementation, not defects in this token.

Not reached. The README's chain id and paired-currency address are documentation values I could not verify against a supplied network file. They do not affect the token's code.

The review is complete. The findings file is in place, the scratch tests are removed, and the tree holds no other changes.

Outcome: no math, boundary or numerical-gap defect in IMDCred. One informational note is recorded.

What I covered

• The token itself is a two-line composition of OpenZeppelin v5.4.0 ERC20 and ERC20Permit plus a holder-only burn. It contains no division, no scaling, no casts and no external calls beyond the ecrecover precompile.
• I diffed the vendored OpenZeppelin tree against the pristine 5.4.0 npm release. Every Solidity file is byte-identical, so the arithmetic under review is the audited upstream code.
• I wrote and ran a 22-test scratch suite against the five entry points: zero and max amounts, self-transfers, burning the whole supply, the infinite-allowance sentinel at max and max-minus-one, zero-address sender, receiver, spender and permit owner, high-s and bad-v signatures, deadline equal to now and at max, chain-id change, nonce sequencing and permit front-running. All passed, confirming the guards hold before each unchecked block and that sum of balances always equals total supply.
• The aderyn large-literal lead resolves to exactly 1e27 at compile time, and the launch split of 10 and 90 percent is exact with no dust.

What I reported

• Info: permit has no ERC-1271 path, so a holder that is a smart-contract wallet can never approve by signature and must use approve. Reproduced with a contract owner and any EOA signature, which reverts with ERC2612InvalidSigner. This is standard OpenZeppelin behaviour, not a token defect, but the README advertises permit as the gasless path for the game contracts.

Coverage record: all five listed entry points have rows, four as holds and permit as finding 1, plus rows for the supply invariant, the literal constant, the vendored dependency and the ETH boundary. Nothing was left unreached. The pool price derivation and Uniswap v4 seed math are outside the token and the deployer's responsibility, so they were not audited here.

The review is complete. The findings file is valid JSON, the quoted snippet matches line 22 of the source, the scratch directory is removed, and git status shows only the untracked findings file.

Outcome: no defects in the assigned area. The economics, invariant and flow-gap checks all hold on src/IMDCred.sol. The file .imd-findings.json holds one info-level note and ten coverage rows.

What I checked

• Conservation and supply cap. A Foundry invariant suite with a handler driving transfer, approve, transferFrom, burn and permit across five actors never broke sum(balances) == totalSupply or totalSupply + burned == TOTAL_SUPPLY. The only mint is in the constructor and nothing else reaches _update with a zero sender.
• Launch flows arrive whole. There is no _update override, no tax, no exemption list and no external call, so the distributor, claimant, pool-seed and both swap legs move exactly the stated amount. The project's own tests already exercise this and all 27 pass.
• ERC-2612 permit. Domain separator matches the spec for name IMDCred, version 1, chain 4663 and the token address, and rebuilds if the chain id changes. High-s signatures, a zero owner and a zero spender all revert. A deadline equal to the current timestamp is accepted.
• Sentinel and boundary paths. Transfer and approve to the zero address revert, burn of the whole supply leaves zero and nothing further burnable, self-transfer conserves, ether and unknown selectors revert.
• Dependency integrity. Every vendored OpenZeppelin file the token uses is byte-identical to the published v5.4.0 npm package.
• Economics parameters. The pool share and opening cap are copied from the job. The derived price for either currency ordering sits well inside Uniswap v4's sqrt-price bounds. Price derivation belongs to the deployer, not the token.

The one item recorded (info). OpenZeppelin's permit consumes the nonce before approving, so anyone can submit a holder's permit first and make a game contract's bundled permit-then-transferFrom revert even though the allowance is already set. That is correct EIP-2612 behaviour and no change to the token is recommended. It is noted so the out-of-tree game contracts wrap permit defensively.

Not reached. The protected launch test could not be run here because it needs v4-core and the launch helpers, which are not in this tree. Static analysis reported only a large-numeric-literal style note, which is not a defect.

Done. The build is clean with zero warnings, and forge test passes across all three suites.

What I found

The token at src/IMDCred.sol is a thin composition of OpenZeppelin v5.4.0 ERC20 and ERC20Permit plus a one-line self-burn. I read it adversarially and drove it with random sequences, zero and one-wei inputs, the whole supply, repeated calls, self-as-counterparty, and malleated or cross-chain signatures. No defect surfaced, so no findings file was written. The only behaviour worth noting is that tokens sent to the token's own address are stuck forever, which is standard for an ownerless ERC20 and is pinned as a test rather than reported.

What I added

• test/IMDCred.invariant.t.sol: a handler with six keyed actors plus the deployer, ghost accounting per address and per allowance pair, and seven invariants checked after every call with fail_on_revert on. Clamped handlers reach the success paths; unclamped handlers pass raw inputs and assert the exact revert the token must produce for over-balance transfers, zero receivers, over-allowance pulls, over-burns, replayed permits, expired permits and forged permits. Invariants: supply equals the mint minus burns and never grows, tracked balances sum to supply, every holder holds received minus sent minus burned, allowances and nonces match the ghosts, the zero address holds nothing, and metadata and the permit domain stay fixed.
• test/IMDCred.edges.t.sol: 41 unit and fuzz tests for edges the existing suite did not reach: whole-supply transfer and burn, one-wei and max-uint inputs, self-transfer, self-transferFrom, approve to zero spender, approve overwrite, allowance above balance, burn not touching allowances, permit at the exact deadline, zero value, high-s malleability, garbage signatures, wrong spender or owner, future nonce, chain binding, per-owner nonces, distinct domains across deployments, and EIP-5267 domain fields.

How I checked it

Before trusting the invariants I ran the same handler against a scratch mutant token that mints 1% of every transfer to the deployer. Every invariant failed on the first run, so the suite is not vacuous. That mutant lived in the scratch directory and has been removed.

Suite	Tests	Result
existing IMDCred.t.sol	27	pass
new IMDCred.edges.t.sol	41	pass
new IMDCred.invariant.t.sol	7 invariants, 256 runs, depth 64	pass

One thing to be aware of: forge persists shrunk invariant failures under the cache directory, and a stale entry from my mutant run made the suite fail once until I cleared it. The cache is gitignored, so the verifier starts clean. The two new files are uncommitted in the working tree, ready for the harness to pick up.

The review is complete and the findings file is written. The tree is otherwise untouched.

Outcome: no defects. The token at src/IMDCred.sol is a 36-line fixed-supply OpenZeppelin v5.4.0 ERC20 with EIP-2612 permit and a self-only burn. Both specialist notes reproduced, but both are standard EIP-2612 behaviour rather than defects, so I kept them at info and they open no revision.

What I verified against the code:

• Vendored library integrity. All 18 OpenZeppelin files in the token's compile closure hash byte-identical to the upstream v5.4.0 tag.
• Deployability. Creation code and runtime are well under the size limits. An opcode scan of both finds no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE, only the STATICCALL to the ecrecover precompile. The constructor takes no arguments and mints exactly 1e27 to the factory.
• Manifest. The launch.json in the tree uses only schema keys, its supply, decimals, name, symbol and empty constructor arguments match the contract, and the notes are under the length limit.
• Protected floor. The verifier's protected test cannot run here because it imports v4-core and factory sources outside this tree. I read every assertion in it. A plain OZ ERC20 with no tax, exemptions, owner or mint path satisfies each one.
• Entry points. All five are answered. Four hold and permit is marked finding only because the two info notes attach to it.
• Static analysis. The aderyn large-literal lead evaluates to exactly the manifest supply.

Scratch tests I wrote reproduced the contract-wallet permit revert and the permit front-run griefing, and confirmed burn cannot exceed balance, the EIP-712 domain binds the chain id, and ETH is refused. The scratch directory was removed afterwards. The project's own 69 tests all pass.