Committed on main as one commit, working tree clean. The deliverable is complete and verified.

What was built

• src/HiveDeskToken.sol: a plain ERC-20 on OpenZeppelin v5.4.0 named HiveDesk, symbol HVD, 18 decimals. The constructor mints the full one billion supply to msg.sender once. There is no owner, mint, pause, blocklist, burn-from, proxy, fallback or external library call, so nothing can grow the supply or touch a holder's balance after launch.
• test/HiveDeskToken.t.sol: 24 tests covering metadata, the single constructor mint event, independence of deployments, every common mint and admin selector tried from both a stranger and the deployer, privileged freeze and seize calls doing nothing, launch flows arriving whole, exact transfers, allowance semantics, reverts on insufficient balance, allowance and zero addresses, rejection of plain ETH, a runtime opcode scan, and three fuzz tests.
• script/DeployHiveDeskToken.s.sol: a review-only rehearsal script whose deploy() the tests call directly. It reads nothing from the environment.
• README.md: assumptions, manifest-ready deployment parameters, operational responsibilities, and the security checklist applied.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables ffi and filesystem access. forge-std v1.11.0 and the five OpenZeppelin files the token needs are vendored under lib/ as ordinary files with no git metadata.

Verification

• Clean build with an empty environment and --offline succeeded.
• All tests pass in parallel with the verifier's fuzz seed, and forge fmt --check is clean.
• The built artifact has no link references and no metadata CBOR, so the launch can hash and deploy it as built.
• A scratch harness mirroring the protected floor, with CREATE2 deployment from an etched factory address and supply checks after the constructor, passed. The actual protected tests need the verifier's v4-core tree and environment, so they were not run here.
• Slither and Mythril are not on this machine and did not run.

Open items for the launch, not for me

• The manifest step writes launch.json with the values in the README's deployment table. I did not write one.
• Explorer verification after deployment belongs to the IdentityMD deployer.
• No owner-settable values exist, so there is nothing to configure after launch.

I found no defects in the HiveDesk (HVD) token's permissions. .imd-findings.json has an empty findings list and a coverage row marked "holds" for each of the three entry points.

What the code is: src/HiveDeskToken.sol is OpenZeppelin's standard ERC20 (v5.4.0) plus four constants and a constructor. The constructor mints 1,000,000,000 × 10^18 to msg.sender once, through _mint at line 32. The compiled interface has only the standard ERC20 functions and the four constant getters. There is no owner, role, pause, blocklist, burnFrom, proxy, receive or fallback.

What I checked:

• Hidden changes in the library: I compared all five vendored OpenZeppelin files in lib/ against upstream v5.4.0. They are byte-identical, so no permission logic is hidden there.
• Access Control guide: nothing in the contract needs a guard, so there is nothing to bypass or escalate, and no initialize() to call first. The only mint is in the constructor. Neither the deployer nor anyone else can move or freeze a holder's balance without that holder's approval.
• Asymmetry guide:
  • transfer and transferFrom take the same internal path. The only difference is that transferFrom first deducts the allowance.
  • Neither has a fee or exemption branch, so every launch flow (factory to distributor, claims, the pool seed, swaps) moves exactly the amount requested.
  • An unlimited allowance is not reduced on spend. That is standard OpenZeppelin behaviour and the README documents it.
• Trust Gap guide: with no privileged actor and no fee or pricing formula, none of its combinations apply.
• Tests:
  • forge build succeeds and the existing suite passes, 24 of 24.
  • I also ran a temporary fuzz test (256 runs each), then deleted it:
    • transfer and transferFrom leave identical balances and the correct allowance.
    • No address other than the holder, the deployer included, can move the holder's tokens without approval.
    • approve to the zero address reverts.
  • All three passed.

Static-analysis leads: Slither reported nothing. Aderyn's one note, a large number at src/HiveDeskToken.sol:25, is the supply constant 1_000_000_000. That is a style note, not a defect.

Not covered: I did not run the protected launch tests themselves. They need the launch environment settings and v4-core files that are not in this tree. I only read them for what they require. I did not modify any files.

Done. launch.json is written and is the only change in the working tree.

What the manifest says

• Kind is custom_token. The token is HiveDeskToken, name HiveDesk, symbol HVD, 18 decimals, with an empty constructorArgs list. The compiled ABI confirms the constructor takes no parameters.
• totalSupply is the exact figure the constructor mints to msg.sender, one billion tokens in minor units.
• contracts is empty. The accepted tree has only the token; the deploy script under script/ is a local rehearsal and not a launch contract, which the notes state.
• pool and economics are copied exactly as the launch gives them: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object verbatim.
• notes is one string of about 1300 characters describing only the token that is present.

Checks run

• forge build compiles cleanly.
• forge test with the verifier's fuzz seed: 24 passed, 0 failed.
• A scratch JSON check confirmed the manifest has only schema keys, lowercase addresses, string uint256 fields, numeric fee, tickSpacing and decimals, and a contract name under 32 characters.
• git status shows launch.json as the sole new file. No configuration, lib, or test files were touched.

Review complete. The findings file is written and the working tree is otherwise untouched.

Result: no defects found. .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What was reviewed

• src/HiveDeskToken.sol is a 34-line subclass of OpenZeppelin ERC20 v5.4.0 that adds four constants and a constructor minting 1e27 minor units to msg.sender. It overrides nothing.
• Execution Trace guide: traced transfer, approve and transferFrom through _transfer, _update, _approve and _spendAllowance. Zero-address sentinels revert, the balance check precedes the write, the unchecked arithmetic is bounded by total supply, and there are no external calls, so no stale reads, partial updates or reentrancy paths exist. The only allowance residual is the documented infinite allowance.
• Periphery guide: read every vendored base file line by line. ERC20, Context, IERC20, IERC20Metadata and the ERC-6093 errors match upstream logic. _msgSender returns msg.sender. The compiled ABI exposes only the standard ERC-20 surface plus four view constants, with no immutables, link references or forbidden opcodes.
• First Principles guide: the constructor's assumption that msg.sender is the factory was confirmed by deploying via CREATE2 from a factory stand-in. The supply constant fits in uint256. No path exists that grows supply, moves or freezes a holder, or taxes a launch flow.

Checks run

• forge build and the project's 24 tests pass, including fuzz tests.
• A scratch Foundry test exercised CREATE2 deployment, transfer to the token's own address, self-transfer, exact and over-spent allowances, and transferFrom from the zero address. All behaved as standard ERC-20. The scratch file was removed afterwards.
• Both static-analysis leads were reviewed. Slither reported nothing. Aderyn's large-numeric-literal note on line 25 is the one-billion constant, which is correct and tested against decimals().

Trust notes, not defects: tokens sent to the token's own address or to the zero-address-adjacent unrecoverable addresses are lost, as with any plain ERC-20, and the README already states this. There is no owner, so there are no privileged powers to document.

The review is complete. The findings file at the repository root holds an empty findings list and a seven-row coverage record, and no project file was changed.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas. The token at src/HiveDeskToken.sol adds only two constants and a constructor to OpenZeppelin's ERC20, so all of its arithmetic lives in the vendored library. I confirmed that library is the real one: all five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag.

What I checked against the guides:

• Math Precision. There is no division, no multiplication after division, no downcast, no shift and no scale conversion anywhere on the token's code path. The supply constant is a compile-time product that evaluates to exactly 10^27 and equals one billion times ten to the power of the reported decimals. The unchecked blocks in the library's balance update are safe because the balance check precedes the subtraction and the sum of balances is fixed at the supply.
• Boundary. The token has no external calls, no payable function, no sentinel-address branch, no bytes decoding and no receive or fallback. The zero-address guards on sender, receiver and spender were exercised. Inputs of 0, 1 wei, full balance, balance plus one and the maximum uint256 behaved as ERC-20 requires on all three entry points, including self-transfers at full balance and an allowance of max minus one being decremented while max is treated as infinite.
• Numerical Gap. The invariant that balances sum to the total supply held exactly across a 512-run fuzz of 64-step random transfer and transferFrom sequences over nine accounts. The launch shares of ten percent and eighty percent are exact multiples of the supply with no rounding, and with no tax or exemption list every launch flow moves exactly its stated amount.

The one static-analysis lead, Aderyn's large numeric literal note on line 25, is a style remark about a literal that is already underscore-separated and is not a defect. The existing 24-test suite passes and the sources pass the formatter check.

All three ABI entry points are recorded as holding, with four additional rows for the invariants I verified. My scratch tests under test/scratch were removed after they passed, since no finding needed a proof file. Nothing in my area was left unreached.

The review is complete. The findings file is valid JSON with one finding and ten coverage rows, and nothing under src, lib or configuration was changed.

Outcome: no defect in the assigned area. HiveDeskToken is a bare OpenZeppelin ERC20 v5.4.0 with a single constructor mint of 1e27 units to msg.sender. I checked it against the Economic Security, Invariant and Flow Gap guides and found nothing that loses funds, misdirects a launch flow, or breaks a guarantee.

What I verified

• Vendored library is genuine. All five OpenZeppelin files under lib hash byte for byte to the upstream v5.4.0 tag, so the inherited approve, transfer and transferFrom are the audited originals.
• Conservation holds. A stateful fuzz over the three entry points ran 256 sequences and 128,000 calls. The sum of balances stayed equal to totalSupply, and totalSupply stayed at one billion tokens throughout.
• Launch flows arrive whole. There is no fee, burn, hook, exemption list or external call. A PoolManager-style balance-delta settle equals the amount sent, and the 10/80/10 split leaves the factory at exactly zero.
• Supply cannot grow. The compiled ABI has exactly three state-changing functions. There is no mint, owner, initializer, receive, fallback, delegatecall or selfdestruct.
• Metadata matches the brief. Name, symbol, 18 decimals and the supply constant agree with the README's manifest values, and the contract identifier is 13 characters.

The one recorded item is informational: the standard ERC-20 approve race, where a spender front-running an allowance reduction from 100 to 50 can take 150. It is inherent to the plain ERC-20 the brief asks for and needs no code change. I included it with a concrete reproduction so the judge can see the only economic lever this token exposes and discard it if they prefer.

Not reached: launch.json does not exist yet. The README says the manifest step writes it after acceptance, which the reference permits for an early review, so its row is marked unreached rather than failing.

The scratch tests live in test/scratch/EconomicsReview.t.sol, which is gitignored and not part of the submission.

Added failure-path, boundary, and fuzz tests plus four-actor stateful invariants. Only test/ changed.

Validation passed with the supplied seed:

• forge build
• forge test: 45 passing tests
• 32,768 random invariant calls, no unexpected reverts

No implementation defects found.

The review is complete and the findings file is written and valid.

Outcome: the HiveDesk token has no defects. The one specialist finding reproduces but is standard ERC-20 behaviour, so it is kept at info as a holder trust assumption, not as a defect that reopens the author's work.

What I verified against the code

• The token is a parameterless OpenZeppelin ERC20 that mints the full supply once to msg.sender. The vendored OpenZeppelin files hash identically to upstream v5.4.0, fetched from GitHub for comparison.
• The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE opcodes. Creation and runtime sizes are far under the deployment limits, and the constructor needs nothing the factory does not give it.
• The ABI exposes only approve, transfer and transferFrom as state-changing entry points. No owner, mint, burn, pause or blocklist path exists.
• The manifest uses only schema keys, lowercase addresses, an empty constructorArgs list matching the constructor, and a totalSupply equal to what the constructor mints.
• The project's own suite passes, including a 32,768-call stateful invariant run. My scratch test under test/scratch confirms metadata, exact transfer amounts, revert paths, infinite allowance and the approve race.

Specialist findings settled

• Economics, info, approve overwrite race: reproduced in test/scratch/JudgeReview.t.sol with the exact sequence the specialist gave. Kept at info with the reproduction, since the standard specifies this behaviour and the brief asks for a plain token.
• Permissions, flow, math and the independent tester reported nothing, so there were no duplicates to merge.

Coverage record: all three entry points answered, two hold and approve carries the info finding, plus three invariant rows covering fixed supply, forbidden opcodes and the manifest.