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.
BIP 371 · 2021 · Design paper
Taproot Fields for PSBT
BIP 371, Taproot Fields for PSBT. The new per-input types are defined as follows: {| ! Name ! ! ! Description ! ! Description ! Versions Requiring Inclusion ! Versions Requiring Exclusion ! Versions Allowing Inclusion |- | Taproot Key Spend Signature | PSBT_IN_TAP_KEY_SIG = 0x13 | None | No key data '''Why is there no key data for PSBT_IN_TAP_KEY_SIG '''The signature in a key path spend corresponds directly with the pubkey provided in the output script.
BIP 373 · 2024 · Design paper
MuSig2 PSBT Fields
BIP 373, MuSig2 PSBT Fields. The new per-input types are defined as follows: {| ! Name ! ! ! ! Versions Requiring Inclusion ! Versions Requiring Exclusion ! Versions Allowing Inclusion |- | rowspan="2"|MuSig2 Participant Public Keys | rowspan="2"| PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a | | | rowspan="2"| | rowspan="2"| | rowspan="2"| 0, 2 |- | The MuSig2 aggregate public key (compressed) '''Why the compressed aggregate public key instead of x-only?''' [[bip-0032.mediawiki|BIP 32]] public keys can be derived from a [[bip-0327.mediawiki|BIP 327]] MuSig2 aggregate public key (see: [[bip-0328.mediawiki|BIP 328]]).
BIP 380 · 2021 · Design paper
Output Script Descriptors General Operation
BIP 380, Output Script Descriptors General Operation. Output Script Descriptors are a simple language which can be used to describe collections of output scripts.
BIP 382 · 2021 · Design paper
Segwit Output Script Descriptors
BIP 382, Segwit Output Script Descriptors. This document specifies wpkh() , and wsh() output script descriptors.
BIP 383 · 2021 · Design paper
Multisig Output Script Descriptors
BIP 383, Multisig Output Script Descriptors. This document specifies multi() , and sortedmulti() output script descriptors.
BIP 386 · 2021 · Design paper
tr() Output Script Descriptors
BIP 386, tr() Output Script Descriptors. This document specifies tr() output script descriptors.
BIP 387 · 2024 · Design paper
Tapscript Multisig Output Script Descriptors
BIP 387, Tapscript Multisig Output Script Descriptors. This document specifies multi_a() and sortedmulti_a() output script descriptors.
EIP 225 · 2017 · Design paper
Clique proof-of-authority consensus protocol
EIP 225, Clique proof-of-authority consensus protocol. Clique is a proof-of-authority consensus protocol.
EIP 747 · 2018 · Design paper
wallet_watchAsset RPC Method
EIP 747, wallet_watchAsset RPC Method. This EIP standardizes a new wallet-scoped RPC method, wallet_watchAsset, to allow a client to suggest a token for the user's wallet to track.
EIP 2255 · 2019 · Design paper
Wallet Permissions System
EIP 2255, Wallet Permissions System. Two new wallet-namespaced RPC endpoints, wallet_getPermissions and wallet_requestPermissions, providing a standard interface for requesting and checking permissions.
EIP 2700 · 2020 · Design paper
JavaScript Provider Event Emitter
EIP 2700, JavaScript Provider Event Emitter. A standard mechanism for JavaScript Ethereum Providers to notify clients about chain state changes when both are able to interface with each other via a shared JavaScript object.
EIP 4736 · 2022 · Design paper
Consensus Layer Withdrawal Protection
EIP 4736, Consensus Layer Withdrawal Protection. If a consensus layer mnemonic phrase is compromised, it is impossible for the consensus layer network to differentiate the legitimate holder of the key from an illegitimate holder.
EIP 7002 · 2023 · Design paper
Execution layer triggerable withdrawals
EIP 7002, Execution layer triggerable withdrawals. Adds a new mechanism to allow validators to trigger withdrawals and exits from their execution layer (0x01) withdrawal credentials.
EIP 7044 · 2023 · Design paper
Perpetually Valid Signed Voluntary Exits
EIP 7044, Perpetually Valid Signed Voluntary Exits. Lock validator voluntary exit signature domain on Capella for perpetual validity.
EIP 7549 · 2023 · Design paper
Move committee index outside Attestation
EIP 7549, Move committee index outside Attestation. Move the committee's index field outside of the signed Attestation message to allow aggregation of equal consensus votes.
EIP 7910 · 2025 · Design paper
eth_config JSON-RPC Method
EIP 7910, eth_config JSON-RPC Method. This document describes an RPC method that provides node-relevant configuration data for the current, next, and last known forks.
ERC 165 · 2018 · Design paper
Standard Interface Detection
ERC 165, Standard Interface Detection. Creates a standard method to publish and detect what interfaces a smart contract implements.
ERC 191 · 2016 · Design paper
Signed Data Standard
ERC 191, Signed Data Standard. We propose the following format for signed_data 0x19 .
ERC 601 · 2017 · Design paper
Ethereum hierarchy for deterministic wallets
ERC 601, Ethereum hierarchy for deterministic wallets. A logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 and eip-draft-ethereum-purpose.
ERC 1046 · 2018 · Design paper
tokenURI Interoperability
ERC 1046, tokenURI Interoperability. ERC-721 introduced a tokenURI function for non-fungible tokens to handle miscellaneous metadata such as: - thumbnail image - title - description - special asset properties - etc.
ERC 1271 · 2018 · Design paper
Standard Signature Validation Method for Contracts
ERC 1271, Standard Signature Validation Method for Contracts. Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot.
ERC 1450 · 2018 · Design paper
RTA-Controlled Security Token
ERC 1450, RTA-Controlled Security Token. ERC-1450 facilitates the recording of ownership and transfer of securities sold in compliance with Securities Act Regulations CF, D, and A.
ERC 2135 · 2019 · Design paper
Consumable Interface (Tickets, etc)
ERC 2135, Consumable Interface (Tickets, etc). An interface to mark a digital asset as "consumable" and to react to its "consumption." Digital assets sometimes need to be consumed.
ERC 2678 · 2020 · Design paper
Revised Ethereum Smart Contract Packaging Standard (EthPM v3)
ERC 2678, Revised Ethereum Smart Contract Packaging Standard (EthPM v3). A data format describing a smart contract software package.
ERC 4337 · 2021 · Design paper
Account Abstraction Using Alt Mempool
ERC 4337, Account Abstraction Using Alt Mempool. Historically, users could interact with Ethereum only by sending transactions from special accounts controlled by private keys, with transaction validation entirely enforced by fixed protocol rules.
ERC 4361 · 2021 · Design paper
Sign-In with Ethereum
ERC 4361, Sign-In with Ethereum. Sign-In with Ethereum describes how Ethereum accounts authenticate with off-chain services by signing a standard message format parameterized by scope, session details, and security mechanisms (e.g., a nonce).
ERC 4519 · 2021 · Design paper
Non-Fungible Tokens Tied to Physical Assets
ERC 4519, Non-Fungible Tokens Tied to Physical Assets. This EIP standardizes an interface for non-fungible tokens representing physical assets, such as Internet of Things (IoT) devices.
ERC 4906 · 2022 · Design paper
EIP-721 Metadata Update Extension
ERC 4906, EIP-721 Metadata Update Extension. Many EIP-721 contracts emit an event when one of its tokens' metadata are changed.
ERC 4955 · 2022 · Design paper
Vendor Metadata Extension for NFTs
ERC 4955, Vendor Metadata Extension for NFTs. This EIP standardizes a schema for NFTs metadata to add new field namespaces to the JSON schema for EIP-721 and EIP-1155 NFTs.
ERC 5006 · 2022 · Design paper
Rental NFT, NFT User Extension
ERC 5006, Rental NFT, NFT User Extension. It proposes an additional role (user) which can be granted to addresses that represent a user of the assets rather than an owner.
ERC 5007 · 2022 · Design paper
Time NFT, ERC-721 Time Extension
ERC 5007, Time NFT, ERC-721 Time Extension. It proposes some additional functions (startTime, endTime) to help with on-chain time management.
ERC 5192 · 2022 · Design paper
Minimal Soulbound NFTs
ERC 5192, Minimal Soulbound NFTs. It proposes a minimal interface to make tokens soulbound using the feature detection functionality of EIP-165.
ERC 5219 · 2022 · Design paper
Contract Resource Requests
ERC 5219, Contract Resource Requests. This EIP standardizes an interface to make resource requests to smart contracts and to receive HTTP-like responses.
ERC 5267 · 2022 · Design paper
Retrieval of EIP-712 domain
ERC 5267, Retrieval of EIP-712 domain. This EIP complements EIP-712 by standardizing how contracts should publish the fields and values that describe their domain.
ERC 5313 · 2022 · Design paper
Light Contract Ownership
ERC 5313, Light Contract Ownership. This specification defines the minimum interface required to identify an account that controls a contract.
ERC 5375 · 2022 · Design paper
NFT Author Information and Consent
ERC 5375, NFT Author Information and Consent. This EIP standardizes a JSON format for storing off-chain information about NFT authors.
ERC 5380 · 2022 · Design paper
ERC-721 Entitlement Extension
ERC 5380, ERC-721 Entitlement Extension. A new interface that allows ERC-721 token owners to grant limited usage of those tokens to other addresses.
ERC 5484 · 2022 · Design paper
Consensual Soulbound Tokens
ERC 5484, Consensual Soulbound Tokens. An interface extending EIP-721 to create soulbound tokens.
ERC 5489 · 2022 · Design paper
NFT Hyperlink Extension
ERC 5489, NFT Hyperlink Extension. A new extension for NFTs (non-fungible token, aka EIP-721): nft-hyperlink-extention (hNFT), embedding NFTs with hyperlinks, referred to as “hNFTs”.
ERC 5507 · 2022 · Design paper
Refundable Tokens
ERC 5507, Refundable Tokens. Refund functionality for initial token offerings to ERC-20, ERC-721, and ERC-1155.
ERC 5516 · 2022 · Design paper
Soulbound Multi-owner Tokens
ERC 5516, Soulbound Multi-owner Tokens. A standard interface for non-transferable, multi-owner Soulbound tokens.
ERC 5570 · 2022 · Design paper
Digital Receipt Non-Fungible Tokens
ERC 5570, Digital Receipt Non-Fungible Tokens. A standard schema for digital receipts of transactions.
ERC 5585 · 2022 · Design paper
ERC-721 NFT Authorization
ERC 5585, ERC-721 NFT Authorization. This EIP separates the ERC-721 NFT's commercial usage rights from its ownership to allow for the independent management of those rights.
ERC 5625 · 2022 · Design paper
NFT Metadata JSON Schema dStorage Extension
ERC 5625, NFT Metadata JSON Schema dStorage Extension. This EIP extends the NFT metadata JSON schema defined in EIP-721 and EIP-1155, adding a dStorage key that provides information about how the NFT data is stored.
ERC 5646 · 2022 · Design paper
Token State Fingerprint
ERC 5646, Token State Fingerprint. This specification defines the minimum interface required to unambiguously identify the state of a mutable token without knowledge of implementation details.
ERC 5679 · 2022 · Design paper
Token Minting and Burning
ERC 5679, Token Minting and Burning. A consistent way to extend token standards for minting and burning.
ERC 5732 · 2022 · Design paper
Commit Interface
ERC 5732, Commit Interface. A simple commit interface to support commit-reveal scheme which provides only a commit method but no reveal method, allowing implementations to integrate this interface with arbitrary reveal methods such as vote or transfer.
ERC 5750 · 2022 · Design paper
General Extensibility for Method Behaviors
ERC 5750, General Extensibility for Method Behaviors. This EIP standardizes the passing of unstructured call data to functions to enable future extensibility.
ERC 6066 · 2022 · Design paper
Signature Validation Method for NFTs
ERC 6066, Signature Validation Method for NFTs. While Externally Owned Accounts can validate signed messages with ecrecover() and smart contracts can validate signatures using specifications outlined in ERC-1271, currently there is no standard method to create or validate signatures made by NFTs.
ERC 6093 · 2022 · Design paper
Custom errors for commonly-used tokens
ERC 6093, Custom errors for commonly-used tokens. A standard set of custom errors for commonly-used tokens, which are defined as ERC-20, ERC-721, and ERC-1155 tokens.
ERC 6381 · 2023 · Design paper
Public Non-Fungible Token Emote Repository
ERC 6381, Public Non-Fungible Token Emote Repository. The Public Non-Fungible Token Emote Repository standard provides an enhanced interactive utility for ERC-721 and ERC-1155 by allowing NFTs to be emoted at.
ERC 6492 · 2023 · Design paper
Signature Validation for Predeploy Contracts
ERC 6492, Signature Validation for Predeploy Contracts. Contracts can sign verifiable messages via ERC-1271.
ERC 6538 · 2023 · Design paper
Stealth Meta-Address Registry
ERC 6538, Stealth Meta-Address Registry. This specification defines a standardized way of storing and retrieving an entity's stealth meta-address, by extending ERC-5564.
ERC 6672 · 2023 · Design paper
Multi-redeemable NFTs
ERC 6672, Multi-redeemable NFTs. An extension to the ERC-721 standard for Non-Fungible Tokens (NFTs) to enable multi-redeemable NFTs.
ERC 6808 · 2023 · Design paper
Fungible Key Bound Token
ERC 6808, Fungible Key Bound Token. A standard interface for Fungible Key Bound Tokens (FKBT/s), a subset of the more general Key Bound Tokens (KBT/s).
ERC 6809 · 2023 · Design paper
Non-Fungible Key Bound Token
ERC 6809, Non-Fungible Key Bound Token. A standard interface for Non-Fungible Key Bound Tokens (NFKBT/s), a subset of the more general Key Bound Tokens (KBT/s).
ERC 6982 · 2023 · Design paper
Efficient Default Lockable Tokens
ERC 6982, Efficient Default Lockable Tokens. This proposal introduces a lockable interface for ERC-721 tokens that optimizes gas usage by eliminating unnecessary events.
ERC 7092 · 2023 · Design paper
Financial Bonds
ERC 7092, Financial Bonds. This proposal introduces fixed-income financial bonds with key characteristics defined to facilitate bond issuance in the primary market and enable buying or selling bonds in the secondary market.
ERC 7160 · 2023 · Design paper
ERC-721 Multi-Metadata Extension
ERC 7160, ERC-721 Multi-Metadata Extension. An extension to the ERC-721 standard to support multiple metadata URIs per token.
ERC 7231 · 2023 · Design paper
Identity-aggregated NFT
ERC 7231, Identity-aggregated NFT. This standard extends ERC-721 by binding individuals' Web2 and Web3 identities to non-fungible tokens (NFTs) and soulbound tokens (SBTs).
ERC 7432 · 2023 · Design paper
Non-Fungible Token Roles
ERC 7432, Non-Fungible Token Roles. This standard introduces role management for NFTs.
ERC 7578 · 2023 · Design paper
Physical Asset Redemption
ERC 7578, Physical Asset Redemption. This proposal is an extension of ERC-721 and implements additional functionality and information pertaining to the NFT’s underlying physical asset by capturing information that enables the holder of physical asset backed NFTs to verify authenticity and facilitate redemption of the underlying physical assets.
ERC 7627 · 2024 · Design paper
Secure Messaging Protocol
ERC 7627, Secure Messaging Protocol. This proposal implements the capability to securely exchange encrypted messages on-chain.
ERC 7631 · 2024 · Design paper
Dual Nature Token Pair
ERC 7631, Dual Nature Token Pair. A fungible ERC-20 token contract and non-fungible ERC-721 token contract can be interlinked, allowing actions performed on one contract to be reflected on the other.
ERC 7634 · 2024 · Design paper
Limited Transfer Count NFT
ERC 7634, Limited Transfer Count NFT. This standard extends ERC-721 with a mechanism that lets token owners/minters cap how many times a specific token can be transferred.
ERC 7656 · 2024 · Design paper
Generalized Contract-Linked Services
ERC 7656, Generalized Contract-Linked Services. This proposal defines a factory capable of deploying generic services linked to specific contracts, such as ERC-4337 accounts or ERC-721 tokens (NFTs).
ERC 7734 · 2024 · Design paper
Decentralized Identity Verification (DID)
ERC 7734, Decentralized Identity Verification (DID). This proposal introduces a standard for decentralized identity verification (DID) on the blockchain.
ERC 7751 · 2024 · Design paper
Wrapping of bubbled up reverts
ERC 7751, Wrapping of bubbled up reverts. A standard for handling bubbled up reverts in Ethereum smart contracts using a dedicated custom error.
ERC 7813 · 2024 · Design paper
Store, Table-Based Introspectable Storage
ERC 7813, Store, Table-Based Introspectable Storage. This standard introduces a flexible on-chain storage pattern that organizes data into structured tables that consist of records with fixed key and value schemas, similar to a traditional database.
ERC 7878 · 2025 · Design paper
Bequeathable Contracts
ERC 7878, Bequeathable Contracts. A standard interface for contracts to allow tokens to be inherited after the owner's death.
ERC 7893 · 2025 · Design paper
DeFi Protocol Solvency Proof Mechanism
ERC 7893, DeFi Protocol Solvency Proof Mechanism. A standardized interface that enables DeFi protocols to implement verifiable solvency proofs through smart contracts.
ERC 7913 · 2025 · Design paper
Signature Verifiers
ERC 7913, Signature Verifiers. Externally Owned Accounts (EOA) can sign messages with their associated private keys.
ERC 7994 · 2025 · Design paper
Purpose-Bound ERC-20 with Conditional Unlock
ERC 7994, Purpose-Bound ERC-20 with Conditional Unlock. This ERC extends the concept introduced in [ERC-7291] by enabling [ERC-20]-compatible tokens to carry multi-condition unlocking constraints, combining temporal, identity, and usage restrictions into a programmable structure.
ERC 8001 · 2025 · Design paper
Agent Coordination Framework
ERC 8001, Agent Coordination Framework. ERC-8001 defines a minimal, single-chain primitive for multi-party agent coordination.
ERC 8034 · 2025 · Design paper
Referable NFT Royalties
ERC 8034, Referable NFT Royalties. Royalty Distribution, a standalone royalty distribution for Referable Non-Fungible Tokens (rNFTs).
ERC 8063 · 2025 · Design paper
Groups - Membership Tokens
ERC 8063, Groups - Membership Tokens. This proposal defines a "Group" as an ERC-20 token where token balance represents membership level.
ERC 8196 · 2026 · Design paper
AI Agent Authenticated Wallet
ERC 8196, AI Agent Authenticated Wallet. A standard interface for AI agent-authenticated wallets.
BIP 310 · 2018 · Design paper
Stratum protocol extensions
BIP 310, Stratum protocol extensions. This BIP provides a generic mechanism for specifying stratum protocol extensions.
BIP 320 · 2018 · Design paper
nVersion bits for general purpose use
BIP 320, nVersion bits for general purpose use. This BIP reserves 16 bits of the block header nVersion field for general purpose use and removes their meaning for the purpose of version bits soft-fork signalling.
BIP 329 · 2022 · Design paper
Wallet Labels Export Format
BIP 329, Wallet Labels Export Format. This document specifies a format for the export of labels that may be attached to various common types of records in a wallet.
BIP 372 · 2022 · Design paper
Pay-to-contract tweak fields for PSBT
BIP 372, Pay-to-contract tweak fields for PSBT. The new per-input type is defined as follows: {| ! Name ! ! ! Description ! ! Description ! Versions Requiring Inclusion ! Versions Requiring Exclusion ! Versions Allowing Inclusion |- | P2C Key Tweak | PSBT_IN_P2C_TWEAK = 0x19 | | 33 bytes of compact public key serialization specifying to which keys the P2C tweak may be applied (i.e.
BIP 375 · 2025 · Design paper
Sending Silent Payments with PSBTs
BIP 375, Sending Silent Payments with PSBTs. This document specifies new fields and new field inclusion/exclusion requirements.
BIP 389 · 2022 · Design paper
Multipath Descriptor Key Expressions
BIP 389, Multipath Descriptor Key Expressions. This document specifies a modification to Key Expressions of Descriptors that are described in BIP 380.
BIP 390 · 2024 · Design paper
musig() Descriptor Key Expression
BIP 390, musig() Descriptor Key Expression. This document specifies a musig() key expression for output script descriptors.
BIP 392 · 2026 · Design paper
Silent Payment Output Script Descriptors
BIP 392, Silent Payment Output Script Descriptors. This document specifies sp() output script descriptors for silent payments.
BIP 393 · 2026 · Design paper
Output Script Descriptor Annotations
BIP 393, Output Script Descriptor Annotations. This document specifies an optional annotation syntax for output script descriptors as defined in [[bip-0380.mediawiki|BIP 380]].
EIP 3076 · 2020 · Design paper
Slashing Protection Interchange Format
EIP 3076, Slashing Protection Interchange Format. A standard format for transferring a key's signing history allows validators to easily switch between clients without the risk of signing conflicting messages.
EIP 7495 · 2023 · Design paper
SSZ ProgressiveContainer
EIP 7495, SSZ ProgressiveContainer. A new Simple Serialize (SSZ) type to represent containers with forward-compatible Merkleization: A given field is always assigned the same stable generalized index (gindex) even when different container versions append new fields or drop existing fields.
EIP 8045 · 2025 · Design paper
Exclude slashed validators from proposing
EIP 8045, Exclude slashed validators from proposing. A modification to the beacon chain proposer selection process to exclude slashed validators from being selected as proposers.
EIP 8066 · 2024 · Design paper
Upgrade Mascots
EIP 8066, Upgrade Mascots. This EIP establishes a mascot for each Ethereum network upgrade.