Solana Activates BN254, BLS12-381, and ZK ElGamal: Three Cryptographic Primitives Now Live

Three cryptographic primitives are now active on Solana SOL$73.48-1.0%'s mainnet. BN254 G2 went live at epoch 985, BLS12-381 followed at epoch 986, and the ZK ElGamal Proof Program has been re-enabled after spending more than a year offline following a security disclosure. Developer educator @SolPlay_jonas published a detailed walkthrough covering all three with live on-chain demos, calling the combination the start of Solana's "privacy arc."

Anza's Agave 4.0 delivered all three features. The Solana Foundation's crypto-primitives-examples repository provides runnable code for each primitive alongside interactive demos.

BN254 and Native Groth16 ZK-SNARK Verification on Solana

BN254, also called alt_bn128, is the elliptic curve that powers Groth16, the most widely deployed zero-knowledge proof system in production. Ethereum added BN254 support at the protocol level via EIP-196 and EIP-197 in 2017. Solana now has it natively.

SIMD-0302 adds the full G2 arithmetic layer: point addition, subtraction, scalar multiplication, and pairing checks. These operations are what Groth16 batch verification requires. Programs running on Solana can now verify Groth16 proofs entirely on-chain, without off-chain preprocessing or external coprocessors.

The most immediate practical benefit is cross-chain compatibility. ZK light clients and ZK bridges built against Ethereum's proof format can now settle on Solana using the same curve. Developers writing Groth16 circuits with tooling like gnark, snarkjs, or Circom can port that work to Solana without switching proof systems. BN254 provides approximately 100-bit security, sufficient for current ZK applications.

BLS12-381: Signature Aggregation, 128-Bit Security, and Alpenglow's Validator Infrastructure

BLS12-381 is a more recent pairing-friendly curve targeting 128-bit security. It is the curve behind Ethereum 2.0's validator signatures, and is used broadly in modern consensus protocols. SIMD-0388 brings native BLS12-381 syscalls to Solana, covering G1 and G2 operations: point addition, subtraction, scalar multiplication, validation, pairing, and decompression.

The most direct application is BLS signature aggregation. Rather than verifying N signatures separately, BLS aggregation compresses all N into a single combined signature verifiable in one step. Multi-party governance contracts, on-chain multisigs, and threshold credential schemes all become significantly cheaper as a result.

The deeper integration is with Alpenglow, Solana's next-generation consensus protocol. Validators registering BLS public keys for Alpenglow must supply a Proof of Possession, a cryptographic proof that they control the private key corresponding to a registered public key, to prevent rogue-key attacks. BLS12-381 syscalls make verifying those proofs possible inside BPF programs. Agave 4.0 introduced the Alpenglow infrastructure; full mainnet deployment was targeting Q3 2026 per Helius' release overview.

ZK ElGamal: Confidential Token Balances Without Revealing Amounts

The ZK ElGamal Proof Program has a narrower scope than the two curve libraries above. It is a native Solana program built for one job: verifying zero-knowledge proofs about encrypted token balances.

The program uses ElGamal encryption, a public-key scheme that lets users encrypt their token balances and then prove properties about those values without decryption. Supported proof types include Pubkey Validity (confirming a well-formed public key), Zero Ciphertext (proving a ciphertext encrypts zero), Equality Proofs (confirming two ciphertexts hold the same value), and Range Proofs (confirming an encrypted balance fits within a valid 64-bit unsigned range via Pedersen commitments).

These are the verification primitives that power Token-2022's Confidential Transfer extension. When confidential transfers are active on a token, observers can see that a transaction occurred but cannot read the amounts or resulting balances. The ZK ElGamal program verifies that the transfer is mathematically valid without exposing the underlying numbers.

The program was disabled at the start of epoch 805, June 19, 2025, after a researcher disclosed a flaw in the proof verification logic. A full post-mortem published by the Solana Foundation detailed the issue: a missing component in a hash function. No exploit occurred, and no real value was at risk, since no major token issuer had activated confidential transfers for live users at the time. Re-enablement followed a complete audit and was shipped as part of Agave 4.0.

What Developers Can Build With Solana's New Cryptographic Stack

The three primitives address different layers of what ZK-heavy application development requires.

ZK applications built against the standard Ethereum toolchain can now verify Groth16 proofs directly on Solana via BN254. Confidential DeFi becomes possible at the token level through ZK ElGamal: balances stay encrypted while on-chain programs confirm transfers are valid. ZK bridges between Solana and Ethereum rollups gain a shared curve for proof settlement on both sides. BLS12-381 enables efficient on-chain multisig and threshold schemes for governance programs, with particular relevance to Alpenglow's validator registration process.

The crypto-primitives-examples repository also includes interactive demos for each primitive: a BLS multisig implementation using BN254, an aggregate-key registry with BLS12-381, and private ballot elections using ZK ElGamal's homomorphic summation. The code is explicitly marked as educational and unaudited, not a production library.

A fourth primitive, SHA-512 (SIMD-0512), is proposed but not yet activated on any cluster.