Vega enables secure, private identity verification using zero-knowledge proofs on mobile devices.

Concept 1: The Core Problem — Why Sharing Credentials Is Dangerous

What's happening today?

When you need to prove your age online, you typically upload your ID. That document then gets:

• Processed by a server
• Sometimes stored
• Eventually (hopefully) deleted

Why this is a serious problem

Your government ID is one of your most sensitive documents. Yet you're sharing it just to prove one single bit of information — for example, "yes, I am over 21."

Think of it this way:

What you NEED to prove:    "I am over 21"          ← 1 bit of information
What you ACTUALLY share:   Full name, address,
                           date of birth, ID number,
                           photo, expiry date...    ← Dozens of sensitive details

High-profile data breaches have repeatedly exposed government IDs that people shared for routine checks. This isn't an accident — it's the predictable result of a broken system.

The policy pressure making this urgent

Governments are now mandating ID-based verification:

• The EU Digital Identity (EUDI) Wallet — digital IDs for all EU citizens
• The EU's age-verification blueprint
• The UK's Online Safety Act — requires government ID for age checks

App developers face a painful choice:

• Use inaccurate methods (like AI-based age guessing), or
• Compromise user privacy by requiring ID uploads

---

Concept 2: The Big Idea — Proving Without Revealing

The central question Vega asks:

"Can we prove something about a credential without ever revealing the credential itself?"

A simple analogy

Imagine you want to prove you're old enough to enter a bar. Today's system is like handing the bouncer your wallet — they look at your ID, but also see your address, your full name, and everything else.

The ideal system would be like this:

The bouncer asks a question. You answer only "yes" or "no." The bouncer is mathematically certain you're telling the truth — but learns nothing else.

This is exactly what Zero-Knowledge Proofs (ZKPs) make possible.

---

Concept 3: Zero-Knowledge Proofs (ZKPs) — The Cryptographic Tool

What is a Zero-Knowledge Proof?

A ZKP is a cryptographic method that lets you prove a statement is true without revealing why it's true or what data supports it.

The three properties of a ZKP

Applied to identity

Traditional:   Show ID → Verifier sees everything
ZKP:           Prove claim → Verifier learns only "yes, claim is true"

In Vega's case:

• The credential (driver's license) stays on your phone
• The proof travels to the verifier
• The verifier learns only: "This person is over 21" — nothing more

Why hasn't this been practical before?

Prior ZKP systems had serious drawbacks:

• Required a trusted setup — a special ceremony that had to be repeated every time the logic changed
• Were too slow to run on a phone
• Produced large proofs that were slow to transmit
• Sacrificed performance to avoid the trusted setup

Vega solves all of these.

---

Concept 4: The Building Blocks Vega Is Built On

Vega didn't emerge from nothing. It combines four prior research contributions:

Building Block 1: Spartan

• Efficiently proves R1CS (a standard way to express computational statements)
• Produces succinct proofs (small in size)
• Requires no trusted setup

Building Block 2: Nova

• Introduced folding schemes
• Key idea: instead of proving many instances of a computation separately, you compress (fold) them into one instance
• Think of it like combining many small tasks into one summary task

Building Block 3: HyperNova

• Extended Nova's folding
• Discovered that folding a real instance with a random instance hides the secret data
• This technique is called "NovaBlindFold" — it's how Vega achieves zero-knowledge cheaply

Building Block 4: NeutronNova

• The most efficient folding scheme for handling a batch of instances at once
• Critical for Vega's speed when processing many SHA-256 blocks

How they fit together

NeutronNova  →  Folds many SHA-256 steps into one
Spartan      →  Proves the folded result efficiently
NovaBlindFold → Adds zero-knowledge with minimal overhead

---

Concept 5: The Hashing Problem — Why SHA-256 Is the Bottleneck

What does a credential proof need to do?

To prove something from a credential, the system must:

1. Hash the credential bytes using SHA-256 (to verify integrity)
2. Verify the issuer's digital signature (to confirm it's authentic)

Why hashing becomes the dominant cost

Signature verification would normally be the expensive part. But Vega is clever — it works in a mathematical field where signature arithmetic is native and cheap. So hashing becomes the bottleneck.

How SHA-256 works (simplified)

SHA-256 processes data in 64-byte blocks, applying the same compression function repeatedly:

Block 1 → Compress → Intermediate digest 1
Block 2 → Compress → Intermediate digest 2
...
Block 30 → Compress → Final hash

A typical mobile driver's license requires 30 blocks.

The naive approach (and why it's bad)

The straightforward circuit approach: unroll all 30 iterations into one giant circuit.

Problem: The circuit size grows with credential length. This is slow, produces large proofs, and leaks information about credential size.

Vega's solution: Fold the steps

Instead of one giant circuit:

Naive:   [Block1 + Block2 + ... + Block30] → One huge circuit

Vega:    [Block1] → Step circuit instance 1
         [Block2] → Step circuit instance 2
         ...
         [Block30] → Step circuit instance 30
         
         NeutronNova folds all 30 instances → ONE instance
         
         Spartan proves just ONE step + ONE core circuit

Result: The proving key only needs to describe one step and one core — it stays small regardless of credential length.

---

Concept 6: Fold-and-Reuse Proving — The Speed Secret

The two-phase pipeline

Vega splits work into two phases:

Phase 1: Once Per Credential (done when you first load your ID)

Credential loaded
      ↓
Split into "step circuits" (SHA-256 blocks) and "core circuit" (signature, age check)
      ↓
Commit reusable data → Cache it

This expensive work is done once and stored.

Phase 2: Once Per Presentation (done each time you prove something)

Re-randomize cached commitments (for privacy)
      ↓
Fold all SHA-256 step instances via NeutronNova
      ↓
Prove folded step + core circuit via Spartan
      ↓
Apply NovaBlindFold for zero-knowledge
      ↓
Final ZK proof: 108 KB, generated in 92 ms

Why this matters for repeated use

A user might present their credential to:

• A website
• An app
• An AI agent acting on their behalf
• Multiple services in one day

Each time, the credential hasn't changed. Only the session nonce (a fresh random value from the verifier) and possibly the date change.

By caching the expensive precomputed work, subsequent presentations skip most of the heavy lifting.

---

Concept 7: Avoiding the Credential Parser — Lookup Tables

The parsing problem

A mobile driver's license is encoded in CBOR (Concise Binary Object Representation) — a structured binary format. Building a full CBOR parser as a circuit would be:

• Complex to implement
• Expensive to run

The key insight

The credential is signed by a trusted issuer. So we already know it's well-formed. We don't need to parse it — we just need to reach in and grab specific fields.

How lookup tables work

Vega treats the credential as a byte-addressable lookup table:

Prover says: "The device public key starts at byte 847"
             "Here are the bytes"

Circuit checks:
  ✓ Do these bytes match the authenticated credential?
  ✓ Is the correct CBOR prefix at the start of the field?
     (prevents claiming the wrong field)
  ✓ Are the addresses contiguous?
     (prevents splicing bytes from unrelated locations)

Result: An entire parser replaced by a handful of lookups.

The same idea solves the length-hiding problem

Credentials vary in length. If the circuit size varied with the credential, that would leak information about the credential.

Solution: Build a table of all intermediate SHA-256 digests. The core circuit picks the correct one using a private index. If the prover picks the wrong entry, the issuer's signature check fails — so cheating is impossible.

---

Concept 8: Making It Zero-Knowledge — Cheaply

The challenge

A proof system must be zero-knowledge: the verifier should learn nothing beyond the specific claim being proved.

Standard approaches to achieve this are:

• Complex to engineer
• Add significant overhead to the prover

Vega's simpler approach

Step 1: Commit to every message the prover sends using hiding cryptographic commitments

Instead of sending: actual_value
The prover sends:   commit(actual_value, random_blinding_factor)

The verifier sees commitments, not values.

Step 2: Prove the hidden values would pass the verifier's checks

The verifier only performs a logarithmic number of operations — so the constraint system expressing those checks is tiny (just a few hundred constraints).

Step 3: Apply NovaBlindFold

Fold this small constraint system with a random instance via Nova's folding scheme. This hides the underlying data.

Key insight: The zero-knowledge overhead scales with this small constraint system — not with the full secret data. This is why it's cheap.

---

Concept 9: Device Binding — Tying the Proof to a Person

The problem without device binding

A ZKP proves facts about a credential. But what stops someone who steals a credential from generating valid proofs?

Or in an AI agent world: what stops an unauthorized agent from presenting proofs on someone's behalf?

Vega's solution: Device binding

Every proof is cryptographically tied to the holder's physical device:

1. Verifier sends a fresh session nonce (random value)
2. The user's device signs the nonce with its private key
   (stored in the phone's secure element — never leaves hardware)
3. The circuit:
   - Extracts the device public key from the credential (via lookup)
   - Verifies the device signature over the session nonce hash

Result:

• Possession of the credential alone is not enough to produce a valid proof
• The proof is only valid if it came from the specific device bound to that credential
• AI agents can present proofs on a user's behalf — but only proofs generated on the user's device

---

Concept 10: Unlinkability — Preventing Tracking Across Presentations

The privacy risk

If you present your credential to Website A and Website B, and both proofs look the same, those services could collude to track you.

Vega's solution: Re-randomization

Before each proof, the precomputed commitments are refreshed with new randomness:

Presentation 1:  commit(data, random_1)  →  Proof A
Presentation 2:  commit(data, random_2)  →  Proof B

Proof A and Proof B are cryptographically unlinkable — even though they prove the same fact about the same credential.

This is cheaper than recomputing everything from scratch, and it ensures two proofs about the same credential cannot be linked.

---

Concept 11: Performance — What This Looks Like in Practice

The numbers

What this means in practice

User taps "Present Credential"
         ↓
         92 milliseconds later...
         ↓
Proof is done. Service learns only the requested fact.
Credential never left the phone.

464 KB fits comfortably on any phone. 92 ms is imperceptible to a human user.

---

Concept 12: Where This Leads — Three Future Applications

Application 1: AI Agents Carrying Identity

As autonomous AI agents act on behalf of people (booking travel, entering agreements, accessing services), they'll need to prove facts about the humans they represent:

Agent says: "My principal is over 18"
            "My principal is a licensed physician"

With Vega:

• The proof is generated on the human's device
• Bound to the agent's session via device binding
• The agent never holds the underlying credential

Application 2: Bridging Off-Chain Identity to Blockchain Systems

Decentralized systems need real-world identity signals (KYC, accredited investor status, jurisdiction). Today this requires:

Current:  Upload documents → Centralized intermediary → On-chain attestation
          (User loses privacy twice: to intermediary AND on-chain)

With ZKP: Prove fact from government credential → On-chain verifier receives only proof
          (No intermediary sees credential; re-randomization prevents linkability)

Application 3: General Credential Formats

The techniques work for any credential with:

• A stable byte encoding
• A digital signature

This includes mobile driver's licenses, EU Digital Identity Wallets, and future formats not yet designed.

---

Summary: The Complete Picture

PROBLEM:
  Proving one fact requires sharing everything

SOLUTION: Zero-Knowledge Proofs
  Prove a claim without revealing supporting data

VEGA'S INNOVATIONS:
  1. Fold-and-reuse    → Speed through NeutronNova folding
  2. Lookup tables     → No parser needed; length-hiding
  3. NovaBlindFold     → Cheap zero-knowledge
  4. Re-randomization  → Unlinkable presentations
  5. Device binding    → Tied to physical hardware

RESULT:
  92 ms · 108 KB proof · No trusted setup
  Credential never leaves the device
  Works with real-world formats (mDL, EUDI)
  Ready for AI agent world

The fundamental shift Vega represents:

From a world where proving a fact about yourself requires giving up your identity → to one where cryptography lets you keep it.