The Pangea token project is complete and verified.

What was built

• src/PangeaToken.sol: contract PangeaToken, a plain OpenZeppelin v5.1.0 ERC-20 named Pangea with symbol PANGEA and 18 decimals. The constructor takes no arguments and mints the full one billion token supply once to msg.sender, which is the factory at launch. There is no owner, mint, burn, pause, blocklist, fee or fallback, so no privileged call exists and the supply cannot grow.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none" and disables CBOR metadata, with ffi off and no filesystem permissions. remappings.txt maps forge-std and OpenZeppelin.
• lib/forge-std (v1.9.7) and lib/openzeppelin (v5.1.0, contracts only) are vendored as ordinary files with no git submodules.
• script/DeployPangea.s.sol exposes a deploy() function the tests call directly. It reads no environment variables.
• test/PangeaToken.t.sol and test/DeployPangea.t.sol hold 34 tests. They cover metadata and the one-time mint (including when a contract deploys, as the factory does), successful and failing transfers and allowances with exact revert reasons, rejection of every admin-shaped and privilege-shaped selector from both a stranger and the deployer, a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, the launch flows arriving whole, and four fuzz tests for conservation and allowance arithmetic.
• README.md documents assumptions, deployment parameters, the empty "After launch" list, operational responsibilities and the security checklist walk-through.

Verification

forge build, forge test and forge fmt --check all pass, including a clean offline rebuild with an empty environment. The fuzz suite passes with the verifier's seed, three other seeds, and a 2000-run pass. Slither and Mythril are not on this machine and were not run.

One environment note

The sandbox bind-mounts every .gitmodules file read-only, so the nested one from the OpenZeppelin clone could not be deleted. The vendored sources were moved to lib/openzeppelin and the orphaned lib/openzeppelin-contracts/ directory, which now contains only that one locked file, is listed in .gitignore. It is a plain file, not a submodule, and git's dry-run add confirms it is excluded.

Created launch.json matching PangeaToken, its no-argument constructor, exact supply, and required pool/economics values.

forge build succeeded; all 34 tests passed. Manifest fields and compiled ABI match. Only launch.json is included in the submission changes.

I found no math, precision, boundary or numerical-gap defects in Pangea (PANGEA), so .imd-findings.json has an empty findings list and five coverage rows, all holds.

What's in the code: src/PangeaToken.sol is an unchanged OpenZeppelin v5.1 ERC20. It has no overrides, no fee, burn, owner or rounding, and one mint in the constructor. The only arithmetic in the project is TOTAL_SUPPLY = SUPPLY_WHOLE_TOKENS * 10 ** DECIMALS.

What I checked against the three guides:

• Supply math: 10 ** DECIMALS uses a small 8-bit constant as the exponent, but Solidity still computes it in full 256-bit integers. The result is 1e27 tokens in minor units, which matches the requested 1,000,000,000 tokens with 18 decimals. A scratch test confirmed totalSupply(), the deployer's balance and decimals() == 18.
• Overflow in unchecked code: the library skips overflow checks when it adds to or subtracts from balances. Those sums can never exceed the fixed supply of 1e27, which is far below the 2^256 limit, and supply can't grow after the constructor.
• Edge values: sending 1 wei more than a balance reverts, and so does sending 2^256−1. A zero-value transferFrom leaves the allowance unchanged, and a maximum allowance stays unlimited while the full 1e27 moves exactly.
• Totals add up (fuzzed, 256 runs): after any sequence of transfer and transferFrom, including sending to yourself and to the same address twice, the balances still add up to the total supply. Spent allowances also go down by exactly the amount moved.
• Boundary and numerical-gap items: none apply. The contract makes no external calls, has no payable functions, no special-case address branches, no byte decoding, and no division anywhere.

Coverage: all three listed entry points, approve, transfer and transferFrom, are marked holds. There are two more rows for the supply and balance-total rules.

Static analysis: slither reported nothing. aderyn's "large numeric literal" note on line 24 is about how 1_000_000_000 is written, not a defect, so I didn't report it.

Not run: the supplied protected test files import harness files that aren't in this repository, so I couldn't run them. The project's own 34 tests pass. The scratch tests are deleted and the tree is unchanged apart from the findings file.

The review is complete. The findings file holds no defects and a seven-row coverage record.

Result: no defects found in the Access Control, Trust Gap and Asymmetry areas. The token at src/PangeaToken.sol is OpenZeppelin v5.1.0 ERC20 plus constants and a constructor that mints the whole supply once to the deployer. There is no owner, role, modifier, initializer, mint, burn, pause, blocklist, receive or fallback, so no privileged seam exists for any of the three guides' failure modes.

What I verified:

• Permission map. The compiled ABI exposes only the standard ERC-20 surface plus five view constants. Every writer of balances, allowances and supply is reached solely through the three listed entry points or the constructor.
• Vendored library integrity. I read the ERC20 and Context sources in full. They match OpenZeppelin v5.1.0 with no hidden branch or extra writer.
• Entry points. All three rows are marked holds. A stranger or the deployer cannot pull from a holder without an allowance, approve writes only the caller's own row, and transfer and transferFrom move identical amounts with the supply unchanged.
• Static-analysis lead. The aderyn large-literal note is style only. The supply constant evaluates to exactly one billion times ten to the eighteenth.
• Tests. The existing 34 tests pass with the verifier's fuzz seed, and a four-test scratch probe I wrote under test/scratch also passes. Slither and Mythril were not run.

Trust assumptions recorded as notes rather than findings: the deployer receives the whole supply, the remainder key controls ten percent after launch, and unlimited approvals are never decremented. The manifest file is absent from the tree, which the README states is written by a later step, so it is outside this review.

The review is complete and the findings file is written with zero defects and full coverage.

Outcome. I found no defect in the Pangea token. The findings record at .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three listed entry points plus the constructor, two invariants and two periphery targets. Git shows no other change to the tree, and I created nothing under test/scratch/ because no finding needed a proof.

What I checked, by guide.

• Execution Trace: traced approve, transfer and transferFrom from entry to final state through the OpenZeppelin base. Every failure path reverts before any write, debits and credits are exact, and no reachable path passes the zero address into the supply-changing branches of the update function. The constructor is the only mint, for exactly one billion tokens at 18 decimals, to the caller, which is the factory under the launch's CREATE2 deployment.
• Periphery: hashed the five vendored OpenZeppelin files the token depends on against the published 5.1.0 release, and all five match byte for byte. The deploy script reads no environment and is not on the launch path.
• First Principles: the ABI exposes only the ERC-20 surface and five view constants. No receive, fallback, owner, initializer, mint, burn, pause or blocklist exists, so there is no state a privileged hand could reach. The runtime disassembly contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE.

Evidence run. The build and all 34 project tests pass under the verifier's fuzz seed, including the factory-to-distributor-to-claimant and factory-to-requester flows arriving whole. The protected floor test itself could not be run here because it needs the v4-core dependency and launch environment variables, so my floor claims rest on reading it against the token's behaviour rather than on executing it.

Two non-defect notes for the author. The README states chain id 1, an IMD pair, fee 12500, tick spacing 60 and a specific remainder address. Those are launch facts the manifest step owns, so if the job differs the README will be stale, but nothing in the code depends on them. The aderyn large-numeric-literal lead on line 24 is the supply constant, which the tests assert equals one billion times ten to the eighteenth, so it is not a defect.

I added two test files for the Pangea token. forge build succeeds, and forge test passes 56 tests with both the verifier's seed and a random seed. I didn't find any defects, so there is no .imd-findings.json.

What the token is: src/PangeaToken.sol is a plain OpenZeppelin v5.1.0 ERC-20. It adds only constants and a constructor that mints 1,000,000,000 × 10^18 to whoever deploys it. It has no owner, no further minting, no fees, no pause and no burn.

test/PangeaToken.invariant.t.sol runs random call sequences against the token (256 runs × 64 calls), which the brief requires for a contract that holds value.

• How it works: a handler contract makes random calls from five accounts that start with uneven balances, including one holding a single wei. It keeps its own record of what every balance and allowance should be.

• Calls it makes: normal transfers, transfers of a whole balance, transfers to outside addresses and to the token itself, approvals (including unlimited ones) and transferFrom.

• Failure paths: it also tries calls that must fail: sending more than the balance or allowance, sending to the zero address, approving the zero address, and admin-style calls like mint, burn, burnFrom, pause, blacklist, permit and increaseAllowance. Each must revert with the exact expected error and change nothing.

• Checked after every call:

  • the supply never changes;
  • all balances add up to the supply and match the handler's record;
  • all allowances match the handler's record;
  • nothing ever lands on the zero address and the token never holds ETH;
  • name, symbol and decimals never change;
  • none of the calls above did anything unexpected.

  The handler never reverts and logs problems instead, so no run is silently thrown away; the run reports 0 reverts.

• Sanity check: I confirmed with a throwaway test that the handler actually catches problems. When I moved tokens behind its back, it flagged the mismatch.

test/PangeaToken.edges.t.sol covers edge cases the existing suite missed:

• spending your own tokens through transferFrom still needs an allowance;
• a zero-amount transferFrom works without any allowance;
• the zero address is rejected as receiver, owner, approver and sender;
• the whole supply can move through an exact allowance;
• an unlimited allowance still can't exceed the owner's balance;
• setting an allowance to zero revokes it;
• transferFrom emits a Transfer event but no Approval event;
• tokens sent to the token contract are stuck there for good, since it has no rescue function;
• there is no permit or increase/decrease-allowance function, and transfer won't accept ETH.

It also has fuzz tests (1,000 runs each) showing that a failed transfer or transferFrom changes nothing, that approve sets exactly the amount given, and that sending tokens to yourself changes nothing.

I didn't change the earlier contributors' test files or anything outside test/. The two new files are uncommitted in the working tree.

The review is complete and the findings file is written. The result is a clean review with no defects.

Outcome

.imd-findings.json holds an empty findings list and eight coverage rows: the three state-changing entry points, four invariants, and the dependency check. Every entry point is marked holds.

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

• Supply is fixed. _mint is reachable only from the constructor, _update is not overridden, and transfers to the zero address revert, so nothing can mint or burn. The compiled ABI has only the standard ERC-20 surface plus five view constants.
• Conservation. A handler-driven invariant run over transfer, approve and transferFrom kept the sum of balances equal to the total supply and the zero address empty across 6,400 random calls, including deliberate over-balance and over-allowance attempts.
• Launch flows arrive whole. With no fee, tax, reflection, exemption list or hook, the 10% swarm share, the pool share and the remainder split losslessly for any pool share up to 90%. A balance-delta settle probe, the pattern Uniswap v4 uses, credits a seed and a sell back exactly.
• Dependency integrity. The five vendored OpenZeppelin files the token compiles are byte-identical to the published 5.1.0 package, and the source tree contains no non-ASCII characters. This was the one realistic place a defect could hide in a token this thin.
• Deployment. The constructor takes no arguments, makes no external call, and mints to msg.sender, so the factory receives the whole supply as the protected floor requires. Decimals are the default 18.

Trust notes, not defects

• Unlimited approvals are honoured and never decremented, and the standard ERC-20 approve race applies. Both are documented in the README and inherent to the standard.
• Tokens sent to the token contract itself are unrecoverable by design.

Not covered

Nothing in the assigned area was left unreached. Slither and Mythril were not run beyond the verifier's output, which reported only a cosmetic numeric-literal note. The scratch test directory was removed, so the tree carries only the findings file.

Review complete. No defects found, and the findings file is written with an empty list and a full coverage record.

What I checked

• The token itself. src/PangeaToken.sol is a 34-line wrapper over OpenZeppelin ERC20 with a no-argument constructor that mints the whole supply to msg.sender once. There is no owner, mint, burn, pause, blocklist, fee or hook, and the ABI exposes only the standard ERC-20 surface plus five constants.
• Dependency integrity. The five vendored OpenZeppelin files the token compiles against are byte-identical to upstream v5.1.0, so the inherited transfer, approve and transferFrom logic is the audited library code.
• The protected floor, replayed locally. The platform's protected tests need v4-core sources this tree lacks, so I wrote a scratch test replaying their checks: CREATE2 deployment from a contract, the swarm share and requester remainder arriving whole, a pull of the pool share via transferFrom, 22 admin and privileged selectors reverting from both the deployer and a stranger, and a reachable-opcode walk of the runtime finding no DELEGATECALL, CALLCODE or SELFDESTRUCT. All passed. Creation and runtime bytecode are far under the size limits.
• Entry points. All three listed entry points hold, with their revert paths traced and exercised: zero-address receiver or spender, balance short by one wei, allowance exhausted, and the unlimited-allowance case.
• Specialists and tooling. All four specialists and the test writer reported nothing, so there was nothing to reproduce or merge. The one aderyn lead, the large numeric literal, is a compile-time constant that evaluates to exactly 1e27 and is not a defect.
• Manifest. launch.json uses only schema keys, lowercase addresses, strings for uint256 values, an empty constructorArgs matching the no-argument constructor, and a totalSupply equal to what the constructor mints.

The project's own 56 tests also pass with the verifier's fuzz seed, and formatting is clean. The scratch directory is removed and the tree is unchanged apart from the findings file.