Solana just got new cryptographic tools
Across 2025 and 2026, four cryptographic features landed in the Solana runtime — one is still only a proposal. All of them exist to make calculations that were previously too expensive finish in an instant. Let's start with why they were needed.
You need to verify a document signed by 1,000 people. What's the cheapest way to do it on-chain?
Answer: B. Signatures and public keys can be added together, so you can collapse 1,000 of them into one and check it a single time. That's BLS aggregation. But without a way to run that addition on-chain, it stays theoretical — which is exactly what these new features changed.
Compute meter: hand-rolled vs syscall
Every Solana transaction has a ceiling on the compute (CU) it may spend. Run the same cryptographic operation two ways — written by hand inside your program, or called through a syscall the runtime provides — and watch the meters.
A syscall is a dedicated chip slotted into the runtime. The same operation costs orders of magnitude more when a program assembles it instruction by instruction than when the runtime runs an optimized implementation in one shot.
Where the four actually sit
These four are not siblings. Two on the left are compute chips for pairing curves (syscalls); the one on the right is a dedicated program that verifies proofs; below is an empty slot on the hash shelf. Getting this distinction straight is the map for every chapter that follows.
👆 Tap a chip or program to see what it does
Pick a part
The two on the left, the one on the right, and the shelf below all behave differently. Try them in order.
In one go: what is a pairing?
It's a machine: put in two points, get out one number. It has exactly one useful property — multiplying the left point or multiplying the right one gives you the same number either way. That unassuming property is, on its own, how you check whether a signature is real. Let's walk through it.
1Pick one secret number
You alone know this number. This is what 'multiply by' actually meant. From it, two things get built.
Signature
3 × the message point
the secret number applied to the message side
Public key
3 × the reference point
the secret number applied to the reference point (this one you hand out)
The same secret number, applied to two different partners — that's the whole trick
2Feed them in and see whether they balance
[signature] and [reference point] the secret number is applied on the left
3[message point] and [public key] the secret number is applied on the right
3Apply the secret on the left, or apply it on the right. Being able to move it freely between the two is what a pairing really is. Chapter 01 draws the same idea as a balance scale and goes a step further, alongside adding points and the one-way property.
So what was missing in 'G2 arithmetic'?
A pairing needs one point from each of two collections with different properties. Those two are G1 and G2. Solana could already do pairings and G1-side arithmetic — but it could not add points inside G2. Flip the switch and compare.
The G stands for Group. A group here just means a collection of points you can add together. The 1 and 2 are plain serial numbers: the first collection is G1, the second is G2. Both come from the same curve but behave differently, and a G2 point takes twice the bytes.
= the collection where signatures live
The lighter collection. Signatures can be added together into one.
This side was already available.
= the collection where public keys live
The heavier collection. If public keys can be added, everyone's folds into one.
Public keys couldn't be added together — so folding everyone into one was impossible.
What was missing wasn't pairing — it was addition on G2. Only once public keys can be folded does checking 1,000 people in a single verification become possible. Filling that gap is what makes chapter 02's multisig work.
When each became usable
New Solana features switch on through feature gates: at a chosen epoch (roughly a two-to-three-day window) they become active across the network at once.
Always separate what runs today from what doesn't. Throughout this site the three live features are green and the proposed SHA-512 is amber.
A world where you only add points
The secret number, the points, the multiplying — this chapter shows what they actually are. No formulas. Three things to take away: points can be added, repeated addition can't be undone, and that's why signatures collapse into one.
What 'adding points' actually means
An elliptic curve is the shape below. The points sitting on it have their own kind of addition — less like adding numbers, more like drawing lines with a ruler. Move the two points and watch where the answer appears.
Everything starts from that one fact: you can add. Signatures and public keys are nothing but points on this curve, so if points add, signatures and public keys add too. Folding a thousand of them into one, from chapter 00, is this addition repeated 999 times.
A public key is built as (secret number × reference point), and anyone can see it. Can you work back from a public key to the secret number?
Answer: B. There is no division in this world. To learn how many times something was added, you have to add one at a time until you match. The demo below lets you feel it.
Easy going out, impossible coming back
That smooth curve is a drawing device; real cryptography uses a blunter world — a fixed number of grid cells with points scattered across them. Start from the reference point and add one step at a time. Watch where you land.
times added
1
( — , — )
Shown only this landing spot, could you say how many times it was added?
This is why publishing the public key is safe. Going out (count → landing spot) is instant. Coming back (landing spot → count) is brute force only. So the public key can be handed around freely while the secret number stays home.
Three approvals, folded into one
Alice, Bob and Carol share control of a vault, and it should open only when all three approve — a multisig. The obvious approach attaches three signatures and checks three times. But points can be added, so there's a better way.
Two different things get added. ① the three public keys — registered in advance, defining who the members are — and ② the signatures actually submitted this time. Each side folds into one, and then a single check compares them.
From here on, these are the symbols
Chapters 02 through 05 draw the same idea the same way every time. Come back here whenever a picture is unclear.
Arrow
A point on the curve — what a signature or public key really is. Colour means whose it is.
Joining arrows
Addition. The end of the chain is the answer, and however many you join, there is one end.
Reversed arrow
Subtraction. The endpoint lands back exactly where it was. The star of chapter 03.
Balance scale
A pairing check. Level means genuine; tipped means forged.
Envelope
A ciphertext. It travels with nobody able to see inside. Chapter 04.
Stamp
A zero-knowledge proof — a mark saying 'the contents are valid' without opening the envelope.
Gate
A verifier program. Green when something passes, red when it's turned away.
Chip
A syscall — a dedicated computing unit slotted into the runtime.
Two curves, and how they differ
These are the curves chapters 02 and 03 use. Both support pairings, but they differ in security level and in which operations Solana exposes.
BN254
also called alt_bn128. Used in chapter 02
BLS12-381
the modern standard. Used in chapter 03
On to chapter 02. Using what you've seen here — points add, the chain has one end — we'll run a system that confirms everyone's approval with a single check.
Everyone's approval, checked once
This chapter runs chapter 01's 'points can be added' on Solana for real. Five members are registered, their signatures fold into one, and a single check confirms the approval — with the verdict landing on-chain.
Only one drawer was missing
Pairing checks and G1-side addition were already on Solana. What kept BLS multisig impractical was the one missing piece: addition on the G2 side, where public keys live. Slot in the last chip.
What arrived was not pairing. It was addition on the G2 side. Before it, this math had to be hand-written inside the program, which never fit a realistic budget. With one chip in place, the remaining pieces snap together at once.
In a five-member multisig, one member refuses to sign. What happens to the other four signatures?
Answer: B. A folded signature can't be taken apart to see whose signatures are inside. Unless it corresponds exactly to the five registered keys, the check simply doesn't balance. No partial credit — everyone or nobody.
Run the multisig
The five members are already registered on-chain. Choose who signs, then hit send. What happens in your browser and what happens on the chain are shown separately.
🖥 BROWSEROn your side: collect the signatures and fold them into one
⛓ ON-CHAINWhat the program does: fold the registered keys and check once
Key folded from registered members
the five stored on-chain — always the same
Key implied by the signature received
only those who signed — it shifts if anyone is missing
The program never counts who signed. It folds the registered keys, takes the key implied by the incoming signature, and checks once whether they balance. Five members or a thousand, it's still one check.
Registration is the fiddly part
Checking takes one step, but registering the members in the first place is different. A Solana transaction holds up to 1,232 bytes, and a G2 public key is 128 bytes — so roughly seven members fit per transaction. Try moving the count.
So what's the win?
Twenty approvers, done the obvious way and done by folding.
One at a time
Fold, then check once
On to chapter 03. Here every key had to be stored on-chain. Switching to BLS12-381 cuts that to a single stored item — and lets members come and go freely.
One point on the chain, and only one
Chapter 02 stored every member's key on-chain, so more members meant more storage. Switching to BLS12-381 reduces that to a single point — and makes members joining and leaving effortless. The key is subtraction.
All the keys are folded into one stored point, and now a member leaves. What do you do with that stored point?
Answer: B. Where there's addition there's subtraction — take the leaver's key back out and you're exactly where you'd be if they had never joined. You don't even need the other members' keys. That subtraction is precisely what BN254 didn't offer in chapter 02.
Members come and go, by adding and subtracting
Click a name to move that member in or out. Joining appends an arrow (addition); leaving appends a reversed one and the endpoint travels back (subtraction). Watch how the value stored on-chain changes on the right.
Current members 3
click to remove — that member's key is subtracted from the stored point
Outside
click to add — that member's key is added to the stored point
Chapter 02's approach
store every member's key, laid out side by side
—
The registry approach
store only the single folded result
192 bytes (constant, whatever the headcount)
Subtraction removes the need to remember. Even with no record of who joined, the leaver's key alone is enough to undo their contribution. So the chain keeps no history — just the one current point.
More members, same storage
A BLS12-381 G2 point is 192 bytes. Compare the on-chain space needed when you list every key against storing only the folded point.
Once you leave, you can't get through
The stored point represents exactly the current membership, so a check passes only when today's members all sign. A departed member's signature no longer balances anything. Try all three situations.
The stored point
the value representing today's members
Value implied by the signatures
depends on who actually signed
Chapter 02 and 03, side by side
Ch.02: multisig (BN254)
Ch.03: registry (BLS12-381)
🔗 Series link: this curve also underpins Alpenglow
Signature aggregation isn't the only reason BLS12-381 was introduced. The SIMD-0388 proposal states plainly that it also matters for enabling Alpenglow, Solana's next-generation consensus. Folding a great many validator votes into one — exactly the mechanism in this chapter — is what makes agreement itself faster.
On to chapter 04. Everything so far has been about confirming who approved. Next the flavour changes entirely: showing something is correct while revealing nothing. Not curves and scales, but envelopes and stamps.
Reveal nothing, prove it's correct
The flavour changes completely here. The question is no longer who approved something, but whether hidden contents are valid. Claims about what's inside the envelope get verified without ever opening it.
From here, a different world
Set down the tools from chapters 02 and 03. No curves, no balance scales. Different cryptography, and a different mechanism running it.
📐⚖️
The world of chapters 02–03
Pairing curves (BN254 / BLS12-381). Add points, check the scale for balance, call a computing unit slotted into the runtime.
✉️🖃
The world of chapter 04
ElGamal encryption over curve25519. Seal the contents in an envelope and stamp it to show it's valid, unopened. A dedicated program acts as the gate.
Can two numbers that are still sealed in envelopes (still encrypted) be added together without opening them?
Answer: B. ElGamal encryption has the property that adding two envelopes yields an envelope holding the sum. Individual ballots stay invisible while the total can still be extracted — a private ballot, straight out of the box.
Prove the comparison, hide the number
Pick a secret number, seal it, and prove to the chain only how it relates to a public number. On the left is what you see; on the right, what the chain sees. The same moment from two viewpoints.
Choose the claim to prove
🖥 What you can see
You know the secret, so the contents are visible
72
inside the envelope
50
the public number
🖃 Stamp created
—
⛓ What the chain can see
Only the envelope and the stamp. The contents never appear
? ? ?
—
50
the public number
🖃 Stamp
—
—
—
Count the votes without opening them
Five people seal a yes (1) or no (0) into an envelope. The envelopes are added while still sealed, and the only thing opened at the end is the total. Who voted what stays unknown throughout.
What is a range proof? It shows, without revealing the contents, only that what's inside falls within an agreed range — here, that it's a 0 or a 1. Without it, someone could exploit the secrecy and write 100 to inflate their vote.
What does batched mean? Five voters' proofs collapse into a single stamp. Inspecting one stamp once is far cheaper than inspecting five separately.
Proving one by one
🖃🖃🖃🖃🖃
five stamps to inspect
Batched together
🖃
one stamp covers all five
🖃 One stamp covering all five — 'every envelope holds a 0 or a 1'
batched range proof / about 111,000 CU
Waiting for the vote to close
Close the vote and the gate inspects everything
Where this actually gets used
The biggest destination for this machinery is Token-2022 confidential transfers. Balances and amounts stay encrypted while the chain confirms only the conditions — that the balance suffices, that what was sent equals what was received.
On to chapter 05. All three so far are already running. Last comes the one that isn't — SHA-512 — along with the whole picture in one place.
One seat, still empty
All three so far already run on mainnet. SHA-512, the last one here, is still a proposal. What's being proposed, why people want it — and then the whole picture in one place.
Remind me — what's a hash?
Feed in text of any length and a fixed-length string comes out. That's a hash. Type something below: change a single character and the result becomes something entirely different. Your browser computes these for real.
—
—
Programs cannot call SHA-512 yet. But is the SHA-512 implementation itself already inside today’s validators?
Answer: B. SHA-512 is built into the procedure for verifying Ed25519 signatures, which every Solana transaction uses. So Agave and Firedancer have carried the implementation all along. What is missing is the door — no entry point exists for programs to call it.
Who checks that signature?
Two kinds of signature flow through Solana. One the runtime checks automatically; to the runtime the other is just data, and it passes straight through. Press a button and watch where inspection happens.
Three ways to check it yourself
To verify signature ②, a program has these three options. Ways 1 and 2 are what people actually use today; way 3 is a proposal that is not available yet. Switch tabs to compare them.
So the proposal is: just add a door
SHA-512 has long been inside both Agave and Firedancer, because verifying Ed25519 requires it. Nothing new gets built. The only missing piece is an entrance for programs to call it through.
Hash implementations inside a validator
sha256
🚪 callable from programs
keccak256
🚪 callable from programs
blake3
🚪 callable from programs
sha512
🔒 present, but not callable
in use for Ed25519 verification
One SHA-512 hash, computed by a program
The way you call it is exactly the same shape as the existing ones — hand over data, get back a fixed-length answer
Where the four stand
Press a card to jump back to that chapter.
SHA-512
Proposed. Inside the validator already, but not yet reachable
covered in this chapterSo how cheap is all this?
Every compute figure from this site, side by side. The range is far too wide for a plain scale, so start with a logarithmic one. Switch to 'true proportion' to see how small they all are against the per-transaction ceiling.
This is what 'new tools arrived' actually means. Back when this math had to be hand-written inside a program, none of it fit under the ceiling. Being able to call the runtime's own implementation changed the order of magnitude outright.
That's a wrap
Points can be added, addition can't be undone, and envelopes add up unopened — take those three away and you have the gist. When you want to get hands-on, the official demo and source are below.