Foundry Miners Vote BIP-110: Control Network Future

The significance of Foundry’s decision cannot be overstated. Foundry controls approximately one-third of the Bitcoin network’s total hashrate, making its position on any major proposal consequential for the network’s future. By allowing miners to determine its signaling strategy through hashrate-weighted voting, Foundry has democratized an otherwise centralized decision point, giving voice to thousands of individual mining operations that contribute computing power to the pool. This approach aligns with Bitcoin’s core principles of decentralization while also highlighting the tension between corporate governance and community consensus.

UnBIP-110: The Proposal and Its Purpose

BIP-110 addresses what its supporters view as a critical problem: the proliferation of arbitrary, non-monetary data on the Bitcoin blockchain, particularly through Ordinals, inscriptions, and other data-embedding protocols. The proposal would implement temporary consensus-level restrictions on transaction data fields, fundamentally reshaping how Bitcoin handles information beyond payments and monetary transactions. Understanding what BIP-110 proposes requires examining both its technical specifications and the philosophical debate surrounding it.

The Technical Specifications of BIP-110

BIP-110 proposes several specific technical limitations designed to constrain data storage on Bitcoin. The first major change would cap most new transaction outputs at 34 bytes, effectively restricting the amount of arbitrary data that can be directly embedded in standard transactions. Additionally, the proposal would restore an 83-byte limit on OP_RETURN outputs, a specific Bitcoin script instruction that has historically served as a mechanism for encoding arbitrary data onto the blockchain. For particularly large data pushes, BIP-110 would reject any pushes exceeding 256 bytes, creating a hard ceiling on how much information can be packed into individual transactions.

Beyond output restrictions, BIP-110 would temporarily restrict certain Taproot capabilities, including annexes, large control blocks, and specific opcodes. This matters because the Taproot upgrade, deployed in late 2021, created new technical pathways for inscribing large amounts of data directly into witness data—the portion of a transaction that contains signatures and scripts. By constraining these capabilities, BIP-110 would make it significantly more expensive and less practical to use Bitcoin as a permanent data storage medium.

Critically, the proposal includes an automatic expiration mechanism. The restrictions would last approximately one year, or roughly 52,416 blocks after activation, after which all limitations would automatically sunset unless explicitly renewed. This temporal constraint is intentional—it allows the Bitcoin community to test whether these restrictions achieve their intended goals without locking in permanent changes based on incomplete information. Additionally, the proposal includes a crucial exception: inputs spending UTXOs created before activation would remain permanently exempt from these rules, meaning existing Bitcoin holders need not worry about deadlines for moving their funds.

The Philosophy Behind Data Limitation

The philosophical underpinning of BIP-110 centers on Bitcoin’s fundamental purpose as sound money. Supporters argue that when Bitcoin transactions can carry arbitrary amounts of non-monetary data, the protocol becomes polluted with what they consider spam—information that serves purposes entirely unrelated to payments and value transfer. This distorts incentives within the Bitcoin system, they contend, because developers focus on accommodating data storage instead of improving Bitcoin’s efficacy as a payment network.

The “inscription” phenomenon, which emerged in 2022 with the introduction of Ordinals, exemplifies the concern. These protocols allow users to inscribe images, text, and other digital artifacts directly onto the Bitcoin blockchain, essentially using it as a permanent data storage medium. While supporters of Ordinals celebrate this as a legitimate and innovative use of Bitcoin’s ledger, critics argue it creates externalities: transaction fees increase, node operators face greater hardware requirements, and blockchain bloat accelerates. From BIP-110’s perspective, these costs fall disproportionately on Bitcoin’s actual users—those seeking to transact in the cryptocurrency for its intended purpose.

How Foundry’s Voting Mechanism Works

Foundry’s voting process represents an innovative attempt to democratize pool decision-making while maintaining technical rigor. Rather than implementing a simple “one account, one vote” system that would be vulnerable to manipulation, Foundry has designed a hashrate-weighted voting mechanism that ensures voting power correlates with actual computational contribution to the network.

The Hashrate-Weighted System

Each miner’s vote carries weight proportional to their average hashrate contribution over a specific ten-day window, from July 6 to July 15, 2026. This approach ensures that voting power accurately reflects actual mining participation within the pool. Miners with larger operations, having contributed more computing power, exercise proportionally greater influence over Foundry’s signaling decision. This creates aligned incentives: those most invested in mining (and thus most affected by network decisions) have the most voice in shaping those decisions.

The voting window extended through early August 2026, concluding at Bitcoin block 961,632. This timeframe was carefully chosen because it corresponds with the mandatory signaling window specified in BIP-110’s activation timeline. At this block height, if the proposal hasn’t achieved early lock-in through voluntary signaling, the protocol forces all miners to signal their position one way or another. By aligning Foundry’s voting window with this critical deadline, the pool ensured its decision would be made at precisely the moment when the broader network needs to understand mining community positioning.

Foundry’s Default Position and Signaling Rules

Foundry established a crucial baseline: until support for BIP-110 crosses the 51% threshold among participating hashrate, the pool signals “No” with all of its blocks. This means that by default, Foundry’s immense hashing power—roughly one-third of the network—was initially weighted against BIP-110. For the proposal to gain Foundry’s signaling support, miners within the pool would need to exceed a clear majority threshold. This high bar for reversal reflects Foundry’s cautious approach: the burden of proof rested with BIP-110 supporters to demonstrate community backing.

Once the 51% threshold of voting hashrate was crossed in support, Foundry would flip its signaling to “Yes” with all of its blocks. This binary switching mechanism is simple and transparent—there’s no ambiguity about where Foundry stands at any given moment. Accounts that failed to submit votes would automatically count as “No” votes, ensuring that passive miners could not inadvertently block the expression of community sentiment through inaction. However, Foundry ensured that individual votes remained confidential, though aggregate results and community-wide signaling data would be shared publicly.

Preserving Miner Autonomy

Crucially, Foundry allowed miners to change their votes at any time while the voting window remained open. This flexibility recognizes that opinions evolve as new information emerges. A miner who initially voted one way could adjust their position as community discourse developed, technical concerns were clarified, or new evidence about the proposal’s implications came to light. This opt-in governance model stands in contrast to the top-down approach of a traditional corporation unilaterally deciding its own position.

The Great BIP-110 Debate: Supporters vs. Critics

BIP-110 has become the focal point of one of Bitcoin’s most fundamental ongoing debates—the question of what the network is fundamentally for. This disagreement transcends simple technical differences; it reflects deeply held beliefs about Bitcoin’s purpose, governance philosophy, and relationship to decentralization.

The Case for BIP-110: Core Arguments from Supporters

Supporters of BIP-110 make several compelling arguments rooted in network health and Bitcoin’s original mission. They contend that arbitrary data storage on Bitcoin creates genuine harms. When blocks fill with inscriptions and other non-monetary information, network users compete for limited blockspace with data whose primary value lies in permanence rather than transactional necessity. This pushes transaction fees upward for those seeking to use Bitcoin for actual payments, effectively pricing ordinary users out of the network while subsidizing data storage.

Beyond direct economic effects, BIP-110 advocates worry about long-term sustainability. As block bloat accelerates, the hardware requirements for running a full Bitcoin node increase correspondingly. This threatens decentralization because fewer individuals and organizations can afford to operate nodes. A network with fewer nodes becomes less robust, less censorship-resistant, and more vulnerable to capture. From this perspective, BIP-110 is fundamentally a decentralization protection mechanism—it preserves Bitcoin’s ability to function as a peer-to-peer system by preventing data storage demands from overwhelming ordinary node operators.

The Opposition: Concerns and Counterarguments

Critics of BIP-110, including prominent figures like Blockstream CEO Adam Back and MicroStrategy chairman Michael Saylor, raise serious concerns about the proposal’s implications. Their primary worry centers on the slippery slope of consensus change driven by policy preferences rather than technical necessity. By restricting one category of transaction use at the consensus level, BIP-110 would establish a precedent: Bitcoin’s core rules can be modified to enforce preferences about how the network “should” be used, rather than simply maintaining the protocol’s functionality.

Adam Back has warned that BIP-110 could establish the mechanism for freezing user funds. If consensus rules can be changed to restrict arbitrary data, what prevents future changes that restrict other transaction types deemed undesirable? This creates network governance risk that extends well beyond data restrictions. Once the principle of consensus restrictions on transaction types is established, proposals to restrict transactions used by exchanges, specific countries, or disfavored communities become technically possible and politically tempting.

Foundry’s Market Position and Network Implications

Understanding the significance of Foundry’s voting process requires grasping exactly how powerful Foundry’s hashrate is within the broader Bitcoin network. Foundry USA controls approximately 23.8% to 33% of the Bitcoin network’s total computing power, depending on the measurement timeframe and which sources are consulted. This enormous share makes Foundry the undisputed leader among mining pools, far exceeding any competitor. To understand what this means: if Foundry were a country, its hashrate would represent roughly one-third of the world’s total Bitcoin mining capacity.

Hashrate Concentration and Governance Weight

This concentration of hashrate creates significant governance implications for any major proposal. When Foundry signals support for a soft fork, it can shift perception of community support dramatically. Conversely, when Foundry opposes or remains neutral toward a proposal, it effectively creates a ceiling on how quickly that proposal can achieve lock-in. Analysts at BGeometrics specifically identified decisions by Foundry and Antpool as the most likely to move daily signaling into meaningful ranges that could determine the overall trajectory of BIP-110 support.

The mandatory signaling window near block 961,632 (projected for early August 2026) represents a moment of truth. At that point, the Bitcoin protocol forces the question: will BIP-110 activate? The answer will substantially depend on whether Foundry signals “Yes” or “No”, because without Foundry’s substantial hashrate, achieving the 55% threshold necessary for early lock-in becomes mathematically very difficult. Conversely, with Foundry’s support, activation becomes probable.

Other Major Pools and Miner Sentiment

Beyond Foundry, the landscape of miner sentiment regarding BIP-110 reveals significant skepticism. Current miner signaling for BIP-110 has remained below 1% as of mid-July 2026, despite months of community discussion and promotion by proponents. This indicates that outside of Foundry’s internal deliberation process, the broader mining community has shown minimal enthusiasm for the proposal. Significantly, none of the 20 largest mining pools besides Foundry had shown interest in supporting BIP-110 as of late January 2026, even as the debate raged.

This low baseline support suggests that Foundry’s voting process genuinely matters. If Foundry’s internal democracy resulted in overwhelming support for BIP-110, it would represent a dramatic reversal from community sentiment and could still push the proposal toward activation. If Foundry’s miners vote down the proposal, it will likely ensure BIP-110’s failure to achieve the threshold necessary for activation.

Timeline and Activation Mechanics

Understanding BIP-110’s technical activation timeline is essential for grasping why Foundry’s voting moment arrives at such a critical juncture. The proposal operates according to a carefully structured schedule that begins with a signaling phase and potentially culminates in mandatory lock-in.

Signaling Period and Early Lock-In

The signaling phase began in December 2025 and extends through approximately August 2026, when Bitcoin reaches block 961,632. During this extended window, miners can voluntarily signal their support or opposition to BIP-110 using bit 4 of the version field in block headers. If supporters achieve 55% signaling in any single retarget period (2,016 blocks, roughly two weeks), early lock-in occurs, immediately advancing the proposal to the next phase.

As of mid-July 2026, signaling had not achieved early lock-in, falling far short of the 55% threshold. This suggests that absent a significant shift in mining community opinion (precisely what Foundry’s voting process might trigger), BIP-110 would proceed to the mandatory signaling phase rather than achieving early activation.

Mandatory Signaling and Forced Consensus

If early lock-in does not occur before block 961,632, the protocol enters a mandatory signaling period. During this phase, miners must explicitly signal their position; blocks that fail to signal are rejected as invalid by the Bitcoin network. This mechanism ensures that the network ultimately determines BIP-110’s fate through forced consensus reflection—every miner must stake a position rather than defaulting to silence.

The mandatory signaling period continues until either 55% of blocks signal support (triggering lock-in) or the signaling window closes without achieving the threshold (causing the proposal to be deactivated). Crucially, Foundry’s voting window, which closed at block 961,632, aligns precisely with this mandatory signaling period, ensuring that the pool’s internal democracy would determine Foundry’s position at the critical moment.

Activation and Implementation

Once lock-in is achieved, activation occurs two weeks later, when the new consensus rules take effect globally. At this moment, all Bitcoin nodes enforcing BIP-110 begin rejecting transactions and blocks that violate the new data restrictions. For miners, this means modifying their block templates and transaction selection logic to comply with the new rules. For nodes, it means updating to software that recognizes the restrictions.

The one-year expiration window—approximately 52,416 blocks—begins immediately upon activation. After this period, all restrictions automatically sunset unless the community actively chooses to renew them through a new signaling process. This temporal mechanism ensures that BIP-110 remains reversible and experimental rather than a permanent constitutional change to Bitcoin.

Implications for Miners and Network Economics

BIP-110’s activation would have material economic consequences for mining operations, particularly those heavily dependent on transaction fee revenue from non-monetary data storage. Understanding these implications is essential for explaining why miners’ votes on the proposal carry such weight and why the debate generates passionate responses.

Fee Revenue Dynamics

Bitcoin mining economics operate on two distinct revenue streams: block subsidies (newly created Bitcoin) and transaction fees. Currently, the block subsidy sits at 3.125 BTC per block following the 2024 halving, representing a declining percentage of total miner revenue over time. Increasingly, miners rely on transaction fees to maintain profitability. Data-heavy transactions, particularly inscriptions and Ordinals, typically pay premium fees because users storing data on Bitcoin are willing to pay substantially to guarantee permanent on-chain storage.

Mining Operation Strategy and Equipment Investment

Mining operations must make long-term infrastructure decisions that depend partly on expectations about future fee environments. Operations that have recently invested heavily in mining hardware, anticipating continued high fees from data-heavy transactions, might find their capital investments less profitable than expected if BIP-110 activates. Conversely, operations that believe BIP-110 will activate might strategically invest in more efficient equipment, knowing that lower fees will require maximum efficiency to remain profitable.

This strategic uncertainty creates an additional dimension to why Foundry’s mining pool voting process matters so much. For individual miners deciding whether to contribute hashrate to Foundry versus competitors, the pool’s position on BIP-110 signals something crucial: will Foundry’s leadership optimize for immediate fee maximization, or for long-term network health and decentralization? Miners with different time horizons and risk tolerances naturally gravitate toward pools aligned with their own strategic preferences.

Community Response and Broader Network Sentiment

The Bitcoin community’s response to Foundry’s voting initiative reveals deep divisions about governance philosophy and Bitcoin’s future direction. Reactions ranged from enthusiastic support to skepticism about whether pool-level voting can genuinely represent diverse miner interests.

Support from Decentralization Advocates

Bitcoin developers and protocol advocates who support BIP-110 praised Foundry’s voting mechanism as a model for democratic pool governance. They argued that allowing individual miners to determine pool signaling represents true decentralization in action—power distributed to the protocol’s actual participants rather than concentrated in corporate leadership. Several prominent Bitcoin developers highlighted Foundry’s approach as potentially revolutionary for mining pool governance, suggesting it could become a template for how pools handle future consensus-critical decisions.

The transparency of Foundry’s process—publishing aggregate voting results and signaling rules publicly—enhanced credibility among those concerned about pool centralization. By removing any mystery about how Foundry would determine its position, the pool demonstrated commitment to governance legitimacy that extended beyond mere technical correctness.

Skepticism from Data-Storage Advocates

Conversely, developers and companies building on Bitcoin for data storage expressed concerns about the voting mechanism and its implications. Some questioned whether hashrate-weighted voting truly represents community sentiment, arguing that it privileges mining operations while excluding developers, users, merchants, and other stakeholders. A developer voting on BIP-110 carries no weight in Foundry’s system despite potentially bearing significant consequences for their protocols and applications.

Advocates for Ordinals and inscriptions specifically worried that a successful BIP-110 vote could establish a dangerous precedent: that minority factions could restrict legitimate uses of Bitcoin through consensus changes. They contended that if data storage constitutes a valid Bitcoin use case (which market demand demonstrates), then restricting it violates principles of protocol neutrality. From this perspective, Foundry’s vote might appear democratic internally but constituted an undemocratic restriction of legitimate network use.

Regulatory and Institutional Considerations

Institutional Bitcoin stakeholders, including major exchanges and financial platforms, largely remained publicly neutral on BIP-110, though private discussions suggested concern about activation’s implications for their systems. These institutions have invested heavily in infrastructure assuming current Bitcoin rules remain stable. Consensus-level changes create operational uncertainty that requires expensive system updates, testing, and potential compliance reviews.

Some regulatory observers noted that BIP-110’s debate occurred within an evolving regulatory environment. In several jurisdictions, 2025-2026 saw increased scrutiny of cryptocurrency, particularly regarding transaction privacy and regulatory compliance. While BIP-110 framed itself purely as a technical measure addressing blockchain bloat, some observers detected regulatory undertones—a hope that restricting Bitcoin’s capacity for data embedding might limit its utility for uses disfavored by regulators.

Technical Implementation Challenges and Network Readiness

Beyond governance and economics, BIP-110’s activation would require substantial technical preparation across the entire Bitcoin ecosystem. The proposal’s technical complexity and broad implications meant that network readiness represented a critical factor in whether activation could succeed smoothly.

Node Software Updates and Compatibility

BIP-110 requires that Bitcoin node software be updated to recognize and enforce the new consensus rules. Node operators—the thousands of individuals and organizations maintaining Bitcoin’s decentralized verification—would need to download and deploy new software versions. The Bitcoin Core project, which maintains the reference implementation, would need to review BIP-110 thoroughly, ensure compatibility with existing functionality, and release updates well before mandatory signaling began.

The timeline proved challenging because BIP-110’s mandatory signaling window arrived before universal node software compatibility could be assumed. Not every node operator updates promptly; some run older software for extended periods. If BIP-110 activated while a significant portion of the network ran incompatible software, this could create a network split or fork, with incompatible nodes rejecting blocks that newer nodes considered valid. Such splits create confusion, reduce network security, and undermine Bitcoin’s credibility.

Wallet and Exchange Coordination

For end users, BIP-110 activation would require wallet software updates ensuring that newly created transactions comply with the new restrictions. Wallet developers would need to modify transaction construction logic to avoid generating outputs that BIP-110 would classify as invalid. For sophisticated wallets supporting Taproot and advanced script constructions, this modification required careful implementation to avoid unexpected validation failures.

Exchanges and custodial services similarly needed to update deposit and withdrawal systems. These institutions maintain massive quantities of user funds and process thousands of transactions daily. Any software bugs or incompatibilities could result in transaction rejections, stuck withdrawals, or worse—potentially moving user funds into non-compliant transaction states. The coordination burden of ensuring global exchange readiness constituted a substantial implementation challenge.

Testing and Soft Fork Risk Mitigation

To minimize risks, the Bitcoin development community planned extensive testing of BIP-110 on testnet—Bitcoin’s experimental network replica. Developers would simulate the proposal’s activation, test edge cases, and identify potential incompatibilities before the proposal reached mainnet mandatory signaling. This deliberate approach to soft fork risk mitigation became standard practice for any significant protocol change following lessons learned from previous activations.

Broader Implications for Bitcoin’s Governance Future

Foundry’s voting initiative transcends the specific question of BIP-110 support, raising fundamental questions about how Bitcoin should make decisions and who should participate in governance.

Precedent for Pool-Level Democracy

If Foundry’s voting process succeeds in meaningfully reflecting miner sentiment and drives BIP-110’s outcome, other mining pools would likely adopt similar mechanisms for future proposals. This could establish pool-level democratic decision-making as the norm for consensus-critical choices, shifting Bitcoin’s de facto governance from top-down corporate leadership to distributed miner participation. Over time, this might improve perception that Bitcoin’s consensus represents genuine community choice rather than elite capture.

However, critics worry that pool voting creates new governance risks. Individual miners, while numerous, possess limited understanding of complex technical tradeoffs underlying major proposals. Pool voting operators might strategically frame proposals to influence desired outcomes. Miners might vote based on immediate economic self-interest rather than long-term network health. These concerns suggest that democratizing within pools might not actually democratize overall network governance if pools themselves become the decision-making unit.

Interaction with Developer Governance

Bitcoin’s governance involves multiple constituencies: miners, developers, node operators, and users. Each group influences protocol evolution through different mechanisms. Developers propose changes and implement code; miners determine whether to signal support; node operators decide whether to enforce consensus rules; users respond to the resulting protocol. BIP-110’s process tested whether miner governance could proceed independently of developer consensus.

Notably, prominent Bitcoin developers expressed concerns about BIP-110’s proposal itself, independent of miner sentiment. If developers ultimately refuse to implement the proposal in node software, miners’ votes for activation become meaningless—activation requires network consensus, not merely miner willingness. This tension between miner and developer governance remains unresolved and could become acute if miners vote for proposals that developers believe harmful.

Evolution Toward Explicit Governance Structures

Some observers noted that Bitcoin’s de facto governance structures—driven by forum discussions, pool signaling, and developer consensus—lack formal transparency and legitimacy. While this informality has served Bitcoin reasonably well for 17 years, the growing complexity of proposals like BIP-110 and the increasing stakes of network decisions might necessitate more explicit governance frameworks. Foundry’s voting mechanism represents one attempt to formalize previously informal decision-making, establishing transparent rules and procedures where previously governance proceeded through opaque corporate deliberation.

Whether Bitcoin ultimately adopts more formal governance structures, or continues relying on distributed informal consensus-building, remains uncertain. What seems clear is that as Bitcoin matures and becomes increasingly consequential, governance questions will only become more prominent.

Conclusion

Foundry’s decision to allow miners to vote on BIP-110 support represents a watershed moment in Bitcoin’s evolution—not merely because of the specific technical proposal at stake, but because of what it reveals about Bitcoin’s capacity for democratic self-governance. The voting process exemplifies both the promise and the peril of decentralized decision-making: it distributes power to those most directly affected by protocol changes, yet it also highlights the complexity of achieving genuine consensus among thousands of stakeholders with divergent interests.

BIP-110 itself encapsulates a fundamental tension within Bitcoin: the question of what purpose the network serves and who gets to decide. Supporters see a necessary step to preserve Bitcoin’s function as sound money and protect network decentralization from data-storage demands. Critics view it as a dangerous precedent for consensus restrictions on transaction types and a misguided attempt to police legitimate network uses. Neither perspective is frivolous; both reflect genuine concerns about Bitcoin’s long-term trajectory.

The outcome of Foundry’s voting process—and BIP-110’s ultimate activation or rejection—will resonate far beyond Bitcoin. It will signal to the broader cryptocurrency ecosystem whether consensus-based governance can function effectively at scale, and whether decentralized networks can make difficult collective decisions while preserving their core values. In that sense, Foundry’s miners don’t merely vote on a technical proposal; they participate in determining the very nature of decentralized governance itself.