Implemented Cabal Coin (CABAL) with 18 decimals and exactly 1 billion tokens minted once to the deployer. Dependencies are vendored, and deployment responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed all 34 local tests using the supplied seed.
• forge fmt --check passed.

The full launch integration remains for the external protected verifier.

I found no math defects in Cabal Coin; the only finding is one info-level item outside my area. The findings and coverage are in .imd-findings.json. No other files were changed.

What I reviewed: src/CabalCoin.sol is a standard OpenZeppelin v5.0.2 ERC20. Its only addition is a constant supply, 1_000_000_000 * 10 ** 18 (1e27), minted once to the deployer in the constructor. The vendored OpenZeppelin files match their listed checksums. All 34 existing tests pass, including the fuzz, invariant and launch tests.

Math Precision guide: the code has no division, scaling, cast, fee, shift or bitmask. The only unchecked arithmetic is in OpenZeppelin's _update and _spendAllowance, and a checked comparison guards it first: the balance or allowance must be at least the amount, which is the most a transfer can move. The supply, 1e27, is far below 2^256, and decimals() is 18, matching the supply's scale.

Boundary guide: the token makes no external calls and has no payable functions or byte-decoding. I checked the edge inputs:

• A zero-amount transfer, or a transfer to yourself, leaves balances unchanged.
• A transfer to address zero reverts, and so does an approval from or to address zero.
• An allowance of type(uint256).max is treated as unlimited and never decreases. That is OpenZeppelin's documented behaviour.
• A transfer of the whole supply works.

Numerical Gap guide: there is no rounding or conditional fast path, so there is nothing for these combined checks to apply to. The supply can never change, and launch transfers to the factory, distributor and pool manager arrive in full.

Coverage: approve, transfer and transferFrom are each marked holds, plus three invariant rows: fixed supply, decimals and exact launch flows.

Finding (info): sha256sum -c DEPENDENCIES.sha256 fails for 7 forge-std files (StdJson.sol, console.sol, Vm.sol and four others). DEPENDENCIES.md says every vendored file is an unmodified upstream copy, so either the checksum file or those files are wrong. forge-std is only used by the tests, so the deployed token is not affected.

The aderyn "large numeric literal" warning is harmless: the literal is exactly the supply the brief asks for. Slither reported nothing.

Done. launch.json is written and committed as the only change.

What the manifest says

• Token is the accepted contract CabalCoin in src/CabalCoin.sol: name "Cabal Coin", symbol "CABAL", 18 decimals, an empty constructorArgs list because its constructor takes no parameters, and totalSupply of exactly what the constructor mints to msg.sender, 10^27 minor units.
• Contracts is an empty list. The accepted tree contains the token only, with no application contracts.
• Pool uses the IMD pair address, fee 12500, tickSpacing 60 and the one-to-one sqrtPriceX96 provenance value from the launch reference.
• Economics is the requester's object copied verbatim.
• Notes describe the fixed supply, the absence of privileged functions, and that no exemptions are needed for the factory, distributor or pool manager flows. The notes are well under the character limit.

Checks

• A structural check confirmed only schema keys are present, all uint256 and address fields are strings, numeric fields are numbers, and economics matches the required object byte for byte.
• forge build succeeded and forge test with the verifier's fuzz seed passed all 34 tests, including the invariant suite.
• Git status shows the commit touched only launch.json.

I wrote two new test files for Cabal Coin (CABAL). The full suite, now 54 tests, passes under forge test with the verifier's fuzz seed. I found no defects, so there is no .imd-findings.json.

What the contract is: a plain OpenZeppelin ERC-20 that mints exactly 10^27 (one billion with 18 decimals) to whoever deploys it. It has no owner, no mint or burn, no pause, and no fee on transfer. The 34 tests already in test/ were left alone; one of them already checks that the supply is minted only to the deployer through a factory-style deployment.

New in test/CabalCoinAdversarialInvariant.t.sol:

• A random-sequence test that also drives the failure paths:
  • transfers and transferFrom above the balance or allowance;
  • sending to the zero address;
  • transferFrom out of the zero address;
  • approving the zero address as spender.
• Amounts are picked from the edges: zero, exactly the balance or allowance, one more than that, the full supply, and the maximum value.
• Each call is checked against a separate record of what every balance and allowance should be. A call that succeeds must move exactly that amount. A call that fails must revert with the exact OpenZeppelin error and change no balance or allowance.
• The six actors include the deployer and the token's own address, to confirm neither gains any power.
• The invariants checked after every call: balances and allowances match the record; actor balances add up to the supply; the total supply never changes; the zero address never holds tokens or gains an allowance. It is set to 256 runs at depth 64 inside the file and ran 16,384 calls with no unexpected reverts.

New in test/CabalCoinEdges.t.sol (19 tests):

• An exact balance or allowance succeeds and one more reverts; sending the maximum value or the supply plus one reverts.
• An allowance of the maximum minus one counts down normally, while the maximum itself is never used up.
• The allowance is checked before the balance; the owner still needs to approve themselves to use transferFrom on their own tokens.
• Contracts can act as a spender or a holder; ETH and unknown or truncated calls are rejected.
• Each deployment mints only to its own deployer.
• Fuzz tests at 1,000 runs cover approvals, chained transfers, spenders with an unlimited allowance, and strangers trying to move someone else's tokens.
• One test records the usual ERC-20 risk when an approval is changed: a spender who sees the change coming can spend both the old and the new amount. This is how every ERC-20 behaves, so it is documented rather than reported as a defect.

Not committed: the commit failed because this machine has no git user name or email set ("Author identity unknown"), and I didn't change the git settings. The two files are staged in the working tree under test/, with nothing changed outside it.

The review is complete and the report is written to .imd-findings.json, which validates as JSON with one finding and nine coverage rows. No tracked file was changed.

Outcome: CabalCoin's permission model is clean. The token is a bare OpenZeppelin v5.0.2 ERC20 with a single constructor mint to the deployer, and I found no access-control, trust-gap or asymmetry defect in it.

What I verified

• Access control. The compiled ABI exposes exactly the nine standard ERC20 selectors plus the supply constant. There is no owner, minter, pauser, initializer, receive or fallback. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. All three state-changing entry points act only on the caller's own balance or allowance.
• Trust gap. The token has no fee, price formula, settable recipient or caller-class branch, so no seam between access, economics and asymmetry exists inside it. The one trust assumption is that the immediate deployer, the factory, receives the whole supply. The README documents this.
• Asymmetry. Every paired surface in the inherited ERC20 mirrors upstream exactly. The vendored OpenZeppelin files are byte-identical to the pinned upstream commit, so the inherited logic is not tampered.
• Checks run. Build, the full 34-test suite with the README's seed, and the fmt check all pass. The protected floor tests were read but need the verifier's harness, so they were not executed.

One low finding. The documented provenance check fails. Running the checksum command from DEPENDENCIES.md reports seven forge-std files as FAILED. The recorded hashes are those of genuine upstream bytes, and the files in the tree differ from upstream only in line wrapping, so test behaviour is unchanged and the production token is unaffected. The defect is that the "unmodified upstream files" statement and the README's recorded checksum pass are false for the committed tree. The fix is to restore the upstream bytes or regenerate the checksum file and correct the wording.

Not covered. No static-analysis lead needed reproduction beyond the aderyn note on the large numeric literal, which is a correctly valued constant and not a defect.

The review is complete and the findings file is written. The only files in the working tree beyond the committed state are .imd-findings.json and the scratch test under test/scratch/, neither of which is submitted work.

Result: the token's economics hold. One low-severity provenance defect was found outside the assigned area.

What I checked in the assigned area

• Economic Security. CabalCoin is upstream OpenZeppelin v5.0.2 ERC20 with a single constructor mint, confirmed byte-identical to upstream. It makes no external calls, has no fee, burn, hook, rebase, pause or blacklist, and no sentinel branches. A scratch fuzz modelling the pool manager's sync, transfer, settle accounting and a router-style allowance pull showed the received amount equals the requested amount in every run. All launch flows move exactly what they say.
• Invariant. Sum of balances equals total supply equals 1e27, permanently. _mint runs only in the constructor, _burn is unreachable, and _update is the sole balance writer. The constant 1_000_000_000 * 10 ** 18 evaluates exactly to 1e27, which answers the aderyn large-literal lead. Supply cannot grow and no privileged entry point exists.
• Flow Gap. No execution-times-periphery seam exists because the token never calls out and has no transfer-time branching. Under CREATE2 from the factory, the constructor's msg.sender is the factory, so the whole supply lands where the launch expects it.

Finding reported (low)

The repository's documented provenance check fails. Running sha256sum -c DEPENDENCIES.sha256 reports seven forge-std files as FAILED, because the recorded hashes are upstream's while the committed files were reformatted by a forge fmt pass. The differences are whitespace only and touch the test-only library, so token bytecode and launch flows are unaffected. The claim in DEPENDENCIES.md that all vendored files are unmodified, and the README's claim that every checksum passed, are both false in this tree.

Coverage

All three ABI entry points are recorded as holds, along with three invariant and flow rows. One row is unreached: the economics fields of launch.json, since no manifest exists yet at this stage.

Not carried forward

The ERC-20 approve front-running property and tokens sent to the token contract itself are standard behaviour already documented in the README and have no extractable value, so they are not reported.

Review complete. The findings file is written and the scratch tests are removed.

Outcome: the Cabal Coin token has no defect in its control flow. The only substantiated finding is a provenance and documentation inaccuracy, reported at low severity.

What I checked (Execution Trace, Periphery, First Principles guides, plus the Senior Auditor's Mindset):

• Token source. src/CabalCoin.sol is 17 lines over unmodified OpenZeppelin v5.0.2 ERC20. The constructor mints exactly 10^27 units once to the immediate deployer. There are no admin functions, no fallback or receive, no external calls and no forbidden opcodes.
• Entry points. Traced approve, transfer and transferFrom through Context, _approve, _spendAllowance, _transfer and _update. Zero-address sentinels revert on every path. Infinite allowance behaves as documented. Reverts are atomic. Self-transfers net to zero. The deployer cannot move another holder's balance.
• Launch floor. Transfers deliver exact amounts, so the swarm share, claims, seed and both swap directions move what they say. Nothing in the token needs exemptions. The protected test's privileged-call and opcode scans both pass against this code.
• Verification. Build, all 34 project tests with the documented seed, and forge fmt --check pass. Four extra scratch tests I wrote confirming the edge traces also passed, then were deleted.

Finding 1, low. Seven vendored forge-std files fail their recorded SHA-256 checksums, contradicting the "unmodified upstream files" statement in DEPENDENCIES.md and the recorded verification on README.md line 51. I fetched the same files from upstream at the recorded commit. The upstream bytes match the recorded hashes. The tree copies differ only by whitespace, so the formatter was run over lib/. No behavioral impact: these are test-only files and OpenZeppelin, the only dependency compiled into the token, is intact. The fix is to restore the upstream bytes or regenerate the checksums, and exclude lib/ from formatting.

Coverage. All three listed entry points are marked holds, plus three invariant rows: constructor mint, supply immutability and privileged calls, and dependency integrity, the last pointing at finding 1. Nothing in my area was left unreached.

The review is complete and written to .imd-findings.json. No tracked files were changed.

Outcome. The token is clean. The only defect that survives is the one all four specialists reported, merged into a single low finding.

• Kept, merged (low): the seven forge-std files under lib/ were reformatted after their checksums were recorded. I reproduced it: sha256sum -c DEPENDENCIES.sha256 reports 7 FAILED, the recorded Vm.sol hash matches upstream commit 77041d2 exactly, and the tree copy differs from upstream only in whitespace. The four specialist reports share this root cause, so they are one finding. Severity stays low: it is a false provenance claim in DEPENDENCIES.md and README.md, not a behavioral defect.
• Not affected: the five OpenZeppelin v5.0.2 files the token compiles against are byte-identical to upstream commit dbb6104. The build passes and all 54 local tests pass with the README's seed.

My own pass on the code. CabalCoin is a 17-line stock OpenZeppelin ERC20 with a no-argument constructor that mints 10^27 units once to msg.sender. All three entry points hold: approve, transfer and transferFrom are the unmodified upstream implementations with no override, no tax, burn, pause, blacklist, mint, owner, delegatecall or selfdestruct surface. The runtime is well under the size limit. The manifest matches the contract: empty constructorArgs, totalSupply equal to the INITIAL_SUPPLY constant, decimals 18, a 9-character contract name, lowercase addresses, and the correct types per field. The two static-analysis lines (slither clean, aderyn's large-numeric-literal note on the supply constant) do not indicate a defect.

Coverage record: three entry points marked holds, plus two invariant rows for the constructor mint and the absence of any privileged surface.