Protocol papers
Consensus papers.
A consensus paper answers who may extend the chain and when a result is final. It does not answer whether the later network kept the paper.
How to read this shelf
Each card opens a study. The study is a reading of a public paper, not the paper and not a description of today's network. Status is a design paper unless the record says historical or failure case.
How to read this page
Research status is named on the page. Primary sources are linked. This is a mechanism and operating note, not investment suitability, legal advice, a security guarantee or an implementation certificate.
Cardano · 2017 · Design paper
Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol
The academic protocol Cardano's settlement layer is built around. It gives a proof-of-stake chain a stated security argument in a synchronous model, with stake electing slot leaders.
Algorand · 2017 · Design paper
ALGORAND: The Efficient and Democratic Ledger
Micali's ledger design: a proof-of-stake protocol that elects a small, unpredictable committee to certify each block, and replaces participants so a corruptor cannot find them in time.
Avalanche · 2018 · Design paper
Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family
A family of consensus protocols that sample the network repeatedly and tip toward one outcome. The 2018 note was pseudonymous. A later write-up adds named co-authors. Avalanche the network is an implementation, not the sample itself.
Solana · 2018 · Design paper
Solana: A new architecture for a high performance blockchain
Yakovenko's design note for a ledger that encodes the passage of time as a verifiable hash chain, called Proof of History, so that validators spend less effort agreeing on order.
Tendermint · 2014 · Design paper
Tendermint: Consensus without Mining
A practical Byzantine-fault-tolerant state machine for a known validator set, with instant finality on commit. It became the consensus engine under Cosmos SDK chains. The 2014 note is the origin, not the current CometBFT specification.
Tezos · 2014 · Design paper
Tezos — a self-amending crypto-ledger
Goodman's proposal for a ledger whose protocol can be amended by a defined on-ledger process, with stakeholders who bake blocks and who may delegate.
Hedera · 2016 · Design paper
The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance
Baird's technical report on hashgraph: gossip about gossip, a virtual vote computed from the graph, and a fairness claim about the order of transactions. Hedera is the later public network that uses the algorithm under a governing council.
Nano · 2017 · Design paper
Nano: A Feeless Distributed Cryptocurrency Network
LeMahieu's design, first published as RaiBlocks: each account has its own chain, and the account holder is the only one who can append to it. Value moves by a send block on one chain and a receive block on another.
Zilliqa · 2017 · Design paper
The ZILLIQA Technical Whitepaper
A 2017 design for a sharded chain: a directory service that assigns nodes, shards that process transactions in parallel, and a language proposal aimed at safe-by-construction contracts.
Harmony · 2019 · Design paper
Harmony Technical Whitepaper
A sharded proof-of-stake design that combines a BFT-style consensus inside shards with a randomness scheme for assigning validators, aimed at keeping a single shard from being captured.
MultiversX · 2019 · Design paper
Elrond: A Highly Scalable Public Blockchain via Adaptive State Sharding
The 2019 Elrond paper on adaptive state sharding: shards that hold state, a metachain that notarises results, and a secure proof-of-stake selection of validators. The network later rebranded as MultiversX. The paper remains the design document.
NEAR · 2019 · Design paper
The NEAR White Paper
NEAR's public design paper: a sharded proof-of-stake chain with a single account model, nightshade-style data availability across chunks, and a stated intent that hiding the shards from application authors is part of the product.
Aptos · 2022 · Design paper
The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infrastructure
Aptos Labs' 2022 paper for a Move-based chain that pipelines dissemination, ordering, execution and certification, and that treats protocol upgrades as a first-class feature rather than a hard-fork event.
Sui · 2022 · Design paper
The Sui Smart Contracts Platform
Mysten Labs' platform paper. Assets are Move objects. Operations on objects owned by a single address can finish by consistent broadcast among validators. Shared objects go through consensus. The split is the design.
Diem · 2020 · Historical document
The Diem Blockchain
The technical paper for the Libra, later Diem, payment chain: a permissioned BFT ledger, a Move language for resources, and a reserve-backed currency proposal. The project was wound down in 2022. The paper still matters because Move, and the account model Aptos and Sui started from, was specified here.
Mina · 2020 · Design paper
Coda: Decentralized Cryptocurrency at Scale
The Coda paper, later the Mina protocol: a chain whose certificate is a constant-size succinct proof, so a client can check the state without replaying history. The project renamed from Coda to Mina. The paper keeps the original name.
TON · 2021 · Design paper
The Open Network
Durov's design for a multi-chain system of account-chains gathered into shardchains, with a masterchain that records the others. It began as Telegram's network design and continued as The Open Network after Telegram stepped away from the original launch.
Kadena · 2018 · Design paper
Chainweb: A Proof-of-Work Parallel-Chain Architecture for Massive Throughput
Kadena's public parallel-chain design. Many proof-of-work chains advance together, and each block commits to peer-chain headers, so a confirmation is a braid rather than a single chain. This is not the 2016 private-chain note already in the historic library.
EOSIO · 2018 · Design paper
EOS.IO Technical White Paper
The 2018 technical paper for EOSIO: delegated proof of stake, named block producers, and an operating-system metaphor for accounts, permissions and resource allocation. It is a design document. It is not a description of later governance fights around any one chain that used the software.
Internet Computer · 2018 · Design paper
DFINITY Consensus System
The DFINITY consensus overview: a randomness beacon, a ranking of block proposers, and notarisation so that a chain can come to agreement quickly among a large set. The Internet Computer is the later network built by the DFINITY foundation on this line of research.
PBFT · 1999 · Design paper
Practical Byzantine Fault Tolerance
The paper that made a Byzantine quorum practical: a known set of replicas, three phases, and a view change when the leader is useless. Tendermint and HotStuff inherit the shape. Open membership is a different problem.
Bitcoin-NG · 2016 · Design paper
Bitcoin-NG: A Scalable Blockchain Protocol
Separate the rare proof-of-work election from the frequent publication of transactions. Key blocks choose a leader. That leader's microblocks carry the transactions until the next key block.
GHOST · 2015 · Design paper
Secure High-Rate Transaction Processing in Bitcoin
At high block rates the longest chain throws away too much honest work. GHOST follows the heaviest subtree, so blocks off the main tip still count for the fork choice.
PHANTOM · 2018 · Design paper
PHANTOM and GHOSTDAG
A blockDAG protocol that still ends in one linear order. Honest blocks cluster. The parameter k is how wide that cluster may be. Kaspa is a later network in this line, not the paper.
SPECTRE · 2016 · Design paper
SPECTRE: A Fast and Scalable Cryptocurrency Protocol
Blocks form a DAG and vote pairwise on which of two blocks came first. In the common case that vote settles quickly. The paper does not promise a total order of every pair, which is why it is a poor fit for general contracts.
Casper FFG · 2017 · Design paper
Casper the Friendly Finality Gadget
A finality overlay. Validators cast two rounds of votes so that a chain of checkpoints becomes justified and then final. Equivocation can be slashed. The gadget does not, by itself, propose blocks.
HotStuff · 2019 · Design paper
HotStuff: BFT Consensus in the Lens of Blockchain
A three-phase BFT protocol whose communication is linear in the number of replicas, because a leader collects a threshold signature instead of everyone talking to everyone. Diem used a variant. The paper is not that network.
HoneyBadgerBFT · 2016 · Design paper
The Honey Badger of BFT Protocols
An asynchronous atomic broadcast. It does not wait for a timeout to make progress, and threshold encryption stops a leader from reading a batch and then dropping the transactions it dislikes.
Narwhal and Tusk · 2022 · Design paper
Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus
Split the mempool from the consensus. Narwhal is a DAG of certified batches. Tusk picks a leader inside that DAG. Later Sui consensus descends from this split. The paper is not a Sui status report.
Snow White · 2017 · Design paper
Snow White: Robustly Reconfigurable Consensus
A proof-of-stake design in the sleepy model: honest nodes may be offline, and the set of stakeholders can change. It is an academic predecessor, not Cardano and not Ethereum.
Thunderella · 2017 · Design paper
Thunderella: Blockchains with Optimistic Instant Confirmation
A fast path and a slow path. If a large supermajority is honest and an accelerator proposes quickly, transactions confirm at network speed. If not, the protocol falls back to an underlying chain.
Proofs of space · 2015 · Design paper
Proofs of Space
A proof that a machine reserved storage, not that it burned energy on a puzzle. The verifier checks a small challenge. Chia is a later system that pairs this idea with a verifiable delay. The paper is not Chia.
Verifiable delay functions · 2018 · Design paper
Verifiable Delay Functions
A function that forces a wait. Evaluating it takes a set number of sequential steps. Checking the result is quick, and the output is unique. Parallel machines do not make the wait much shorter.
Gasper · 2020 · Design paper
Combining GHOST and Casper
An idealised proof-of-stake protocol that pairs a GHOST-style fork choice with Casper FFG finality. The paper is the design argument for Ethereum's beacon chain, not a status report on a later client or a later outage.
Prism · 2019 · Design paper
Deconstructing the Blockchain to Approach Physical Limits
Bitcoin uses one chain for three jobs: proposing transactions, voting on history, and ordering the result. Prism splits those jobs onto separate block trees so throughput can approach network capacity while confirmation tracks propagation delay.
Streamlet · 2020 · Design paper
Streamlet: Textbook Streamlined Blockchains
A deliberately small consensus protocol: epochs, a leader, a vote, and a rule that three adjacent certified blocks on the same chain become final. The point is to show how little machinery the last few years of BFT designs actually need.
FruitChains · 2016 · Design paper
FruitChains: A Fair Blockchain
Nakamoto consensus can pay a minority coalition more than its share of hash power, which is the selfish-mining observation. FruitChains records transactions in 'fruit' that hang off the chain, and pays out over a window so honest hash power gets roughly honest rewards.
DAG-Rider · 2021 · Design paper
All You Need is DAG
Replicas reliably broadcast proposals into a round-structured DAG. Once the DAG is local, each replica can read a total order off it without another round of consensus messages. The paper is the asynchronous, optimally resilient version of that idea.
Bullshark · 2022 · Design paper
Bullshark: DAG BFT Protocols Made Practical
DAG-Rider is built for asynchrony and pays for it on the common path. Bullshark keeps a DAG and a local commit rule, but adds a fast path for when the network is timely. The paper also writes down a simpler partially synchronous version.
Ouroboros Genesis · 2018 · Design paper
Ouroboros Genesis: Composable Proof-of-Stake Blockchains with Dynamic Availability
Genesis gives a way to join late, when honest stake may be dynamic, without a checkpoint the protocol itself cannot justify.
Stake bleeding · 2018 · Design paper
Stake-Bleeding Attacks on Proof-of-Stake Blockchains
The paper shows a long-range style attack in which past stake keeps producing an alternative history unless the protocol makes that history obviously stale.
Bitcoin in asynchronous networks · 2017 · Design paper
Analysis of the Blockchain Protocol in Asynchronous Networks
The paper analyses Nakamoto consensus when the delay bound is not a clean round, and states how confirmation has to grow with that delay.
Stubborn mining · 2016 · Design paper
Stubborn Mining: Generalizing Selfish Mining and Combining with an Eclipse Attack
The paper generalises the withholding strategies and shows they compose with an eclipse attack that starves a node of honest blocks.
Proof-of-work security · 2016 · Design paper
On the Security and Performance of Proof of Work Blockchains
The paper builds a quantitative model of stale blocks, double-spends and selfish mining across proof-of-work parameters.
Dumbo · 2020 · Design paper
Dumbo: Faster Asynchronous BFT Protocols
Dumbo reduces the cost of the asynchronous path by improving the reliable broadcast and the binary agreement that HoneyBadger-style protocols stack together.
Bitcoin SoK · 2015 · Design paper
Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
This systematisation names the stability and consensus questions, the client problems, and the open research problems as of its date. It is a map, not a new protocol.
SpaceMint · 2015 · Design paper
SpaceMint: A Cryptocurrency Based on Proofs of Space
SpaceMint elects a leader from plots of stored data. The quality of the stored answer, not a hash grind at block time, decides who may extend the chain.
Bitcoin as a ledger · 2017 · Design paper
Bitcoin as a Transaction Ledger: A Composable Treatment
The paper gives a composable ledger functionality and shows that a bitcoin-like protocol realises it under stated assumptions.
Shoal · 2024 · Design paper
Shoal: Improving DAG-BFT Latency and Robustness
Shoal pipelines the DAG so a block can commit faster in the good case, and it uses a reputation idea so slow leaders stop dominating the schedule.
Mysticeti · 2023 · Design paper
Mysticeti: Reaching the Limits of Latency with Uncertified DAGs
Mysticeti commits from an uncertified DAG: blocks are signed by their authors and the commit rule does not require a certificate first.
Cordial Miners · 2023 · Design paper
Cordial Miners: Fast and Efficient Consensus for Every Eventuality
Cordial Miners build a DAG with a simple cordial rule for including other miners' blocks, aiming at responsiveness without the certificate tax of the earlier DAG BFTs.
Hashcash · 2002 · Design paper
Hashcash: A Denial of Service Counter-Measure
The client finds a partial hash collision. The server checks it cheaply. The stamp is the cost.
Lamport clocks · 1978 · Design paper
Time, Clocks, and the Ordering of Events in a Distributed System
Lamport clocks number events so that if A happened before B, A's number is smaller. The converse is not true. That one direction is the whole idea.
Bitcoin · 2008 · Design paper
Bitcoin: A Peer-to-Peer Electronic Cash System
Publish every spend to a peer network. Let proof-of-work order the history. The longest chain of work is the ledger honest nodes extend. The first spend of a coin in that chain is the one that counts.
Paxos · 1998 · Design paper
The Part-Time Parliament
A value is chosen only when a majority has accepted it in some ballot, and every higher ballot must honour a value that majority might already have chosen.
Paxos Made Simple · 2001 · Design paper
Paxos Made Simple
The same two-phase majority protocol, written as pseudocode: prepare, accept, and learn.
Raft · 2014 · Design paper
In Search of an Understandable Consensus Algorithm
A strong leader accepts entries, replicates them in order, and commits only when a majority of the current term has stored them.
Byzantine Generals · 1982 · Design paper
The Byzantine Generals Problem
With oral messages, more than two thirds must be loyal. With signed messages, any number of traitors can be tolerated if a loyal commander is heard.
Partial Synchrony · 1988 · Design paper
Consensus in the Presence of Partial Synchrony
Safety can hold with no timing assumption. Liveness can wait for a period, after some unknown instant, when messages arrive within a bound.
FLP · 1985 · Design paper
Impossibility of Distributed Consensus with One Faulty Process
No deterministic protocol does all three. Any protocol that is always safe has an execution that never decides.
Bitcoin Backbone · 2015 · Design paper
The Bitcoin Backbone Protocol
Common prefix, chain quality and chain growth, under a synchronous network and an honest majority of hash power.
Sleepy Consensus · 2017 · Design paper
The Sleepy Model of Consensus
Only awake nodes participate. A public randomness beacon picks a leader from the awake stake. Sleeping nodes do not have to be online to keep their stake safe.
Ouroboros Praos · 2018 · Design paper
Ouroboros Praos: An Adaptively-Secure, Semi-synchronous Proof-of-Stake Protocol
Praos hides who the slot leader is until they speak, and it tolerates a semi-synchronous delay, so an adaptive adversary cannot target the leader in advance.
Selfish Mining · 2014 · Design paper
Majority Is Not Enough: Bitcoin Mining Is Vulnerable
A miner who withholds blocks and releases them to waste honest work can earn more than their share, even below 50 percent, under the paper's propagation assumptions.
Eclipse Attacks · 2015 · Design paper
Eclipse Attacks on Bitcoin's Peer-to-Peer Network
Fill a node's peer table with attacker addresses so every connection the node opens lands on the attacker. The node can then be fed a private view of blocks and transactions.
Flexible Paxos · 2016 · Design paper
Flexible Paxos: Quorum Intersection Revisited
Only quorums from different phases have to intersect. A phase-1 quorum and a phase-2 quorum must overlap. Two phase-2 quorums need not.
EPaxos · 2013 · Design paper
There Is More Consensus in Egalitarian Parliaments
Any replica can propose. Commands that do not conflict commit in one round. Commands that conflict take a second round that records the dependency.
Conflux · 2018 · Design paper
Scaling Nakamoto Consensus to Thousands of Transactions per Second
Keep every block in a directed acyclic graph. A pivot chain picks a total order. Honest blocks that lost the race still contribute security and transactions.
Jolteon and Ditto · 2022 · Design paper
Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback
Jolteon takes two rounds in the happy path. Ditto keeps that path and falls back to an asynchronous protocol when the network or the leader misbehaves.
SBFT · 2019 · Design paper
SBFT: A Scalable and Decentralized Trust Infrastructure for Blockchains
Collectors aggregate signatures into one proof. A client and the replicas see a constant number of messages rather than a quadratic flood, under the paper's collector assumption.
Zyzzyva · 2007 · Design paper
Zyzzyva: Speculative Byzantine Fault Tolerance
Replicas execute the leader's request speculatively and reply. If every replica agrees, the client is done. A disagreement starts a slower path that looks more like PBFT.
Weak Subjectivity · 2014 · Design paper
Proof of Stake: How I Learned to Love Weak Subjectivity
A node that has been offline longer than a known window must take a recent checkpoint from a source it already trusts. Inside the window, the protocol can defend itself.
Raft membership · 2014 · Design paper
Consensus: Bridging Theory and Practice
Membership changes one server at a time, or through joint consensus, so there is never a moment when two disjoint majorities can both commit.
Bitcoin network · 2013 · Design paper
Information Propagation in the Bitcoin Network
Measure how Bitcoin announcements travel. The median time and the long tail are what set a safe block interval.
Verifier's dilemma · 2015 · Design paper
Demystifying Incentives in the Consensus Computer
If checking a block is expensive and the chance it is invalid is small, the equilibrium is not to check. The paper names that gap the verifier's dilemma.
Merged mining · 2017 · Design paper
Merged Mining: Curse or Cure?
Merged mining lets the same proof of work stamp a child chain. Security is not transferred for free: the parent miners may not validate the child, and an attack on the child can be cheap in attention even when hash power is large.
Nothing at stake · 2016 · Design paper
Cryptocurrencies without Proof of Work
The paper studies stake-based chain selection and the cost of signing every fork. It is one of the early formal attempts to replace work with a scarce key.
BIP 16 · 2012 · Design paper
Pay to Script Hash
BIP 16, Pay to Script Hash. A new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions.
BIP 18 · 2012 · Design paper
hashScriptCheck
BIP 18, hashScriptCheck. This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck.
BIP 30 · 2012 · Design paper
Duplicate transactions
BIP 30, Duplicate transactions. This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them.
BIP 34 · 2012 · Design paper
Block v2, Height in Coinbase
BIP 34, Block v2, Height in Coinbase. Bitcoin blocks and transactions are versioned binary structures.
BIP 42 · 2014 · Design paper
A finite monetary supply for Bitcoin
BIP 42, A finite monetary supply for Bitcoin. Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever.
BIP 65 · 2014 · Design paper
OP_CHECKLOCKTIMEVERIFY
BIP 65, OP_CHECKLOCKTIMEVERIFY. A new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future.
BIP 66 · 2015 · Design paper
Strict DER signatures
BIP 66, Strict DER signatures. This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.
BIP 91 · 2017 · Design paper
Reduced threshold Segwit MASF
BIP 91, Reduced threshold Segwit MASF. This document specifies a method to activate the existing BIP9 segwit deployment with a majority hashpower less than 95%.
BIP 94 · 2024 · Design paper
Testnet 4
BIP 94, Testnet 4. A new test network with the goal to replace Testnet 3.
BIP 112 · 2015 · Design paper
CHECKSEQUENCEVERIFY
BIP 112, CHECKSEQUENCEVERIFY. A new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system that in combination with BIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.
BIP 113 · 2015 · Design paper
Median time-past as endpoint for lock-time calculations
BIP 113, Median time-past as endpoint for lock-time calculations. This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block.
BIP 143 · 2016 · Design paper
Transaction Signature Verification for Version 0 Witness Program
BIP 143, Transaction Signature Verification for Version 0 Witness Program. This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.
BIP 147 · 2016 · Design paper
Dealing with dummy stack element malleability
BIP 147, Dealing with dummy stack element malleability. This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY .
BIP 148 · 2017 · Design paper
Mandatory activation of segwit deployment
BIP 148, Mandatory activation of segwit deployment. This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
BIP 342 · 2020 · Design paper
Validation of Taproot Scripts
BIP 342, Validation of Taproot Scripts. The rules below only apply when validating a transaction input for which all of the conditions below are true: The transaction input is a '''segregated witness spend''' (i.e., the scriptPubKey contains a witness program as defined in [[bip-0141.mediawiki|BIP141]]).
EIP 2982 · 2020 · Design paper
Serenity Phase 0
EIP 2982, Serenity Phase 0. Phase 0 of Serenity (eth2), a multi-phased upgrade to the consensus mechanism for Ethereum mainnet.
EIP 3675 · 2021 · Design paper
Upgrade consensus to Proof-of-Stake
EIP 3675, Upgrade consensus to Proof-of-Stake. This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain.
EIP 4881 · 2021 · Design paper
Deposit Contract Snapshot Interface
EIP 4881, Deposit Contract Snapshot Interface. A standard format for transmitting the deposit contract Merkle tree in a compressed form during weak subjectivity sync.
EIP 6110 · 2022 · Design paper
Supply validator deposits on chain
EIP 6110, Supply validator deposits on chain. Appends validator deposits to the Execution Layer block structure.
EIP 6916 · 2023 · Design paper
Automatically Reset Testnet
EIP 6916, Automatically Reset Testnet. A specification for an automatically reset testnet, a novel approach to testnets that can be implemented within Ethereum clients.
EIP 6953 · 2023 · Design paper
Network Upgrade Activation Triggers
EIP 6953, Network Upgrade Activation Triggers. This EIP outlines the various network upgrade activation triggers used on Ethereum over time, from the proof-of-work era to the first post-merge network upgrade, Shanghai/Capella, across both the execution and consensus layers.
EIP 7045 · 2023 · Design paper
Increase max attestation inclusion slot
EIP 7045, Increase max attestation inclusion slot. Increases max attestation inclusion slot from attestation.slot + SLOTS_PER_EPOCH to the last slot of epoch N+1 where N is the epoch containing the attestation slot.
EIP 7685 · 2024 · Design paper
General purpose execution layer requests
EIP 7685, General purpose execution layer requests. This proposal defines a general purpose framework for storing contract-triggered requests.
EIP 7870 · 2025 · Design paper
Hardware and Bandwidth Recommendations
EIP 7870, Hardware and Bandwidth Recommendations. This proposal specifies hardware and bandwidth recommendations for different types of Ethereum nodes: - Full nodes: Nodes that follow the tip of the chain without necessarily proposing blocks.
EIP 7917 · 2025 · Design paper
Deterministic proposer lookahead
EIP 7917, Deterministic proposer lookahead. At the start of each epoch, pre-calculate and store in the beacon_state a deterministic proposer_lookahead for the next MIN_SEED_LOOKAHEAD + 1 epochs.
EIP 7934 · 2025 · Design paper
RLP Execution Block Size Limit
EIP 7934, RLP Execution Block Size Limit. This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MiB), which includes a margin of 2 MiB to account for beacon block sizes.
BIP 53 · 2025 · Design paper
Disallow 64-byte transactions
BIP 53, Disallow 64-byte transactions. The rationale for disallowing transactions that are serialized to 64 bytes without the transaction's witness.
BIP 98 · 2017 · Design paper
Fast Merkle Trees
BIP 98, Fast Merkle Trees. In many applications it is useful to prove membership of a data element in a set without having to reveal the entire contents of that set.
BIP 116 · 2017 · Design paper
MERKLEBRANCHVERIFY
BIP 116, MERKLEBRANCHVERIFY. A general approach to bitcoin contracts is to fully enumerate the possible spending conditions and then program verification of these conditions into a single script.
BIP 117 · 2017 · Design paper
Tail Call Execution Semantics
BIP 117, Tail Call Execution Semantics. BIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] provide mechanisms by which script policy can be revealed at spend time as part of the execution witness.
BIP 118 · 2017 · Design paper
SIGHASH_ANYPREVOUT for Taproot Scripts
BIP 118, SIGHASH_ANYPREVOUT for Taproot Scripts. This BIP modifies the behaviour of the [[bip-0342.mediawiki|BIP 342]] signature opcodes '''What about key path spends?''' This proposal only supports ANYPREVOUT signatures via script path spends, and does not support ANYPREVOUT signatures for key path spends.
BIP 119 · 2020 · Design paper
CHECKTEMPLATEVERIFY
BIP 119, CHECKTEMPLATEVERIFY. A new opcode, OP_CHECKTEMPLATEVERIFY, to be activated as a change to the semantics of OP_NOP4.
BIP 301 · 2019 · Design paper
Blind Merged Mining (Consensus layer)
BIP 301, Blind Merged Mining (Consensus layer). Blind Merged Mining (BMM) allows SHA-256d miners to collect transaction fee revenue from other blockchains, without running any new software (i.e., without "looking" at those alt-chains, hence "blind").
BIP 360 · 2024 · Design paper
Pay-to-Merkle-Root (P2MR)
BIP 360, Pay-to-Merkle-Root (P2MR). We define the Pay-to-Merkle-Root (P2MR) output structure as follows: A P2MR output is similar to a P2TR output (as defined in [[bip-0341.mediawiki|BIP 341]]); however, unlike P2TR outputs, we disable the key path spend for the benefit of quantum resistance by omitting the internal key and the tap tweak step.
BIP 361 · 2026 · Design paper
Post Quantum Migration and Legacy Signature Sunset
BIP 361, Post Quantum Migration and Legacy Signature Sunset. {| class="wikitable" |- style="text-align:center;" ! Phase ! What Happens ! Who Must Act ! Time Horizon |- | A | Permitted sends are from legacy scripts to PQ scripts.
BIP 443 · 2025 · Design paper
OP_CHECKCONTRACTVERIFY
BIP 443, OP_CHECKCONTRACTVERIFY. To add consensus support for a new tapscript opcode that enables a new type of output restrictions: OP_CHECKCONTRACTVERIFY ( OP_CCV ).
EIP 7688 · 2024 · Design paper
Forward compatible consensus data structures
EIP 7688, Forward compatible consensus data structures. The changes needed to adopt ProgressiveContainer from EIP-7495 and ProgressiveList from EIP-7916 in consensus data structures.
EIP 7916 · 2025 · Design paper
SSZ ProgressiveList
EIP 7916, SSZ ProgressiveList. A new Merkle tree shape for Simple Serialize (SSZ) types that results in fewer hashes when only a small number of leaves is used.
EIP 8061 · 2025 · Design paper
Increase exit and consolidation churn
EIP 8061, Increase exit and consolidation churn. This EIP roughly doubles the consolidation churn, as well as quadrupling the exit churn and restoring its proportionality to total stake (though maintaining the existing cap on activations).
EIP 8261 · 2026 · Design paper
Gas Limit Schedule
EIP 8261, Gas Limit Schedule. This EIP recommends that, starting with Gloas (EIP-7732), consensus layer clients source their gas limit preference from an optional GAS_LIMIT_SCHEDULE field in the consensus layer config.yaml instead of hardcoded, release-scoped defaults.