From the paper, to the mechanism, to what actually happened.

• CryptoNote

  2013 · Design paper · Privacy

  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.

  Full study
• Zerocoin

  2013 · Design paper · Privacy

  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.

  Full study
• Zerocash

  2014 · Design paper · Privacy

  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.

  Full study
• Monero

  2016 · Design paper · Privacy

  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.

  Full study
• Mimblewimble

  2016 · Design paper · Privacy

  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.

  Full study
• Cardano

  2017 · Design paper · Reach consensus

  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.

  Full study
• Algorand

  2017 · Design paper · Reach consensus

  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.

  Full study
• Avalanche

  2018 · Design paper · Reach consensus

  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.

  Full study
• Solana

  2018 · Design paper · Reach consensus

  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.

  Full study
• Tendermint

  2014 · Design paper · Reach consensus

  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.

  Full study
• Tezos

  2014 · Design paper · Reach consensus

  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.

  Full study
• Hedera

  2016 · Design paper · Reach consensus

  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.

  Full study
• Nano

  2017 · Design paper · Reach consensus

  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.

  Full study
• Zilliqa

  2017 · Design paper · Reach consensus

  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.

  Full study
• Harmony

  2019 · Design paper · Reach consensus

  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.

  Full study
• MultiversX

  2019 · Design paper · Reach consensus

  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.

  Full study
• NEAR

  2019 · Design paper · Reach consensus

  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.

  Full study
• Aptos

  2022 · Design paper · Reach consensus

  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.

  Full study
• Sui

  2022 · Design paper · Reach consensus

  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.

  Full study
• Diem

  2020 · Historical document · Reach consensus

  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.

  Full study
• Mina

  2020 · Design paper · Reach consensus

  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.

  Full study
• TON

  2021 · Design paper · Reach consensus

  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.

  Full study
• Kadena

  2018 · Design paper · Reach consensus

  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.

  Full study
• EOSIO

  2018 · Design paper · Reach consensus

  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.

  Full study
• Internet Computer

  2018 · Design paper · Reach consensus

  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.

  Full study
• Polkadot

  2016 · Design paper · Connect

  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.

  Full study
• Cosmos

  2016 · Design paper · Connect

  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.

  Full study
• Lightning

  2016 · Design paper · Scale

  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.

  Full study
• Plasma

  2017 · Design paper · Scale

  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.

  Full study
• Arbitrum

  2018 · Design paper · Scale

  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.

  Full study
• StarkWare

  2018 · Design paper · Scale

  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.

  Full study
• Celestia

  2019 · Design paper · Scale

  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.

  Full study
• EigenLayer

  2023 · Design paper · Scale

  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.

  Full study
• Polygon

  2019 · Design paper · Scale

  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.

  Full study
• Uniswap

  2020 · Design paper · Move value

  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.

  Full study
• Uniswap

  2021 · Design paper · Move value

  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.

  Full study
• Curve

  2019 · Design paper · Move value

  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.

  Full study
• Balancer

  2019 · Design paper · Move value

  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.

  Full study
• 0x

  2017 · Design paper · Move value

  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'.

  Full study
• Bancor

  2017 · Design paper · Move value

  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.

  Full study
• THORChain

  2020 · Design paper · Move value

  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.

  Full study
• Compound

  2019 · Design paper · Move value

  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.

  Full study
• Aave

  2020 · Design paper · Move value

  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.

  Full study
• Maker

  2017 · Design paper · Move value

  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.

  Full study
• Terra

  2019 · Failure case · Move value

  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.

  Full study
• Chainlink

  2017 · Design paper · Data

  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'.

  Full study
• The Graph

  2020 · Design paper · Data

  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.

  Full study
• Augur

  2018 · Design paper · Data

  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.

  Full study
• Ocean

  2019 · Design paper · Data

  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.

  Full study
• Bittensor

  2021 · Design paper · Data

  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.

  Full study
• SingularityNET

  2017 · Design paper · Data

  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.

  Full study
• Filecoin

  2017 · Design paper · Store and connect

  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.

  Full study
• Arweave

  2018 · Design paper · Store and connect

  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.

  Full study
• Helium

  2018 · Design paper · Store and connect

  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.

  Full study
• Golem

  2016 · Design paper · Store and connect

  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.

  Full study
• Livepeer

  2017 · Design paper · Store and connect

  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.

  Full study
• Basic Attention Token

  2018 · Design paper · Store and connect

  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.

  Full study
• Secret Network

  2015 · Design paper · 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.

  Full study
• Oasis

  2019 · Design paper · Privacy

  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.

  Full study
• PBFT

  1999 · Design paper · Reach consensus

  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.

  Full study
• Bitcoin-NG

  2016 · Design paper · Reach consensus

  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.

  Full study
• GHOST

  2015 · Design paper · Reach consensus

  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.

  Full study
• PHANTOM

  2018 · Design paper · Reach consensus

  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.

  Full study
• SPECTRE

  2016 · Design paper · Reach consensus

  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.

  Full study
• Casper FFG

  2017 · Design paper · Reach consensus

  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.

  Full study
• HotStuff

  2019 · Design paper · Reach consensus

  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.

  Full study
• HoneyBadgerBFT

  2016 · Design paper · Reach consensus

  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.

  Full study
• Narwhal and Tusk

  2022 · Design paper · Reach 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.

  Full study
• Snow White

  2017 · Design paper · Reach 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.

  Full study
• Thunderella

  2017 · Design paper · Reach consensus

  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.

  Full study
• Confidential Transactions

  2015 · Design paper · Privacy

  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.

  Full study
• Bulletproofs

  2018 · Design paper · Privacy

  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.

  Full study
• Groth16

  2016 · Design paper · Privacy

  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.

  Full study
• PLONK

  2019 · Design paper · Privacy

  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.

  Full study
• Halo

  2019 · Design paper · Privacy

  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.

  Full study
• Zexe

  2020 · Design paper · Privacy

  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.

  Full study
• Fraud and data availability proofs

  2018 · Design paper · Scale

  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.

  Full study
• TrueBit

  2017 · Design paper · Scale

  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.

  Full study
• KZG commitments

  2010 · Design paper · Scale

  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.

  Full study
• Proofs of space

  2015 · Design paper · Reach consensus

  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.

  Full study
• Verifiable delay functions

  2018 · Design paper · Reach consensus

  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.

  Full study
• Atomic swaps

  2018 · Design paper · Connect

  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.

  Full study
• Sprites

  2017 · Design paper · Connect

  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.

  Full study
• IBC

  2020 · Design paper · Connect

  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.

  Full study
• Flash Boys 2.0

  2019 · Design paper · Move value

  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.

  Full study
• Uniswap v4

  2023 · Design paper · Move value

  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.

  Full study
• TWAMM

  2021 · Design paper · Move value

  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.

  Full study
• Liquity

  2021 · Design paper · Move value

  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.

  Full study
• ERC-4337

  2021 · Design paper · Data

  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.

  Full study
• Gasper

  2020 · Design paper · Reach consensus

  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.

  Full study
• Prism

  2019 · Design paper · Reach consensus

  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.

  Full study
• Streamlet

  2020 · Design paper · Reach consensus

  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.

  Full study
• FruitChains

  2016 · Design paper · Reach consensus

  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.

  Full study
• DAG-Rider

  2021 · Design paper · Reach consensus

  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.

  Full study
• Bullshark

  2022 · Design paper · Reach consensus

  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.

  Full study
• EIP-1559

  2019 · Design paper · Move value

  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.

  Full study
• Transaction fee mechanism design

  2020 · Design paper · Move value

  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.

  Full study
• EIP-4844

  2022 · Design paper · Scale

  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.

  Full study
• BitVM

  2023 · Design paper · Scale

  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.

  Full study
• Cairo

  2021 · Design paper · Scale

  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.

  Full study
• Nova

  2021 · Design paper · Privacy

  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.

  Full study
• Marlin

  2019 · Design paper · Privacy

  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.

  Full study
• FROST

  2020 · Design paper · Privacy

  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.

  Full study
• MuSig2

  2020 · Design paper · Privacy

  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.

  Full study
• Taproot

  2020 · Design paper · Privacy

  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.

  Full study
• Curve Cryptoswap

  2021 · Design paper · Move value

  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.

  Full study
• crvUSD design

  2022 · Design paper · Move value

  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.

  Full study
• UMA

  2020 · Design paper · Data

  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.

  Full study
• Perun

  2017 · Design paper · Scale

  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.

  Full study
• Semaphore

  2020 · Design paper · Privacy

  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.

  Full study
• Ouroboros Genesis

  2018 · Design paper · Reach consensus

  Genesis gives a way to join late, when honest stake may be dynamic, without a checkpoint the protocol itself cannot justify.

  Full study
• Stake bleeding

  2018 · Design paper · Reach consensus

  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.

  Full study
• Bitcoin in asynchronous networks

  2017 · Design paper · Reach consensus

  The paper analyses Nakamoto consensus when the delay bound is not a clean round, and states how confirmation has to grow with that delay.

  Full study
• OmniLedger

  2018 · Design paper · Scale

  OmniLedger reassigns validators to shards, uses a bias-resistant randomness beacon, and atomically commits cross-shard transactions.

  Full study
• RapidChain

  2018 · Design paper · Scale

  RapidChain shards the ledger completely and uses a committee protocol that tolerates a smaller honest fraction inside a committee than a classical open network.

  Full study
• Compact multi-signatures

  2018 · Design paper · Privacy

  The paper gives a BLS multi-signature that stays compact and blocks the rogue-key attack with a proof of possession of each key.

  Full study
• Zether

  2020 · Design paper · Privacy

  Zether is a contract for confidential transfers and confidential anonymous transfers, with balances as commitments and a proof that the spend is well formed.

  Full study
• Inner-product arguments

  2016 · Design paper · Privacy

  The paper compresses an inner-product argument so a circuit proof can be logarithmic without a trusted setup, in the discrete-log model.

  Full study
• Aurora

  2019 · Design paper · Privacy

  Aurora proves rank-one constraint systems with a transparent setup, using a FRI-style proximity test rather than a pairing.

  Full study
• Spartan

  2020 · Design paper · Privacy

  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.

  Full study
• HyperPlonk

  2022 · Design paper · Privacy

  HyperPlonk replaces that transform with a sumcheck so the prover is linear in the number of gates, and it allows higher-degree custom gates.

  Full study
• SuperNova

  2022 · Design paper · Scale

  SuperNova folds a universal machine by switching among circuits without a universal circuit that contains every instruction.

  Full study
• HyperNova

  2023 · Design paper · Scale

  HyperNova generalises folding to customisable constraint systems so a recursive proof can follow the arithmetisation the circuit actually uses.

  Full study
• Ouroboros Crypsinous

  2019 · Design paper · Privacy

  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.

  Full study
• Powers of Tau

  2017 · Design paper · Privacy

  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.

  Full study
• Vault

  2019 · Design paper · Scale

  Vault compresses Algorand's state and the proofs a client needs so a bootstrapping node does not replay the entire history.

  Full study
• Stubborn mining

  2016 · Design paper · Reach consensus

  The paper generalises the withholding strategies and shows they compose with an eclipse attack that starves a node of honest blocks.

  Full study
• Proof-of-work security

  2016 · Design paper · Reach consensus

  The paper builds a quantitative model of stale blocks, double-spends and selfish mining across proof-of-work parameters.

  Full study
• Dumbo

  2020 · Design paper · Reach consensus

  Dumbo reduces the cost of the asynchronous path by improving the reliable broadcast and the binary agreement that HoneyBadger-style protocols stack together.

  Full study
• Bitcoin SoK

  2015 · Design paper · Reach consensus

  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.

  Full study
• SpaceMint

  2015 · Design paper · Reach consensus

  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.

  Full study
• Bitcoin as a beacon

  2015 · Design paper · Data

  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.

  Full study
• Bitcoin as a ledger

  2017 · Design paper · Reach consensus

  The paper gives a composable ledger functionality and shows that a bitcoin-like protocol realises it under stated assumptions.

  Full study
• OHIE

  2020 · Design paper · Scale

  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.

  Full study
• Chainspace

  2017 · Design paper · Scale

  Chainspace shards objects, and a transaction names the objects it will read and write so the shards involved can run a distributed commit.

  Full study
• Shoal

  2024 · Design paper · Reach consensus

  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.

  Full study
• Mysticeti

  2023 · Design paper · Reach consensus

  Mysticeti commits from an uncertified DAG: blocks are signed by their authors and the commit rule does not require a certificate first.

  Full study
• Cordial Miners

  2023 · Design paper · Reach consensus

  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.

  Full study
• Hashcash

  2002 · Design paper · Reach consensus

  The client finds a partial hash collision. The server checks it cheaply. The stamp is the cost.

  Full study
• b-money

  1998 · Design paper · Move value

  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.

  Full study
• Lamport clocks

  1978 · Design paper · Reach consensus

  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.

  Full study
• Bitcoin

  2008 · Design paper · Reach consensus

  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.

  Full study
• Paxos

  1998 · Design paper · Reach consensus

  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.

  Full study
• Paxos Made Simple

  2001 · Design paper · Reach consensus

  The same two-phase majority protocol, written as pseudocode: prepare, accept, and learn.

  Full study
• Raft

  2014 · Design paper · Reach consensus

  A strong leader accepts entries, replicates them in order, and commits only when a majority of the current term has stored them.

  Full study
• Byzantine Generals

  1982 · Design paper · Reach consensus

  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.

  Full study
• Partial Synchrony

  1988 · Design paper · Reach consensus

  Safety can hold with no timing assumption. Liveness can wait for a period, after some unknown instant, when messages arrive within a bound.

  Full study
• FLP

  1985 · Design paper · Reach consensus

  No deterministic protocol does all three. Any protocol that is always safe has an execution that never decides.

  Full study
• Bitcoin Backbone

  2015 · Design paper · Reach consensus

  Common prefix, chain quality and chain growth, under a synchronous network and an honest majority of hash power.

  Full study
• Sleepy Consensus

  2017 · Design paper · Reach 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.

  Full study
• Ouroboros Praos

  2018 · Design paper · Reach consensus

  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.

  Full study
• Selfish Mining

  2014 · Design paper · Reach consensus

  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.

  Full study
• Eclipse Attacks

  2015 · Design paper · Reach consensus

  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.

  Full study
• Flexible Paxos

  2016 · Design paper · Reach consensus

  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.

  Full study
• EPaxos

  2013 · Design paper · Reach consensus

  Any replica can propose. Commands that do not conflict commit in one round. Commands that conflict take a second round that records the dependency.

  Full study
• Conflux

  2018 · Design paper · Reach consensus

  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.

  Full study
• Jolteon and Ditto

  2022 · Design paper · Reach consensus

  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.

  Full study
• SBFT

  2019 · Design paper · Reach consensus

  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.

  Full study
• Zyzzyva

  2007 · Design paper · Reach consensus

  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.

  Full study
• Weak Subjectivity

  2014 · Design paper · Reach consensus

  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.

  Full study
• Raft membership

  2014 · Design paper · Reach consensus

  Membership changes one server at a time, or through joint consensus, so there is never a moment when two disjoint majorities can both commit.

  Full study
• Bitcoin network

  2013 · Design paper · Reach consensus

  Measure how Bitcoin announcements travel. The median time and the long tail are what set a safe block interval.

  Full study
• Verifier's dilemma

  2015 · Design paper · Reach consensus

  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.

  Full study
• Merged mining

  2017 · Design paper · Reach consensus

  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.

  Full study
• Nothing at stake

  2016 · Design paper · Reach consensus

  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.

  Full study
• Range proofs

  2018 · Design paper · Privacy

  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.

  Full study
• Dandelion

  2017 · Design paper · Privacy

  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.

  Full study
• Pinocchio

  2013 · Design paper · Privacy

  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.

  Full study
• Sonic

  2019 · Design paper · Privacy

  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.

  Full study
• FRI

  2018 · Design paper · Privacy

  FRI is the proximity test: fold the polynomial in rounds until a constant remains, and sample enough points that a cheating polynomial is caught.

  Full study
• Optimism Cannon

  2023 · Design paper · Scale

  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.

  Full study
• Sovereign rollups

  2022 · Design paper · Scale

  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.

  Full study
• Validium

  2020 · Design paper · Scale

  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.

  Full study
• Based rollups

  2023 · Design paper · Scale

  A based rollup lets the parent's proposers order the rollup's transactions. There is no separate sequencer to bribe or to wait for.

  Full study
• Espresso

  2022 · Design paper · Scale

  A shared sequencer orders transactions for many rollups. Each rollup still executes its own state. The sequencer sells order, not execution.

  Full study
• Payment channels

  2013 · Design paper · Connect

  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.

  Full study
• Eltoo

  2018 · Design paper · Connect

  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.

  Full study
• Channel factories

  2018 · Design paper · Connect

  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.

  Full study
• Discreet log contracts

  2017 · Design paper · Move value

  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.

  Full study
• Constant function market makers

  2020 · Design paper · Move value

  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.

  Full study
• Yield Space

  2020 · Design paper · Move value

  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.

  Full study
• Morpho

  2023 · Design paper · Move value

  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.

  Full study
• ERC-4626

  2022 · Design paper · Move value

  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.

  Full study
• Flash loans

  2020 · Design paper · Move value

  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.

  Full study
• Uniswap v1

  2018 · Design paper · Move value

  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.

  Full study
• GMX

  2021 · Design paper · Move value

  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.

  Full study
• Everlasting options

  2021 · Design paper · Move value

  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.

  Full study
• IPFS

  2014 · Design paper · Store and connect

  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.

  Full study
• Kademlia

  2002 · Design paper · Store and connect

  Nodes have identifiers. Distance is XOR. Each node keeps contacts in buckets by distance, and a lookup walks toward the target in logarithmic steps.

  Full study
• Verkle trees

  2018 · Design paper · Scale

  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.

  Full study
• Decentralized identifiers

  2022 · Design paper · Data

  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.

  Full study
• Verifiable credentials

  2025 · Design paper · Data

  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.

  Full study
• BBS signatures

  2016 · Design paper · Privacy

  A BBS-family signature can be proved in zero knowledge so a holder reveals only some messages and produces an unlinkable presentation.

  Full study
• EIP-7702

  2024 · Design paper · Data

  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.

  Full study
• BIP 32

  2012 · Design paper · Privacy

  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.

  Full study
• BIP 39

  2013 · Design paper · Privacy

  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.

  Full study
• BIP 44

  2014 · Design paper · Privacy

  A path is purpose, coin type, account, change, and index. Accounts are separated so one seed can hold many identities without mixing their change.

  Full study
• BIP 141

  2015 · Design paper · Scale

  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.

  Full study
• BIP 174

  2017 · Design paper · Move value

  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.

  Full study
• BIP 324

  2019 · Design paper · Privacy

  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.

  Full study
• ERC-20

  2015 · Design paper · Move value

  A token contract exposes total supply, balance, transfer, and allowances. Wallets and exchanges can integrate one interface.

  Full study
• ERC-721

  2018 · Design paper · Move value

  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.

  Full study
• ERC-1155

  2018 · Design paper · Move value

  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.

  Full study
• BIP 8

  2017 · Design paper · Privacy

  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.

  Full study
• BIP 9

  2015 · Design paper · Privacy

  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.

  Full study
• BIP 11

  2011 · Design paper · Privacy

  BIP 11, M-of-N Standard Transactions. M-of-N-signatures required transactions as a new 'standard' transaction type.

  Full study
• BIP 13

  2011 · Design paper · Privacy

  BIP 13, Address Format for pay-to-script-hash. A new type of Bitcoin address to support arbitrarily complex transactions.

  Full study
• BIP 16

  2012 · Design paper · Reach consensus

  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.

  Full study
• BIP 18

  2012 · Design paper · Reach consensus

  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.

  Full study
• BIP 22

  2012 · Design paper · Data

  BIP 22, getblocktemplate - Fundamentals. A new JSON-RPC method for "smart" Bitcoin miners and proxies.

  Full study
• BIP 23

  2012 · Design paper · Data

  BIP 23, getblocktemplate - Pooled Mining. Extensions to the getblocktemplate JSON-RPC call to enhance pooled mining.

  Full study
• BIP 30

  2012 · Design paper · Reach consensus

  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.

  Full study
• BIP 31

  2012 · Design paper · Store and connect

  BIP 31, Pong message. This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections.

  Full study
• BIP 34

  2012 · Design paper · Reach consensus

  BIP 34, Block v2, Height in Coinbase. Bitcoin blocks and transactions are versioned binary structures.

  Full study
• BIP 35

  2012 · Design paper · Scale

  BIP 35, mempool message. Make a network node's transaction memory pool accessible via a new "mempool" message.

  Full study
• BIP 37

  2012 · Design paper · Scale

  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.

  Full study
• BIP 38

  2012 · Design paper · Privacy

  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.

  Full study
• BIP 42

  2014 · Design paper · Reach consensus

  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.

  Full study
• BIP 43

  2014 · Design paper · Data

  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).

  Full study
• BIP 45

  2014 · Design paper · Privacy

  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).

  Full study
• BIP 47

  2015 · Design paper · Store and connect

  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.

  Full study
• BIP 48

  2020 · Design paper · Data

  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).

  Full study
• BIP 49

  2016 · Design paper · Data

  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.

  Full study
• BIP 61

  2014 · Design paper · Store and connect

  BIP 61, Reject P2P message. A new message type for the Bitcoin peer-to-peer network.

  Full study
• BIP 65

  2014 · Design paper · Reach consensus

  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.

  Full study
• BIP 66

  2015 · Design paper · Reach consensus

  BIP 66, Strict DER signatures. This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.

  Full study
• BIP 67

  2015 · Design paper · Scale

  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.

  Full study
• BIP 68

  2015 · Design paper · Connect

  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.

  Full study
• BIP 69

  2015 · Design paper · Privacy

  BIP 69, Lexicographical Indexing of Transaction Inputs and Outputs. Currently there is no standard for bitcoin wallet clients when ordering transaction inputs and outputs.

  Full study
• BIP 70

  2013 · Design paper · Store and connect

  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.

  Full study
• BIP 71

  2013 · Design paper · Data

  BIP 71, Payment Protocol MIME types. A MIME (RFC 2046) Media Type for Bitcoin payment request messages.

  Full study
• BIP 72

  2013 · Design paper · Data

  BIP 72, bitcoin: uri extensions for Payment Protocol. An extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70).

  Full study
• BIP 73

  2013 · Design paper · Data

  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.

  Full study
• BIP 75

  2015 · Design paper · Privacy

  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.

  Full study
• BIP 84

  2017 · Design paper · Data

  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.

  Full study
• BIP 85

  2020 · Design paper · Privacy

  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.

  Full study
• BIP 86

  2021 · Design paper · Privacy

  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.

  Full study
• BIP 87

  2020 · Design paper · Scale

  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).

  Full study
• BIP 88

  2020 · Design paper · Data

  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.

  Full study
• BIP 89

  2025 · Design paper · Privacy

  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.

  Full study
• BIP 90

  2016 · Design paper · Scale

  BIP 90, Buried Deployments. Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers.

  Full study
• BIP 91

  2017 · Design paper · Reach consensus

  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%.

  Full study
• BIP 94

  2024 · Design paper · Reach consensus

  BIP 94, Testnet 4. A new test network with the goal to replace Testnet 3.

  Full study
• BIP 111

  2015 · Design paper · Store and connect

  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.

  Full study
• BIP 112

  2015 · Design paper · Reach consensus

  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.

  Full study
• BIP 113

  2015 · Design paper · Reach consensus

  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.

  Full study
• BIP 123

  2015 · Design paper · Store and connect

  BIP 123, BIP Classification. This document describes a classification scheme for BIPs.

  Full study
• BIP 125

  2015 · Design paper · Scale

  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.

  Full study
• BIP 127

  2019 · Design paper · Data

  BIP 127, Simple Proof-of-Reserves Transactions. A simple way to construct proof-of-reserves transactions.

  Full study
• BIP 130

  2015 · Design paper · Store and connect

  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".

  Full study
• BIP 133

  2016 · Design paper · Store and connect

  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.

  Full study
• BIP 137

  2019 · Design paper · Move value

  BIP 137, Signatures of Messages using Private Keys. This document describes a signature format for signing messages with Bitcoin private keys.

  Full study
• BIP 143

  2016 · Design paper · Reach consensus

  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.

  Full study
• BIP 144

  2016 · Design paper · Scale

  BIP 144, Segregated Witness (Peer Services). New messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures.

  Full study
• BIP 145

  2016 · Design paper · Data

  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]].

  Full study
• BIP 147

  2016 · Design paper · Reach consensus

  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 .

  Full study
• BIP 148

  2017 · Design paper · Reach consensus

  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".

  Full study
• BIP 152

  2016 · Design paper · Store and connect

  BIP 152, Compact Block Relay. Compact blocks on the wire as a way to save bandwidth for nodes on the P2P network.

  Full study
• BIP 155

  2019 · Design paper · Store and connect

  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] .

  Full study
• BIP 157

  2017 · Design paper · Scale

  BIP 157, Client Side Block Filtering. A new light client protocol in Bitcoin that improves upon currently available options.

  Full study
• BIP 158

  2017 · Design paper · Store and connect

  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 .

  Full study
• BIP 159

  2017 · Design paper · Store and connect

  BIP 159, NODE_NETWORK_LIMITED service bit. Define a service bit that allows pruned peers to signal their limited services.

  Full study
• BIP 173

  2017 · Design paper · Data

  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.

  Full study
• BIP 176

  2017 · Design paper · Data

  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.

  Full study
• BIP 179

  2019 · Design paper · Data

  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.

  Full study
• BIP 321

  2024 · Design paper · Data

  BIP 321, URI Scheme. A URI scheme for describing Bitcoin payment instructions.

  Full study
• BIP 322

  2018 · Design paper · Store and connect

  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.

  Full study
• BIP 325

  2019 · Design paper · Store and connect

  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.

  Full study
• BIP 328

  2024 · Design paper · Privacy

  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.

  Full study
• BIP 339

  2020 · Design paper · Store and connect

  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.

  Full study
• BIP 342

  2020 · Design paper · Reach consensus

  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]]).

  Full study
• BIP 347

  2023 · Design paper · Connect

  BIP 347, OP_CAT in Tapscript. OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack.

  Full study
• BIP 350

  2020 · Design paper · Data

  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.

  Full study
• BIP 352

  2023 · Design paper · Scale

  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.

  Full study
• BIP 353

  2024 · Design paper · Data

  BIP 353, DNS Payment Instructions. A standard format for encoding [[bip-0021.mediawiki|BIP 21]] URI schemes in DNS TXT records.

  Full study
• BIP 370

  2021 · Design paper · Privacy

  BIP 370, PSBT Version 2. PSBT Version 2 (PSBTv2) only specifies new fields and field inclusion/exclusion requirements.

  Full study
• BIP 371

  2021 · Design paper · Privacy

  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.

  Full study
• BIP 373

  2024 · Design paper · Privacy

  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]]).

  Full study
• BIP 380

  2021 · Design paper · Privacy

  BIP 380, Output Script Descriptors General Operation. Output Script Descriptors are a simple language which can be used to describe collections of output scripts.

  Full study
• BIP 381

  2021 · Design paper · Store and connect

  BIP 381, Non-Segwit Output Script Descriptors. This document specifies pk() , pkh() , and sh() output script descriptors.

  Full study
• BIP 382

  2021 · Design paper · Privacy

  BIP 382, Segwit Output Script Descriptors. This document specifies wpkh() , and wsh() output script descriptors.

  Full study
• BIP 383

  2021 · Design paper · Privacy

  BIP 383, Multisig Output Script Descriptors. This document specifies multi() , and sortedmulti() output script descriptors.

  Full study
• BIP 384

  2021 · Design paper · Store and connect

  BIP 384, combo() Output Script Descriptors. This document specifies combo() output script descriptors.

  Full study
• BIP 385

  2021 · Design paper · Data

  BIP 385, raw() and addr() Output Script Descriptors. This document specifies raw() and addr() output script descriptors.

  Full study
• BIP 386

  2021 · Design paper · Privacy

  BIP 386, tr() Output Script Descriptors. This document specifies tr() output script descriptors.

  Full study
• BIP 387

  2024 · Design paper · Privacy

  BIP 387, Tapscript Multisig Output Script Descriptors. This document specifies multi_a() and sortedmulti_a() output script descriptors.

  Full study
• BIP 388

  2023 · Design paper · Scale

  BIP 388, Wallet Policies for Descriptor Wallets. Software wallets and hardware signing devices typically partition funds into separate "accounts".

  Full study
• EIP 140

  2017 · Design paper · Scale

  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.

  Full study
• EIP 141

  2017 · Design paper · Scale

  EIP 141, Designated invalid EVM instruction. An instruction is designated to remain as an invalid instruction.

  Full study
• EIP 145

  2017 · Design paper · Scale

  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.

  Full study
• EIP 152

  2016 · Design paper · Connect

  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.

  Full study
• EIP 196

  2017 · Design paper · Scale

  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.

  Full study
• EIP 197

  2017 · Design paper · Scale

  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.

  Full study
• EIP 211

  2017 · Design paper · Scale

  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.

  Full study
• EIP 214

  2017 · Design paper · Scale

  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).

  Full study
• EIP 225

  2017 · Design paper · Privacy

  EIP 225, Clique proof-of-authority consensus protocol. Clique is a proof-of-authority consensus protocol.

  Full study
• EIP 234

  2017 · Design paper · Data

  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.

  Full study
• EIP 627

  2017 · Design paper · Store and connect

  EIP 627, Whisper Specification. The format of Whisper messages within the ÐΞVp2p Wire Protocol.

  Full study
• EIP 658

  2017 · Design paper · Scale

  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.

  Full study
• EIP 684

  2023 · Design paper · Scale

  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.

  Full study
• EIP 695

  2017 · Design paper · Data

  EIP 695, Create `eth_chainId` method for JSON-RPC. Include eth_chainId method in eth_-namespaced JSON-RPC methods.

  Full study
• EIP 706

  2017 · Design paper · Store and connect

  EIP 706, DEVp2p snappy compression. The base networking protocol (DEVp2p) used by Ethereum currently does not employ any form of compression.

  Full study
• EIP 712

  2017 · Design paper · Scale

  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.

  Full study
• EIP 747

  2018 · Design paper · Privacy

  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.

  Full study
• EIP 1052

  2018 · Design paper · Scale

  EIP 1052, EXTCODEHASH opcode. A new opcode, which returns the keccak256 hash of a contract's code.

  Full study
• EIP 1108

  2018 · Design paper · Scale

  EIP 1108, Reduce alt_bn128 precompile gas costs. The elliptic curve arithmetic precompiles are currently overpriced.

  Full study
• EIP 1153

  2018 · Design paper · Scale

  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.

  Full study
• EIP 1193

  2018 · Design paper · Store and connect

  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.

  Full study
• EIP 1283

  2018 · Design paper · Scale

  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.

  Full study
• EIP 1344

  2018 · Design paper · Scale

  EIP 1344, ChainID opcode. An opcode that returns the current chain's EIP-155 unique identifier.

  Full study
• EIP 1884

  2019 · Design paper · Scale

  EIP 1884, Repricing for trie-size-dependent opcodes. Repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption.

  Full study
• EIP 1898

  2019 · Design paper · Data

  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.

  Full study
• EIP 2028

  2019 · Design paper · Scale

  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.

  Full study
• EIP 2124

  2019 · Design paper · Store and connect

  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).

  Full study
• EIP 2159

  2019 · Design paper · Data

  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.

  Full study
• EIP 2200

  2019 · Design paper · Scale

  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].

  Full study
• EIP 2228

  2019 · Design paper · Data

  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.

  Full study
• EIP 2255

  2019 · Design paper · Privacy

  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.

  Full study
• EIP 2364

  2019 · Design paper · Scale

  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.

  Full study
• EIP 2464

  2020 · Design paper · Store and connect

  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.

  Full study
• EIP 2481

  2020 · Design paper · Store and connect

  EIP 2481, eth/66 request identifier. The eth protocol defines various request and response commands that are used to exchange data between Ethereum nodes.

  Full study
• EIP 2537

  2020 · Design paper · Scale

  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.

  Full study
• EIP 2565

  2020 · Design paper · Scale

  EIP 2565, ModExp Gas Cost. Defines the gas cost of the ModExp (0x00..05) precompile.

  Full study
• EIP 2681

  2020 · Design paper · Data

  EIP 2681, Limit account nonce to 2^64-1. Account nonces are currently specified to be arbitrarily long unsigned integers.

  Full study
• EIP 2696

  2020 · Design paper · Store and connect

  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.

  Full study
• EIP 2700

  2020 · Design paper · Privacy

  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.

  Full study
• EIP 2718

  2020 · Design paper · Data

  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.

  Full study
• EIP 2929

  2020 · Design paper · Scale

  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.

  Full study
• EIP 2930

  2020 · Design paper · Scale

  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.

  Full study
• EIP 2935

  2020 · Design paper · Scale

  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.

  Full study
• EIP 2976

  2020 · Design paper · Store and connect

  EIP 2976, Typed Transactions over Gossip. Typed Transactions can be sent over devp2p as TransactionType || TransactionPayload.

  Full study
• EIP 2982

  2020 · Design paper · Reach consensus

  EIP 2982, Serenity Phase 0. Phase 0 of Serenity (eth2), a multi-phased upgrade to the consensus mechanism for Ethereum mainnet.

  Full study
• EIP 3198

  2021 · Design paper · Scale

  EIP 3198, BASEFEE opcode. Adds an opcode that gives the EVM access to the block's base fee.

  Full study
• EIP 3529

  2021 · Design paper · Scale

  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.

  Full study
• EIP 3541

  2021 · Design paper · Scale

  EIP 3541, Reject new contract code starting with the 0xEF byte. Disallow new code starting with the 0xEF byte to be deployed.

  Full study
• EIP 3607

  2021 · Design paper · Scale

  EIP 3607, Reject transactions from senders with deployed code. Ethereum addresses are currently only 160 bits long.

  Full study
• EIP 3651

  2021 · Design paper · Scale

  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.

  Full study
• EIP 3675

  2021 · Design paper · Reach consensus

  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.

  Full study
• EIP 3855

  2021 · Design paper · Data

  EIP 3855, PUSH0 instruction. Introduce the PUSH0 (0x5f) instruction, which pushes the constant value 0 onto the stack.

  Full study
• EIP 3860

  2021 · Design paper · Scale

  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).

  Full study
• EIP 4399

  2021 · Design paper · Scale

  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).

  Full study
• EIP 4736

  2022 · Design paper · Privacy

  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.

  Full study
• EIP 4788

  2022 · Design paper · Connect

  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.

  Full study
• EIP 4881

  2021 · Design paper · Reach consensus

  EIP 4881, Deposit Contract Snapshot Interface. A standard format for transmitting the deposit contract Merkle tree in a compressed form during weak subjectivity sync.

  Full study
• EIP 4895

  2022 · Design paper · Scale

  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.

  Full study
• EIP 4938

  2022 · Design paper · Data

  EIP 4938, eth/67 - Removal of GetNodeData. The Ethereum Wire Protocol defines request and response messages for exchanging data between clients.

  Full study
• EIP 5656

  2021 · Design paper · Scale

  EIP 5656, MCOPY - Memory copying instruction. Provide an efficient EVM instruction for copying memory areas.

  Full study
• EIP 5749

  2022 · Design paper · Scale

  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.

  Full study
• EIP 5792

  2022 · Design paper · Data

  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.

  Full study
• EIP 5793

  2022 · Design paper · Scale

  EIP 5793, eth/68 - Add tx type to tx announcement. The Ethereum Wire Protocol defines request and response messages for exchanging data between clients.

  Full study
• EIP 6110

  2022 · Design paper · Reach consensus

  EIP 6110, Supply validator deposits on chain. Appends validator deposits to the Execution Layer block structure.

  Full study
• EIP 6122

  2022 · Design paper · Store and connect

  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.

  Full study
• EIP 6780

  2023 · Design paper · Scale

  EIP 6780, SELFDESTRUCT only in same transaction. This EIP changes the functionality of the SELFDESTRUCT opcode.

  Full study
• EIP 6916

  2023 · Design paper · Reach consensus

  EIP 6916, Automatically Reset Testnet. A specification for an automatically reset testnet, a novel approach to testnets that can be implemented within Ethereum clients.

  Full study
• EIP 6953

  2023 · Design paper · Reach consensus

  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.

  Full study
• EIP 6963

  2023 · Design paper · Store and connect

  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.

  Full study
• EIP 7002

  2023 · Design paper · Privacy

  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.

  Full study
• EIP 7044

  2023 · Design paper · Privacy

  EIP 7044, Perpetually Valid Signed Voluntary Exits. Lock validator voluntary exit signature domain on Capella for perpetual validity.

  Full study
• EIP 7045

  2023 · Design paper · Reach consensus

  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.

  Full study
• EIP 7251

  2023 · Design paper · Scale

  EIP 7251, Increase the MAX_EFFECTIVE_BALANCE. Increases the constant MAX_EFFECTIVE_BALANCE, while keeping the minimum staking balance 32 ETH.

  Full study
• EIP 7514

  2023 · Design paper · Move value

  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.

  Full study
• EIP 7516

  2023 · Design paper · Scale

  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.

  Full study
• EIP 7549

  2023 · Design paper · Privacy

  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.

  Full study
• EIP 7594

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7623

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7642

  2024 · Design paper · Store and connect

  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.

  Full study
• EIP 7685

  2024 · Design paper · Reach consensus

  EIP 7685, General purpose execution layer requests. This proposal defines a general purpose framework for storing contract-triggered requests.

  Full study
• EIP 7691

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7823

  2024 · Design paper · Scale

  EIP 7823, Set upper bounds for MODEXP. Introduce an upper bound on the inputs of the MODEXP precompile.

  Full study
• EIP 7825

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7840

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7870

  2025 · Design paper · Reach consensus

  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.

  Full study
• EIP 7883

  2025 · Design paper · Scale

  EIP 7883, ModExp Gas Cost Increase. This EIP is modifying the ModExp precompile pricing algorithm introduced in EIP-2565.

  Full study
• EIP 7892

  2025 · Design paper · Scale

  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.

  Full study
• EIP 7910

  2025 · Design paper · Privacy

  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.

  Full study
• EIP 7917

  2025 · Design paper · Reach consensus

  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.

  Full study
• EIP 7918

  2025 · Design paper · Scale

  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().

  Full study
• EIP 7934

  2025 · Design paper · Reach consensus

  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.

  Full study
• EIP 7935

  2025 · Design paper · Data

  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.

  Full study
• EIP 7939

  2025 · Design paper · Scale

  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.

  Full study
• EIP 7951

  2025 · Design paper · Scale

  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).

  Full study
• ERC 162

  2016 · Design paper · Data

  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).

  Full study
• ERC 165

  2018 · Design paper · Privacy

  ERC 165, Standard Interface Detection. Creates a standard method to publish and detect what interfaces a smart contract implements.

  Full study
• ERC 173

  2018 · Design paper · Data

  ERC 173, Contract Ownership Standard. This specification defines standard functions for owning or controlling a contract.

  Full study
• ERC 191

  2016 · Design paper · Privacy

  ERC 191, Signed Data Standard. We propose the following format for signed_data 0x19 .

  Full study
• ERC 223

  2017 · Design paper · Scale

  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.

  Full study
• ERC 600

  2017 · Design paper · Move value

  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.

  Full study
• ERC 601

  2017 · Design paper · Privacy

  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.

  Full study
• ERC 681

  2017 · Design paper · Move value

  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.

  Full study
• ERC 777

  2017 · Design paper · Move value

  ERC 777, Token Standard. Standard interfaces and behaviors for token contracts.

  Full study
• ERC 820

  2018 · Design paper · Data

  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.

  Full study
• ERC 1046

  2018 · Design paper · Privacy

  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.

  Full study
• ERC 1167

  2018 · Design paper · Scale

  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.

  Full study
• ERC 1271

  2018 · Design paper · Privacy

  ERC 1271, Standard Signature Validation Method for Contracts. Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot.

  Full study
• ERC 1328

  2018 · Design paper · Connect

  ERC 1328, WalletConnect URI Format. This standard defines how the data to connect some application and a wallet can be encoded with a URI.

  Full study
• ERC 1363

  2018 · Design paper · Move value

  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.

  Full study
• ERC 1450

  2018 · Design paper · Privacy

  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.

  Full study
• ERC 1820

  2019 · Design paper · Data

  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.

  Full study
• ERC 1967

  2019 · Design paper · Scale

  ERC 1967, Proxy Storage Slots. Delegating proxy contracts are widely used for both upgradeability and gas savings.

  Full study
• ERC 2098

  2019 · Design paper · Scale

  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.

  Full study
• ERC 2135

  2019 · Design paper · Privacy

  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.

  Full study
• ERC 2309

  2019 · Design paper · Move value

  ERC 2309, ERC-721 Consecutive Transfer Extension. A standardized event emitted when creating/transferring one, or many non-fungible tokens using consecutive token identifiers.

  Full study
• ERC 2535

  2020 · Design paper · Data

  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.

  Full study
• ERC 2612

  2020 · Design paper · Scale

  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.

  Full study
• ERC 2678

  2020 · Design paper · Privacy

  ERC 2678, Revised Ethereum Smart Contract Packaging Standard (EthPM v3). A data format describing a smart contract software package.

  Full study
• ERC 2771

  2020 · Design paper · Scale

  ERC 2771, Secure Protocol for Native Meta Transactions. A contract-level protocol for Recipient contracts to accept meta-transactions through trusted Forwarder contracts.

  Full study
• ERC 2981

  2020 · Design paper · Move value

  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.

  Full study
• ERC 3448

  2021 · Design paper · Store and connect

  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.

  Full study
• ERC 3475

  2021 · Design paper · Scale

  ERC 3475, Abstract Storage Bonds. The creation of tokenized obligations with abstract on-chain metadata storage.

  Full study
• ERC 3525

  2020 · Design paper · Move value

  ERC 3525, Semi-Fungible Token. The set of smart contract interfaces described in this document defines an ERC-721 compatible token standard.

  Full study
• ERC 3643

  2021 · Design paper · Store and connect

  ERC 3643, T-REX - Token for Regulated EXchanges. The T-REX token is an institutional grade security token standard.

  Full study
• ERC 3668

  2020 · Design paper · Data

  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).

  Full study
• ERC 4337

  2021 · Design paper · Privacy

  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.

  Full study
• ERC 4361

  2021 · Design paper · Privacy

  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).

  Full study
• ERC 4400

  2021 · Design paper · Move value

  ERC 4400, EIP-721 Consumable Extension. This specification defines standard functions outlining a consumer role for instance(s) of EIP-721.

  Full study
• ERC 4519

  2021 · Design paper · Privacy

  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.

  Full study
• ERC 4804

  2022 · Design paper · Scale

  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....

  Full study
• ERC 4834

  2022 · Design paper · Scale

  ERC 4834, Hierarchical Domains. This is a standard for generic name resolution with arbitrarily complex access control and resolution.

  Full study
• ERC 4906

  2022 · Design paper · Privacy

  ERC 4906, EIP-721 Metadata Update Extension. Many EIP-721 contracts emit an event when one of its tokens' metadata are changed.

  Full study
• ERC 4907

  2022 · Design paper · Move value

  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).

  Full study
• ERC 4910

  2022 · Design paper · Move value

  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.

  Full study
• ERC 4955

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5006

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5007

  2022 · Design paper · Privacy

  ERC 5007, Time NFT, ERC-721 Time Extension. It proposes some additional functions (startTime, endTime) to help with on-chain time management.

  Full study
• ERC 5023

  2022 · Design paper · Move value

  ERC 5023, Shareable Non-Fungible Token. This EIP standardizes an interface for non-fungible value-holding shareable tokens.

  Full study
• ERC 5169

  2022 · Design paper · Move value

  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.

  Full study
• ERC 5192

  2022 · Design paper · Privacy

  ERC 5192, Minimal Soulbound NFTs. It proposes a minimal interface to make tokens soulbound using the feature detection functionality of EIP-165.

  Full study
• ERC 5202

  2022 · Design paper · Scale

  ERC 5202, Blueprint contract format. Define a standard for "blueprint" contracts, or contracts which represent initcode that is stored on-chain.

  Full study
• ERC 5219

  2022 · Design paper · Privacy

  ERC 5219, Contract Resource Requests. This EIP standardizes an interface to make resource requests to smart contracts and to receive HTTP-like responses.

  Full study
• ERC 5267

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5313

  2022 · Design paper · Privacy

  ERC 5313, Light Contract Ownership. This specification defines the minimum interface required to identify an account that controls a contract.

  Full study
• ERC 5375

  2022 · Design paper · Privacy

  ERC 5375, NFT Author Information and Consent. This EIP standardizes a JSON format for storing off-chain information about NFT authors.

  Full study
• ERC 5380

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5484

  2022 · Design paper · Privacy

  ERC 5484, Consensual Soulbound Tokens. An interface extending EIP-721 to create soulbound tokens.

  Full study
• ERC 5489

  2022 · Design paper · Privacy

  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”.

  Full study
• ERC 5507

  2022 · Design paper · Privacy

  ERC 5507, Refundable Tokens. Refund functionality for initial token offerings to ERC-20, ERC-721, and ERC-1155.

  Full study
• ERC 5516

  2022 · Design paper · Privacy

  ERC 5516, Soulbound Multi-owner Tokens. A standard interface for non-transferable, multi-owner Soulbound tokens.

  Full study
• ERC 5521

  2022 · Design paper · Move value

  ERC 5521, Referable NFT. It proposes two referable indicators, referring and referred, and a time-based indicator createdTimestamp.

  Full study
• ERC 5528

  2022 · Design paper · Move value

  ERC 5528, Refundable Fungible Token. This specification defines a type of escrow service with the following flow: - The seller issues tokens.

  Full study
• ERC 5564

  2022 · Design paper · Scale

  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.

  Full study
• ERC 5570

  2022 · Design paper · Privacy

  ERC 5570, Digital Receipt Non-Fungible Tokens. A standard schema for digital receipts of transactions.

  Full study
• ERC 5585

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5606

  2022 · Design paper · Move value

  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.

  Full study
• ERC 5615

  2023 · Design paper · Store and connect

  ERC 5615, ERC-1155 Supply Extension. This ERC standardizes an existing mechanism to fetch token supply data from ERC-1155 tokens.

  Full study
• ERC 5625

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5646

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5679

  2022 · Design paper · Privacy

  ERC 5679, Token Minting and Burning. A consistent way to extend token standards for minting and burning.

  Full study
• ERC 5725

  2022 · Design paper · Move value

  ERC 5725, Transferable Vesting NFT. A Non-Fungible Token (NFT) standard used to vest tokens (ERC-20 or otherwise) over a vesting release curve.

  Full study
• ERC 5732

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 5750

  2022 · Design paper · Privacy

  ERC 5750, General Extensibility for Method Behaviors. This EIP standardizes the passing of unstructured call data to functions to enable future extensibility.

  Full study
• ERC 5773

  2022 · Design paper · Move value

  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.

  Full study
• ERC 6059

  2022 · Design paper · Move value

  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.

  Full study
• ERC 6066

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 6093

  2022 · Design paper · Privacy

  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.

  Full study
• ERC 6105

  2022 · Design paper · Move value

  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.

  Full study
• ERC 6147

  2022 · Design paper · Move value

  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.

  Full study
• ERC 6150

  2022 · Design paper · Move value

  ERC 6150, Hierarchical NFTs. It proposes a multi-layer filesystem-like hierarchical NFTs.

  Full study
• ERC 6220

  2022 · Design paper · Move value

  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.

  Full study
• ERC 6239

  2022 · Design paper · Move value

  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.

  Full study
• ERC 6381

  2023 · Design paper · Privacy

  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.

  Full study
• ERC 6454

  2023 · Design paper · Move value

  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.

  Full study
• ERC 6492

  2023 · Design paper · Privacy

  ERC 6492, Signature Validation for Predeploy Contracts. Contracts can sign verifiable messages via ERC-1271.

  Full study
• ERC 6538

  2023 · Design paper · Privacy

  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.

  Full study
• ERC 6672

  2023 · Design paper · Privacy

  ERC 6672, Multi-redeemable NFTs. An extension to the ERC-721 standard for Non-Fungible Tokens (NFTs) to enable multi-redeemable NFTs.

  Full study
• ERC 6808

  2023 · Design paper · Privacy

  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).

  Full study
• ERC 6809

  2023 · Design paper · Privacy

  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).

  Full study
• ERC 6909

  2023 · Design paper · Move value

  ERC 6909, Minimal Multi-Token Interface. The following specifies a multi-token contract as a simplified alternative to the ERC-1155 Multi-Token Standard.

  Full study
• ERC 6982

  2023 · Design paper · Privacy

  ERC 6982, Efficient Default Lockable Tokens. This proposal introduces a lockable interface for ERC-721 tokens that optimizes gas usage by eliminating unnecessary events.

  Full study
• ERC 7007

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7053

  2023 · Design paper · Scale

  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.

  Full study
• ERC 7066

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7092

  2023 · Design paper · Privacy

  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.

  Full study
• ERC 7160

  2023 · Design paper · Privacy

  ERC 7160, ERC-721 Multi-Metadata Extension. An extension to the ERC-721 standard to support multiple metadata URIs per token.

  Full study
• ERC 7201

  2023 · Design paper · Data

  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.

  Full study
• ERC 7208

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7231

  2023 · Design paper · Privacy

  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).

  Full study
• ERC 7291

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7401

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7409

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7432

  2023 · Design paper · Privacy

  ERC 7432, Non-Fungible Token Roles. This standard introduces role management for NFTs.

  Full study
• ERC 7439

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7528

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7535

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7540

  2023 · Design paper · Move value

  ERC 7540, Asynchronous ERC-4626 Tokenized Vaults. The following standard extends ERC-4626 by adding support for asynchronous deposit and redemption flows.

  Full study
• ERC 7575

  2023 · Design paper · Move value

  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.

  Full study
• ERC 7578

  2023 · Design paper · Privacy

  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.

  Full study
• ERC 7588

  2024 · Design paper · Scale

  ERC 7588, Blob Transactions Metadata JSON Schema. A standard for attaching metadata to blobs carried by blob transactions, as outlined in EIP-4844.

  Full study
• ERC 7627

  2024 · Design paper · Privacy

  ERC 7627, Secure Messaging Protocol. This proposal implements the capability to securely exchange encrypted messages on-chain.

  Full study
• ERC 7631

  2024 · Design paper · Privacy

  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.

  Full study
• ERC 7634

  2024 · Design paper · Privacy

  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.

  Full study
• ERC 7656

  2024 · Design paper · Privacy

  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).

  Full study
• ERC 7734

  2024 · Design paper · Privacy

  ERC 7734, Decentralized Identity Verification (DID). This proposal introduces a standard for decentralized identity verification (DID) on the blockchain.

  Full study
• ERC 7743

  2024 · Design paper · Move value

  ERC 7743, Multi-Owner Non-Fungible Tokens (MO-NFT). A new standard for non-fungible tokens (NFTs) that supports multiple owners.

  Full study
• ERC 7751

  2024 · Design paper · Privacy

  ERC 7751, Wrapping of bubbled up reverts. A standard for handling bubbled up reverts in Ethereum smart contracts using a dedicated custom error.

  Full study
• ERC 7786

  2024 · Design paper · Connect

  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.

  Full study
• ERC 7813

  2024 · Design paper · Privacy

  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.

  Full study
• ERC 7818

  2024 · Design paper · Store and connect

  ERC 7818, Expirable ERC-20. Introduces an extension for ERC-20 tokens, which facilitates the implementation of an expiration mechanism.

  Full study
• ERC 7820

  2024 · Design paper · Data

  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.

  Full study
• ERC 7837

  2024 · Design paper · Move value

  ERC 7837, Diffusive Tokens. A standard for a new type of fungible token, called Diffusive Tokens (DIFF).

  Full study
• ERC 7857

  2025 · Design paper · Scale

  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.

  Full study
• ERC 7858

  2024 · Design paper · Move value

  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.

  Full study
• ERC 7878

  2025 · Design paper · Privacy

  ERC 7878, Bequeathable Contracts. A standard interface for contracts to allow tokens to be inherited after the owner's death.

  Full study
• ERC 7893

  2025 · Design paper · Privacy

  ERC 7893, DeFi Protocol Solvency Proof Mechanism. A standardized interface that enables DeFi protocols to implement verifiable solvency proofs through smart contracts.

  Full study
• ERC 7908

  2025 · Design paper · Scale

  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.

  Full study
• ERC 7913

  2025 · Design paper · Privacy

  ERC 7913, Signature Verifiers. Externally Owned Accounts (EOA) can sign messages with their associated private keys.

  Full study
• ERC 7943

  2025 · Design paper · Connect

  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.

  Full study
• ERC 7950

  2025 · Design paper · Data

  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.

  Full study
• ERC 7994

  2025 · Design paper · Privacy

  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.

  Full study
• ERC 8001

  2025 · Design paper · Privacy

  ERC 8001, Agent Coordination Framework. ERC-8001 defines a minimal, single-chain primitive for multi-party agent coordination.

  Full study
• ERC 8034

  2025 · Design paper · Privacy

  ERC 8034, Referable NFT Royalties. Royalty Distribution, a standalone royalty distribution for Referable Non-Fungible Tokens (rNFTs).

  Full study
• ERC 8042

  2025 · Design paper · Data

  ERC 8042, Diamond Storage. This standard formalizes the diamond storage pattern originally introduced by ERC-2535 Diamonds and widely adopted across smart contracts.

  Full study
• ERC 8063

  2025 · Design paper · Privacy

  ERC 8063, Groups - Membership Tokens. This proposal defines a "Group" as an ERC-20 token where token balance represents membership level.

  Full study
• ERC 8126

  2026 · Design paper · Move value

  ERC 8126, AI Agent Verification. A standard interface for verifying AI agents on Ethereum that have been registered via ERC-8004.

  Full study
• ERC 8161

  2025 · Design paper · Move value

  ERC 8161, Transferable Tokenized Vault Requests. This standard extends ERC-7540 by adding optional transferability of pending deposit and redeem Requests.

  Full study
• ERC 8196

  2026 · Design paper · Privacy

  ERC 8196, AI Agent Authenticated Wallet. A standard interface for AI agent-authenticated wallets.

  Full study
• BIP 46

  2022 · Design paper · Scale

  BIP 46, Address Scheme for Timelocked Fidelity Bonds. The derivation scheme for HD wallets which create timelocked addresses used for creating fidelity bonds.

  Full study
• BIP 53

  2025 · Design paper · Reach consensus

  BIP 53, Disallow 64-byte transactions. The rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.

  Full study
• BIP 93

  2023 · Design paper · Data

  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.

  Full study
• BIP 98

  2017 · Design paper · Reach consensus

  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.

  Full study
• BIP 116

  2017 · Design paper · Reach consensus

  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.

  Full study
• BIP 117

  2017 · Design paper · Reach consensus

  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.

  Full study
• BIP 118

  2017 · Design paper · Reach consensus

  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.

  Full study
• BIP 119

  2020 · Design paper · Reach consensus

  BIP 119, CHECKTEMPLATEVERIFY. A new opcode, OP_CHECKTEMPLATEVERIFY, to be activated as a change to the semantics of OP_NOP4.

  Full study
• BIP 122

  2015 · Design paper · Data

  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.

  Full study
• BIP 126

  2016 · Design paper · Data

  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.

  Full study
• BIP 128

  2026 · Design paper · Data

  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.

  Full study
• BIP 136

  2017 · Design paper · Data

  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.

  Full study
• BIP 172

  2025 · Design paper · Data

  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.

  Full study
• BIP 178

  2018 · Design paper · Store and connect

  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.

  Full study
• BIP 197

  2019 · Design paper · Connect

  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).

  Full study
• BIP 300

  2017 · Design paper · Connect

  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.

  Full study
• BIP 301

  2019 · Design paper · Reach consensus

  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").

  Full study
• BIP 310

  2018 · Design paper · Privacy

  BIP 310, Stratum protocol extensions. This BIP provides a generic mechanism for specifying stratum protocol extensions.

  Full study
• BIP 320

  2018 · Design paper · Privacy

  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.

  Full study
• BIP 323

  2026 · Design paper · Data

  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.

  Full study
• BIP 326

  2021 · Design paper · Connect

  BIP 326, Anti-fee-sniping in taproot transactions. This document proposes a certain type of wallet behaviour which uses BIP341 taproot[1].

  Full study
• BIP 329

  2022 · Design paper · Privacy

  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.

  Full study
• BIP 330

  2019 · Design paper · Store and connect

  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]).

  Full study
• BIP 331

  2022 · Design paper · Store and connect

  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.

  Full study
• BIP 360

  2024 · Design paper · Reach consensus

  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.

  Full study
• BIP 361

  2026 · Design paper · Reach consensus

  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.

  Full study
• BIP 372

  2022 · Design paper · Privacy

  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.

  Full study
• BIP 374

  2024 · Design paper · Scale

  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].

  Full study
• BIP 375

  2025 · Design paper · Privacy

  BIP 375, Sending Silent Payments with PSBTs. This document specifies new fields and new field inclusion/exclusion requirements.

  Full study
• BIP 376

  2026 · Design paper · Data

  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.

  Full study
• BIP 389

  2022 · Design paper · Privacy

  BIP 389, Multipath Descriptor Key Expressions. This document specifies a modification to Key Expressions of Descriptors that are described in BIP 380.

  Full study
• BIP 390

  2024 · Design paper · Privacy

  BIP 390, musig() Descriptor Key Expression. This document specifies a musig() key expression for output script descriptors.

  Full study
• BIP 392

  2026 · Design paper · Privacy

  BIP 392, Silent Payment Output Script Descriptors. This document specifies sp() output script descriptors for silent payments.

  Full study
• BIP 393

  2026 · Design paper · Privacy

  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]].

  Full study
• BIP 431

  2024 · Design paper · Scale

  BIP 431, Topology Restrictions for Pinning. This document describes pinning problems that can arise from limitations in mempool policy.

  Full study
• BIP 433

  2025 · Design paper · Scale

  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.

  Full study
• BIP 443

  2025 · Design paper · Reach consensus

  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 ).

  Full study
• BIP 450

  2026 · Design paper · Scale

  BIP 450, Formosa—Seed encoding by themed mnemonic stories. Formosa, an expansion of BIP-0039 for the generation of deterministic wallets.

  Full study
• EIP 2780

  2020 · Design paper · Data

  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.

  Full study
• EIP 3076

  2020 · Design paper · Privacy

  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.

  Full study
• EIP 3155

  2020 · Design paper · Scale

  EIP 3155, EVM trace specification. Introduce a new JSON standard for EVM traces during execution of state tests.

  Full study
• EIP 7495

  2023 · Design paper · Privacy

  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.

  Full study
• EIP 7523

  2023 · Design paper · Scale

  EIP 7523, Empty accounts deprecation. This EIP prohibits the state of any post-merge network from containing empty accounts.

  Full study
• EIP 7610

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7688

  2024 · Design paper · Reach consensus

  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.

  Full study
• EIP 7708

  2024 · Design paper · Scale

  EIP 7708, ETH transfers emit a log. Logs are often used to track when balance changes of assets on Ethereum.

  Full study
• EIP 7732

  2024 · Design paper · Scale

  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.

  Full study
• EIP 7778

  2024 · Design paper · Scale

  EIP 7778, Block Gas Accounting without Refunds. This EIP modifies the block gas accounting mechanism to prevent the circumvention of block gas limits.

  Full study
• EIP 7784

  2024 · Design paper · Scale

  EIP 7784, GETCONTRACT opcode. This is a proposal to add a new opcode, GETCONTRACT.

  Full study
• EIP 7834

  2024 · Design paper · Data

  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.

  Full study
• EIP 7843

  2024 · Design paper · Scale

  EIP 7843, SLOTNUM opcode. To add a new opcode SLOTNUM (0x4b), that returns the corresponding slot number for the current block.

  Full study
• EIP 7880

  2025 · Design paper · Scale

  EIP 7880, EOF - EXTCODEADDRESS instruction. Add an instruction to EOF that reads code delegation designations from an account without requiring code introspection.

  Full study
• EIP 7904

  2025 · Design paper · Scale

  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.

  Full study
• EIP 7916

  2025 · Design paper · Reach consensus

  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.

  Full study
• EIP 7928

  2025 · Design paper · Scale

  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.

  Full study
• EIP 7954

  2025 · Design paper · Data

  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.

  Full study
• EIP 7975

  2025 · Design paper · Store and connect

  EIP 7975, eth/70 - partial block receipt lists. This EIP modifies the 'eth' p2p protocol to allow requesting partial block receipt lists.

  Full study
• EIP 7976

  2025 · Design paper · Scale

  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.

  Full study
• EIP 7981

  2024 · Design paper · Scale

  EIP 7981, Increase Access List Cost. This EIP charges access lists for their data footprint, preventing the circumvention of the EIP-7623 floor pricing.

  Full study
• EIP 7997

  2025 · Design paper · Scale

  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.

  Full study
• EIP 8024

  2025 · Design paper · Scale

  EIP 8024, Backward compatible SWAPN, DUPN, EXCHANGE. Currently, SWAP and DUP instructions are limited to a stack depth of 16.

  Full study
• EIP 8037

  2025 · Design paper · Scale

  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.

  Full study
• EIP 8038

  2025 · Design paper · Scale

  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.

  Full study
• EIP 8045

  2025 · Design paper · Privacy

  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.

  Full study
• EIP 8061

  2025 · Design paper · Reach consensus

  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).

  Full study
• EIP 8066

  2024 · Design paper · Privacy

  EIP 8066, Upgrade Mascots. This EIP establishes a mascot for each Ethereum network upgrade.

  Full study
• EIP 8070

  2025 · Design paper · Scale

  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).

  Full study
• EIP 8133

  2026 · Design paper · Scale

  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.

  Full study
• EIP 8136

  2025 · Design paper · Scale

  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.

  Full study
• EIP 8159

  2026 · Design paper · Store and connect

  EIP 8159, eth/71 - Block Access List Exchange. This EIP modifies the 'eth' p2p protocol to support Block-level Access Lists (BALs).

  Full study
• EIP 8163

  2026 · Design paper · Scale

  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.

  Full study
• EIP 8182

  2026 · Design paper · Scale

  EIP 8182, Private ETH and ERC-20 Transfers. Private ETH and ERC-20 transfers via a shielded-pool system contract.

  Full study
• EIP 8189

  2026 · Design paper · Store and connect

  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.

  Full study
• EIP 8246

  2026 · Design paper · Scale

  EIP 8246, Remove SELFDESTRUCT Burn. This EIP removes the remaining cases where SELFDESTRUCT burns ETH.

  Full study
• EIP 8261

  2026 · Design paper · Reach consensus

  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.

  Full study

Bitcoin PDF · Stake and work · Every study