I've built the Yield Fields Deed token as contract YFDToken in src/YFDToken.sol. forge build, forge test (9 tests pass) and forge fmt --check all pass with solc 0.8.26. The work is not committed: git has no author name or email set on this machine, and changing that would mean touching .git/, which I'm not allowed to do. The files are staged on a new branch, yfd-token.

The token

• Name "Yield Fields Deed", symbol "YFD", 18 decimals.
• The constructor mints 1,000,000,000 YFD (1000000000000000000000000000 in smallest units) once, to the deployer (the launch factory). It takes no constructor arguments.
• It is a standard OpenZeppelin v5.1.0 ERC-20 with nothing added: no owner, no further minting, no pause or blacklist, and no fee or burn on transfer. So the factory's transfers, the pool seed and trades move exactly the amounts they state.
• I scanned the deployed bytecode for DELEGATECALL, CALLCODE and SELFDESTRUCT and found none.

Tests (test/YFDToken.t.sol) cover:

• name, symbol and decimals;
• the whole supply going to the deployer;
• exact transfers, approvals and transferFrom;
• failures: transferring more than the balance, sending to the zero address, and transferFrom without an allowance;
• calls to mint, owner, pause and burnFrom all failing;
• a fuzz test that transfers never change the total supply.

I did not run the launch's own checks (.imd/reads/protected/...). They use code the verifier supplies, which isn't in this repository.

Setup

• foundry.toml pins solc 0.8.26, turns the optimizer on and sets bytecode_hash = "none".
• forge-std v1.9.7 and the contracts/ folder of OpenZeppelin v5.1.0 are copied into lib/ as plain files, not submodules.
• README.md covers the deployment parameters, assumptions, the fact that nothing needs setting after launch, and what operators and holders are responsible for.
• I did not write launch.json; the manifest step does that.

To commit, set a git author name and email and run git commit.

Done. I wrote launch.json at the repository root and it is the only changed file.

What the manifest describes. The accepted tree holds a single contract, YFDToken in src/YFDToken.sol. It takes no constructor arguments and mints the whole supply once to msg.sender, so the manifest's constructorArgs list is empty and totalSupply is the constant from the source in minor units. There are no application contracts, so contracts is an empty list.

Manifest contents.

• kind is custom_token, with name Yield Fields Deed, symbol YFD, decimals 18.
• totalSupply is 1000000000000000000000000000, which matches the source constant and the README.
• pool is the launch's own: IMD pair address, fee 12500, tick spacing 60, initialPrice as provenance.
• economics is copied verbatim from the job.
• notes describe only the token actually present, in well under the 4000 character limit.

Checks run.

• A node script confirmed the manifest has only schema keys, the supply equals 10^27, and economics matches the job string byte for byte.
• forge build compiled cleanly and forge test passed all 9 tests.
• git status shows launch.json as the only new or changed file.

The review is complete. The findings file is written and valid, the scratch test is removed, and the working tree shows no tracked changes.

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

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• The token itself. It is a 17-line wrapper that mints 1,000,000,000e18 to msg.sender in the constructor and adds nothing else. No owner, fee, burn, mint, pause, blacklist, hook, receive or fallback exists. Runtime bytecode has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The vendored library. OpenZeppelin is version 5.1.0, and the ERC20 and Context sources read as unmodified upstream code with no overrides of the sender or update paths.
• Conservation and exactness. A scratch Foundry test fuzzed multi-hop transfers and confirmed the sum of balances always equals total supply. Every launch flow arrives whole: factory to distributor, factory to pool manager, factory to requester, distributor to claimant, and a pool-manager-style pull through transferFrom. Since 1e27 divides evenly by 10,000, every basis-point split is integer-exact.
• Allowance semantics. Max-uint allowance is never decremented, finite allowance decrements by exactly the amount spent, and the zero address reverts on every path. The approve-overwrite race is a property of the ERC-20 standard rather than a defect here, so it is not reported.
• Static analysis lead. Aderyn's large-numeric-literal warning was reproduced as a non-issue. The literal evaluates to exactly the manifest supply.

Not covered: launch.json, which is absent from the tree and written by a later step per the brief.

The review is complete and the findings file holds a clean result.

Outcome: no defects found in the Math Precision, Boundary or Numerical Gap areas. The file .imd-findings.json holds an empty findings list and seven coverage rows, one per listed entry point plus the invariants I checked. The scratch test directory was removed, so the working tree is unchanged apart from the findings file.

What was checked

• Source and library. The token is a 16-line fixed-supply wrapper over OpenZeppelin ERC20 with no overrides. The five vendored files the token imports are hash-identical to upstream OpenZeppelin v5.1.0, so the arithmetic under review is the audited upstream code.
• Entry points. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no mint, burn, owner, payable, receive or fallback path, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Precision and boundaries. A sixteen-case scratch suite exercised zero amounts, the whole supply, supply plus one, max uint, self-transfer via both paths, infinite and near-infinite allowances, the exact-allowance edge, allowance exceeding balance, zero-address spender and sender, approve overwrite semantics, and value sent to non-payable functions. All behaved as ERC-20 specifies. An eight-hop fuzz confirmed the sum of balances stays exactly at the supply.
• Supply constant. The literal evaluates to exactly 1e27, matching the brief and README, and fits int128 so Uniswap v4 deltas and the launch's percentage shares divide exactly. The aderyn large-literal lead is style only.
• Deployment boundary. The creation bytecode executes to completion via eth_call on Robinhood Chain, Base and Ethereum, so the PUSH0 and MCOPY opcodes solc 0.8.26 emits are supported where it deploys.

Not covered: nothing in the assigned area was left unreached. Access control, economics and launch manifest contents belong to the other specialists and no launch.json exists yet in this tree.

Review complete. No defects found in the assigned area, and the findings file is written with the empty list and seven coverage rows.

Outcome. The token at src/YFDToken.sol is a 16-line contract inheriting the vendored OpenZeppelin v5.1.0 ERC-20 with no owner, no modifiers, no constructor arguments and no overrides. Nothing in the Access Control, Trust Gap or Asymmetry guides applies with a concrete failure, so the report is clean.

What I verified

• Permission model. The compiled ABI exposes only the standard ERC-20 functions plus a constant view. Fourteen common admin, mint, pause, blacklist and seize selectors revert when called from the deployer. There is no receive or fallback, and calls carrying ETH revert.
• Deployer residual power. After the constructor mints the supply to the factory, the factory cannot pull a holder's balance without allowance, cannot change supply, and cannot stop a holder transferring. Checked with a scratch Foundry test, since deleted.
• Vendored library integrity. The five OpenZeppelin files the token compiles against are byte-identical to upstream v5.1.0, so no hidden privilege lives in lib/.
• Asymmetry. Transfer and transferFrom move identical amounts through the same internal path. Allowance decrements exactly, with the documented infinite-allowance exception. Zero-address guards are mirrored on both sides. Self-transfers conserve balance. All fuzzed over 256 runs.
• Launch floor. The protected test's exact opcode walk finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Supply equals the manifest value and sits entirely with the deployer.

Static-analysis lead. The aderyn large-numeric-literal note on line 11 is a style remark. The expression equals the manifest supply exactly, which the project's own test asserts. Not a defect.

Not covered. Nothing in my area was left unreached. Launch-flow economics and pool seeding belong to other specialists, though the floor tests they depend on would pass on this code as far as the token's behavior goes.

The review is complete. The findings file is written with an empty findings list and ten coverage rows, and the scratch test and temporary downloads are removed, leaving the tree clean apart from the findings file.

Outcome: no defect found in the Yield Fields Deed token. All three listed entry points hold.

What was reviewed under the Execution Trace, Periphery and First Principles guides:

• Token source. src/YFDToken.sol is a 16-line OpenZeppelin ERC20 subclass. The constructor mints exactly 1e27 minor units once to the deployer and nothing else can mint. The compiled ABI exposes no owner, mint, burn, pause, blacklist, initialize or upgrade selector.
• Entry points. Transfer and transferFrom move the exact amount with no fee, burn or hook, revert on insufficient balance, zero receiver and insufficient allowance, and conserve supply under fuzzing. Approve behaves per OpenZeppelin v5. Infinite allowance is not decremented, which is the standard semantics.
• Periphery. The five OpenZeppelin files the token compiles are byte-identical to the upstream v5.1.0 release. The remaining vendored files differ only by forge fmt whitespace and are not compiled into the token.
• Runtime and chain. The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CREATE2. It uses PUSH0 and MCOPY, and an eth_call on Robinhood Chain executing both opcodes succeeded, so the Cancun build runs on the target chain.
• Launch flows. A scratch test moved the swarm share, pool seed and remainder, then claim and sell legs, with exact balances. The project tests, a format check and the build all pass.

Static analysis leads. Slither reported nothing. The aderyn large-numeric-literal line is the intended supply constant and not a defect.

Not reported on purpose. The ERC-20 approve front-running race is inherent to the interface and documented by OpenZeppelin, so it is noted in the coverage row rather than filed as a finding.

Done. forge build and forge test pass with 47 tests across three suites, and only files under test/ were added. No defects were found in the token, so no findings file was written.

What I added

• test/YFDToken.edges.t.sol (37 tests). Failure paths and edges on top of the existing suite: one wei, the whole supply, one over it, max uint, the same call twice, zero-amount transfers, self-transfer, zero receiver and zero spender, allowance one over and exactly drained, infinite allowance not decremented, owner needing a self-allowance, reverted calls spending nothing, allowance directionality, ether and unknown selectors rejected, and a runtime scan for DELEGATECALL, CALLCODE, SELFDESTRUCT and the EIP-170 size cap. It deploys through a factory probe in one transaction and checks the mint event, then simulates the launch flows the protected floor test performs: distributor share, pool pull under allowance, remainder, claim, and a buy-and-sell round trip, each asserted to the exact amount. Admin and privileged selectors are tried from a stranger, the deployer and the test, and must all revert. Seven fuzz tests at 1000 runs cover reverts above balance or allowance and exact conservation.
• test/YFDToken.invariant.t.sol. A handler with eight actors (deployer, distributor, pool manager, requester, four holders), clamped handlers that must succeed, and unclamped ones that must revert with the exact error and move nothing. Ghost books track every balance, allowance and flow. Seven invariants run at 256 runs and depth 64 with fail-on-revert: fixed supply, actor balances sum to supply, balances and allowances match the ghost books, nobody sends more than they received, the zero address and token hold nothing, and metadata never changes.

Grounding

I ran the same handler and invariants against three broken tokens in the scratch area: a 1% burn on transfer, a public mint, and an accumulating approve. Each was caught by multiple invariants, so the properties are not vacuous.

Not worth a finding

Tokens sent to the token contract itself are stranded with no recovery path. That is standard ERC-20 behaviour and the README documents it, so I pinned it as a test rather than reporting it.

The review is complete. The findings file is valid, the scratch directory is removed, and the working tree is unchanged apart from the untracked .imd-findings.json output.

Outcome: clean review, zero findings. All five specialists reported nothing, and I confirmed that independently rather than taking their word for it.

What I verified against the code:

• Source is a 16-line contract: OpenZeppelin v5.1.0 ERC20 with a constructor that mints exactly 1e27 to msg.sender. No owner, mint, burn, pause, blacklist, fee, or hook of any kind in the ABI.
• Vendored library is a flattened copy, not a submodule, so I read the ERC20 and Context bodies in full. They are identical to upstream v5.1.0, with _msgSender returning msg.sender and no hidden overrides.
• Bytecode has no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE. Creation code is 2,645 bytes and runtime 1,752 bytes, far under the protocol limits. The constructor takes no arguments, so CREATE2 deployment by the factory needs nothing the manifest does not give.
• Manifest uses only schema keys, lowercase addresses, correct types, supply matching the constructor, decimals matching, and notes well under the 4,000-character cap.
• Entry points were traced through every success and revert path in a scratch Foundry test I wrote and ran, covering exact-amount transfers, zero-address reverts, insufficient balance and allowance reverts, finite and infinite allowance handling. The project's own 47 tests, including an invariant suite, also pass.
• Static analysis leads: Slither reported nothing; the aderyn large-numeric-literal note is stylistic, the literal evaluates to exactly 1e27.

The coverage record marks all three entry points as holds, plus three invariant rows for fixed supply, deployability and dependency integrity. Nothing blocks admission of this launch.