Implemented Ink Global Market (INK): 18 decimals, 1 billion tokens minted once to the deployer, with no administrative powers.

Included offline dependencies, deployment documentation, and 31 passing tests covering success, failure, fuzz, and invariant cases.

forge build, forge test with the required seed, and forge fmt --check all pass.

Done. launch.json is written and is the only changed file.

What the manifest says

• Kind is custom_token. The token entry names the Solidity contract InkToken with name "Ink Global Market", symbol INK, 18 decimals, an empty constructorArgs list (the constructor takes no parameters) and totalSupply 1000000000000000000000000000, which is exactly what the constructor mints to msg.sender.
• The contracts list is empty. The accepted tree has only the token, no application contracts, initialization calls or libraries.
• The pool block uses the IMD pair address, fee 12500, tick spacing 60 and the one-to-one sqrtPriceX96 from the launch reference.
• The economics object is copied verbatim from the job.
• Notes describe the token's behavior in about 1,050 characters, including that the swarm's share is the factory's and that initialPrice is provenance only.

Checks

• A small script in the repository confirmed the manifest has only the schema's top-level keys, the economics match the job byte for byte, and the supply is one billion times ten to the eighteenth.
• forge build compiled cleanly, and forge test with the verifier's fuzz seed passed all 31 tests in both suites.
• git status shows launch.json as the only new or changed file.

The review is complete. The findings file is written and the working tree is unchanged.

Result: no defects found in the math area. .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three listed entry points plus the invariants and boundaries I checked.

What the code is. src/InkToken.sol is 17 lines: it inherits the unmodified OpenZeppelin v5.4.0 ERC-20 and mints a compile-time constant of exactly 10^27 units to the deployer in the constructor. I verified the vendored OpenZeppelin files against the SHA-256 hashes in the provenance file and read the implementation directly rather than trusting the label.

What I traced against the Math Precision, Boundary and Numerical Gap guides:

• Supply constant. The literal evaluates at compile time to exactly 10^27, far below the uint256 limit. Divided by 10^18 decimals it is exactly one billion with zero remainder. The aderyn large-literal lead is a readability note only.
• Unchecked arithmetic in _update. Subtraction is guarded by the insufficient-balance check. The unchecked addition to the recipient cannot wrap because the sum of balances equals total supply and no mint or burn path is reachable after construction. Self-transfer of the full balance leaves it unchanged.
• Allowance math. The infinite sentinel is exactly the maximum uint256. An allowance of max minus one decrements normally. When allowance exceeds balance, the revert comes from the balance check and the allowance is untouched. A zero from address reverts on either value.
• Launch splits. 10^27 is divisible by 10,000, so every basis-point share of the supply is exact, with no truncation in the swarm, pool or remainder flows.
• Boundaries. No external calls, no payable function, no receive or fallback, no bytes decoding, no downcasts. The only sentinel branches are the zero-address checks, both sides traced.

Checks run. The project's own suite passed with the README's fuzz seed: 31 tests including 1,000-run fuzz tests and the 128 by 64 stateful invariant. I added a scratch test of the edge values listed above, which passed, and deleted it afterwards. forge fmt --check on the project sources passed.

Not reached. The protected launch harness that seeds and swaps through the Uniswap v4 PoolManager cannot run here because it needs v4-core and manifest-derived environment variables outside this repository. The token-side arithmetic it exercises, whole-amount transfers with no fee or burn, is covered by the rows above.

The findings file is present, parses, and git ignores it via the harness's own exclude list. No tracked file changed and the scratch test is gone.

Outcome: no defects found in the Access Control, Trust Gap and Asymmetry areas. The review is recorded in .imd-findings.json with an empty findings list and ten coverage rows, one per entry point plus the invariants I checked.

What I verified, with concrete values:

• Permission model. The token has no owner, role, modifier, initializer, proxy, receive or fallback. The compiled ABI exposes only the constructor, the three state-changing ERC-20 functions and views. The existing opcode test confirms no DELEGATECALL, CALLCODE or SELFDESTRUCT in the runtime.
• Supply fixed after construction. The only mint is the constructor's call minting 10^27 minor units to the immediate deployer. Burn is unreachable because transfers to the zero address revert and no function calls the internal burn. A probe confirmed both transfer and transferFrom to the zero address revert from the factory with an unlimited allowance set.
• Allowance authorization. A stranger pulling 1 wei from the factory with no allowance reverts and the factory balance is unchanged. A finite allowance of 60 consumed by 25 leaves exactly 35, and 36 then reverts. The maximum allowance never decrements.
• Asymmetry. Approve and spend write the same slot in mirror directions. Both transfer paths share one internal transfer. The mint and burn branches of the update function mirror checked addition against unchecked subtraction with sound bounds.
• Trust gap. With no privileged actor, no pricing and no caller-class-dependent rule, none of the four seams exists. Launch flows move exact amounts, so no holder class is shorted.
• Dependency integrity. I recomputed SHA-256 for all six vendored OpenZeppelin files and matched them both against the tree's PROVENANCE.md and against the upstream raw files fetched at the pinned commit. The ERC-20 is genuinely unmodified v5.4.0.

Two standard ERC-20 properties are noted in coverage rather than reported as findings. The approve-ordering race is intrinsic to the standard and documented in the README. A zero-value transferFrom with no allowance succeeds but changes no state. The aderyn large-literal lead is style only, since the literal evaluates to exactly the manifest supply.

Not covered: the protected launch suite that needs the v4 PoolManager harness, which is not in this tree and runs on the verifier side. All 31 existing tests pass locally.

I added two test files on top of the existing suite. With the verifier's fuzz seed, forge build succeeds and forge test passes all 61 tests: the 31 that were already there plus 30 new ones.

test/InkTokenEdgeCases.t.sol (29 tests, 9 of them fuzz tests):

• Supply and deployment: the supply is exactly 10^27 smallest units. When a factory deploys the token through CREATE2, the token lands at the predicted address and the factory gets the whole supply; tx.origin gets nothing. Deploying again with the same salt reverts, and two separate deployments keep separate supplies. The 10% / 80% / remainder launch split moves exactly.
• Zero addresses: every case reverts with its exact error: sending from address(0), approving from address(0), transferFrom with address(0) as owner, and (fuzzed over any amount) sending to address(0) or approving address(0) as spender.
• Boundaries:
  • transferring the maximum uint256 amount reverts cleanly, and so does sending one wei more than the balance;
  • an allowance of max − 1 counts as a normal limited allowance: it goes down when spent and still caps spending;
  • an unlimited allowance still can't move more than the balance;
  • an allowance belongs to one owner and one spender only, and a spent allowance can't be reused;
  • an owner can approve itself;
  • tokens sent to the token contract stay there and nobody can move them out.
• Events: transferFrom emits only a Transfer event, not an Approval. Failed calls emit nothing.
• Unknown functions: any call to a function the token doesn't have reverts and changes nothing, whether it comes from the deployer or anyone else. Empty or too-short call data also reverts.
• Fuzzed properties: sending tokens to another holder and back adds up correctly, nobody can spend more than they hold, an unlimited allowance never goes down, and approving again always replaces the old allowance.

test/InkTokenFailurePathInvariant.t.sol is a second invariant test, set to 256 runs of 64 calls each in the file itself. The existing invariant test only made valid calls. This one mixes valid calls with invalid ones in random order:

• sending or spending more than the balance or the allowance;
• sending to address(0), approving address(0) as spender;
• calling functions the token doesn't have.

Each invalid call must revert with the exact expected error and leave balances and allowances unchanged. The token contract itself is one of the recipients. After every sequence it checks that:

• balances and allowances match a separately kept record of what they should be;
• the balances add up to the full supply, which never changes;
• no invalid call ever succeeded;
• the token contract's own balance can only grow.

A final check fails the run if no invalid calls were made, so the test can't pass without checking anything.

To make sure the new tests can actually fail, I temporarily changed the token so transferFrom didn't use up allowances. All the new invariants and several unit tests failed. I then restored src/InkToken.sol; only the two new test files are changed.

I found no defects, so there is no .imd-findings.json. The token is the standard OpenZeppelin v5.4.0 ERC-20, and its vendored files match the checksums listed in the repository. I didn't commit anything.

The review is complete. The findings file is in place, the scratch files are removed, and no tracked file changed.

Result: no defects found in the economics area. The file .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three entry points plus the invariants and flows I checked.

What I verified

• Supply invariant. The constructor is the only mint path. _burn is internal and never called, and transfers to the zero address revert before reaching the balance update. Total supply is exactly 1e27 and cannot grow or shrink.
• Conservation. Every transfer debits and credits the same amount. The project's stateful invariant run and my own 8-holder fuzz confirmed the sum of balances equals total supply.
• Launch flows against the real PoolManager. In a scratch project outside the repo I cloned Uniswap v4-core and ran the full sequence: 10% to a distributor, an 80% single-sided seed through sync, transfer and settle, the 10% remainder forwarded, then a trader buying and selling back. Every step moved exactly its stated amount and the manager ended whole.
• Factory deployment. A CREATE2 deploy from a factory contract with no constructor arguments left the whole supply at the factory and nothing at the origin or token address.
• Dependency integrity. The five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag, re-hashed against GitHub raw at the pinned commit.
• Economic surface. No oracle, external call, owner, pause, blacklist, mint or burn selector exists. Zero-address sentinels revert. Runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Leads I dismissed

• The aderyn "large numeric literal" line evaluates to exactly the manifest supply and is style only.
• The ERC-20 approve front-running property is standard behaviour and already documented in the README, not a defect of this implementation.

Not covered. No launch.json exists yet in the tree, so the manifest itself could not be checked. That is expected for an early review and is not a defect.

The review is complete. The findings file is in place and the tree holds no other changes.

Outcome: no defects found in the assigned area. .imd-findings.json holds one info-level note and eight coverage rows, all holds.

What I checked, by guide

• Execution Trace. Traced all three entry points through OpenZeppelin's _update, _approve and _spendAllowance. Zero-sender, zero-recipient, infinite and near-infinite allowance, self-transfer, allowance rollback on a later revert, and value-bearing calls all behave as the standard and the README state. Ten scratch Foundry tests confirmed each path. The only check that manifests is the inherent ERC-20 approve ordering race, which the README already documents. I recorded it as info with the concrete sequence so the judge sees it was examined, and stated that no change is needed.
• Periphery. The five vendored OpenZeppelin files and the licence hash identically to the files at upstream commit c64a1edb…, which the GitHub API confirms is the v5.4.0 tag. The base contracts are unmodified and _msgSender is plain msg.sender.
• First Principles. The constructor mints exactly 10^27 units once to msg.sender. A CREATE2 factory receives the whole supply and the transaction origin receives nothing. There is no owner, mint, burn, pause, callback, receive or fallback, and the runtime bytecode scan for forbidden opcodes passes.

Checks run

• Project suite: 31 tests passed, including the 1,000-run fuzz tests and the 128x64 invariant run.
• Scratch probes: 10 passed, then removed.
• Build and format check passed.
• Static-analysis leads: the aderyn large-literal line is a compile-time constant equal to the manifest supply, not a defect. Slither reported nothing.

Not reachable here. The protected launch suite needs the launch harness, pool contracts and manifest environment, so it was not run locally. The token has no exemption logic, so its whole-share, seed and swap checks are satisfied by construction.

The review is complete and the findings file is written. The git working tree reports no tracked changes, and the findings file was read back successfully.

Outcome: no defects found. The token is a 17-line fixed-supply ERC-20 that inherits unmodified OpenZeppelin v5.4.0 and mints the full supply once to the deployer. The one specialist finding was reproduced and kept at info level. Nothing blocks the launch.

What I verified against the code

• The constructor mints exactly 1e27 units to msg.sender with no arguments, matching the manifest's supply, name, symbol and 18 decimals.
• The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no mint, burn, owner, pause, blacklist, upgrade, receive or fallback, so supply cannot grow and no privileged hand can move or freeze a balance.
• I scanned the runtime bytecode by opcode. It contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE. Sizes are far under the deployment limits.
• All six vendored OpenZeppelin files are byte-identical to the upstream commit named in PROVENANCE.md, and their SHA-256 hashes match the file's claims.
• The project builds cleanly, the format check passes, and the 61-test suite including both stateful invariants passes with the README's fuzz seed.
• Slither reported nothing. Aderyn's large-numeric-literal lead is the supply constant itself and is correct.

Specialist findings settled

• The audit_flow approve ordering race reproduces. I confirmed it with a scratch test in which a spender front-runs a lowering approve and moves 150 tokens where the holder intended at most 100. It is inherent to the ERC-20 standard, is already documented in the README with the revoke-first mitigation, and affects no launch flow. Kept at info with the reproduction and marked as needing no code change.
• The other four areas reported nothing, so there were no duplicates to merge.

Coverage record answers all three entry points plus five invariant rows: constructor allocation, fixed supply, opcode and size limits, vendored dependency integrity, and the static-analysis leads. The scratch test directory was removed so the tree is unchanged apart from the findings file.