membership policy · simplest of five

Seven primitives. One contract. Any current member admits.

sep-anarchy is the simplest of the deployment's five membership-policy contracts: a single PLONK circuit whose policy predicate is “the witness opens some leaf in the current group commitment”. No quorum, no founder set, no admin. Any current member is sufficient to authorise an admission, and the R_Upd circuit is the smallest in the family.

The contract is not a new cryptographic primitive. It rests on a stack of six existing ones — BLS12-381 at the base, KZG and Poseidon2 above it, Merkle and Fiat-Shamir above those, PLONK across the top, and the policy contract as a keystone. This page traces that stack, brick by brick.

BLS12-381· KZG· Poseidon2· Merkle· Fiat-Shamir· PLONK sep-anarchy
sep-anarchy
policy tag
~700 B
proof size
1 pairing
on-chain
1 entry
per admission
~$0.005
per admission

the wall

Bricks are primitives. The keystone is the policy.

Hover any brick to light up the dependencies it transitively requires. Hover the keystone — the sep-anarchy contract — to light up the entire closure. Click any brick for a tooltip card and a link to its primitive sheet.

BLS12-381 pairing-friendly curve · foundation · ~128-bit · broken under Shor KZG polynomial commitments · 48 B · d-SBDH on BLS12-381 Poseidon2 algebraic hash over F_r · ~50–300 constraints / call Merkle tree group commitment C_g · O(log n) sibling path Fiat-Shamir transcript hash via Poseidon2 · soundness in ROM PLONK universal-updatable SNARK · ~700 B proof · single-pairing verifier POLICY · KEYSTONE sep-anarchy R4 R3 R2 R1 R0

Bricks are primitives. The keystone is the policy. Every arrow is a dependency. Soundness of the keystone is the conjunction of soundness of every brick beneath it. SHA-256 sits beside the wall — it pins the SRS provenance into the verifying-key supply chain, not into any individual proof.

the contract

The policy lives inside the circuit. The contract is a thin wrapper.

What sep-anarchy actually does on chain: a Soroban contract that pulls the verifying key for the sep-anarchy R_Upd circuit, checks one PLONK proof, swaps the stored Merkle root, and increments the epoch. The policy semantics — who can admit — are baked into the R_Upd predicate, not into the contract body.

policy predicateinside R_Upd
sep-anarchy predicate
In plain English: any current member can authorise an admission. The R_Upd witness need only carry one valid Merkle path to some leaf of the current group commitment.

Contrast with the other four policies

sep-democracya quorum-of-N members must co-sign the witness
sep-oligarchya fixed founder set, baked into the circuit, admits
sep-oneononeexactly two members co-sign the witness
sep-tyrannya single admin key, baked into the circuit, admits
on-chain contractSoroban · WASM
// sep-anarchy / src/lib.rs · admit(C_g', π) fn admit(&mut self, c_new: Field, proof: Bytes) { // 1. proof's c_old must match what we hold assert(self.current_root == public_input(&proof, "c_old")); // 2. one BLS12-381 pairing host call assert(plonk_verify( VK_anarchy, &proof, [self.current_root, c_new, self.epoch, "sep-anarchy"], )); // 3. advance state by exactly one self.current_root = c_new; self.epoch += 1; emit AdmissionEvent { c_old: self.current_root, c_new, epoch: self.epoch }; }

The contract enforces four things: the proof's c_old matches the stored root, the PLONK proof verifies against VK_anarchy, the epoch advances by exactly one, and the new root replaces the old one. Everything else — the proof of membership — lives inside the circuit.

admission flow

Run an admission. Watch the wall light up bottom to top.

A current member, Alice, admits a new member, Carol. Six steps. As each step fires, the brick it engages glows on the wall and one line of the soundness chain becomes visible on the right. By step six, the full chain is assembled.

/ 06 ·
BLS12-381 pairing-friendly curve · always there KZG polynomial commitments · 48 B Poseidon2 algebraic hash over F_r Merkle tree group commitment C_g · O(log n) Fiat-Shamir transcript hash · Poseidon2 PLONK ~700 B proof · single-pairing verifier POLICY · KEYSTONE sep-anarchy

soundness chain · accumulates with each step

Six steps. By the end, every brick is engaged at least once and the entire soundness chain — from sep-anarchy down to discrete log on BLS12-381 and to one honest contributor in the EF KZG ceremony — is visible.

soundness, both directions

Forward: what every brick gives you. Reverse: what every brick costs you when it fails.

The soundness chain is a conjunction — every brick has to hold. Toggle the wall into reverse mode and click any brick to see exactly which other bricks fail with it. The capstone goes red as soon as anything on its dependency closure does.

Click any brick to break it. Showing failure propagation for . Hover the keystone for the full forward chain.
BLS12-381 pairing-friendly curve · foundation KZG polynomial commitments · 48 B Poseidon2 algebraic hash · F_r Merkle tree group commitment · O(log n) Fiat-Shamir transcript hash · Poseidon2 PLONK ~700 B · single-pairing POLICY · KEYSTONE sep-anarchy

Forward: what every brick gives you. Reverse: what every brick costs you when it fails. Be honest about the cost asymmetry — KZG and PLONK fall under Shor; Poseidon2, Merkle, and Fiat-Shamir survive. The contract as a whole only survives as long as every brick does.

vs the other four

All five policies sit on the same wall. Only the keystone changes shape.

The bricks beneath are bit-identical across sep-anarchy, sep-democracy, sep-oligarchy, sep-oneonone, and sep-tyranny. What differs is the predicate inside R_Upd — and so the size of the keystone circuit.

policy tag predicate R_Upd size trust shape stack delta
sep-anarchy any current member admits smallest one valid Merkle path is sufficient stack identical
sep-democracy a quorum-of-N admits medium N co-signing members stack identical · quorum check inside R_Upd
sep-oligarchy a fixed founder set admits small founder set baked into the circuit stack identical
sep-oneonone exactly two members agree small both members co-sign the witness stack identical
sep-tyranny a single admin admits smallest admin key baked into the circuit stack identical

Five contracts, one stack. Across the five policies, the bricks beneath the keystone are bit-identical: the same BLS12-381 curve, the same KZG SRS, the same Poseidon2 round constants, the same Merkle layout, the same Fiat-Shamir transform, the same PLONK proving system. Only the R_Upd predicate — and therefore the verifying key — differs.

go deeper

Each brick has its own primitive sheet.

Six sheets, one per primitive — plus the existing interactive PLONK admission walkthrough at /proofs/.

  • BLS12-381 /primitives/bls/ — the pairing-friendly curve. G₁ / G₂ / G_T and the bilinear pairing $e$. ~128-bit classical security; broken under Shor.
  • KZG /primitives/kzg/ — constant-size polynomial commitments. 48 B commit, 48 B open, single-pairing verify. Trusted setup pinned by SHA-256 to the EF ceremony SRS.
  • Poseidon2 /primitives/poseidon/ — algebraic hash over $F_r$. Two orders of magnitude cheaper than SHA-256 in-circuit. Conjectured PQ-secure.
  • Merkle tree /primitives/merkle/ — binary tree hashed with Poseidon2 at every internal node. The group commitment $C_g$ is the root.
  • Fiat-Shamir /primitives/fiat-shamir/ — interactive PLONK becomes non-interactive by hashing the transcript with Poseidon2. Soundness in the ROM, with the DFMS multi-round analysis.
  • PLONK /primitives/plonk/ — universal-updatable SNARK over BLS12-381. ~700-byte proof, one-pairing verifier. The thing that actually makes and checks the proof.
  • sep-anarchy /proofs/ — the interactive PLONK admission walkthrough, end to end, with the actual circuit and the actual Soroban transaction.