Post-quantum signature verification precompile (Falcon / FN-DSA)

[bilalprof]

Arc's fee model makes on-chain post-quantum signing economically impossible
today, and a precompile would fix it.

We run a self-custodial payments product where every transaction is signed
in the user's browser with Falcon-1024, the NIST-standardised post-quantum
scheme. We are live on Algorand where Falcon is a native account type. We
would like to move to Arc.

Measured on Arc mainnet at the current 20 Gwei floor, with USDC gas at 18
decimals:

plain USDC transfer 65,000 gas $0.0013
Falcon-512, keccak variant 1,500,000 gas $0.030
Falcon-512, NIST compliant 3,900,000 gas $0.078
Falcon-1024, NIST (est.) ~7,800,000 gas ~$0.156

A Falcon-1024 verification is therefore more than a hundred times the cost of
the payment it authorises, and consumes roughly a quarter of a 30M gas block.
Every available verifier is also Falcon-512 only, unaudited, and the authors
state it should not be used in production.

Draft EIP-8052 proposes a standardised precompile at around 3,000 gas per
verification, which would bring the cost to a small fraction of a cent.

Questions:

1. Is post-quantum signature verification on Arc's roadmap?
2. If not, would Circle consider a precompile along EIP-8052 lines?

Arc would be the first chain where stablecoin payments can be post-quantum
secure at the protocol level. Happy to share our measurements and test cases.

[osr21]

Measurement verification and Arc-specific context

Your gas numbers are correct. Arc denominates USDC gas with 18 decimals at the protocol level, even though the ERC-20 token uses 6 — so the 20 gwei floor framing is exact. At that floor:

Operation	Gas	Cost (USDC)
USDC transfer	65,000	$0.0013
Falcon-512 (Keccak-PRNG variant)	1,500,000	$0.030
Falcon-512 (NIST / SHAKE256)	3,900,000	$0.078
Falcon-1024 NIST (estimated)	~7,800,000	~$0.156

Arc's block gas limit is 30 M, target 15 M. A 7.8 M-gas Falcon-1024 tx fills 26% of a block, and at the 500 ms block time that caps the chain at ~3–4 Falcon-1024 verifications per second — a meaningful throughput ceiling before any demand for the chain's other capacity is counted.

---

EIP-8052 exists and is in active draft

EIP-8052 ("Precompile for Falcon support") is a real draft, created 2025-10-17, from the authors of the FreshCryptoLib Falcon reference implementation and the Falcon co-author Zhenfei Zhang. It proposes three precompiles:

• FALCON_HASH_TO_POINT_SHAKE256 — NIST-compliant challenge computation (~1,000 gas)
• FALCON_HASH_TO_POINT_KECCAKPRNG — EVM-friendly variant using Keccak (~1,000 gas)
• FALCON_CORE — the NTT-based core verification (~2,000 gas)

Total per verification: ~3,000 gas, a ~1,300× reduction for NIST Falcon-512. Discussion thread: https://ethereum-magicians.org/t/eip-8052-precompile-for-falcon-support/25860

One scope note: EIP-8052 currently specifies Falcon-512 only. The abstract explicitly says the lattice dimension is fixed at 512. A Falcon-1024 precompile would need a separate or extended EIP — it is not covered by the current draft. If Falcon-1024 is load-bearing for your security model, that gap is worth raising on the Ethereum Magicians thread.

The EIP also requires EIP-7932 (AlgorithmicTransaction container) as a prerequisite for the native-account path, though the precompile functions themselves can be called independently from contracts.

---

Arc's precompile architecture

Arc already ships Arc-specific precompiles outside the standard EVM set (the transaction memo precompile, the protocol config and validator registry getters, etc.) implemented directly in the node binary and activated through the network's upgrade mechanism. The precedent for Arc-native precompiles exists; the question is the prioritisation and fork-activation timeline.

Because Arc is a permissioned L2 with a faster release cadence than Ethereum mainnet, it could adopt EIP-8052 precompiles ahead of L1 — or adopt the FALCON_CORE precompile alone without requiring EIP-7932 if native Falcon accounts are not in scope initially. That narrower scope (precompile callable from contracts, no changes to tx format) would be lower-effort and already unlocks most of the cost reduction.

---

Near-term mitigation options

While waiting on a precompile decision, two things reduce current costs:

1. Use the Keccak-PRNG variant (the ethfalcon512 path) if you can tolerate the minor deviation from the NIST hash-to-point. The benchmark difference in your table (1.5 M vs 3.9 M gas) comes entirely from using Keccak256 instead of SHAKE256 for the challenge hash — the core NTT verification is the same.

2. Batch verification: if multiple payments in one call each need a Falcon sig checked, the public-key NTT can be precomputed and amortised. The FreshCryptoLib repo (https://github.com/rdubois-crypto/FreshCryptoLib) has a Solidity verifier that structures the steps to allow this.

---

Tagging this as a concrete use case that blocks a live mainnet product would be useful input for Circle's roadmap conversation, and cross-posting the throughput numbers to the EIP-8052 Ethereum Magicians thread would strengthen the L2 motivating case there.