Privacy Architecture

dregg provides privacy at multiple levels. In sovereign mode, the federation never sees cell contents -- only 32-byte commitments and proofs. The privacy stack covers credentials, amounts, recipients, intents, and network metadata.

What Is Private (Implemented)

What Is NOT Fully Private (Honest Limitations)

• Intent content: SSE keyword tokens are enumerable by knowledgeable observers. An adversary who knows the keyword space can test encrypted headers against known tags.
• Mediated interactions: The executor sees sovereign state during federation-mediated multi-party interactions. Peer-to-peer mode avoids this entirely.
• Hosted cells: If you use hosted mode, the federation sees full cell state (by definition).

Anonymous Credentials

The BlindedMerklePoseidon2StarkAir generates fresh blinding per presentation. The public input is hash_2_to_1(leaf_hash, blinding) instead of the raw leaf hash. The verifier cannot determine which Merkle leaf corresponds to this proof. Multiple proofs from the same holder are unlinkable.

Predicate Proofs

Prove properties about private values without revealing them:

• Simple predicates: value >= threshold, value <= threshold, value != x
• Committed thresholds: value >= T where T is hidden behind Poseidon2(T, blinding)
• Relational: my_value > their_value (two-party, sealed channel)
• Arithmetic: expressions over multiple values (balance_a + balance_b >= 2000)
• Programmable: arbitrary expression trees compiled to AIR

Private Notes

Notes are commitments to (owner, value, asset_type, randomness). The commitment is a Poseidon2 hash -- binding (cannot open to different value) but hiding (reveals nothing about contents). Spending requires proving knowledge of the spending key and Merkle membership, producing a nullifier for double-spend prevention.

Private Discovery (PIR)

Intent discovery uses 2-server information-theoretic PIR. The client generates a random vector and XORs a unit vector at the target position. Each server sees a random-looking query. Responses are XORed client-side to recover the target row. Security is information-theoretic (not computational) under non-collusion.

Non-Revocation

The NonRevocationAir proves sorted-Merkle non-membership: for each ancestor in a token's derivation path, find two adjacent leaves in the sorted revocation tree that bracket the ancestor's hash. Prove membership of both neighbors and that the ancestor falls between them (absent). All ancestors are proven simultaneously in a single STARK.

Sovereign Mode Privacy

In sovereign mode, the federation stores only HashMap<CellId, [u8; 32]> -- one hash per cell. It never sees balances, capability sets, metadata fields, or internal state. The privacy model becomes uniform: everything is private by default because the federation literally cannot read your state.

Between two parties who know each other (peer-to-peer mode), there is no federation contact at all. Privacy against network observers relies on Dandelion++ routing and message padding. Privacy against the counterparty is bounded by what you choose to reveal in your proof's public inputs.

Sealer/Unsealer Pairs

E-style rights amplification for partition-tolerant capability transfer. Each pair is an X25519 keypair: sealing uses a fresh ephemeral key (forward secrecy), DH-derived shared secret, and ChaCha20-Poly1305 AEAD. Only the unsealer holder can decrypt. This enables encrypted capability exchange without online coordination.

Faceted Capabilities

From the E programming language: a facet is a restricted view of an object. In dregg, facets are bitmasks on capabilities that restrict which effect types are permitted. Predefined facets include read-only (observation without mutation), transfer-only, state-writer, and admin. Facets compose with attenuation -- a child's mask must be a subset of the parent's mask. This is enforced in-circuit.

Encrypted Turns

Turn payloads can be encrypted to specific recipients. The federation orders opaque blobs (it can verify the STARK proof of validity without seeing plaintext content). Combined with Dandelion++ routing and stealth addresses, this provides strong unlinkability for routine transactions.

Private Vickrey Auction (4-Phase Protocol)

A fully private sealed-bid second-price auction where nobody learns any bid value, the payment amount, or the winner's identity. Uses garbled circuits, oblivious transfer, federation threshold cryptography, Pedersen commitments, ring proofs, and stealth addresses.

Phase 1: Bid Commitment

Each bidder commits their bid using a Pedersen commitment with a STARK range proof. The commitment is binding (cannot change bid) and hiding (no one learns the value).

Phase 2: Threshold-Encrypted Revelation

After the deadline, bidders encrypt their bid openings under the federation's threshold public key. No single federation member can decrypt -- t-of-n threshold decryption is required.

Phase 3: Garbled Circuit Evaluation

The federation collectively evaluates a garbled circuit computing the Vickrey outcome (winner index + second-highest price). Individual bid values are never output. Oblivious transfer between federation members prevents any subset from learning intermediate values. The garbled circuit uses Poseidon2-based garbling (STARK-friendly).

Phase 4: Anonymous Settlement

The winner proves membership in the bidder set via a ring proof without revealing which bid is theirs. Payment goes to a stealth address. The winner receives the item at a fresh stealth address. Even the auctioneer cannot link winner identity to payment.

Security Properties

• Bid privacy: No party learns any bid except the second-highest price.
• Winner privacy: Winner identity hidden behind ring proof.
• Payment privacy: Amount and flow hidden by Pedersen + stealth.
• Fairness: Threshold prevents early bid revelation by coalition < t.
• Correctness: STARK proof attests garbled circuit was evaluated correctly.

Status: Implemented and tested with up to 64 bidders. Uses Simplest OT over Ristretto. Ring proof uses Schnorr-based linkable ring signature.

Private Predicates (Three Tiers)

Further reading

A more formal treatment of the unlinkability guarantees, including composability across protocols and side-by-side analysis vs. Zcash and Aleo, is split across the design docs in the repo: docs/unlinkability-analysis.md, docs/intent-privacy-assessment.md, and docs/defi-privacy-comparison.md. The pages here summarise the operational shape; those files carry the proofs and adversary models.