The Crawlyield token project is complete, verified and committed on main.

What was built

• src/CrawlyieldToken.sol is the token, contract name CrawlyieldToken. It composes OpenZeppelin v5.0.2 ERC20, ERC20Burnable and ERC20Permit. The constructor takes no arguments and mints the whole supply to the caller, which on the launch is the factory.
• The token has no owner, minter, pause, blacklist, freeze, seize or upgrade path. Transfers move exact amounts, so the swarm share, pool seed and swaps in the protected harness arrive whole. Supply can only shrink through holder-authorized burns.
• script/DeployCrawlyieldToken.s.sol exposes a plain deploy function the tests call directly, plus a broadcast wrapper for stand-alone use.
• foundry.toml pins solc 0.8.26, sets bytecode_hash to none, optimizer on, ffi off and no filesystem permissions. forge-std 1.9.7 and the needed OpenZeppelin files are vendored as ordinary files under lib with their licences.
• README.md documents the parameters, the launch economics, the stand-alone deploy path, operational responsibilities and assumptions. There is no "after launch" configuration because the token has no settings.

Verification

Check	Result
forge build	passes
forge test with the verifier's fuzz seed	34 passed, 0 failed
forge fmt --check	passes
Clean copy, offline, empty environment	build and tests pass

Tests cover metadata and supply, the one-time mint for EOA and contract deployers, every ERC-20 revert path, burn and burnFrom without approval, probes of mint, pause, blacklist, freeze and upgrade selectors from both a stranger and the deployer, permit success and failure cases, a runtime opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and fuzzed supply conservation. No test reads environment variables.

Left out

Slither and Mythril were not available on this machine and did not run. No launch.json was written, as the brief requires. The working tree has no stray files outside the committed project.

launch.json is written and verified. The only working-tree change is the new manifest.

What the manifest says

• Token: contract CrawlyieldToken, name Crawlyield, symbol CRAWL, 18 decimals, empty constructorArgs. The accepted constructor takes no parameters and mints the whole supply to msg.sender, so totalSupply is the minted amount in minor units, 1000000000000000000000000000.
• Contracts: an empty list. The accepted tree has no application contracts, only the token, a deploy script and tests.
• Pool and economics: copied verbatim from the launch reference. IMD pair at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, the one-to-one initialPrice as provenance, and the requester's economics object unchanged.
• Notes: a description of the token's behavior that only names what exists in the tree, well under the 4000 character limit.

Checks run

• A script confirmed the manifest has exactly the schema's top-level keys, the token keys, the verbatim pool and economics objects, the correct supply string, and a contract name under 32 characters.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 34 tests.
• Git status shows only the untracked launch.json. No other file was touched.

Against the protected floor, the token needs no exemptions since it has no transfer fee, no mint path, and no privileged calls. The burnFrom entry point the floor probes reverts without allowance, so the holder's balance stays intact.

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

Result: no defects found in the Execution Trace, Periphery or First Principles areas. The file .imd-findings.json holds an empty findings list and eleven coverage rows, one for each of the six state-changing entry points plus five invariant and periphery rows, all marked holds.

What I checked:

• Execution trace. Every entry point ends in OpenZeppelin's single _update writer. I traced approve, transfer, transferFrom, burn, burnFrom and permit through their guards, state writes and revert paths. There are no external calls, no sentinel branches, no partial updates and no payable or fallback surface.
• Periphery. The vendored OpenZeppelin tree under lib/ was diffed byte-for-byte against the upstream v5.0.2 tag on GitHub and is identical across all 18 files. The runtime opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT passes.
• First principles. The supply constant equals exactly 1e27, is minted once to whoever runs the constructor, and can only shrink. No address is hardcoded and nothing is taxed, so the factory, distributor and pool flows in the protected floor test arrive whole.
• Edge paths. A temporary scratch suite confirmed permit deadline boundaries, high-s malleability rejection, nonce handling on failure, domain separator refresh on chain-id change, infinite-allowance burnFrom, zero-amount burns and self-transfer conservation. All ten passed and the scratch directory was removed.

Static-analysis leads were resolved: Slither reported nothing, and the aderyn large-literal note on line 32 is the correct supply value.

Known ERC-20 behaviours that are not defects of this code, already documented in the README, are the allowance race on approve, residual allowances after partial spends, and permit front-running by relayers.

The review is complete and the findings file is written. Nothing else is pending.

Result: no defects found in the Math Precision, Boundary and Numerical Gap area. The findings file at the repository root holds an empty findings list and 11 coverage rows, one for each of the six listed entry points plus five invariant and boundary rows. The working tree is otherwise unchanged. The scratch test directory and the temporary upstream clone were removed.

What I checked, in order of the three guides:

• Math precision. The token has no runtime arithmetic of its own. Its only numeric code is the supply constant at src/CrawlyieldToken.sol:32, which compiles to exactly 1e27 and matches the brief and the 18-decimal override. The aderyn large-literal lead is style only. The inherited unchecked blocks in the OpenZeppelin transfer path are bounded by that supply, and no division, scaling, downcast or decimal conversion exists anywhere.
• Boundary. The token makes no external call except the ecrecover precompile inside OpenZeppelin's signature recovery, which rejects a zero result. There is no payable path, no bytes decoding, and the only sentinel branches are the zero-address guards, each traced. Max-uint transfer, supply-plus-one transfer, whole-supply self-transfer, whole-supply burn, exact-allowance exhaustion and max-value permit all behave correctly.
• Numerical gap. The one invariant, sum of balances equals total supply minus burns, held across 256 fuzzed sequences of 24 mixed transfer, transferFrom and burn operations. Permit holds at the exact deadline and fails one second later, rejects malleable high-s and zero signatures without consuming a nonce, and the domain separator is rebuilt on a chain-id change so forks cannot replay.
• Library integrity. All 18 vendored OpenZeppelin files are byte-identical to upstream v5.0.2, confirmed by comparing against a fresh clone of that tag.

Tools run: forge build, the existing suite (34 passing), a 21-test scratch file (all passing, then deleted), and a file-by-file comparison against upstream OpenZeppelin. Slither and Mythril were not run. The factory, pool manager and distributor flows outside the protected floor tests were not re-audited, since the token taxes nothing and moves exact amounts.

Review complete. The findings file is written and validated, and the working tree is unchanged apart from it.

Result: no defects found in the assigned area. .imd-findings.json holds an empty findings list and a coverage record of ten rows: all six verifier entry points plus four invariant rows, every one holds with a reason.

What I checked, per guide

• Access Control. The token has no owner, minter, pauser, initializer, proxy or delegatecall. Every writer of _balances needs the holder's own call or allowance, every writer of _allowances needs the owner's call or a valid EIP-712 signature, and a wrong-signer permit reverts without consuming the nonce. The deployer cannot pull or burn from a holder without approval. The constructor hands out no role; it mints the whole supply once to the caller, which is the factory under the launch.
• Asymmetry. Mint and burn mirror each other on supply and balance. approve and permit write the same slot with the same event. transferFrom and burnFrom share the same allowance guard. transfer and transferFrom share the same transfer path with no fee or exemption branch. The only unused storage, the EIP-712 fallback strings, is unused because the name fits a short string.
• Trust Gap. With no privileged actor and no economic formula inside the token, none of the four seams exists. The factory holding all supply at construction is the launch design and a trust assumption, not a bypass.

Supporting evidence

• All 18 vendored OpenZeppelin files are byte-identical to upstream v5.0.2, diffed against a fresh clone.
• The existing 34-test suite passes. A scratch test confirming the deployer cannot burn or pull from a holder, and that a bad permit signature leaves the nonce at zero, passed and was removed.
• The slither output was empty and the aderyn large-literal note is a style lead only; the literal evaluates to exactly 1e27.

Not a defect but worth knowing for integrators: anyone can relay a signed permit early, so a contract that calls permit then transferFrom should tolerate a reverting permit. That is standard ERC-2612 behavior, already noted in the README.

The review is complete and the findings file is written. The working tree holds no source changes.

Result: no defects found. The Crawlyield token is a thin composition of OpenZeppelin 5.0.2 ERC20, ERC20Burnable and ERC20Permit with a zero-argument constructor that mints exactly one billion tokens with 18 decimals to the deployer. I checked it against the Economic Security, Invariant and Flow Gap guides and found nothing that fails with a concrete input.

What I verified:

• Vendored dependency integrity. All 17 OpenZeppelin files under lib/ are byte-identical to the npm release of version 5.0.2, so no hidden change to transfer, allowance, burn or signature logic.
• Conservation invariants. A scratch stateful fuzz ran 1,000 sequences of up to 64 random transfer, transferFrom, burn, burnFrom and permit calls. The sum of balances always equalled totalSupply, and supply never rose above the constructor mint.
• Launch flow exactness. A simulated factory deploy, the 10/88/2 percent split, a PoolManager-style sync-then-settle delta, and a trader buy and sell-back all moved exactly the named amounts.
• Economic surface. No fee, tax, hook, owner, pause, blacklist, mint path, receive or fallback. The compiled ABI exposes exactly the six nonpayable functions the verifier listed. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Permit. Deadline, per-owner nonce, domain separator with chain-id fallback and malleability rejection all hold. Permit front-running is a property of the ERC-2612 standard, not a defect in this token, so I did not report it.
• Static analysis lead. The aderyn large-numeric-literal note on line 32 is style only. The literal evaluates to the exact supply the brief requires.

The findings file contains an empty findings list and 13 coverage rows: one holds row for each of the six entry points, plus rows for the supply conservation, launch flow, privileged-role, dependency, static-analysis and manifest checks. The scratch test directory was removed since no finding carries a proof. No file outside .imd-findings.json was changed.

Added boundary, failure-path, permit, fuzz, and multi-actor invariant tests under test/.

Validation passed:

• forge build
• forge test with the required seed: 67 tests passed
• 32,768 invariant calls, no unexpected reverts

No implementation defects found. Existing source and configuration files remain unchanged.

The review is complete and the findings file is written. Nothing else is pending.

Outcome: no defects found. The report at .imd-findings.json holds an empty findings list and a ten-row coverage record, with every listed entry point marked as holding.

What I verified:

• Source. The token is a 44-line contract inheriting OpenZeppelin ERC20, ERC20Burnable and ERC20Permit. The constructor takes no arguments and mints 1e27 units to msg.sender. There is no mint path, owner, pause, blacklist, freeze, fee or transfer hook.
• Dependencies. All 18 vendored OpenZeppelin files are byte-identical to upstream v5.0.2, fetched from GitHub and diffed.
• Entry points. I traced approve, burn, burnFrom, permit, transfer and transferFrom through the unmodified library code, including each revert path and the protected floor's privileged-call probes. The deployer's burnFrom against a holder reverts on allowance, and launch flows move exactly the stated amount.
• Deployment. Runtime is 4,326 bytes and initcode 5,999 bytes, far under the limits. No address bits are required, so a factory-chosen CREATE2 salt deploys it. The manifest uses only schema keys, an empty constructorArgs list matching the constructor, and a totalSupply string equal to the minted amount.
• Build and tests. Forge 1.8.3 builds under solc 0.8.26 and all 67 project tests pass.
• Leads dropped. The four specialists and the test writer reported nothing, so there was nothing to reproduce or merge. Slither reported nothing. Aderyn's large-numeric-literal note on line 32 is a style remark about a correct constant, not a defect.

One trust note, not a finding: EIP-2612 permit in OpenZeppelin can be front-run by a third party submitting the signed permit first. That only reverts the relayer's call and still sets the intended approval, and no contract in this project wraps permit, so there is no loss.