SNARKs for Transfers, STARKs for Vaults

Key Takeaways

• UPP runs two proof systems in the same pool: PLONK (SNARK) for cheap everyday transfers, Circle STARKs for post-quantum secure storage. They coexist permanently, not as a migration path.
• The gas tradeoff is 100x: At 2026's low gas prices (~0.015 gwei), PLONK costs under a cent and STARK costs under a dollar. Even during congestion spikes, STARK stays under $50. For everyday payments, use PLONK. For long-term high-value positions, use STARK.
• STARKs are genuinely post-quantum. They rely on hash collision resistance, not elliptic curves. No quantum algorithm provides more than a quadratic speedup against hashes.
• "Harvest now, decrypt later" makes this urgent. Adversaries recording encrypted blockchain data today can retroactively decrypt SNARK-protected transactions when quantum hardware matures.
• No other Ethereum privacy protocol offers both. RAILGUN, 0xBow, and Aztec are pairing-based only. Polygon Miden uses STARKs but requires a separate L2.

If Quantum Computers Arrive in 2032

Every privacy transaction you made using a pairing-based SNARK becomes retroactively transparent. Every sender, every receiver, every amount: exposed.

For a $500 coffee payment, that's an annoyance. The wrong people learn you were at a conference in Zurich in October 2027.

For a $50 million institutional position held for five years, it's a catastrophe. Every entry, every exit, every rebalancing move — permanently legible to anyone who stored your encrypted on-chain data and waited long enough.

This isn't speculation. Three papers published between May 2025 and March 2026 reduced the estimated qubit cost of breaking elliptic curve cryptography by two orders of magnitude. Google Quantum AI's March 2026 paper estimated a 41% probability of deriving a Bitcoin private key before a standard 10-minute confirmation window closes. The timeline has compressed from "decades away" to "this decade."

The implication for privacy protocols is specific and severe: proof systems built on elliptic curve pairings — which includes every major privacy protocol deployed today — will eventually fail. Not just future transactions. Historical ones too.

That's the fundamental problem with picking a single proof system. You optimize for today's gas costs and accept tomorrow's quantum risk. Or you build for post-quantum security and pay an order of magnitude more in gas on every transaction.

Neither answer is right for every use case. The honest engineering response is to build both, and let the threat model of each transaction determine which one to use.

That's exactly what Universal Private Pool does.

---

What SNARKs and STARKs Are (for CTOs, Not Cryptographers)

Both proof systems solve the same basic problem: I want to prove to you that I know something (a secret, a valid note in a pool, an inclusion in a set) without telling you what that something is. Zero-knowledge proofs are the cryptographic machinery that makes this possible.

The two families differ sharply in how they achieve it.

SNARKs (Succinct Non-interactive Arguments of Knowledge) produce tiny proofs (typically a few hundred bytes) that are cheap to verify on-chain. The catch: they require a trusted setup, a one-time ceremony where some participants generate cryptographic parameters that must remain secret. If those parameters are ever reconstructed, an attacker can forge proofs silently. More critically, SNARK security depends on the hardness of the discrete logarithm problem on elliptic curves, which Shor's algorithm, running on a large enough quantum computer, solves in polynomial time.

STARKs (Scalable Transparent Arguments of Knowledge) require no trusted setup. Security rests entirely on collision resistance of a hash function: the assumption that you can't find two inputs that hash to the same output. No quantum algorithm offers polynomial speedup against hash functions. Grover's algorithm provides a quadratic speedup (which halves effective security), but a 256-bit hash retains 128-bit quantum security. STARKs are genuinely post-quantum.

The cost: STARK proofs are larger (~5 KB vs ~200 bytes) and more expensive to verify on-chain.

At current Ethereum gas prices (which dropped significantly in 2026 to ~0.015 gwei base fee), verifying a PLONK proof costs under a cent. Verifying a STARK costs under a dollar. But at congested-network rates (2+ gwei), those numbers jump to $0.50 and $50 respectively. The 100x ratio between the two systems is constant regardless of gas price.

---

Why Not Just Use STARKs for Everything?

The gas ratio is 100x. At 2026's typical 0.015 gwei base fee, STARK verification costs under $1, which is entirely workable. But during congestion spikes (2+ gwei), that same verification costs ~$50. At that price, a $100 stablecoin transfer with a $50 verification fee is a 50% tax. Nobody pays that.

For a $10 million institutional position with a three-year hold, even a $50 worst-case verification fee is 0.0005% of position value. The quantum risk from using a pairing-based SNARK over that same three-year period is not 0.0005%. It's a qualitatively different category of risk.

The mistake most privacy protocol designers make is optimizing for one point on this spectrum. They pick SNARKs because the gas costs are tractable at retail scale. They never build the post-quantum option, because the gas costs look prohibitive in a spreadsheet.

What that framing misses is that different transactions have different threat models.

A payment at a coffee shop has a 24-hour threat horizon. Even if the privacy guarantees erode in 10 years, the transaction is settled, complete, and irrelevant by then.

A large position in a privacy pool has a threat horizon that extends years. The note is live on-chain. The encrypted data can be harvested today and decrypted when quantum hardware catches up. For that use case, SNARK security isn't just inadequate — it's actively reckless.

Different threat models require different tools.

---

How Does UPP's Dual Architecture Work?

Universal Private Pool runs both proof systems side by side. They are not competing alternatives or a migration path. They are permanently coexistent options designed for different use cases.

The architecture is unified at every layer except the proof mechanism:

• The same UTXO-based note model handles both SNARK and STARK notes
• The same Merkle tree tracks all commitments
• The same ASP compliance layer covers both — every withdrawal and transfer through either system must include a proof of origin-address membership in an approved set
• The same pool contract handles deposits for both modes
• The same ragequit emergency exit path is available regardless of proof mode

What differs is the proving and verification stack. SNARK mode uses PLONK over BLS12-381, verified on-chain via EIP-2537 precompiles. STARK mode uses Circle STARKs built on the Stwo prover, verified via a custom native Solidity verifier.

Users choose a mode when they interact with the pool. They can hold funds in both simultaneously. Moving between modes is possible — withdraw from SNARK, deposit into STARK — without exposing intermediate amounts.

---

PLONK on BLS12-381: The Everyday System

Why BLS12-381, Not BN254

Every privacy protocol you've heard of — RAILGUN, 0xBow, earlier versions of Tornado Cash — uses BN254. It's the curve that Ethereum's built-in pairing precompiles were designed for, which made it the path of least resistance for early ZK development.

BN254 has roughly 100-bit classical security, below NIST recommendations and well below what institutional counterparties and compliance teams want to see in documentation.

BLS12-381 delivers 128-bit classical security — the standard used by AES-256-GCM, the same security level required for classified systems under NSA CNSA 2.0. The curve is already embedded in Ethereum's consensus layer (it's how validators sign attestations), and was brought to Ethereum L1 execution via EIP-2537, which activated in the Pectra upgrade in May 2025.

For a detailed comparison of the circuit migration from BN254, see our earlier post on migrating ZK circuits from BN254 to BLS12-381 PLONK.

PLONK and the Universal Trusted Setup

PLONK uses a universal trusted setup — specifically, the Hermez Powers of Tau ceremony, which involved thousands of independent participants. The setup is reusable across all circuits: you don't need a new ceremony each time a circuit changes. This is a significant operational advantage over Groth16, which requires a fresh per-circuit ceremony.

The setup creates a Structured Reference String (SRS) that both prover and verifier use. The security guarantee is that the setup cannot be backdoored unless every single participant in the Powers of Tau ceremony was compromised and they all colluded. In practice, that's treated as computationally infeasible.

EIP-2537: Native BLS12-381 Precompiles

The EIP-2537 precompiles that landed in Pectra expose three operations directly from the EVM:

• G1ADD (0x0B): Add two BLS12-381 G1 points
• G1MSM (0x0C): Multi-scalar multiplication on G1 — the expensive operation in PLONK verification
• PAIRING_CHECK (0x0F): Check a pairing equation — the core PLONK verification operation

Before Pectra, verifying a PLONK proof over BLS12-381 on-chain required implementing the entire pairing check in Solidity — which cost over a million gas. With the precompiles, verification drops to roughly 200–250K gas. That's competitive with — and in some configurations better than — BN254 PLONK.

Hash Function: Poseidon over BLS12-381

Inside the circuits, all hashing uses Poseidon over the BLS12-381 scalar field. Poseidon is an algebraic hash designed for ZK proofs — unlike Keccak, it maps naturally to arithmetic circuit constraints, keeping the proof small. The specific parameterization uses the BLS12-381 scalar field order:

$r = \texttt{0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001}$

Note commitments take the form Poseidon(amount, ownerHash, blinding, origin, token). Nullifiers take the form Poseidon(spendingSecret, leafIndex, commitment). Both constructions are hash-based and remain secure against quantum adversaries. The vulnerability in SNARK mode is entirely in the elliptic curve proof machinery, not in the note encoding.

Gas Breakdown: PLONK Verification

At 2026's typical 0.015 gwei base fee (ETH @ $2,500), that's roughly $0.0075 per verification — essentially free for routine transfers. Even during congestion spikes at 2 gwei, it's $0.50–1.00.

---

Circle STARKs: The Post-Quantum Vault

Why Circle STARKs?

The STARK verifier is built on Stwo, StarkWare's next-generation prover framework. Stwo represents the current state of the art in efficient STARK proving, with several architectural choices that matter for on-chain verification.

For the full technical documentation, see STARK Vault — Post-Quantum Analysis.

The Mersenne-31 Field

Stwo operates over $\mathbb{F}_p$ where $p = 2^{31} - 1$ — the Mersenne-31 prime. This is the largest Mersenne prime that fits in 31 bits.

Mersenne primes have a property that makes arithmetic extremely fast: modular reduction simplifies to a shift and add. For any product $x$ at most 62 bits:

$x \bmod (2^{31}-1) = (x \gg 31) + (x \mathbin{\&} (2^{31}-1))$

This is dramatically cheaper than general modular reduction with arbitrary primes. On hardware, M31 arithmetic runs without bignum operations: every multiplication fits in a single 64-bit word. The Stwo prover generates proofs in milliseconds for typical UPP circuit sizes.

The field arithmetic extends into a three-level tower for the verifier's cryptographic operations: M31 (base field) → CM31 (complex extension, $\mathbb{F}_{p^2}$) → QM31 (quartic extension, $\mathbb{F}_{p^4}$). QM31 is the "SecureField" used for all random challenges, drawn from a space of size $\sim 2^{124}$. For full details on the Solidity implementation of this tower, see Field Arithmetic: M31 → CM31 → QM31.

AIR Constraints and Circuits

STARK proofs encode computation as an Algebraic Intermediate Representation (AIR) — a set of polynomial constraints over a trace table. Each circuit type has a specific trace layout.

The constraints enforce note validity (correct commitment hash), nullifier uniqueness (prevent double-spend), Merkle inclusion (the note exists in the pool), balance conservation, and ASP membership (the origin address belongs to an approved compliance set).

FRI: The Polynomial Commitment Scheme

The heart of any STARK is the FRI protocol (Fast Reed-Solomon Interactive Oracle Proof of Proximity), which allows the prover to prove that committed polynomials have bounded degree without revealing them.

Circle FRI adapts standard FRI to the circle-group evaluation domain used by Stwo. The first fold is a "circle-to-line" fold: pairs of conjugate circle points $(x, y)$ and $(x, -y)$ are combined using the y-coordinate as a twiddle factor. Subsequent folds are standard line-to-line operations.

Our parameters: starting domain of size $2^7 = 128$, blowup factor $2^1 = 2$, three spot-check queries, five inner FRI layers. Full details at Circle FRI Protocol.

The FRI verification step dominates the overall gas cost — roughly 41% of the total ~20M gas — primarily from Merkle tree verification across all seven commitment layers.

Keccak Channel: 100x Cheaper Than Blake2s

Stwo's default Fiat-Shamir channel uses Blake2s-256. This is the right choice in a native environment, but on the EVM it's a catastrophe: Blake2s has no precompile, and pure-Solidity implementation costs 3,000–5,000 gas per hash call. With hundreds of hash calls per verification, that's millions of additional gas.

We replaced Blake2s with Keccak-256. The EVM's native keccak256 opcode costs approximately 30 gas per 32 bytes — roughly 100 times cheaper.

Stwo's Channel and MerkleChannel traits are generic over the hash function, making this substitution clean: we implemented KeccakMerkleChannel in Rust, which drives the prover, and KeccakChannel.sol, which drives the on-chain verifier. The Fiat-Shamir security guarantee is unchanged — collision resistance and random oracle behavior are the only properties required, and Keccak-256 provides both at the same 128-bit level as Blake2s-256.

For the full serialization format and channel replay protocol, see Keccak Channel & Proof Serialization.

The On-Chain Verifier: 7 Solidity Libraries

Rather than routing verification through a centralized relayer or waiting for EVM precompiles, we built and deployed the first Circle STARK verifier written entirely in Solidity on Ethereum mainnet. It comprises seven libraries totaling approximately 1,900 lines:

The verifier is parameterized at deployment: trace width, multi-mask column indices, and OOD value counts are set in the constructor and inlined as immutables. This means the same CircleStarkVerifier contract pattern covers both the withdraw and transfer circuits without code duplication.

Why STARKs Cost 20M Gas (And Why That Will Change)

The ~20M gas figure is not an inherent property of STARKs. It's a consequence of missing EVM precompiles. The PLONK verifier costs ~200K gas precisely because EIP-2537 gives it native precompiles for G1ADD, G1MSM, and PAIRING_CHECK. The STARK verifier must do all its field arithmetic, Merkle hashing, and FRI folding in pure Solidity, paying EVM interpretation overhead on every operation.

Multiple EIPs that would directly reduce on-chain STARK verification costs are in draft or research stages:

• EIP-7885 (NTT precompile) — adds native Number Theoretic Transform operations, the core primitive for polynomial multiplication in STARK's FRI protocol. Already tested on the ETH2030 experimental devnet at precompile address 0x15.
• EIP-6690 (EVMMAX) — adds optimized modular arithmetic opcodes supporting arbitrary field moduli up to 4096 bits. This would enable native M31 and Goldilocks field arithmetic instead of the pure-Solidity implementation we use today.
• EIP-5988 (Poseidon precompile) — authored by StarkWare's Abdelhamid Bakhta and Eli Ben Sasson. Currently stagnant pending the Ethereum Foundation's Poseidon Cryptanalysis Initiative (results expected through December 2026).
• Vectorized math precompile — proposed by Vitalik as "the GPU for the EVM," enabling 32-bit or 64-bit vectorized operations that could accelerate cryptographic workloads by 8-64x.

The Ethereum Foundation's post-quantum strawmap — published in February 2026 and covering seven hardforks through 2029 — targets progressive deployment of post-quantum signature precompiles (fork "J*", ~2027) and STARK-based consensus aggregation (fork "L*", ~2028). The direction is clear: Ethereum is moving toward STARK-friendliness at the protocol level.

If even a subset of these precompiles lands, STARK verification gas drops by 1-2 orders of magnitude, potentially bringing it into the same range as PLONK.

This is why UPP's architecture uses upgradeable verifiers. The pool contract delegates proof verification to a verifier contract that can be upgraded via governance. When STARK precompiles ship, we swap in a precompile-backed verifier. The pool contract, the note model, the compliance layer, and the user's funds remain untouched. Only the verification backend changes.

This is the same pattern that made PLONK viable: before EIP-2537 (Pectra, May 2025), BLS12-381 pairing verification in pure Solidity cost over 1M gas. After the precompile, it dropped to ~200K. STARKs are on the same trajectory, just earlier in the cycle.

Why STARKs Are Post-Quantum

The security of STARKs reduces entirely to the collision resistance of the hash function used in the Fiat-Shamir channel and the Merkle trees. There are no elliptic curves. No pairings. No discrete logarithm assumptions.

Shor's algorithm (the quantum algorithm that threatens SNARKs) gives no speedup against hash functions. It targets number-theoretic problems like factoring and discrete logarithm, where there's algebraic structure to exploit.

Grover's algorithm does apply to hash functions, but only gives a quadratic speedup. If you're using a 256-bit hash, Grover reduces effective security from 256 bits to 128 bits. That's still 128-bit quantum security — the same security level required by AES-128 and considered adequate by NIST for data classified at the SECRET level through 2031 at minimum.

For a complete analysis of which UPP components are quantum-vulnerable and which are not, see Post-Quantum Analysis.

---

The "Harvest Now, Decrypt Later" Threat

Here's the specific property that makes quantum risk uniquely dangerous for long-term privacy positions.

On a normal public blockchain, transaction data is visible immediately. There's no delayed decryption risk because there's nothing to decrypt.

On a privacy protocol, the data exists but is encrypted or zero-knowledge protected. From an adversary's perspective, the correct strategy is to record everything now and decrypt when the cryptographic assumptions break.

This is called "harvest now, decrypt later" (HNDL). It's not a hypothetical adversary capability; it's an acknowledged operational strategy by intelligence agencies including the NSA.

The blockchain version of HNDL has two distinct attack surfaces:

Attack 1: Proof forgery. When quantum computers can solve the discrete logarithm problem on BLS12-381 (or BN254, or any elliptic curve), they can forge SNARK proofs. This enables double-spending: an attacker could create a valid-looking proof for a note that doesn't exist, or spend a note they don't own. For any shielded pool that uses pairing-based SNARKs, this is an existential integrity failure.

Attack 2: Note decryption. When ECDH-derived shared secrets become computable from public ephemeral keys (which are stored permanently on-chain), every private note ever created becomes readable. Sender, recipient, amount — all exposed. For a position held for years in a privacy pool, every historical rebalancing, every exit, every counterparty — retroactively transparent.

STARK mode is immune to both attacks. There are no elliptic curve secrets to compute and no pairing assumptions to break. The proof remains sound against a quantum adversary. The note encryption can be upgraded to post-quantum key exchange independently (a planned future phase), but the proof system itself is already safe.

For a detailed timeline analysis of when quantum computers might reach the necessary scale, see our earlier post Q-Day Is Closer Than You Think.

---

When Are STARKs Worth the Gas Premium?

The 100x gas premium is worth it when the quantum risk premium exceeds the verification cost. For retail payments, that's never. For institutional positions held for years, it's already the case.

Let's put numbers on the tradeoff. Ethereum gas prices dropped significantly in 2026, so the economics are more favorable than they were a year ago. Here are both scenarios:

(Assuming ETH @ $2,500)

The ratio is always 100x. But the absolute numbers matter: at typical 2026 gas prices, STARK verification costs less than a dollar. Even during congestion, it stays under $100. The question is which scenario to plan for.

Retail payment scenario: You're transferring $200 in USDC privately. At typical gas, PLONK costs less than a penny. The quantum threat horizon is effectively zero — the transaction will be economically irrelevant long before quantum computers arrive. Use PLONK.

Long-term institutional position: A fund is holding $5 million in a privacy pool for 36 months. Even at worst-case congestion, the $100 STARK verification fee is 0.002% of position value — trivially small. At typical gas, it's $0.75. The quantum risk over that 36-month window is not zero. HNDL exposure to a state-level adversary over three years for a multi-million dollar position is a real and material risk. Use Circle STARK.

The breakeven intuition: If the quantum risk premium (expected loss from retroactive exposure, probability-weighted) exceeds the gas premium, use STARK. At 2026's low gas prices, the gas premium for STARK is so small that the decision is almost always "use STARK if you're holding for more than a few months." The dual-system architecture lets each user make their own tradeoff based on their actual gas conditions and holding period.

STARK costs will continue to decrease. Three vectors:

1. L2 execution: On Ethereum L2s, 20M gas translates to a fraction of the L1 cost. A Rollup with 100x compression makes STARK verification essentially free.
2. Proof aggregation: Multiple STARK proofs can be batched and verified together, amortizing the fixed verification cost across many transactions.
3. STARK-friendly precompiles: EIP-7885 (NTT), EIP-6690 (modular arithmetic), and Vitalik's vectorized math proposal would each shave significant gas off STARK verification. The EF's seven-fork strawmap through 2029 has STARK-friendliness as a core theme. UPP's upgradeable verifiers are designed to adopt these precompiles the moment they ship.

The 100x ratio is a constant of the architecture. The absolute dollar cost depends on Ethereum's gas market, and that market is trending strongly in STARK's favor.

---

How Do Users Choose Between SNARK and STARK?

A simple toggle in the UI. No cryptography knowledge required. From the user's perspective, the dual proof system surfaces as a mode choice.

The UPP interface presents two distinct balance displays: your SNARK pool balance and your STARK vault balance. Both show the same token denominations. Both are accessible from the same wallet. Neither requires understanding the underlying cryptography.

When you shield tokens, you choose which mode to deposit into. The modal presents both options with a plain-language explanation: SNARK mode is cheaper and suitable for everyday transfers; STARK mode costs more but protects against future quantum exposure.

When you transfer or withdraw, you use whichever pool your note is in. There's no need to be in the same mode as your counterparty — notes in different modes don't interact directly, but both modes support the same token set.

Moving between modes is straightforward: withdraw from SNARK (revealing nothing except that some amount left the SNARK pool), then deposit into STARK. The intermediate step is a public deposit, but amounts and origin can be obscured through standard multi-hop patterns if needed.

The ASP compliance layer is identical in both modes. Every transfer and withdrawal — regardless of proof system — requires demonstrating that the note's origin address belongs to an approved compliance set. Compliance is a property of the pool, not of the proof system.

---

Side-by-Side Comparison

Both systems share: the same UTXO note model, the same ASP compliance layer, the same Merkle tree, the same ragequit mechanism, and the same pool contract.

---

What Other Protocols Do

None of the major privacy protocols on Ethereum currently offer a post-quantum option.

RAILGUN uses Groth16 over BN254. This is roughly 100-bit classical security (below NIST recommendations) and provides no post-quantum protection. RAILGUN's compliance mechanism (PPOI) is wallet-level, not contract-level. There is no STARK mode or post-quantum roadmap published.

0xBow uses Groth16 over BN254. Same cryptographic profile as RAILGUN. No post-quantum option.

Aztec uses PLONK variants (Honk, CHONK) across its L2 stack. These are more efficient than Groth16 and support universal trusted setups, but are still curve-based and provide no post-quantum security. Aztec is building an entirely new execution environment, not a pool on Ethereum L1.

Polygon Miden uses STARKs (via Miden VM), which makes it post-quantum secure. But Miden is a new L2 with its own VM and execution environment, not a privacy pool you can add to an existing Ethereum workflow. Users would need to bridge assets, use a different execution model, and accept Miden's trust assumptions separately from Ethereum L1.

Zcash Orchard uses Halo 2 — a recursive SNARK that eliminates the per-circuit trusted setup via an accumulator scheme. This is a real improvement over Groth16, but Halo 2 is still based on the Pallas/Vesta elliptic curve pair. These curves face the same quantum threat as BN254 and BLS12-381. No trusted setup is not the same as post-quantum.

At a glance:

The dual-system architecture in UPP is, to our knowledge, the first attempt to offer both pairing-based and hash-based proof systems in the same pool, with the same compliance layer and the same note model, as a permanent coexistent design rather than a migration path.

---

Conclusion: SNARK and STARK

The framing of "SNARK vs STARK" treats them as competitors. They're not. They solve different problems for different threat models.

For a $100 private payment, spending 100x more gas on STARK verification is unnecessary (even though at 2026's low gas prices, both are cheap). For a $5 million institutional privacy position with a 3-year hold, PLONK's quantum exposure is irresponsible. Forcing users into one answer imposes the wrong tradeoff on every transaction that doesn't fit the assumption.

The honest architecture offers both. Users who want cheap, fast, private everyday transactions get PLONK on BLS12-381 — 128-bit classical security, EIP-2537 native verification, Universal trusted setup. Users who need long-term quantum-resistant storage get Circle STARKs — Stwo prover, Mersenne-31 field, Keccak-based Fiat-Shamir, native Solidity verifier, no elliptic curves anywhere.

The same compliance layer covers both. The same pool holds both. There's no migration, no breaking change, no forced choice.

If quantum computers arrive in 2032, the STARK vault positions are safe. The SNARK transfers made for coffee payments in 2027 are retroactively transparent — but that was always the acceptable tradeoff for those transactions.

The question isn't which proof system to use. It's which one is right for this transaction.

---

Frequently Asked Questions

Can I move funds between SNARK and STARK mode?

Yes. Withdraw from one mode (which settles on-chain), then deposit into the other. The intermediate step is a public deposit, but the amounts leaving and entering the pool are not linked unless an observer correlates them. Standard multi-hop patterns can obscure this further.

Are STARKs always more expensive than SNARKs?

Always 100x more gas today, yes — but that's because STARK verification runs in pure Solidity without precompiles, while PLONK benefits from native EIP-2537 precompiles. At 2026's typical 0.015 gwei base fee, STARK verification already costs under $1. When STARK precompiles land, the gap narrows dramatically. UPP uses upgradeable verifiers specifically so it can swap in precompile-backed verification without any migration or fund movement.

What happens if quantum computers arrive before I withdraw from SNARK mode?

Your SNARK-mode notes become vulnerable to proof forgery (someone could forge a proof to steal them) and retroactive decryption (anyone who recorded the encrypted on-chain data could read the transaction details). This is why STARK mode exists for long-term holdings. The decision of which mode to use should reflect how long you expect to hold the position.

Do both modes use the same compliance layer?

Yes. The ASP compliance system is proof-system-agnostic. Every withdrawal and transfer, regardless of whether it uses PLONK or Circle STARK, must include a valid ASP membership proof. The ragequit mechanism also works identically in both modes.

Why not wait for STARK precompiles instead of building a Solidity verifier?

We deployed the first Circle STARK verifier in pure Solidity on Ethereum mainnet because waiting is not a strategy. The verifier works today. When precompiles ship, UPP's upgradeable verifier architecture lets us swap in a precompile-backed implementation without touching the pool, user funds, or compliance layer. We get post-quantum security now and cheaper verification later — instead of neither.

---

This is pre-audit software deployed on Sepolia testnet. All gas figures are estimates based on current Ethereum mainnet conditions and may vary. Nothing here is financial or security advice.

Explore the technical documentation: STARK Vault overview, Post-Quantum Analysis, Field Arithmetic, FRI Protocol, Keccak Channel. For questions or to discuss integration, reach out to the Permissionless Technologies team.