I've built the Sworn (SWORN) token. forge build, forge fmt --check and forge test all pass, including with the verifier's fuzz seed, and it's committed as 59cc1d2. I couldn't run the two protected launch tests here, because they need files only the verifier has (the pool manager code and the owner checks). The token was written to meet what they check.

The token (src/SwornToken.sol, contract SwornToken)

• It's a standard ERC-20 named "Sworn" with symbol "SWORN" and 18 decimals.
• The constructor mints all 1,000,000,000 tokens once, to whoever deploys it (in the launch, IMD's factory). The supply can never change after that.
• It takes no constructor arguments.
• There is no owner, mint, burn, pause, blacklist, transfer fee or upgrade path. Every transfer moves exactly the amount it says, so the launch's payouts, pool seed and trades all work without exemptions.
• It doesn't call other contracts and uses no libraries, so there's nothing to link before deploying.

Tests (test/SwornToken.t.sol): 18 tests, all passing. They check the name, symbol, decimals and supply; that the whole supply goes to the deployer; transfers and approvals; each failure case (not enough balance or allowance, sending to or approving the zero address); that unlimited approvals aren't used up; that the deploy script's deploy() works; that admin-style calls like mint, pause or blacklist don't exist; and two fuzz tests showing the total supply never changes.

Setup

• foundry.toml pins solc 0.8.26 with bytecode_hash = "none" and the optimizer on, and does not enable ffi or file access.
• forge-std v1.9.7 is copied into lib/forge-std as ordinary files, not a submodule.
• script/DeploySworn.s.sol is a reference deploy script for local review only; it reads no environment variables. The real launch goes through IMD's factory.

README: it lists the token's details, assumptions and deployment parameters (none), and says there are no admin roles or "After launch" settings to manage. It also notes that tokens sent to the wrong address can't be recovered, and that passing tests are not a security audit.

Git had no author set on this machine, so I made the commit under your name and email (Johan Struber, johanstruber@protonmail.com). I did not write a launch.json; that's left to the manifest step.

launch.json is written and verified. Only that file changed.

What the manifest says

• Kind custom_token, token contract SwornToken, name Sworn, symbol SWORN, 18 decimals.
• Empty constructorArgs, matching the accepted no-argument constructor in src/SwornToken.sol.
• totalSupply in minor units, equal to the constant the constructor mints to msg.sender.

Field	Value
totalSupply	1000000000000000000000000000
notes length	916 characters

• No application contracts, since the accepted tree contains only the token.
• Pool and economics copied verbatim from the launch terms: IMD pair, fee 12500, tick spacing 60, the given initialPrice, and the requester's economics object.

Checks run

• The JSON parses with exactly the schema's six top-level keys and the asserted values.
• forge build compiles cleanly.
• forge test with the verifier's fuzz seed passed all 18 tests.
• git status shows launch.json as the only new or changed path.

The permissions review of SwornToken is complete. The findings file is written and validated, the scratch directory is removed, and the working tree holds no other changes.

Outcome. The token has no permission surface to break. It is a 70-line fixed-supply ERC-20 with no owner, initializer, proxy, mint, burn, pause, blacklist, fee, external call, delegatecall or selfdestruct. The compiled ABI confirms only three state-changing functions, all ordinary ERC-20. Each writes only the caller's own slots or slots the owner explicitly approved. The deployer holds no power over any other holder once the constructor finishes.

One finding, severity info. The zero-address sentinel checks are asymmetric. approve rejects a zero spender and transfers reject a zero receiver, but nothing rejects a zero sender. Anyone can call transferFrom(address(0), x, 0) and it succeeds, emitting a mint-shaped Transfer(address(0), x, 0) event. No balance or supply changes, and any nonzero value from the zero address reverts first on allowance, so this is event hygiene only. OpenZeppelin reverts in this case. The minimal fix is a zero-sender revert at the top of the private transfer helper. I verified the behaviour with a scratch Foundry test before reporting it.

Coverage. All three listed entry points have rows: approve and transfer hold, transferFrom carries the info finding. I added rows for the constructor, the no-privileged-role invariant, fixed supply, holder-balance protection, the Trust Gap seams, the reference deploy script, and the aderyn large-literal lead, which is a style note on a constant that equals the required supply exactly.

Not reached. The protected launch floor test could not be run locally because it depends on v4-core and launch library sources not present in this tree. By inspection the token satisfies it: no constructor arguments, exact supply minted to msg.sender, decimals 18, exact transfers on every flow, no forbidden opcodes.

The review is complete and the findings file is written. The git status came back empty for tracked changes since .imd-findings.json is ignored, and the scratch tests are removed.

Outcome: the Sworn token holds up under the Economic Security, Invariant and Flow Gap checks. I found no defect that affects funds, supply or the launch flows. One informational deviation from reference ERC-20 behaviour is recorded.

What I checked in src/SwornToken.sol against the three guides:

• Economic Security. No external dependencies, oracles, callbacks or low-level calls exist. The token is not fee-on-transfer, rebasing, pausable or blacklistable, and both transfer paths return true. Sentinel handling is correct: zero receiver and zero spender revert.
• Invariant. Total supply is immutable and set once to exactly 1e27 in the constructor, all credited to the deployer. The ABI exposes only ERC-20 getters plus approve, transfer and transferFrom, so no path can grow or freeze balances. A multi-actor fuzz with self-transfers kept the sum of balances equal to total supply. The unchecked arithmetic is safe because that sum is bounded.
• Flow Gap. Factory to distributor, pool seed, swaps and claims all move exactly the stated amount, so the protected floor's balance-delta checks are met without exemptions. The reachable-opcode scan from the protected test finds no DELEGATECALL, CALLCODE, SELFDESTRUCT or CALL.
• Static-analysis lead. The aderyn large-literal note is style only. The literal evaluates to exactly the stated supply.

The one finding (info): transferFrom accepts a zero-address sender when the value is zero. Any account can call it with the zero address and value 0, and the token emits a zero-value Transfer from the zero address, which indexers read as a mint. Balances and supply are untouched, and any non-zero value reverts. OpenZeppelin rejects this path. The minimal fix is a zero-sender check in the private transfer helper.

Coverage: all three listed entry points have rows, two hold and one points to the info finding, plus four invariant rows. Nothing in my area was left unreached.

The math review of the Sworn token is complete. The result is one informational finding and no defects in the arithmetic itself.

What I reviewed. The token at src/SwornToken.sol is a 70-line fixed-supply ERC-20 with no owner, no mint, and no external calls. Its whole math surface is the compile-time supply constant, two unchecked subtractions, and one unchecked balance addition. I checked it against the Math Precision, Boundary and Numerical Gap guides from the Pashov reference and against the OpenZeppelin reference semantics.

What holds.

• The supply constant equals exactly 1e27 minor units, confirmed with cast to-wei and a test assertion. The aderyn "large numeric literal" lead is stylistic only.
• Both unchecked subtractions run only after a strict less-than check reverts first, so neither can wrap.
• The unchecked balance addition cannot overflow because no mint path exists after the constructor and balances always sum to 1e27. A fuzz test of three-party transfers and a full-supply hop confirm conservation.
• Max-uint transfers, full-balance self-transfers, zero-value transfers, the infinite-allowance sentinel at exactly max and at max-1, and exact allowance consumption all behave as intended.
• There is no division, scaling, downcast, payable path or external call, so most guide items have nothing to apply to. Sending ETH to the contract reverts.

The one finding (info). Any caller can execute transferFrom(address(0), to, 0) successfully. The function checks the receiver for the zero address but never the sender, and a zero value passes both the zero allowance and the zero balance of the zero address. The result is a mint-shaped Transfer(address(0), to, 0) event emitted by an unprivileged third party. No balance, allowance or supply changes, so no funds are at risk. Indexers that treat a Transfer from the zero address as a mint would record a zero mint, and holder lists could be spammed. OpenZeppelin v5 reverts in this case. The minimal fix is a sender zero-address check in the internal transfer helper. Reproduction is verified by a scratch Foundry test that passes on the current code.

Deliverable. Findings and coverage are in .imd-findings.json at the repository root. Coverage marks approve and transfer as holding, transferFrom as carrying finding 1, plus five invariant and boundary rows that hold. The scratch test lives under test/scratch/ and is not kept. No tracked file was changed. The existing 18-test suite passes, as do my 14 scratch probes.

Not done. No proof file was attached because the finding is informational, not critical or high. Nothing in my assigned area was left unreached.

The control-flow audit of SwornToken found one low-severity defect, and it's recorded in .imd-findings.json with 8 coverage rows. No tracked files changed, and I removed my scratch tests and build output.

Finding: anyone can emit a fake mint log (low)

• Location: src/SwornToken.sol:60. _transfer checks the receiver but not the sender.
• Failing input: any account can call transferFrom(address(0), 0xB0B, 0). It succeeds and emits Transfer(0x0, 0xB0B, 0), which looks like a mint.
• Impact: no balance, allowance or supply changes, and no funds are at risk. Only off-chain readers that treat a transfer from 0x0 as a mint are misled, such as explorers or supply scanners.
• Fix: reject from == address(0), the same way line 60 rejects a zero receiver.
• Proof: the included Foundry test fails on this code and passes on a temporary copy with that check added (the copy reused InvalidReceiver; the finding recommends a new InvalidSender error).

Coverage

Target	Verdict	Basis
approve	holds	Writes only the caller's own allowance; zero spender and malformed addresses revert.
transfer	holds	Self-transfer, full balance, short calldata and attached ETH all behave correctly.
transferFrom	finding 1	Otherwise correct: allowance key, max-allowance handling and reverts all hold.
Fixed supply	holds	256 invariant runs (128,000 calls) passed, and the unchecked blocks cannot wrap.
Launch flows	holds	Swarm share, claim, seed, remainder, buy and sell all moved exact amounts.
Runtime bytecode	holds	No external calls, DELEGATECALL, CALLCODE or SELFDESTRUCT.
Single mint	holds	Only the constructor sets the supply.
Deploy script and README	holds	The script is reference-only and the README's claims match the code.

I went through all three guides (Execution Trace, Periphery, First Principles). Most of their items don't apply here, because the token has no external calls, assembly, oracles or libraries of its own. The aderyn large-literal lead isn't a defect: the value is exactly 10^27.

What this doesn't cover

• Protected floor tests: they could not run because src/LaunchLiquidity.sol, PoolInitializationGuard and HookFlags aren't supplied. Instead, I ran the compiled token through the current Uniswap v4-core main branch in a temporary harness, with ETH and both ERC-20 currency orders.
• Limits of that harness: it used a pool with no hook and my own settlement code, so it doesn't replace the floor tests.
• Manifest: launch.json isn't in the tree yet, so it wasn't reviewed.
• Project tests: all 18 pass, but the dead type(uint256).max branch in testFuzz_transferFrom never runs. That's only a test gap, since test_infiniteAllowanceNotDecreased and my own tests cover that behaviour, so I didn't report it.

Review complete. The findings file is written at .imd-findings.json and the tree is otherwise unchanged.

Outcome: one finding kept, at low severity, merged from all five reports. Nothing else reproduced or surfaced.

• Kept and merged. All five specialists (math, flow, economics, permissions, and the test writer) reported the same root cause: _transfer rejects a zero receiver but not a zero sender, so anyone can call transferFrom with from = 0x0 and value 0 and make the token emit a mint-shaped Transfer event after construction. I traced both guards (allowance 0 < 0 false, balance 0 < 0 false) and confirmed no state changes. Recalibrated to low: no funds move and no on-chain guarantee breaks, but off-chain mint labels and holder lists can be spammed on a token advertised as fixed-supply.
• Proof verified. The flow specialist's attached test fails on this tree with the stated message and passes on a copy where _transfer reverts for a zero sender. I attached it to the finding.
• My own pass found nothing further. approve and transfer hold. Allowance handling, the infinite-allowance sentinel, unchecked arithmetic, self-transfers and supply conservation all check out. No receive, fallback, owner, mint, burn, delegatecall or selfdestruct exists. All 62 project tests pass.
• Manifest checked. Empty constructorArgs match the no-argument constructor, totalSupply matches the minted amount exactly, decimals and names agree, and bytecode is far below size limits.
• Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is a style remark on the supply constant and is not a defect.

Coverage answers all three entry points plus two invariant rows. Scratch test files and the temporary fixed copy were removed.