Protocol papers
Privacy papers: what is hidden, and from whom.
These papers do not all hide the same thing. Say whether the design hides the link, the amount, or the history.
How to read this shelf
Each card opens a study. The study is a reading of a public paper, not the paper and not a description of today's network. Status is a design paper unless the record says historical or failure case.
How to read this page
Research status is named on the page. Primary sources are linked. This is a mechanism and operating note, not investment suitability, legal advice, a security guarantee or an implementation certificate.
CryptoNote · 2013 · Design paper
CryptoNote v 2.0
The public design paper behind unlinkable payments. Monero adopted the construction and then replaced pieces of it. The historic library only has a third-party review of CryptoNote, not this document.
Zerocoin · 2013 · Design paper
Zerocoin: Anonymous Distributed E-Cash from Bitcoin
A 2013 proposal to add an anonymity layer on top of Bitcoin by burning a coin into a commitment and later redeeming a different coin with a zero-knowledge proof of membership.
Zerocash · 2014 · Design paper
Zerocash: Decentralized Anonymous Payments from Bitcoin
The 2014 paper that showed how a payment ledger can hide sender, receiver and amount, while still letting the network check that coins were not created or double-spent. Zcash is an implementation of this line of work, not a co-author of the paper.
Monero · 2016 · Design paper
Ring Confidential Transactions
The research note Monero used to hide amounts, not just the signer. It extends ring signatures so a spender can prove a balance inside a ring without publishing the values.
Mimblewimble · 2016 · Design paper
Mimblewimble
A short 2016 note on a ledger that stores confidential transactions and can delete spent history. Grin and Beam are later implementations. The note itself is the primary text.
Confidential Transactions · 2015 · Design paper
Confidential Transactions
Hide the amounts on a Bitcoin-style transaction with Pedersen commitments, and use range proofs so a commitment cannot stand for a negative number. The graph of who paid whom stays visible.
Bulletproofs · 2018 · Design paper
Bulletproofs: Short Proofs for Confidential Transactions and More
Range proofs whose size grows logarithmically, with no trusted setup. They made confidential amounts practical to verify. They are not, by themselves, a private payment system.
Groth16 · 2016 · Design paper
On the Size of Pairing-based Non-interactive Arguments
A pairing-based argument in three group elements. The proofs are tiny and cheap to verify. Each circuit needs its own setup, and a leaked setup can forge proofs.
PLONK · 2019 · Design paper
PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge
A SNARK with a universal and updatable structured reference string. One setup can serve many circuits. The proofs are larger than Groth16, and there is still a setup.
Halo · 2019 · Design paper
Halo: Recursive Proof Composition without a Trusted Setup
Recursion for inner-product arguments, without a structured setup. A proof can attest that another proof was checked. That is how a chain can fold a long history into one object. Halo 2 is a later system.
Zexe · 2020 · Design paper
Zexe: Enabling Decentralized Private Computation
A model for private computation over records. Each record has a birth predicate and a death predicate. A transaction proves that some records died and others were born, without showing which, or showing the data.
Nova · 2021 · Design paper
Nova: Recursive Zero-Knowledge Arguments from Folding Schemes
Incrementally verifiable computation without putting a SNARK inside a SNARK. A folding scheme compresses two instances of a computation into one instance of the same size. Repeating that fold is the recursion. The paper is about prover cost, not about a chain.
Marlin · 2019 · Design paper
Marlin: Preprocessing zkSNARKs with Universal and Updatable SRS
A preprocessing zkSNARK whose structured reference string is universal and can be updated, rather than baked for one circuit in a ceremony that must be trusted forever. The paper improves on Sonic's costs. It is still a SNARK, with a setup.
FROST · 2020 · Design paper
FROST: Flexible Round-Optimized Schnorr Threshold Signatures
A threshold Schnorr signature: any t of n signers can produce one ordinary-looking signature, and fewer than t cannot. The signing protocol is two rounds, or one if nonces were prepared earlier. The paper is the scheme, not a custody vendor.
MuSig2 · 2020 · Design paper
MuSig2: Simple Two-Round Schnorr Multi-Signatures
n signers, all of them, produce one Schnorr signature that verifies under one aggregated key. Two rounds, and concurrent sessions are in the security claim. This is n-of-n, not a threshold. It is the multi-signature Bitcoin-style schemes reached for.
Taproot · 2020 · Design paper
BIP 341: Taproot: SegWit version 1 spending rules
A Bitcoin spend that can look like a single key, while still hiding a tree of alternative scripts until one of them is used. Schnorr signatures and the key-path spend are the mechanism. Amounts stay public. This is not a privacy coin.
Semaphore · 2020 · Design paper
Semaphore: Zero-Knowledge Signaling on Ethereum
A member of a group proves they are some member, and posts a signal, without showing which member. A nullifier stops the same member signalling twice in the same context. The 2020 proposal is a base layer for voting and similar uses. It is not itself a mixer, and later versions changed the circuits.
Compact multi-signatures · 2018 · Design paper
Compact Multi-Signatures for Smaller Blockchains
The paper gives a BLS multi-signature that stays compact and blocks the rogue-key attack with a proof of possession of each key.
Zether · 2020 · Design paper
Zether: Towards Privacy in a Smart Contract World
Zether is a contract for confidential transfers and confidential anonymous transfers, with balances as commitments and a proof that the spend is well formed.
Inner-product arguments · 2016 · Design paper
Efficient Zero-Knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting
The paper compresses an inner-product argument so a circuit proof can be logarithmic without a trusted setup, in the discrete-log model.
Aurora · 2019 · Design paper
Aurora: Transparent Succinct Arguments for R1CS
Aurora proves rank-one constraint systems with a transparent setup, using a FRI-style proximity test rather than a pairing.
Spartan · 2020 · Design paper
Spartan: Efficient and General-Purpose zkSNARKs without Trusted Setup
Spartan encodes the circuit as a sparse matrix and uses a polynomial commitment so the prover's work tracks the number of constraints more tightly than a dense encoding.
HyperPlonk · 2022 · Design paper
HyperPlonk: Plonk with Linear-Time Prover and High-Degree Custom Gates
HyperPlonk replaces that transform with a sumcheck so the prover is linear in the number of gates, and it allows higher-degree custom gates.
Ouroboros Crypsinous · 2019 · Design paper
Ouroboros Crypsinous: Privacy-Preserving Proof-of-Stake
Crypsinous combines a stake lottery with a private transaction ledger so the leader proof and the transfers do not reveal the stake and the amounts in the way a public chain does.
Powers of Tau · 2017 · Design paper
Scalable Multi-party Computation for zk-SNARK Parameters
Powers of Tau is a multi-party computation that builds the structured reference string so that if one participant deletes their randomness, the trapdoor is gone.
Range proofs · 2018 · Design paper
Confidential Assets
Confidential assets put an asset tag beside a Pedersen commitment so a transaction can balance in several assets without publishing which output is which asset or how much.
Dandelion · 2017 · Design paper
Dandelion: Redesigning the Bitcoin Network for Anonymity
Forward the transaction along a line, in a stem phase, and only then broadcast it, in a fluff phase, so the first flood is not centred on the sender.
Pinocchio · 2013 · Design paper
Pinocchio: Nearly Practical Verifiable Computation
Compile the program to a quadratic arithmetic program and prove it was satisfied. Verification is a small number of pairings, independent of the program's length, after a trusted setup.
Sonic · 2019 · Design paper
Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updatable Structured Reference Strings
Sonic uses a structured reference string that is universal: one setup can serve many circuits, and it can be updated so the toxic waste is harder to keep.
FRI · 2018 · Design paper
Fast Reed-Solomon Interactive Oracle Proofs of Proximity
FRI is the proximity test: fold the polynomial in rounds until a constant remains, and sample enough points that a cheating polynomial is caught.
BBS signatures · 2016 · Design paper
BBS+ Signatures and Selective Disclosure
A BBS-family signature can be proved in zero knowledge so a holder reveals only some messages and produces an unlinkable presentation.
BIP 32 · 2012 · Design paper
Hierarchical Deterministic Wallets
A master secret derives a tree of child keys. A parent public key can derive child public keys on non-hardened paths, so a server can issue addresses without the private key.
BIP 39 · 2013 · Design paper
Mnemonic Code for Generating Deterministic Keys
Encode entropy as a word list with a checksum, then stretch the words with a passphrase into a seed. The words are the backup. The passphrase is an extra secret, often empty.
BIP 44 · 2014 · Design paper
Multi-Account Hierarchy for Deterministic Wallets
A path is purpose, coin type, account, change, and index. Accounts are separated so one seed can hold many identities without mixing their change.
BIP 324 · 2019 · Design paper
Version 2 P2P Encrypted Transport Protocol
A v2 connection does an Elligator-style handshake and then encrypts the byte stream, so a passive observer cannot read the messages or easily identify the protocol.
BIP 8 · 2017 · Design paper
Version bits with lock-in by height
BIP 8, Version bits with lock-in by height. This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes.
BIP 9 · 2015 · Design paper
Version bits with timeout and delay
BIP 9, Version bits with timeout and delay. This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel.
BIP 11 · 2011 · Design paper
M-of-N Standard Transactions
BIP 11, M-of-N Standard Transactions. M-of-N-signatures required transactions as a new 'standard' transaction type.
BIP 13 · 2011 · Design paper
Address Format for pay-to-script-hash
BIP 13, Address Format for pay-to-script-hash. A new type of Bitcoin address to support arbitrarily complex transactions.
BIP 38 · 2012 · Design paper
Passphrase-protected private key
BIP 38, Passphrase-protected private key. A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string.
BIP 45 · 2014 · Design paper
Structure for Deterministic P2SH Multisignature Wallets
BIP 45, Structure for Deterministic P2SH Multisignature Wallets. A structure for hierarchical deterministic P2SH multi-party multi-signature wallets (HDPM wallets from now on) based on the algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).
BIP 69 · 2015 · Design paper
Lexicographical Indexing of Transaction Inputs and Outputs
BIP 69, Lexicographical Indexing of Transaction Inputs and Outputs. Currently there is no standard for bitcoin wallet clients when ordering transaction inputs and outputs.
BIP 75 · 2015 · Design paper
Out of Band Address Exchange using Payment Protocol Encryption
BIP 75, Out of Band Address Exchange using Payment Protocol Encryption. This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
BIP 85 · 2020 · Design paper
Deterministic Entropy From BIP32 Keychains
BIP 85, Deterministic Entropy From BIP32 Keychains. ''"One Seed to rule them all,'' ''One Key to find them,'' ''One Path to bring them all,'' ''And in cryptography bind them."'' It is not possible to maintain one single (mnemonic) seed backup for all keychains used across various wallets because there are a variety of incompatible standards.
BIP 86 · 2021 · Design paper
Key Derivation for Single Key P2TR Outputs
BIP 86, Key Derivation for Single Key P2TR Outputs. This document suggests a derivation scheme for HD wallets whose keys are involved in single key P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
BIP 89 · 2025 · Design paper
Chain Code Delegation
BIP 89, Chain Code Delegation. Chain Code Delegation (CCD) is a method for multi-signature wallets in which a privileged participant withholds BIP32 chain codes from one or more non-privileged participants, and supplies per-input scalar tweaks at signing time.
BIP 328 · 2024 · Design paper
Derivation Scheme for MuSig2 Aggregate Keys
BIP 328, Derivation Scheme for MuSig2 Aggregate Keys. This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2 aggregate public key and how such keys should be used for key derivation.
BIP 370 · 2021 · Design paper
PSBT Version 2
BIP 370, PSBT Version 2. PSBT Version 2 (PSBTv2) only specifies new fields and field inclusion/exclusion requirements.