The deliverable is complete and verified locally.

What was built

• src/BitcornToken.sol: a plain OpenZeppelin v5 ERC-20. Name "bitcorn", symbol "BITCORN", 18 decimals. The constructor mints the full 1,000,000,000 supply once to the deployer and takes no arguments. There is no mint, owner, pause, blacklist, freeze, burn or upgrade path, and no external calls, so every launch flow moves exactly what it says and the supply can never grow.
• test/BitcornToken.t.sol: 22 tests, run from a stub factory contract so the constructor's caller is a contract as at launch. They cover metadata, exact supply, launch flows arriving whole, transfer and allowance success paths, the OpenZeppelin failure errors for insufficient balance, missing allowance and zero addresses, the same privileged-selector sweeps the protected floor uses, a bytecode scan for forbidden opcodes, and three fuzz tests checked with the verifier's seed.
• foundry.toml pins solc 0.8.26, enables the optimizer, sets bytecode_hash = "none", and leaves ffi off with no filesystem permissions.
• README.md documents the one assumption, the manifest values for reference, the trust model and the after-launch responsibilities.
• lib/forge-std (v1.11.0) and lib/openzeppelin-contracts (v5.4.0) are vendored as ordinary files with their git metadata removed, trimmed to sources and licences so the offline build works.

Check results

Check	Result
forge build (clean, solc 0.8.26)	pass
forge test with the verifier's fuzz seed	22 passed, 0 failed
forge fmt --check	pass

Assumption to flag. The brief's description of what the token does is the single word "adam". I treated it as a label with no behavioural content and built a standard fixed-supply token. The README states this plainly so the requester can order a follow-up if they meant a specific mechanic.

One note on the tree. A stale .gitmodules file inside the vendored OpenZeppelin folder could not be deleted because the sandbox masks that filename as read-only. It is not a submodule, as there is no gitlink and no nested repository, and git ignores a .gitmodules that is not at the repository root. Nothing was committed, since the upload step owns the git history.

Created launch.json matching BitcornToken’s constructor, metadata, and exact supply, with the supplied pool settings and verbatim economics.

forge build succeeded. All 22 tests passed with the specified fuzz seed. Manifest and constructor ABI checks passed. Only launch.json is changed for submission.

I added invariant tests and a set of edge-case tests for the bitcorn token in a new file, test/BitcornToken.invariant.t.sol. I left the existing test/BitcornToken.t.sol as it was. forge build succeeds, and forge test passes all 37 tests (22 existing, 15 new) with the verifier's fuzz seed.

Invariant tests (BitcornTokenInvariantTest). A handler makes random calls across six actors, one of which is the deployer contract. It does ordinary transfers and transferFroms, approvals (sometimes unlimited), and three kinds of call that must be refused: sending more than the balance, sending to the zero address, and spending more than the allowance. The refused calls must fail with OpenZeppelin's exact error. The test also keeps its own record of what every balance and allowance should be. Four invariants are checked after every call:

• the total supply stays at exactly 1,000,000,000 × 10¹⁸;
• the actors' balances add up to the whole supply, and neither the token contract nor the handler holds any;
• every balance and allowance matches the test's own record;
• no call that should be refused succeeded, and no call that should succeed was refused.

An extra check confirms that every run actually moved tokens, so the invariants aren't passing vacuously. The campaign ran 256 runs and 16,384 calls with no failures; run counts are set in the test file.

Edge cases (BitcornTokenEdgeTest):

• moving the whole supply in one transfer, then 1 wei more reverts;
• transfers of supply + 1 and of the maximum uint256 revert;
• sending to yourself, both fuzzed and above your balance;
• a new approval replaces the old one and can revoke it;
• transferFrom checks the balance even when the allowance is larger, and a failed call leaves the allowance unspent;
• transferFrom to the zero address reverts;
• a zero-amount transferFrom needs no approval;
• the deployer has no allowance over holders' tokens;
• a fuzzed two-step transfer keeps the total exact.

Findings: none. The token is a standard OpenZeppelin ERC20 with nothing added, and nothing failed, so I didn't write .imd-findings.json.

• One expectation I corrected: I first expected transferFrom(address(0), …, 0) to fail with ERC20InvalidSender. It actually fails with ERC20InvalidApprover, because OpenZeppelin checks the allowance before the sender. That is the library's normal behaviour, so I changed the test rather than reporting it.
• Pinned as a test, not reported: tokens sent to the token contract's own address can never be retrieved. Plain ERC20 tokens all work this way.

I haven't committed the new file; it's untracked in the working tree.

The review is complete. The findings file at .imd-findings.json holds an empty finding list and eight coverage rows, and the only change in the tree is that file. The scratch test and the temporary download directory were removed.

Result: no defects in the assigned area. The token at src/BitcornToken.sol is an unmodified OpenZeppelin 5.4.0 ERC20 with a no-argument constructor that mints the whole supply to the deployer. There are no roles, owners, exempt lists, hooks, or paired admin variants, so none of the failure modes in the Access Control, Trust Gap or Asymmetry guides has a surface to attach to.

What I verified

• The compiled ABI exposes exactly three state-changing entry points plus ten views. No mint, owner, pause, blacklist, freeze, burnFrom or upgrade selector exists, and a random-selector fuzz from random senders never changed supply or any balance.
• The vendored OpenZeppelin ERC20, IERC20, IERC20Metadata, Context and IERC6093 files are byte-identical to the published 5.4.0 package, so the inherited permission semantics are the audited upstream ones.
• The deployer cannot pull a holder's tokens without allowance, a self-pull still needs allowance, a reverted pull leaves the allowance intact, and a spender cannot raise its own allowance from another owner.
• Launch flows from factory to distributor, distributor to claimant, factory to pool and factory to remainder each arrive whole with supply unchanged. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The existing 22-test suite passes, and my six scratch probes passed before deletion.

Static-analysis lead. The aderyn large-numeric-literal note at line 29 evaluates to exactly the manifest supply, so it is style only.

Trust assumptions to document, not defects. The deployer is the only initial holder and has no power beyond an ordinary holder's. Standard ERC20 approve-overwrite semantics apply, which the README already states. Nothing in the area was left unreached.

Review complete. The findings file is valid JSON, the cited snippet matches line 18 of the source, the scratch test directory is removed, and the tree is otherwise unchanged.

Outcome: no defect requiring revision. BitcornToken is an unmodified OpenZeppelin v5.4.0 ERC20 with a single constructor mint of 1e27 units to msg.sender. I traced all three state-changing entry points against every item in the Execution Trace, Periphery and First Principles guides and found no failing input.

What I checked and recorded in .imd-findings.json:

• One info finding. The standard ERC-20 allowance race, where a spender can consume an old allowance and then a lowered one across an approve change. I reproduced it with a scratch Foundry test and it holds on this code. It is inherited from the ERC-20 standard, not a defect in the requester's code, and I say so explicitly. No revision is needed.
• Coverage rows for all three ABI entry points. The transfer and transferFrom paths hold. The approve row points to the info finding.
• Six invariant rows. The constructor mint and supply, balance conservation, decimals agreement, the vendored OpenZeppelin base matching upstream, exact launch flows, and the absence of delegatecall, selfdestruct, receive, fallback and owner.

Verification performed: the project build and its 22 tests pass, the compiled ABI shows a zero-input constructor and exactly the three listed entry points, and forge fmt reports the tree as clean. The static-analysis lead on line 29 is a benign large-literal style note and did not become a finding. One latent coupling is noted in a coverage row rather than as a finding: the TOKEN_DECIMALS constant feeds the supply but is not wired into decimals(), which is harmless today since both are 18.

Review complete. The findings file is written and the working tree is clean apart from ignored build output.

Result: no defects found in the Economic Security, Invariant, or Flow Gap areas. .imd-findings.json holds an empty findings list and nine coverage rows, all holds.

What I checked:

• The contract at src/BitcornToken.sol is an unmodified OpenZeppelin v5.4.0 ERC20 with one constructor mint of 1e27 to msg.sender. It declares no owner, mint, burn, pause, blacklist, receive, fallback, or upgrade path, and the runtime bytecode has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Entry points. All three listed entry points (approve, transfer, transferFrom) are stock OpenZeppelin code: exact amounts, correct revert paths, infinite allowance untouched, and no way for the deployer to pull a holder's tokens.
• Invariants. I ran a stateful fuzz campaign under test/scratch exercising transfer, approve and transferFrom across twelve actors. Total supply stayed fixed and the sum of balances equalled supply in every run. The scratch file was removed afterwards.
• Launch flows. The 10/60/30 split of 1e27 produces no rounding dust and each leg arrives whole. There is no transfer hook, so the factory, distributor, PoolManager and traders need no exemptions and the protected floor test paths are satisfied by inspection.
• Economics and static analysis. The aderyn large-literal note is the supply constant, which is correct. The ERC-20 approve front-running property exists as in every standard token and is not reported as a defect.

Not covered: nothing in my area was left unreached. The manifest step has not run yet, so there is no launch.json to check; the README's reference values (no constructor args, supply 1e27, 18 decimals) are consistent with the code.

The math audit of BitcornToken is complete, and the findings file is written at .imd-findings.json.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas. The token is a 40-line unmodified OpenZeppelin v5.4.0 ERC-20 with a single compile-time supply constant and no custom arithmetic.

What I verified:

• Supply constant. The expression at src/BitcornToken.sol:29 evaluates to exactly 1e27 at compile time, matching the manifest value. The aderyn large-literal lead is benign.
• Transfer and allowance math. OpenZeppelin's _update and _spendAllowance were traced for every unchecked block. Each is guarded by a prior revert check, so no wrap is reachable. Boundary inputs were exercised in a scratch test: zero amounts, self-transfers of the full balance, type(uint256).max amounts, allowance of max and max-minus-one, zero addresses in every position, and an 8-step fuzzed transfer sequence confirming the balance sum stays at 1e27.
• Boundary guide. The token has no external calls, no payable or receive paths, no sentinel-address branches and no bytes decoding, so that checklist has nothing to apply to. The ABI is exactly the 13 standard ERC-20 selectors.
• Dependency integrity. I downloaded OpenZeppelin 5.4.0 from npm into a temp directory and compared it to the vendored copy. The five files the token compiles are byte-identical. Other differences are forge-fmt whitespace and mock files the token never imports.

One info-level note is recorded, explicitly marked as not a current defect: decimals() returns OpenZeppelin's hard-coded 18 rather than reading the TOKEN_DECIMALS constant that sizes the supply. They agree today, so nothing fails. The note describes the hypothetical state where editing the constant would desynchronise them, and a one-line behaviour-preserving override if the author wants it.

Coverage has eight rows: all three listed entry points hold, plus the constructor, the supply-conservation invariant, both guide-level sweeps and the dependency check. The existing 22-test suite passes, the scratch test directory was removed, and the working tree is clean apart from the findings file.

The review is done and the findings file is written. The token is clean.

Outcome: no defect that would open a revision. The findings file holds one info-level note and a six-row coverage record, with all three entry points marked as holding.

What I verified

• The contract is OpenZeppelin v5.4.0 ERC20 unmodified, with a no-argument constructor that mints the full supply to the deployer. I read the vendored ERC20 and Context sources and found them stock.
• The build succeeds and all 37 project tests pass. The runtime is well under the EIP-170 limit and contains no delegatecall, callcode or selfdestruct.
• The manifest matches the code: empty constructor arguments, exact supply, 18 decimals, lowercase addresses, schema keys only.
• My own scratch test confirmed exact transfers, the self-transfer case, infinite allowance behaviour, and that no mint, receive or fallback path exists. I deleted the scratch directory afterwards.

Specialist findings

• Kept as info: the allowance race from the flow audit. I reproduced it in a scratch test. After approving 100e18, a front-running transferFrom, then an approve of 50e18 and another transferFrom, the spender holds 150e18. This is inherent to ERC-20 and the README already states holders own their approvals. No revision is needed.
• Dropped: the math audit's note that decimals() does not read TOKEN_DECIMALS. Both return 18 and no input in the tree makes them disagree, so it is a maintenance remark, not a reproducible defect.

No files other than the findings file were changed.