Foundry BIP-110 vote guide shows miners how to use hashrate to cast decisive, transparent votes now.
Miners can now help decide Bitcoin’s next soft fork. This Foundry BIP-110 vote guide explains how Foundry’s pool is collecting hashrate-weighted votes and when signals change. Learn what BIP-110 does, why it matters, and how to cast or change your vote before the mandatory signaling window near block 961,632 in early August.
Foundry Digital is giving mining clients a direct say on whether to signal for BIP-110, a temporary soft fork that limits non-monetary data in Bitcoin transactions. Your vote is weighted by your hashrate and can swing the pool’s stance from “No” to “Yes” once it crosses 51% of voting hashrate. This Foundry BIP-110 vote guide walks through the process, the timeline, and what your choice could mean for fees, policy, and network stability.
Why BIP-110 matters now
BIP-110 is a proposal to cut back spam-like data on Bitcoin. It does not break old rules for normal payments because it is a soft fork. But it does tighten limits on the size and type of non-monetary data that transactions can carry.
Here are the core rules in plain terms:
Most new outputs must be 34 bytes or smaller.
OP_RETURN outputs go back to an 83-byte limit.
Nodes reject data pushes larger than 256 bytes.
Supporters say these limits keep Bitcoin focused on peer-to-peer money. They want block space to serve monetary activity first. Opponents, including Michael Saylor and Adam Back, warn that this turns a policy debate into a consensus change. They argue it may block fee-paying transactions that some users value. That could also change miner fee mixes and user behavior in ways that are hard to predict.
Foundry BIP-110 vote guide: what miners must know
Foundry’s pool will signal for or against BIP-110 based on votes from client accounts. Each account’s vote weight equals its average hashrate over a set window. The pool starts with “No” and flips to “Yes” only if “Yes” votes reach a majority of voting hashrate.
Who can vote and how votes are weighted
Foundry uses a hashrate-weighted system, measured over an average 10-day window between July 6 and July 15. This means:
Your vote carries weight equal to your average hashrate on the pool during that window.
Accounts that do not respond count as “No.”
You can change your vote while the window remains open.
Individual votes are confidential. Foundry may share aggregate results.
If you ran significant hashrate during July 6–15, your choice can meaningfully affect the pool’s signal. If you were idle during much of that period, your vote weight may be smaller.
When and how signaling happens
Foundry’s default is “No.” It will signal “No” in all blocks until “Yes” votes cross 51% of voting hashrate. When the “Yes” threshold is met, Foundry flips to “Yes” in all of its blocks. The signaling period is expected to run into early August with a mandatory signaling window near block 961,632. That window forces the issue before the activation deadline.
Foundry controls roughly a third of the Bitcoin network’s hashrate. Analysts say Foundry and Antpool can push daily signaling into a decisive range. That makes your vote with Foundry especially important for the outcome.
Step-by-step: casting your vote in Foundry Pool
You do not need to change your hardware to vote. You do need to respond to Foundry’s request and set your choice.
Check your email from Foundry. Look for a notice about BIP-110 voting and the deadline.
Log in to your Foundry pool account. Use your normal dashboard credentials and complete 2FA if required.
Find the BIP-110 voting area. Look for a banner, governance tab, or a direct link in the email.
Select your vote. Choose “Yes” to support signaling for BIP-110 or “No” to oppose.
Confirm your choice. Save or submit. You should see a status message that your vote is recorded.
Monitor your vote and the pool signal. You can change your vote while the window remains open.
If you cannot find the voting page, contact Foundry support. Do not assume your preference is set. Remember: no response is treated as “No.”
How to evaluate your choice
Your decision may reflect views about Bitcoin’s role and your revenue mix. Consider both sides with clear, simple points.
Reasons some miners support BIP-110
Stronger focus on payments. It prioritizes peer-to-peer money over arbitrary data.
Less spam risk. It may reduce blocks filled with non-monetary data.
Predictable policy. Limits restore earlier, familiar caps like the 83-byte OP_RETURN.
Reasons others oppose it
Consensus risk. It turns a policy dispute into a network rule change.
Fee uncertainty. It could block some fee-paying transactions, affecting revenue.
User impact. It constrains use cases that rely on larger data pushes.
Some miners earn extra fees when non-monetary data demand surges. Others prefer steadier blocks focused on payments. Your fleet size, energy cost, and payout goals will shape your choice.
Impact on your revenue and operations
Think about how BIP-110 could shift transaction flows and fees. If non-monetary data gets limited, fee demand may move toward payment-heavy periods. If the fork fails to gain support, inscription-like activity could continue to compete for block space. Either path can change fee timing and risk.
Revenue profile: If your operation benefits from inscription spikes, a “No” may align with your fee strategy. If you value steadier payment flows, a “Yes” may fit better.
Reorg and validity risk: Soft forks require network agreement. If your pool signals for a rule that your nodes enforce but peers do not, you must manage reorg risk. Stay aligned with your pool’s validation rules.
Operational policy: If BIP-110 activates, update policies that use OP_RETURN or larger pushes so your own transactions remain valid.
Prepare your fleet and wallet policy
Node readiness: Track client updates from your node vendor. Make a plan for when and if you apply new rules.
Transaction policy: Ensure internal transactions respect new limits if activation occurs.
Monitoring: Watch block templates, mempool shifts, and fee rates after any signaling change.
Tracking the vote and activation timeline
You should follow both Foundry’s stance and the broader network’s signal rate to gauge activation prospects.
Foundry announcements: Check your dashboard and email for updated vote totals and pool signals.
Network dashboards: Analysts like BGeometrics publish BIP-110 signaling snapshots. Compare pool-by-pool data.
Height checkpoints: The mandatory signaling window lands near block 961,632 in early August. Expect sharper moves around that time.
Peer pools: Watch Antpool and other large pools. Their choices, together with Foundry’s, can tip the outcome.
Use this information to adjust your vote if your view changes. This Foundry BIP-110 vote guide encourages active monitoring so your hashrate reflects your final stance.
Common pitfalls to avoid
Not voting at all: Silence is counted as “No.” If you support BIP-110, you must actively vote.
Missing the weighting window: Your vote weight is based on average hashrate from July 6–15. Know what that figure was for your account.
Waiting too long: A late change can miss the period when Foundry tallies signals.
Assuming the UI saved your vote: Always check for a confirmation message in your dashboard or email.
Ignoring node policy: If activation proceeds, align your node software and internal transaction rules to avoid invalid transactions.
Key takeaways
BIP-110 is a temporary soft fork that caps non-monetary data with clear byte limits.
Foundry will signal based on hashrate-weighted client votes and starts with “No.” It flips to “Yes” if “Yes” crosses 51% of voting hashrate.
Your silence counts as “No,” but you can change your vote while the window is open.
Watch for the mandatory signaling window near block 961,632 in early August and track other large pools.
Plan for fee changes and update node and transaction policies if activation occurs.
Your hashrate is your voice. Use it. With the pool’s large share of network power, your choice can be decisive. If you support the proposal, vote early and confirm your status. If you oppose it, keep monitoring the network and be ready to adjust. This Foundry BIP-110 vote guide is designed to help you cast a clear and confident vote—and to review your position as new data comes in.
(Source: https://bitcoinmagazine.com/news/foundry-asks-bitcoin-miners-vote-bip-110)
For more news: Click Here
FAQ
Q: What is BIP-110 and what would it change?
A: BIP-110 is a temporary soft fork proposal aimed at restricting non-monetary data on the Bitcoin blockchain. Its rules limit most new outputs to 34 bytes, restore an 83-byte limit on OP_RETURN outputs, and reject data pushes above 256 bytes.
Q: How is Foundry letting miners vote on BIP-110?
A: This Foundry BIP-110 vote guide explains that Foundry allows mining clients to signal for or against BIP-110 by using their hashrate, with votes measured over an average 10-day window between July 6 and July 15. The pool signals based on the majority of hashrate-weighted votes and will flip from “No” to “Yes” once “Yes” crosses 51% of voting hashrate.
Q: Who can vote in Foundry’s process and how are votes weighted?
A: Mining clients who had hashrate on Foundry during the July 6–15 averaging window can vote, with each account’s weight equal to its average hashrate in that period. Accounts that do not respond are counted as “No”, individual votes remain confidential, and owners can change their choice while the window is open.
Q: What triggers Foundry to switch its signal from “No” to “Yes”?
A: Foundry starts by signaling “No” and will switch to signaling “Yes” for all of its blocks only when “Yes” votes cross 51% of voting hashrate across the signaling period. The pool expects the signaling period to run into early August with a mandatory signaling window near block 961,632.
Q: How do I cast or change my vote in Foundry’s pool?
A: Check your email from Foundry, log into your Foundry pool account, find the BIP-110 voting area, select “Yes” or “No” and confirm, completing 2FA if required and looking for a confirmation message. You can change your vote while the window remains open and should contact Foundry support if you cannot find the voting page.
Q: What are the main arguments for and against BIP-110?
A: Supporters say the soft fork would reduce spam-like data, prioritize peer-to-peer money, and restore familiar limits like the 83-byte OP_RETURN cap. Opponents, including Michael Saylor and Adam Back, argue it turns a policy dispute into a consensus change that could invalidate fee-paying transactions and alter miner fee mixes.
Q: How might BIP-110 affect miner revenue and node operations?
A: Limiting non-monetary data could shift fee demand toward payment transactions and change miners’ revenue profiles, particularly for operators who benefit from inscription-like activity. If activation occurs, operators should update node and transaction policies and be aware of reorg and validity risks if network agreement is uneven.
Q: Where should I monitor signaling and the activation timeline?
A: Follow Foundry announcements and your pool dashboard for updated vote totals and the pool’s signal, and consult network signaling trackers such as analytics from BGeometrics to compare pool-by-pool data. Watch the mandatory signaling window near block 961,632 in early August and the choices of other large pools like Antpool for moves that can tip the outcome.
* The information provided on this website is based solely on my personal experience, research and technical knowledge. This content should not be construed as investment advice or a recommendation. Any investment decision must be made on the basis of your own independent judgement.