Implemented Rise.sol: one billion RISE, 18 decimals, minted once to the deployer, with no fees or administrative powers.

Vendored dependencies, added success/failure and invariant tests, and documented launch parameters and the 90% pool / 10% network / 0% creator allocation.

forge build, all 32 reported tests, and forge fmt --check pass, including offline verification with an empty environment.

No deployment occurred; full Uniswap integration remains the network’s admission check.

I found no permission defects in src/Rise.sol, so .imd-findings.json has an empty findings list and a coverage row for each entry point. That is the only file I wrote; no source or config was touched.

What I checked

• The contract: src/Rise.sol is a plain OpenZeppelin v5.0.2 ERC-20. Its only code is a constructor that mints 1_000_000_000 * 10 ** 18 once to msg.sender (the factory). There is no owner, role, initializer, receive or fallback, and nothing that changes transfer behaviour.
• The OpenZeppelin files it uses: all five match the checksums in lib/SHA256SUMS, so the ERC-20 code is the unmodified library.
• Access control: no function is restricted, and none needs to be. approve only sets the caller's own allowance. transfer only moves the caller's balance. transferFrom requires an allowance from the owner and has no bypass.
• Trust gap and asymmetry: no one holds any power after deployment. Nobody can mint, burn, pause, blacklist, freeze, seize, upgrade, or charge a fee. The launch addresses (factory, pool manager, distributor) get the same rules as every other holder, so the launch transfers move exactly the amounts they say.
• Static analysis: Aderyn's "large numeric literal" warning at src/Rise.sol:12 points at the intended supply constant, so it isn't a defect.
• Tests: forge test passes all 32 tests in the 3 suites, including the invariant run (8,192 calls, 0 reverts).

Coverage: approve, transfer and transferFrom each behave as intended. I also checked two invariants: no privileged roles exist after deployment, and the supply is fixed and minted to the factory. Both hold. I did not run the protected launch-flow test in .imd/reads/protected/, because it needs v4-core files that aren't in the repository.

Outside my area: 7 forge-std files in lib/forge-std/src don't match lib/SHA256SUMS. forge-std is only used by tests and doesn't affect the deployed token, so I didn't file it as a finding. Still, the checksum file is out of date and should be regenerated.

I found no math defects in Rise. The only thing I reported is one info-level note outside the math area. Results are in .imd-findings.json, and I changed no other files.

What the token is: src/Rise.sol is a plain OpenZeppelin v5.0.2 ERC20. Its constructor mints 1_000_000_000 * 10**18 to the deployer once, and there are no other functions. The OpenZeppelin files match their recorded checksums, so the library code is unmodified. The build succeeds and all 32 existing tests pass, including the invariant test.

What I checked against the Math Precision, Boundary and Numerical Gap guides:

• Supply: the amount is a compile-time constant equal to exactly 1e27, far below the uint256 limit. Aderyn's "large numeric literal" warning is just this intended value.
• Transfer math: a transfer larger than the sender's balance reverts. OpenZeppelin skips overflow checks on the subtraction and addition, which is safe because no balance can exceed the fixed 1e27 supply. Zero-amount and self-transfers keep balances unchanged, and there is no fee.
• Allowance math: an unlimited allowance is never reduced. Otherwise the call reverts before the unchecked subtraction if the allowance is too small.
• Launch split: the 10% swarm share comes to exactly 1e26 and the 90% pool share to exactly 9e26, with nothing left over. That matches 0 tokens to the creator. 9e26 also fits within the 128-bit amounts the Uniswap v4 pool uses.

Coverage: approve, transfer and transferFrom are all marked holds. I also added rows for the supply, launch-split and total-supply invariants.

The note: running sha256sum --check lib/SHA256SUMS fails for 7 forge-std files, although the dependency notes say they are unmodified. Only the tests use forge-std, so the deployed token isn't affected. The fix is to regenerate the checksums or restore the original v1.9.7 files.

Not covered: there is no launch.json yet, so I couldn't check the manifest's price or economics fields. I reasoned from the brief's numbers instead.

I found no defects in Rise's control flow. The results are in .imd-findings.json: one info-level note outside my area and a coverage row for each of the three entry points. I changed no tracked files.

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

• The contract: src/Rise.sol is a bare OpenZeppelin v5.0.2 ERC-20. Its constructor mints 1_000_000_000 * 10**18 to msg.sender, which is the factory. It has no owner or roles, no fee branches, no outside calls, and no mint or burn reachable after deployment.
• Within a transaction:
  • transferFrom spends the allowance before it moves the balance, and any revert undoes both.
  • The unlimited-allowance value (type(uint256).max) only skips reducing the allowance. It never skips the balance or receiver checks.
  • Transfers to or from address(0) revert, so tokens can't be burned that way.
  • A transfer to yourself keeps your balance correct.
  • Every amount moves exactly, so the launch transfers (factory → distributor, distributor → claimant, both directions through the PoolManager) arrive whole.
• Across transactions: there are no settings to change, no multi-step operations and no roles. The approve front-running race is ordinary ERC-20 behaviour and the README already documents it.
• Supporting code: the five vendored OpenZeppelin files match their recorded checksums and the v5.0.2 code. Context._msgSender simply returns msg.sender.
• Static analysis: aderyn's large-numeric-literal warning at src/Rise.sol:12 is about style only, not a defect.
• Tests: forge test --offline passed all 32 tests, including both invariant checks.

Finding (info, outside my area, test-only): sha256sum --check lib/SHA256SUMS fails for 7 forge-std files. They were reformatted with forge fmt, but the checksums recorded are upstream v1.9.7's; I confirmed that by fetching upstream Vm.sol and console.sol. This contradicts the docs' claims that the files are "unmodified" and the checksums matched. It doesn't change the deployed bytecode.

Coverage: all three entry points (approve, transfer, transferFrom) hold. I added rows for the supply invariant, the exact launch transfers, the constructor's roles and starting balances, and the vendored dependencies; all hold.

Not covered: I couldn't run the protected admission test here, because it needs the factory, Uniswap v4 and launch inputs that aren't in this repo. The other specialists' guides were outside my assignment.

Created launch.json matching Rise’s constructor, exact supply, required economics, and paired currency. Documented defaults: 0.3% pool fee and tick spacing 60.

Schema and constructor ABI checks passed. Offline forge build succeeded; forge test passed all 32 tests. Only launch.json is changed for submission.

Review complete. .imd-findings.json is written and validated (snippet matches the tree; all three listed entry points have coverage rows).

Summary

Scope covered (Economic Security, Invariant, Flow Gap guides): src/Rise.sol is a 13-line wrapper over OpenZeppelin v5.0.2 ERC20, which I confirmed byte-identical to upstream. I traced every mutating entry point (approve, transfer, transferFrom) through _update/_approve/_spendAllowance against each failure mode in my three guides, and substantiated the holds verdicts with a scratch Foundry suite (test/scratch/EconReview.t.sol, 6 tests incl. 512-run fuzz, all passing) plus the project's existing 32 tests.

What holds:

• Supply is exactly 1e27 minor units, minted once to msg.sender; no mint/burn/owner/pause/upgrade selector, no receive/fallback.
• sum(balances) == totalSupply under every path; sentinel address(0) calls revert rather than silently succeed; finite allowances decrement exactly, uint256.max stays infinite.
• The launch flows (10% → distributor, 90% → pool, claims, buy/sell through the PoolManager) move exactly what they say — no fee, hook, external call or dependency for a flow-gap seam to form across. 90% + 10% = 100%, so remainderTo receives only seed-rounding dust, which the README already discloses.

One finding (low, outside my area but concrete): the committed lib/SHA256SUMS fails for seven forge-std files because they were re-wrapped by forge fmt after the sums were recorded; sha256sum --check lib/SHA256SUMS reports 7 mismatches, contradicting README line 26's "Vendored checksums matched". Whitespace-only, test-only — provenance, not behaviour. Fix is to restore the pristine v1.9.7 files (no config change needed) or regenerate the sums.

Not reached / limits: no launch.json exists yet, so manifest-vs-constructor checks are deferred to that step; the protected harness needs the network's v4/factory support contracts, which aren't in this tree, so I verified the ERC-20 legs it exercises rather than running it. Static-analysis leads (aderyn large-literal) were checked and are cosmetic.

Added 13 tests covering allowance boundaries, revocation, isolation, failed-call rollback, and arbitrary recipients. Expanded stateful invariants to nine actions.

Offline verification passed:

• forge build
• forge test: 45 passed, 0 failed
• 24,576 invariant calls, no unexpected reverts

Only test/ changed. Assumptions and external integration limits are documented in test/README.md. No reproducible implementation defects found.

Saved .imd-findings.json.

• One reproduced low-severity checksum finding; three duplicates merged.
• All three token entry points hold.
• 45 Foundry tests and formatting passed.
• Protected pool integration remains unverified because dependencies and launch inputs are absent.

Source and configuration files remain unchanged.