The honest answer: REF is primarily a signing and proving system, not an encryption system. Most of what REF does is authenticate, not encrypt. Here is the full stack, layer by layer.
Every layer uses the primitive appropriate to its purpose. No algorithm is used where another would be more correct. This is Kerckhoffs' principle applied to architecture — standard constructions, composed with domain separation.
The merchant signs a commitment to the purchase. This is a digital signature, not encryption — the goal is authenticity and non-repudiation, not confidentiality.
The merchant signature proves who attested, not whether the purchase was real. A dishonest merchant can sign attestations for purchases that never occurred (phantom attestation — ATK-3). This is mitigated economically (performance deposits), not cryptographically.
Inside the zero-knowledge circuit, all commitments use a SNARK-friendly hash. This is not a signature or encryption — it's a binding commitment that enables efficient proof generation.
att_hash
and token_commit
inside the arithmetic circuit. Chosen because it has ~8× fewer constraints than SHA-256 in R1CS.
Domain-separated with versioned tags: REF/TOKEN/v2,
REF/NULLIFIER/v2.
This is the most commonly misunderstood layer. Groth16 is not encryption — it's a proof of knowledge. It proves that the prover knows a valid purchase witness without revealing the purchase details. The verifier learns nothing except that the statement is true.
Circuit: ref_token_v1_1.circom ·
1,155 constraints · 8 security findings addressed · 8 negative test vectors properly rejecting
with CONSTRAINT_REJECTED. Commit 3c3017b.
Groth16 requires a per-circuit trusted setup. If the PTAU toxic waste is recovered, arbitrary proof forgery becomes possible. Mitigation: (a) Hermez ceremony had 1,088 contributors; (b) Phase 2 roadmap evaluates PLONKish universal-setup systems that eliminate this trust requirement.
Validators exchange authenticated messages to reach Byzantine agreement on token validity. This layer uses message authentication (not encryption) — every PBFT message is signed, and quorum certificates aggregate these signatures.
This is the only layer that actually encrypts. It protects data confidentiality — but none of REF's core security properties (authenticity, uniqueness, integrity, privacy) depend on this layer. They are all guaranteed by the layers above.
The cryptographic stack is stratified so that no single layer has enough information to violate privacy. The merchant sees the purchase but not the review. The consensus layer sees commitments but not the purchase details. The platform sees the result but not the data.
SignEd25519(sk, H(purchase))att_hash = Poseidon(...)
{ valid: true }The choice of what not to use is as important as what we selected. REF uses no custom primitives — every algorithm is peer-reviewed and standard.
| Algorithm | Status | Reason for Exclusion |
|---|---|---|
| MD5, SHA-1 | Banned | Catastrophically broken collision resistance |
| 3DES | Banned | Deprecated by NIST (2023) |
| RC4 | Banned | Stream cipher with numerous biases |
| ECB mode | Banned | Deterministic — pattern leakage |
| RSA (new impl) | Avoided | ECC preferred — 64× faster verification, smaller keys. RSA only in legacy TLS cert chains. |
| SHA-512 | Unnecessary | Overkill for 128-bit security target |
| Custom primitives | Banned | Kerckhoffs' principle — use standard constructions only |
BLS12-381 aggregation is scaffolded but not in production. Phase 1 uses Ed25519 for all signatures. BLS aggregation is a Phase 2 optimization for reducing QC size.
Formal verification of Poseidon parameters — circuits deployed, but no Coq/Isabelle proof of collision resistance. Testing demonstrates correctness; formal proof requires external engagement (budgeted: $100–175K, Trail of Bits or Veridise).
Post-quantum migration — roadmap for Kyber-1024 (KEM) and CRYSTALS-Dilithium (signatures), target 2027. Not critical for current threat model, but on the horizon.