Who holds the Power in the Bitcoin ecosystem (does your node matter)
Bitcoin does not run on ideals; it runs on coordination between code, hash, and liquidity — and those are controlled by a few dozen institutional actors who can synchronize quickly.
In my “How Bitcoin’s developers are attacking its Sovereign/Monetary use“ article, I wrote about how governance activations show who sets the rules.
Past upgrade processes (e.g., BIP9, BIP8, “Speedy Trial”) revealed that miners and coordinated developers can accelerate or block changes faster than ordinary users can veto.
Power concentrates among aligned institutional actors.
Net effect:
Technical ideals matter less than coordination leverage.
Future upgrades will likely follow similar political dynamics.
In simple terms
What actually happens in upgrades
Rule changes need coordination. To activate, you need miners to mine the new rules, big pools to signal, exchanges/custodians to accept deposits, wallet/infrastructure teams to ship updates, and users to run them.
BIP9/BIP8/“Speedy Trial” are coordination levers. They set thresholds and timers that, in practice, let miners + core devs + major infra decide when something flips on — or stalls.
Who really has leverage
Miners/pools: Control signaling and block production. If they don’t play ball, activation drags. If they coordinate, it can move very fast.
Core maintainers & lead devs: Control what’s merged, what binaries ship, and which activation method/warnings land in the “standard” client most people run.
Exchanges/custodians/Payment-Service-Providers: Control where coins flow. If they choose a side, liquidity follows them. That decides practical reality more than forum votes.
Ordinary users: Matter in aggregate, but only if they can withhold liquidity or hash in a coordinated way — which is rare.
Why this concentrates power
Coordinating thousands of small users is hard; coordinating a few dozen institutions is easy.
Activation schemes with time windows and thresholds reward actors who can move in lockstep (pools, large infra, top client maintainers).
“User veto” exists in theory (run your own rules), but without miners and exchanges you’re on a minority chain with no liquidity.
What this means in practice
Technical purity loses to coordination. The “best” design doesn’t win; the most coordinated coalition does.
Messaging is part of the game. Activation method choices (“Speedy Trial”, LOT=true/false, flag days) are politics encoded in software defaults.
Future upgrades repeat the pattern. Expect negotiations between dev leads, pools, and big venues; users mostly ratify by upgrading after the fact.
Bottom line
Bitcoin’s upgrades aren’t decided by abstract ideals — they’re decided by who can coordinate miners, code, and liquidity fastest. That’s why power tends to cluster with aligned institutional actors, and why future changes will follow the same political playbook.
Now, let’s dive a bit deeper.
The Power Stack (from fastest practical leverage → slowest)
1) Liquidity governors
Who: Top exchanges/custodians/payment processors (Coinbase, Binance, Bitfinex, major prime brokers, ETF custodians), stablecoin issuers, large market makers.
Levers:
List/deposit policy: They decide which client/ruleset is “Bitcoin” for practical settlement. If deposits from a minority chain or non-standard policy are refused, that fork is dead for commerce.
Wallet defaults & API constraints: They throttle or prefer certain script types, Replace-By-Fee modes, feerates, Taproot paths, etc.
Paperization share: The more Assets under management in ETFs/custody, the more price discovery moves off self-custody and onto venues that coordinate easily.
Why this wins: Users don’t “vote” with full nodes; they vote with where their coins can move today. Liquidity decides reality.
2) Coordination devs (maintainers + release managers)
Who: Core maintainers, the few people who can actually merge, ship binaries, set activation knobs (BIP9/BIP8/Speedy-Trial/LOT flags), and write release notes/warnings.
Levers:
What’s “in Core”: Inclusion/omission of activation mechanisms, default policies, and warnings shape behavior more than any mailing-list rhetoric.
Standardness/mempool policy: “Policy, not consensus” still governs relay and mining templates — that’s de facto power over what transacts cheaply or at all.
Why this wins: 70–80% of the network follows the reference client defaults. Defaults beat principles.
3) Pools & pool software authors
Who: 10–15 pool operators, plus the devs who ship pool templates and job selectors.
Levers:
Signaling/activation: A few pools can hit the threshold or stall it.
Template filtering: They can quietly exclude non-standard transactions, or OFAC lists, and miners follow.
Orphan-risk economics: Pools adopt changes that reduce variance or increase fees; they ignore those that don’t pay.
Why this wins: Hashpower centralizes quickly around variance/fee advantages; coordination among a dozen actors is trivial.
4) Relay/mempool gatekeepers
Who: Large public relays, miners’ gateway nodes, full-node implementations that most infra runs (Core, Knots).
Levers:
Policy switches: Replace-By-Fee rules, OP_RETURN size, package relay, “standardness” lists.
Propagation bias: If a txn doesn’t relay, it effectively doesn’t exist for most miners.
Why this wins: Relay is the bloodstream; “policy” is a silent choke-point.
5) App stores / OS platforms / cloud
Who: Apple/Google (wallet distribution), major clouds (AWS/GCP/Azure) hosting nodes/pools/exchanges.
Levers:
App policy: ID-gating, KYC-only wallet distribution, metadata requirements.
Cloud Acceptable Use Policies: ToS can squeeze archival nodes/pools under “illicit content” or traffic policies.
Why this wins: Kill the default wallet distribution or popular node images → real usage collapses outside pros.
6) Regulators/insurers/banks
Who: AML agencies, securities regulators, cyber insurers, correspondent banks.
Levers:
Compliance perimeter: AML/KYC, Travel Rule, “unhosted wallet” frictions; bank account closures; insurer control baselines.
Civil liability vectors: Make node/pool operators liable for content or transmissions.
Why this wins: Even without “bans”, compliance frictions decide adoption and fee pressure.
7) Hardware & energy chokepoints
Who: ASIC supply chain (foundries, packaging), large energy providers/grid operators.
Levers:
Capex allocation & lead times: Shape hash distribution and bargaining power of pools.
Energy contracts: Curtailment, tariffs, priority rules.
Why this wins: Hashpower follows cheap silicon + power; both are permissioned in practice.
8) Ordinary users (“economic nodes”)
Who: Self-custody users, sovereign merchants, hobby nodes.
Levers:
Liquidity boycott: Collective refusal to use certain rules/UTXO forms.
Hash/merchant coordination: Rare but possible (User-Activated-Soft-Fork 2017).
Why they rarely win: Coordination costs are enormous; attention/UX scarcity; no treasury.
How upgrades actually get decided (repeatable pattern)
Core release bakes the rails (activation method + policy defaults).
Pools pre-coordinate on signaling templates if it helps fees/variance or aligns with compliance pressure.
Exchanges/custodians quietly say which side they’ll credit as “BTC” (internal risk meetings).
Narrative op: “Free-market signaling / rough consensus” messaging keeps users calm.
Flag-day/threshold hits → users upgrade after the fact; dissenters discover that without liquidity/relay their chain is a museum piece.
2017 SegWit and 2021 Taproot showed both sides: User-Activated-Soft-Fork can work only when large venues and miners already see it as net-beneficial and low-risk. Otherwise, delays or neutering win.
Why power keeps concentrating (and will more)
Paperization: ETFs/notes → price anchored by venues, not by sovereign users.
Compliance perimeter rising: OFAC lists, Travel Rule, provenance → pools/venues want policy clients.
Default UX: App stores and hosted wallets gate retail — ID-first becomes normal.
Coordination math: 20 institutions can decide in a week what 100k users can’t do in a year.
What this implies for future changes
Policy-compatible tweaks (provenance, relay policies, standardness shifts, wallet metadata) move fast.
Hard sovereignty features (that threaten perimeter control or raise non-compliance usage) stall unless there’s overwhelming economic upside for pools/venues.
Mempool policy will be the stealth battleground: it shapes what’s cheap/relayed without touching consensus. Watch mempool policy diffs like earnings — relay is the new law.
The extra levers almost nobody models
A) Derivatives & index plumbing (price governance)
CME futures / ETF primary markets / Authorized Participants & market makers: when paper share of exposure rises, basis trades and collateral rules effectively move price formation off self-custody and onto a few desks. That shapes what chain is “worth coordinating on” during upgrades.
Reference rate providers / index committees: which trades count for NAV/settlement is governance by spreadsheet. If your chain/policy is excluded from the reference set, you’ve lost de facto reality.
B) Mempool/relay defaults beyond Core
DNS seeds & time sources: who your node hears from first shapes your view of the network; a handful of operators run most seeds.
Large public relays / gateway nodes / FIBRE-like hops: miners often don’t peer with you; they peer with a few relays. Policy changes at those relays (minrelayfee, Replace-By-Fee modes, package relay) are a soft kill or boost.
Standardness knobs: “policy, not consensus” is where controversial tx types live or die cheaply (datacarriersize, OP_RETURN ceilings, template filters, mempoolfullrbf, package relay admission).
C) Maintainer bus-factor & funding
BIP editors, release managers, Common Vulnerabilities and Exposures triage team: tiny set. If they won’t ship an activation path or they label something “risky”, most infra won’t touch it.
Funding channels: paymasters (companies, grant orgs) tilt roadmaps without ever issuing an edict.
D) Distribution levers
App stores / OS attestation / telemetry: wallets live or die by default distribution. If iOS/Android or MDM policies squeeze “unhosted” wallets, your economic users shrink even with “freedom on GitHub”.
Cloud Acceptable Use Policies: archival nodes, relays, explorers, pool infra are on AWS/GCP/Azure; a ToS nudge can prune whole classes (“unknown binaries”, “CSAM liabilities”, “financial compliance”).
E) Legal & liability toggles
FATF / Travel Rule / “unhosted wallet” guidance: not a ban — just a friction ratchet that steers exchanges/custodians/pools to policy clients.
Node operator civil exposure via illegal content theories: even if it’s nonsense, insurers and compliance teams react first, developers later.
F) ASIC & energy choke-points
Foundry capacity, packaging, firmware signing: a few supply nodes decide who scales hash, when.
Grid contracts / curtailment: “policy power” to turn miners off at the worst time.
G) Media narrative & developer UX defaults
SDKs / wallet kits / fee estimators: most devs import fee logic and “standardness” from the reference stack. Change the kit, you change the surface.
Activation reality (why coordination beats ideals)
Thresholds + time windows reward small-N coordination (pools + venues + release).
Core’s shipped knobs (BIP9 vs BIP8, Speedy Trial, LOT flags, “warnings”) are politics in default form.
Liquidity veto > node veto: a minority chain with little deposit/withdrawal support is a museum piece, regardless of how many home nodes like it.
User-Activated-Soft-Fork “worked” in 2017 because the same small-N actors quietly pre-aligned. Without that, it stalls.
What would have to change for ordinary users (“economic nodes”) to regain power
Think levers we can actually move, measured by penetration %, not vibes. The goal isn’t purity; it’s raising the coordination cost for top-down decisions we don’t like.
A) Liquidity independence (so our veto has teeth)
Self-custody share ↑
Target: ≥ 40–50% of circulating BTC in self-custody and rising.
How: push defaults that make self-custody safe for normal people (seedless schemes with social recovery, inheritance kits, proof-of-payment exports).
Proof-of-Reserves (PoR) norms for custodians & ETFs
Target: ≥ 80% of custodial BTC by Assets-Under-Management under cryptographic PoR (plus liabilities attestations).
Why: shrinks room for paper overhang that dulls user leverage.
Decentralized fiat on/off-ramps
Target: ≥ 20% of monthly retail flow through non-custodial P2P rails (Bisq/RoboSats/peers) or self-hosted Payment-Service-Providers.
Why: exchange listing policy stops being a hard veto if we can still move commerce.
B) Relay sovereignty (so our transactions exist)
Client plurality
Target: Core ≤ 30% of reachable nodes; healthy share on Knots/viable alternate clients that can flip policy flags independently.
Why: prevents a single release train from setting global mempool behavior.
Policy diversity
Target: measurable minority (≥ 20–30%) running non-default policy: datacarriersize capped, package relay tuned, OP_RETURN filters sensible.
Why: makes “policy as law” more expensive to deploy.
Independent relays / alt-seeds
Target: multiple high-throughput relays not controlled by the same org; diversified DNS seeds; more Tor/I2P peers.
Why: if default relays exclude your tx, you still propagate.
C) Mining veto (so pools can’t coordinate against us cheaply)
DATUM/Stratum V2 with job negotiation
Target: ≥ 30% of hash using miner-selected templates (not just V2 transport).
Why: pool operators lose sole policy filter; censorship becomes a coordination problem, not one switch.
Pool plurality & co-ops
Target: top-3 pools ≤ 50% of hash; emergence of non-custodial pool-of-pools and P2Pool-like options with real payouts.
Firmware & foundry diversification
Target: multi-vendor firmware with open signing; two+ foundries in production for BTC ASICs.
Why: reduces single-point policy capture on hash.
D) Distribution independence (so defaults don’t crush us)
Target: ≥ 25% of active sovereign users getting wallets via alt channels (F-Droid, sideload, desktop).
Why: app-store policy becomes a pinch, not a kill.
Cloud independence for infra
Target: a meaningful slice of relays/explorers on bare-metal, residential, or alt clouds.
Why: Acceptable Use Policy shock ≠ full blackout.
E) Playbook for upgrades (pre-committed strategy)
User-Activated-Soft-Fork 2.0 with economic triggers
Structure: clients ship two-key activation: (a) LOT=false path and (b) a hard flag day that auto-arms only if (i) Proof-of-Reserves coverage ≥ X%, (ii) miner job-negotiation ≥ Y%, (iii) N major Payment-Service-Providers signal readiness.
Why: reduces risk of splitting into an illiquid minority chain.
If we can’t move at least half of these dials, users remain spectators.
So to tilt power back to users, increase plurality in clients/relays, push job-negotiation to miners, raise self-custody & Proof-of-Reserves coverage, and de-app-store wallet distribution. If those needles move, ordinary users regain a credible veto. If they don’t, upgrades will keep following the same small-N political playbook — no matter how many nodes say otherwise.
Bottom line
Bitcoin does not run on ideals; it runs on coordination between code, hash, and liquidity — and those are controlled by a few dozen institutional actors who can synchronize quickly. Core defaults + pool templates + venue policies decide reality. Users matter only when they can coordinate economic liquidity, which is rare. Expect future changes to follow the same political playbook — and position your capital (and your sovereignty) accordingly.
The coordination dynamics here are spot on. Most people think running a node gives them real power, but liquidity governors and big exchages actually call the shots. That section on pool coordination and mempool policy as the stealth battleground is especialy eye opening.