Priva Whitepaper

Version 1.0 · Living document

Priva is a decentralized network that treats privacy as infrastructure. Node operators earn PRIVA by performing verifiable, meaningful work — relaying mixnet traffic, serving encrypted storage, and settling shielded transfers — and in return unlock a suite of privacy-native applications.

This document describes the protocol's architecture, its two core cryptographic systems — Proof-of-Meaningful-Work (PoMW) and shielded transfers — the PRIVA token economy, and the threat model. It is a living document; the canonical implementations live in the Priva monorepo under crypto/, contracts/, and node-client/.

1. Motivation

Most "privacy" in Web3 stops at the wallet. Network metadata — who talks to whom, when, and how often — is left exposed, and "proof of work" rewards arbitrary hashing rather than useful service. Priva inverts both:

Work must be meaningful. Rewards are tied to relaying, storing, and settling real traffic, attested by signed receipts and anchored on-chain.
Privacy is the product, not a feature. Every layer is engineered to minimize metadata and keep secrets client-side.

2. Network Architecture

Priva is a layered stack. Each layer is independently useful and composes with the others.

Layer	Function	Privacy primitive
Routing mesh	Relays packets between peers	Mixnet — layered encryption, batching, cover traffic
Encrypted storage	Stores user blobs across nodes	Client-side encryption, erasure coding
Settlement	Confirms value transfer & work	Zero-knowledge proofs (Groth16) on-chain

Nodes run the Go node-client (libp2p over QUIC/TCP), report heartbeats and work proofs to the API, and persist peer state locally. The public surface is a single Caddy reverse proxy terminating TLS; see Architecture for the deployment topology.

2.1 Tiers

A node's contribution tier gates which applications it can use and multiplies its rewards. Tiers are earned through staked PRIVA and sustained proven work (Standard → Advanced → Elite).

3. Proof-of-Meaningful-Work (PoMW)

PoMW answers a single question verifiably: did a node actually do the work it claims? Rather than trusting self-reported uptime, Priva aggregates counterparty-signed receipts into a tamper-evident commitment that is anchored on-chain each epoch.

3.1 Receipts

When node N relays (or stores) a message for a recipient R, R signs a receipt over the canonical tuple:

msg = nodeId | recipient | messageHash | epoch
sig = Sign_R(msg)

The node submits (nodeId, recipient, messageHash, epoch, sig) to the aggregator. The aggregator verifies that recover(msg, sig) == recipient before accepting it — a node cannot fabricate work without a valid counterparty signature. (Reference implementation: crypto/pomw_prototype.)

3.2 Epoch Merkle commitment

Accepted receipts for an epoch are hashed into leaves and folded into a Merkle tree:

leaf_i   = H(receipt_i)
root_e   = MerkleRoot({ leaf_0, leaf_1, ..., leaf_n })

At the end of each epoch the aggregator publishes root_e to an on-chain oracle (PoMWOracle.submitRoot(root, epoch)). Anyone holding a receipt can later prove inclusion against the published root with a logarithmic-size Merkle path, and reward distribution is computed against the committed set.

3.3 Dispute window

Each published root opens a dispute window. During the window, any party can submit a fraud proof — e.g. a duplicated leaf, a receipt with an invalid signature, or a node over-counting its share. Rewards finalize only after the window closes without a successful challenge, making over-reporting economically irrational.

4. Shielded Transfers

Priva's settlement layer supports shielded transfers: moving value (or proof of a private action) without revealing the link between sender and recipient. This is built on a Merkle-inclusion + nullifier circuit proven in zero knowledge with Groth16 and verified on-chain. (Reference implementation: crypto/shielded_prototype.)

4.1 Commitments and the note tree

Deposits create a note committed into an append-only Merkle tree. The leaf is a Poseidon commitment binding the value to a private (secret, nonce) pair held only by the owner. Poseidon is used throughout because it is dramatically cheaper to prove inside an arithmetic circuit than SHA-256 or Keccak.

4.2 The circuit

To spend, a user proves — without revealing which note — that:

Membership. Their note's leaf is included in the tree with root root. The circuit recomputes the path, selecting child order from a boolean direction bit at each level:

for each level i:
    pathIndices[i] ∈ {0, 1}              // enforced boolean
    (left, right) = swap(cur, sibling, pathIndices[i])
    cur = Poseidon(left, right)
root == cur

Nullifier. They derive a unique, unlinkable spend tag:
```
nullifier = Poseidon(secret, nonce)
```

The nullifier is published on spend; the contract rejects any repeat, which prevents double-spends without revealing which note was consumed. Because the nullifier is a one-way function of private inputs, observers cannot link a spend back to its deposit.

4.3 Proving system and on-chain verification

The circuit is compiled with circom and proven with Groth16 (snarkjs), yielding constant-size proofs (~200 bytes) and cheap on-chain verification. The toolchain exports a Solidity Verifier.sol that the settlement contract calls in verifyProof(...). Continuous integration compiles the circuit, runs a development trusted setup, and exports the verifier on every change (see the Build Circuits workflow), so the artifacts are always reproducible from source.

note

Groth16 requires a per-circuit trusted setup. Priva treats this as a first-class security ceremony — see §5. PLONK is supported in the toolchain as a universal-setup alternative for future circuit revisions.

5. The Trusted Setup Ceremony

Groth16's soundness depends on the secret "toxic waste" of the setup being destroyed. Priva runs a multi-party computation (MPC) ceremony (Powers of Tau → phase-2 circuit-specific contributions) where security holds as long as at least one participant is honest and discards their entropy.

The ceremony is designed for public verifiability:

Every contribution is chained and attested; each contributor publishes a transcript and the hash of their output.
A verification script (verify_ceremony.sh / .ps1) re-checks artifact presence, published checksums, and runs snarkjs zkey verify <r1cs> <ptau> <zkey> against the final key.
On every published release, CI re-runs verification against the release artifacts and uploads the log.

See crypto/shielded_prototype/ceremony_plan.md and contributor_template.md for the full protocol and how to contribute.

6. Privacy Applications

Proven work unlocks tiered access to the application suite:

App	Status	Description
Chat	Live	Encrypted P2P messaging over the mixnet, no metadata retention
Browser	Live	Onion-proxied browsing with private DNS and tracker resistance
Bridge	Beta	Shielded cross-chain transfers validated by the ZK verifier
Wash	Soon	Private denomination pools with withdrawal unlinkability

7. Token Economy (PRIVA)

PRIVA is the network's native asset (ERC-20, 1,000,000,000 hard cap). It is earned through node farming, used to stake for tiers and governance, and pays protocol fees. Emissions are milestone-based — released against verifiable network growth rather than a fixed time schedule. Full parameters, allocation, and the emission curve are in Tokenomics (PRIVA).

8. Threat Model & Security

Metadata minimization. Mixnet batching and cover traffic break timing and volume correlation; the network stores no message metadata.
No trust in self-reporting. PoMW requires counterparty signatures and on-chain Merkle commitments with dispute windows.
Unlinkable settlement. Nullifiers prevent double-spends while ZK proofs hide the spent note; only validity, never identity, is revealed on-chain.
Ceremony integrity. A 1-of-N honest assumption plus public verification protects the Groth16 setup.
Client-side secrecy. Encryption keys and note secrets never leave the user's device.

Priva is pre-audit. The cryptographic components shipped today are reference prototypes; production deployment is gated on independent audits and a public trusted-setup ceremony.

9. Roadmap

Now — Live mixnet chat & browser; PoMW receipt aggregation; shielded transfer circuit + verifier reproducible in CI.
Next — On-chain PoMW oracle with dispute resolution; public MPC ceremony; bridge to mainnet.
Later — Wash denomination pools; PLONK migration for universal setup; selective-disclosure / proof-of-innocence tooling.

References

crypto/pomw_prototype — PoMW receipt aggregator and Merkle commitments
crypto/shielded_prototype — Merkle-inclusion + nullifier circuit, Groth16 setup, Solidity verifier
Architecture · Tokenomics (PRIVA) · FAQ
Groth16 (Jens Groth, 2016); Poseidon hash (Grassi et al.); circom / snarkjs (iden3)

1. Motivation​

2. Network Architecture​

2.1 Tiers​

3. Proof-of-Meaningful-Work (PoMW)​

3.1 Receipts​

3.2 Epoch Merkle commitment​

3.3 Dispute window​

4. Shielded Transfers​

4.1 Commitments and the note tree​

4.2 The circuit​

4.3 Proving system and on-chain verification​

5. The Trusted Setup Ceremony​

6. Privacy Applications​

7. Token Economy (PRIVA)​

8. Threat Model & Security​

9. Roadmap​

References​