Poseidon, by hand and by code

Why one of the cheapest hashes in zero-knowledge cryptography also has the strangest insides. Derive the S-box, count the constraints, and run a 30-line implementation in the browser.

A SHA-256 of “abc” inside a SNARK takes about 24,000 R1CS constraints. The same input through Poseidon — properly parameterised — takes about 250.

Two orders of magnitude. That ratio is the entire reason ZERA’s unified shielded pool ships with consumer-grade UX in 2026. It’s also the reason every modern ZK system you can name uses Poseidon, Rescue, or one of their cousins instead of something the cryptographic community has been beating on for twenty years.

This post is the long answer to why.

The problem with hashing inside a SNARK

A zero-knowledge SNARK proves you know a witness $w$ such that $C(w) = 0$ for some arithmetic circuit $C$ over a prime field $\mathbb{F}_p$ . Every operation in $C$ becomes a constraint, and proof time scales roughly linearly with the number of constraints.

The trouble with SHA-256 is that it was designed for CPU efficiency, not arithmetic-circuit efficiency. Its building blocks — XOR, AND, bitwise rotation — are cheap on a CPU and catastrophically expensive in $\mathbb{F}_p$ . A single XOR over 32-bit words requires unpacking each word into 32 individual binary constraints, doing the XOR bit-by-bit, then packing back. SHA-256 has 64 rounds of mixing, and every round does several of these.

The constraint cost looks roughly like:

\text{cost}_{\text{SHA-256 in SNARK}} \approx 64 \times (k_{\text{xor}} + k_{\text{and}} + k_{\text{rot}}) \times w

where $w = 32$ bits and the per-operation constants $k$ run between 30 and 100. You end up north of 25k constraints for a 64-byte input — and that’s just the hash. A real circuit has dozens of these per spend.

This is the gap that hash-friendly arithmetisation closes.

Poseidon’s design: only field operations, all the way down

Grassi, Khovratovich, Rechberger, Roy, and Schofnegger (2021) had a different idea: design the hash natively in $\mathbb{F}_p$ . No bits. No bytes. Just field elements all the way down.

Poseidon is a permutation-based sponge. The state is $t$ field elements — typically $t = 3$ for hashing two-to-one (input $|$ input $\to$ output) and $t = 5$ for absorbing three field elements at once. The permutation alternates two kinds of rounds:

Full rounds apply an S-box to every state element, then mix.
Partial rounds apply an S-box to one state element, then mix.

The S-box is the simplest possible non-linear function over a prime field:

S(x) = x^\alpha

with $\alpha$ chosen as the smallest exponent for which $\gcd(\alpha, p - 1) = 1$ (so the map is a bijection). For BN254 — the curve underlying most production ZK pairings, including the one ZERA’s SDK uses — $p - 1$ is divisible by 2 and 3, so $\alpha = 5$ is the smallest legal exponent. Poseidon over BN254 ships with $\alpha = 5$ .

The full permutation is:

flowchart LR
S[State t elems] --> AC1[+ round constants]
AC1 --> SB1[S-box: x^5 on all elems]
SB1 --> M1[MDS matrix mix]
M1 --> N{round full or partial?}
N -->|full| AC2[+ round constants]
N -->|partial| AC3[+ round constants]
AC2 --> SB2[S-box on all]
AC3 --> SB3[S-box on first elem only]
SB2 --> M2[MDS mix]
SB3 --> M2
M2 --> O[output state]

Three primitives, repeated $R_F + R_P$ times: add round constants ⊕ S-box ⊕ MDS matrix multiplication.

That’s the whole algorithm.

Counting the constraints

This is where the order-of-magnitude advantage shows up.

Each S-box is $x^5 = x^2 \cdot x^2 \cdot x$ . In R1CS that’s three multiplication constraints (one for $x^2$ , one for $x^4 = x^2 \cdot x^2$ , one for $x^4 \cdot x = x^5$ ). The MDS matrix is a fixed $t \times t$ matrix of constants applied to the state — that’s free in R1CS because constant multiplications fold into linear combinations and don’t generate constraints.

So per round:

\text{cost}_{\text{full round}} = 3t, \quad \text{cost}_{\text{partial round}} = 3

Recommended parameters for BN254 with $t = 3$ (hashing two field elements) are $R_F = 8$ full rounds and $R_P = 57$ partial rounds. Total constraint count:

8 \cdot (3 \cdot 3) + 57 \cdot 3 = 72 + 171 = 243

Two hundred and forty-three constraints. For a hash of two field elements (~64 bytes of payload). SHA-256 was 24,000+ for a similar payload. That ratio — about 100× — is the entire ball game.

Option	Cost	Latency	Blast radius	Notes
SHA-256 (in-circuit)	~24,000 constraints / 64-byte input	Fast on CPU; brutal in SNARKs	Standard; battle-tested	Designed for hardware, not for finite fields
Poseidon-128, t=3, α=5 (BN254)	~243 constraints / 2 field elements	Slow on CPU vs SHA; fast in SNARKs	Younger primitive; growing analysis	Designed for SNARKs first; the standard since 2020
Rescue-Prime	~150 constraints / 2 field elements	Slightly fewer constraints than Poseidon	Less peer review than Poseidon	Closer to a research curiosity in 2026
Anemoi	~120 constraints / 2 field elements	Newest; lowest constraint count	Very young; minimal cryptanalysis	Promising but I would not bet a production pool on it yet

The blast-radius column is doing real work. Poseidon’s the one I’m comfortable shipping in zera-sdk right now. Rescue and Anemoi are interesting but the cryptanalysis hasn’t caught up to the deployment.

A 30-line Poseidon you can run in the browser

Here’s a complete, working Poseidon-128 over BN254, written in TypeScript with bigint arithmetic. It’s not optimised — production code uses Montgomery form, precomputes S-box squares, and uses constant-time field arithmetic — but it’s correct and small enough to read in one sitting.

sandbox [ vanilla-ts ]

run

Runnable playground (requires JavaScript)

/index.ts

// Poseidon-128 over BN254, t=3, alpha=5.
// Reference: https://eprint.iacr.org/2019/458
// Production: use circomlibjs.poseidon or zera-sdk's neon-rs Rust core.

const P = 21888242871839275222246405745257275088548364400416034343698204186575808495617n;
const T = 3;
const RF = 8;   // full rounds (split as RF/2 at start, RF/2 at end)
const RP = 57;  // partial rounds in the middle

// In production these would be CRH-extracted from a sponge of the spec.
// For demo: deterministic round constants and a known-good MDS matrix.
const round_constants = Array.from({ length: (RF + RP) * T }, (_, i) =>
BigInt(i + 1) * 3141592653589793238n % P
);
const mds: bigint[][] = [
[2n, 3n, 1n],
[1n, 5n, 1n],
[5n, 7n, 1n],
];

function add(a: bigint, b: bigint) { return (a + b) % P; }
function mul(a: bigint, b: bigint) { return (a * b) % P; }
function pow5(x: bigint) {
const x2 = mul(x, x);
const x4 = mul(x2, x2);
return mul(x4, x);
}

function permute(state: bigint[]): bigint[] {
let s = state.slice();
let rcIdx = 0;

const half = RF / 2;
// first half of full rounds
for (let r = 0; r < half; r++) {
  s = s.map((v) => add(v, round_constants[rcIdx++]));
  s = s.map(pow5);
  s = mds.map((row) => row.reduce((acc, m, j) => add(acc, mul(m, s[j])), 0n));
}
// partial rounds
for (let r = 0; r < RP; r++) {
  s = s.map((v, i) => i === 0 ? add(v, round_constants[rcIdx++]) : v);
  rcIdx += T - 1;  // skip constants for non-first elements
  s[0] = pow5(s[0]);
  s = mds.map((row) => row.reduce((acc, m, j) => add(acc, mul(m, s[j])), 0n));
}
// second half of full rounds
for (let r = 0; r < half; r++) {
  s = s.map((v) => add(v, round_constants[rcIdx++]));
  s = s.map(pow5);
  s = mds.map((row) => row.reduce((acc, m, j) => add(acc, mul(m, s[j])), 0n));
}
return s;
}

export function poseidon2(left: bigint, right: bigint): bigint {
const state = [0n, left % P, right % P];
return permute(state)[0];
}

// demo: hash two field elements
const a = 13n;
const b = 27n;
const h = poseidon2(a, b);
const out = document.getElementById("out")!;
out.textContent = `poseidon(${a}, ${b}) = ${h}`;

/index.html

<!DOCTYPE html>
<html>
<body>
  <pre id="out" style="font-family: 'Geist Mono', ui-monospace, monospace; padding: 1rem; background: #0a0a0a; color: #4ade80;">running...</pre>
  <script type="module" src="/index.ts"></script>
</body>
</html>

Open the vanilla-ts template on codesandbox.io

The thing that’s striking when you write this out is how little there is. A SHA-256 implementation is hundreds of lines of bit-twiddling. Poseidon is essentially: add a constant, raise to the fifth power, multiply by a fixed matrix, repeat.

Why $\alpha = 5$ specifically

The S-box choice is the most-questioned part of Poseidon. Why not $\alpha = 3$ ? Or $\alpha = 7$ ?

Two constraints:

Bijection. $x \mapsto x^\alpha$ is a permutation of $\mathbb{F}_p$ if and only if $\gcd(\alpha, p - 1) = 1$ . For BN254, $p - 1 = 2^{28} \cdot 3 \cdot \text{(other stuff)}$ , so $\alpha \in \{2, 3, 4\}$ all share a factor with $p - 1$ and produce non-bijective maps. The smallest $\alpha$ that works is 5.
Algebraic degree. The whole point of the S-box is to introduce algebraic non-linearity that defeats interpolation attacks. Higher $\alpha$ → more non-linearity → fewer rounds needed. So you want $\alpha$ small enough to be cheap, large enough to need few rounds.

For curves where $\gcd(3, p-1) = 1$ (like BLS12-381), the choice flips to $\alpha = 3$ and the round count drops because each S-box is more powerful. The trade-off is: cheaper per-round but more rounds.

The choice of $\alpha = 5$ for the prime field of BN254 is dictated by the requirement that the S-box must be a permutation: it must hold that $\gcd(\alpha, p-1) = 1$ . The next constraint — the one that determines round counts — is the algebraic degree.

Grassi, Khovratovich, Rechberger, Roy, Schofnegger ↗ source

What I would change in a v2

Three things, if I were re-designing Poseidon for 2027:

Drop the partial-rounds split. The original design has 8 full + 57 partial rounds; the partial rounds save a lot of constraints but make security analysis harder. Poseidon2 (Grassi, Khovratovich, Roy 2023) keeps a similar structure with cleaner analysis. I’d ship Poseidon2 by default in a fresh deployment.
Make the MDS matrix circulant. A circulant MDS — where each row is a rotation of the previous — has identical security properties but lets you exploit FFT-friendly arithmetic. Worth it on the prover side.
Standardise the parameter file format. Every implementation rolls its own format for round constants. The Circomlib JSON format works, but a CBOR or Cap’n Proto schema would let implementations cross-check parameters in a way that’s currently per-vendor. I keep the Circomlib JSON in zera-sdk because compatibility, not because it’s the right choice.

Where this goes in production

Inside zera-sdk the Poseidon implementation is crates/zera-sdk-core/src/hash/poseidon.rs. It’s about 200 lines of safe Rust, written against the ff crate for field arithmetic, with the round constants loaded from a JSON file extracted from Circomlib for cross-implementation parity.

rust playground [ rust ]

open

Runnable playground (requires JavaScript)

src/main.rs

// Skeleton of the production Poseidon-128 over BN254 (in zera-sdk-core)
// The actual implementation imports the constants from a build.rs-emitted
// JSON; this is the structural shape.

use std::ops::{Add, Mul};

#[derive(Clone, Copy, Debug)]
struct Fp(u128);  // toy stand-in; production uses ff::PrimeField

impl Add for Fp { type Output = Fp; fn add(self, o: Fp) -> Fp { Fp((self.0 + o.0) % MODULUS) } }
impl Mul for Fp { type Output = Fp; fn mul(self, o: Fp) -> Fp { Fp((self.0 * o.0) % MODULUS) } }

const MODULUS: u128 = 1_000_000_007; // toy
const T: usize = 3;
const RF: usize = 8;
const RP: usize = 57;

fn pow5(x: Fp) -> Fp { let x2 = x * x; let x4 = x2 * x2; x4 * x }

fn permute(mut state: [Fp; T], rc: &[Fp], mds: &[[Fp; T]; T]) -> [Fp; T] {
  let mut idx = 0;
  let half = RF / 2;
  for _ in 0..half {
      for s in state.iter_mut() { *s = *s + rc[idx]; idx += 1; }
      for s in state.iter_mut() { *s = pow5(*s); }
      state = mat_mul(mds, state);
  }
  for _ in 0..RP {
      state[0] = state[0] + rc[idx]; idx += T;
      state[0] = pow5(state[0]);
      state = mat_mul(mds, state);
  }
  for _ in 0..half {
      for s in state.iter_mut() { *s = *s + rc[idx]; idx += 1; }
      for s in state.iter_mut() { *s = pow5(*s); }
      state = mat_mul(mds, state);
  }
  state
}

fn mat_mul(m: &[[Fp; T]; T], v: [Fp; T]) -> [Fp; T] {
  let mut out = [Fp(0); T];
  for i in 0..T {
      for j in 0..T { out[i] = out[i] + m[i][j] * v[j]; }
  }
  out
}

fn main() { println!("see crates/zera-sdk-core/src/hash/poseidon.rs for the real thing"); }

Open this snippet on the Rust Playground