The deliverable is complete and verified. forge build, forge test (31 tests, 0 failures) and forge fmt --check all pass with solc 0.8.26 pinned.

What was built

• src/OracleToken.sol: a self-contained, fixed-supply ERC-20. It returns the name "AutonomoUs oracle", symbol "ORACLE" and 18 decimals. The constructor takes no arguments and mints 1,000,000,000 × 10^18 to msg.sender once. There is no owner, mint, burn, fee, pause, blocklist, library, delegatecall or selfdestruct, so the launch flows the protected harness checks move exactly what they say.
• src/interfaces/IERC20.sol: the interface the token implements.
• script/DeployOracleToken.s.sol: a standalone deploy script whose run() reads no environment and hands off to a deploy() function the tests call directly. The launch itself deploys through the factory, not this script.
• test/OracleToken.t.sol: unit and fuzz tests for metadata, exact supply, minting to an EOA, a contract deployer and the script, success paths with events, every revert path, the absence of mint or admin or freeze entry points, rejection of ETH and unknown selectors, an opcode scan, and conservation of supply.
• foundry.toml at the repository root with bytecode_hash = "none", cbor_metadata = false, optimizer on, no ffi and no fs permissions. remappings.txt maps forge-std.
• lib/forge-std/: forge-std v1.11.0 vendored as plain files, exported with git archive so no nested repository or submodule remains.
• README.md: parameters, launch flow, assumptions, deployment paths, "After launch" (nothing to set), security notes and trust assumptions, and the tooling that ran.

Things to note

• No launch.json and no .imd-blocked.json were written. Nothing in the brief needed requester input.
• Slither and Mythril were not available here and did not run; the README says so.
• Nothing is committed. The working tree holds only the eight new paths listed above, and the vendored library carries no git metadata.

launch.json is written and verified. It is the only new or changed file in the tree.

What the manifest says

• Kind is custom_token. The token entry names the Solidity contract OracleToken with name "AutonomoUs oracle", symbol ORACLE, 18 decimals, empty constructorArgs, and totalSupply of 1000000000000000000000000000.
• The contracts list is empty, since the accepted tree contains only the token and no application contracts.
• Pool and economics are copied exactly as the launch gives them: IMD pair address, fee 12500, tick spacing 60, one-to-one initialPrice, and the requester's poolBps, initialMarketCapWei and remainderTo.
• Notes describe the token's fixed supply, absence of privileged roles and fee-free transfers, and state that the swarm share is the factory's and not written in the manifest.

How I checked it

• Read the accepted source. The constructor takes no parameters, matching the empty constructorArgs, and mints a constant 1e9 times 1e18 to msg.sender. The ABI from forge inspect confirms a zero-input constructor.
• Ran a scratch script that parses the manifest and asserts the schema keys, the supply equals the constructor's constant, the economics object is byte-identical to the job's, addresses are lowercase, initialPrice is below 2^256, and notes stay under the 4000-character limit. All assertions passed.
• Ran forge build and forge test. The build succeeded and all 31 existing tests passed.
• Confirmed with git status that launch.json is the only untracked or modified path.

Review complete. The permissions audit of src/OracleToken.sol found no defects, and .imd-findings.json holds an empty findings list with seven coverage rows, all holds.

What I checked, per the three assigned guides

• Access Control. The ABI exposes exactly three mutators: approve, transfer and transferFrom. There is no role, modifier, initializer, owner, pause, blocklist, mint, burn, proxy or delegatecall. The constructor takes no arguments and hands out no power; the deployer is an ordinary holder once it returns. Each storage slot has a single guard shape: allowances are written only by their owner through approve or decremented by the approved spender, and balances are written only by the constructor and the shared internal transfer.
• Asymmetry. Both mutators route through the same internal transfer, so the zero-receiver check and the balance check apply identically. The only branch is the unlimited allowance, which skips the decrement but not the balance check. Self-transfers through both paths leave the balance unchanged. No storage variable is written without being read or read without being written.
• Trust Gap. With no privileged actor and no setter, there is no seam where one caller class can redirect or extract value from another.

Adversarial probes run and passed in a scratch test, since removed: pulls by the deployer and by the token itself without allowance revert, allowance from one owner grants nothing over another, unlimited allowance is still bounded by balance, pulls from the zero address cannot mint, and supply is conserved under fuzzed mixed transfer and transferFrom sequences. The existing suite of 31 tests also passes.

Notes that are not defects. A zero-value transferFrom with no allowance succeeds and emits a Transfer event naming the victim as sender. EIP-20 mandates this and OpenZeppelin behaves the same, so I did not report it. Tokens sent to the contract's own address are stuck, which the README documents as a deliberate trade-off against adding a privileged rescue function. The aderyn large-literal lead is stylistic and the constant evaluates to the manifest supply exactly.

No launch.json is present yet, which is expected before the manifest step. The README's expected token entry matches the constructor and supply.

The review is complete and the findings file is in place.

Outcome: the token holds up under the Math Precision, Boundary and Numerical Gap guides. I found no defect that moves or loses value, and one cosmetic deviation recorded as info.

What I checked

• Build and the existing 31 unit and fuzz tests pass under solc 0.8.26.
• The supply constant on line 37, the only lead from static analysis, is a compile-time checked product equal to 1e27 and nowhere near overflow.
• The unchecked block in the transfer path is safe. The subtraction is guarded by the balance check and the addition cannot overflow because balances always sum to the constant supply. A full-balance self-transfer nets to zero because the recipient slot is read after the sender slot is written.
• The allowance path decrements at max minus one, skips the decrement at the max sentinel, and reverts on balance before any write when the value is the max integer.
• Boundary enumeration is trivial. The contract has no external calls, no payable or fallback paths, no byte decoding and no token-address parameters, so the only sentinel branches are the zero recipient and zero spender, both of which revert as intended.
• A scratch fuzz test over random transfers among four accounts kept the sum of balances at exactly 1e27 across 256 runs. The scratch directory has been removed.

The one finding, severity info: anyone can call transferFrom with the zero address as sender and a zero value. It passes both checks, moves nothing, and emits a Transfer from the zero address that looks like a mint. OpenZeppelin refuses this with ERC20InvalidSender, which the contract omits despite claiming ERC-6093 errors. Indexers that list zero-sender events as mints will show spurious zero-value rows. The reproduction and a one-line fix are in the report.

Coverage: all three entry points have rows, plus rows for the supply invariant, the literal lead, the boundary enumeration and the launch flows. Git status is clean apart from the gitignored findings file.

Review complete. The findings file is written at the repository root, no source files were changed, and my scratch test directory is removed.

Result: no fund-affecting defect in the ORACLE token. src/OracleToken.sol is a 150-line self-contained ERC-20 with no external calls, no owner, no mint or burn path, and a constructor that writes the whole 1e27 supply to msg.sender once. I traced all three state-changing entry points against the Execution Trace, Periphery and First Principles guides, and confirmed each by Foundry probes rather than by reading alone.

One finding, severity info. transferFrom(address(0), to, 0) succeeds from any caller and emits Transfer(address(0), to, 0), which is the shape of a mint event. The cause is that _transfer never validates from, so the zero allowance and zero balance of address(0) pass the two < checks at value 0. Balances and total supply are untouched, and any non-zero value from address(0) reverts, so the impact is limited to event-driven indexers. The fix is a one-line ERC20InvalidSender check, matching the ERC-6093 convention the contract already claims.

Coverage recorded for all three listed entry points plus the constructor, two invariants, the periphery files and the launch flows. All hold except transferFrom, which points at the finding above. Specifically verified:

• Unchecked arithmetic in _transfer is sound: the sum of balances is the constructor constant, fuzzed over random multi-actor sequences.
• Self-transfer, self-recipient transferFrom, max allowance, and allowance left intact on a balance revert all behave as intended.
• Interface selectors match canonical ERC-20 values, and the deploy script reads nothing from the environment.
• The aderyn large-literal lead resolves to exactly 1e27 and is not a defect.

Nothing in my area was left unreached. The existing 31-test suite passes on the current code.

Review complete. The findings file is at the repository root with one low-severity finding and ten coverage rows. No tracked file was changed.

Outcome. The token is economically sound for the launch. Supply is a compile-time constant minted once to msg.sender, there are no external calls, no privileged roles, no fee or burn on any path, and the sum of balances stayed equal to total supply under a stateful invariant run. A sync/settle balance-delta mimic of the Uniswap v4 PoolManager received exactly the seeded and sold amounts, so the factory, distributor, pool and trader flows all move what they say.

One finding, severity low. A zero-value pull from the zero address succeeds and emits a mint-shaped event.

• Any unprivileged caller can run transferFrom(address(0), anyone, 0) and the token emits Transfer(0x0, anyone, 0) and returns true. The internal transfer checks the receiver but never the sender, and a zero value passes both the allowance and balance checks at src/OracleToken.sol:139.
• No on-chain state changes, and a non-zero value from the zero address reverts on allowance. The impact is limited to off-chain consumers that treat Transfer-from-zero as a mint, which can be made to show spurious post-launch mints.
• Minimal fix: add an ERC20InvalidSender revert as the first line of the internal transfer, matching OpenZeppelin. The constructor does not go through that function, so the one-time mint is unaffected. I verified the proof test fails on the current code and passes on a scratch copy with that change, with the existing 31 tests still green.

Coverage. All three listed entry points have rows: approve and transfer hold, transferFrom carries the finding. Extra rows record the invariants and flows checked from the Economic Security, Invariant and Flow Gap guides: supply conservation, no supply growth, constructor mint to the factory, launch flow exactness, absence of dependencies and privileged powers, and metadata against the brief. Nothing in the assigned area was left unreached.

Leads not promoted. The approve overwrite race and the fact that tokens sent to the contract itself are stuck are both standard ERC-20 behaviour and documented in the README, so they are not reported. The aderyn large-literal note at line 37 is the supply constant and is correct.

The proof test lives at test/scratch/ZeroSenderMintEvent.t.sol and its source is embedded in the finding.

Done. All deliverables are in place and verified.

What I delivered (two new files under test/, building on the existing 31-test suite rather than rewriting it):

• test/OracleToken.invariant.t.sol adds the missing invariant coverage. A handler drives the token from five actors with bounded inputs across eight entry points, four happy paths and four planned failure paths that expect the exact revert and assert nothing moved. Ghost accounting tracks balances, allowances, and per-holder inflow and outflow, and random recipients are registered so the sum invariant stays complete. The suite runs with fail-on-revert on, so any unplanned revert is a failure. Inline config sets 256 runs at depth 64. Eight invariants hold: constant supply, sum of balances equals supply, balances and allowances match the ghost record, no balance exceeds supply, the zero address holds nothing, the contract holds no ether, and tokens sent to the token itself never leave. A vacuity guard in afterInvariant confirms every sequence actually ran calls.
• test/OracleTokenEdge.t.sol adds 29 unit and property tests for inputs the original suite skipped: the owner needing a self-allowance, from == to pulls, zero-value pulls without allowance, the max versus max - 1 allowance boundary, two spenders racing for one balance, no stray Approval on pulls, the exact one-word true return shape, short calldata rejection, the mint event emitted exactly once, a CREATE2 factory deployment, and the launch flows at their exact percentages. Fuzz tests run at 1000 runs each.

Result

Suite	Tests	Status
Existing unit/fuzz	31	pass
Edge cases	29	pass
Invariants (256 runs, 16,384 calls)	1	pass

One finding reported, not tested around. I wrote it to .imd-findings.json at low severity with a self-contained proof. The _transfer function guards the recipient but not the sender against the zero address. Anyone can call transferFrom(address(0), to, 0) with no allowance and it succeeds, emitting a Transfer from the zero address, which is the ERC-20 shape of a mint. No value or supply moves, but after a launch that forbids supply growth, any address can make explorers and indexers see phantom mints. OpenZeppelin reverts here with ERC20InvalidSender, which this contract omits from its otherwise ERC-6093 error set. The proof in test/scratch/ZeroSenderProof.t.sol fails on the current code with both of its tests and passes once the guard is added.

Nothing outside test/ and the findings file was changed, and nothing was installed. The new test files are uncommitted in the working tree, since the brief did not ask me to commit.

I found one real defect, rated low, and wrote it to .imd-findings.json. Nothing in the tracked tree changed; the only leftovers are git-ignored build output in out/ and cache/.

Finding 1 (low): transferFrom accepts the zero address as the sender (src/OracleToken.sol:138)

• Merged: all four specialist reports describe this same cause, so it is one finding. Two rated it info and two rated it low.
• Cause: _transfer refuses a zero recipient but never checks the sender.
• Effect: any caller can run transferFrom(address(0), to, 0). It passes the allowance and balance checks (both are 0, and 0 < 0 is false). It then emits Transfer(address(0), to, 0), which the token's own interface describes as a mint (IERC20.sol:7).
• Impact: off-chain only. Balances, allowances and total supply never change, and a non-zero amount from the zero address reverts on the allowance check. Explorers and "mint after launch" monitors can be made to show fake mints whenever someone wants.
• Fix: add if (from == address(0)) revert ERC20InvalidSender(address(0)); at the top of _transfer and declare that error.
• How I reproduced it: I ran both proofs the specialists attached. All three of their tests fail on the current code with the reasons the findings give. In a throwaway copy with the fix applied, all 64 tests pass (the three proof tests plus the 61 existing ones). The finding carries the write_foundry_tests proof, which checks both that the call reverts and that no mint-shaped event is emitted.

Coverage

• approve: holds. It refuses a zero spender and sets the allowance outright.
• transfer: holds. A transfer to yourself is handled correctly, there is no fee, and the launch transfers arrive whole.
• transferFrom: this is finding 1. Its allowance handling is otherwise correct.
• Supply invariant: holds. The constructor mints 1e27 once to the deployer and nothing can mint, burn or exercise any privilege afterwards. This matches launch.json (totalSupply and empty constructorArgs).

Leads I dropped

• aderyn "large numeric literal" at line 37: 1_000_000_000 * 10**18 is exactly what the manifest states, so it is not a defect.
• slither: reported nothing.

I couldn't run the protected launch test locally, because it needs the verifier's settings and v4 sources that aren't in this tree. A reading of the token gives no reason to expect it to fail.