audit/protofire/ holds exactly one report:
audit/protofire/st0x.deploy.v0.1.1.may-2026.pdf
Two more are cited across the tree and neither is in the repo:
st0x.deploy 5.0, July 2026 — where H01 was reported. Cited at test/src/concrete/StoxReceiptVault.rawTotalSupply.t.sol:11 ("Regression guards for Protofire H01"), CHANGELOG.md:20, and src/lib/LibERC20Storage.sol:115.st0x.deploy 6.0, Aug 2026 — the report covering commit 4f126183 / tag sol-v0.1.30. Cited at script/DeployProdV4_0_1_30.sol:25 and test/src/lib/LibProdDeployV4.t.sol:561.
Why the 6.0 one matters now
PR #314 froze src/generated/0_1_30/ and its whole justification is that the bytecode is the audited artifact: "The tag's commit 4f126183 is the exact commit Protofire's st0x.deploy 6.0 report (Aug 2026) reviews — all issues marked fixed." Everything downstream in the orchestrator stack rests on that.
Nothing in the repo can check it. An adversarial audit of #314 established that every assertion over src/generated/0_1_30/ is self-referential: all four constants in a pointers file derive from CREATION_CODE, so any internally coherent blob passes all twelve new assertions, and git-clean only ever regenerates candidate/. The single external anchor for "this is the audited bytecode" is prose in three comments pointing at a document that is not here.
The tag resolving to 4f126183 is verifiable and was verified. That Protofire reviewed that commit, and marked all issues fixed, is not.
This is a recurrence rather than a new gap — test/src/concrete/upgrade/V3UpgradeShadowFork.t.sol:230 still carries "The v0.1.1 audit report is not in-repo at the time of writing", written before that PDF landed. Same shape, now open again for two reports.
Ask
Commit both PDFs beside the existing one, named on the same convention:
audit/protofire/st0x.deploy.v5.0.july-2026.pdf
audit/protofire/st0x.deploy.v6.0.aug-2026.pdf
Attach them to this issue if that is easier and they can be committed from here.
Worth doing at the same time, since it is the cheap half: have the 6.0 report's reviewed commit recorded somewhere a test can read, so the "audited artifact" claim has an in-repo anchor rather than living only in comment prose.
audit/protofire/holds exactly one report:Two more are cited across the tree and neither is in the repo:
st0x.deploy 5.0, July 2026 — where H01 was reported. Cited attest/src/concrete/StoxReceiptVault.rawTotalSupply.t.sol:11("Regression guards for Protofire H01"),CHANGELOG.md:20, andsrc/lib/LibERC20Storage.sol:115.st0x.deploy 6.0, Aug 2026 — the report covering commit4f126183/ tagsol-v0.1.30. Cited atscript/DeployProdV4_0_1_30.sol:25andtest/src/lib/LibProdDeployV4.t.sol:561.Why the 6.0 one matters now
PR #314 froze
src/generated/0_1_30/and its whole justification is that the bytecode is the audited artifact: "The tag's commit4f126183is the exact commit Protofire's st0x.deploy 6.0 report (Aug 2026) reviews — all issues marked fixed." Everything downstream in the orchestrator stack rests on that.Nothing in the repo can check it. An adversarial audit of #314 established that every assertion over
src/generated/0_1_30/is self-referential: all four constants in a pointers file derive fromCREATION_CODE, so any internally coherent blob passes all twelve new assertions, andgit-cleanonly ever regeneratescandidate/. The single external anchor for "this is the audited bytecode" is prose in three comments pointing at a document that is not here.The tag resolving to
4f126183is verifiable and was verified. That Protofire reviewed that commit, and marked all issues fixed, is not.This is a recurrence rather than a new gap —
test/src/concrete/upgrade/V3UpgradeShadowFork.t.sol:230still carries "The v0.1.1 audit report is not in-repo at the time of writing", written before that PDF landed. Same shape, now open again for two reports.Ask
Commit both PDFs beside the existing one, named on the same convention:
Attach them to this issue if that is easier and they can be committed from here.
Worth doing at the same time, since it is the cheap half: have the 6.0 report's reviewed commit recorded somewhere a test can read, so the "audited artifact" claim has an in-repo anchor rather than living only in comment prose.