pq-precompile doc claims "Zero6-gated" but hardfork_flags is never read in the dispatch or execution path

[pplmaverick]

Summary

pq-precompile's address constant is documented as gated by the Zero6 hardfork, but
tracing the full call chain from registration to execution shows hardfork_flags is
never inspected anywhere in that path. This differs from sibling precompiles in the
same dispatch table, which do read hardfork_flags internally.

Evidence

Doc claim:
crates/pq-precompile/src/lib.rs:24

/// PQ precompile address ... (Zero6-gated)

Registration — no gate:
crates/precompiles/src/precompile_provider.rs:45-65
create_precompiles_map(spec, hardfork_flags: ArcHardforkFlags) passes hardfork_flags
into all four stateful precompile closures uniformly, but the function body contains no
if hardfork_flags... / .is_active(...) branch anywhere — registration into the match
arm is unconditional for all four addresses, not just PQ.

Wrapper — parameter unused:
crates/precompiles/src/pq.rs:20-25

pub(crate) fn run_pq(input: ..., _hardfork_flags: ArcHardforkFlags) -> ...

Underscore-prefixed, confirmed unused.

Core impl — doesn't accept the parameter at all:
crates/pq-precompile/src/lib.rs::run_pq_precompile
Signature is (gas: u64, data: &[u8], reservoir: u64) — no hardfork parameter in scope.

Contrast with sibling precompile that does use it correctly:
crates/precompiles/src/native_coin_control.rs:132,146,250,264 reads
hardfork_flags.is_active(ArcHardfork::Zero8) in four places to drive real behavioral
branches, with dedicated test coverage
(delegatecall_charges_early_revert_penalty_only_under_zero8).

Test suite acknowledges the gap:
crates/execution-e2e/tests/e2e/pq_precompile.rs:26-27

//! There is no case here for Zero6 disabled (PQ precompile unavailable): the harness uses
//! LOCAL_DEV, where Zero6 is active from genesis—same scope as `p256_precompile.rs`.

This comment confirms "Zero6 disabled → PQ precompile unavailable" is the intended
behavior, but the test harness never exercises it because Zero6 is active from genesis
in every test environment.

Current impact

None on any externally reachable network. ARC_ZERO6_HARDFORK_TIMESTAMP_ACTIVATION_TESTNET
(1779894517, 2026-05-27) has already passed on testnet, and mainnet activates Zero6 from
Block(0) — so there's no point in either network's history, past or future, where
PQ_ADDRESS would be reachable while Zero6 is inactive.

Devnet (ARC_ZERO6_HARDFORK_BLOCK_ACTIVATION_DEVNET = 40033853) is block-height-gated
rather than timestamp-gated, and I did not verify its current height — but devnet has no
public RPC or block explorer (confirmed via hardhat.config.ts, where devnet/testnet/
mainnet all default to an empty URL sourced from a private env var, unlike localdev
which defaults to http://localhost:8545). It appears to be an internal CI/staging
network with no external attack surface, so its activation state doesn't affect this
report's impact assessment regardless of its current height.

This is a documentation/implementation gap rather than a live vulnerability.

Why raise it anyway

create_precompiles_map has no registration-time hardfork gating mechanism at all — this
is systemic across the dispatch layer, not specific to PQ. If a future hardfork-gated
precompile is added following the same pattern (unconditional match arm + hope the
internal run_* function checks hardfork_flags), the same gap would recur, and might
not always land on the safe side of a timestamp coincidence like this one did.

Suggested resolution (either direction seems reasonable, deferring to maintainers)

• Either: remove the "(Zero6-gated)" claim from the doc comment if availability gating was
  never intended at the dispatch layer, or
• Add an explicit if !hardfork_flags.is_active(ArcHardfork::Zero6) { return None } guard
  in create_precompiles_map for PQ_ADDRESS, matching the intent in the doc comment.

Happy to open a PR for either direction if useful.

[osr21]

Verified the static analysis against current main (66ad2d5) — every cited location checks out: the PQ_ADDRESS arm in create_precompiles_map is unconditional, run_pq takes _hardfork_flags and ignores it, run_pq_precompile has no hardfork parameter, and native_coin_control.rs (plus system_accounting.rs, which branches on Zero6 itself at lines 660–670) shows what flag use looks like when it's real.

But I think the framing should shift from "doc/implementation gap" to regression introduced in v0.8.0, based on two things the repo history and the live chain both confirm:

1. The gate existed through v0.7.3 — the v0.8.0 provider rewrite dropped it

crates/precompiles/src/precompile_provider.rs at tags v0.7.2 and v0.7.3 (identical, lines 63–67):

PQ_ADDRESS => {
    // Only register PQ precompile if Zero6 hardfork is active
    if !hardfork_flags.is_active(ArcHardfork::Zero6) {
        return None;
    }

Both releases also carried both polarity tests: test_pq_precompile_available_with_zero6 and test_pq_precompile_not_available_without_zero6. On main, the guard is gone, the negative test is gone — and the surviving test_pq_precompile_available now passes ArcHardforkFlags::default(), which is all hardforks inactive (#[derive(Default)] over six bools), while asserting the precompile is available. So the test suite doesn't just fail to catch the regression; it now pins it.

The doc comment isn't stale, in other words — it describes behavior that shipped and ran in production until v0.8.0.

2. Live testnet confirms fork-boundary gating — but only on backends still running pre-v0.8.0 binaries

Zero6 activates on testnet at timestamp 1779894517, which binary-searches to block 44295021. eth_call to 0x1800…0004 with a garbage selector (0xdeadbeef):

Block	Result
44295020 (last pre-Zero6, ts 1779894516)	EVM error: StackUnderflow
44295021 (first Zero6-active, ts 1779894517)	execution reverted: Invalid selector (the precompile's early-revert)

The flip lands exactly on the activation block, consistently across rpc.testnet.arc.io, rpc.testnet.arc.network, and arc-testnet.drpc.org — that's registration-time gating executing in the serving binary, not routing noise.

Side note that sharpens the "what does unavailable mean" question: the reserved addresses carry marker bytecode 0x01 on testnet (eth_getCode returns 0x01 for both 0x…0004 and the unregistered 0x…0005), so an ungated call executes ADD on an empty stack. Pre-Zero6 canonical semantics are "execute the marker code and halt with StackUnderflow" — not an empty-account no-op.

Which binary answers those historical calls? A version fingerprint separates them: value-exceeds-balance requests without fee fields return EVM error: OutOfFunds on v0.8.0 (revm 38) but the older insufficient funds for gas * price + value… text on earlier releases. Against rpc.testnet.arc.io, recent blocks (latest, −5k, −100k) fingerprint as v0.8.0 while deep blocks — including the fork boundary above — fingerprint as pre-v0.8.0. So the correctly-gated historical answers are coming from not-yet-upgraded archive backends. A v0.8.0 binary evaluating block 44295020 would return Invalid selector instead.

Why this is more than documentation

• Historical-view drift: as archive fleets upgrade, eth_call / eth_estimateGas / debug_traceCall against pre-Zero6 blocks silently change answers for 0x1800…0004 (StackUnderflow → precompile semantics). Endpoints at different versions already disagree today.
• Latent replay divergence: pre-Zero6 blocks were produced and validated under v0.7.x rules, where a call to 0x…0004 executed the marker code. A v0.8.0 node re-executing those blocks (full sync from genesis) computes precompile semantics instead — different gas and receipts if any pre-Zero6 transaction ever called that address. Whether such a transaction exists in testnet history is checkable internally; if none, this stays latent, but it's precisely the landmine the v0.7.x guard existed to prevent.
• Devnet: ARC_ZERO6_HARDFORK_BLOCK_ACTIVATION_DEVNET = 40033853 is block-gated, so a v0.8.0 devnet node below that height would expose PQ early in live execution, not just in replay.

On the resolution

Given v0.7.3, the either/or mostly answers itself: restoring the registration guard (and the not_available_without_zero6 test polarity that was lost) matches the doc comment, the pre-v0.8.0 releases, and the semantics under which the chain's pre-Zero6 history was actually produced. The systemic point in the report stands and is worth keeping in view — the closure-based set_precompile_lookup shape that arrived with the revm 38 migration has no structural place for registration-time gating, which is presumably exactly how the guard got lost. A Zero6-inactive e2e case (the gap the pq_precompile.rs header already acknowledges) would keep the next provider refactor from dropping it silently again.

[pplmaverick]

Given the severity re-assessment in this thread, I've submitted this through Circle's
official security channel (circle-bbp on HackerOne) per SECURITY.md, crediting the
analysis here. Pausing further public technical discussion on this thread until that's
resolved — happy to follow up here once there's guidance on next steps.

[osr21]

Escalating through the Bug Bounty Program is the right call given the re-assessment — that's exactly what SECURITY.md asks for once something stops looking like a pure documentation issue. I'll likewise hold off on posting further technical detail here until there's guidance from that process.

If it helps triage, the verification artifacts behind my comment above (exact RPC request/response transcripts for the fork-boundary probes, the version-fingerprint matrix per endpoint and block depth, and the tag-by-tag source comparison) are reproducible from what's already written, and I'm happy to hand over the raw transcripts through the same private channel if Circle's team wants them — feel free to reference this thread's analysis in the report as you see fit.

For anyone else following along: nothing in this thread requires action from dapp or contract developers on Arc testnet. The mainline behavior at current blocks is unaffected (Zero6 has been active since May); the discussion concerns consistency of node-level historical views and re-execution, which is for node operators and the Arc team to resolve.

[ygd58]

Nice writeup -- the trace from doc claim through registration to the unused _hardfork_flags param is clear and the impact assessment (no live-network exposure today, systemic risk for future hardfork-gated precompiles) is well-reasoned.

If you are not planning to open the PR yourself, happy to take a pass at option 2 (the explicit if !hardfork_flags.is_active(ArcHardfork::Zero6) { return None } guard in create_precompiles_map, matching the doc's stated intent) with a regression test mirroring native_coin_control.rs's is_active(...) pattern -- just did not want to duplicate effort if you or a maintainer already has it in hand.

[osr21]

@ygd58 Not planning to open it from my side, so no duplication risk there.

That said, I'd suggest holding the PR until there's guidance from the private-channel process @pplmaverick kicked off, or a maintainer weighs in here. Two practical reasons:

• The report is in Circle's security triage now. Everything needed for the fix is already public in this thread, but how the fix lands — release vehicle, sequencing relative to already-running v0.8.0 nodes and not-yet-upgraded archive fleets, whether devnet needs handling first — is exactly what a team coordinates during triage. A parallel public PR mid-process risks working against that rather than helping.
• Worth knowing before investing effort: development on this repo happens internally and syncs out — release tags land as single squashed sync commits (e.g. current main's HEAD is chore: sync v0.8.0), and external PRs sit behind first-time-contributor CI approval. So a public PR here is most useful as a reference implementation the team can port, not something likely to merge directly.

Once there's a green light, the change is already fully specified upthread: the v0.7.2/v0.7.3 guard quoted in my first comment is effectively the spec, plus restoring the deleted not_available_without_zero6 test and correcting the surviving unit test that now passes ArcHardforkFlags::default() (all hardforks inactive) while asserting the precompile is available. If you do take it, that last piece is the one I'd most want covered — a test that pins the wrong behavior is worse than a missing one.

[ygd58]

Good call, holding off on a PR until triage concludes -- appreciate the context on how external PRs actually land here, that changes my calculus on where to spend effort. Will watch this thread for the green light.