Implemented Identity Units (UI): 1 billion tokens, 18 decimals, minted once to the deployer, with fee-free transfers.

Added vendored dependencies, deployment documentation, and success, failure, fuzz, and invariant tests.

Passed forge build, forge test (31 tests), and forge fmt --check, including offline checks with an empty environment.

The protected launch harness requires network infrastructure unavailable locally.

I found no defects in my area (Math Precision, Boundary and Numerical Gaps), so .imd-findings.json holds an empty findings list plus coverage rows.

What I checked: src/IdentityUnits.sol is a plain OpenZeppelin v5.0.2 ERC20 that mints INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 (10^27) once to msg.sender in the constructor. The token code doesn't change any of the inherited ERC20 behaviour.

• Supply math: 10^27 is computed at compile time and is far below 2^256. There is no mint or burn entry point after the constructor, so the supply can't change.
• Unchecked blocks: each one in OZ's _update and _spendAllowance is guarded first:
  • The sender's balance is subtracted only after fromBalance >= value is checked.
  • The recipient's balance can't overflow because it's capped by the total supply.
  • The allowance is reduced only after currentAllowance >= value is checked.
• Edge values:
  • A transfer of 0 works.
  • Sending a full balance works.
  • Sending to yourself works.
  • The zero address reverts as sender, recipient, approver or spender.
  • type(uint256).max works as an unlimited allowance that is never reduced.
• Precision and fees: there are no fees, division or rounding. _update moves exactly value, so the "no fee" rule holds. Decimals stay at the default 18.
• Tool leads: Aderyn flagged large-numeric-literal at line 10. The constant is correct, so at most it's a style point, not a defect. Slither reported nothing.
• Tests: forge test passes all 31 of the repo's tests, including the invariant suite (8,192 calls, 0 reverts).

Coverage: all three entry points are marked holds: approve, transfer and transferFrom. I added rows for two invariants: the fixed supply, and 18 decimals with exact, fee-free transfers.

Limits:

• I did not run the protected launch test. It needs files outside this repo (LaunchLiquidity, PoolInitializationGuard, v4-core) and launch environment variables I don't have.
• I relied on the vendored OZ files being unmodified, as DEPENDENCIES.md says. I read the relevant functions and they match standard v5.0.2, but I didn't check the archive hash.
• I left out the standard ERC-20 approve race. It's outside the math area and not specific to this token.

The permissions audit (access control, trust gap and asymmetry) of src/IdentityUnits.sol found no defects. I wrote .imd-findings.json with {"findings":[]} and a coverage record. I changed no other files.

What I checked:

• Source: the token is a plain OpenZeppelin v5.0.2 ERC20. Its constructor only sets the name and symbol and mints 1_000_000_000 * 10**18 to msg.sender, which is the factory when the factory deploys it. There is no owner or role storage, no access-check modifier, no external mint, burn, pause, blacklist, freeze, seize, initialize or upgrade function, and no receive, fallback or external call.
• Vendored library: I read the vendored ERC20.sol and Context.sol in full. transfer, approve, transferFrom, _update, _spendAllowance and _approve contain nothing beyond the standard upstream code. decimals returns 18 and there is no fee or exemption logic.
• Trust gap and asymmetry: after construction the deployer or factory holds no power that other holders lack. It cannot move tokens without an allowance and cannot freeze anyone. The launch flows (factory to distributor, distributor claims, and pool seed and swaps) move exact amounts, as the protected harness requires.
• Tests: forge test passes, 31 of 31, including the invariant test. I did not run the protected harness: it needs the network's Uniswap v4 launch code and environment variables, which aren't in this repo.

Coverage rows (all holds):

• IdentityUnits.approve(address,uint256): only writes the caller's own allowance.
• IdentityUnits.transfer(address,uint256): only moves the caller's own balance, and the full amount arrives.
• IdentityUnits.transferFrom(address,address,uint256): the allowance is spent before the transfer, and no privileged caller can skip that.
• Invariants: I also added rows for no privileged role after deployment, a supply that cannot grow, and no DELEGATECALL, CALLCODE, SELFDESTRUCT or callbacks.

Not reported as defects:

• Approve race: approve replaces an allowance rather than adding to it, which allows the usual transaction-ordering race. This is standard ERC-20 behaviour and the README documents it.
• Static-analysis leads: aderyn flagged a "large numeric literal" at line 10. It is only a style note and the value is correct (10^27). Slither reported nothing at low impact or above.

Created launch.json matching the accepted constructor, exact supply, requested pair, and verbatim economics.

Validation passed: supplied schema, constructor ABI, forge build, and all 31 tests. Only launch.json is changed outside permitted scratch artifacts.

The findings file is in place and excluded by the harness's own git exclude list, scratch is removed, and the tree is otherwise untouched. Review is complete.

Result: no defects found. The token is a 16-line wrapper over an unmodified OpenZeppelin v5.0.2 ERC20 that mints the whole supply to the constructor caller once and adds nothing else. .imd-findings.json holds an empty findings list and nine coverage rows, all holds.

What I checked against the Execution Trace, Periphery and First Principles guides

• Execution flow of the three entry points. Traced approve, transfer and transferFrom through the inherited internals. Zero-address sentinels revert on every path, including the zero-sender transferFrom that could otherwise look like a mint. Allowance is spent before the balance moves and the whole call reverts atomically if either step fails. The infinite-allowance residual and the approve race are standard ERC-20 behaviour and are documented in the README.
• Deployment and first caller. A CREATE2 deployment from an etched factory address lands all of the supply on the factory. The supply constant computes to exactly 10^27, matching the brief and the manifest string in the README. Decimals report 18.
• Launch flows. Factory to distributor, distributor to claimant, and an approve plus pull by a pool-style address followed by a push back all arrive whole. There is no fee, so no exemption list is needed or present.
• Admin surface. All 22 selectors from the protected floor and the project tests, tried from the factory and a stranger, revert with no state change. No receive or fallback exists. A factory transferFrom against a holder without approval reverts.
• Bytecode. Both creation and runtime code are free of DELEGATECALL, CALLCODE, SELFDESTRUCT and PUSH0. Runtime is well under the EIP-170 limit.
• Periphery. All five vendored OpenZeppelin files hash-match the upstream v5.0.2 tag. No submodules exist. Context resolves msg.sender directly with no forwarder.
• Static-analysis lead. The aderyn large-numeric-literal note is the supply expression and evaluates correctly. Not a defect.

Tooling that ran: offline forge build with no warnings, the project's 31 tests including the invariant suite, forge fmt check, and my scratch harness of five tests. Slither and the Uniswap v4 protected harness could not be run here. The seed and swap through a real PoolManager remain the one floor check I could only reason about rather than execute, and a plain fee-free ERC20 gives the pool manager nothing to trip on.

The review is complete. No defects were found in the Identity Units token, and .imd-findings.json holds an empty findings list with nine coverage rows.

What I audited. The token in src/IdentityUnits.sol is an unmodified OpenZeppelin v5.0.2 ERC20 whose constructor mints the full supply to the caller. I checked it against the Economic Security, Invariant and Flow Gap guides, the x-ray token profile, and the protected launch harness.

What held, and how I verified it:

• Supply and recipient. The constant equals ten to the twenty-seventh power, and the constructor mints it all to the immediate caller, which is the factory under CREATE2. The existing factory test and my scratch probe both confirm the factory holds and forwards the whole supply.
• Conservation invariants. Mint is reachable only from the constructor. There is no burn path, because transfers to the zero address revert and no burn selector exists in the ABI. The fuzz and invariant suites pass with 31 tests.
• Launch flows arrive whole. Every transfer moves exactly the requested value and returns true. The supply is divisible by ten thousand, so the ten percent swarm share and every possible pool share split with no dust. The supply also fits within the signed 128-bit range Uniswap v4 uses for deltas.
• No external dependencies. An opcode scan of the runtime found no call, static call, delegate call, create or self-destruct instructions. There is no receive or fallback, so nothing can be sandwiched, re-entered or starved.
• No privileged surface. The ABI exposes only approve, transfer and transferFrom as state-changing functions. Every admin selector in the protected harness reverts without changing state.
• Dependency integrity. All five vendored OpenZeppelin files diff byte-identical against the upstream v5.0.2 tag, so there is no hidden relayer or exempt path in the context helper.

Leads I ran down and dismissed. The aderyn large-numeric-literal note is style only, and the literal evaluates to the correct supply. The standard ERC-20 approve ordering race is inherent to the specification, is documented in the README, and is not an implementation defect, so it is noted in the coverage row rather than reported.

The scratch test directory was removed after use, and the working tree has no other changes.

Added 15 edge-case and fuzz tests, and expanded invariants to cover rejected calls, allowance rollback, supply conservation, and fee-free transfers.

Offline forge build and forge test pass: 46 tests, including 32,768 invariant calls.

Only test/ files changed. No implementation defects found.

fetch failed

The review is complete. The findings file is valid JSON and no tracked files were changed.

Result: no defects found. The four specialists and the independent tester each reported nothing, and I confirmed that against the code.

What I checked:

• Source. src/IdentityUnits.sol is a 16-line contract inheriting OpenZeppelin ERC20 with an argument-free constructor that mints a constant supply once to msg.sender. There are no owner, mint, burn, pause, blacklist or upgrade functions.
• Vendored library. The five OpenZeppelin files in lib/ hash identically to upstream v5.0.2, so the inherited approve, transfer and transferFrom are the unmodified reference implementations with no fee, exact amounts, and reverts on zero addresses or insufficient balance and allowance.
• Manifest agreement. The constant equals 10^27, which matches launch.json totalSupply, constructorArgs is empty, and decimals returns 18.
• Launch floor. A scratch test deployed the token through a factory-like contract and confirmed the whole supply lands on the deployer, metadata is correct, calls to mint, owner and burn selectors revert, and the runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The scratch directory was removed afterwards.
• Existing suite. All 46 tests pass, including the invariant suite with 32,768 handler calls and zero reverts.
• Static analysis. The single aderyn low on the large numeric literal is a style note. The expression folds to exactly 10^27 and is not a defect.

.imd-findings.json holds an empty findings list and a coverage record of seven rows. The three listed entry points are marked as holding, plus rows for the constructor mint, the no-supply-growth and no-admin-surface invariant, the forbidden-opcode scan, and the aderyn lead.