Approved workflow

Periphery/provenance. docs/dependencies.json records per-file SHA-256 hashes for the vendored forge-std v1.9.7 tree, and docs/REVIEW.md line 35 states 'All 36 vendored dependency files matched their recorded SHA-256 hashes.' Recomputing the hashes shows 7 of the 30 forge-std files do NOT match: src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IERC7540.sol, src/interfaces/IMulticall3.sol.

I downloaded the upstream v1.9.7 tarball (sha256 45157353ab49... matches archive_sha256 in dependencies.json) and compared: the recorded hashes are the genuine upstream hashes, and the vendored copies differ from upstream only by whitespace/line wrapping (identical after stripping all whitespace), consistent with a formatter having been run on lib/ despite fmt.ignore = ["lib/**"]. All 6 OpenZeppelin v5.1.0 files are byte-identical to upstream and match their recorded hashes.

Impact: these are test-only dependencies (never part of deployed bytecode) and the semantic content is unchanged, so this is not an exploit. But the documented provenance check fails as shipped, the review handoff's verification claim is inaccurate, and a reviewer relying on the hash list cannot distinguish this benign reformat from a tampered Vm.sol/StdAssertions.sol without re-fetching upstream (which the offline verifier cannot do).

Fix: re-vendor the 7 files byte-for-byte from the v1.9.7 archive so they match the recorded hashes (preferred, preserves provenance), or regenerate the hash list from the tree and correct the REVIEW.md sentence; either way add the hash check to the documented local validation commands so the claim is reproducible.

First-principles / cross-function state. withdraw() only sets _entries[id].withdrawn = true and never clears entryIdOf[msg.sender], while register() rejects any caller whose entryIdOf is nonzero. The combined effect is that an address which withdraws while registration is still open can never hold an entry again, and update() on the withdrawn entry also reverts (EntryAlreadyWithdrawn).

The brief says 'anyone registers one entry per address ... an entrant may update their own entry until the deadline and withdraw it'; a withdrawn address holds no entry, so a fresh registration before the deadline would still satisfy one-entry-per-address, and nothing in the brief asks for withdrawal to be a lifetime ban. withdraw() takes no argument and no confirmation, so an accidental or premature call (e.g. intending to withdraw and re-enter under a different project) is unrecoverable from an EOA that the entrant must also control on mainnet for prize payout; their only recourse is a different wallet, which conflicts with the EOA guidance.

The README documents this as intentional, so this is an interpretation call for the author/judge rather than a code slip. If the permanent-ban semantics are kept, no code change is needed.

If re-entry should be allowed before the deadline, minimal fix: in register(), treat a withdrawn prior entry as free (uint256 prior = entryIdOf[msg.sender]; if (prior != 0 && !_entries[prior].withdrawn) revert AlreadyRegistered();) and assign a new ID so enumeration stays append-only; or alternatively let update() clear the withdrawn flag before the deadline.

Execution-trace / wrong-state execution. register and update carry whileOpen, withdraw does not, so the registry's state is mutable forever. The brief's sentence 'registration and updates close exactly 14 days after deployment' names only those two operations, so the builder's reading is defensible and the README documents it (judges must snapshot at the deadline and the prize operator must re-check withdrawals before payout).

The consequence is operational rather than a code defect: the on-chain entry set is not frozen at the deadline, the judging snapshot and the withdrawn flag can disagree, and a winner who withdraws between the snapshot and payout forfeits a mainnet prize with no on-chain record of the judging snapshot. If the intent is 'entries frozen at the deadline', add whileOpen to withdraw(); otherwise no change is needed and the off-chain snapshot rule in docs/ABI.md must be followed.

Reported so the judge can settle the interpretation; not a blocking defect.

docs/dependencies.json is the offline provenance record for the vendored dependencies and README.md (line 56) and docs/REVIEW.md (line 35: 'All 36 vendored dependency files matched their recorded SHA-256 hashes') present it as verified.

Recomputing sha256 over the committed files shows 7 of the 29 forge-std files do not match their recorded hash: src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IERC7540.sol, src/interfaces/IMulticall3.sol.

I downloaded the pinned archive named in the record (archive sha256 45157353ab49... matches) and confirmed the recorded hashes are the genuine upstream v1.9.7 hashes; the committed copies differ from upstream only by whitespace/line-wrapping (token streams identical after stripping whitespace, e.g. IMulticall3.aggregate was re-wrapped to one 120-column line), consistent with a formatter having been run over lib/ despite the fmt ignore.

All 6 OpenZeppelin files (the only production dependency, including ERC20.sol used by LaunchToken) are byte-identical to upstream v5.1.0, so the launch token bytecode is unaffected. Impact is limited to the integrity of the provenance record and a false statement in the review handoff: anyone performing the offline hash check the README directs them to will see it fail, and the record can no longer distinguish a benign reformat from a tampered test harness.

Fix: either restore the 7 files to their upstream bytes (re-extract from the pinned archive) or regenerate the hashes from the committed files, and correct the REVIEW.md claim. Outside my assigned economic area; reported because it is concrete and the handoff asserts the opposite.

Flow-gap note (execution x first principles), not a code bug: the implementation is internally consistent and documented in README.md, docs/ABI.md and docs/REVIEW.md. The brief says entrants 'may update their own entry until the deadline and withdraw it' and that 'registration and updates close exactly 14 days after deployment'. The builder read the deadline as applying only to register/update, so withdraw() carries no whileOpen modifier and succeeds at any time.

Consequence for the economics of judging: the brief has the 7-agent panel score 'every entry' at the deadline, but the on-chain state is not frozen at that moment; an entrant can flip their entry to withdrawn after judging begins or after results are published, and the live state the website/prize service reads will differ from the panel's snapshot.

The only victim is the withdrawer (self-harm), so this has no severity; it is flagged because the alternative reading of the brief (withdraw also closes at the deadline) is equally plausible and would change the contract, and the off-chain rule for a top-three winner who withdraws before payout (forfeit vs re-rank) is not stated in README.md.

The requester should confirm the intended reading; if withdrawals should close at the deadline, add the whileOpen modifier to withdraw() and update the three documents and testWithdrawalAllowedAtAndAfterDeadline.

Flow-gap note (execution x first principles), documented in README.md ('never permits another registration from the address'), not a code bug. The brief requires 'one entry per address' and allows an entrant to 'withdraw it'. The implementation keeps entryIdOf permanently assigned after withdrawal and register() rejects any address whose id is nonzero, so the flow register -> withdraw -> register reverts with AlreadyRegistered while the window is still open.

This is stricter than 'one active entry per address': an entrant who withdraws by mistake, or withdraws intending to re-enter with a different project, is locked out of that address for the whole hackathon and must enter from a different wallet (which, per the prize rule, must also be one they control on mainnet). No third party loses anything, so no severity.

The requester should confirm this is the intended meaning of 'one entry per address'; the alternative (allow a withdrawn entrant to register a fresh id, keeping the old id in history) is a small change to register() and the AlreadyRegistered check plus the invariant model in test/RegistryInvariant.t.sol.

Merged from audit_flow (id 1d9d158a...) and audit_economics (id dd6c58cb...), same root cause. docs/dependencies.json is the offline provenance record README.md (line 56) points reviewers to, and docs/REVIEW.md line 35 states 'All 36 vendored dependency files matched their recorded SHA-256 hashes.'

Recomputing the hashes over the committed tree shows 7 of the 30 forge-std entries do not match: src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IERC7540.sol, src/interfaces/IMulticall3.sol.

I downloaded the pinned upstream v1.9.7 archive (its sha256 45157353ab49... equals archive_sha256 in the record) and compared: the recorded hashes are the genuine upstream hashes, and after stripping all whitespace every one of the 7 vendored files is token-identical to upstream (e.g. upstream IMulticall3.aggregate is wrapped over 4 lines, the vendored copy is one 120-column line), so a formatter was run over lib/ despite fmt.ignore = ["lib/**"].

All 6 OpenZeppelin v5.1.0 files, the only production dependency, match their recorded hashes byte for byte, so LaunchToken bytecode is unaffected and nothing deployed is touched. Impact is limited to provenance: the documented hash check fails as shipped, the handoff's claim is false, and an offline reviewer cannot distinguish this benign reformat from a tampered test harness (Vm.sol/StdAssertions.sol) without re-fetching upstream, which the offline verifier cannot do.

Fix: re-extract the 7 files byte-for-byte from the pinned v1.9.7 archive so they match the record (preferred), or regenerate the hash list from the committed files; in either case correct the REVIEW.md sentence and add the hash check to the documented local validation commands.

Merged from audit_flow (id 0cc8e3c0...) and audit_economics (id e614c2c5...), same root cause. withdraw() at line 115 only sets _entries[id].withdrawn = true and never clears entryIdOf[msg.sender], while register() at line 84 rejects any caller whose entryIdOf is nonzero and update() reverts EntryAlreadyWithdrawn on a withdrawn entry. Combined, an address that withdraws while registration is still open can never hold an active entry again.

The brief says 'anyone registers one entry per address ... an entrant may update their own entry until the deadline and withdraw it'; a withdrawn address holds no live entry, so a fresh registration before the deadline would still satisfy one entry per address, and nothing in the brief asks for withdrawal to be a lifetime ban. withdraw() takes no argument and no confirmation, so an accidental or premature call is unrecoverable from the wallet the entrant must also control on mainnet for prize payout; the only recourse is a second wallet, which conflicts with the EOA guidance.

README.md line 27 and docs/ABI.md document the permanent semantics and testWithdrawalIsPermanent asserts them, so this is an interpretation the author chose rather than a slip; no third party loses anything. If the permanent-ban reading is kept, no code change is needed and the requester should confirm it.

If re-entry before the deadline is intended, minimal fix in register(): uint256 prior = entryIdOf[msg.sender]; if (prior != 0 && !_entries[prior].withdrawn) revert AlreadyRegistered(); and assign a new ID so enumeration stays append-only, then update the invariant model in test/RegistryInvariant.t.sol, testWithdrawalIsPermanent and the three documents.

Merged from audit_flow (id 559da7b6...) and audit_economics (id 0249122e...), same root cause. register() and update() carry whileOpen; withdraw() does not, so an entrant can flip their entry to withdrawn at any time after the deadline, including after the 7-agent panel has scored or results are published.

The brief's sentence 'registration and updates close exactly 14 days after deployment' names only those two operations, so the builder's reading is defensible, and README.md line 27, docs/ABI.md and docs/REVIEW.md all document that judges must use the deadline snapshot and the prize operator must re-check withdrawals before payout.

The consequence is operational: the on-chain entry set is not frozen at the deadline, the judging snapshot and the live withdrawn flag can disagree, and a winner who withdraws between snapshot and payout forfeits a mainnet prize under the documented rule. Only the withdrawer is affected, so no severity.

Reported so the requester can settle the interpretation: if 'entries frozen at the deadline' is intended, add whileOpen to withdraw() and update testWithdrawalAllowedAtAndAfterDeadline and the three documents; otherwise no change is needed.