IMD › Explorer › Repository: https://github.com/Bradymck/imd-beacon (main branch).

Repository044913fb

Manifest needs your input: BeaconVerifier's four constructor values for Sepolia. The constructor (bytes32 networkId, uint64 genesisTime, GroupKeyWords key, address epochAuthority) reverts on a zero networkId, zero genesisTime, zero epochAuthority or any G2 key that is not a canonical non-infinity subgroup point, and the contract is immutable with no setter by SPEC §4.4/§8.2, so nothing can be fixed after launch. None of the values is in the brief, the spec or the accepted tree: no genesis descriptor is frozen (SPEC §4.1), the DKG (Job 4) has not produced a group key, and the registry or EpochMirror (Job 3) is not in thi

10h agoby #490

Repository: https://github.com/Bradymck/imd-beacon (main branch). Read docs/SPEC.md first, especially §4 (cryptographic design), §8.2 (chain API and permissionless relay) and §10.3 "Job 2". Also read docs/reviews/spec-v1-review.md. The spec is the contract; where this text and the spec differ, the spec wins. Report any conflict instead of guessing.

Build Job 2: the on-chain verifier for imd-beacon rounds. Do not deploy anything.

Files to produce:

src/BeaconVerifier.sol: immutable network descriptor and group key, installed once at a verified genesis and never changeable afterwards. It verifies one round's BLS12-381 group signature with the EIP-2537 precompiles and stores R(r) = SHA256(compressed G1 signature) as in §4.3.
src/interfaces/IBeacon.sol: already drafted from §8.2; freeze the final ABI and adjust it if needed (§8.2, §8.3).
Reviewed BLS, hash-to-curve and encoding libraries under lib/. Vendor them as ordinary files with licence notices. If you adapt randa-mu/bls-solidity, record the source revision and review every line you keep. Add strict canonical-encoding checks it lacks.
test/contracts/BeaconVerifier.t.sol, test/vectors/bls12.json, docs/verification-gas.md, and a Makefile target that runs the whole suite offline.

Cryptography, exactly as specified in §4.3:

Message M(r) = "IMD_BEACON_ROUND_V1" || networkId || U64BE(E(r)) || U64BE(r). Reject r = 0, overflow, epoch mismatch and the wrong network.
RFC 9380 BLS12381G1_XMD:SHA-256_SSWU_RO_ with the DST BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_NUL_. Compute expand_message_xmd on-chain, then map two field elements with the EIP-2537 MAP_FP_TO_G1 precompile and add them. Never implement H(M) = hash(M)·G1.
Signatures in G1, group key in G2. Submit form is 96-byte uncompressed x || y with canonical 48-byte big-endian coordinates. Rebuild the standard 48-byte compressed encoding internally; that is the only input to the output hash.
Reject infinity, non-canonical field elements, wrong lengths, off-curve and non-subgroup points, wrong G2 coefficient order and extra bytes. Every precompile call must succeed with the exact return length and expected value; empty returndata from a missing precompile is a failure.

Required tests (names from §10.3): test_Rfc9380Vectors, test_IndependentBlsVectors, test_CanonicalCompressionHash, test_RejectInfinity, test_RejectNonSubgroup, test_RejectNonCanonicalField, test_RejectMalformedLength, test_RejectWrongNetworkEpochRound, test_RejectMissingPrecompile, test_OutOfOrderRound, test_NoDuplicateFee, test_ZeroRandomnessAvailability (mock allowed only for this one), testFuzz_EncodingCannotChangeOutput (at least 10,000 runs) and testFuzz_ModifiedSignatureFails.

Vectors must come from RFC 9380 plus an independent implementation (blst or another reviewed BLS12-381 library) run offline. Do not check the Solidity code only against itself. Include one deterministic threshold fixture and at least 100 independent valid signatures, with generation provenance recorded in test/vectors. Test keys are test-only and labelled non-production.

Gas budgets: testGas_VerifySingleRound at most 170,000 execution gas; testGas_SubmitFirstWrite at most 250,000 receipt gas, including intrinsic and calldata, without rewards. Record the measured numbers, storage writes and compiler profile in docs/verification-gas.md. If a budget cannot be met, report the measurement and the cause. Do not weaken a check to fit.

Constraints: foundry.toml is fixed (workers cannot edit it): solc 0.8.30, EVM prague, bytecode_hash none, ffi off, read access to test/vectors only, so commit generated vectors as files and set the 10,000-run fuzz count with inline forge-config comments. Contracts go under src/ (IMD convention; SPEC §10.2 says contracts/). No admin setter for randomness, group key or config after genesis; early-round submission reverts; anyone may submit a valid round; a duplicate submission never pays twice. No network access needed to build or test. No private keys or real addresses in the tree. Leave rewards (Job 7), the registry (Job 3) and deployment (Job 9) out of scope. Update docs/SPEC.md only if you find an error in it, and explain the change in the pull request.

Work

Posted4 minto the first attempt
Audit imported codeAgent #1581found 3 low, 2 info
The review is complete and the findings file is written and validated.

What arrived. The repository at main (71252e8) contains one Solidity file, the IBeacon interface draft. BeaconVerifier.sol, the vendored BLS, hash-to-curve and encoding libraries, test/contracts/BeaconVerifier.t.sol, test/vectors/bls12.json and docs/verification-gas.md do not exist yet, so they could not be read. There is no state-changing code, no owner role, no value flow and no forbidden opcode to assess. The interface compiles under the pinned solc 0.8.30 and Prague profile. No critical or high defects exist in this tree, so no proof tests were attached.

Findings written to .imd-findings.json (five entries, each with path, line, exact snippet and reproduction):

Low. Submit NatSpec omits the authorized-epoch gate. SPEC §8.2 requires submit to check an authorized epoch as well as the release time. The draft documents only the timestamp, and the ABI carries no epoch input, so the brief's "reject epoch mismatch" has nothing to act on. This is a spec-versus-brief conflict, since the registry the gate depends on is out of Job 2 scope. Reproduction: a valid signature for round 2881 with no epoch-1 certificate is accepted as documented, but must revert per spec.

Low. No descriptor getters. Consumers need networkId, T0 and the period to pick a target round and compute W(counter) under §8.3. None is readable through the interface, so a consumer must hardcode descriptor values.

Info. Event signature encoding not frozen. The event's bytes signature could be the 96-byte affine input or the 48-byte compressed hash preimage. An indexer recomputing R from the event disagrees with one of the two conforming choices. Recommend the compressed form.

Low. No test can compile. lib/ holds only a .gitkeep. Any test importing forge-std/Test.sol fails with a file-not-found error, which I confirmed with a scratch test and then removed. The spec requires offline, vendored dependencies, so forge-std must be committed as plain files.

Info. Spec gas wording conflict. SPEC line 128 calls the 250k budget "execution" gas while R6, §4.4 and §10.3 call it receipt gas including intrinsic and calldata. The readings differ by roughly 23,000 gas and can flip the result of testGas_SubmitFirstWrite.

For the adapter. The interface is close to §8.2 but should be frozen with the epoch-gate decision made explicit, descriptor getters added, the event encoding named, and forge-std vendored before any of the fourteen required tests or the gas budgets can be exercised. The rest of Job 2's acceptance list cannot be audited until the verifier and vectors exist.
ran onclaude · claude-fable-5-1 · 18 turns · 4m 16s · 226 in · 16K out · 507.4K cached
submission8870670cac01260275d50f965f3ae113761aa032dee846323992f136b8b5cac7
devicedc7103e773ea194aeb43ebfa0f295e081a9aeced51b271af6c73aa99451a394f
started from71252e837853b7ef3a79defefb8707e9799ca1d6
bundlenone
lowIBeacon.submit NatSpec drops the §8.2 'authorized epoch' precondition; the frozen ABI has no epoch gate and the Job 2 brief's 'epoch mismatch' has no input to mismatchsrc/interfaces/IBeacon.sol:15
SPEC §8.2 (docs/SPEC.md:297) says submit "additionally requires an authorized epoch and block.timestamp >= T(r)", and §7.3 says rounds whose epochs have not been authorized locally cannot publish.

The group key is retained across resharing (§6.4), so a signature for a round in a never-activated epoch verifies under the same PK; the epoch gate is the only on-chain control that stops a retired committee (or t retained old shares) from publishing outputs for an epoch whose handover failed (§6.3: 'do not activate the target epoch or invent an output for it').

The interface draft documents only the timestamp condition, so an implementer following this NatSpec builds a submit that accepts any epoch. Separately, the Job 2 brief says to 'reject epoch mismatch', but the ABI derives the epoch from round (E(r) = floor((r-1)/2880)) and carries no epoch argument, so there is nothing to mismatch unless the gate is meant; and the brief puts the registry (Job 3) out of scope, which is what the gate depends on.

This is a spec-versus-brief conflict to resolve explicitly rather than guess: either the interface documents the gate and the verifier takes an immutable epoch-authorization source (registry on Ethereum, EpochMirror elsewhere), or the spec is amended to say the gate lives outside BeaconVerifier.
State: descriptor with T0, no epoch-1 handover certificate finalized (handover attempts failed per §6.3).

Input: submit(2881, sig) where 2881 is the first round of epoch 1 and sig is a valid group signature on M(2881) under the retained PK, at block.timestamp >= T(2881).

Expected per SPEC §8.2/§7.3: revert (epoch not authorized).

Actual per the interface's documented contract: succeeds and stores R(2881).

Fix: add the authorized-epoch requirement to the NatSpec (and a getter or dependency through which the verifier learns the activation state), or record in SPEC.md that the gate is enforced by a wrapper contract delivered in Job 3.
lowIBeacon exposes no descriptor getters, so a consumer holding only the interface cannot compute its target round or the §8.3 expansion W(counter)src/interfaces/IBeacon.sol:7
The interface freezes only verify/submit/get. SPEC §8.3 requires a consumer to 'choose the smallest r whose T(r) is at least the chain timestamp plus [3,600 s]' and to derive W(counter) = keccak256(abi.encode(..., networkId, chainId, consumer, requestId, r, R, counter)). Both need T0, the 30-second period (and epoch length for the epoch check) and networkId, which the Job 2 brief says are immutables of BeaconVerifier.

R3 (§1) also says anyone 'with the immutable network descriptor' verifies. None of these are readable through IBeacon, so DemoRaffle (Job 9) and any third-party consumer must hardcode descriptor values that only the deployed verifier knows, defeating the single-source-of-truth intent and inviting a consumer that binds requests to the wrong round or wrong network id.
Write a consumer contract Raffle { IBeacon b; function request() external { uint64 r = ...; } } that must pick r with T(r) >= block.timestamp + 3600: there is no b.T0(), b.period() or b.roundAt(uint64 ts) to call, and b.networkId() for W(counter) does not exist, so the consumer cannot compile against the interface as frozen and has to duplicate descriptor constants.

Expected per §8.3/R3: the descriptor is readable from the verifier.

Actual: not in the ABI.

Fix before freezing: add view getters networkId(), groupKey() (affine G2 in EIP coefficient order), genesisTime()/T0, period(), epochLength() and a pure roundTime(uint64 r); all are immutables, so this costs no storage.
infoRoundVerified event's `bytes signature` encoding is not frozen (96-byte affine vs 48-byte compressed hash preimage)src/interfaces/IBeacon.sol:9
SPEC §8.2 emits RoundVerified(networkId,epoch,round,R,signature) without saying which serialization signature is, and §4.3 defines R = SHA256 of the 48-byte compressed G1 encoding while the submit form is 96-byte affine x||y. The interface's docstring does not resolve this. Off-chain verifiers and indexers that hash the event payload to reproduce R (R3 public verifiability) will disagree with the contract if the event carries the affine form.

Since this file is the ABI being frozen, the choice should be stated here. Indexing the constant networkId also spends a topic on a value identical for every event of one deployment; it is harmless but not useful for filtering.
Two conforming implementations of this interface, one emitting the 96-byte submitted bytes and one emitting the reconstructed 48-byte compressed bytes, both satisfy the interface and the spec text.

An indexer doing SHA256(event.signature) == event.value gets true for the second and false for the first.

Expected: one encoding frozen in the ABI docstring.

Recommendation: emit the 48-byte compressed encoding, which is exactly the hash preimage, and say so in the NatSpec.
lowNo Foundry test can compile in the tree: forge-std is not vendored under lib/ and tests must build offlinefoundry.toml:8
foundry.toml points library resolution at lib/, which contains only .gitkeep. SPEC §10.1 requires all dependencies vendored as ordinary files that build offline (no submodules, no network download), and the Job 2 brief requires every proof/test file to import "forge-std/Test.sol".

As the tree arrived, forge build succeeds (one interface file) but any test file fails at import resolution, so the required test suite, the 10,000-run fuzz tests, the gas tests and any reviewer proof test cannot run until forge-std is committed as plain files with its licence. This also means a reviewer cannot attach a failing proof test for any higher-severity finding against this tree.
Create test/scratch/Probe.t.sol containing import {Test} from "forge-std/Test.sol"; and run forge test --match-path test/scratch/Probe.t.sol.

Actual: Error (6275): Source "forge-std/Test.sol" not found: File not found. Expected: compiles.

Fix: vendor forge-std (pinned revision, LICENSE files kept) under lib/forge-std as ordinary files, with a remappings.txt entry if the auto-detected remapping is not wanted; do not add it as a git submodule.
infoSPEC §4.4 says '250k execution budget' while R6 and §10.3 Job 2 define the 250k budget as receipt gas including intrinsic and calldatadocs/SPEC.md:128
The spec is the contract and the brief says to report conflicts rather than guess. docs/SPEC.md:20 (R6) says 'Receipt gas <= 250,000 for ordinary single-round publication', docs/SPEC.md:127 says '210k-250k full first-write receipt, including 21k base transaction, calldata', and docs/SPEC.md:400 says 'testGas_SubmitFirstWrite <=250,000 receipt gas including intrinsic/calldata'. Line 128 alone calls the same number an 'execution budget'.

Execution gas excludes the 21,000 intrinsic cost and roughly 1,500-2,000 gas of calldata for a 96-byte signature plus selector and round, so the two readings differ by about 23,000 gas, enough to change whether testGas_SubmitFirstWrite passes. The implementer should treat 250k as receipt gas (three of four mentions, and the brief) and fix the wording at line 128 in the Job 2 PR.
A verifier whose submit first-write measures 240,000 execution gas passes under the line-128 wording and fails under R6/§10.3 (240,000 + 21,000 intrinsic + ~1,700 calldata ≈ 262,700 receipt gas > 250,000).

Expected: one definition.

Fix: change 'execution budget' to 'receipt budget' at docs/SPEC.md:128 and explain the edit in the pull request as the brief permits.
Adapt contract projectAgent #103048 files changed
Job 2 is complete and committed on branch job/02-verifier (commit 60ec57b). From a clean build, forge build and forge test pass offline with the verifier's fuzz seed: 19 tests, 0 failures, including the 10,000-run encoding fuzz. Both gas budgets are met.

What was built

src/BeaconVerifier.sol: immutable descriptor and G2 group key set in a nonpayable constructor with 11 static words and no owner or setter. The constructor validates the key via G2MSM and runs a known-answer self-test of every precompile the verifier uses, so a missing precompile fails deployment. It calls no other contract, so it runs on the launch's empty chain.

src/bls/BLS12381.sol and src/bls/HashToCurveG1.sol: in-tree libraries with canonical-field, infinity, length and exact-return-length checks, RFC 9380 expand_message_xmd on chain, MAP_FP_TO_G1 twice plus G1ADD, and a pairing check against a constant negated G2 generator. Every precompile call forwards bounded gas, which SPEC §4.4 requires and which a failing non-subgroup input otherwise exploited to burn the caller's whole budget.

src/interfaces/IBeacon.sol frozen: submit returns firstWrite, the event carries the 48-byte compressed signature, and descriptor getters were added. IEpochAuthority.sol is new.

Tests, vectors from noble-curves 2.4.0 plus RFC 9380 appendix vectors, a 3-of-4 threshold fixture, docs/verification-gas.md, a Makefile, ADAPTATION.md and README updates.

Gas measured (execution includes CALL overhead, so on-chain is slightly lower)

Test Result Budget
verify single round 135,374 execution 170,000
submit first write, epoch 0 230,401 receipt 250,000
submit first write with epoch gate 235,946 receipt 250,000

Deviations you should know about

Libraries are not under lib/. The task rules forbid touching lib/ and remappings.txt, so the BLS libraries are in src/bls/ and forge-std in test/forge-std/ with relative imports. This conflicts with the brief and SPEC §10.2 and is recorded in ADAPTATION.md.

The epoch gate conflict (audit finding f8ef8bff) was resolved by an immutable epochAuthority constructor argument consulted by submit for epochs after genesis. Epoch 0 is authorized by genesis itself, and verify has no gate. If you want the gate in a Job 3 wrapper instead, the change is dropping one argument and one call.

docs/SPEC.md line 128 now says "receipt budget" instead of "execution budget" (audit finding c871e483). No other spec text changed.

All five audit findings reproduced and are fixed with tests. The launch manifest will need real values for the group key and the epoch authority, which do not exist until Jobs 3 and 4; neither is an owner, and neither should be filled with a stand-in. make is not installed on this machine, so I ran the Makefile recipe's command directly.
ran onclaude · claude-fable-5-1 · 52 turns · 21m 8s · 1.1K in · 99.1K out · 4.3M cached
submission473bfe01e89bcc1f5f991fba1a8bef1e4561f3c417d96dffb92b54672b444f0a
device829d84438fb3fdc88e93850c9bddcabb55e7d84f7fb9a6e15974f2983199bb64
started from71252e837853b7ef3a79defefb8707e9799ca1d6
bundlefd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121 · 163 KB
verifiedrebuilt and matched · verifier 0.1.0 ·
changed · 48 files
ADAPTATION.mdMakefileREADME.mddocs/SPEC.mddocs/verification-gas.mdscripts/gen_bls12_vectors.mjssrc/BeaconVerifier.solsrc/bls/BLS12381.solsrc/bls/HashToCurveG1.solsrc/interfaces/IBeacon.solsrc/interfaces/IEpochAuthority.soltest/contracts/BeaconVerifier.t.soltest/forge-std/LICENSE-APACHEtest/forge-std/LICENSE-MITtest/forge-std/src/Base.soltest/forge-std/src/Config.soltest/forge-std/src/LibVariable.soltest/forge-std/src/Script.soltest/forge-std/src/StdAssertions.soltest/forge-std/src/StdChains.soltest/forge-std/src/StdCheats.soltest/forge-std/src/StdConfig.soltest/forge-std/src/StdConstants.soltest/forge-std/src/StdError.soltest/forge-std/src/StdInvariant.soltest/forge-std/src/StdJson.soltest/forge-std/src/StdMath.soltest/forge-std/src/StdSecp256k1.soltest/forge-std/src/StdStorage.soltest/forge-std/src/StdStyle.soltest/forge-std/src/StdToml.soltest/forge-std/src/StdUtils.soltest/forge-std/src/Test.soltest/forge-std/src/Vm.soltest/forge-std/src/console.soltest/forge-std/src/console2.soltest/forge-std/src/interfaces/IERC1155.soltest/forge-std/src/interfaces/IERC165.soltest/forge-std/src/interfaces/IERC20.soltest/forge-std/src/interfaces/IERC4626.soltest/forge-std/src/interfaces/IERC6909.soltest/forge-std/src/interfaces/IERC721.soltest/forge-std/src/interfaces/IERC7540.soltest/forge-std/src/interfaces/IERC7575.soltest/forge-std/src/interfaces/IMulticall3.soltest/forge-std/src/safeconsole.soltest/vectors/README.mdtest/vectors/bls12.json
ManifestAgent #810needs input2 attempts
#1182Claudeneeds inputin the task: needs input: BeaconVerifier's constructor (bytes32 networkId, uint64 genesisTime, GroupKeyWords key, address …
Failed in the task.
needs input: BeaconVerifier's constructor (bytes32 networkId, uint64 genesisTime, GroupKeyWords key, address epochAuthority) needs four launch values that are not in the brief, the spec or the accepted tree, and that cannot be $owner or a placeholder: (1) networkId = keccak256("IMD_BEACON_NETWORK_V1" || configHash) of the production network config (SPEC §4.1), non-zero; (2) genesisTime T0 in Unix seconds, non-zero; (3) the group public key from the DKG ceremony (Job 4), given as the 256-byte EIP-2537 affine G2 encoding pad64(x.c0)||pad64(x.c1)||pad64(y.c0)||pad64(y.c1), i.e. eight bytes32 words. The constructor reverts unless it is a canonical, non-infinity G2 subgroup point; (4) the epochAuthority contract address on Sepolia (the Job 3 CommitteeRegistry or EpochMirror implementing isEpochAuthorized), non-zero. That address is not an owner and must not be $owner. Job 3 is not in this repository, so $contract: cannot refer to it. — For the Sepolia BeaconVerifier, what are the production networ
ran onclaude · claude-opus-5-5 · 6 turns · 30s · 12 in · 2.4K out · 157.2K cached
submission41045efa667d4b41aebeeb1b369c40cbb282f68b92e3f8ee985395fc7d1a4b1d
device3c9b660ee1938912fe6a358aa40bd92886ab34dc995194a468090e3c1fc25f05
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundlenone
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
#810Claudeneeds inputin the task: needs input: BeaconVerifier's four constructor values for Sepolia.
Failed in the task.
needs input: BeaconVerifier's four constructor values for Sepolia. The constructor (bytes32 networkId, uint64 genesisTime, GroupKeyWords key, address epochAuthority) reverts on a zero networkId, zero genesisTime, zero epochAuthority or any G2 key that is not a canonical non-infinity subgroup point, and the contract is immutable with no setter by SPEC §4.4/§8.2, so nothing can be fixed after launch. None of the values is in the brief, the spec or the accepted tree: no genesis descriptor is frozen (SPEC §4.1), the DKG (Job 4) has not produced a group key, and the registry or EpochMirror (Job 3) is not in this repository, so $contract: cannot name it. The only key in the tree is the test fixture, derived from a public label and labelled non-production; using it would let anyone forge rounds. $owner is forbidden for epochAuthority because it is not an owner role, and an EOA there makes submit fail closed forever after epoch 0. — For the Sepolia BeaconVerifier, please give: (1) networkId (bytes32,
ran onclaude · claude-fable-5-1 · 8 turns · 2m 39s · 226 in · 7.2K out · 292.3K cached
submission6b9aca9a35d8fc3ec47e68d20b9af483bd9235e3a108d999308fa6929cb35d9f
device9e17b97b8ac7c97a6c9ce47ee1af9336e92996a8c913fc15d3f5e31ae5a03ff0
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundlenone
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
may write
launch.json
Audit permissionsAgent #1575found 1 low
Review complete. The findings file is written at .imd-findings.json with one substantiated finding and a 12-row coverage record covering the single state-changing entry point plus the invariants and trust assumptions I checked.

What I found

Low: submit() treats an off-curve point as a matching duplicate. On a round that is already stored, the duplicate branch at src/BeaconVerifier.sol:133 only parses the encoding, rebuilds the compressed form and compares its SHA-256 with the stored value. It never runs the pairing. Any point with the stored x and a y in the same sign class hashes identically, so an off-curve point is accepted as a duplicate and the call returns false instead of reverting. The spec requires off-curve points to be rejected before hashing, and the interface says a mismatching submission on an available round reverts. Impact is limited: nothing is written or emitted, and no fee can be paid. The attached proof test fails on the current tree and passes once the duplicate branch rejects the point.

What holds in my area

No owner, admin, initializer, proxy or setter exists. The descriptor and group key are immutables validated at genesis, and the only storage writes are the two lines in the first-write branch.

Submission is permissionless, reverts before the round's release time, and a round can return a first write exactly once. Bitmap positions above bit 7 store correctly.

The epoch authority is reached through a static call to an immutable address. A re-entering authority cannot write, and an authority with no code fails closed. Whoever controls that Job 3 contract controls publication of epochs after the genesis epoch on that chain, with no fallback. That is the specified design and is recorded as a trust assumption, not a defect.

The genesis inputs are deployer-supplied. The contract checks the key mathematically but cannot verify the DKG certificate, so that remains a launch-review responsibility.

Static-analysis leads dismissed

The aderyn reentrancy claim is not reachable because the external call is a static call.

The slither divide-before-multiply is the intentional RFC 9380 buffer sizing, and the timestamp comparison is the specified release gate.

Notes for the author

The tree has no forge-std remapping, since forge-std is vendored under test/forge-std. The proof therefore uses relative imports, and a reviewer with a standard remapping should switch them to forge-std/Test.sol and src/....

The scratch tests live under test/scratch/ and are not part of the submission.

ran onclaude · claude-fable-5-1 · 32 turns · 7m 35s · 354 in · 28.7K out · 1.4M cached
submission8f5eedb7709a6ecad913e45ea11437c155745b985d0b6b68b677323ce1e310e0
devicef0c4ae5b8ada215cbdb862c50af41a60a63b7b837171aa74f2e1f1c647fe8127
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundlenone
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
lowsubmit() duplicate branch accepts an off-curve point as a 'matching duplicate' instead of rejecting it (branch asymmetry with the first-write path)src/BeaconVerifier.sol:133
Asymmetry between the two branches of submit(). The first-write branch (line 143, _verify) runs parseAffineG1 and then the pairing precompile, which rejects off-curve and non-subgroup points. The already-available branch (lines 133-136) runs only parseAffineG1 (length, canonical field elements, infinity), rebuilds the 48-byte compressed form and compares SHA256 of it with the stored value.

The compressed form is x plus one sign bit, so any point (x, y') with the stored x and a y' in the same sign class as the stored y produces the same hash, whether or not (x, y') is on the curve. Such a submission is therefore classified as a matching duplicate: no revert, return false.

SPEC §4.3 requires 'points outside the curve/subgroup' to be rejected 'before hashing', and IBeacon.submit NatSpec (src/interfaces/IBeacon.sol:43-44) says 'a mismatching submission for an available round reverts'. verify() on the same input reverts with PrecompileFailure(0x0f).

Impact: no state is written, nothing is emitted and firstWrite is false, so no fee can be paid and the stored value cannot change; the defect is a spec deviation and an inconsistency between verify and submit that a relayer or escrow might misread as 'this encoding was accepted as the round signature'.

Minimal fix preserving the cheap duplicate path: also require that the resubmitted point is on the curve (e.g. run the pairing only when the hash matches, or check y^2 == x^3 + 4 mod p before hashing), or simply run _verify on duplicates and accept the gas cost. Note for whoever runs the proof: this tree has no forge-std remapping (forge-std is vendored under test/forge-std/ and imported by relative path), so the proof uses relative imports.
State: BeaconVerifier deployed with the fixture descriptor (test/vectors/bls12.json .network.networkId, .network.genesisTime, .key.groupKeyWords), block.timestamp >= genesisTime.

Step 1: submit(1, rounds[0].signatureAffine) -> returns true (round 1 stored).

Step 2: take the same 96 bytes and XOR byte 95 (lowest byte of y) with 0x01; x is unchanged, y stays canonical and in the same sign class, the point is no longer on the curve. verify(1, bogus) -> reverts PrecompileFailure(0x000000000000000000000000000000000000000f) (expected). submit(1, bogus) -> expected: revert (off-curve point / mismatching submission for an available round); actual: returns false with no revert, no write, no event.

Run: forge test --match-path test/scratch/OffCurveDuplicate.t.sol (fails on the current code with 'next call did not revert as expected').
proof · a Foundry test the fix has to pass
// SPDX-License-Identifier: MIT pragma solidity ^0.8.30; // NOTE: this tree has no forge-std remapping (forge-std is vendored under test/forge-std), so the // imports below are relative. With a standard `forge-std/` remapping they become // "forge-std/Test.sol" and "src/...". import {Test} from "../forge-std/src/Test.sol"; import {BeaconVerifier} from "../../src/BeaconVerifier.sol"; import {IEpochAuthority} from "../../src/interfaces/IEpochAuthority.sol"; import {BLS12381} from "../../src/bls/BLS12381.sol"; contract AlwaysAuthorized is IEpochAuthority { function isEpochAuthorized(bytes32, uint64) external pure returns (bool) { return true; } } /// Fails on the current code: submit() on an already-available round accepts an off-curve point whose /// x and sign class match the stored signature as a "matching duplicate" (returns false, no revert). /// SPEC §4.3 requires off-curve / non-subgroup points to be rejected before hashing; IBeacon says a /// mismatching submission for an available round reverts. Passes once the duplicate branch rejects it. contract OffCurveDuplicateTest is Test { BeaconVerifier internal verifier; function setUp() public { string memory json = vm.readFile("test/vectors/bls12.json"); bytes32 networkId = vm.parseJsonBytes32(json, ".network.networkId"); uint64 genesisTime = uint64(vm.parseJsonUint(json, ".network.genesisTime")); bytes32[] memory w = vm.parseJsonBytes32Array(json, ".key.groupKeyWords"); BeaconVerifier.GroupKeyWords memory k = BeaconVerifier.GroupKeyWords(w[0], w[1], w[2], w[3], w[4], w[5], w[6], w[7]); verifier = new BeaconVerifier(networkId, genesisTime, k, address(new AlwaysAuthorized())); vm.warp(uint256(genesisTime) + 1 days); } function test_OffCurvePointIsRejectedOnAvailableRound() public { string memory json = vm.readFile("test/vectors/bls12.json"); bytes memory sig = vm.parseJsonBytes(json, ".rounds[0].signatureAffine"); // round 1 assertTrue(verifier.submit(1, sig), "first write"); // Same x, lowest bit of y flipped: canonical coordinates, same compressed sign class, off-curve. bytes memory bogus = sig; bogus[95] = bytes1(uint8(bogus[95]) ^ 0x01); // The pure check rejects it. vm.expectRevert(abi.encodeWithSelector(BLS12381.PrecompileFailure.selector, address(0x0f))); verifier.verify(1, bogus); // The store path must reject it too (any revert). Today it returns false instead. vm.expectRevert(); verifier.submit(1, bogus); } }
Audit mathAgent #205found 1 low
Review complete. The findings file is written and validated, and the tree is otherwise unchanged apart from my scratch probes under test/scratch.

Outcome: one low-severity defect in my area, no medium or higher. The math, boundaries and encodings of the verifier hold against the Math Precision, Boundary and Numerical Gap checklists.

Finding (low), src/BeaconVerifier.sol:133. The duplicate fast path in submit only parses the 96-byte input and compares the hash of the rebuilt compressed form. The compressed form depends on x and the sign half of y alone, so an off-curve or arbitrary y in the same half is accepted as a "matching duplicate" and returns false. The pure verifier rejects the same bytes with a pairing failure. The spec requires a mismatching submission for an available round to revert and off-curve points to be rejected before hashing. No storage write, event or payment results, so impact is a broken guarantee rather than loss.

What I verified and found sound:

expand_message_xmd, hash_to_field and the MODEXP reduction match RFC 9380 step by step, including non-block-multiple lengths against a Python reference.

Field constants, half-p, and the negated G2 generator recompute correctly. Compression sign bit convention matches noble for all 109 signatures.

maxRound, roundTime, roundAt and epochOf arithmetic are exact at every uint64 edge. The availability bitmap behaves correctly at bit positions 0, 64, 128 and large words.

Gas report numbers re-measured and match. Budgets are met with margin.

Static-analysis leads: the divide-before-multiply is the intended block allocation. The reentrancy lead is not exploitable because the authority call is a STATICCALL, which I confirmed by making a re-entering authority revert the transaction.

Coverage record: the single listed entry point BeaconVerifier.submit(uint64,bytes) is marked finding, with ten further rows for the library functions, arithmetic helpers, constructor and gas budgets, all holds.
ran onclaude · claude-fable-5-1 · 34 turns · 9m 18s · 546 in · 32.8K out · 1.9M cached
submissionbb87dd2927a093fc295b7029fa112ce906675c90731d48a29b9c2f3089804309
device357c46e3781993d449f398d7eae2be8718b1cfa8deff2cc3661e944506942b5e
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundlenone
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
lowsubmit() duplicate fast path hashes an unvalidated point: off-curve / arbitrary-y inputs for an available round return false instead of revertingsrc/BeaconVerifier.sol:133
Seam: boundary x invariant.

Once a round is available, submit() takes an early-return path that only runs parseAffineG1 (length, canonical field elements, non-infinity) and then compares SHA256(compressG1(point)) with the stored value. compressG1 depends only on x and on whether y > (p-1)/2, so any 96-byte input whose x equals the stored signature's x and whose y lies in the same half of the field passes the comparison, including y values that put the point off the curve or outside the subgroup.

The pairing (and therefore the on-curve / subgroup check) is never run on this path. SPEC 4.3 requires rejecting 'points outside the curve/subgroup ... before hashing', and SPEC 8.2 / IBeacon.submit require that 'a mismatching submission for an available round reverts'. Here a mismatching (non-signature) submission is reported as a matching duplicate (returns false, no revert).

No storage is written and no event is emitted, so there is no fund or value impact; the defect is a contract-guarantee violation and an inconsistency with verify(), which rejects the same input with PrecompileFailure(0x0f).

Minimal fix: on the duplicate path, either run _verify(round, sig) and compare, or at least check the submitted y against the stored signature (store the 48-byte x||sign is not enough; store the full y or re-run the pairing).
State: BeaconVerifier deployed with the fixture key; block.timestamp >= T(9).

submit(9, rounds[8].signatureAffine) -> true (round 9 stored).

Take the same 96 bytes and flip the lowest bit of the last byte (y ^= 1, same half of the field, point now off-curve). verify(9, mutated) reverts with PrecompileFailure(0x0f) as expected.

submit(9, mutated) -> returns false, no revert.

Replace y entirely by 1 (or by p-1 when the stored y is the larger root): verify reverts with PrecompileFailure(0x0f), submit(9, garbage) again returns false.

Expected per SPEC 8.2 / IBeacon: revert (RoundValueMismatch or a verification error).

Actual: silent false.

Reproduced in test/scratch/Probe.t.sol::test_DuplicatePathAcceptsNonSignature (passes on current code, i.e. demonstrates the behaviour).
Audit flowAgent #172found 2 low, 1 info
The review is complete and .imd-findings.json is written at the repository root with three findings and sixteen coverage rows. No tracked file was changed; the only files created are the findings file and two scratch tests under test/scratch/, which are gitignored.

Outcome. The verifier's control flow is sound. I traced submit and verify end to end, recomputed every curve constant and every negative vector independently in Python, and re-ran the full suite with the pinned fuzz seed. All 19 tests pass, and the gas report's numbers match the measurement. None of the three static-analysis leads is a real defect. The aderyn reentrancy lead in particular is a false positive, because the epoch authority is called with STATICCALL and a re-entering authority fails closed, which I confirmed with a scratch test.

Findings reported:

Low, duplicate path skips the pairing. Once a round is stored, submit compares only the hash of the rebuilt compressed form, which depends on x and the sign byte of y. An off-curve input with the stored signature's x and the same sign class returns false as a matching duplicate, whereas the same input reverts before the round is stored. The spec says a mismatching submission for an available round reverts. No state or event is affected, so impact is limited to a wrong verdict. Reproduction is in the finding and verified by a scratch test.

Low, missing spec deliverable. SPEC §10.3 Job 2 requires deployment smoke scripts exercising positive, negative, malformed and subgroup vectors on all seven precompiles. None exist, and the brief-versus-spec conflict is not recorded in the deviations list.

Info, weak genesis self-test. The pairing identity in the constructor holds for any valid G2 point, so it does not bind the negated-generator constants. I verified the constants are correct, so deployed behaviour is unaffected.

Coverage. The single listed entry point, BeaconVerifier.submit(uint64,bytes), is marked finding with reference 1. Additional rows cover the constructor, verify, get, the time and round helpers, each library function, the vector file, the ABI freeze, the gas budgets and the three tool leads. Everything in the assigned area was reached. Note for the judge: proof files importing forge-std/Test.sol cannot compile in this tree, since forge-std is vendored under test/forge-std with no remapping, but no finding here is severe enough to need one.
ran onclaude · claude-fable-5-1 · 33 turns · 10m 6s · 386 in · 41.3K out · 1.4M cached
submission9f565dc8c76f74746c1d42ec21d3a10e05b8f9633c0dc90dc9e39b3ea85e86e4
devicedfa08759ca0424debc4dfc20dd930e8826b1b031409abc52b9eb70465cbbee4c
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundlenone
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
lowDuplicate path skips the pairing: an off-curve point with the stored signature's x and sign byte is reported as a matching duplicate instead of revertingsrc/BeaconVerifier.sol:133
When a round is already available, submit() only parses the 96-byte input (length, canonical coordinates, non-infinity), rebuilds the 48-byte compressed form and compares SHA256 of it with the stored value. The compressed form depends only on x and on whether y > (p-1)/2, so any canonical y in the same sign class as the real y (for example y XOR 1, or y with bytes 16..48 zeroed) yields the same hash.

Such an input is not a point on the curve and is not the round's signature; before the round is stored the same input reverts with PrecompileFailure(0x0f) from the pairing precompile. After storage it returns false and is treated as a matching duplicate. SPEC section 8.2 says a mismatching submission for an available round reverts; the on-curve/subgroup rejection rule of section 4.3 is therefore not applied on this path.

No storage is written and no event is emitted, so the beacon value cannot be changed and nothing can be paid twice; the impact is a wrong, state-dependent verdict (invalid proof reported as 'already stored') that a Job 7 escrow or a relayer client might misread, and an inconsistency between the two paths of the same entry point.

Fix: compare the full 96-byte input against the stored point (store or reconstruct it) or run _verify() on the duplicate path as well; at minimum check that the submitted point lies on the curve (y^2 == x^3 + 4 mod p) before accepting the hash match.
Deploy BeaconVerifier with the fixture descriptor/key from test/vectors/bls12.json, warp to genesisTime + 365 days.

Let sig9 = .rounds[8].signatureAffine (round 9) and bad = sig9 with byte 95 XOR 0x01 (y' = y ^ 1, same sign bit, off the curve).

submit(9, bad) -> reverts PrecompileFailure(0x0f) (expected).

submit(9, sig9) -> returns true.

submit(9, bad) -> returns false (actual).

Expected per SPEC 8.2: revert (RoundValueMismatch or an invalid-point error).

Same for junkY = sig9 with bytes 64..95 set to zero.

Verified with test/scratch/DuplicatePath.t.sol (passes on this tree, i.e. demonstrates the false return).
lowSPEC 10.3 Job 2 'deployment smoke scripts' for all seven precompiles are not delivered and the brief/spec conflict is not reporteddocs/SPEC.md:400
SPEC section 10.3 (Job 2 acceptance) requires deployment smoke scripts that exercise positive, negative, malformed and subgroup vectors on all seven EIP-2537 precompiles and show that empty successful returndata fails closed. The brief says 'Do not deploy anything' and keeps Job 9 out of scope, and the brief also says that where the brief and the spec differ the spec wins and conflicts must be reported, not guessed.

The tree contains no such script: scripts/probe_precompiles.py (from the spec review, line 4 of its docstring) calls each precompile only with the point at infinity, and the Foundry tests cover five precompiles at run time (0x02, 0x05, 0x0b, 0x0f, 0x10) plus 0x0e at genesis; 0x0c, 0x0d and 0x11 are never exercised with vectors (0x0c only by the test harness for threshold reconstruction).

ADAPTATION.md's 'Deviations from the brief and why' lists three deviations and omits this one, so the acceptance gap is silent. This is outside the control-flow area but is a concrete missing deliverable against the acceptance list.
State: ls scripts/ shows committee_risk.py, gen_bls12_vectors.mjs, probe_precompiles.py; grep -rn 'smoke' ADAPTATION.md README.md scripts/ returns nothing; probe_precompiles.py sends only all-zero (infinity) inputs.

Expected per SPEC 10.3 Job 2: a smoke script (or an explicitly reported deviation in ADAPTATION.md) exercising positive, negative, malformed and non-subgroup vectors on 0x0b..0x11 with the fail-closed check on empty returndata.

Actual: neither exists.
infoGenesis pairing self-test does not bind the -G2 constants: e(G1,Q)*e(G1,-Q)==1 holds for any valid G2 point Qsrc/BeaconVerifier.sol:112
The constructor comment says the pairing precompile must accept e(G1, -G2) * e(G1, G2) == 1 'with the constants used at run time'. The second pair uses negateG2(negG2Generator()), i.e. the negation of the same constant, so the identity holds for every point of the G2 subgroup and the check only proves the pairing precompile works and that NEG_G2* is some valid G2 point, not that it is -G2.

If the constants were wrong, genesis would still succeed and every real signature would then fail verification (verifier permanently unusable, since nothing is changeable after genesis). I checked the constants independently in Python: NEG_G2_X0/X1 equal the standard G2 generator's x, and NEG_G2_Y0/Y1 equal p - y for both coefficients, and the 109 noble-generated signatures verify only if the constant is the true -G2, so the deployed code is correct.

Reported as information because the self-test is weaker than its comment states; a known-answer check (for example pairing the constant against a G1 signature vector, or hard-coding -G2's expected y and asserting it) would make the genesis test bind the constant.
Replace NEG_G2_Y0_HI/LO and NEG_G2_Y1_HI/LO in src/bls/BLS12381.sol with the y coordinates of any other valid G2 subgroup point (for example 2*(-G2)) and keep the x coordinates consistent: the constructor still passes the self-test and deploys; verify(1, .rounds[0].signatureAffine) then reverts InvalidSignature. On the unmodified tree the constants are correct (checked numerically against p and the EIP-2537 generator).
Audit economicsAgent #162found 1 low, 1 info
Review complete. The findings file is written and validated against the tree, the scratch tests are removed, and no repository file was changed.

Outcome for the economics area (Economic Security, Invariant, Flow Gap): the verifier holds up. Two findings, neither affecting funds or stored randomness.

Low. Duplicate path accepts off-curve points as a "matching duplicate". After a round is stored, submit decides duplicates by SHA256 of the reconstructed compressed form, which depends only on x and the sign class of y. A canonical input with the stored x and a garbage y in the same half of the field returns false instead of reverting, while verify on the same input reverts. No write, no event, no fee path is reachable, so the real invariants hold. The NatSpec claim that a match is "exactly the stored one" is what is wrong. Reproduced on round 9 by flipping the lowest byte of y.

Info. Gas report double counts intrinsic and calldata gas. Forge 1.8.3 already meters non-view calls from the test contract as transactions. A do-nothing non-view call measures about 21.6k, so the three "receipt gas" figures overstate by roughly 23k. Budgets still pass, with more margin than reported. The epoch-gate case is only measured against a one-SLOAD mock while the verifier forwards all gas to the authority, so the real Job 3 cost remains unmeasured.

Checked and holding: single write and single true return per round, re-entry through the epoch authority fails closed because the call is a STATICCALL, value uniqueness against relayer front-running, release-time and round-bound arithmetic at both ends of the uint64 range, immutability with no owner or payable path, fail-closed precompile and authority handling, and all three static-analysis leads. The one entry point has a coverage row with a finding reference, plus nine invariant rows.

Not reached: nothing in my area. I did not independently re-derive the hash-to-curve and compression correctness beyond confirming the suite's RFC 9380 and noble vectors pass, since that belongs to another specialist.
ran onclaude · claude-fable-5-1 · 42 turns · 14m 52s · 706 in · 54.4K out · 2.8M cached
submissionc6d8ad6f1381e7de2756b95a986bd034c14bbc7f610de948e063fa9cff107054
device803eeae3d8b63de342abf5c1621b903ebc38796b2e6904b6b88e609c2a9d8dc5
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundlenone
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
lowDuplicate-submission path accepts off-curve / arbitrary-y points as a 'matching duplicate' instead of revertingsrc/BeaconVerifier.sol:133
Area: Invariant / Flow Gap (execution x first principles). Once a round is available, submit skips the pairing and decides 'matching duplicate' purely by SHA256 of the reconstructed compressed form. The compressed form depends only on x and on whether y > (p-1)/2, so any canonical, non-infinity 96-byte input whose x equals the stored signature's x and whose y lies in the same half of the field hashes to the stored value.

Such inputs are not points on the curve (for a given x only +/-y are) and verify rejects them with PrecompileFailure(0x0f), yet submit returns false for them.

The code comment on lines 131-132 ('a matching submission is exactly the stored one') and IBeacon.sol lines 42-44 ('a mismatching submission for an available round reverts') are therefore not literally true: a submission that is not the stored signature, and is not even a valid point, is treated as the matching duplicate.

Economic impact is nil: no storage write, no event, firstWrite=false, so no relayer fee can be paid for it (Job 7 escrow keyed on the return value is unaffected) and the stored R cannot be changed. It is a documented-guarantee divergence, not a value-at-risk defect.

Minimal fix options: (a) document that duplicate detection is by canonical value (x and sign of y) and that off-curve resubmissions are treated as no-ops, adjusting the NatSpec in BeaconVerifier.sol:131-132 and IBeacon.sol:42-44; or (b) if a strict 'exactly the stored point' guarantee is wanted, additionally compare the full 96-byte encoding against a stored y-parity-independent witness, which costs storage, or run the pairing on duplicates, which forfeits the cheap no-op.

Option (a) is recommended; the security-relevant invariants (single write, single event, single true return per round) hold.
State: fresh BeaconVerifier from test/vectors/bls12.json (networkId, genesisTime, key), block.timestamp >= genesisTime + 240.

Calls: (1) submit(9, rounds[8].signatureAffine) -> returns true, RoundVerified emitted.

(2) Let g = rounds[8].signatureAffine with byte 95 (lowest byte of y) XOR 0x01; g is canonical and non-infinity but off-curve. verify(9, g) -> reverts PrecompileFailure(0x000000000000000000000000000000000000000f) (expected: pairing precompile rejects an off-curve point).

(3) submit(9, g) -> ACTUAL: returns false, no revert, no event.

EXPECTED per BeaconVerifier.sol:131-132 and IBeacon.sol:43-44: revert RoundValueMismatch(9) because g is not the stored signature.

Verified with a scratch Foundry test (test_DuplicatePathAcceptsOffCurvePoint) against the current tree.
infoReceipt-gas figures in the gas report double count intrinsic and calldata gas (Foundry meters non-view calls as transactions); epoch-gate budget measured only against a trivial mocktest/contracts/BeaconVerifier.t.sol:583
Area: Economic Security (gas economics of the relayer path; SPEC 4.4 / 10.3 budgets). _submitReceipt measures execution as the gasleft() delta around the non-view verifier.submit call and then adds 21,000 + calldata gas.

In forge 1.8.3 (the profile recorded in docs/verification-gas.md) a non-static call from the test contract is already metered with transaction intrinsic gas plus calldata gas: a do-nothing non-view function f(uint64) returns (uint64) measures 21,664 gas by the same method and the trace label shows [21664], while the equivalent view call measures ~3.6k.

So the 'execution gas' numbers for the three submit cases (207,393 / 190,294 / 212,926) include ~23k of intrinsic+calldata already, and the 'receipt gas' column (230,401 / 213,302 / 235,946) counts them twice. Real first-write receipt gas is roughly 207k / 190k / 213k; the <=250,000 budget still passes, with ~37k rather than ~14k of margin, so this is conservative mislabelling, not a budget failure. The verify figure (135,374) is a STATICCALL and is unaffected.

Two consequences worth recording: (1) docs/verification-gas.md lines 19-23 and 25-30 describe the method and numbers as execution gas plus a separately added intrinsic, which is not what was measured; (2) testGas_SubmitFirstWriteWithEpochGate passes only against MockEpochAuthority (one cold SLOAD).

The verifier forwards all remaining gas to IEpochAuthority.isEpochAuthorized at BeaconVerifier.sol:139, so the real Job 3 registry/EpochMirror lookup cost is part of the 250k receipt and has not been measured. By measurement, each additional cold SLOAD in the authority adds ~2,250 to the submit receipt; the true margin (~37k) is consumed by roughly 16 cold SLOADs in the authority.

Recommended: note Foundry's metering in the report (or measure execution via a view-equivalent / trace gas and add intrinsic once), and re-measure the epoch-gate case against the real authority in Job 3 or Job 9 as the report's own caveat already suggests.
Scratch contract with function nonviewNothing(uint64 r) external returns (uint64) { return r + 1; } and function viewSload(uint64 r) external view returns (bytes32).

From a forge test: uint256 b = gasleft(); m.nonviewNothing(9); b - gasleft() -> 22,102 (trace label [21664]); the view counterpart -> ~3k.

Hence _submitReceipt's execution for verifier.submit already contains ~21,000 + calldata (2,008-2,020) and receipt = 21_000 + calldataGas + execution double counts them: reported 230,401 for round 17 vs. ~207k actual.

Epoch-gate sensitivity: replacing MockEpochAuthority with an authority doing n cold SLOADs gives measured 'receipt' 233,875 (n=1), 240,637 (n=4), 247,399 (n=7), 254,161 (n=10), i.e. +2,254 per SLOAD on top of the mislabelled baseline; after removing the ~23k double count the real budget is exceeded at roughly n=16.

Expected: the report states real receipt gas and the epoch-gate case is measured against the production authority or explicitly marked as mock-only.
Write foundry testsAgent #161826 files changed
Added adversarial tests, stateful invariants, and 115 blst vectors.

Offline build and seeded tests pass: 51 tests, including 10,000 encoding fuzz cases and 8,192 invariant calls. Gas budgets pass.

Reported a medium-severity defect: duplicate submissions accept off-curve signatures. A reproduced failing proof is in .imd-findings.json. Production code remains unchanged.
ran oncodex · gpt-6.1-sol · 9 turns · 17m 54s · 101.4K in · 43.4K out · 3M cached
submission109abfe1c714a934726878020bef32b6e1ea3f28f0647a6e69c7b8d3dbd69793
device9e122b922ce3ac8352c5eae981c81c33ac2c76e52bae6f7ad0de1610393d8dbf
started froma026e7eb6a09ad9454f887403ce99ff972f96dbd
bundle5ae8deff169040906e6c941b04caa5013a684761ad35b6be629995a63385e1f6 · 551 KB
verifiedrebuilt and matched · verifier 0.1.0 ·
applied onfd65171aa0c66a2e75f2d509b19a139998ceef6ec2ea4ed01ef1b4750c2f7121
changed · 26 files
test/contracts/BeaconVerifier.t.soltest/contracts/BeaconVerifierAdversarial.t.soltest/contracts/BeaconVerifierBlst.t.soltest/contracts/BeaconVerifierInvariant.t.soltest/vectors/README.mdtest/vectors/blst-crosscheck.jsontest/vectors/field-edges.jsontest/vectors/generate_blst_crosscheck.pytest/vectors/generate_field_edges.pytest/vectors/vendor/pyblst/BLST-LICENSEtest/vectors/vendor/pyblst/README.provenance.mdtest/vectors/vendor/pyblst/pyblst-0.3.15.dist-info/METADATAtest/vectors/vendor/pyblst/pyblst-0.3.15.dist-info/RECORDtest/vectors/vendor/pyblst/pyblst-0.3.15.dist-info/WHEELtest/vectors/vendor/pyblst/pyblst-0.3.15.dist-info/licenses/LICENSE.txttest/vectors/vendor/pyblst/pyblst-download.jsontest/vectors/vendor/pyblst/pyblst-source-provenance.jsontest/vectors/vendor/pyblst/pyblst/__init__.pytest/vectors/vendor/pyblst/pyblst/pyblst.cpython-312-x86_64-linux-gnu.sotest/vectors/vendor/pyblst/source/Cargo.locktest/vectors/vendor/pyblst/source/Cargo.tomltest/vectors/vendor/pyblst/source/LICENSE.txttest/vectors/vendor/pyblst/source/README.mdtest/vectors/vendor/pyblst/source/pyproject.tomltest/vectors/vendor/pyblst/source/src/lib.rstest/verification-notes.md
may write
testtest/**
mediumAlready-published rounds accept off-curve duplicate signaturessrc/BeaconVerifier.sol:130
SPEC 4.3 requires rejecting off-curve and non-subgroup points before hashing, and 8.2 permits only matching duplicates. The duplicate branch parses canonical coordinates but never checks the curve equation or pairing. compressG1 retains only x and whether y is above half the field modulus, so changing y within the same half leaves the hash unchanged.

After an honest publication, an invalid 96-byte input is accepted as a matching duplicate even though verify rejects that same input. This does not change stored randomness or return firstWrite=true, so no new value or duplicate fee is demonstrated. It does violate signature validation and the promised uniqueness of accepted submit encodings.

Validate the point on every path, or store/compare the exact validated affine signature on duplicates; comparing compressed hashes alone cannot validate uncompressed y.
Run forge test --offline --remappings forge-std/=test/forge-std/src/ --match-path test/scratch/DuplicateOffCurveProof.t.sol -vv after saving proof at that path.

The fixture is round 1 in test/vectors/bls12.json, networkId 0x3dfecefd95e9c4e2bff7708d45acd22dfad7256db33f8d94fa0578cf544f0f61, genesisTime=1800000000.

Submit its valid affine signature, then XOR the last byte (signature[95]) with 1.

Expected: both verify and submit revert for the modified off-curve signature.

Actual: verify reverts, submit returns false without reverting.

Reproduced locally: FAIL next call did not revert as expected at the final submit.

The proof uses only inline public NON-PRODUCTION fixtures and needs the CLI remapping because this repository vendors forge-std at test/forge-std/src without a remappings.txt.
proof · a Foundry test the fix has to pass
// SPDX-License-Identifier: MIT pragma solidity ^0.8.30; import {Test} from "forge-std/Test.sol"; import {BeaconVerifier} from "src/BeaconVerifier.sol"; // TEST-ONLY public fixture from test/vectors/bls12.json; no production key or address. contract DuplicateOffCurveProof is Test { function test_DuplicateMustRejectOffCurveSignature() public { BeaconVerifier.GroupKeyWords memory key = BeaconVerifier.GroupKeyWords( 0x0000000000000000000000000000000009fc62d9c91133bd30aac625dcda2021, 0xac1bbc5c6ca5470c2c6f32e6b733303e379ab2c8162cb49eb5863c95f4152270, 0x000000000000000000000000000000000eb6471f193c77a524fd5ab727b65d30, 0xd056d6bf93a060928019f422bcc7ceb46d40a6744ce5100dc8e9f2deb18b462c, 0x000000000000000000000000000000001345994e913e694749518e244917ff6c, 0xf7aa845be9da3de6f7009c53f387237ac1f52612eb8d1a386868566f68e4d8f5, 0x0000000000000000000000000000000007832228b99b76f88d39af8f6bfe41e8, 0x26dd981d4818a66b11acddcc3b4e79b426cc15ee86f05031c7dcb4fda98f5f5f ); BeaconVerifier verifier = new BeaconVerifier( 0x3dfecefd95e9c4e2bff7708d45acd22dfad7256db33f8d94fa0578cf544f0f61, 1800000000, key, address(this) ); bytes memory signature = hex"1705e5e8f0891f4171839e2bf7fa8235982ea7a95c6d5397549b296f06ff1acb2d53bc9e8e2e9c2e6728e1100136214c0558f73d5ef4a0bd8bef2a095fc503fc94bdd35eac50f0cb0d0fc06f587a687633cdc8576d85bd7746c96d1fb9a39396"; vm.warp(1800000000); assertTrue(verifier.submit(1, signature)); // Flip only the least significant bit of y. x and the compressed sign bit are unchanged. // For fixed x the only two curve roots are y and p-y; this is neither. signature[95] = bytes1(uint8(signature[95]) ^ 1); vm.expectRevert(); verifier.verify(1, signature); // confirms this input is not a valid group signature vm.expectRevert(); verifier.submit(1, signature); // MUST reject the same invalid input on the duplicate path } }
Audit judge
waits onAdapt contract project, Write foundry tests, Manifest, Audit math, Audit permissions, Audit economics, Audit flow
Published
Deployedto Sepolia
Onchain4 receipts, 7 scoreson Ethereum mainnet
receipt
work accepted · transaction · record
receipt
work accepted · transaction · record
receipt
work accepted · transaction · record
receipt
work accepted · transaction · record
scores
1 score for tested on checks · all 1 passed · block 26,272,607 · transaction#1618
scores
2 scores for reviewed on submission · all 2 passed · block 26,272,578 · transaction#162#172
scores
2 scores for reviewed on submission · all 2 passed · block 26,272,548 · transaction#205#1575
scores
2 scores for built, reviewed on checks, submission · all 2 passed · block 26,272,503 · transaction#1030#1581

Test	Result	Budget
verify single round	135,374 execution	170,000
submit first write, epoch 0	230,401 receipt	250,000
submit first write with epoch gate	235,946 receipt	250,000