Electrum Server

What Is an Electrum Server?

An Electrum server is middleware that connects a fully validating Bitcoin node to lightweight wallet clients. It reads every block from the node, extracts transaction data, and builds an index organized by address (technically, by script hash). When a wallet needs to check its balance or look up past transactions, it queries this index instead of scanning the entire blockchain itself.

Without an Electrum server, a wallet has two options: run its own full node and rescan the blockchain (slow and resource-heavy), or trust a third-party API with limited verification. The Electrum protocol offers a middle path: the wallet gets fast, indexed lookups while still verifying transaction inclusion through Merkle proofs, similar to how an SPV client works.

The Electrum protocol was originally designed for the Electrum desktop wallet but has since become a de facto standard. Wallets like Sparrow, BlueWallet, and many others support connecting to Electrum-compatible servers, making this architecture one of the most widely deployed patterns for Bitcoin wallet infrastructure.

How It Works

The Electrum server architecture has three layers: a Bitcoin full node that validates and stores the blockchain, the Electrum server that indexes it, and wallet clients that query the index over the Electrum protocol.

Blockchain Indexing

When the server starts, it connects to a Bitcoin Core node via RPC and begins processing every block from the genesis block forward. For each transaction output, it:

1. Extracts the locking script (scriptPubKey) from the output, which encodes the spending conditions for that UTXO
2. Computes a SHA-256 hash of the script, producing a 32-byte "script hash" that serves as an address-neutral identifier
3. Stores the mapping from script hash to transaction data in a local database

This script hash approach is address-type agnostic: it works identically for P2PKH, P2WPKH, P2TR, and all other address formats. The wallet simply computes the same script hash for any address it controls and queries the server for matching transactions.

The Electrum Protocol

Clients communicate with servers using JSON-RPC over TCP/SSL connections. The standard ports are 50001 (TCP) and 50002 (SSL/TLS), with modern clients exclusively using encrypted connections. The protocol supports both request-response queries and subscriptions that push updates when state changes.

Key protocol methods include:

// Subscribe to changes for an address (by script hash)
blockchain.scripthash.subscribe(scripthash)

// Get full transaction history for an address
blockchain.scripthash.get_history(scripthash)

// Get confirmed and unconfirmed balance
blockchain.scripthash.get_balance(scripthash)

// List unspent outputs for coin selection
blockchain.scripthash.listunspent(scripthash)

// Broadcast a signed transaction
blockchain.transaction.broadcast(raw_tx_hex)

// Subscribe to new block headers
blockchain.headers.subscribe()

// Get Merkle proof for SPV verification
blockchain.transaction.get_merkle(tx_hash, height)

The subscription model is particularly important: when a wallet calls blockchain.scripthash.subscribe, the server returns the current status and then pushes a notification whenever a new transaction involving that script hash appears. This lets wallets detect incoming payments in real time without polling.

SPV Verification

Electrum clients do not blindly trust the server for confirmed transactions. When the server reports a transaction as confirmed, the client requests a Merkle branch via blockchain.transaction.get_merkle. This proof links the transaction to a block header that the client has independently validated as part of the longest proof-of-work chain.

However, the server is trusted for mempool transactions (no SPV proof exists for unconfirmed transactions), and a malicious server can "lie by omission" by withholding transactions from history results. Running your own server eliminates both risks.

Server Implementations

Three open-source implementations dominate the Electrum server ecosystem, each with distinct trade-offs:

ElectrumX

The original Electrum server implementation, written in Python. Now maintained by the spesmilo team (the Electrum wallet developers) after the original author dropped Bitcoin support. ElectrumX stores enough data in its index to answer most client queries without reaching back to Bitcoin Core, making it efficient for serving many concurrent clients.

• Language: Python (requires 3.10+)
• Requires txindex=1 on Bitcoin Core
• Index size: approximately 75+ GB
• Initial sync: several days on commodity hardware
• Actively maintained with regular releases through 2026

Fulcrum

A high-performance C++ implementation that delivers the fastest query response times of any Electrum server. Fulcrum stores the full 32-byte script hash for each entry (no truncation), eliminating false positives. Benchmarks from Sparrow Wallet show it loads wallet history 20 to 30 times faster than ElectrumX.

• Language: C++20, multi-threaded and asynchronous
• Requires txindex=1 on Bitcoin Core
• Index size: approximately 100+ GB
• Recommended for multi-wallet households and power users
• Available on node platforms like Umbrel, RaspiBlitz, and MyNode

electrs

A Rust implementation optimized for minimal resource usage. Unlike ElectrumX and Fulcrum, electrs does not require txindex on Bitcoin Core and maintains the smallest index of any implementation. The trade-off: it stores only block heights per script hash and must reparse raw blocks at query time, resulting in slower responses for wallets with large transaction histories.

• Language: Rust
• Does not require txindex
• Index size: approximately 30+ GB
• Fastest initial sync (under 24 hours on modern hardware)
• Designed for personal use rather than public deployment
• Actively maintained with frequent releases

Privacy Considerations

The most important thing to understand about Electrum servers is the privacy model. When you connect to a public Electrum server, the server operator learns:

• Every address your wallet controls (sent as script hash subscriptions during sync)
• Your complete transaction history for those addresses
• Your IP address (unless routed through Tor)
• Any transactions you broadcast, linking your identity to specific sends
• Your balance and UTXO set via balance and listunspent queries

The server can reasonably conclude that all queried addresses belong to the same entity. For users of HD wallets that derive many addresses from a single seed, this means the server effectively learns your entire financial picture.

This is a fundamentally different privacy model from compact block filters (BIP 157/158), where the client downloads filter data and performs matching locally. With compact block filters, the server never learns which addresses the client is interested in. The trade-off is that compact block filters require more bandwidth and are slower for initial sync. For a deeper comparison, see the Bitcoin privacy landscape analysis.

Why Running Your Own Server Matters

For users who take self-custody seriously, running a personal Electrum server is the recommended configuration. When your wallet connects to your own server backed by your own full node, you get:

• Full privacy: no third party sees your addresses, balances, or transaction patterns
• Full validation: your node verifies every block and transaction against consensus rules, so you are not trusting anyone else for blockchain data
• Censorship resistance: your transactions cannot be selectively blocked or delayed by a server operator
• Availability: your wallet does not depend on the uptime of external infrastructure

A typical self-hosted setup runs Bitcoin Core alongside an Electrum server on the same machine, often a Raspberry Pi or small server. Node distribution platforms like Umbrel, RaspiBlitz, and Start9 bundle these components together with one-click installation, making the setup accessible to non-technical users.

For more context on the trade-offs between self-hosted and third-party infrastructure, see the self-custodial vs. custodial wallets comparison and the Bitcoin node implementation comparison.

Use Cases

Desktop and Mobile Wallets

The primary use case for Electrum servers is powering lightweight wallets. Wallets like Sparrow, Electrum, and BlueWallet connect to an Electrum server to fetch address balances, build transaction histories, and broadcast signed transactions. This lets users run a feature-rich wallet without maintaining hundreds of gigabytes of blockchain data on their device.

Watch-Only Monitoring

Watch-only wallets use Electrum servers to monitor addresses without holding private keys. This pattern is common for cold storage monitoring: a user keeps keys on a signing device while tracking balances through a watch-only wallet connected to their own Electrum server.

Multisig Coordination

Multisig wallets rely on Electrum servers to track UTXO state across multiple signers. Each cosigner can run their own wallet pointed at a shared or personal Electrum server to independently verify the multisig wallet's balance and construct partially signed transactions using PSBTs.

Block Explorer Backends

Customized forks of electrs power some of the most popular block explorers. Blockstream.info uses a fork of electrs as the backend for its Esplora explorer, and mempool.space runs a modified version for its mempool visualization and transaction lookup service.

Risks and Considerations

Trust and Privacy Trade-offs

Using a public Electrum server means trusting the operator not to log, sell, or exploit the address and transaction data they inevitably collect. Even well-intentioned operators may be compelled to share logs with authorities. The only mitigation that fully addresses this is running your own server.

Server Integrity

A malicious Electrum server can withhold transactions from query results (lying by omission), causing a wallet to display an incorrect balance. While the server cannot forge transactions (SPV proofs prevent this for confirmed transactions), it can hide incoming payments. Connecting to multiple servers or running your own eliminates this risk.

Resource Requirements

Running an Electrum server requires a fully synced Bitcoin Core node (600+ GB), plus the server index (30 to 100+ GB depending on implementation). Initial indexing can take hours to days. For users without the hardware or bandwidth to maintain this infrastructure, the privacy trade-off of using a trusted public server may be acceptable, especially when combined with Tor for IP-level privacy.

Phishing via Server List

In the past, attackers have added malicious servers to public Electrum server lists that return crafted error messages containing phishing links. These messages appeared in wallet interfaces and tricked users into downloading malware. Modern Electrum clients have mitigated this by filtering server messages, but the episode illustrates the risks of connecting to untrusted infrastructure.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.