Blockchain
Powering the Internet of Value
This paper is the result of a research project carried out by Labs in EVRY Financial Services during the fall of 2015.
The Blockchain Canon
Design library
590 foundational papers, connected to what changed when they met the world.
590 public design papers. Each record is a reading: the mechanism, the assumptions, the trade-offs, and what changed after the text. Bitcoin, Ethereum, Stellar, Ripple, Corda, Tether and the other historic PDFs stay at their original paths. The research corpus is the rights and citation layer. It does not replace these readings and it does not republish the papers.
PrivacyConsensusInteroperabilityScalingMarketsCredit and stable valueData and agentsStorage and networksConfidential compute
Privacy
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.
Consensus
Cardano · 2017 · Design paper
Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol
The academic protocol Cardano's settlement layer is built around. It gives a proof-of-stake chain a stated security argument in a synchronous model, with stake electing slot leaders.
Algorand · 2017 · Design paper
ALGORAND: The Efficient and Democratic Ledger
Micali's ledger design: a proof-of-stake protocol that elects a small, unpredictable committee to certify each block, and replaces participants so a corruptor cannot find them in time.
Avalanche · 2018 · Design paper
Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family
A family of consensus protocols that sample the network repeatedly and tip toward one outcome. The 2018 note was pseudonymous. A later write-up adds named co-authors. Avalanche the network is an implementation, not the sample itself.
Solana · 2018 · Design paper
Solana: A new architecture for a high performance blockchain
Yakovenko's design note for a ledger that encodes the passage of time as a verifiable hash chain, called Proof of History, so that validators spend less effort agreeing on order.
Tendermint · 2014 · Design paper
Tendermint: Consensus without Mining
A practical Byzantine-fault-tolerant state machine for a known validator set, with instant finality on commit. It became the consensus engine under Cosmos SDK chains. The 2014 note is the origin, not the current CometBFT specification.
Tezos · 2014 · Design paper
Tezos — a self-amending crypto-ledger
Goodman's proposal for a ledger whose protocol can be amended by a defined on-ledger process, with stakeholders who bake blocks and who may delegate.
Hedera · 2016 · Design paper
The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance
Baird's technical report on hashgraph: gossip about gossip, a virtual vote computed from the graph, and a fairness claim about the order of transactions. Hedera is the later public network that uses the algorithm under a governing council.
Nano · 2017 · Design paper
Nano: A Feeless Distributed Cryptocurrency Network
LeMahieu's design, first published as RaiBlocks: each account has its own chain, and the account holder is the only one who can append to it. Value moves by a send block on one chain and a receive block on another.
Zilliqa · 2017 · Design paper
The ZILLIQA Technical Whitepaper
A 2017 design for a sharded chain: a directory service that assigns nodes, shards that process transactions in parallel, and a language proposal aimed at safe-by-construction contracts.
Harmony · 2019 · Design paper
Harmony Technical Whitepaper
A sharded proof-of-stake design that combines a BFT-style consensus inside shards with a randomness scheme for assigning validators, aimed at keeping a single shard from being captured.
MultiversX · 2019 · Design paper
Elrond: A Highly Scalable Public Blockchain via Adaptive State Sharding
The 2019 Elrond paper on adaptive state sharding: shards that hold state, a metachain that notarises results, and a secure proof-of-stake selection of validators. The network later rebranded as MultiversX. The paper remains the design document.
NEAR · 2019 · Design paper
The NEAR White Paper
NEAR's public design paper: a sharded proof-of-stake chain with a single account model, nightshade-style data availability across chunks, and a stated intent that hiding the shards from application authors is part of the product.
Aptos · 2022 · Design paper
The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infrastructure
Aptos Labs' 2022 paper for a Move-based chain that pipelines dissemination, ordering, execution and certification, and that treats protocol upgrades as a first-class feature rather than a hard-fork event.
Sui · 2022 · Design paper
The Sui Smart Contracts Platform
Mysten Labs' platform paper. Assets are Move objects. Operations on objects owned by a single address can finish by consistent broadcast among validators. Shared objects go through consensus. The split is the design.
Diem · 2020 · Historical document
The Diem Blockchain
The technical paper for the Libra, later Diem, payment chain: a permissioned BFT ledger, a Move language for resources, and a reserve-backed currency proposal. The project was wound down in 2022. The paper still matters because Move, and the account model Aptos and Sui started from, was specified here.
Mina · 2020 · Design paper
Coda: Decentralized Cryptocurrency at Scale
The Coda paper, later the Mina protocol: a chain whose certificate is a constant-size succinct proof, so a client can check the state without replaying history. The project renamed from Coda to Mina. The paper keeps the original name.
TON · 2021 · Design paper
The Open Network
Durov's design for a multi-chain system of account-chains gathered into shardchains, with a masterchain that records the others. It began as Telegram's network design and continued as The Open Network after Telegram stepped away from the original launch.
Kadena · 2018 · Design paper
Chainweb: A Proof-of-Work Parallel-Chain Architecture for Massive Throughput
Kadena's public parallel-chain design. Many proof-of-work chains advance together, and each block commits to peer-chain headers, so a confirmation is a braid rather than a single chain. This is not the 2016 private-chain note already in the historic library.
EOSIO · 2018 · Design paper
EOS.IO Technical White Paper
The 2018 technical paper for EOSIO: delegated proof of stake, named block producers, and an operating-system metaphor for accounts, permissions and resource allocation. It is a design document. It is not a description of later governance fights around any one chain that used the software.
Internet Computer · 2018 · Design paper
DFINITY Consensus System
The DFINITY consensus overview: a randomness beacon, a ranking of block proposers, and notarisation so that a chain can come to agreement quickly among a large set. The Internet Computer is the later network built by the DFINITY foundation on this line of research.
PBFT · 1999 · Design paper
Practical Byzantine Fault Tolerance
The paper that made a Byzantine quorum practical: a known set of replicas, three phases, and a view change when the leader is useless. Tendermint and HotStuff inherit the shape. Open membership is a different problem.
Bitcoin-NG · 2016 · Design paper
Bitcoin-NG: A Scalable Blockchain Protocol
Separate the rare proof-of-work election from the frequent publication of transactions. Key blocks choose a leader. That leader's microblocks carry the transactions until the next key block.
GHOST · 2015 · Design paper
Secure High-Rate Transaction Processing in Bitcoin
At high block rates the longest chain throws away too much honest work. GHOST follows the heaviest subtree, so blocks off the main tip still count for the fork choice.
PHANTOM · 2018 · Design paper
PHANTOM and GHOSTDAG
A blockDAG protocol that still ends in one linear order. Honest blocks cluster. The parameter k is how wide that cluster may be. Kaspa is a later network in this line, not the paper.
SPECTRE · 2016 · Design paper
SPECTRE: A Fast and Scalable Cryptocurrency Protocol
Blocks form a DAG and vote pairwise on which of two blocks came first. In the common case that vote settles quickly. The paper does not promise a total order of every pair, which is why it is a poor fit for general contracts.
Casper FFG · 2017 · Design paper
Casper the Friendly Finality Gadget
A finality overlay. Validators cast two rounds of votes so that a chain of checkpoints becomes justified and then final. Equivocation can be slashed. The gadget does not, by itself, propose blocks.
HotStuff · 2019 · Design paper
HotStuff: BFT Consensus in the Lens of Blockchain
A three-phase BFT protocol whose communication is linear in the number of replicas, because a leader collects a threshold signature instead of everyone talking to everyone. Diem used a variant. The paper is not that network.
HoneyBadgerBFT · 2016 · Design paper
The Honey Badger of BFT Protocols
An asynchronous atomic broadcast. It does not wait for a timeout to make progress, and threshold encryption stops a leader from reading a batch and then dropping the transactions it dislikes.
Narwhal and Tusk · 2022 · Design paper
Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus
Split the mempool from the consensus. Narwhal is a DAG of certified batches. Tusk picks a leader inside that DAG. Later Sui consensus descends from this split. The paper is not a Sui status report.
Snow White · 2017 · Design paper
Snow White: Robustly Reconfigurable Consensus
A proof-of-stake design in the sleepy model: honest nodes may be offline, and the set of stakeholders can change. It is an academic predecessor, not Cardano and not Ethereum.
Thunderella · 2017 · Design paper
Thunderella: Blockchains with Optimistic Instant Confirmation
A fast path and a slow path. If a large supermajority is honest and an accelerator proposes quickly, transactions confirm at network speed. If not, the protocol falls back to an underlying chain.
Proofs of space · 2015 · Design paper
Proofs of Space
A proof that a machine reserved storage, not that it burned energy on a puzzle. The verifier checks a small challenge. Chia is a later system that pairs this idea with a verifiable delay. The paper is not Chia.
Verifiable delay functions · 2018 · Design paper
Verifiable Delay Functions
A function that forces a wait. Evaluating it takes a set number of sequential steps. Checking the result is quick, and the output is unique. Parallel machines do not make the wait much shorter.
Gasper · 2020 · Design paper
Combining GHOST and Casper
An idealised proof-of-stake protocol that pairs a GHOST-style fork choice with Casper FFG finality. The paper is the design argument for Ethereum's beacon chain, not a status report on a later client or a later outage.
Prism · 2019 · Design paper
Deconstructing the Blockchain to Approach Physical Limits
Bitcoin uses one chain for three jobs: proposing transactions, voting on history, and ordering the result. Prism splits those jobs onto separate block trees so throughput can approach network capacity while confirmation tracks propagation delay.
Streamlet · 2020 · Design paper
Streamlet: Textbook Streamlined Blockchains
A deliberately small consensus protocol: epochs, a leader, a vote, and a rule that three adjacent certified blocks on the same chain become final. The point is to show how little machinery the last few years of BFT designs actually need.
FruitChains · 2016 · Design paper
FruitChains: A Fair Blockchain
Nakamoto consensus can pay a minority coalition more than its share of hash power, which is the selfish-mining observation. FruitChains records transactions in 'fruit' that hang off the chain, and pays out over a window so honest hash power gets roughly honest rewards.
DAG-Rider · 2021 · Design paper
All You Need is DAG
Replicas reliably broadcast proposals into a round-structured DAG. Once the DAG is local, each replica can read a total order off it without another round of consensus messages. The paper is the asynchronous, optimally resilient version of that idea.
Bullshark · 2022 · Design paper
Bullshark: DAG BFT Protocols Made Practical
DAG-Rider is built for asynchrony and pays for it on the common path. Bullshark keeps a DAG and a local commit rule, but adds a fast path for when the network is timely. The paper also writes down a simpler partially synchronous version.
Ouroboros Genesis · 2018 · Design paper
Ouroboros Genesis: Composable Proof-of-Stake Blockchains with Dynamic Availability
Genesis gives a way to join late, when honest stake may be dynamic, without a checkpoint the protocol itself cannot justify.
Stake bleeding · 2018 · Design paper
Stake-Bleeding Attacks on Proof-of-Stake Blockchains
The paper shows a long-range style attack in which past stake keeps producing an alternative history unless the protocol makes that history obviously stale.
Bitcoin in asynchronous networks · 2017 · Design paper
Analysis of the Blockchain Protocol in Asynchronous Networks
The paper analyses Nakamoto consensus when the delay bound is not a clean round, and states how confirmation has to grow with that delay.
Stubborn mining · 2016 · Design paper
Stubborn Mining: Generalizing Selfish Mining and Combining with an Eclipse Attack
The paper generalises the withholding strategies and shows they compose with an eclipse attack that starves a node of honest blocks.
Proof-of-work security · 2016 · Design paper
On the Security and Performance of Proof of Work Blockchains
The paper builds a quantitative model of stale blocks, double-spends and selfish mining across proof-of-work parameters.
Dumbo · 2020 · Design paper
Dumbo: Faster Asynchronous BFT Protocols
Dumbo reduces the cost of the asynchronous path by improving the reliable broadcast and the binary agreement that HoneyBadger-style protocols stack together.
Bitcoin SoK · 2015 · Design paper
Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
This systematisation names the stability and consensus questions, the client problems, and the open research problems as of its date. It is a map, not a new protocol.
SpaceMint · 2015 · Design paper
SpaceMint: A Cryptocurrency Based on Proofs of Space
SpaceMint elects a leader from plots of stored data. The quality of the stored answer, not a hash grind at block time, decides who may extend the chain.
Bitcoin as a ledger · 2017 · Design paper
Bitcoin as a Transaction Ledger: A Composable Treatment
The paper gives a composable ledger functionality and shows that a bitcoin-like protocol realises it under stated assumptions.
Shoal · 2024 · Design paper
Shoal: Improving DAG-BFT Latency and Robustness
Shoal pipelines the DAG so a block can commit faster in the good case, and it uses a reputation idea so slow leaders stop dominating the schedule.
Mysticeti · 2023 · Design paper
Mysticeti: Reaching the Limits of Latency with Uncertified DAGs
Mysticeti commits from an uncertified DAG: blocks are signed by their authors and the commit rule does not require a certificate first.
Cordial Miners · 2023 · Design paper
Cordial Miners: Fast and Efficient Consensus for Every Eventuality
Cordial Miners build a DAG with a simple cordial rule for including other miners' blocks, aiming at responsiveness without the certificate tax of the earlier DAG BFTs.
Hashcash · 2002 · Design paper
Hashcash: A Denial of Service Counter-Measure
The client finds a partial hash collision. The server checks it cheaply. The stamp is the cost.
Lamport clocks · 1978 · Design paper
Time, Clocks, and the Ordering of Events in a Distributed System
Lamport clocks number events so that if A happened before B, A's number is smaller. The converse is not true. That one direction is the whole idea.
Bitcoin · 2008 · Design paper
Bitcoin: A Peer-to-Peer Electronic Cash System
Publish every spend to a peer network. Let proof-of-work order the history. The longest chain of work is the ledger honest nodes extend. The first spend of a coin in that chain is the one that counts.
Paxos · 1998 · Design paper
The Part-Time Parliament
A value is chosen only when a majority has accepted it in some ballot, and every higher ballot must honour a value that majority might already have chosen.
Paxos Made Simple · 2001 · Design paper
Paxos Made Simple
The same two-phase majority protocol, written as pseudocode: prepare, accept, and learn.
Raft · 2014 · Design paper
In Search of an Understandable Consensus Algorithm
A strong leader accepts entries, replicates them in order, and commits only when a majority of the current term has stored them.
Byzantine Generals · 1982 · Design paper
The Byzantine Generals Problem
With oral messages, more than two thirds must be loyal. With signed messages, any number of traitors can be tolerated if a loyal commander is heard.
Partial Synchrony · 1988 · Design paper
Consensus in the Presence of Partial Synchrony
Safety can hold with no timing assumption. Liveness can wait for a period, after some unknown instant, when messages arrive within a bound.
FLP · 1985 · Design paper
Impossibility of Distributed Consensus with One Faulty Process
No deterministic protocol does all three. Any protocol that is always safe has an execution that never decides.
Bitcoin Backbone · 2015 · Design paper
The Bitcoin Backbone Protocol
Common prefix, chain quality and chain growth, under a synchronous network and an honest majority of hash power.
Sleepy Consensus · 2017 · Design paper
The Sleepy Model of Consensus
Only awake nodes participate. A public randomness beacon picks a leader from the awake stake. Sleeping nodes do not have to be online to keep their stake safe.
Ouroboros Praos · 2018 · Design paper
Ouroboros Praos: An Adaptively-Secure, Semi-synchronous Proof-of-Stake Protocol
Praos hides who the slot leader is until they speak, and it tolerates a semi-synchronous delay, so an adaptive adversary cannot target the leader in advance.
Selfish Mining · 2014 · Design paper
Majority Is Not Enough: Bitcoin Mining Is Vulnerable
A miner who withholds blocks and releases them to waste honest work can earn more than their share, even below 50 percent, under the paper's propagation assumptions.
Eclipse Attacks · 2015 · Design paper
Eclipse Attacks on Bitcoin's Peer-to-Peer Network
Fill a node's peer table with attacker addresses so every connection the node opens lands on the attacker. The node can then be fed a private view of blocks and transactions.
Flexible Paxos · 2016 · Design paper
Flexible Paxos: Quorum Intersection Revisited
Only quorums from different phases have to intersect. A phase-1 quorum and a phase-2 quorum must overlap. Two phase-2 quorums need not.
EPaxos · 2013 · Design paper
There Is More Consensus in Egalitarian Parliaments
Any replica can propose. Commands that do not conflict commit in one round. Commands that conflict take a second round that records the dependency.
Conflux · 2018 · Design paper
Scaling Nakamoto Consensus to Thousands of Transactions per Second
Keep every block in a directed acyclic graph. A pivot chain picks a total order. Honest blocks that lost the race still contribute security and transactions.
Jolteon and Ditto · 2022 · Design paper
Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback
Jolteon takes two rounds in the happy path. Ditto keeps that path and falls back to an asynchronous protocol when the network or the leader misbehaves.
SBFT · 2019 · Design paper
SBFT: A Scalable and Decentralized Trust Infrastructure for Blockchains
Collectors aggregate signatures into one proof. A client and the replicas see a constant number of messages rather than a quadratic flood, under the paper's collector assumption.
Zyzzyva · 2007 · Design paper
Zyzzyva: Speculative Byzantine Fault Tolerance
Replicas execute the leader's request speculatively and reply. If every replica agrees, the client is done. A disagreement starts a slower path that looks more like PBFT.
Weak Subjectivity · 2014 · Design paper
Proof of Stake: How I Learned to Love Weak Subjectivity
A node that has been offline longer than a known window must take a recent checkpoint from a source it already trusts. Inside the window, the protocol can defend itself.
Raft membership · 2014 · Design paper
Consensus: Bridging Theory and Practice
Membership changes one server at a time, or through joint consensus, so there is never a moment when two disjoint majorities can both commit.
Bitcoin network · 2013 · Design paper
Information Propagation in the Bitcoin Network
Measure how Bitcoin announcements travel. The median time and the long tail are what set a safe block interval.
Verifier's dilemma · 2015 · Design paper
Demystifying Incentives in the Consensus Computer
If checking a block is expensive and the chance it is invalid is small, the equilibrium is not to check. The paper names that gap the verifier's dilemma.
Merged mining · 2017 · Design paper
Merged Mining: Curse or Cure?
Merged mining lets the same proof of work stamp a child chain. Security is not transferred for free: the parent miners may not validate the child, and an attack on the child can be cheap in attention even when hash power is large.
Nothing at stake · 2016 · Design paper
Cryptocurrencies without Proof of Work
The paper studies stake-based chain selection and the cost of signing every fork. It is one of the early formal attempts to replace work with a scarce key.
BIP 16 · 2012 · Design paper
Pay to Script Hash
BIP 16, Pay to Script Hash. A new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions.
BIP 18 · 2012 · Design paper
hashScriptCheck
BIP 18, hashScriptCheck. This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck.
BIP 30 · 2012 · Design paper
Duplicate transactions
BIP 30, Duplicate transactions. This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them.
BIP 34 · 2012 · Design paper
Block v2, Height in Coinbase
BIP 34, Block v2, Height in Coinbase. Bitcoin blocks and transactions are versioned binary structures.
BIP 42 · 2014 · Design paper
A finite monetary supply for Bitcoin
BIP 42, A finite monetary supply for Bitcoin. Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever.
BIP 65 · 2014 · Design paper
OP_CHECKLOCKTIMEVERIFY
BIP 65, OP_CHECKLOCKTIMEVERIFY. A new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future.
BIP 66 · 2015 · Design paper
Strict DER signatures
BIP 66, Strict DER signatures. This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.
BIP 91 · 2017 · Design paper
Reduced threshold Segwit MASF
BIP 91, Reduced threshold Segwit MASF. This document specifies a method to activate the existing BIP9 segwit deployment with a majority hashpower less than 95%.
BIP 94 · 2024 · Design paper
Testnet 4
BIP 94, Testnet 4. A new test network with the goal to replace Testnet 3.
BIP 112 · 2015 · Design paper
CHECKSEQUENCEVERIFY
BIP 112, CHECKSEQUENCEVERIFY. A new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system that in combination with BIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.
BIP 113 · 2015 · Design paper
Median time-past as endpoint for lock-time calculations
BIP 113, Median time-past as endpoint for lock-time calculations. This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block.
BIP 143 · 2016 · Design paper
Transaction Signature Verification for Version 0 Witness Program
BIP 143, Transaction Signature Verification for Version 0 Witness Program. This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.
BIP 147 · 2016 · Design paper
Dealing with dummy stack element malleability
BIP 147, Dealing with dummy stack element malleability. This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY .
BIP 148 · 2017 · Design paper
Mandatory activation of segwit deployment
BIP 148, Mandatory activation of segwit deployment. This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
BIP 342 · 2020 · Design paper
Validation of Taproot Scripts
BIP 342, Validation of Taproot Scripts. The rules below only apply when validating a transaction input for which all of the conditions below are true: The transaction input is a '''segregated witness spend''' (i.e., the scriptPubKey contains a witness program as defined in [[bip-0141.mediawiki|BIP141]]).
EIP 2982 · 2020 · Design paper
Serenity Phase 0
EIP 2982, Serenity Phase 0. Phase 0 of Serenity (eth2), a multi-phased upgrade to the consensus mechanism for Ethereum mainnet.
EIP 3675 · 2021 · Design paper
Upgrade consensus to Proof-of-Stake
EIP 3675, Upgrade consensus to Proof-of-Stake. This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain.
EIP 4881 · 2021 · Design paper
Deposit Contract Snapshot Interface
EIP 4881, Deposit Contract Snapshot Interface. A standard format for transmitting the deposit contract Merkle tree in a compressed form during weak subjectivity sync.
EIP 6110 · 2022 · Design paper
Supply validator deposits on chain
EIP 6110, Supply validator deposits on chain. Appends validator deposits to the Execution Layer block structure.
EIP 6916 · 2023 · Design paper
Automatically Reset Testnet
EIP 6916, Automatically Reset Testnet. A specification for an automatically reset testnet, a novel approach to testnets that can be implemented within Ethereum clients.
EIP 6953 · 2023 · Design paper
Network Upgrade Activation Triggers
EIP 6953, Network Upgrade Activation Triggers. This EIP outlines the various network upgrade activation triggers used on Ethereum over time, from the proof-of-work era to the first post-merge network upgrade, Shanghai/Capella, across both the execution and consensus layers.
EIP 7045 · 2023 · Design paper
Increase max attestation inclusion slot
EIP 7045, Increase max attestation inclusion slot. Increases max attestation inclusion slot from attestation.slot + SLOTS_PER_EPOCH to the last slot of epoch N+1 where N is the epoch containing the attestation slot.
EIP 7685 · 2024 · Design paper
General purpose execution layer requests
EIP 7685, General purpose execution layer requests. This proposal defines a general purpose framework for storing contract-triggered requests.
EIP 7870 · 2025 · Design paper
Hardware and Bandwidth Recommendations
EIP 7870, Hardware and Bandwidth Recommendations. This proposal specifies hardware and bandwidth recommendations for different types of Ethereum nodes: - Full nodes: Nodes that follow the tip of the chain without necessarily proposing blocks.
EIP 7917 · 2025 · Design paper
Deterministic proposer lookahead
EIP 7917, Deterministic proposer lookahead. At the start of each epoch, pre-calculate and store in the beacon_state a deterministic proposer_lookahead for the next MIN_SEED_LOOKAHEAD + 1 epochs.
EIP 7934 · 2025 · Design paper
RLP Execution Block Size Limit
EIP 7934, RLP Execution Block Size Limit. This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 2 MiB to account for beacon block sizes.
BIP 53 · 2025 · Design paper
Disallow 64-byte transactions
BIP 53, Disallow 64-byte transactions. The rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
BIP 98 · 2017 · Design paper
Fast Merkle Trees
BIP 98, Fast Merkle Trees. In many applications it is useful to prove membership of a data element in a set without having to reveal the entire contents of that set.
BIP 116 · 2017 · Design paper
MERKLEBRANCHVERIFY
BIP 116, MERKLEBRANCHVERIFY. A general approach to bitcoin contracts is to fully enumerate the possible spending conditions and then program verification of these conditions into a single script.
BIP 117 · 2017 · Design paper
Tail Call Execution Semantics
BIP 117, Tail Call Execution Semantics. BIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] provide mechanisms by which script policy can be revealed at spend time as part of the execution witness.
BIP 118 · 2017 · Design paper
SIGHASH_ANYPREVOUT for Taproot Scripts
BIP 118, SIGHASH_ANYPREVOUT for Taproot Scripts. This BIP modifies the behaviour of the [[bip-0342.mediawiki|BIP 342]] signature opcodes '''What about key path spends?''' This proposal only supports ANYPREVOUT signatures via script path spends, and does not support ANYPREVOUT signatures for key path spends.
BIP 119 · 2020 · Design paper
CHECKTEMPLATEVERIFY
BIP 119, CHECKTEMPLATEVERIFY. A new opcode, OP_CHECKTEMPLATEVERIFY, to be activated as a change to the semantics of OP_NOP4.
BIP 301 · 2019 · Design paper
Blind Merged Mining (Consensus layer)
BIP 301, Blind Merged Mining (Consensus layer). Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").
BIP 360 · 2024 · Design paper
Pay-to-Merkle-Root (P2MR)
BIP 360, Pay-to-Merkle-Root (P2MR). We define the Pay-to-Merkle-Root (P2MR) output structure as follows: A P2MR output is similar to a P2TR output (as defined in [[bip-0341.mediawiki|BIP 341]]); however, unlike P2TR outputs, we disable the key path spend for the benefit of quantum resistance by omitting the internal key and the tap tweak step.
BIP 361 · 2026 · Design paper
Post Quantum Migration and Legacy Signature Sunset
BIP 361, Post Quantum Migration and Legacy Signature Sunset. {| class="wikitable" |- style="text-align:center;" ! Phase ! What Happens ! Who Must Act ! Time Horizon |- | A | Permitted sends are from legacy scripts to PQ scripts.
BIP 443 · 2025 · Design paper
OP_CHECKCONTRACTVERIFY
BIP 443, OP_CHECKCONTRACTVERIFY. To add consensus support for a new tapscript opcode that enables a new type of output restrictions: OP_CHECKCONTRACTVERIFY ( OP_CCV ).
EIP 7688 · 2024 · Design paper
Forward compatible consensus data structures
EIP 7688, Forward compatible consensus data structures. The changes needed to adopt ProgressiveContainer from EIP-7495 and ProgressiveList from EIP-7916 in consensus data structures.
EIP 7916 · 2025 · Design paper
SSZ ProgressiveList
EIP 7916, SSZ ProgressiveList. A new Merkle tree shape for Simple Serialize (SSZ) types that results in fewer hashes when only a small number of leaves is used.
EIP 8061 · 2025 · Design paper
Increase exit and consolidation churn
EIP 8061, Increase exit and consolidation churn. This EIP roughly doubles the consolidation churn, as well as quadrupling the exit churn and restoring its proportionality to total stake (though maintaining the existing cap on activations).
EIP 8261 · 2026 · Design paper
Gas Limit Schedule
EIP 8261, Gas Limit Schedule. This EIP recommends that, starting with Gloas (EIP-7732), consensus layer clients source their gas limit preference from an optional GAS_LIMIT_SCHEDULE field in the consensus layer config.yaml instead of hardcoded, release-scoped defaults.
Interoperability
Polkadot · 2016 · Design paper
Polkadot: Vision for a heterogeneous multi-chain framework
Wood's 2016 vision paper: a relay chain that provides shared security and a queue of cross-chain messages, with parachains that keep their own state transition. It is a vision paper. The live protocol has a specification of its own.
Cosmos · 2016 · Design paper
Cosmos: A Network of Distributed Ledgers
The Cosmos paper: independent zones running a BFT consensus, connected by a hub, speaking a packet protocol that later became IBC. Unlike Polkadot's shared-security vision, zones here are sovereign. They choose their own validator sets.
Atomic swaps · 2018 · Design paper
Atomic Cross-Chain Swaps
A swap across ledgers where either every transfer completes or none does, using hash locks and time locks. There is no custodian in the paper. A party can still walk away and leave the other waiting.
Sprites · 2017 · Design paper
Sprites and State Channels
State channels whose disputes do not have to hop one channel at a time. A global preimage manager lets a payment resolve in constant time on-chain. Lightning did not adopt this design as its production path.
IBC · 2020 · Design paper
The Interblockchain Communication Protocol
Two chains verify each other with light clients. A relayer carries packets and proofs. The relayer is not trusted to tell the truth. It is trusted to bother showing up. Security is the security of both chains.
Payment channels · 2013 · Design paper
Bitcoin Payment Channels
Two parties lock coins in a shared output and exchange updated transactions that are not broadcast. Only the last state, or a dispute, hits the chain.
Eltoo · 2018 · Design paper
eltoo: A Simplified Update Mechanism for Lightning
Eltoo replaces penalties with a sequence of state numbers. A later state can spend an earlier one. Nothing is confiscated. The latest number wins if it is published in time.
Channel factories · 2018 · Design paper
Scalable Funding of Bitcoin Micropayment Channel Networks
A factory is a shared on-chain output that several parties can use to allocate many channels off-chain, so the chain sees the factory and not every channel.
BIP 68 · 2015 · Design paper
Relative lock-time using consensus-enforced sequence numbers
BIP 68, Relative lock-time using consensus-enforced sequence numbers. Relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
BIP 347 · 2023 · Design paper
OP_CAT in Tapscript
BIP 347, OP_CAT in Tapscript. OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack.
EIP 152 · 2016 · Design paper
Add BLAKE2 compression function `F` precompile
EIP 152, Add BLAKE2 compression function `F` precompile. This EIP will enable the BLAKE2b hash function and other higher-round 64-bit BLAKE2 variants to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins.
EIP 4788 · 2022 · Design paper
Beacon block root in the EVM
EIP 4788, Beacon block root in the EVM. Commit to the hash tree root of each beacon chain block in the corresponding execution payload header.
ERC 1328 · 2018 · Design paper
WalletConnect URI Format
ERC 1328, WalletConnect URI Format. This standard defines how the data to connect some application and a wallet can be encoded with a URI.
ERC 7786 · 2024 · Design paper
Cross-Chain Messaging Gateway
ERC 7786, Cross-Chain Messaging Gateway. This proposal describes an interface, and the corresponding workflow, for smart contracts to send arbitrary data through cross-chain messaging protocols.
ERC 7943 · 2025 · Design paper
uRWA - Universal Real World Asset Interface
ERC 7943, uRWA - Universal Real World Asset Interface. The Universal RWA (uRWA) standard, a set of interfaces for tokenized Real World Assets (RWAs) such as securities, real estate, commodities, or other physical/financial assets on the blockchain.
BIP 197 · 2019 · Design paper
Hashed Time-Locked Collateral Contract
BIP 197, Hashed Time-Locked Collateral Contract. A script for generalized debt agreement contract based on Hashed Time-Lock Contract (BIP 199) transactions according to the Atomic Loans specification (https://arxiv.org/pdf/1901.05117.pdf).
BIP 300 · 2017 · Design paper
Hashrate Escrows (Consensus layer)
BIP 300, Hashrate Escrows (Consensus layer). BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- instead of a federation or fixed set of pubkeys.
BIP 326 · 2021 · Design paper
Anti-fee-sniping in taproot transactions
BIP 326, Anti-fee-sniping in taproot transactions. This document proposes a certain type of wallet behaviour which uses BIP341 taproot[1].
Scaling
Lightning · 2016 · Design paper
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
Poon and Dryja's 2016 design for Bitcoin payments that stay off the main chain inside penalty-backed channels, and that route across a network of those channels using hashed timelock contracts.
Plasma · 2017 · Design paper
Plasma: Scalable Autonomous Smart Contracts
A 2017 construction for trees of child chains whose state commitments are posted to a parent chain, with exits so a user can leave if the child operator misbehaves. It is an ancestor of later rollup and validium designs, not a synonym for them.
Arbitrum · 2018 · Design paper
Arbitrum: Scalable, private smart contracts
The 2018 USENIX paper on Arbitrum: a verifier that checks a manager's execution of a virtual machine by bisecting disputes, instead of re-executing every instruction. Offchain Labs' later Nitro stack is a descendant, not this paper line for line.
StarkWare · 2018 · Design paper
Scalable, transparent, and post-quantum secure computational integrity
The STARK paper: proofs of computational integrity that are succinct, do not need a trusted setup, and are argued to resist quantum attackers on the underlying hashes. StarkWare's later systems, including StarkEx and Starknet, are built on this proof system. They are not identical to it.
Celestia · 2019 · Design paper
LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts
Al-Bassam's LazyLedger paper, the research origin of Celestia. The base layer orders and makes data available. It does not execute application transitions. Clients check availability with sampling, and applications execute on their own.
EigenLayer · 2023 · Design paper
EigenLayer: The Restaking Collective
Eigen Labs' design for letting Ethereum stakers opt in to additional slashing conditions, so new services can rent economic security instead of bootstrapping a new token set from zero.
Polygon · 2019 · Design paper
Matic Network white paper
The 2019 Matic paper for a Plasma-inspired sidechain with a proof-of-stake checkpoint layer posting to Ethereum. Polygon is the later organisation and product family. This page is about the 2019 document, not about every subsequent Polygon stack.
Fraud and data availability proofs · 2018 · Design paper
Fraud and Data Availability Proofs
Light clients can refuse a block if a fraud proof shows it is invalid, but only if the block's data was actually published. The paper shows how erasure coding and sampling let clients check publication without downloading everything.
TrueBit · 2017 · Design paper
A scalable verification solution for blockchains
Pay a solver to run a heavy computation off-chain, and pay a verifier only when they find a lie. An interactive game narrows the lie to one step. A jackpot is there so verifiers show up even when solvers are usually honest.
KZG commitments · 2010 · Design paper
Constant-Size Commitments to Polynomials and Their Applications
Commit to a polynomial and later open it at a point, in constant size, with a pairing. The commitment is binding if the setup's trapdoor stays secret. Modern data-availability schemes use this as a brick. The paper is older than those schemes.
EIP-4844 · 2022 · Design paper
Shard Blob Transactions
A new transaction type carries a blob: a large chunk of data that consensus nodes hold briefly and that the execution layer cannot read byte by byte. Rollups are the intended user. The blob is not cheap forever, and it is not the rollup's proof.
BitVM · 2023 · Design paper
BitVM: Compute Anything on Bitcoin
A way to dispute an arbitrary computation between two Bitcoin parties using hashlocks, timelocks and large Taproot trees, without a new opcode. Honest execution stays off-chain. A false claim can be challenged on-chain. It is not a global virtual machine.
Cairo · 2021 · Design paper
Cairo – a Turing-complete STARK-friendly CPU architecture
A CPU whose every instruction was chosen so that a STARK can prove 'this program ran'. You write a program instead of a new set of polynomial equations for each statement. The paper is the machine, not a network's throughput.
Perun · 2017 · Design paper
Perun: Virtual Payment Hubs over Cryptocurrencies
Lightning routes each payment through the intermediaries. Perun asks those intermediaries to set up a virtual channel and then step out of the individual payments. The paper gives the construction for one hub, on a chain that can run the contracts.
OmniLedger · 2018 · Design paper
OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding
OmniLedger reassigns validators to shards, uses a bias-resistant randomness beacon, and atomically commits cross-shard transactions.
RapidChain · 2018 · Design paper
RapidChain: Scaling Blockchain via Full Sharding
RapidChain shards the ledger completely and uses a committee protocol that tolerates a smaller honest fraction inside a committee than a classical open network.
SuperNova · 2022 · Design paper
SuperNova: Proving Universal Machine Executions without Universal Circuits
SuperNova folds a universal machine by switching among circuits without a universal circuit that contains every instruction.
HyperNova · 2023 · Design paper
HyperNova: Recursive Arguments for Customizable Constraint Systems
HyperNova generalises folding to customisable constraint systems so a recursive proof can follow the arithmetisation the circuit actually uses.
Vault · 2019 · Design paper
Vault: Fast Bootstrapping for the Algorand Cryptocurrency
Vault compresses Algorand's state and the proofs a client needs so a bootstrapping node does not replay the entire history.
OHIE · 2020 · Design paper
OHIE: Blockchain Scaling Made Simple
Run many parallel Nakamoto chains. A block is assigned to a chain by its hash. The safety argument stays close to bitcoin's, and the throughput is the sum.
Chainspace · 2017 · Design paper
Chainspace: A Sharded Smart Contracts Platform
Chainspace shards objects, and a transaction names the objects it will read and write so the shards involved can run a distributed commit.
Optimism Cannon · 2023 · Design paper
The Fault Proof System
A dispute walks a single instruction of a state transition on a parent chain, so anyone who can post a bond can force the on-chain step that decides a bad proposal.
Sovereign rollups · 2022 · Design paper
Rollups as Sovereign Chains
Publish transaction data to a data-availability layer. Let the rollup's own nodes interpret it. Fraud or validity proofs are checked by those nodes, not by an Ethereum bridge, unless someone adds one.
Validium · 2020 · Design paper
Validium and the Data-Availability Spectrum
Validium proves execution and keeps the data off the parent chain, with a committee or another store. Volition lets a user choose, per state, whether the data sits on the parent.
Based rollups · 2023 · Design paper
Based Rollups
A based rollup lets the parent's proposers order the rollup's transactions. There is no separate sequencer to bribe or to wait for.
Espresso · 2022 · Design paper
The Espresso Sequencer
A shared sequencer orders transactions for many rollups. Each rollup still executes its own state. The sequencer sells order, not execution.
Verkle trees · 2018 · Design paper
Verkle Trees
Verkle trees use vector commitments so a proof of many leaves shares one commitment path. The proof is shorter, at the cost of a polynomial-commitment assumption.
BIP 141 · 2015 · Design paper
Segregated Witness
Move witness data outside the input script. The transaction id that contracts depend on no longer covers the witness. A new weight limit counts witness bytes less than base bytes.
BIP 35 · 2012 · Design paper
mempool message
BIP 35, mempool message. Make a network node's transaction memory pool accessible via a new "mempool" message.
BIP 37 · 2012 · Design paper
Connection Bloom filtering
BIP 37, Connection Bloom filtering. New support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent.
BIP 67 · 2015 · Design paper
Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
BIP 67, Deterministic Pay-to-script-hash multi-signature addresses through public key sorting. A method to deterministically generate multi-signature pay-to-script-hash transaction scripts.
BIP 87 · 2020 · Design paper
Hierarchy for Deterministic Multisig Wallets
BIP 87, Hierarchy for Deterministic Multisig Wallets. A sane hierarchy for deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on).
BIP 90 · 2016 · Design paper
Buried Deployments
BIP 90, Buried Deployments. Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers.
BIP 125 · 2015 · Design paper
Opt-in Full Replace-by-Fee Signaling
BIP 125, Opt-in Full Replace-by-Fee Signaling. Many nodes today will not replace any transaction in their mempool with another transaction that spends the same inputs, making it difficult for spenders to adjust their previously-sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.
BIP 144 · 2016 · Design paper
Segregated Witness (Peer Services)
BIP 144, Segregated Witness (Peer Services). New messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.
BIP 157 · 2017 · Design paper
Client Side Block Filtering
BIP 157, Client Side Block Filtering. A new light client protocol in Bitcoin that improves upon currently available options.
BIP 352 · 2023 · Design paper
Silent Payments
BIP 352, Silent Payments. We use the following functions and conventions: ''outpoint'' (36 bytes): the COutPoint of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first) '''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian.
BIP 388 · 2023 · Design paper
Wallet Policies for Descriptor Wallets
BIP 388, Wallet Policies for Descriptor Wallets. Software wallets and hardware signing devices typically partition funds into separate "accounts".
EIP 140 · 2017 · Design paper
REVERT instruction
EIP 140, REVERT instruction. The REVERT instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.
EIP 141 · 2017 · Design paper
Designated invalid EVM instruction
EIP 141, Designated invalid EVM instruction. An instruction is designated to remain as an invalid instruction.
EIP 145 · 2017 · Design paper
Bitwise shifting instructions in EVM
EIP 145, Bitwise shifting instructions in EVM. Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract.
EIP 196 · 2017 · Design paper
Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128
EIP 196, Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.
EIP 197 · 2017 · Design paper
Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128
EIP 197, Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.
EIP 211 · 2017 · Design paper
New opcodes: RETURNDATASIZE and RETURNDATACOPY
EIP 211, New opcodes: RETURNDATASIZE and RETURNDATACOPY. A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now.
EIP 214 · 2017 · Design paper
New opcode STATICCALL
EIP 214, New opcode STATICCALL. To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).
EIP 658 · 2017 · Design paper
Embedding transaction status code in receipts
EIP 658, Embedding transaction status code in receipts. This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed.
EIP 684 · 2023 · Design paper
Revert creation in case of collision
EIP 684, Revert creation in case of collision. This EIP causes contract creation to throw an error when attempted at an address with pre-existing code.
EIP 712 · 2017 · Design paper
Typed structured data hashing and signing
EIP 712, Typed structured data hashing and signing. This is a standard for hashing and signing of typed structured data as opposed to just bytestrings.
EIP 1052 · 2018 · Design paper
EXTCODEHASH opcode
EIP 1052, EXTCODEHASH opcode. A new opcode, which returns the keccak256 hash of a contract's code.
EIP 1108 · 2018 · Design paper
Reduce alt_bn128 precompile gas costs
EIP 1108, Reduce alt_bn128 precompile gas costs. The elliptic curve arithmetic precompiles are currently overpriced.
EIP 1153 · 2018 · Design paper
Transient storage opcodes
EIP 1153, Transient storage opcodes. This proposal introduces transient storage opcodes, which manipulate state that behaves identically to storage, except that transient storage is discarded after every transaction, and TSTORE is not subject to the gas stipend check as defined in EIP-2200.
EIP 1283 · 2018 · Design paper
Net gas metering for SSTORE without dirty maps
EIP 1283, Net gas metering for SSTORE without dirty maps. Net gas metering changes for SSTORE opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn't match how most implementations work.
EIP 1344 · 2018 · Design paper
ChainID opcode
EIP 1344, ChainID opcode. An opcode that returns the current chain's EIP-155 unique identifier.
EIP 1884 · 2019 · Design paper
Repricing for trie-size-dependent opcodes
EIP 1884, Repricing for trie-size-dependent opcodes. Repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption.
EIP 2028 · 2019 · Design paper
Transaction data gas cost reduction
EIP 2028, Transaction data gas cost reduction. We propose to reduce the gas cost of Calldata (GTXDATANONZERO) from its current value of 68 gas per byte to 16 gas per byte, to be backed by mathematical modeling and empirical estimates.
EIP 2200 · 2019 · Design paper
Structured Definitions for Net Gas Metering
EIP 2200, Structured Definitions for Net Gas Metering. It's a combined version of [EIP-1283] and [EIP-1706], with a structured definition so as to make it interoperable with other gas changes such as [EIP-1884].
EIP 2364 · 2019 · Design paper
eth/64: forkid-extended protocol handshake
EIP 2364, eth/64: forkid-extended protocol handshake. The inclusion of the forkid, originally defined in (EIP-2124), as a new field in the Ethereum wire protocol (eth) handshake.
EIP 2537 · 2020 · Design paper
Precompile for BLS12-381 curve operations
EIP 2537, Precompile for BLS12-381 curve operations. Add functionality to efficiently perform operations over the BLS12-381 curve, including those for BLS signature verification.
EIP 2565 · 2020 · Design paper
ModExp Gas Cost
EIP 2565, ModExp Gas Cost. Defines the gas cost of the ModExp (0x00..05) precompile.
EIP 2929 · 2020 · Design paper
Gas cost increases for state access opcodes
EIP 2929, Gas cost increases for state access opcodes. Increases gas cost for SLOAD, CALL, BALANCE, EXT and SELFDESTRUCT when used for the first time in a transaction.
EIP 2930 · 2020 · Design paper
Optional access lists
EIP 2930, Optional access lists. Adds a transaction type which contains an access list, a list of addresses and storage keys that the transaction plans to access.
EIP 2935 · 2020 · Design paper
Serve historical block hashes from state
EIP 2935, Serve historical block hashes from state. Store last HISTORY_SERVE_WINDOW historical block hashes in the storage of a system contract as part of the block processing logic.
EIP 3198 · 2021 · Design paper
BASEFEE opcode
EIP 3198, BASEFEE opcode. Adds an opcode that gives the EVM access to the block's base fee.
EIP 3529 · 2021 · Design paper
Reduction in refunds
EIP 3529, Reduction in refunds. Remove gas refunds for SELFDESTRUCT, and reduce gas refunds for SSTORE to a lower level where the refunds are still substantial, but they are no longer high enough for current "exploits" of the refund mechanism to be viable.
EIP 3541 · 2021 · Design paper
Reject new contract code starting with the 0xEF byte
EIP 3541, Reject new contract code starting with the 0xEF byte. Disallow new code starting with the 0xEF byte to be deployed.
EIP 3607 · 2021 · Design paper
Reject transactions from senders with deployed code
EIP 3607, Reject transactions from senders with deployed code. Ethereum addresses are currently only 160 bits long.
EIP 3651 · 2021 · Design paper
Warm COINBASE
EIP 3651, Warm COINBASE. The COINBASE address shall be warm at the start of transaction execution, in accordance with the actual cost of reading that account.
EIP 3860 · 2021 · Design paper
Limit and meter initcode
EIP 3860, Limit and meter initcode. We extend EIP-170 by introducing a maximum size limit for initcode (MAX_INITCODE_SIZE = 2 MAX_CODE_SIZE = 49152).
EIP 4399 · 2021 · Design paper
Supplant DIFFICULTY opcode with PREVRANDAO
EIP 4399, Supplant DIFFICULTY opcode with PREVRANDAO. This EIP supplants the semantics of the return value of existing DIFFICULTY (0x44) opcode and renames the opcode to PREVRANDAO (0x44).
EIP 4895 · 2022 · Design paper
Beacon chain push withdrawals as operations
EIP 4895, Beacon chain push withdrawals as operations. Introduce a system-level "operation" to support validator withdrawals that are "pushed" from the beacon chain to the EVM.
EIP 5656 · 2021 · Design paper
MCOPY - Memory copying instruction
EIP 5656, MCOPY - Memory copying instruction. Provide an efficient EVM instruction for copying memory areas.
EIP 5749 · 2022 · Design paper
The 'window.evmproviders' object
EIP 5749, The 'window.evmproviders' object. A Javascript Ethereum Provider interface injection that will allow for the interoperability of multiple browser wallets at the same time.
EIP 5793 · 2022 · Design paper
eth/68 - Add tx type to tx announcement
EIP 5793, eth/68 - Add tx type to tx announcement. The Ethereum Wire Protocol defines request and response messages for exchanging data between clients.
EIP 6780 · 2023 · Design paper
SELFDESTRUCT only in same transaction
EIP 6780, SELFDESTRUCT only in same transaction. This EIP changes the functionality of the SELFDESTRUCT opcode.
EIP 7251 · 2023 · Design paper
Increase the MAX_EFFECTIVE_BALANCE
EIP 7251, Increase the MAX_EFFECTIVE_BALANCE. Increases the constant MAX_EFFECTIVE_BALANCE, while keeping the minimum staking balance 32 ETH.
EIP 7516 · 2023 · Design paper
BLOBBASEFEE instruction
EIP 7516, BLOBBASEFEE instruction. Add a BLOBBASEFEE (0x4a) instruction that returns the value of the blob base-fee of the current block it is executing in.
EIP 7594 · 2024 · Design paper
PeerDAS - Peer Data Availability Sampling
EIP 7594, PeerDAS - Peer Data Availability Sampling. PeerDAS (Peer Data Availability Sampling) is a networking protocol that allows nodes to perform data availability sampling (DAS) to ensure that blob data has been made available while downloading only a subset of the data.
EIP 7623 · 2024 · Design paper
Increase calldata cost
EIP 7623, Increase calldata cost. The current calldata pricing permits EL payloads of up to 7.15 MB, while the average size is much smaller at around 100 KB.
EIP 7691 · 2024 · Design paper
Blob throughput increase
EIP 7691, Blob throughput increase. Increases the number of blobs in a block to provide more scale to Ethereum via L2 solution that rely on L1 data capacity.
EIP 7823 · 2024 · Design paper
Set upper bounds for MODEXP
EIP 7823, Set upper bounds for MODEXP. Introduce an upper bound on the inputs of the MODEXP precompile.
EIP 7825 · 2024 · Design paper
Transaction Gas Limit Cap
EIP 7825, Transaction Gas Limit Cap. This proposal introduces a protocol-level cap on the maximum gas usage per transaction to 16,777,216 (2^24) gas.
EIP 7840 · 2024 · Design paper
Add blob schedule to EL config files
EIP 7840, Add blob schedule to EL config files. Add a new object to client configuration files blobSchedule which lists the target blob count per block and max blob count per block for each fork.
EIP 7883 · 2025 · Design paper
ModExp Gas Cost Increase
EIP 7883, ModExp Gas Cost Increase. This EIP is modifying the ModExp precompile pricing algorithm introduced in EIP-2565.
EIP 7892 · 2025 · Design paper
Blob Parameter Only Hardforks
EIP 7892, Blob Parameter Only Hardforks. Blob Parameter Only (BPO) Hardforks, a lightweight mechanism for incrementally scaling Ethereum’s blob capacity through targeted hard forks that modify only blob-related parameters: target, max, and baseFeeUpdateFraction.
EIP 7918 · 2025 · Design paper
Blob base fee bounded by execution cost
EIP 7918, Blob base fee bounded by execution cost. This EIP assigns a reserve price BLOB_BASE_COST base_fee_per_gas to blobs by introducing an if-clause in calc_excess_blob_gas().
EIP 7939 · 2025 · Design paper
Count leading zeros (CLZ) opcode
EIP 7939, Count leading zeros (CLZ) opcode. Introduce a new opcode, CLZ(x), which pops x from the stack and pushes the number of leading zero bits in x to the stack.
EIP 7951 · 2025 · Design paper
Precompile for secp256r1 Curve Support
EIP 7951, Precompile for secp256r1 Curve Support. Add functionality to efficiently perform ECDSA signature verification over the secp256r1 elliptic curve (also known as P-256 or prime256v1).
ERC 223 · 2017 · Design paper
Token with transaction handling model
ERC 223, Token with transaction handling model. The following describes an interface and logic for fungible tokens that supports a tokenReceived callback to notify contract recipients when tokens are received.
ERC 1167 · 2018 · Design paper
Minimal Proxy Contract
ERC 1167, Minimal Proxy Contract. To simply and cheaply clone contract functionality in an immutable way, this standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address.
ERC 1967 · 2019 · Design paper
Proxy Storage Slots
ERC 1967, Proxy Storage Slots. Delegating proxy contracts are widely used for both upgradeability and gas savings.
ERC 2098 · 2019 · Design paper
Compact Signature Representation
ERC 2098, Compact Signature Representation. The secp256k1 curve permits the computation of the public key of signed digest when coupled with a signature, which is used implicitly to establish the origin of a transaction from an Externally Owned Account as well as on-chain in EVM contracts for example, in meta-transactions and multi-sig contracts.
ERC 2612 · 2020 · Design paper
Permit Extension for EIP-20 Signed Approvals
ERC 2612, Permit Extension for EIP-20 Signed Approvals. Arguably one of the main reasons for the success of EIP-20 tokens lies in the interplay between approve and transferFrom, which allows for tokens to not only be transferred between externally owned accounts (EOA), but to be used in other contracts under application specific conditions by abstracting away msg.sender as the defining mechanism for token access control.
ERC 2771 · 2020 · Design paper
Secure Protocol for Native Meta Transactions
ERC 2771, Secure Protocol for Native Meta Transactions. A contract-level protocol for Recipient contracts to accept meta-transactions through trusted Forwarder contracts.
ERC 3475 · 2021 · Design paper
Abstract Storage Bonds
ERC 3475, Abstract Storage Bonds. The creation of tokenized obligations with abstract on-chain metadata storage.
ERC 4804 · 2022 · Design paper
Web3 URL to EVM Call Message Translation
ERC 4804, Web3 URL to EVM Call Message Translation. This standard translates an RFC 2396 URI like web3://uniswap.eth/ to an EVM message such as: EVMMessage { To: 0xaabbccddee....
ERC 4834 · 2022 · Design paper
Hierarchical Domains
ERC 4834, Hierarchical Domains. This is a standard for generic name resolution with arbitrarily complex access control and resolution.
ERC 5202 · 2022 · Design paper
Blueprint contract format
ERC 5202, Blueprint contract format. Define a standard for "blueprint" contracts, or contracts which represent initcode that is stored on-chain.
ERC 5564 · 2022 · Design paper
Stealth Addresses
ERC 5564, Stealth Addresses. This specification establishes a standardized method for interacting with stealth addresses, which allow senders of transactions or transfers to non-interactively generate private accounts exclusively accessible by their recipients.
ERC 7053 · 2023 · Design paper
Interoperable Digital Media Indexing
ERC 7053, Interoperable Digital Media Indexing. An interoperable indexing strategy designed to enhance the organization and retrieval of digital media information across multiple smart contracts and EVM-compatible blockchains.
ERC 7588 · 2024 · Design paper
Blob Transactions Metadata JSON Schema
ERC 7588, Blob Transactions Metadata JSON Schema. A standard for attaching metadata to blobs carried by blob transactions, as outlined in EIP-4844.
ERC 7857 · 2025 · Design paper
AI Agents NFT with Private Metadata
ERC 7857, AI Agents NFT with Private Metadata. A standard interface for NFTs specifically designed for AI agents, where the metadata represents agent capabilities and requires privacy protection.
ERC 7908 · 2025 · Design paper
HD wallet In Treasury Management
ERC 7908, HD wallet In Treasury Management. This proposal aims to provide a standardized method for on-chain treasury management of institutional assets, ensuring secure private key generation, hierarchical management, and departmental permission isolation while supporting asset security and transaction efficiency in multi-chain environments.
BIP 46 · 2022 · Design paper
Address Scheme for Timelocked Fidelity Bonds
BIP 46, Address Scheme for Timelocked Fidelity Bonds. The derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds.
BIP 374 · 2024 · Design paper
Discrete Log Equality Proofs
BIP 374, Discrete Log Equality Proofs. All conventions and notations are used as defined in [https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki#notation BIP327].
BIP 431 · 2024 · Design paper
Topology Restrictions for Pinning
BIP 431, Topology Restrictions for Pinning. This document describes pinning problems that can arise from limitations in mempool policy.
BIP 433 · 2025 · Design paper
Pay to Anchor (P2A)
BIP 433, Pay to Anchor (P2A). This document describes a new standard output script called Pay to Anchor (P2A) and prescribes making spending of this output type standard.
BIP 450 · 2026 · Design paper
Formosa—Seed encoding by themed mnemonic stories
BIP 450, Formosa—Seed encoding by themed mnemonic stories. Formosa, an expansion of BIP-0039 for the generation of deterministic wallets.
EIP 3155 · 2020 · Design paper
EVM trace specification
EIP 3155, EVM trace specification. Introduce a new JSON standard for EVM traces during execution of state tests.
EIP 7523 · 2023 · Design paper
Empty accounts deprecation
EIP 7523, Empty accounts deprecation. This EIP prohibits the state of any post-merge network from containing empty accounts.
EIP 7610 · 2024 · Design paper
Revert creation in case of non-empty storage
EIP 7610, Revert creation in case of non-empty storage. This EIP causes contract creation to throw an error when attempted at an address with pre-existing storage.
EIP 7708 · 2024 · Design paper
ETH transfers emit a log
EIP 7708, ETH transfers emit a log. Logs are often used to track when balance changes of assets on Ethereum.
EIP 7732 · 2024 · Design paper
Enshrined Proposer-Builder Separation
EIP 7732, Enshrined Proposer-Builder Separation. This EIP fundamentally changes the way an Ethereum block is validated by decoupling the execution validation from the consensus validation both logically as well as temporally.
EIP 7778 · 2024 · Design paper
Block Gas Accounting without Refunds
EIP 7778, Block Gas Accounting without Refunds. This EIP modifies the block gas accounting mechanism to prevent the circumvention of block gas limits.
EIP 7784 · 2024 · Design paper
GETCONTRACT opcode
EIP 7784, GETCONTRACT opcode. This is a proposal to add a new opcode, GETCONTRACT.
EIP 7843 · 2024 · Design paper
SLOTNUM opcode
EIP 7843, SLOTNUM opcode. To add a new opcode SLOTNUM (0x4b), that returns the corresponding slot number for the current block.
EIP 7880 · 2025 · Design paper
EOF - EXTCODEADDRESS instruction
EIP 7880, EOF - EXTCODEADDRESS instruction. Add an instruction to EOF that reads code delegation designations from an account without requiring code introspection.
EIP 7904 · 2025 · Design paper
Compute Gas Cost Analysis
EIP 7904, Compute Gas Cost Analysis. This document reports an empirical analysis of the runtime of EVM compute operations and precompiles across the major execution clients.
EIP 7928 · 2025 · Design paper
Block-Level Access Lists
EIP 7928, Block-Level Access Lists. Block-Level Access Lists (BALs) that record all accounts and storage locations accessed during block execution, along with their post-execution values.
EIP 7976 · 2025 · Design paper
Increase Calldata Floor Cost
EIP 7976, Increase Calldata Floor Cost. An adjustment to calldata pricing by raising the floor cost from 10/40 to 64/64 gas per calldata byte.
EIP 7981 · 2024 · Design paper
Increase Access List Cost
EIP 7981, Increase Access List Cost. This EIP charges access lists for their data footprint, preventing the circumvention of the EIP-7623 floor pricing.
EIP 7997 · 2025 · Design paper
Deterministic Factory Contract
EIP 7997, Deterministic Factory Contract. The availability of a well-known CREATE2 factory at 0x4e59b44847b379578588920cA78FbF26c0B4956C is made a formal requirement to enable deterministic deployments at identical addresses across EVM chains.
EIP 8024 · 2025 · Design paper
Backward compatible SWAPN, DUPN, EXCHANGE
EIP 8024, Backward compatible SWAPN, DUPN, EXCHANGE. Currently, SWAP and DUP instructions are limited to a stack depth of 16.
EIP 8037 · 2025 · Design paper
State Creation Gas Cost Increase
EIP 8037, State Creation Gas Cost Increase. This proposal increases the cost of state creation operations, thus avoiding excessive state growth under increased block gas limits.
EIP 8038 · 2025 · Design paper
State-access gas cost update
EIP 8038, State-access gas cost update. This EIP updates the gas cost of state-access operations to reflect Ethereum's larger state and the consequent slowdown of these operations.
EIP 8070 · 2025 · Design paper
eth/72 - Sparse Blobpool
EIP 8070, eth/72 - Sparse Blobpool. This proposal introduces the sparse blobpool, a construction that brings cell-level, custody-aligned sampling in the Execution Layer (EL).
EIP 8133 · 2026 · Design paper
Network Upgrade Naming
EIP 8133, Network Upgrade Naming. This EIP documents the naming conventions used for Ethereum network upgrades across the Execution Layer, Consensus Layer, post-Merge combined upgrades, and Blob-Parameter-Only upgrades.
EIP 8136 · 2025 · Design paper
Cell-Level Deltas for Data Column Broadcast
EIP 8136, Cell-Level Deltas for Data Column Broadcast. Cell-Level Deltas for Data Column Broadcast optimizes PeerDAS (EIP-7594) by allowing more efficient transfers of blob data columns across the network.
EIP 8163 · 2026 · Design paper
Reserve `EXTENSION (0xae)` opcode
EIP 8163, Reserve `EXTENSION (0xae)` opcode. Reserve an opcode EXTENSION (0xae) which will be guaranteed to not become a valid opcode on Ethereum L1 EVM, but which will be available to be used in other EVMs as a prefix to encode extension instructions.
EIP 8182 · 2026 · Design paper
Private ETH and ERC-20 Transfers
EIP 8182, Private ETH and ERC-20 Transfers. Private ETH and ERC-20 transfers via a shielded-pool system contract.
EIP 8246 · 2026 · Design paper
Remove SELFDESTRUCT Burn
EIP 8246, Remove SELFDESTRUCT Burn. This EIP removes the remaining cases where SELFDESTRUCT burns ETH.
Markets
Uniswap · 2020 · Design paper
Uniswap v2 Core
The 2020 core paper for Uniswap v2: a constant-product automated market maker, with arbitrary ERC-20 pairs, price accumulators, and a flash-swap callback. It is the clearest short specification of the pool that much of later DeFi either forked or assumed.
Uniswap · 2021 · Design paper
Uniswap v3 Core
The 2021 paper that replaces the uniform reserve curve with concentrated liquidity. A provider chooses a price range. Inside the range their capital acts like a constant-product pool. Outside it, their position is entirely in one asset.
Curve · 2019 · Design paper
StableSwap — efficient mechanism for Stablecoin liquidity
Egorov's 2019 invariant for pools of assets that should trade near parity. The curve is flat around the peg, where most stablecoin trades happen, and bends toward a constant-product tail when the pool is pushed off parity.
Balancer · 2019 · Design paper
Balancer: A non-custodial portfolio manager, liquidity provider, and price sensor
The Balancer paper generalises the two-asset constant-product pool to a weighted basket of several tokens. Traders rebalance the basket. Liquidity providers define target weights. The pool is both an index and a market.
0x · 2017 · Design paper
0x: An open protocol for decentralized exchange on the Ethereum blockchain
The 2017 0x paper: off-chain signed orders, on-chain settlement, and relayers who host order books without taking custody. It is the reference design for 'the book is off-chain, the swap is on-chain'.
Bancor · 2017 · Design paper
Bancor Protocol: Continuous Liquidity and Asynchronous Price Discovery for Tokens through their Smart Contracts
The 2017 Bancor paper on smart tokens that hold reserves of other tokens and quote a continuous price from a reserve ratio. It is an early automated-liquidity design, distinct from Uniswap's later constant-product pools.
THORChain · 2020 · Design paper
THORChain: a decentralised liquidity protocol
THORChain's design for continuous liquidity pools that cross native chains. Nodes bond capital, observe external chains, and sign outbound transactions as a threshold set. It is a liquidity network, not a wrapped-asset bridge run by a single custodian.
Flash Boys 2.0 · 2019 · Design paper
Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges
A measurement paper. Miners and bots reorder and insert transactions around DEX trades. The authors name miner-extractable value and show priority gas auctions. It is not a trading manual, and it is not a claim that any strategy here is available or profitable now.
Uniswap v4 · 2023 · Design paper
Uniswap v4 Core
One contract holds many pools. Hooks are code that runs before and after swaps and liquidity changes. Flash accounting settles balances at the end of a lock. A hook can change the rules v3 users took for granted.
TWAMM · 2021 · Design paper
The Time-Weighted Average Market Maker
Execute a large order as if it were split into infinitely many tiny trades across an interval, without paying gas for each piece. Settlement is lazy. This is an order schedule, not a price oracle, despite the nearby acronym TWAP.
EIP-1559 · 2019 · Design paper
Fee market change for ETH 1.0 chain
Replace a first-price auction for inclusion with a protocol-quoted base fee that moves with demand, plus a tip to the producer. The base fee is burned. The EIP is a fee-market rule, not a promise that fees will be low.
Transaction fee mechanism design · 2020 · Design paper
Transaction Fee Mechanism Design
A mechanism-design reading of blockchain fees. Roughgarden separates what users pay, what miners keep, and what gets burned, and asks which combinations are incentive-compatible for myopic miners. EIP-1559 is the running example, not a price forecast.
Curve Cryptoswap · 2021 · Design paper
Automatic market-making with dynamic peg
Stableswap concentrates liquidity around a fixed price of one. This paper moves that concentration so it can follow a moving price between volatile assets. The pool reprices itself from its own trades. It does not know the outside world except through those trades.
Discreet log contracts · 2017 · Design paper
Discreet Log Contracts
The oracle publishes a signature on an outcome. Parties use adaptor signatures so the signature that settles the contract also reveals the oracle's secret, without the oracle knowing which contract it served.
Constant function market makers · 2020 · Design paper
Improved Price Oracles: Constant Function Market Makers
A constant-function market maker defines a set of reserves that must stay on a curve. Prices and oracle quality fall out of that curve and of the path traders take.
Yield Space · 2020 · Design paper
The Yield Protocol: On-Chain Lending With Interest Rate Discovery
Yield Space is an invariant between a target asset and a zero-coupon token. The price of the zero-coupon token implies a rate, and the curve is built so that rate behaves like a rate rather than like a spot commodity.
Uniswap v1 · 2018 · Design paper
Uniswap v1
A pool holds ETH and one ERC-20. The product of the reserves is constant. Anyone can trade against the pool or add both assets.
GMX · 2021 · Design paper
GMX: A Decentralised Perpetual Exchange
GMX v1 pools liquidity provider assets into a vault that takes the other side of leveraged trades. Prices come from an oracle. Traders pay fees to the pool.
Everlasting options · 2021 · Design paper
Everlasting Options
An everlasting option is funded so that holding it approximates a rolling option position. The funding payment, not an expiry, keeps the price near the claim.
BIP 174 · 2017 · Design paper
Partially Signed Bitcoin Transactions
A PSBT is a standard container for a transaction, the inputs' previous outputs, and the partial signatures. Roles are creator, updater, signer, combiner, finaliser and extractor.
ERC-20 · 2015 · Design paper
Token Standard
A token contract exposes total supply, balance, transfer, and allowances. Wallets and exchanges can integrate one interface.
ERC-721 · 2018 · Design paper
Non-Fungible Token Standard
Each token id has an owner. Transfer moves that id. An optional metadata URI points at a description. The standard does not say the description is true, or that the object exists off-chain.
ERC-1155 · 2018 · Design paper
Multi Token Standard
One contract holds many ids. Each id can be fungible or not, by how many copies exist. A batch transfer moves several ids in one call. A receiver hook tries to stop tokens being sent to contracts that cannot hold them.
EIP 7514 · 2023 · Design paper
Add Max Epoch Churn Limit
EIP 7514, Add Max Epoch Churn Limit. Update the maximum validator growth rate from an exponential to a linear increase by capping the epoch churn limit.
ERC 600 · 2017 · Design paper
Ethereum purpose allocation for Deterministic Wallets
ERC 600, Ethereum purpose allocation for Deterministic Wallets. A logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 and this proposed change to BIP43.
ERC 681 · 2017 · Design paper
URL Format for Transaction Requests
ERC 681, URL Format for Transaction Requests. A standard way of representing various transactions, especially payment requests in ether and ERC-20 tokens as URLs.
ERC 777 · 2017 · Design paper
Token Standard
ERC 777, Token Standard. Standard interfaces and behaviors for token contracts.
ERC 1363 · 2018 · Design paper
Payable Token
ERC 1363, Payable Token. Defines a token interface for ERC-20 tokens that supports executing recipient code after transfer or transferFrom, or spender code after approve.
ERC 2309 · 2019 · Design paper
ERC-721 Consecutive Transfer Extension
ERC 2309, ERC-721 Consecutive Transfer Extension. A standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers.
ERC 2981 · 2020 · Design paper
NFT Royalty Standard
ERC 2981, NFT Royalty Standard. A standardized way to retrieve royalty payment information for non-fungible tokens (NFTs) to enable universal support for royalty payments across all NFT marketplaces and ecosystem participants.
ERC 3525 · 2020 · Design paper
Semi-Fungible Token
ERC 3525, Semi-Fungible Token. The set of smart contract interfaces described in this document defines an ERC-721 compatible token standard.
ERC 4400 · 2021 · Design paper
EIP-721 Consumable Extension
ERC 4400, EIP-721 Consumable Extension. This specification defines standard functions outlining a consumer role for instance(s) of EIP-721.
ERC 4907 · 2022 · Design paper
Rental NFT, an Extension of EIP-721
ERC 4907, Rental NFT, an Extension of EIP-721. It proposes an additional role (user) which can be granted to addresses, and a time where the role is automatically revoked (expires).
ERC 4910 · 2022 · Design paper
Royalty Bearing NFTs
ERC 4910, Royalty Bearing NFTs. The proposal directly connects NFTs and royalties in a smart contract architecture extending the ERC-721 standard, with the aim of precluding central authorities from manipulating or circumventing payments to those who are legally entitled to them.
ERC 5023 · 2022 · Design paper
Shareable Non-Fungible Token
ERC 5023, Shareable Non-Fungible Token. This EIP standardizes an interface for non-fungible value-holding shareable tokens.
ERC 5169 · 2022 · Design paper
Client Script URI for Token Contracts
ERC 5169, Client Script URI for Token Contracts. This EIP provides a contract interface adding a scriptURI() function for locating executable scripts associated with the token.
ERC 5521 · 2022 · Design paper
Referable NFT
ERC 5521, Referable NFT. It proposes two referable indicators, referring and referred, and a time-based indicator createdTimestamp.
ERC 5528 · 2022 · Design paper
Refundable Fungible Token
ERC 5528, Refundable Fungible Token. This specification defines a type of escrow service with the following flow: - The seller issues tokens.
ERC 5606 · 2022 · Design paper
Multiverse NFTs
ERC 5606, Multiverse NFTs. This specification defines a minimal interface to create a multiverse NFT standard for digital assets such as wearables and in-game items that, in turn, index the delegate NFTs on each platform where this asset exists.
ERC 5725 · 2022 · Design paper
Transferable Vesting NFT
ERC 5725, Transferable Vesting NFT. A Non-Fungible Token (NFT) standard used to vest tokens (ERC-20 or otherwise) over a vesting release curve.
ERC 5773 · 2022 · Design paper
Context-Dependent Multi-Asset Tokens
ERC 5773, Context-Dependent Multi-Asset Tokens. The Multi-Asset NFT standard allows for the construction of a new primitive: context-dependent output of information per single NFT.
ERC 6105 · 2022 · Design paper
No Intermediary NFT Trading Protocol
ERC 6105, No Intermediary NFT Trading Protocol. A marketplace functionality to ERC-721 to enable non-fungible token trading without relying on an intermediary trading platform.
ERC 6150 · 2022 · Design paper
Hierarchical NFTs
ERC 6150, Hierarchical NFTs. It proposes a multi-layer filesystem-like hierarchical NFTs.
ERC 6220 · 2022 · Design paper
Composable NFTs utilizing Equippable Parts
ERC 6220, Composable NFTs utilizing Equippable Parts. The Composable NFTs utilizing equippable parts standard extends ERC-721 by allowing the NFTs to selectively add parts to themselves via equipping.
ERC 6239 · 2022 · Design paper
Semantic Soulbound Tokens
ERC 6239, Semantic Soulbound Tokens. This proposal extends ERC-721 and ERC-5192 by introducing Resource Description Framework (RDF) triples to Soulbound Tokens' (‘SBTs‘) metadata.
ERC 6454 · 2023 · Design paper
Minimal Transferable NFT detection interface
ERC 6454, Minimal Transferable NFT detection interface. The Minimalistic Transferable interface for Non-Fungible Tokens standard extends ERC-721 by introducing the ability to identify whether an NFT can be transferred or not.
ERC 6909 · 2023 · Design paper
Minimal Multi-Token Interface
ERC 6909, Minimal Multi-Token Interface. The following specifies a multi-token contract as a simplified alternative to the ERC-1155 Multi-Token Standard.
ERC 7007 · 2023 · Design paper
Verifiable AI-Generated Content Token
ERC 7007, Verifiable AI-Generated Content Token. The verifiable AI-generated content (AIGC) non-fungible token (NFT) standard is an extension of the ERC-721 token standard for AIGC.
ERC 7066 · 2023 · Design paper
Lockable Extension for ERC-721
ERC 7066, Lockable Extension for ERC-721. An extension of ERC-721, this standard incorporates locking features into NFTs, allowing for various uses while preventing sale or transfer.
ERC 7208 · 2023 · Design paper
On-Chain Data Containers
ERC 7208, On-Chain Data Containers. A series of interfaces for the abstraction of storage of on-chain data by implementing the logic functions that govern such data on independent smart contracts.
ERC 7401 · 2023 · Design paper
Parent-Governed Non-Fungible Tokens Nesting
ERC 7401, Parent-Governed Non-Fungible Tokens Nesting. ❗️ The Parent-Governed NFT Nesting standard extends ERC-721 by allowing for a new inter-NFT relationship and interaction.
ERC 7409 · 2023 · Design paper
Public Non-Fungible Tokens Emote Repository
ERC 7409, Public Non-Fungible Tokens Emote Repository. ❗️ The Public Non-Fungible Tokens Emote Repository standard provides an enhanced interactive utility for ERC-721 and ERC-1155 by allowing NFTs to be emoted at.
ERC 7439 · 2023 · Design paper
Prevent ticket touting
ERC 7439, Prevent ticket touting. This standard is an extension of ERC-721 and defines standard functions outlining a scope for ticketing agents or event organizers to take preventative actions to stop audiences being exploited in the ticket scalping market and allow customers to resell their tickets via authorized ticket resellers.
ERC 7743 · 2024 · Design paper
Multi-Owner Non-Fungible Tokens (MO-NFT)
ERC 7743, Multi-Owner Non-Fungible Tokens (MO-NFT). A new standard for non-fungible tokens (NFTs) that supports multiple owners.
ERC 7837 · 2024 · Design paper
Diffusive Tokens
ERC 7837, Diffusive Tokens. A standard for a new type of fungible token, called Diffusive Tokens (DIFF).
ERC 7858 · 2024 · Design paper
Expirable NFTs and SBTs
ERC 7858, Expirable NFTs and SBTs. Introduces an extension for ERC-721 Non-Fungible Tokens (NFTs) and Soulbound Tokens (SBTs) that adds an expiration mechanism, allowing tokens to become invalid after a predefined period.
ERC 8126 · 2026 · Design paper
AI Agent Verification
ERC 8126, AI Agent Verification. A standard interface for verifying AI agents on Ethereum that have been registered via ERC-8004.
Credit and stable value
Compound · 2019 · Design paper
Compound: The Money Market Protocol
The 2019 Compound paper: pooled lending markets where suppliers earn a floating rate and borrowers post collateral. Interest rates are a function of utilisation, set in the protocol rather than negotiated bilaterally.
Aave · 2020 · Design paper
Aave Protocol white paper
Aave's v1 protocol paper: pooled lending with stable and variable rates, and loan features such as rate switching and uncollateralised flash loans inside a single transaction. It sits in the same family as Compound, with a different rate and product surface.
Maker · 2017 · Design paper
The Dai Stablecoin System
MakerDAO's 2017 description of Dai: a liability minted against overcollateralised vaults, kept near a dollar target by fees, a collateral auction, and an emergency shutdown. It is the reference design for crypto-collateralised stable value, as distinct from a fiat-backed token.
Terra · 2019 · Failure case
Terra Money: Stability and Adoption
Do Kwon's 2019 paper for a family of fiat-pegged tokens stabilised by an arbitrage relationship with a second, volatile token. It is included because it is a canonical design paper that was not in the historic library. It is included as a failure case, not as a model to ship.
Liquity · 2021 · Design paper
Liquity: Decentralized Borrowing
Borrow a stable-value token against ether, with a one-time fee instead of an interest rate. Troves are liquidated into a stability pool. Redemptions let the token be swapped for the collateral of the weakest trove. The paper does not promise a peg.
crvUSD design · 2022 · Design paper
Curve stablecoin design
A stablecoin lent against volatile collateral, where liquidation is a continuous trade into a special pool rather than a one-shot auction. The paper calls that pool LLAMMA. A peg keeper and a monetary-policy rate sit beside it. Simulations in the paper are not a promise about later losses.
b-money · 1998 · Design paper
b-money
Participants broadcast contract offers. Money is created by solving a computational problem, and a collective bookkeeping system tracks balances. A second variant uses a subset of servers.
Morpho · 2023 · Design paper
Morpho Blue: Permissionless Lending
Morpho Blue isolates a market to one loan asset, one collateral asset, one oracle, one LLTV and one rate model. Risk does not cross markets inside the core.
ERC-4626 · 2022 · Design paper
Tokenized Vault Standard
A tokenised vault has deposit, mint, withdraw and redeem, and a defined conversion between the asset and the share. The share is an ERC-20.
Flash loans · 2020 · Design paper
ERC-3156: Flash Loans
A flash lender sends assets to a receiver and requires that the same transaction returns them, plus a fee. If it does not, the transaction reverts. There is no default in the credit sense, because there is no time.
BIP 137 · 2019 · Design paper
Signatures of Messages using Private Keys
BIP 137, Signatures of Messages using Private Keys. This document describes a signature format for signing messages with Bitcoin private keys.
ERC 6059 · 2022 · Design paper
Parent-Governed Nestable Non-Fungible Tokens
ERC 6059, Parent-Governed Nestable Non-Fungible Tokens. The Parent-Governed Nestable NFT standard extends ERC-721 by allowing for a new inter-NFT relationship and interaction.
ERC 6147 · 2022 · Design paper
Guard of NFT/SBT, an Extension of ERC-721
ERC 6147, Guard of NFT/SBT, an Extension of ERC-721. It separates the holding right and transfer right of non-fungible tokens (NFTs) and Soulbound Tokens (SBTs) and defines a new role, guard with expires.
ERC 7291 · 2023 · Design paper
Purpose bound money
ERC 7291, Purpose bound money. A Purpose Bound Money (PBM) token is a wrapper around an ERC-1155 token that can be used for a limited activity.
ERC 7528 · 2023 · Design paper
ETH (Native Asset) Address Convention
ERC 7528, ETH (Native Asset) Address Convention. The following standard proposes a convention for using the address 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee in all contexts where an address is used to represent ETH in the same capacity as an ERC-20 token.
ERC 7535 · 2023 · Design paper
Native Asset ERC-4626 Tokenized Vault
ERC 7535, Native Asset ERC-4626 Tokenized Vault. This standard is an extension of the ERC-4626 spec with an identical interface and behavioral overrides for handling Ether or any native asset as the underlying.
ERC 7540 · 2023 · Design paper
Asynchronous ERC-4626 Tokenized Vaults
ERC 7540, Asynchronous ERC-4626 Tokenized Vaults. The following standard extends ERC-4626 by adding support for asynchronous deposit and redemption flows.
ERC 7575 · 2023 · Design paper
Multi-Asset ERC-4626 Vaults
ERC 7575, Multi-Asset ERC-4626 Vaults. The following standard adapts ERC-4626 to support multiple assets or entry points for the same share token.
ERC 8161 · 2025 · Design paper
Transferable Tokenized Vault Requests
ERC 8161, Transferable Tokenized Vault Requests. This standard extends ERC-7540 by adding optional transferability of pending deposit and redeem Requests.
Data and agents
Chainlink · 2017 · Design paper
Chainlink: A Decentralized Oracle Network
The 2017 Chainlink paper: a network of independent nodes that fetch off-chain data, aggregate it, and deliver a signed result on-chain, with a reputation and penalty story around the nodes. It is the reference design for 'the contract needs a fact from outside'.
The Graph · 2020 · Design paper
The Graph: a decentralised query protocol for blockchains
The Graph's protocol paper for indexing chain data. Indexers stake on serving a subgraph. Curators signal which subgraphs matter. Consumers pay for queries. The problem is read access, not consensus.
Augur · 2018 · Design paper
Augur: a Decentralized Oracle and Prediction Market Platform
The Augur paper: prediction markets whose outcomes are reported by token holders, with a dispute ladder that can escalate a contested result. It is both a market design and an oracle design. The historic library already holds Gnosis. Augur is the other canonical public prediction-market paper and was not in that set.
Ocean · 2019 · Design paper
Ocean Protocol: A Decentralized Substrate for AI Data and Services
Ocean's technical paper for publishing, pricing and consuming data services with on-chain access control and off-chain storage. The data does not sit inside the chain. The permission and the payment do.
Bittensor · 2021 · Design paper
Bittensor: A Peer-to-Peer Intelligence Market
Rao's paper for a market in which machine-learning models score each other. Peers rank neighbours, ranks accumulate on a ledger, and an incentive mechanism is specified to resist a naive cartel of mutual high scores. It is a design for pricing intelligence as a commodity, not a benchmark of any particular model.
SingularityNET · 2017 · Design paper
SingularityNET: A Decentralized, Open Market and Network for AIs
Goertzel's 2017 proposal for a marketplace where AI services discover, call and pay each other. The paper is broad on purpose: discovery, reputation, inter-agent calls and a tokenised payment rail, sketched as one network.
ERC-4337 · 2021 · Design paper
Account Abstraction Using Alt Mempool
Smart-contract accounts that propose UserOperations, bundled by a separate mempool, without a change to Ethereum's consensus. Paymasters can sponsor gas. The validation rule lives in the account, which is the point and the risk.
UMA · 2020 · Design paper
UMA Data Verification Mechanism: Adding Economic Guarantees to Blockchain Oracles
An oracle that does not answer every question in real time. It prices the cost of bribing the token holders who would resolve a dispute, and it asks contract designers to keep the profit of a lie below that cost. The draft is an economic argument, not a feed you can read as truth.
Bitcoin as a beacon · 2015 · Design paper
On Bitcoin as a Public Randomness Source
The paper asks when a proof-of-work block hash is a safe public beacon, and how a miner can bias it by withholding or grinding.
Decentralized identifiers · 2022 · Design paper
Decentralized Identifiers (DIDs) v1.0
A DID is an identifier whose document, including keys, can be resolved by a method. The method says where the document lives. The standard does not pick one blockchain.
Verifiable credentials · 2025 · Design paper
Verifiable Credentials Data Model v2.0
An issuer signs a set of claims about a subject. A holder later presents those claims, or a derivation, to a verifier. The verifier checks the issuer's signature, not a central account.
EIP-7702 · 2024 · Design paper
Set Code for EOAs
A transaction can temporarily, for the transaction's authority, delegate an externally owned account's code to a contract. The key still signs. The code that runs can batch, sponsor, or limit what the key may do.
BIP 22 · 2012 · Design paper
getblocktemplate - Fundamentals
BIP 22, getblocktemplate - Fundamentals. A new JSON-RPC method for "smart" Bitcoin miners and proxies.
BIP 23 · 2012 · Design paper
getblocktemplate - Pooled Mining
BIP 23, getblocktemplate - Pooled Mining. Extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.
BIP 43 · 2014 · Design paper
Purpose Field for Deterministic Wallets
BIP 43, Purpose Field for Deterministic Wallets. A "Purpose Field" for use in deterministic wallets based on algorithm described in BIP-0032 (BIP32 from now on).
BIP 48 · 2020 · Design paper
Multi-Script Hierarchy for Multi-Sig Wallets
BIP 48, Multi-Script Hierarchy for Multi-Sig Wallets. A logical hierarchy for deterministic multi-sig wallets based on an algorithm described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on).
BIP 49 · 2016 · Design paper
Derivation scheme for P2WPKH-nested-in-P2SH based accounts
BIP 49, Derivation scheme for P2WPKH-nested-in-P2SH based accounts. The derivation scheme for HD wallets using the P2WPKH-nested-in-P2SH ([[bip-0141.mediawiki|BIP 141]]) serialization format for segregated witness transactions.
BIP 71 · 2013 · Design paper
Payment Protocol MIME types
BIP 71, Payment Protocol MIME types. A MIME (RFC 2046) Media Type for Bitcoin payment request messages.
BIP 72 · 2013 · Design paper
bitcoin: uri extensions for Payment Protocol
BIP 72, bitcoin: uri extensions for Payment Protocol. An extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70).
BIP 73 · 2013 · Design paper
Use "Accept" header for response type negotiation with Payment Request URLs
BIP 73, Use "Accept" header for response type negotiation with Payment Request URLs. An enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]]) that addresses the need for short URLs when scanning from QR codes.
BIP 84 · 2017 · Design paper
Derivation scheme for P2WPKH based accounts
BIP 84, Derivation scheme for P2WPKH based accounts. The derivation scheme for HD wallets using the P2WPKH ([[bip-0173.mediawiki|BIP 173]]) serialization format for segregated witness transactions.
BIP 88 · 2020 · Design paper
Hierarchical Deterministic Path Templates
BIP 88, Hierarchical Deterministic Path Templates. This document describes a format for the representation of the templates that specify the constraints that can be imposed on BIP32 derivation paths.
BIP 127 · 2019 · Design paper
Simple Proof-of-Reserves Transactions
BIP 127, Simple Proof-of-Reserves Transactions. A simple way to construct proof-of-reserves transactions.
BIP 145 · 2016 · Design paper
getblocktemplate Updates for Segregated Witness
BIP 145, getblocktemplate Updates for Segregated Witness. Modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].
BIP 173 · 2017 · Design paper
Base32 address format for native v0-16 witness outputs
BIP 173, Base32 address format for native v0-16 witness outputs. We first describe the general checksummed base32 '''Why use base32 at all?''' The lack of mixed case makes it more efficient to read out loud or to put into QR codes.
BIP 176 · 2017 · Design paper
Bits Denomination
BIP 176, Bits Denomination. Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin.
BIP 179 · 2019 · Design paper
Name for payment recipient identifiers
BIP 179, Name for payment recipient identifiers. A new term for 'address' Bitcoin addresses are intended to be only used '''once''' and you should generate a new one for every new incoming payment.
BIP 321 · 2024 · Design paper
URI Scheme
BIP 321, URI Scheme. A URI scheme for describing Bitcoin payment instructions.
BIP 350 · 2020 · Design paper
Bech32m format for v1+ witness addresses
BIP 350, Bech32m format for v1+ witness addresses. We first specify the new checksum algorithm, and then document how it should be used for future Bitcoin addresses.
BIP 353 · 2024 · Design paper
DNS Payment Instructions
BIP 353, DNS Payment Instructions. A standard format for encoding [[bip-0021.mediawiki|BIP 21]] URI schemes in DNS TXT records.
BIP 385 · 2021 · Design paper
raw() and addr() Output Script Descriptors
BIP 385, raw() and addr() Output Script Descriptors. This document specifies raw() and addr() output script descriptors.
EIP 234 · 2017 · Design paper
Add `blockHash` to JSON-RPC filter options.
EIP 234, Add `blockHash` to JSON-RPC filter options.. Add an option to JSON-RPC filter options (used by eth_newFilter and eth_getLogs) that allows specifying the block hash that should be included in the results.
EIP 695 · 2017 · Design paper
Create `eth_chainId` method for JSON-RPC
EIP 695, Create `eth_chainId` method for JSON-RPC. Include eth_chainId method in eth_-namespaced JSON-RPC methods.
EIP 1898 · 2019 · Design paper
Add `blockHash` to defaultBlock methods
EIP 1898, Add `blockHash` to defaultBlock methods. For JSON-RPC methods which currently accept a default block parameter, additionally allow the parameter to be a block hash.
EIP 2159 · 2019 · Design paper
Common Prometheus Metrics Names for Clients
EIP 2159, Common Prometheus Metrics Names for Clients. Standardized names of common metrics for Ethereum clients to use with Prometheus, a widely used monitoring and alerting solution.
EIP 2228 · 2019 · Design paper
Canonicalize the name of network ID 1 and chain ID 1
EIP 2228, Canonicalize the name of network ID 1 and chain ID 1. The Ethereum network with network ID 1 and chain ID 1 is named Ethereum Mainnet.
EIP 2681 · 2020 · Design paper
Limit account nonce to 2^64-1
EIP 2681, Limit account nonce to 2^64-1. Account nonces are currently specified to be arbitrarily long unsigned integers.
EIP 2718 · 2020 · Design paper
Typed Transaction Envelope
EIP 2718, Typed Transaction Envelope. TransactionType || TransactionPayload is a valid transaction and TransactionType || ReceiptPayload is a valid transaction receipt where TransactionType identifies the format of the transaction and Payload is the transaction/receipt contents, which are defined in future EIPs.
EIP 3855 · 2021 · Design paper
PUSH0 instruction
EIP 3855, PUSH0 instruction. Introduce the PUSH0 (0x5f) instruction, which pushes the constant value 0 onto the stack.
EIP 4938 · 2022 · Design paper
eth/67 - Removal of GetNodeData
EIP 4938, eth/67 - Removal of GetNodeData. The Ethereum Wire Protocol defines request and response messages for exchanging data between clients.
EIP 5792 · 2022 · Design paper
Wallet Call API
EIP 5792, Wallet Call API. Defines new JSON-RPC methods which enable apps to ask a wallet to process a batch of onchain write calls and to check on the status of those calls.
EIP 7935 · 2025 · Design paper
Set default gas limit to 60M
EIP 7935, Set default gas limit to 60M. This should be significantly increased to 60M by the time Fusaka is released by execution layer clients updating their default configurations.
ERC 162 · 2016 · Design paper
Initial ENS Hash Registrar
ERC 162, Initial ENS Hash Registrar. The implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS).
ERC 173 · 2018 · Design paper
Contract Ownership Standard
ERC 173, Contract Ownership Standard. This specification defines standard functions for owning or controlling a contract.
ERC 820 · 2018 · Design paper
Pseudo-introspection Registry Contract
ERC 820, Pseudo-introspection Registry Contract. This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.
ERC 1820 · 2019 · Design paper
Pseudo-introspection Registry Contract
ERC 1820, Pseudo-introspection Registry Contract. This standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation.
ERC 2535 · 2020 · Design paper
Diamonds, Multi-Facet Proxy
ERC 2535, Diamonds, Multi-Facet Proxy. This proposal standardizes diamonds, which are modular smart contract systems that can be upgraded/extended after deployment, and have virtually no size limit.
ERC 3668 · 2020 · Design paper
CCIP Read—Secure offchain data retrieval
ERC 3668, CCIP Read—Secure offchain data retrieval. Contracts wishing to support lookup of data from external sources may, instead of returning the data directly, revert using OffchainLookup(address sender, string[] urls, bytes callData, bytes4 callbackFunction, bytes extraData).
ERC 7201 · 2023 · Design paper
Namespaced Storage Layout
ERC 7201, Namespaced Storage Layout. We define the NatSpec annotation @custom:storage-location to document storage namespaces and their location in storage in Solidity or Vyper source code.
ERC 7820 · 2024 · Design paper
Access Control Registry
ERC 7820, Access Control Registry. The Access Control Registry (ACR) standard defines a universal interface for managing role-based access control across multiple smart contracts.
ERC 7950 · 2025 · Design paper
Encode chain id with transaction hash
ERC 7950, Encode chain id with transaction hash. This standard proposes a way to encode the combination of a chain ID and a transaction hash into one string.
ERC 8042 · 2025 · Design paper
Diamond Storage
ERC 8042, Diamond Storage. This standard formalizes the diamond storage pattern originally introduced by ERC-2535 Diamonds and widely adopted across smart contracts.
BIP 93 · 2023 · Design paper
codex32: Checksummed SSSS-aware BIP32 seeds
BIP 93, codex32: Checksummed SSSS-aware BIP32 seeds. We first describe the general checksummed base32 '''Why use base32 at all?''' The lack of mixed case makes it more efficient to read out loud, write, type or to put into QR codes.
BIP 122 · 2015 · Design paper
URI scheme for Blockchain references / exploration
BIP 122, URI scheme for Blockchain references / exploration. A URI scheme for looking up blocks, transactions and addresses on a Blockchain explorer, or in general to make proper Blockchain references.
BIP 126 · 2016 · Design paper
Best Practices for Heterogeneous Input Script Transactions
BIP 126, Best Practices for Heterogeneous Input Script Transactions. When a Bitcoin transaction contains inputs that reference previous transaction outputs sent to different Bitcoin addresses, personally identifiable information of the user will leak into the blockchain in an uncontrolled manner.
BIP 128 · 2026 · Design paper
Timelock-Recovery Storage Format
BIP 128, Timelock-Recovery Storage Format. This document proposes a standard format for saving timelock-recovery plans, to allow different wallets to generate them, and different services to monitor/execute them.
BIP 136 · 2017 · Design paper
Bech32 Encoded Tx Position References
BIP 136, Bech32 Encoded Tx Position References. A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally, an outpoint index within the transaction.
BIP 172 · 2025 · Design paper
Define Bitcoin Subunits as Satoshis
BIP 172, Define Bitcoin Subunits as Satoshis. To formally define and standardize Bitcoin's smallest indivisible unit (1/100,000,000 of a bitcoin) as "satoshi" (singular) or "satoshis" (plural), with "sats" as the standard abbreviated form.
BIP 323 · 2026 · Design paper
24 nVersion bits for general purpose use
BIP 323, 24 nVersion bits for general purpose use. 24 bits are reserved in the nVersion field as extra nonce space for miners, providing for additional hashrate with header-only mining without relying on rolling nTime more often than once per second.
BIP 376 · 2026 · Design paper
Spending Silent Payment outputs with PSBTs
BIP 376, Spending Silent Payment outputs with PSBTs. We use the following functions and conventions: ser 32 (i): serializes a 32-bit unsigned integer ''i'' as a 4-byte sequence, most significant byte first.
EIP 2780 · 2020 · Design paper
Resource-based intrinsic transaction gas
EIP 2780, Resource-based intrinsic transaction gas. This EIP decomposes the flat 21,000 intrinsic transaction cost into explicit primitives, each priced to match the resources a transaction actually consumes.
EIP 7834 · 2024 · Design paper
Separate Metadata Section for EOF
EIP 7834, Separate Metadata Section for EOF. Introduce a new separate metadata section to the Ethereum Object Format (EOF) that is unreachable by the code, and any changes to which does not affect the code.
EIP 7954 · 2025 · Design paper
Increase Maximum Contract Size
EIP 7954, Increase Maximum Contract Size. To raise the maximum allowed size for contract code deployed on Ethereum from 24,576 bytes to 65,536 bytes, and to raise the initcode size limit from 49,152 bytes to 131,072 bytes.
Storage and networks
Filecoin · 2017 · Design paper
Filecoin: A Decentralized Storage Network
Protocol Labs' July 2017 paper. Storage is an algorithmic market: clients pay miners to store data, miners prove replication and spacetime, and a retrieval market is specified beside the storage market. The historic library's filecoin.pdf is an earlier, different sketch. This is the 2017 document.
Arweave · 2018 · Design paper
Arweave yellow paper
Arweave's protocol paper for permanent storage: miners store a recall block drawn from the history, an endowment is supposed to prepay storage, and the dataset is content-addressed. The yellow paper is the technical document. Marketing pages are not a substitute.
Helium · 2018 · Design paper
Helium: A Decentralized Wireless Network
The Helium paper for a wireless network built from independently owned hotspots. Coverage is the commodity. Proof-of-coverage is the paper's way of checking that a radio is where it says it is and that it can be heard. Later changes of purpose and token are not this document.
Golem · 2016 · Design paper
The Golem Project: crowdfunding white paper
Golem Factory's 2016 paper for a marketplace of spare computer power. Requestors split tasks. Providers run them. A reputation and payment layer is supposed to make the exchange work without a single render farm. The paper is explicit that it was also a crowdfunding document. This page uses the technical design and ignores the sale.
Livepeer · 2017 · Design paper
Livepeer: a decentralised live video streaming network
Petkanics and Tang's design for live video transcoding as a protocol job. Broadcasters send a stream. Transcoders stake and compete to encode the renditions viewers actually need. It is a specific media market, which is why it is more concrete than a general 'decentralised compute' essay.
Basic Attention Token · 2018 · Design paper
Basic Attention Token: Blockchain Based Digital Advertising
Brave's 2018 paper for an advertising unit that pays publishers and users from a measured attention event inside the browser, rather than from a chain of third-party trackers. The browser is load-bearing. The token is the unit of account in the paper's payment flow.
IPFS · 2014 · Design paper
IPFS - Content Addressed, Versioned, P2P File System
Name a file by its hash. Retrieve it from any peer who has the bytes. Version history is a graph of hashes, not a folder on one machine.
Kademlia · 2002 · Design paper
Kademlia: A Peer-to-peer Information System Based on the XOR Metric
Nodes have identifiers. Distance is XOR. Each node keeps contacts in buckets by distance, and a lookup walks toward the target in logarithmic steps.
BIP 31 · 2012 · Design paper
Pong message
BIP 31, Pong message. This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections.
BIP 47 · 2015 · Design paper
Reusable Payment Codes for Hierarchical Deterministic Wallets
BIP 47, Reusable Payment Codes for Hierarchical Deterministic Wallets. A technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse.
BIP 61 · 2014 · Design paper
Reject P2P message
BIP 61, Reject P2P message. A new message type for the Bitcoin peer-to-peer network.
BIP 70 · 2013 · Design paper
Payment Protocol
BIP 70, Payment Protocol. A protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process.
BIP 111 · 2015 · Design paper
NODE_BLOOM service bit
BIP 111, NODE_BLOOM service bit. This BIP extends BIP 37, Connection Bloom filtering, by defining a service bit to allow peers to advertise that they support bloom filters explicitly.
BIP 123 · 2015 · Design paper
BIP Classification
BIP 123, BIP Classification. This document describes a classification scheme for BIPs.
BIP 130 · 2015 · Design paper
sendheaders message
BIP 130, sendheaders message. Add a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv".
BIP 133 · 2016 · Design paper
feefilter message
BIP 133, feefilter message. Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate.
BIP 152 · 2016 · Design paper
Compact Block Relay
BIP 152, Compact Block Relay. Compact blocks on the wire as a way to save bandwidth for nodes on the P2P network.
BIP 155 · 2019 · Design paper
addrv2 message
BIP 155, addrv2 message. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [https://tools.ietf.org/html/rfc2119 RFC 2119] .
BIP 158 · 2017 · Design paper
Compact Block Filters for Light Clients
BIP 158, Compact Block Filters for Light Clients. A structure for compact filters on block data, for use in the BIP 157 light client protocol bip-0157.mediawiki .
BIP 159 · 2017 · Design paper
NODE_NETWORK_LIMITED service bit
BIP 159, NODE_NETWORK_LIMITED service bit. Define a service bit that allows pruned peers to signal their limited services.
BIP 322 · 2018 · Design paper
Generic Signed Message Format
BIP 322, Generic Signed Message Format. A standard for interoperable signed messages based on the Bitcoin Script format, either for proving availability of funds, or for committing to a message as the intended recipient of funds sent to the invoice address.
BIP 325 · 2019 · Design paper
Signet
BIP 325, Signet. A new type of test network where signatures are used in addition to proof of work for block progress, enabling much better coordination and robustness (be reliably unreliable), for persistent, longer-term testing scenarios involving multiple independent parties.
BIP 339 · 2020 · Design paper
WTXID-based transaction relay
BIP 339, WTXID-based transaction relay. Two changes to the p2p protocol to support transaction relay based on the BIP 141 wtxid of a transaction, rather than its txid.
BIP 381 · 2021 · Design paper
Non-Segwit Output Script Descriptors
BIP 381, Non-Segwit Output Script Descriptors. This document specifies pk() , pkh() , and sh() output script descriptors.
BIP 384 · 2021 · Design paper
combo() Output Script Descriptors
BIP 384, combo() Output Script Descriptors. This document specifies combo() output script descriptors.
EIP 627 · 2017 · Design paper
Whisper Specification
EIP 627, Whisper Specification. The format of Whisper messages within the ÐΞVp2p Wire Protocol.
EIP 706 · 2017 · Design paper
DEVp2p snappy compression
EIP 706, DEVp2p snappy compression. The base networking protocol (DEVp2p) used by Ethereum currently does not employ any form of compression.
EIP 1193 · 2018 · Design paper
Ethereum Provider JavaScript API
EIP 1193, Ethereum Provider JavaScript API. A common convention in the Ethereum web application ("dapp") ecosystem is for key management software ("wallets") to expose their API via a JavaScript object in the web page.
EIP 2124 · 2019 · Design paper
Fork identifier for chain compatibility checks
EIP 2124, Fork identifier for chain compatibility checks. Currently nodes in the Ethereum network try to find each other by establishing random connections to remote machines "looking" like an Ethereum node (public networks, private networks, test networks, etc), hoping that they found a useful peer (same genesis, same forks).
EIP 2464 · 2020 · Design paper
eth/65: transaction announcements and retrievals
EIP 2464, eth/65: transaction announcements and retrievals. Three additional message types into the eth protocol (releasing a new version, eth/65): NewPooledTransactionHashes (0x08) to announce a set of transactions without their content; GetPooledTransactions (0x09) to request a batch of transactions by their announced hash; and PooledTransactions (0x0a) to reply to a transaction request.
EIP 2481 · 2020 · Design paper
eth/66 request identifier
EIP 2481, eth/66 request identifier. The eth protocol defines various request and response commands that are used to exchange data between Ethereum nodes.
EIP 2696 · 2020 · Design paper
JavaScript `request` method RPC transport
EIP 2696, JavaScript `request` method RPC transport. A standard for remote procedure calls between an Ethereum Provider and an Ethereum Client when both are able to interface with each other via a shared JavaScript object.
EIP 2976 · 2020 · Design paper
Typed Transactions over Gossip
EIP 2976, Typed Transactions over Gossip. Typed Transactions can be sent over devp2p as TransactionType || TransactionPayload.
EIP 6122 · 2022 · Design paper
Forkid checks based on timestamps
EIP 6122, Forkid checks based on timestamps. EIP-2124 proposed a way of identifying nodes on the p2p network based on their chain configuration via the forkid parameter.
EIP 6963 · 2023 · Design paper
Multi Injected Provider Discovery
EIP 6963, Multi Injected Provider Discovery. An alternative discovery mechanism to window.ethereum for EIP-1193 providers which supports discovering multiple injected Wallet Providers in a web page using Javascript's window events.
EIP 7642 · 2024 · Design paper
eth/69 - history expiry and simpler receipts
EIP 7642, eth/69 - history expiry and simpler receipts. This EIP modifies the 'eth' p2p protocol to announce the historical block range served by the node.
ERC 3448 · 2021 · Design paper
MetaProxy Standard
ERC 3448, MetaProxy Standard. By standardizing on a known minimal bytecode proxy implementation with support for immutable metadata, this standard allows users and third party tools (e.g.
ERC 3643 · 2021 · Design paper
T-REX - Token for Regulated EXchanges
ERC 3643, T-REX - Token for Regulated EXchanges. The T-REX token is an institutional grade security token standard.
ERC 5615 · 2023 · Design paper
ERC-1155 Supply Extension
ERC 5615, ERC-1155 Supply Extension. This ERC standardizes an existing mechanism to fetch token supply data from ERC-1155 tokens.
ERC 7818 · 2024 · Design paper
Expirable ERC-20
ERC 7818, Expirable ERC-20. Introduces an extension for ERC-20 tokens, which facilitates the implementation of an expiration mechanism.
BIP 178 · 2018 · Design paper
Version Extended WIF
BIP 178, Version Extended WIF. An extension to the Wallet Import Format (WIF) to specify what kind of bitcoin address the private key corresponds to.
BIP 330 · 2019 · Design paper
Transaction announcements reconciliation
BIP 330, Transaction announcements reconciliation. This document specifies a P2P protocol extension for reconciliation of transaction announcements between 2 nodes , which is a building block for efficient transaction relay protocols (e.g., [https://arxiv.org/pdf/1905.10518.pdf Erlay]).
BIP 331 · 2022 · Design paper
Ancestor Package Relay
BIP 331, Ancestor Package Relay. Peer-to-peer protocol messages enabling nodes to request and relay the unconfirmed ancestor package of a given transaction, and to request and relay transactions in batches.
EIP 7975 · 2025 · Design paper
eth/70 - partial block receipt lists
EIP 7975, eth/70 - partial block receipt lists. This EIP modifies the 'eth' p2p protocol to allow requesting partial block receipt lists.
EIP 8159 · 2026 · Design paper
eth/71 - Block Access List Exchange
EIP 8159, eth/71 - Block Access List Exchange. This EIP modifies the 'eth' p2p protocol to support Block-level Access Lists (BALs).
EIP 8189 · 2026 · Design paper
snap/2 - BAL-Based State Healing
EIP 8189, snap/2 - BAL-Based State Healing. This EIP upgrades the snap protocol from version 1 to version 2, removing GetTrieNodes (0x06) / TrieNodes (0x07) and adding GetBlockAccessLists (0x08) / BlockAccessLists (0x09) to enable BAL-based state healing during snap sync.
Confidential compute
Secret Network · 2015 · Design paper
Enigma: Decentralized Computation Platform with Guaranteed Privacy
The 2015 Enigma paper from MIT: private contracts executed over secret-shared data, so nodes compute without seeing the raw inputs. Secret Network is a later project in this lineage, using different machinery. This page is about the Enigma paper, which the historic library does not hold.
Oasis · 2019 · Design paper
Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts
The Ekiden paper: smart contracts that execute inside trusted hardware, with the ledger checking attestations rather than re-executing the private code. Oasis Network is the later production system in this line. The paper is the academic statement of the approach.
Already in the historic library
These primary papers were on the original site. Open the archived PDF rather than a second essay.
- Bitcoin
Satoshi Nakamoto, 2008
- Ethereum
Buterin white paper
- Ethereum yellow paper
Wood, EIP-150 revision
- Ripple consensus
Schwartz, Youngs, Britto
- Stellar consensus
Mazières
- Interledger
Thomas and Schwartz
- Pegged sidechains
Back et al.
- Tether
Fiat on a Bitcoin-era chain
- Dash
Duffield and Diaz
- Peercoin
King and Nadal, proof of stake
- Corda
R3 introductory paper
- IOTA Tangle
Popov
- Filecoin, 2014 sketch
Earlier than the 2017 Protocol Labs paper
- Gnosis
Prediction markets
- Sia
Vorick and Champine
- Storj
Wilkinson et al.
- Kadena, 2016
Private-chain note, not Chainweb
Historic library
The original Blockchain Lab PDF index, kept at the same paths. Summaries are the archive blurbs, not new essays.
BlockChain Technology
Beyond Bitcoin
A blockchain is essentially a distributed database of records or public ledger of all transactions or digital events that have been executed and shared among participating parties.
Bitcoin
A Peer-to-Peer Electronic Cash System
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
BlockChain Technology
To banking and financial sector in india
TECHNOLOGY and banking have a long close association. Both have been benefitting immensely by this association.
Blockchain Innovations
With Pegged Sidechains
The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not least Bitcoin.
Ethereum
A secure decentralised generalised transaction ledger
Since the introduction of Bitcoin[Nak09] in 2009, and the multiple computer science and electronic cash innovations it brought, there has been great interest in the potential of decentralised cryptocurrencies.
Ripple Consensus
The Ripple Protocol Consensus Algorithm
While several consensus algorithms exist for the Byzantine Generals Problem, specifically as it pertains to distributed payment systems, many suffer from high latency induced by the requirement that all nodes within the network communicate synchronously
Permacoin
Repurposing Bitcoin Work for Data Preservation
Bitcoin is widely regarded as the first broadly successful ecash system. An oft-cited concern, though, is that mining Bitcoins wastes computational resources.
MultiChain Blockchain
Dr Gideon Greenspan, Founder and CEO, Coin Sciences Ltd
Blockchain’s
Driving the Next Wave of Innovation
Smart contracts with embedded business rules promise not only to reduce transaction costs but to create more agile value chains that enable closer cooperation and enhanced trust across the extended manufacturing ecosystem.
Blockchain
een uitwerking van nieuw denken
Blockchain is de nieuwe belofte in ICT: er gaat geen dag voorbij of er is een congres of er verschijnt een artikel over de technologie. Maar wat is blockchain precies en wat kan de overheid ermee?
Hawk
The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts
Emerging smart contract systems over decentralized cryptocurrencies allow mutually distrustful parties to transact safely without trusted third parties. I
Veros
White Paper
A cryptocurrency is a medium of exchange, which makes use of cryptography to secure transactions and to control creation of additional currency units.
The Digital Asset Platform
Non-technical White Paper
This paper provides a high level overview of the architecture of the Digital Asset Platform, a common foundation on which financial services applications can be built.I
Dash
A PrivacyCentric CryptoCurrency
A cryptocurrency based on Bitcoin, the work of Satoshi Nakamoto, with various improvements such as a twotier incentivized network, known as the Masternode network. I
Heat Ledger
Heuristically Enhanced Asynchronous Transactions
HEAT Ledger is a self-appointed “Gen 3.0” cryptocurrency platform focusing on resolving the two most pressing pitfalls of the existing 2.0 and 1.0 cryptocurrency server software solutions;
Heat Ledger
Heuristically Enhanced Asynchronous Transactions
HEAT Ledger is a self-appointed “Gen 3.0” cryptocurrency platform focusing on resolving the two most pressing pitfalls of the existing 2.0 and 1.0 cryptocurrency server software solutions;
ChainDB
A Peer-to-Peer Database System
Bitcoin [1] has demonstrated a new approach to securely storing data in the cloud. The Bitcoin database services millions of users around the planet and has thus far shown itself to be essentially invulnerable to attack.
Blockchain Technology
Implications and Opportunities For Professional Engineers
You are hereby granted a non-exclusive limited revocable license to use this National Society of Professional Engineers (NSPE) white paper provided full attribution is provided to NSPE
Corda
White papers
A distributed ledger made up of mutually distrusting nodes would allow for a single global database that records the state of deals and obligations between institutions and people
Ethereum
A next generation smart contract
When Satoshi Nakamoto first set the Bitcoin blockchain into motion in January 2009, he was simultaneously introducing two radical and untested concepts.
Blockchain
Opportunities for Health Care
by RJ Krawiec, Dan Housman, Mark White, Mariya Filipova, Florian Quarre, Dan Barr, Allen Nesbitt, Kate Fedosova, Jason Killmeyer, Adam Israel, Lindsay Tsai
Hewlett Packard
Blockchain in the financial services industry
Blockchain is a technology that creates a distributed ledger of transactions on a network that is secure, tamper-proof, and easily accessible.
Stratis
Blockchain Solution
Blockchain or Distributed Ledger Technology (DLT) offers a radically different paradigm of storing and managing information online.
Embracing Disruption
Tapping the potential of distributed
DTCC is an industry-owned and governed financial market utility with more than 40 years of experience mitigating risk
#MTFLabs:Blockchain
Whitepaper
In late May of 2016, a diverse group of experts met at #MTFBerlin, to participate in a laboratory in which they would experiment, test ideas and explore how blockchain technology
D+H
Financial Technologies
Heralding a New Era in Financial Services In recent months, hardly a day has passed without news of further initiatives and investments in blockchain
Digital Assets on Public Blockchains
White Paper
Digital asset management is one of promising applications of blockchain technology. Blockchains could provide principal disintermediation between digital asset issuers, application developers and consumers and decouple tasks.
Æternity blockchain
The trustless, decentralized and purely functional oracle machine
— Since the introduction of Ethereum in 2014 there has been great interest in decentralized trustless applications (smart contracts).
Finance and Economics Discussion Series
Divisions of Research & Statistics and Monetary.
Digital innovations in finance, loosely known as fintech, have garnered a great deal of attention across the financial industry.
Uport
A platform for self-sovereign identity.
Uport is a secure, easy-to-use system for self-sovereign identity, built on Ethereum. The uPort technology consists of three main components: smart contracts, developer libraries, and a mobile app.
Tether
Fiat currencies on the Bitcoin blockchain
A digital token backed by fiat currency provides individuals and organizations with a robust and decentralized method of exchanging value while using a familiar accounting unit
Blockfreight
The blockchain for global freight.
April 26th | This day now marks two revolutions in freight, 60 years apart. The first was in 1956 with the launch Malcom McLean’s shipping container introducing.
Blockchain Technologies
A whitepaper discussing.
The healthcare industry suffers from an inability to clearly communicate costs in a timely and easy-to-understand format.
Blockchain
In Capital Markets
The aim of this joint report by Euroclear and Oliver Wyman is to help leaders in capital markets to understand the potential of the technology, lay out the paths for its adoption, and present.
PAR
Productive Asset Record System
An open investment recording system built with intelligent lending and hedge fund administration in mind.
Storj
A Peer-to-Peer Cloud Storage Network
A peer-to-peer cloud storage network implementing client-side encryption would allow users to transfer and share data without reliance on a third party storage provider.
Creditbit
WHITE PAPER
Creditbit is a relatively young cryptocurrency, developed on an independent Bitcoin-like Blockchain on December 2015.
TATA
Blockchain for the Internet of Things
Blockchain has begun to have a signicant inuence in the Internet of Things by enhancing security, empowering the incorporation of an increasing number of devices into the ecosystem.
Finra
Distributed Ledger Technology: Implications of Blockchain for the Securities Industry1
Distributed Ledger Technology (DLT) (also known as blockchain technology or distributed database technology) has attracted significant interest and funding in the financial services industry in recent years.
Sia
Simple Decentralized Storage
The authors introduce Sia, a platform for decentralized storage. Sia enables the formation of storage contracts between peers.
DIONS
Whitepaper
The development of modern cryptocurrencies began in 2008 with the publication of an article by Satoshi Nakamoto [1] and Bitcoin release, although it should be noted, some work in this direction was made earlier[2].
Proving Ethereum for the Clearing Use Case
Emerald Performance Testing Technical Paper
The current cross-border clearing and settlement value chain is costly, inefficient, and not transparent.
Gnosis
White paper
Prediction markets are poised to become one of the most disruptive innovations in capital markets and data science since the beginning of the Information Revolution.
Filecoin
A Cryptocurrency Operated File Storage Network
Filecoin is a distributed electronic currency similar to Bitcoin. Unlike Bitcoin’s computation-only proof-of-work, Filecoin’s proof-of-work function includes a proof-of-retrievability component, which requires nodes to prove they store a particular file.
SWISSCOIN
Whitepaper
January 3, 2009 has marked the beginning of a new era of globalisation and world interconnection: the first Bitcoin transaction1 has occurred.
SWISSCOIN
Whitepaper
January 3, 2009 has marked the beginning of a new era of globalisation and world interconnection: the first Bitcoin transaction1 has occurred.
Open-Transactions
Secure Contracts between Untrusted Parties
A low-trust notary could replace conventional transaction servers and would allow users to gain access to safe, fast, inexpensive, off-chain transactions with increased functionality.
WINGS
White Paper
WINGS is a blockchain platform that seeds and nurtures a community dedicated to the launching, backing and promotion of new projects proposals through a fluid organizational model referred to as a Decentralized Autonomous Organization (DAO).
Fab City
Locally productive, globally connected self-sufcient cities
More than 200 years since the Industrial Revolution, global urbanisation keeps accelerating. United Nations projections indicate that 75% of the human population will be living in cities by 2050.
PWC
Blockchain – an opportunity for energy producers and consumers?
Blockchain is a special technology for peer-to-peer transaction platforms that uses decentralised storage to record all transaction data.
Teambrella
A PeertoPeer Insurance System
Most insurance services are currently both inefficient and nontransparent. We propose a way to solve these issues by implementing a system that provides peertopeer insurance.
Plutus
White Paper
The Plutus Mobile Application enables a user to make contactless Bitcoin payments at any merchant with a Near Field Communication (NFC) enabled checkout terminal.
Taas
Token-as-a-Service
TaaS introduces an innovation business model that allows investeros to capitalize on the rise of blockchain markets without dealing with hurdles. risk and technical barriers.
An Introduction to Bitcoin and Blockchain Technology
Whitepaper
Bitcoin technology began to enter the public discourse in 2011, largely through its association as an anonymous payment system used on illicit and underground websites.
Decent
Whitepaper
True innovation is rare, especially in the world of media. More difficult is to determine which aspect of media thrives for development most. Majority of mainstream media do not truly innovate as they are happy with their current business models.
Chronicled
Open Registry for IoT
With a blockchain-hosted Open Registry for Internet of Things, we envision a future where everything—from your car, to a work of art, to the glass of wine you drink at the end of a long day—can have a unique and unforgeable identity, life, and history on the Internet.
PPCoin
Peer-to-Peer Crypto-Currency with Proof-of-Stake
A peer-to-peer crypto-currency design derived from Satoshi Nakamoto’s Bitcoin. Proof-of-stake replaces proof-of-work to provide most of the network security.
A Securities Law Framework for Blockchain Tokens
White Paper
A blockchain token is a digital token created on a blockchain as part of a decentralized softwareprotocol.
Kadena
The first scalable, high performance private blockchain
This paper introduces Kadena, the first private/permissioned blockchain technology to achieve high performance at scale. K
Capgemini
Leveraging Blockchain to Transform Insurance Industry
‘The revolution will not be televised. It will be cryptographically time stamped on the block chain.
JPX
Applicability of Distributed Ledger Technology to Capital Market Infrastructure
This material was compiled based on the results of research and studies by directors, officers, and/or employees of Japan Exchange Group, Inc.,
Equibit
A Peer-to-Peer Electronic Equity System
The registration, transfer, clearing and settlement of equities represents a significant part of economic activity currently underserved by modern technological innovation.
ETHEREUM
A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER EIP-150 REVISION
The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, not least Bitcoin.
ShoCard
White Paper
With the use of a mobile app and facial recognition, travelers need to be only identified once and can be quickly verified by nonaffiliated airlines, airports or other agencies.
The Stellar Consensus Protoco
A Federated Model for Internet-level Consensus
Financial infrastructure is currently a mess of closed systems. Gaps between these systems mean that transaction costs are high [Provost 2013] and money moves slowly across political and geographic boundaries [Banning-Lover 2015; CGAP 2008].
A Protocol for Interledger Payments
White paper
We present a protocol for payments across payment systems. It enables secure transfers between ledgers and allows anyone with accounts on two ledgers to create a connection between them.
REVIEW OF CRYPTONOTE
White paper
This document is not intended as financial advice; it is one mathematician’s take on the white paper before digging into the code. I’ve learned a lot writing this document.
Blockchain Technology
Possibilities for the U.S.Postal Service
Blockchain technology allows peers to exchange money directly without the need for a traditional financial intermediary, lowering the cost and increasing the speed of transactions.
ETLA
White Paper
In November 2008, a mysterious white paper appeared on the Internet in all quietness. Written under the pseudonym Satoshi Nakamoto, the paper described a new method for creating a fully distributed digital currency system by cryptographically
Filament Foundations
White Paper
As more and more devices are connected in the Internet of Things (IoT), an enormous amount of value is waiting to be unlocked.
Tangle
White Paper
In this paper we analyze the technology used as a backbone of iota (a cryptocurrency for Internet-of-Things industry).
Dragonfly Fintech
Blockchain Technology A New Paradigm
A blockchain is a system to share distributed data in a robust and mathematically secure way. Due to the ubiquity of data at the core of many real-world systems, blockchain technology is already revolutionizing data processing in many domains.
Consensys
White Paper
This report hopes to bring the World Government Summit a fresh perspective on the current state of blockchain technology. The report explores how the blockchain will drive positive changes in nearly every area of civic life over the next ten years.
World Economic Forum
White Paper
There is widespread recognition among leaders in most industries that the role of digital technology is rapidly shifting, from being a driver of marginal efficiency to an enabler of fundamental innovation and disruption.
Imf staff discussion note
Virtual Currencies and Beyond: Initial Considerations
New technologies—supported by advances in encryption and network computing—are driving transformational change in the global economy, including in how goods, services and assets are exchanged.
Enabling Blockchain Innovations with Pegged Sidechains
White Paper
Since the introduction of Bitcoin[Nak09] in 2009, and the multiple computer science and electronic cash innovations it brought, there has been great interest in the potential of decentralised cryptocurrencies.
Adel
White Paper
This document and any other Adel documents do not constitute a prospectus of any sort and are not a solicitation for investment.
Fraunhofer
White Paper
The »Industrial Data Space« is a virtual data space using standards and common governance models to facilitate the secure exchange and easy linkage of data in business ecosystems.
Blockchain
DECENTRALIZED TRUST
Entreprenörskapsforum är en oberoende stiftelse och den ledande nätverksorganisationen för att initiera och kommunicera policyrelevant forskning om entreprenörskap, innovationer och småföretag.
ECOMP
(Enhanced Control, Orchestration, Management & Policy) Architecture White Paper
AT&T’s Domain 2.0 (D2) program is focused on leveraging cloud technologies (the AT&T Integrated Cloud – AIC) and network virtualization to offer services while reducing Capital.