Utreexo: How Hash-Based Accumulators Could Make Bitcoin Nodes 10x Lighter

Running a Bitcoin full node today requires storing the entire UTXO set: a database of every unspent transaction output on the network. As of mid-2026, that set contains over 170 million entries and occupies roughly 11 GB on disk. It must be kept in fast storage (ideally RAM-backed) because every incoming transaction is validated against it. This growing requirement prices out resource-constrained devices and raises the barrier to decentralized verification.

Utreexo, proposed by Tadge Dryja at the MIT Digital Currency Initiative in 2019, offers a radically different approach: replace the entire UTXO set with a compact cryptographic accumulator that fits in under one kilobyte. The node still validates every transaction and every consensus rule. It just does so without storing 11 GB of state locally.

Why the UTXO Set Keeps Growing

Every Bitcoin transaction consumes existing UTXOs and creates new ones. The UTXO set is the net result: all outputs that have been created but not yet spent. A full node must check this set to confirm that any given transaction is spending real, unspent coins and not attempting a double spend.

Growth is driven by several factors. The Ordinals and inscriptions wave created millions of small-value outputs: roughly 30% of all UTXOs (over 51 million) are inscription-related dust. Around 49% of all UTXOs contain less than 1,000 satoshis. The set crossed 170 million entries in 2025 and continues to climb, with the on-disk chainstate database now exceeding 11 GB.

For a desktop machine with an SSD, 11 GB is manageable. For a Raspberry Pi, a mobile phone, or a user in a region with limited hardware access, it is a meaningful barrier. And unlike historical block data (which can be pruned), the UTXO set must remain intact and quickly accessible for validation to work.

How Utreexo Works: A Forest of Merkle Trees

The core insight behind Utreexo is that a full node does not need to store every UTXO locally. It only needs to verify that a UTXO exists when someone tries to spend it. A cryptographic accumulator can represent the entire set in a compact form, and anyone spending a UTXO can provide a Merkle proof demonstrating its inclusion.

The Merkle Forest Structure

Utreexo represents the UTXO set as a forest of perfect binary Merkle trees. Each tree has exactly 2ⁿ leaves. For any number N of UTXOs, the number of trees equals the number of set bits in N's binary representation. With 173 million UTXOs, the forest contains roughly 14 trees, producing 14 root hashes of 32 bytes each.

The total accumulator state: 14 roots multiplied by 32 bytes, plus an 8-byte leaf counter. That comes to approximately 456 bytes. The entire UTXO set, compressed from 11 GB to under half a kilobyte, small enough to encode in a QR code.

No consensus change required: Utreexo is a node architecture optimization, not a protocol change. It requires no soft fork or network-wide upgrade. Any node operator can adopt it independently.

Addition and Deletion

When a new UTXO is created, it becomes a leaf in the forest. Utreexo merges trees of equal size iteratively, similar to binary addition with carry. When a UTXO is spent, the spender provides an inclusion proof, the node verifies it against the stored roots, and the leaf is removed from the accumulator.

Per BIP 181, all hashing uses SHA-512/256, producing 32-byte outputs. The specification defines three core operations: addition (append a leaf and merge), verification (validate a proof against stored roots), and deletion (remove a leaf after proof verification).

Inclusion Proofs

An inclusion proof for a single UTXO consists of the sibling hashes along the path from the leaf to the tree root. With approximately 170 million UTXOs, the tree depth is about 27 levels, making the worst-case proof size around 864 bytes (27 hashes of 32 bytes each).

In practice, proofs are batched at the block level. A typical Bitcoin block spends hundreds of UTXOs whose proof paths share many intermediate nodes. Shared ancestors appear only once in the combined proof, significantly reducing total data. The original paper estimated that batched proofs add roughly 20-25% to the data downloaded during initial block download when paired with a modest (500 MB) RAM cache.

The Bridge Node Architecture

Utreexo introduces two types of nodes: compact nodes (which store only the accumulator roots) and bridge nodes (which maintain the full Merkle forest and generate proofs for compact nodes).

A bridge node is a standard full node with approximately 8 GB of additional storage for the complete forest and a mapping of outpoints to tree positions. When a compact node requests a block, the bridge node attaches the necessary inclusion proofs. Any existing full node can become a bridge node, and the proofs it generates are independently verifiable: a compact node does not need to trust the bridge.

This trust model is important. If a bridge node provides an invalid proof, the compact node detects the error immediately by checking against its stored roots. The system is trustless in the same way that serving block headers is trustless: the data is self-authenticating.

Bandwidth vs. Storage: The Core Tradeoff

Utreexo trades storage for bandwidth. The compact node saves gigabytes of disk space but must download inclusion proofs with every block and transaction it receives. The question is whether this tradeoff is worthwhile.

For devices where storage is the binding constraint (phones, embedded systems, low-cost single-board computers), the tradeoff strongly favors Utreexo. For data center nodes on fast connections, the bandwidth overhead is negligible. The nodes where Utreexo matters most are precisely the ones that cannot exist today.

Transient UTXOs save bandwidth: BIP 182 specifies that UTXOs created and spent within the same block are excluded from the accumulator entirely. Since roughly 40% of UTXOs live fewer than 20 blocks, this optimization meaningfully reduces both proof data and accumulator operations.

Utreexo vs. Other Node Optimization Approaches

Utreexo is not the only approach to making Bitcoin nodes more accessible. AssumeUTXO, pruning, and SPV/lightweight clients each address different aspects of the problem. Understanding how they compare clarifies where Utreexo fits.

AssumeUTXO: Fast Bootstrapping

AssumeUTXO, merged into Bitcoin Core in version 28, lets a new node load a pre-computed snapshot of the UTXO set and begin validating new blocks immediately. The full historical validation happens in the background. It solves the sync-time problem: a new node can be operational in roughly 90 minutes instead of days.

The key difference: AssumeUTXO is a one-time sync optimization. After bootstrapping, the node still stores the full UTXO set. Utreexo provides permanent, ongoing storage reduction. The two approaches are complementary, and combining them is already being explored.

Pruning: Discarding Old Blocks

Pruned nodes delete historical block data after validating it, reducing total storage from over 650 GB to roughly 550 MB of block data. However, pruning does not touch the UTXO set: a pruned node still maintains the full ~11 GB chainstate.

Utreexo and pruning are orthogonal optimizations that can be combined. The Floresta implementation already does this: it runs as a pruned Utreexo node, requiring only about 800 MB of total disk space while still fully validating every transaction.

SPV and Lightweight Clients

SPV clients download only block headers (about 50 MB) and trust that miners have validated transactions correctly. Neutrino clients (BIP 157/158) improve privacy over classic SPV but share the same fundamental limitation: they do not validate consensus rules.

Utreexo occupies a fundamentally different security category. A Utreexo compact node validates every transaction against every consensus rule, exactly like a traditional full node. It achieves lightweight-client storage characteristics with full-node security guarantees.

Current Implementation Status

As of mid-2026, Utreexo has moved from research prototype to working software with formal BIP proposals under review. Three draft BIPs were submitted in August 2025 by Calvin Kim, Tadge Dryja, and Davidson Souza.

BIP Specifications

utreexod: Go Implementation

The utreexod project, a fork of btcd written in Go, released its beta in May 2024. It supports mainnet operation (though it is not yet recommended for significant funds) and includes a hardcoded UTXO state for rapid bootstrapping without full IBD. The implementation is specifically designed for low disk I/O, making it suitable for devices with SD card storage.

Floresta: Rust Implementation

Floresta, developed by Davidson Souza and funded by Vinteum, is a Rust implementation that wraps libbitcoinkernel for consensus-critical validation. This makes it bug-compatible with Bitcoin Core, avoiding consensus divergence risks. Floresta combines pruning with Utreexo accumulators, requiring only about 800 MB of disk space and less than 300 MB of RAM. It has been demonstrated running on a $15 Raspberry Pi Zero 2W with just 512 MB of RAM.

Floresta also includes a built-in Electrum server, meaning wallet software that speaks the Electrum protocol can connect directly to a Floresta node without needing a separate indexing service. The project exposes a library interface (libfloresta) for embedding in other applications.

Mandacaru: Mobile Full Node

The most striking demonstration of Utreexo's potential is Mandacaru, an Android application built on Floresta. Written in Kotlin with Jetpack Compose, it runs a fully validating Bitcoin node on Android 10+ devices. It supports mainnet, testnet, and signet, includes a built-in Electrum server, and can look up and broadcast transactions.

Mandacaru ships with an "assumeutreexo" mode: a bundled accumulator snapshot that lets the node start validating immediately. If the bundled snapshot is invalid, verification fails detectably, preserving the security model. This combines the fast-start benefit of AssumeUTXO with the permanent storage reduction of Utreexo.

What Mobile Full Nodes Would Change

The practical impact of Utreexo extends beyond storage savings. If phones and low-cost devices can run fully validating nodes, the economics of Bitcoin verification change fundamentally.

Self-Sovereign Verification

Today, most mobile Bitcoin wallets are lightweight clients that rely on third-party servers for transaction data. They trust that those servers are honest about the blockchain state. A mobile Utreexo node eliminates this dependency: the device validates everything itself, matching the security guarantees of a desktop full node.

Decentralization of the Verification Layer

Bitcoin's security model depends on a distributed set of nodes independently verifying every block. As the UTXO set grows and hardware requirements increase, the number of entities capable of running full nodes shrinks. Utreexo reverses this trend by bringing verification to devices that already exist in billions of pockets.

This has direct relevance for Bitcoin Layer 2 protocols. When users of systems like Spark can run their own full nodes to verify Bitcoin-anchored transactions, the verification layer becomes more decentralized. Rather than trusting a remote server to confirm that an on-chain commitment transaction was included in a valid block, the user's own device can confirm it directly.

Remaining Challenges for Mobile

Utreexo does not eliminate all barriers to mobile full nodes. Several practical challenges remain:

• Bandwidth overhead (~1.7x for block relay) is significant on metered cellular connections
• Initial block download requires billions of hash operations, consuming battery and CPU time
• The mempool handling and peer-to-peer networking stack is still maturing on mobile platforms
• Background execution on iOS and Android is restricted, limiting continuous synchronization

These are engineering challenges, not fundamental limitations. The "assumeutreexo" approach in Mandacaru demonstrates that reasonable compromises exist: start from a recent snapshot and validate forward, rather than replaying the entire blockchain history on a phone.

Development Timeline

Open Questions and Future Directions

Utreexo's design is well-understood, but several open questions remain before it could see widespread adoption.

Bitcoin Core Integration

Utreexo is not currently part of Bitcoin Core. The BIP proposals are in draft status, and integration into the reference implementation would require substantial peer review and testing. Floresta's approach of wrapping libbitcoinkernel suggests a possible integration path where Utreexo can leverage Bitcoin Core's consensus logic without forking the entire codebase.

Proof Relay Efficiency

How proofs propagate across the P2P network matters for scalability. BIP 183 defines protocol extensions for proof exchange, but optimizing proof relay, especially for unconfirmed transactions in the mempool, remains an active area of research. Compact block relay (BIP 152) reduced block propagation latency by transmitting short transaction IDs instead of full transactions. Utreexo proofs will need similarly efficient relay mechanisms to avoid adding latency to block propagation.

Interaction With Other Proposals

Utreexo intersects with several other Bitcoin improvement efforts. AssumeUTXO infrastructure could be reused for bootstrapping Utreexo nodes. The Great Consensus Cleanup could simplify some edge cases in accumulator validation. Erlay (efficient transaction relay) would reduce the bandwidth overhead of attaching proofs to individual transactions. These proposals are independent but mutually reinforcing.

What This Means for Bitcoin Builders

For developers building on Bitcoin and its Layer 2 ecosystem, Utreexo represents a shift in what is architecturally possible. Wallets that currently rely on trusted Electrum servers could embed a Floresta-based node directly, gaining full validation without requiring users to provision server infrastructure. Lightning nodes, which already need to monitor the chain for channel breaches, could use Utreexo to reduce their storage footprint. And Layer 2 protocols that anchor state to Bitcoin L1 benefit from a world where more users can independently verify those anchors.

Developers interested in building on Bitcoin Layer 2s can explore the Spark SDK documentation for building self-custodial wallets and payment applications. For a deeper look at how Bitcoin node optimization techniques compare, see our research on AssumeUTXO fast sync and Bitcoin node implementation comparison.

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.