Cryptographic Architecture · February 2026

What Encryption Does REF Use?

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.

Prepared by
REF Protocol
Classification
Public
Security Level
128-bit across all primitives
Primitives
5 layers · 8 algorithms
Core Architectural Principle
REF does not "encrypt reviews." It binds reviews to purchases cryptographically through signatures, commitments, and zero-knowledge proofs. Encryption protects data in transit and at rest. The protocol's security properties come from a different category of operations entirely.
01 — The Cryptographic Stack

Five Layers, Each With a Distinct Security Function

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.

L1
Attestation Layer
Merchant → Protocol boundary
Signing
▾

The merchant signs a commitment to the purchase. This is a digital signature, not encryption — the goal is authenticity and non-repudiation, not confidentiality.

Phase 1
Ed25519
RFC 8032 · EdDSA over Curve25519
Deterministic signatures on purchase attestations. No nonce vulnerabilities. Constant-time implementation resists timing side channels.
~128-bit security 32 bytes key size 0.089ms verify
Fallback
ECDSA P-256
FIPS 186-4 · secp256r1
For platforms (e.g., Salesforce Commerce Cloud) whose crypto libraries don't support Ed25519. NIST-standardized, broader HSM compatibility.
~128-bit security FIPS certified
Honest Acknowledgment

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.

L2
Token & Commitment Layer
ZK circuit interior
Hashing
▾

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.

Production
Poseidon Hash
Algebraic hash · SNARK-friendly over BN254 base field
Computes 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.
~128-bit collision resistance ~8× fewer constraints than SHA-256
L3
Privacy Layer
Zero-knowledge proof generation
Proving
▾

This is the most commonly misunderstood layer. Groth16 is not encryption — it's a proof of knowledge. Under the stated Groth16 knowledge-soundness and zero-knowledge assumptions, a valid proof provides evidence of knowledge of a witness satisfying the configured circuit. The verifier also sees the circuit's public inputs and surrounding protocol metadata; the proof hides the private witness values defined by the circuit.

Production
Groth16 ZK-SNARK
Over BN254 (alt_bn128) · Pairing-friendly elliptic curve
Zero-knowledge succinct non-interactive argument of knowledge. Proves purchase verification without revealing purchase data. Trusted setup via Hermez Powers-of-Tau (2²² constraints, 1,088 ceremony contributors).
BN254 curve Groth16 proof system 8/8 negative vectors rejected
Verification Evidence — EV-011 v2.1

Circuit: ref_token_v1_1.circom · 1,155 constraints · eight findings documented · v1.1 code changes recorded for F-001, F-002, F-004, F-005, F-007 · F-003 v2 fix documented · F-006 v1 design boundary · F-008 monitored · 8/8 recorded negative vectors rejected with CONSTRAINT_REJECTED. See EV-011 v2.1 locked evidence bundle.

Trusted Setup Caveat

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.

L4
Consensus Layer
Validator network (PBFT)
Authenticating
▾

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.

Production
HMAC-SHA256
RFC 2104 · Keyed-hash MAC
Message authentication for PREPARE, COMMIT, and VIEW_CHANGE messages between validators. Prevents forgery without shared-key infrastructure.
128-bit security PBFT protocol
Roadmap
BLS12-381
Aggregate signatures · Pairing-based
Compact quorum certificates: aggregate ⌈2c/3⌉ validator signatures into a single proof of agreement. Reduces QC size from O(n) to O(1). Requires Proof-of-Possession at registration to prevent rogue-key attacks.
~128-bit security O(1) QC size
L5
Transport Layer
Data at rest & in transit
Encrypting
▾

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 conditioned on the assumptions and evidence provided by the layers above.

Production
AES-256-GCM
FIPS 140-2 · AEAD · HSM-backed
Authenticated encryption with associated data for storage. Provides confidentiality + integrity atomically. Key management via hardware security modules.
256-bit key FIPS validated
Production
TLS 1.3 + X25519
ECDHE key exchange · PFS
Transport encryption with perfect forward secrecy. Session keys not compromised if long-term keys are leaked. X25519 constant-time, side-channel resistant.
~128-bit security PFS configured
02 — Information Flow Boundaries

What Crosses Each Boundary

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.

Data Flow Across Trust Boundaries

Merchant Zone
Purchase tuple
SignEd25519(sk, H(purchase))
att_hash = Poseidon(...)
→
att_hash only
Protocol Zone
ZK proof π
Token commitment
Nullifier (spend-once)
Quorum certificate
→
bool + QC
Platform Zone
{ valid: true }
Quorum certificate
No purchase data
No customer PII
03 — What REF Correctly Avoids

Conspicuously Absent Algorithms

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 Beyond the current development-stage requirements
Custom primitives Banned Kerckhoffs' principle — use standard constructions only
04 — Implementation Maturity

Honest Status of Each Primitive

✍️
Ed25519
Attestation signatures
<10ms verification
Production
🔗
Poseidon
ZK circuits deployed
Domain-separated tags
Production
🛡️
Groth16
1,155 constraints
EV-011 constraint evidence
Implemented
🤝
HMAC-SHA256
PBFT message auth
Replay prevention
Production
🔐
AES-256-GCM
FIPS 140-2 validated
HSM-backed keys
Production
📡
BLS12-381
Aggregate QCs
PoP required
Scaffold
What's Not Done — Phase 2 (Post-Series A)

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.

Poseidon parameter formal verification: not completed. The circuits are implemented, and testing provides implementation evidence, but no Coq/Isabelle proof of collision resistance is claimed here.

Post-quantum migration — roadmap for Kyber-1024 (KEM) and CRYSTALS-Dilithium (signatures), target 2027. Not critical for current threat model, but on the horizon.

"The question is not 'what encryption does REF use?' The question is 'what mathematical operations establish purchase-eligibility provenance under the configured protocol?' Those operations are signing, committing, proving, and reaching consensus — not encrypting."
— Core Architectural Principle