How to build on UTXO chains: Bitcoin, Litecoin, Dogecoin, and Bitcoin Cash

Bitcoin doesn't have account balances. It never has. Neither does Litecoin, Dogecoin, or Bitcoin Cash. These four chains share a 2009 design called the UTXO model, which replaces the "one row per address" state machine every Ethereum and Solana developer takes for granted. The model works at the protocol level. It breaks at the application layer, where every basic query your app needs to make either doesn't exist or has to be reassembled by an external indexer.

That's why teams shipping on UTXO chains have spent years stitching infrastructure together: one provider for RPC, another for indexed reads, a third for webhooks, custom code for the gaps. Our UTXO bundle collapses that into a single platform across all four chains, on the same dashboard, API keys, and metering you use for EVM and Solana.

What's different about UTXO chains?

UTXO stands for "unspent transaction output." Every Bitcoin transaction consumes one or more outputs as inputs and creates new outputs. A wallet's "balance" is not stored anywhere on chain. It is computed by summing every output the wallet controls that hasn't been spent yet. The Bitcoin developer guide is explicit: "when your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 satoshis waiting in one or more UTXOs."

A concrete example. Alice controls three UTXOs: 0.4 BTC, 0.3 BTC, and 0.2 BTC. She sends 0.5 BTC to Bob. The transaction consumes her 0.4 and 0.3 BTC outputs in full, creates a 0.5 BTC output for Bob, returns ~0.1999 BTC as change to a new address Alice controls, and leaves ~0.0001 BTC as the miner fee. The 0.2 BTC UTXO is untouched. UTXOs are atomic. You can't partially spend one.

The contrast with account-based chains is sharp:

Litecoin, Dogecoin, and Bitcoin Cash all inherit this model. They forked Bitcoin's codebase, tweaked block times and a few parameters, and shipped. The same mental model and the same class of infrastructure serve all four chains.

Why do devs care?

The differences are not philosophical. They show up in concrete places where most teams underestimate the work.

You can't ask a node for an address's balance

Bitcoin Core stores blocks and transactions. It does not maintain an address-to-transaction index. Core developers have explicitly resisted adding one because, as one maintainer put it, "address indexes are inherently unscalable since they grow linearly with the size of the blockchain." Their position is that address indexing belongs in external services. So every Bitcoin app that needs to display a balance, list a user's transactions, or watch for incoming payments sits on top of an indexer: a service that watches the chain and maintains a queryable database of addresses, transactions, and UTXOs. The only question is who runs it. Most teams use a hosted blockchain node provider instead of standing up their own infrastructure.

Wallets don't have one address, they have thousands

Reusing an address links every input and output under one identity. So the convention is one address per receive, derived from a single seed through hierarchical deterministic (HD) keys defined in BIP 32. An exchange that holds one corporate xpub (an extended public key that can derive a tree of receive addresses from a single root, without exposing the private keys that spend them) can show every customer a freshly derived deposit address. A self-custodial wallet can recompute every UTXO it controls from a 12-word seed. The catch: an indexer must derive addresses sequentially and watch them all, with BIP 44's 20-address gap limit determining when to stop. Skip 20 addresses and the indexer thinks you're done, which is a real-world cause of "where did my funds go" tickets.

Fees are paid by size, not by value

The unit is satoshis per virtual byte. A wallet that consolidates 100 small UTXOs into one output pays a fee proportional to those 100 inputs, regardless of the value moved. Estimation is mempool-dependent and varies minute by minute. Stuck transactions get bumped with replace-by-fee (BIP 125) or child-pays-for-parent. None of this is conceptually hard. All of it is real production code you'd otherwise write yourself.

Finality is probabilistic

A Bitcoin block can be reorganized out of the chain by a competing one. When that happens, every transaction in the displaced blocks returns to the mempool. Outputs that were "spent" become unspent again. Your indexer has to unwind cleanly or it hands your app the wrong balance. Apps protect themselves with confirmation thresholds: 1 conf for low-value payments, 6 for the historic standard, 30+ for large exchange deposits. Litecoin and Dogecoin have shorter block times (2.5 minutes for LTC, 1 minute for DOGE) so the same number of confirmations buys less wall-clock security.

Address formats keep changing

Bitcoin has shipped three address-format upgrades without retiring the earlier ones: P2SH in 2012, SegWit in 2017, and Taproot in 2021. Four families coexist in the network today: legacy P2PKH (1...), nested SegWit P2SH (3...), native SegWit P2WPKH (bc1q...), and Taproot P2TR (bc1p...). A 1-input, 2-output P2WPKH transaction is roughly 141 virtual bytes against ~226 vB for the equivalent P2PKH transaction, so format choice has direct fee consequences. Production wallets and explorers must support all four.

Every team building on Bitcoin spends a chunk of their first quarter on this list. Most of it has nothing to do with the product they're shipping.

How does Alchemy support UTXO chains?

We support Bitcoin, Litecoin, Dogecoin, and Bitcoin Cash on the same platform as Ethereum, Solana, and the rest of the chain directory. Same API keys. Same dashboard. Same metering model. Same webhooks. Every feature ships on every tier.

What ships at launch:

• Raw JSON-RPC passthrough to full nodes running with -txindex=1, for every standard Bitcoin Core method (getblock, getrawtransaction, estimatesmartfee, sendrawtransaction, and the rest).
• Indexed REST APIs for address balances, UTXO lookups, paginated transaction history, enriched transaction details, and spending status. The queries Bitcoin Core can't answer natively, answered in milliseconds.
• xpub and descriptor tracking on all four chains. Output descriptors specify how to derive addresses from a key; we handle the derivation across BIP 44, 49, 84, and 86 trees and the standard 20-address gap limit. Balance, UTXO, and history queries run against the full derived address set, not just the first address you submitted.
• WebSocket subscriptions for confirmed transactions, address activity, new blocks, and reorg notifications, with configurable confirmation thresholds per stream.
• Transaction operations beyond raw broadcast: fee estimation tiered to fast, medium, and slow (mempool-aware), unsigned transaction construction, compilation, verification, and broadcast.
• Compatibility wrappers for Blockbook-style bb_* (the QuickNode shape) and Blockdaemon-style bd_* method signatures, so existing integrations migrate with HTTP-call changes only.

In code, that looks like this. Raw JSON-RPC for anything a node supports:

REST for the queries Bitcoin Core can't answer natively:

Persistent connections for live updates:

The full reference, including every endpoint and the migration-wrapper method list, lives in our Bitcoin API quickstart and the Bitcoin JSON-RPC reference. For a deeper read on how UTXO state differs from account state, our UTXO vs. account model docs cover the protocol-level mechanics.

How's that different from what's out there?

If you're shipping on Bitcoin today, you're probably using one of three providers, each of which leaves gaps:

Three things change for builders.

One vendor, one integration, one bill

If you're already on Alchemy for Ethereum, Base, Polygon, or Solana, adding Bitcoin is not a procurement project. It's a chain you turn on. Same API keys, same metering, same webhooks delivery model, same dashboard. The multi-vendor setups that have been standard on UTXO chains for years collapse into a single integration.

All four chains, one feature set

Every existing provider covers some combination of these chains and features, but the coverage is uneven. QuickNode ships Blockbook indexed reads and xpub tracking on BTC, LTC, and BCH; Dogecoin Blockbook is a separate paid add-on. Blockcypher offers HD Wallets on BTC, LTC, and DOGE through wallets/hd. Blockdaemon's Wallet Transact API covers transaction construction across all four. Teams end up matching each use case to whichever provider supports the specific feature and chain combination they need, then stitching the rest in custom code. We deliver xpub tracking, indexed reads, transaction operations, and WebSocket subscriptions across Bitcoin, Litecoin, Dogecoin, and Bitcoin Cash in one bundle, with no per-chain add-ons or feature splits.

Migrations are HTTP-call changes, not rearchitectures

Compatibility wrappers for Blockbook-style bb_* methods (the QuickNode shape) and Blockdaemon-style bd_* methods mean your existing integrations keep their request shape. You change the host. You don't rewrite the call site. For teams on Blockcypher's legacy REST surface, the request format does change (we use REST GET with a different shape) but the underlying data model is the same. We ship a consolidated UTXO migration guide at launch with sections for Blockcypher, QuickNode Blockbook, and Blockdaemon.

The dev benefit, in one line: less infrastructure to glue together, fewer providers to manage, and a faster path from "we need Bitcoin support" to shipping it.

Build on Bitcoin with Alchemy

Bitcoin, Litecoin, Dogecoin, and Bitcoin Cash are live on Alchemy alongside Ethereum, Solana, and 100+ other chains. PAYG developers add chains from the dashboard on day one. No contracts, no waitlist, no minimum commitment. Enterprise customers get UTXO chains under their existing compute unit allocation. Read the Bitcoin support launch announcement for the full feature breakdown.

Create an endpoint in the Alchemy dashboard and start querying, or contact sales for enterprise integration support and custom pricing.