How Bitcoin Transactions Get Confirmed on Braidpool.
- Abstract
- 1. The Problem Braidpool Is Solving
- 2. System Architecture: Three Components
- 3. The Full 6-Stage Pipeline
- 4. Stage-by-Stage Deep Dive
- 5. Architectural Comparisons: Traditional Pool vs. Braidpool
- 6. Open Research Questions
- 7. Summary: The Transaction’s Journey
- 8. Acknowledgements
- 9. Closing Remarks
- References
Topic: Bitcoin Mining Protocol · Distributed Systems · Blockchain Architecture Level: Intermediate–Advanced | Students, Researchers, Protocol Engineers
written by Priya Rani - Twitter - LinkdIn
Abstract
Bitcoin’s mining infrastructure has a centralisation problem. As of 2026, just six to seven pools mine over 95% of all Bitcoin blocks, a structural concentration that hands transaction selection to a small number of operators. Braidpool is a protocol-level response to this: a fully decentralised mining pool built on a Directed Acyclic Graph (DAG) of shares called “beads,” with a committed mempool engine that makes transaction selection local, non-outsourceable, and MEV-resistant. This article traces the complete lifecycle of a Bitcoin transaction through Braidpool’s six confirmation stages, from the global mempool to final settlement, grounding each stage in the system’s architecture, design decisions, and relevant research.
Last 3 years pool dominance - https://mempool.space/graphs/mining/pools#3y
1. The Problem Braidpool Is Solving
Braidpool’s transaction pipeline is only understandable through its architecture. The system runs as three co-located processes on every miner’s machine:
Before we follow a transaction through the pipeline, we need to understand why Braidpool exists.
1.1 Mining Pool Centralisation
Bitcoin was designed with a vision of decentralised, permissionless participation. But in practice, solo mining a Bitcoin block is statistically improbable for almost anyone. The probability that a single miner with, say,1% of the global hashrate finds the next block is 1 in 100 per block interval. To reduce income variance, miners have historically pooled their resources.
The side effect: Power concentration
Research by b10c (2025) shows that six mining pools now mine over 95% of all Bitcoin blocks, with Foundry USA at ~30% and AntPool at ~19% alone collectively approaching the 51% threshold, illustrating the concentration of block production, although pool hashrate should not be interpreted as equivalent to coordinated attack power because miners can rapidly migrate between pools. (b10c, Bitcoin Mining Centralisation in 2025, April 2025).
This matters for a reason that goes beyond just attack risk: whoever runs the pool controls which transactions appear in blocks. A pool operator builds the block template. They decide what gets included and what gets excluded. This is a form of centralised transaction censorship, even if currently exercised benignly.
An NBER study on mining pool economics - Decentralised Mining in Centralised Pools, Li et al., 2019, found that while cross-pool diversification theoretically counteracts some centralisation, the arms-race dynamic of pooling still escalates energy consumption and competitive inequality without meaningfully restoring decentralisation at the transaction-selection level.
1.2 The MEV Problem
Transaction ordering isn’t neutral. Protocols like Runes, BRC-20, and various on-chain DEX implementations depend on the order in which transactions appear within a block to function. A miner who controls transaction ordering can extract value from this dependence by inserting their own transactions to front-run users or selling priority access. This is known as MEV: Maximal Extractable Value.
Daian et al. (2020) formally defined MEV as the total profit a miner can extract through transaction inclusion, exclusion, and reordering. Angeris et al. (The Spectre and Spectra of MEV, 2023, MIT/Berkeley) extended this with a formal theoretical model, showing MEV is related to the “smoothness” of value functions over the symmetric group, essentially, how much value shifts as transactions are permuted.
On Ethereum, MEV stabilised at roughly $300,000 per day in 2024 (Flashbots data). Bitcoin has historically been more MEV-resistant by design, but as Layer 2 protocols and on-chain logic expand, the risk is growing.
Braidpool’s design choice: rather than filtering these transactions (which, as we’ll see, opens a censorship door), randomise their ordering cryptographically, making MEV extraction structurally impossible.
1.3 The DAG Insight
Standard Bitcoin uses a linear chain. When two miners find blocks simultaneously, one becomes an “orphan” = wasted work. High orphan rates are a core reason pooling became necessary in the first place.
Research on DAG-based consensus (GHOST, Sompolinsky & Zohar, 2015; GHOSTDAG/PHANTOM, Sompolinsky et al., 2018) showed that a Directed Acyclic Graph structure can include parallel blocks without discarding them, eliminating orphan waste and enabling much higher share rates while preserving security.
Braidpool extends Nakamoto consensus to a DAG. In its architecture (from the Braidpool spec):
“The consensus algorithm we choose is inspired by simply extending Nakamoto consensus to a Directed Acyclic Graph. We call nodes in this DAG ‘beads’ and the overall structure a ‘braid’.
A braid has an additional restriction relative to a general DAG: beads cannot name as parents other beads that are already ancestors of another parent. This prevents redundant linkage and keeps the graph clean and linearly orderable. The DAG can be totally ordered in linear time using Kahn’s algorithm or a modified depth-first search to “graph cut” a common ancestor to all parents.
Work by developer zawy12 on Braidpool’s difficulty algorithm (Delving Bitcoin, December 2024) showed a remarkable property: hashrate and latency “precisely cancel time units” in the DAG width calculation, enabling a timestamp-free difficulty algorithm that targets DAG width directly, a clean theoretical result with important practical implications for pool security.
With this foundation established, let’s follow a transaction.
2. System Architecture: Three Components
Braidpool’s transaction pipeline is only understandable through its architecture. The system runs as three co-located processes on every miner’s machine:
braidpool-node - The coordination core. Manages the DAG of beads, communicates with other Braidpool peers over libp2p/QUIC, orchestrates template construction, and handles FROST multisig payouts.
cmempoold - The committed mempool engine. A specially compiled, minimally stripped version of Bitcoin Core ,no network access, no wallet, no ZMQ, no RPC ,communicating only via IPC. It holds a “committed” view of the mempool that reflects the cumulative transaction history across the DAG, not just live broadcast transactions.
bitcoind - Standard Bitcoin Core. Handles on-chain validation, chainstate, UTXO set, and block broadcast to the Bitcoin network.
Why IPC-only? This is a deliberate design constraint. By requiring all three components to run on the same host and communicate exclusively via IPC, Braidpool makes it structurally difficult to outsource transaction selection to a remote party. You cannot point your braidpool-node at someone else’s cmempoold over the network, the architecture actively resists that. This is the technical enforcement of the decentralisation goal.
3. The Full 6-Stage Pipeline
Here is the complete transaction journey. Read this before the detailed sections, and refer back to it as you go.
Student Note The Key Boundary: Stages 1–3 operate inside or adjacent to Braidpool’s internal world. Stage 4 is the handoff. Stages 5–6 are pure Bitcoin. Understanding which system “owns” each stage is the key to understanding the architecture.
4. Stage-by-Stage Deep Dive
Stage 1 Mempool: The Global Waiting Room
What happens: A user broadcasts a Bitcoin transaction. It propagates through the Bitcoin P2P network and lands in the mempool of every connected full node including the bitcoind instance that every Braidpool miner runs.
Technical detail: The mempool is an in-memory data structure (a priority queue) organised by fee rate (satoshis per virtual byte, or sat/vByte). Transactions sit here unconfirmed, publicly visible, waiting to be selected.
The Braidpool difference: In a traditional pool, the pool operator’s ‘bitcoind’ reads the mempool and builds a block template that all miners in the pool work on. The individual miner has no say. In Braidpool, every miner runs their own full node and reads their own mempool independently. Transaction selection is performed locally, by the miner, for the miner’s own beads.
This is not just an implementation detail, it’s the architectural enforcement of censorship resistance. No operator can instruct a Braidpool miner to exclude a specific transaction.
Research Connection: The 2025 mining centralisation analysis by b10c notes that “these pools control which transactions they include in or exclude from their blocks” as the core risk of pool concentration. Braidpool eliminates this by making block template construction an entirely local operation.
One template vs. many: Centralised pools vs. Braidpool
Stage 2 - Staged: Entering the Committed Mempool
What happens: The miner’s braidpool-node begins constructing the next bead. It needs to decide which transactions to include. Here is where ‘cmempoold’ does its most important work.
The core problem: In a DAG, multiple beads can be “tips” simultaneously; there is no single latest block. A new bead can have multiple parent beads. Each of those parent beads may have included different transactions. The new bead needs a coherent view of which transactions have already been committed (and should not be repeated) and which are still available.
How “cmempoold” solves this:
Step 1: braidpool-node identifies all parent beads in the DAG
Parent Bead A ──┐
Parent Bead B ──┼──► New Bead (being built)
Parent Bead C ──┘
Step 2: Extract the transaction sets from each parent bead
Step 3: Call cmempoold to MERGE the mempools of all parents
into a single committed mempool for this new bead:
- Transactions already in parents → mark as spent
- Remaining transactions → sorted by ancestor work
- Conflicts resolved by highest-work-path priority
Step 4: Call getblocktemplate on cmempoold → candidate template
Step 5: Reserve space in the template for the new "staged"
transactions not yet seen in any parent
The ancestor work sorting is an important nuance here. Braidpool’s author,Bob McElrath, noted in April 2025 that when constructing a new bead, all parent beads share the same descendant work (the work in the single new bead being created). This means descendant-work sorting doesn’t differentiate; the system falls back to ancestor-work sorting and then effectively lucks out when ordering transactions across competing parent beads.
What “Staged” means: Your transaction has been selected into the candidate block template that will be used if the miner finds a valid share. It’s queued. It’s committed to — but not yet proven.
# Query staged transactions via Braidpool CLI:
braidpool-cli stagedtransactions
Student Analogy: Think of this stage like a professor collecting exam papers at the end of class. The papers are “staged” collected, organised, but not yet officially graded and recorded. The act of collection happened, but the permanent record hasn’t been made yet.
Stage 3- Committed: Mined into a Bead (Weak Block)
What happens: The miner finds a valid share of a Bitcoin block that satisfies Braidpool’s internal proof-of-work difficulty target. This target is set lower than Bitcoin’s full network difficulty, which means miners find shares far more frequently than actual Bitcoin blocks. The share is packaged as a bead.
What a bead contains:
┌─────────────────────────────────────┐
│ BRAIDPOOL BEAD │
├─────────────────────────────────────┤
│ Bitcoin Block Header │
│ (version, prev_hash, merkle_root, │
│ timestamp, bits, nonce) │
├─────────────────────────────────────┤
│ Coinbase Transaction │
│ (with OP_RETURN metadata: │
│ - Braidpool epoch identifier │
│ - Miner's payout pubkey │
│ - Parent bead hashes │
│ - FROST multisig commitment) │
├─────────────────────────────────────┤
│ Selected Transactions │
│ (from committed mempool template, │
│ with RANDOMIZED ordering) │
└─────────────────────────────────────┘
Transaction Randomisation: The Anti-MEV Mechanism
This is architecturally one of the most distinctive and research-relevant parts of Braidpool.
The core problem: MEV (Miner Extractable Value), the ability to profit by reordering, inserting, or front-running transactions, is an increasingly serious threat to blockchain fairness. Malkhi and Szalachowski (MEV Protection on a DAG, 2022, Chainlink Labs) note that “a malicious consensus leader can inject transactions or change the order of user transactions to maximise its profit.” Angeris et al. (2023) formalise MEV as related to the smoothness of value functions over the symmetric group, essentially, how much monetary value shifts as transaction permutations change.
Braidpool’s solution does not filter or censor those approaches, as the developers note, open a dangerous door:
“If you can censor Runes/BRC20 transactions, why can’t you censor Ukraine Donations|Canadian Truckers|Political Party X|Mongolian Independence?”
Instead, Braidpool randomises transaction order cryptographically, making any ordering-dependent protocol unreliable. The algorithm:
Input: Block template from cmempoold
Parent block hash (H_parent)
Miner's extranonce (N)
Step 1: Use cluster mempool analysis to identify
transaction clusters that can be freely reordered
(respecting UTXO spend dependencies)
Example:
TX_A creates output → TX_B spends it
Constraint: TX_A MUST come before TX_B
TX_C and TX_D are independent
Constraint: NONE — can be shuffled freely
Step 2: Seed PRNG with H_parent || N
(deterministic but unpredictable without knowing
the exact parent hash + extranonce combination)
Step 3: Shuffle clusters using PRNG seed
Step 4: Recompute Merkle root over shuffled TX list
Output: Block template with randomised, valid TX ordering
The result: even the miner who finds the share cannot predict or control the final transaction order before committing. Any protocol depending on ordering (Runes, BRC-20 ordinals, sandwich-attack MEV bots) gets broken, not filtered, not censored, just made structurally unreliable.
Research Connection: MAD-DAG (Bar-Zur et al., 2025, Technion) proposes a related approach using the DAG structure itself to protect against MEV by disincentivising selfish ordering even when block rewards vary. Braidpool’s approach is more aggressive: it doesn’t just disincentivise ordering manipulation, it makes it cryptographically impossible at the share level.
Bead Validity Rules
Once committed and broadcast, other Braidpool nodes verify the bead. A critical rule applies:
-
If a transaction cannot be accepted into the merged mempool of the bead’s parents, AND it lies on the highest-work path in the DAG → the bead is invalid.
-
If the transaction conflict is NOT on the highest-work path → skip it and continue.
This is a form of DAG-level consensus on transaction inclusion - invalid transaction history on the canonical path invalidates the bead entirely.
braidpool-cli committedtransactions
Stage 4- Block Staged: The Handoff to Bitcoin
What happens: The vast majority of beads never become Bitcoin blocks. They record proof of work and earn the miner a share of the eventual payout, but Bitcoin’s full difficulty target is far higher. Eventually, roughly every 10 minutes on average, one Braidpool miner’s hash attempt satisfies Bitcoin’s full PoW requirement.
At that moment, braidpool-node assembles the final Bitcoin block using the committed mempool template from cmempoold. The transactions are already ordered (randomised Merkle root computed), the coinbase transaction is finalised, and the block is ready for submission.
This is the critical boundary. Before this stage, everything lives in Braidpool’s internal DAG world, peer-to-peer, off-chain, internal. After this stage, we’re interacting with the Bitcoin base layer, which is global, permanent, and irreversible.
Braidpool DAG World │ Bitcoin Base Layer
│
Beads, shares, DAG, │ Actual Bitcoin blocks,
committed mempool, │ UTXO set, blockchain,
FROST payout system │ global finality
│
◄─── Stage 1, 2, 3 ────►│ ◄─── Stage 4, 5, 6 ───►
braidpool-cli blockstagedtransactions
Stage 5- Mined: On-Chain, First Confirmation
What happens: The assembled Bitcoin block is broadcast to the Bitcoin network via the local ‘bitcoind’ instance. Bitcoin nodes worldwide validate it. If valid, it’s appended to the longest chain. Your transaction now has its first confirmation.
Simultaneously, ‘cmempoold’ is notified via IPC that a new block has been found. It removes every transaction in that block from the committed mempool. This IPC loop keeps the local mempool state synchronised with the global blockchain state - without any network calls.
Block found
│
├──► bitcoind.broadcast(block) ──► Bitcoin P2P Network
│
└──► IPC ──► cmempoold.removeConfirmed(block.txs)
(committed mempool stays clean)
Why this matters: The IPC-only notification architecture means there’s no external API to intercept, no remote service to attack, no network pathway to proxy. The integrity of the mempool state is enforced at the OS process level.
Stage 6- Bitcoin Confirmations: Network Finality
What happens: Pure Bitcoin. Every block added on top of the block containing your transaction is one more confirmation.
Confirmations Security Model Use Case 0 Unconfirmed (mempool) Trusted, zero-conf scenarios only 1 Weak finality Small payments, trusted counterparties 3 Standard Most merchant/retail transactions 6 Strong finality Industry standard reorg probability negligible 100+ Protocol rule Coinbase outputs (Bitcoin enforces this)
The 6-confirmation standard comes from Nakamoto’s original analysis in the Bitcoin whitepaper (2008): the probability of an attacker with q% of the hashrate successfully rewriting history drops exponentially with each confirmation. At 6 confirmations and q=10% hashrate, the attack success probability is under 0.1%.
Braidpool payouts vs. transaction finality: Note the distinction. Braidpool pays its miners every 2016 Bitcoin blocks (~2 weeks) using a FROST threshold Schnorr signatures, which allow a k-of-n group of miners to jointly produce a standard Schnorr signature without revealing individual private keys. This is separate from regular transaction confirmation. User transactions in Braidpool-mined blocks follow the standard 6-confirmation finality regardless of payout cycles.
5. Architectural Comparisons: Traditional Pool vs. Braidpool
5.1 Transaction Lifecycle Comparison
This comparison highlights the fundamental architectural differences between traditional mining pools and Braidpool. In traditional pools, critical decisions such as mempool selection, block template construction, transaction ordering, and payout management are centralised under the pool operator, creating potential points of censorship, MEV extraction, and custodial risk. In contrast, Braidpool distributes these responsibilities across individual miners. Each miner independently maintains a mempool view, constructs block templates locally, participates in decentralised bead tracking through a braid DAG, and receives rewards via non-custodial FROST multisignature payouts. This design removes reliance on centralised infrastructure and enhances transparency, censorship resistance, and miner autonomy throughout the transaction lifecycle.5.2 Stratum V2 vs. Braidpool
Many pools are adopting Stratum V2, which includes a Job Declaration Protocol (JDP) that lets miners build their own block templates. This is directionally similar to Braidpool’s approach, but Braidpool’s developers have noted they are unlikely to use Stratum V2’s JDP or Template Distribution Protocol, because these still allow a miner to delegate template selection to a remote party over the network. Braidpool’s IPC-only design prevents this at the architecture level, not just the protocol level.
Braidpool does use Stratum V2’s Mining Protocol for communication with individual mining devices (ASICs) , the low-level hashrate protocol. Only the template-building layer is redesigned.
6. Open Research Questions
For students and researchers, Braidpool surfaces several interesting unsolved problems:
-
Ancestor Work Sorting in DAGs As noted by McElrath (April 2025): when constructing a new bead, all parent beads have identical descendant work (the single new bead). This means descendant-work sorting is degenerate, the system falls back on ancestor work, and effectively randomness. What are the game-theoretic consequences? Does this create incentive misalignment for transaction selection? Can a miner game ancestor work sorting to manipulate which transactions get committed?
-
Cluster Mempool and DAG Interaction Bitcoin Core’s cluster mempool project (BIP proposed 2023–2024) reorganises mempool transaction graphs into clusters for more principled fee-bump handling. Braidpool uses cluster analysis for its transaction randomisation. How does the DAG’s multi-parent structure interact with CPFP (Child Pays for Parent) and RBF (Replace by Fee) across bead boundaries?
-
Latency, DAG Width, and Transaction Inclusion Fairness The DAG difficulty algorithm targets DAG width as a proxy for hashrate × latency balance. As network latency increases, the DAG naturally widens, including more concurrent beads. What are the implications for transaction inclusion fairness? Do high-latency miners see systematically different transaction sets?
-
MEV Randomisation Completeness Braidpool’s randomisation relies on the cluster mempool to identify independently reorderable transaction groups. But cluster analysis is NP-hard in the general case. Bitcoin Core uses heuristics. Are there edge cases where ordering dependencies are missed, leaving residual MEV surface? How does this interact with lightning channel opens and other time-sensitive transactions?
7. Summary: The Transaction’s Journey
TX SENT
│
▼
Stage 1 │ MEMPOOL │ Bitcoin Network │ Each miner's bitcoind
Stage 2 │ STAGED │ braidpool-node + │ cmempoold merges parents
│ │ cmempoold │ getblocktemplate called
Stage 3 │ COMMITTED │ Braidpool DAG │ Weak block found
│ │ │ TX order randomised
│ │ │ Bead broadcast P2P
────────────────│─────────────│── BITCOIN BOUNDARY ──
Stage 4 │ BLOCK STAGED│ Braidpool → Bitcoin │ Full PoW found
│ │ │ Final block assembled
Stage 5 │ MINED │ Bitcoin Network │ Block broadcast
│ │ │ 1st confirmation
│ │ │ cmempoold cleared
Stage 6 │ CONFIRMATIONS│ Bitcoin Network │ 6 blocks = final
8. Acknowledgements
I would like to take a moment to express my sincere gratitude to everyone who supported this work.
To my family and friends, thank you for your constant encouragement, understanding, and patience throughout this journey.
A special thank you to my mentor, Bob McElrath, who continually challenges me to improve, takes the time to understand every problem I face, and always returns with thoughtful solutions and guidance. Your support and mentorship have meant a great deal to me.
I am also deeply grateful to Zaid and Ansh for being dedicated maintainers, constantly bringing fresh ideas and helping shape discussions around making the protocol truly scalable.
Finally, thank you to the entire Braidpool community for the valuable discussions, reviews, and collaborative spirit that help all of us learn and grow together.
Braidpool Github Contributors
If you’d like to be part of the journey, we’d love to have you join the community on Discord.
9. Closing Remarks
Braidpool represents one of the most architecturally complete attempts to restore Bitcoin’s transaction selection to individual miners. The six-stage pipeline isn’t just an implementation detail; it’s a statement about what trustless, decentralised mining infrastructure should look like.
Each stage is a boundary: between the global Bitcoin network and a local process, between Braidpool’s DAG and Bitcoin’s chain, between a committed mempool and an on-chain ledger. Understanding these boundaries, what crosses them, what enforces them, and what would happen if they were violated is the key to understanding not just Braidpool, but the deeper architecture of trustless systems.
For students: this protocol is a live research artefact. The open questions in Section 6 are not academic hypotheticals; they are problems the developers are actively working through. The best way to learn distributed systems design is to read the source code alongside the spec.
References
- Braidpool Repo : https://github.com/braidpool/braidpool
- Braidpool Specification.
- Committed Mempool Architecture Discussion. Braidpool GitHub Issues
- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
- b10c. Bitcoin Mining Centralisation in 2025. April 15, 2025. https://b10c.me/blog/015-bitcoin-mining-centralization/
- Li, Cong, & He. Decentralised Mining in Centralised Pools. NBER Working Paper 25592, 2019. https://nber.org/papers/w25592
- Daian et al. Flash Boys 2.0: Frontrunning in Decentralised Exchanges, Miner Extractable Value, and Consensus Instability. IEEE S&P 2020.
- Angeris, Chitra, Diamandis, Kulkarni. The Spectre (and Spectra) of Miner Extractable Value August 2023.
- Malkhi & Szalachowski. Maximal Extractable Value (MEV) Protection on a DAG, Chainlink Labs, 2022.
- Bar-Zur et al. MAD-DAG: Protecting Blockchain Consensus from MEV. arXiv:2511.21552, Technion, November 2025.
- Sompolinsky & Zohar. Secure High-Rate Transaction Processing in Bitcoin (GHOST). Financial Cryptography .
- Sompolinsky, Lewenberg, Zohar. PHANTOM / GHOSTDAG. IACR ePrint 2018/104.
- zawy12. Fastest-possible PoW via Simple DAG. Delving Bitcoin, December 2024. https://delvingbitcoin.org/t/fastest-possible-pow-via-simple-dag/1331
This article is intended for students, researchers, and protocol engineers. It reflects the Braidpool architecture as of mid-2025. The protocol is under active development. It is written by @priyaashuu for Bitshala.
Write a comment