Implemented Bit (BIT): 100,000,000 tokens with 18 decimals, minted once to the deployer. No additional minting or admin powers.

Included vendored dependencies, deployment documentation, and success/failure tests.

Validation passed: forge build, all 29 tests with the requested fuzz seed, and forge fmt --check.

Done. The manifest is written and the tree builds and tests clean.

What I wrote: launch.json at the repository root, the only file changed. It describes the accepted tree exactly.

• Token is the Solidity contract Bit, name Bit, symbol BIT, 18 decimals, with an empty constructorArgs list. The ABI confirms the constructor takes no parameters.
• totalSupply is the constructor's single mint to msg.sender, 100,000,000 BIT in minor units, as a decimal string.
• contracts is empty. The tree has no application contracts, so none are named.
• pool and economics are copied verbatim from the launch terms: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's 8000 bps, 3,500 IMD cap and remainder address.
• notes describe the fixed supply, the absence of any privileged function or transfer fee, and that no exemptions are needed, in well under the 4,000 character limit.

Verification:

Check	Result
Manifest key set, types and values	passes a local script against the schema rules in the brief
forge build	compiles cleanly with solc 0.8.26
forge test with the verifier's fuzz seed	29 passed, 0 failed, including the invariant suite
git status	only launch.json is new

The protected tests need launch-time environment values the network supplies later, so they were read for requirements rather than run here. The token's plain behavior satisfies each of their checks: exact supply to the factory, no fee on any flow, no supply growth, and no privileged calls.

The math review of the Bit token is complete with no defects found. The findings file is written with an empty findings list and eight coverage rows, and no tracked file was changed.

What I reviewed. The token is a 16-line wrapper over OpenZeppelin v5.1.0 ERC20 that mints a fixed supply to the deployer in its constructor. All arithmetic lives in the vendored _update and _spendAllowance, so I traced those under the Math Precision, Boundary and Numerical Gap guides and confirmed the library is what it claims to be.

Checks that hold, with the concrete inputs tried:

• Supply constant. The compile-time literal evaluates to exactly 100000000000000000000000000, which is 1e26 at 87 bits. Divided by ten to the eighteenth it gives 100,000,000, so the manifest supply and decimals agree.
• Transfer arithmetic. Sending the max uint256, supply plus one, one wei, zero, and a self-transfer of the whole supply all behave correctly. The unchecked additions are bounded by total supply and no mint path exists after construction.
• Allowance arithmetic. Spending at the max allowance leaves it at max. Spending one from max minus one leaves max minus two. Spending exactly the allowance then one more reverts with the ERC-6093 error rather than a panic.
• Boundaries. No external calls, no payable function, no bytes decoding, no receive or fallback. The ABI shows only the three listed state-changing entry points.
• Library integrity. All five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag.
• Static-analysis lead. The aderyn large-numeric-literal note is the brief's supply written in base units and is not a defect.

Verification run. The project's 29 tests pass, including the 128-run stateful invariant. My own scratch suite of 11 boundary tests under test/scratch also passes, and that directory is ignored by git.

Not reached. Nothing within the assigned area was left unreached. The protected launch tests need the network's pool-manager harness and environment variables, so I did not execute them, though the token's exact-amount transfers satisfy what they check.

I added two test files for Bit (BIT): one for edge cases and one for invariants. All 50 tests pass with forge test and the verifier's fuzz seed: the 29 tests already here plus 21 new ones. I found no defects, so I didn't write .imd-findings.json. Bit is a plain OpenZeppelin v5.1 ERC-20 that mints 100,000,000 × 10¹⁸ once to the deployer, with no owner, extra mint, burn or admin functions. I didn't change anything outside test/ and haven't committed.

test/Bit.adversarial.invariant.t.sol: the existing invariant suite only ran calls that succeed, so this one also runs failing calls in the random sequences, over five actors plus any address that receives tokens. It ran 256 sequences of 64 calls (16,384 calls) without a break.

• Calls that should succeed: transfers between actors, transfers to any nonzero address (including the token itself), approvals both limited and unlimited, and transferFrom within the allowance and balance.
• Calls that should fail: overdrawing a balance, overspending an allowance, transferFrom where the allowance is enough but the balance isn't, sending to the zero address directly or through transferFrom, approving the zero address, and calls to mint, burn, burnFrom, pause, blacklist and transferOwnership. Each failure must revert with the exact error and change nothing.
• Checked after every call:
  • The total supply never changes.
  • Every holder's balance matches the expected value, and the balances add up to the supply.
  • All 25 allowance pairs match the expected values.
  • The token holds no ETH.

test/Bit.edge.t.sol (20 tests, 5 of them fuzzed at 1,000 runs):

• Launch: a factory stand-in deploys Bit at a predicted address and splits 10% / 80% / 10% in one call, the way one launch transaction would. The original caller gets nothing, and deploying again with the same launch number reverts.
• Bytecode: the code that can run contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Limits: going one wei over a balance, one over the supply, or sending type(uint256).max all revert. An allowance of max - 1 counts down like a normal one; an unlimited allowance stays unlimited but still can't move more than the balance.
• Allowances: holders need an allowance even to move their own tokens with transferFrom. Allowances are separate for each owner and spender, and a spent allowance can't be used again.
• Stuck funds and ETH: tokens sent to the token contract stay there and still count in the supply; ETH forced onto the contract doesn't affect any balance; ETH sent with a call is refused.
• Fuzzed: split transfers land exactly, an unlimited allowance never goes down, approve sets exactly the value given, a stranger can't move the deployer's funds, and a transferFrom over the balance leaves the allowance untouched.

Two things in the code work as written but holders should know: tokens sent to the token contract can never be moved out, and the usual ERC-20 risk when an allowance is changed (the spender can use the old one first) applies. The README already covers both.

The two protected checks in .imd/reads/ (the token floor and the owner checks) need the launch setup and manifest values the network supplies, so I couldn't run them here. My factory stand-in only models the launch transfers.

The review is complete. No defects were found in the Bit token, and the findings file holds an empty list with a full coverage record.

What was reviewed. The token is a 17-line contract at src/Bit.sol inheriting the vendored OpenZeppelin v5.1.0 ERC-20 with no overrides. Its only custom logic is a constructor that mints 100,000,000 tokens with 18 decimals to the deployer. I traced the three state-changing entry points against the Execution Trace, Periphery and First Principles guides.

Checks performed and their results.

• Execution Trace: traced approve, transfer and transferFrom through the inherited internals. Zero-address sentinels are rejected, the infinite-allowance path is standard, and every state update happens in one call with no external call between reads and writes, so no stale read or partial update exists.
• Periphery: all five vendored OpenZeppelin files hash byte-identical to the upstream v5.1.0 sources downloaded from GitHub. The Context base returns plain msg.sender.
• First Principles: the supply constant evaluates to exactly 1e26, mint is reachable only from the constructor, and the ABI exposes no admin, mint, burn, receive or fallback function.
• Launch floor reproduced locally: a scratch test deployed the token through a CREATE2 factory driven by a separate account, confirmed the factory holds the whole supply, walked the reachable runtime bytecode for DELEGATECALL, CALLCODE and SELFDESTRUCT, and confirmed ETH and unknown selectors revert. All passed, as did the project's 29 tests.
• The single static-analysis lead, a large numeric literal, is a readability note and not a defect.

Not reported. The ERC-20 approve replacement race is an interface property, already documented in the README as a holder responsibility, so it is noted in the coverage row rather than filed as a finding.

Coverage. The findings file answers all three listed entry points as holds, plus rows for the constructor, fixed-supply invariant, vendored library provenance, bytecode scan, launch-flow exactness and the static-analysis lead. The scratch test was removed because no finding needs a proof. No project file was changed.

The review is complete. The findings file is valid JSON with an empty findings list and nine coverage rows, and no tracked file in the repository was changed.

Outcome: no defects found in the economics area. Bit is a 16-line contract that inherits the stock OpenZeppelin ERC20, mints the full supply once to its deployer in the constructor, and adds nothing else. All three guides were checked against it.

What I verified

• Economic Security. The token has no external dependencies, oracles, fees, rebases, callbacks or sentinel-address branches. ERC-20 behaviour is the unmodified OpenZeppelin implementation. I downloaded the upstream v5.1.0 release archive, confirmed its hash matches lib/PROVENANCE.md, and diffed all six vendored files: byte-identical.
• Invariant. Supply is fixed at the manifest value of 100,000,000 BIT in 18 decimals. Only the constructor mints, the internal update hook is not overridden, and the compiled ABI exposes just approve, transfer, transferFrom and views. Sixteen admin-style selectors tried from a stranger and from the deployer all revert with supply unchanged. Sum of balances equals total supply under the project's stateful invariant and my own fuzz run.
• Flow Gap. The launch flows that the protected test demands were modelled through a CREATE2 factory: swarm share to distributor, pool seed, remainder, a claim, and a buy and sell. Every transfer delivered exactly the requested amount, and the factory cannot pull a holder's balance without allowance.
• Outside my area, checked cheaply. The runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, and all paths reject ETH.

Static-analysis lead. The aderyn large-numeric-literal warning on line 11 is a style lint. The expression evaluates to exactly the 27-digit supply the brief and manifest require.

Not reported on purpose. The standard ERC-20 approve race and tokens stranded at the token's own address are inherent to the ERC-20 design, are documented in the README, and are not defects of this code.

Coverage. All three listed entry points are marked holds, plus six invariant and dependency rows. Nothing was left unreached. My scratch probe lives in test/scratch/EconProbe.t.sol, which is ignored by git and not part of the submission.

The permission audit of Bit (BIT) is complete with no defects found. The findings file holds an empty list and a full coverage record.

What I checked

• Access Control. The token has no owner, roles, modifiers, initializer, proxy, or fallback. The compiled ABI exposes exactly three state-changing functions, matching the verifier's list. The constructor mints the whole supply to the factory once and hands out no role that survives deployment.
• Trust Gap. The vendored OpenZeppelin files are the only code the token trusts. I downloaded the v5.1.0 release, confirmed its hash matches the provenance note, and found all five vendored files byte-identical to upstream. The factory holding the supply is a launch trust assumption, not a token defect.
• Asymmetry. The transfer and delegated transfer paths share the same checks and state writes. The only differences are the allowance gate and the documented absence of an Approval event on spend, which is standard OpenZeppelin v5 behavior.

Reproduction probes run. Eight scratch tests passed and were removed afterward. They confirmed a stranger and the deployer cannot pull one wei without allowance, an allowance granted to one spender cannot be used by another, approve binds only the caller, transfers from the zero address revert even at zero value, zero-value delegated transfers by a stranger move nothing, and unknown selectors and plain ETH revert. The project's own 29 tests and the formatter check also pass.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note points at the supply constant, which equals the documented base units exactly and is not a defect.

Coverage. All three entry points are marked holds, plus six rows for the constructor role handout, the fixed-supply and no-privileged-entry-point invariants, library integrity, path symmetry, and the launch flows. Nothing in my area was left unreached.

The review is complete and .imd-findings.json holds zero findings with eight coverage rows. The git tree shows only the findings file, which is in .gitignore.

Outcome. The Bit token is clean. No specialist reported a finding, and my own pass found nothing to add.

What I verified

• The contract is a sixteen-line subclass of OpenZeppelin ERC20 whose constructor mints the fixed supply to the deployer. Under CREATE2 from the factory, that deployer is the factory.
• The five vendored OpenZeppelin files are byte-identical to the upstream 5.1.0 npm release. I compared sha256 hashes against a fresh download.
• The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no owner, mint, pause, blacklist, burnFrom, receive or fallback.
• A reachable-opcode scan of the deployed bytecode finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Runtime is well under the EIP-170 limit.
• The manifest uses only schema keys, its totalSupply equals the constructor's mint, and its empty constructorArgs match the argless constructor.
• The project's 50 tests pass, including the fuzz and invariant suites.

Leads dismissed. The one aderyn line, a large numeric literal at src/Bit.sol:11, is a style note. The literal evaluates to exactly the manifest's supply. The standard ERC-20 approval race is documented in the README and is not a defect of this code.

Coverage. All three listed entry points are marked holds, plus five invariant rows covering the constructor mint, supply fixedness, bytecode, manifest, and the specialist and static-analysis inputs.