Who Controls Bitcoin? Inside Bitcoin Core's Decentralized Governance Model

Bitcoin has no CEO, no board of directors, and no foundation with the authority to make protocol decisions. There is no roadmap, no quarterly earnings call, no company behind it. Yet Bitcoin's software gets updated, bugs get fixed, and new features get deployed. The question of who controls Bitcoin is one of the most misunderstood aspects of the protocol, and understanding the answer matters for anyone building on or holding Bitcoin.

The governance model that emerged over Bitcoin's 17 years is unlike anything in traditional software development or corporate governance. It is deliberately slow, adversarial by design, and optimized for one thing above all else: not breaking what already works. This article explains how that model functions in practice, who the key participants are, and what historical episodes reveal about the system's real power dynamics.

What Is Bitcoin Core?

Bitcoin Core is the reference implementation of the Bitcoin protocol. It is an open-source software project hosted on GitHub under the bitcoin/bitcoin repository. While alternative implementations exist (such as btcd written in Go or Bitcoin Knots maintained by Luke Dashjr), Bitcoin Core is run by the overwhelming majority of full nodes on the network, making it the de facto standard.

Crucially, Bitcoin Core is not Bitcoin. It is one implementation of the Bitcoin protocol rules. If Bitcoin Core developers merged a change that the network disagreed with, node operators could simply refuse to upgrade, and the change would have no effect. This distinction is the foundation of Bitcoin's governance model: developers propose, but the network decides.

How Changes Happen: The BIP Process

Proposed changes to the Bitcoin protocol follow the Bitcoin Improvement Proposal (BIP) process, modeled on Python Enhancement Proposals. There are three types of BIPs: Standards Track (protocol and implementation changes), Informational (design guidelines), and Process (governance procedures).

The Lifecycle of a BIP

1. An author posts an idea to the bitcoindev mailing list for initial feedback
2. If the idea survives initial scrutiny, a formatted draft is submitted as a pull request to the bitcoin/bips repository
3. A BIP editor reviews for formatting only (not technical merit) and assigns a number
4. The broader community reviews via mailing lists, forums, and developer meetings
5. Iterative revision continues until rough consensus emerges
6. If the BIP requires code changes, an implementation is developed, tested, and submitted to Bitcoin Core
7. For consensus-layer changes, the community selects an activation mechanism (miner signaling, user-activated soft fork, or other methods)

No formal voting: At no point in this process does anyone cast a vote. There is no quorum, no parliamentary procedure, no binding resolution. Consensus is "rough" and social. A proposal moves forward when there are no remaining substantive objections, not when a majority raises their hand.

The BIP process is intentionally conservative. Many proposals spend years in discussion before any code is written. Others are abandoned after encountering objections that the author cannot resolve. The bar for changing Bitcoin's consensus rules is extraordinarily high, and that is by design.

The Roles: Contributors, Reviewers, and Maintainers

Bitcoin Core development involves three distinct roles with very different levels of influence. Understanding these roles is essential to understanding who actually controls the software.

Contributors

Anyone can submit a pull request to the Bitcoin Core repository. In 2024, 256 unique authors had pull requests merged, with 170 first-time contributors submitting code. By 2025, over 135 developers contributed code, a 35% increase from the prior year. Contributing code is open and permissionless, but getting code merged is another matter entirely.

Reviewers

Code review is the critical bottleneck in Bitcoin Core development, and it is the most important role in the entire system. Every pull request requires review from multiple experienced developers before it can be considered for merging. Reviewers signal their assessment using a standardized vocabulary:

• ACK (Acknowledged): the reviewer approves the change
• NACK (Not Acknowledged): the reviewer objects to the change
• Concept ACK: the reviewer agrees with the goal but has not reviewed the code in detail
• utACK (Untested ACK): reviewed but not tested

In 2024, only 49 developers qualified as "regular reviewers" (those leaving 100 or more review comments), according to the CoreDev 2024 retrospective survey. Review bottleneck was the number one frustration cited by survey respondents. Pull requests can wait weeks or months for adequate review, particularly for complex consensus changes.

The power of NACK: Any reviewer can effectively block a change by raising a substantive technical objection. A single well-reasoned NACK carries more weight than a dozen casual ACKs. This asymmetry is deliberate: it is much easier to break Bitcoin than to improve it, so the system privileges caution over speed.

Maintainers

Maintainers are the developers with commit access: the ability to merge pull requests into the main branch. This is the most visible form of authority in Bitcoin Core, and also the most misunderstood. Maintainers do not decide what gets merged based on personal preference. Their role is to judge whether a pull request has achieved sufficient review and rough consensus, then press the merge button.

The "lead maintainer" role no longer exists as a single position. Wladimir van der Laan held that role for eight years before stepping down in August 2022, deliberately naming no successor. He stated his hope that the departure would push Bitcoin development toward further decentralization.

As of early 2026, six developers hold trusted maintainer keys:

TheCharlatan's appointment in January 2026 was the first expansion of the maintainer set in over three years, backed by more than 20 existing Core contributors. Michael Ford (fanquake) has been the most active maintainer in practice, handling roughly 60% of all merged pull requests in 2025 and leading every release from v28.1 through v30.0.

Rough Consensus: How Decisions Actually Get Made

Bitcoin Core uses a decision-making model borrowed from the Internet Engineering Task Force (IETF): rough consensus. This does not mean majority rule. It means that a proposal is considered to have consensus when there are no remaining unaddressed objections from technically competent participants.

In practice, this works as follows: a proposal is discussed, objections are raised, the author addresses them or explains why they are not valid, and the process repeats until either the objections are resolved or the proposal is abandoned. There is no deadline, no vote count, and no appeals process. The maintainer who ultimately merges (or declines to merge) a change exercises judgment about whether rough consensus has been achieved.

This model has a critical implication: nobody can unilaterally push a change through. Even if a maintainer personally supports a proposal, they cannot merge it over substantive objections. And even if all maintainers agree, node operators can refuse to run the new version. Power is distributed across every layer of the system.

The Block Size War: Governance Under Pressure

The most dramatic test of Bitcoin's governance model was the block size war of 2015 to 2017. The dispute centered on a seemingly simple question: should Bitcoin's 1 MB block size limit be increased via a hard fork to accommodate more transactions per block?

The Competing Proposals

Multiple proposals attempted to increase the block size directly. BIP 101, implemented in Bitcoin XT by Mike Hearn and Gavin Andresen, proposed raising the limit to 8 MB in August 2015. Bitcoin Unlimited, launched in early 2016, proposed letting miners and nodes set their own block size limits. Both gained significant miner support but never achieved activation thresholds.

On the other side, Bitcoin Core developers led by Pieter Wuille and Gregory Maxwell proposed SegWit (Segregated Witness) in December 2015: a soft fork that separated signature data from transaction data, effectively increasing block capacity without changing the block size limit. This approach avoided a hard fork, which would have required every node to upgrade or be left behind.

The New York Agreement

In May 2017, over 50 Bitcoin companies signed the New York Agreement (NYA), proposing a compromise: activate SegWit first, then execute a 2 MB block size hard fork (known as SegWit2x) a few months later. This was an attempt by businesses and miners to override Bitcoin Core's development process through industry consensus.

SegWit activated in August 2017, but on November 8, 2017, the SegWit2x developers announced the planned hard fork was canceled due to insufficient community support. The business-driven governance attempt had failed. Bitcoin Cash forked away on August 1, 2017, creating a separate chain for those who wanted larger blocks.

Lesson from the block size war: Companies, miners, and even prominent developers could not override the preferences of node operators and the Core development process. The network's governance is not determined by hashrate, economic weight, or social influence alone. No single constituency can force a change.

SegWit Activation: Users vs. Miners

The activation of SegWit in 2017 demonstrated another dimension of Bitcoin's governance: the tension between miners and users. BIP 141 (the SegWit proposal) required 95% miner signaling to activate, but miner support stalled around 30 to 45% for months.

In response, BIP 148 introduced the concept of a User-Activated Soft Fork (UASF): nodes running BIP 148 software would reject any block not signaling SegWit support after August 1, 2017. This created credible economic pressure on miners. If enough economic nodes (exchanges, wallets, merchants) ran BIP 148, blocks that did not signal for SegWit would be considered invalid by a significant portion of the network.

BIP 91, a compromise requiring only 80% miner signaling (down from 95%), locked in on July 23, 2017, making the August 1 UASF deadline effectively unnecessary. SegWit activated on August 24, 2017. The episode proved that users, not just miners, have real power in Bitcoin's governance through their choice of which software to run.

Taproot: A Smoother Upgrade

The activation of Taproot in 2021 showed a governance system that had learned from the SegWit experience. The upgrade comprised three BIPs: BIP 340 (Schnorr signatures), BIP 341 (Taproot spending rules), and BIP 342 (Tapscript), all authored by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns.

Technical consensus on Taproot was broad. The contentious question was not whether to activate it, but how. After extended debate, the community settled on Speedy Trial: a mechanism using BIP 8 with a shorter signaling window. It required 90% miner signaling within any 2,016-block period, with a deployment window from April to August 2021.

Miners crossed the 90% threshold in June 2021, locking in activation at block 709,632 in mid-November 2021. The smoother process reflected incremental improvements in governance norms, though the debate over the activation method itself consumed months of developer attention.

The Covenant Debates: Governance in Real Time

As of mid-2026, Bitcoin's governance system faces its most complex challenge since the block size war: the covenant debates. Multiple proposals for adding new opcodes to Bitcoin Script are competing for community consensus, each with different technical properties and philosophical implications.

The Leading Proposals

The covenant debate reveals Bitcoin governance at its most complex. Multiple technically sound proposals compete, each with different tradeoffs. OP_CTV is narrow and conservative but limited in scope. OP_CAT is more powerful but raises concerns about recursive covenants and fungibility. LNHANCE tries to find a pragmatic middle ground by bundling opcodes that directly benefit Lightning and other Layer 2 protocols. The technical arguments are largely settled; the harder question is the activation methodology itself, which is expected to be more contentious than any technical disagreement.

The OP_RETURN Controversy: A Recent Test Case

In 2025, Bitcoin Core faced its most divisive governance moment since the block size war. Bitcoin Core developers proposed removing the 80-byte OP_RETURN relay limit, effectively raising the default to allow near-block-size data in OP_RETURN outputs.

The rationale was pragmatic: users were already bypassing the limit using Taproot witness data (as the Ordinals and inscriptions phenomenon demonstrated), causing UTXO bloat because data stored in fake UTXOs is worse for the network than data stored in provably unspendable OP_RETURN outputs. The limit was not preventing data storage; it was just making it messier.

Opponents, led by Luke Dashjr, argued the change amounted to endorsing "spam" on the Bitcoin blockchain. Bitcoin Core v30 shipped in late 2025 with the expanded OP_RETURN default. The aftermath was notable: Bitcoin Knots (Dashjr's alternative implementation maintaining stricter limits) saw its node share surge from roughly 2% to an estimated 14 to 20% of the network, while Bitcoin Core's share declined accordingly.

This episode demonstrated a healthy governance dynamic: when users disagreed with a Bitcoin Core decision, they migrated to an alternative implementation. No single implementation controls the network. The protocol's rules are enforced by the software that node operators choose to run.

Power Dynamics: Who Can Block and Who Can Push

Bitcoin's governance distributes power across multiple constituencies, none of which can act unilaterally.

Who Can Block Changes

• Any reviewer can effectively stall a proposal by raising substantive objections that must be addressed
• Maintainers can decline to merge code, even if it has reviewer support
• Miners can refuse to signal for a soft fork activation, as they did initially with SegWit
• Node operators can refuse to upgrade, rendering any merged change irrelevant to the network

Who Can Push Changes Through

Nobody, unilaterally. Not the maintainers. Not the miners. Not any company or foundation. Changes require a rough alignment across contributors, reviewers, maintainers, miners, and node operators. The block size war proved that even a coalition of the largest Bitcoin businesses and mining pools could not force a change the rest of the ecosystem rejected.

Bitcoin vs. Ethereum Governance

Comparing Bitcoin's governance to Ethereum's highlights just how unusual the Bitcoin model is.

Ethereum's model is not inherently worse; it serves a different purpose. Ethereum was designed to support smart contracts and decentralized applications, making its governance more accommodating of protocol changes. Bitcoin's primary function as a monetary base layer pushes governance toward extreme conservatism. The Ethereum Foundation provides funding, coordinates research, and hosts the All Core Devs calls that serve as Ethereum's primary governance venue. Bitcoin has no equivalent organization.

The tradeoff is speed versus stability. Ethereum can ship features like proto-danksharding (EIP-4844) or the merge to proof of stake in a matter of years. Bitcoin's covenant proposals have been debated since 2019 with no activation date in sight. Whether this is too conservative or appropriately cautious depends on what you think Bitcoin is for.

Is Bitcoin Governance Too Conservative?

Critics argue that Bitcoin's governance has become ossified. Covenant proposals that could enable vaults, better Layer 2 protocols, and more expressive scripting have been in discussion for years. The review bottleneck means that even non-controversial improvements can take months to merge. Some developers have left the project citing frustration with the pace.

Defenders argue that conservatism is the entire point. Bitcoin secures hundreds of billions of dollars in value. A consensus bug that allows double-spending or inflation would be catastrophic. The slow pace of change is not a bug but rather the core feature of a system designed to be a predictable, reliable monetary base. Every soft fork that adds complexity to Bitcoin Script also adds attack surface that can never be removed.

The 2024 CoreDev retrospective survey captured this tension: contributor satisfaction scored 3.54 out of 5, while project happiness scored 3.92 out of 5. Developers are generally positive about the project's direction but frustrated by the mechanics of getting work done within the current process.

What This Means for Layer 2 Developers

Bitcoin's conservative governance is simultaneously a constraint and a guarantee for Layer 2 protocols. Changes to the base layer are slow but predictable, giving L2 developers a stable foundation to build upon.

Protocols like Spark are designed around the current capabilities of Bitcoin's base layer. Spark uses Schnorr signatures and Taproot (features that took years to activate) as building blocks for its statechain-based architecture. The stability guarantee is real: once a feature activates on Bitcoin L1 via soft fork, it will not be removed. L2 developers can build on these primitives with confidence that the ground beneath them will not shift.

At the same time, the governance model means that L2 protocols cannot depend on future base-layer changes. Covenants would unlock more efficient vault designs, channel factories, and other constructions, but no L2 project can responsibly build around opcodes that may never activate. This forces Layer 2 developers to innovate within existing constraints, which has historically produced creative solutions like Lightning payment channels, HTLCs, and statechain transfers.

Building on Bitcoin Today

For developers interested in building on Bitcoin's stable foundation, the Spark SDK documentation provides a practical starting point. Spark abstracts the complexity of L1 interactions while preserving self-custody, letting developers focus on application logic rather than protocol mechanics. For a deeper comparison of how different Layer 2 protocols navigate Bitcoin's base-layer constraints, see Bitcoin L2 Trust Model Comparison.

Conclusion

Bitcoin's governance model has no parallel in technology or finance. It has no leader, no foundation, no roadmap, and no formal voting. Changes require rough consensus across a distributed set of contributors, reviewers, maintainers, miners, and node operators. The system is deliberately adversarial: it is designed to make change difficult, because the cost of a bad change to a monetary network is far higher than the cost of moving slowly.

The block size war proved that economic majorities cannot override the network. SegWit activation proved that users, not just miners, have real governance power. Taproot showed the system can still evolve, albeit slowly. The ongoing covenant debates will test whether the governance model can handle multiple competing proposals without fracturing the community.

For anyone building on, investing in, or using Bitcoin, this governance model is not a historical curiosity. It is the reason Bitcoin's monetary policy has never changed, the reason its consensus rules are trustworthy, and the reason Layer 2 developers can treat the base layer as bedrock. Whether that bedrock should evolve faster is a legitimate debate. That it should remain bedrock is not.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.