The InkDead (IDEAD) token project is written, but I could not run forge build, forge test, or forge fmt in this session. Every shell command failed before starting with a sandbox error (apply-seccomp: write /proc/self/setgroups ... Permission denied), so the verification is desk-checked only, and nothing is committed to git.

What was delivered

• foundry.toml at the repository root. It pins solc 0.8.26, evm_version cancun, optimizer at 200 runs, bytecode_hash = "none", ffi off, no fs permissions, and no compiler path.
• src/IDEADToken.sol, the contract named IDEADToken with name InkDead, symbol IDEAD, 18 decimals, and a supply of one billion tokens minted once to msg.sender in the constructor. It is a plain ERC-20 with ERC-6093 custom errors, no owner, no mint, no burn, no pause, no blacklist, no fees, no external calls, and no constructor arguments.
• src/interfaces/IERC20.sol, the standard interface with metadata.
• test/utils/TestBase.sol, a minimal cheatcode interface and assertion helpers, so the project vendors no library at all. The sandbox failure also blocked downloading forge-std, and this layout means the offline verifier needs nothing outside the tree.
• test/IDEADToken.t.sol with 27 tests. They cover metadata, the one-time mint and its event, transfer and transferFrom success paths with events, every revert path, unlimited allowance behaviour, the launch floor's lists of mint and admin selectors from both a stranger and the deployer, a holder staying able to move its balance, ether rejection, and five fuzz tests on supply conservation and allowance bounds. Inputs are bounded in the tests so they pass for any seed, and nothing reads the environment.
• README.md documenting the manifest values, launch economics as given, assumptions, operational responsibilities, the empty "After launch" section, and the security checklist items applied.

Not verified

• forge build, forge test and forge fmt --check were never executed. I read the code back and checked it by hand against solc 0.8.26 rules and the pinned protected tests, but a compile or test failure is possible.
• No git commit was made, because git could not run either. The working tree holds all the files.

Recommended next step is to run the three commands once a working shell is available, with the verifier's fuzz seed:

forge build && forge test && forge fmt --check
FOUNDRY_FUZZ_SEED=0x8acbbce6192ca122c804723a0450a01a793bdf7248fad1d22fb15cc6dd9425e6 forge test

I found no defects in the permissions area of src/IDEADToken.sol. I wrote the result to .imd-findings.json: an empty findings list and a holds coverage row for each of the three entry points, plus two rows for supply and access invariants I checked. The project's existing 29 tests pass. I changed no other files.

Access Control

• The contract has no owner, minter, pause, blacklist, upgrade or admin storage, and no function that uses any.
• The constructor takes no arguments. It only puts the 1,000,000,000 × 10^18 supply in msg.sender's balance (the factory's at launch), so nobody holds a role once deployment ends.
• Nothing can mint or burn, and totalSupply() returns a fixed constant.

Trust Gap

• Only the holder can move their balance, and a spender can move it only through an allowance the holder granted. transferFrom checks the caller's allowance and reduces it before moving anything; the maximum value counts as unlimited, as in OpenZeppelin.
• The factory has no special power over other holders.
• There is no fee, so tokens sent to the distributor and the PoolManager arrive in full, and the token needs no exemption arguments.

Asymmetry

• approve, transfer and transferFrom reject the zero address the same way.
• A transfer to yourself keeps the balance correct, because the receiver's balance is re-read after the sender's is reduced. One existing test (test_transfer_toSelfKeepsBalance) covers this.
• Approving a zero amount and transferring a zero amount behave consistently.

Other notes

• Changing an allowance from one non-zero value to another lets a watching spender use both amounts. Every standard ERC-20 has this property, so I didn't report it.
• Static analysis flagged one "large numeric literal" at line 27. That is the supply constant, written 1_000_000_000 * 10 ** uint256(DECIMALS) as intended, so it isn't a defect.

I covered all three guides for my area and reached every entry point. There is no launch.json in the tree yet, so I could not review a manifest.

I wrote launch.json for the InkDead launch, and it is the only file changed.

What the manifest says

• Kind is custom_token. The token is IDEADToken, name InkDead, symbol IDEAD, 18 decimals, with an empty constructorArgs list because the accepted constructor takes no parameters.
• totalSupply is the exact amount the constructor mints to msg.sender, one billion tokens in minor units, computed with node rather than typed.
• contracts is empty. The accepted tree has only the token and no application contracts.
• pool and economics are copied exactly from the launch reference: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice as provenance, and the requester's economics object verbatim.
• notes describe only what exists in the tree: no owner, no mint path, no fee or burn on transfer, so every launch flow moves exactly the stated amount and the token needs no factory or pool manager argument.

Checks run

• forge build compiles cleanly with the pinned solc 0.8.26.
• forge test with the verifier's fuzz seed passes all 29 tests.
• A node script confirmed the schema keys, the 32-character name limit, lowercase addresses, string uint256 values, the verbatim economics, and that notes are under 4000 characters.
• git status shows launch.json as the only new or changed file.

The findings file is in place and the harness excludes it from git on purpose, so the tree is otherwise untouched. The review is complete.

Result: no defects found in the math, boundary or numerical-gap area. The findings file holds an empty list and seven coverage rows, all holds.

What I checked, against the token in src/IDEADToken.sol:

• Math Precision. The contract contains no division, no runtime multiplication, no narrowing cast and no decimals conversion. The only arithmetic is two unchecked blocks. The subtraction in the transfer path is guarded by the balance comparison on the line before it. The subtraction in the allowance path is guarded the same way. The addition to the receiver cannot overflow because the sum of balances is the constant supply and nothing mints. The supply constant is exactly 1e27 and matches the manifest figure. The aderyn large-literal lead is a style note with no wrong value behind it.
• Boundary. There are no external calls, no payable, receive or fallback, and no bytes decoding. The only sentinel branches are the zero-address guards, and I walked both sides of each. Calling transferFrom with a zero sender is rejected by the allowance guard for positive value and by the sender guard for zero value.
• Numerical Gap. The invariant that balances sum to the supply has no rounding anywhere to drift it. I confirmed it with a 256-run random-walk fuzz across four accounts. The max-allowance sentinel is an exact-equality check, so max minus one is finite and decrements. An infinite allowance above the holder's balance still reverts on the balance guard. Self-transfer through both transfer and transferFrom leaves the balance unchanged.

I ran the project's 29 tests, which pass, and eleven scratch edge-case tests of my own, which also pass. The scratch tests were removed afterwards as the task allows. Two standard ERC-20 properties are worth the author knowing but are not defects: the approve front-running race exists as in every plain ERC-20, and tokens sent to the token's own address are accepted with no recovery path, which the README already states as intended.

The control-flow review of the IDEAD token found no defects. The findings file holds an empty list and seven coverage rows, all holds.

What was reviewed. The Execution Trace, Periphery and First Principles passes were run by hand over src/IDEADToken.sol, its interface, the project tests, and the protected launch floor. The contract has three state-changing entry points and no privileged role, external call, fallback or receive. Every failure path is a check before any storage write, and the two balance writes sit in one unchecked block that cannot revert between them, so no partial state is reachable. The only sentinel is the unlimited allowance, and it still passes through every transfer check. A zero-address sender cannot slip through at value zero because no allowance can ever exist for it. Self-transfer of the whole balance leaves it unchanged. Supply is a compile-time constant minted once to the factory under CREATE2 with no constructor arguments, so the launch flows move exactly what they state.

Evidence gathered.

• The project's 29 tests pass under solc 0.8.26.
• A scratch probe of eight extra cases passed, including a reachable-opcode scan of the runtime for DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL and CREATE, ether rejection on every calldata shape, and a fuzzed conservation check across transfer and transferFrom interleavings. The scratch directory was removed afterwards.
• The two static-analysis leads were checked. Slither reported nothing, and the aderyn large-literal note is a compile-time constant equal to the manifest supply, not a defect.

Not reported on purpose. The standard ERC-20 approve race is inherent to the requested plain token, matches OpenZeppelin v5, and is documented in the README. It is a design property, not a defect in this code.

Coverage. All three listed entry points are marked holds with reasons, plus rows for the supply invariant, the launch-flow exactness, the opcode and ether checks, and the interface file. Nothing in my area was left unreached.

I added an invariant suite and an edge-case suite for the InkDead (IDEAD) token. forge build and forge test pass with the verifier's seed: 57 tests across 3 suites, none failing. I found no defects in src/IDEADToken.sol, so I didn't write a .imd-findings.json.

What I added (only under test/):

• test/IDEADToken.invariant.t.sol runs 256 random sequences of 64 calls each (16,384 calls in total), set in the test file itself. A handler contract drives the token from five accounts, one of them the deployer, and keeps its own record of what every balance and allowance should be.
  • Calls it makes: normal transfers, approvals and spends via transferFrom, with amounts pulled towards 0, 1, the limit and one below the limit. It also tries every failure path: sending more than the balance, sending to the zero address, approving the zero address, spending more than the allowance, spending more than the balance while the allowance covers it, and calling mint/burn/pause/blacklist-style functions. Each failure must revert with its exact error.
  • Checks after every call: the total supply never changes; the five balances always add up to the full supply; every balance and allowance matches the handler's record; and the zero address, the token, the handler and the test contract hold nothing.
• test/IDEADToken.edges.t.sol has 27 tests, including fuzz tests at 1,000 runs. They cover gaps in the earlier suite:
  • the zero address as the caller of transfer, approve and transferFrom;
  • when both the allowance and the balance are short, the allowance error is the one reported;
  • an owner pulling its own tokens with transferFrom still needs an allowance to itself;
  • an allowance one below "unlimited" does go down when spent;
  • an unlimited allowance still can't move more than the balance;
  • transferFrom emits one Transfer event and no Approval;
  • the constructor emits exactly one event (the mint);
  • unknown functions, burn and empty calls are rejected;
  • a reverted call changes no balance or allowance.
• test/utils/TestBase.sol: I only added to it, with no changes to what was there. It now has the two cheatcodes for recording events, two more assertEq versions, and a bound helper, so fuzz inputs are kept in range instead of throwing runs away. The project still vendors no libraries.

Checking the invariant tests aren't empty: in a throwaway copy, I made the handler's record skip one allowance update. All five invariants then failed, and so did the handler's own revert checks, so the suite does catch a mismatch.

The three files are not committed; they're in the working tree.

Review complete. The findings file is written with zero defects and a full coverage record.

Outcome: .imd-findings.json holds an empty findings list and 8 coverage rows, all holds, covering the three listed entry points plus the invariants and launch flows I checked. I found no defect in the economics of this token.

What I checked, per guide:

• Economic Security. No fee, tax, rebase, pause, blacklist or callback, so no flow can arrive short and nothing can be extracted. Transfers return true, zero-address receivers and spenders revert, infinite allowance is never decremented, and a reverted transferFrom spends nothing. The approve overwrite race is the ERC-20 standard's own behaviour, not a defect.
• Invariant. Sum of balances equals the constant supply of 1e27 after every step. The constructor is the only balance creator, nothing burns or mints, and the unchecked addition cannot overflow because the sum is bounded. A 2000-run fuzz of random 12-step transfer, approve and transferFrom sequences among four actors confirmed this, along with exact balance and allowance deltas on every success and the right reason on every revert.
• Flow Gap. I built Uniswap v4-core outside the repository and ran the launch against a real PoolManager: deploy from a factory stand-in, 10% to the distributor, initialize at the 4299-cap price, single-sided seed via sync, transfer and settle, remainder forwarded, then a 0.01 ETH buy and a full sell. The seed took 7.70e26 tokens, within the 80% share, the buy delivered exactly the swap delta, the sell returned all tokens with ETH back, and balances summed to the supply throughout. I also replicated the floor's reachable-opcode scan over the compiled runtime, which is clean.

Static analysis lead. The aderyn large-numeric-literal note at src/IDEADToken.sol:27 is style only. The literal evaluates to exactly 1e27 and matches the manifest supply.

Not reached. Nothing in the assigned area. I did not run the protected floor test itself, since its helper contracts are not supplied, but my harness exercised the same seed and swap path against the real PoolManager.

Working tree. Only .imd-findings.json was added. Scratch tests live in the gitignored test/scratch/ directory and the v4 harness is in /tmp.

The review is complete. The findings file is valid JSON, the snippet matches the README lines, and the tree is clean apart from the gitignored scratch test.

Outcome: the IDEAD token has no code defect. All four specialists reported nothing, and I reproduced nothing against the code either. The only reproducible issue is a stale README sentence, filed at info severity.

What I checked myself

• The three entry points approve, transfer and transferFrom in src/IDEADToken.sol. Each has zero-address guards, a balance or allowance check before its unchecked arithmetic, and no other state write. The unchecked receiver add cannot wrap because balances always sum to the constant supply.
• The constructor mints the full supply to the caller with no arguments and no external call. A scratch test deployed it through CREATE2 from a factory contract and confirmed the factory holds the whole supply.
• The reachable runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or STATICCALL. Creation code and runtime are far below the protocol size limits.
• The manifest in launch.json uses only schema keys, has an empty constructor argument list matching the parameterless constructor, and states a supply equal to the constant minted. Decimals and the contract name also match.
• The aderyn lead about the large numeric literal evaluates to exactly one billion tokens at 18 decimals. It is a style note, not a defect.
• The project's own 57 tests pass, including a 256-run invariant suite with an independent ledger.

The one finding (info)

README lines 46 and 47 say the launch parameters are not written to a launch.json in the repository. That file now exists at the root, added by a later commit than the README. The manifest content is correct, so the fix is only to reword the sentence.

Coverage record

All three listed entry points are marked holds, with four additional rows for the constructor, the fixed-supply invariant, the manifest check and the static-analysis lead. No proofs were attached since nothing reaches high or critical severity.