Key Management Architecture · February 2026

What Type of Key Does REF Use?

REF manages four distinct key types across its protocol layers. No single key compromise breaks the whole system — each key type has a bounded blast radius, a defined lifecycle, and an explicit degradation mode.

Prepared by
REF Protocol
Classification
Public
Key Types
4 distinct classes
Principle
Defense in depth — no single point of failure
Defense-in-Depth Principle
Four key types, four blast radii. A compromised merchant key cannot forge consensus. A compromised validator key cannot fabricate attestations. A compromised transport key reveals no protocol-layer secrets. Each layer's keys are isolated by design.
01 — The Four Key Types

Each Key Has a Purpose, a Lifecycle, and a Failure Mode

Key management is where cryptographic theory meets operational reality. For each key type, we state not just what it does, but what happens when it's compromised — because rigorous engineering means modeling failure, not just success.

🔏
Merchant Signing Keys
Ed25519 · RFC 8032 · 256-bit private / 32-byte public
Phase 1

The merchant's identity in the REF protocol. This key signs purchase attestations — it proves who attested that a purchase occurred.

Operation
A := SignEd25519(skmerchant, Hext(purchase))
Storage
HSM-backed key management. Private key never leaves secure enclave. No secrets in application code.
Key Size
256-bit private key (32 bytes). Deterministic public key derivation — no nonce vulnerabilities.
Rotation
Configurable schedule per Merchant Service Agreement. Old attestations remain valid under previous key.
Key Lifecycle
📋
Onboard
HSM generates
Register
pk → REF registry
🔏
Sign
Attestations
🔄
Rotate
Per MSA schedule
🗑️
Retire
Secure erasure
If Compromised

An attacker with the merchant's signing key can fabricate attestations for purchases that never occurred (phantom attestation — ATK-3). The economic layer makes this irrational: merchant performance deposits ($10K/$25K/$50K+ by tier) exceed the value of fabricated reviews. But it is not cryptographically prevented — it is economically deterred.

Validator Signing Keys
Ed25519 (Phase 1) · BLS12-381 (roadmap) · PoP required
Phase 1

Validators use these keys to sign PBFT consensus messages. A quorum certificate (QC) is proof that ≥ ⌈2c/3⌉ validators agreed on a token's validity.

Operation
Signs PREPARE, COMMIT, and VIEW_CHANGE messages in the PBFT protocol
Registration
Proof-of-Possession (PoP) required at registration — prevents rogue-key attacks where an adversary crafts a key to cancel out honest validators' contributions
Economic Binding
Validator key bonded to economic stake. Key compromise without stake compromise is insufficient for attack.
BLS Roadmap
BLS12-381 enables signature aggregation — compress ⌈2c/3⌉ signatures into one. Reduces QC size from O(n) to O(1). Phase 2 implementation.
Key Lifecycle
🎲
Generate
Validator node
🛡️
PoP
Prove possession
💰
Bond
Stake deposit
Consensus
Sign messages
🔄
Rotate
Per epoch
If Compromised

A single compromised validator key is tolerated — PBFT requires > f = ⌊c/3⌋ Byzantine validators to violate safety. Compromising one key gains the attacker one vote, not control. VRF-based committee selection ensures the adversary cannot predict which validators will be on any given committee.

🧮
ZK Proving & Verification Keys
Groth16 SRS · BN254 · Hermez Powers-of-Tau (2²² constraints)
Production

These are not signing keys — they are the Structured Reference String (SRS) from a trusted setup ceremony. The proving key enables proof generation; the verification key enables proof checking. Neither is a secret in the traditional sense.

Proving Key (pk)
Used client-side to generate ZK proofs. Large (~hundreds of KB). Distributed to proof generators. Not secret — but specific to the circuit.
Verification Key (vk)
Used server-side and by validators to verify proofs. Small (~1 KB). Pinned in artifact registry with SHA-256 hash. Public.
Ceremony
Hermez Powers-of-Tau · 2²² constraint capacity · 1,088 contributors · Phase 2 circuit-specific with drand beacon finalization
Circuit
ref_token_v1_1.circom · 1,155 constraints · EV-011 v2.1 (commit 3c3017b)
Key Derivation Chain
🏛️
PTAU
1,088 contributors
⚙️
Phase 2
Circuit-specific
🎲
Beacon
drand random
🔑
pk + vk
Final keys
📋
Manifest
SHA-256 pinned
Toxic Waste Concern — The Hardest Honest Answer

If the Powers-of-Tau toxic waste is recovered, an adversary can forge proofs for any statement — meaning they could fabricate purchase proofs without real purchases. This is a catastrophic failure mode with no detection at the protocol level.

Mitigation: (a) Hermez ceremony had 1,088 contributors — security requires only one honest participant; (b) Phase 2 roadmap evaluates PLONKish universal-setup systems (PLONK, Halo2) that eliminate per-circuit trust entirely; (c) REF's Phase 2 circuit-specific setup lacks independent audit trail — acknowledged gap, budgeted for external attestation.

🔒
Transport & Session Keys
X25519 ECDHE · AES-256-GCM · Ephemeral
Production

Ephemeral keys for TLS 1.3 sessions. These protect data confidentiality in transit — but none of REF's core security properties depend on them. If every transport key were compromised, the protocol's authenticity, uniqueness, and integrity guarantees would still hold.

Key Agreement
X25519 Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Constant-time, side-channel resistant.
Session Encryption
AES-256-GCM — authenticated encryption. Session keys destroyed after connection closes.
Forward Secrecy
Perfect Forward Secrecy (PFS): past sessions cannot be decrypted even if long-term server keys are later compromised.
Lifetime
Single TLS session. Generated per connection, never persisted to disk. Shortest-lived key in the protocol.
Key Lifecycle (Ephemeral)
🤝
Handshake
X25519 ECDHE
🔐
Session
AES-256-GCM
💨
Destroy
Connection close
Why Transport Keys Are the Least Important

Transport keys protect confidentiality of data in motion. But REF's security properties — authenticity (P-AUTH), uniqueness (P-UNIQ), integrity (P-INTEG), privacy (P-PRIV) — are all enforced by the layers above. Even if TLS were stripped entirely, the ZK proofs, signatures, and consensus certificates would still be valid and unforgeable.

02 — Blast Radius Analysis

What Breaks When Each Key Is Compromised

Defense in depth means every key type has a bounded blast radius. No single key compromise cascades across layers.

Key Compromised Impact Blast Radius Mitigation
Merchant sk Phantom attestations for that merchant Single merchant Economic deterrence (bonds). Platform cross-validation. Key rotation.
Validator sk One Byzantine vote per compromised key 1/c of committee BFT tolerance (f < c/3). VRF unpredictability. Slashing on equivocation.
ZK toxic waste Arbitrary proof forgery — any statement Entire protocol 1,088-contributor ceremony. PLONKish migration roadmap. No detection possible.
Transport sk Session eavesdropping (single connection) One session PFS — past sessions safe. Ephemeral keys — no persistence. Protocol integrity unaffected.
The Asymmetry That Matters

The two most operationally likely compromises (merchant key, transport key) have the smallest blast radii. The compromise with the largest blast radius (ZK toxic waste) requires breaking a 1,088-participant MPC ceremony — a fundamentally different class of difficulty. This is by design, not by accident.

"We have four key types: merchant signing keys, validator signing keys, ZK proving and verification keys from a trusted setup, and ephemeral transport keys. No single key compromise breaks the whole system — that's defense in depth."
— Core Architectural Principle