When someone says “white-label crypto stack”, the phrase does a lot of quiet work. It sounds like a single product, but it’s really a system of six distinct components that each solve a different problem, talk to each other in specific ways, and individually take real engineering to get right. If you’re evaluating whether to build one yourself or start from a pre-built one, the first useful thing is to understand what’s actually in the box — and why each piece is there rather than optional.
This is that tour. I build a white-label stack of exactly these components, so the descriptions are concrete rather than abstract. But the goal here is to explain the architecture, not to sell — by the end you’ll be able to judge any stack, mine or anyone else’s, on whether it has the pieces it needs and whether they fit together honestly. Everything described runs on testnet, where the coins have no monetary value; this is about software components, not money. See the software & demo notice.
01 · The blockchain node — the network itself
The node is the foundation everything else stands on. It’s the program that holds the rules of your chain: it validates transactions and blocks against your consensus parameters, relays them to other nodes, stores the chain, and exposes an RPC interface that every other component queries.
Why you need it: without a node, there is no network — nothing to validate transactions, nothing to peer with, nothing to ask “what’s the balance of this address?”. A node is the blockchain in any practical sense.
A credible setup runs at least two nodes that peer with each other; one node is just a database. The node also enforces the rules you chose at genesis — block time, reward schedule, supply cap, address format — so it’s where your chain’s identity actually lives. In our stack the node is a Scrypt chain forked from Litecoin Core, with the genesis ceremony already done; that ceremony (mining genesis, baking its hash into the source, getting every node to agree byte-for-byte) is the part that’s fiddly to do from scratch, and getting the algorithm choice right matters — I wrote up why we chose Scrypt.
02 · The wallet — how people hold and move coins
A chain nobody can hold is inert. The wallet is the user-facing piece that generates addresses, shows balances, and signs transactions. It’s also where the hardest correctness requirements live, because a bug here doesn’t throw an error — it loses access permanently.
Why you need it: it’s the only way an ordinary person interacts with your chain. No wallet, no users.
The properties that matter:
- Self-custody. Keys derive from a BIP-39 seed phrase and stay on the device; no operator holds a copy. This is the correct default, and it shifts a genuine responsibility onto users — enough that we wrote a whole seed-phrase storage field guide.
- Chain-correct addressing. The wallet must derive addresses on your chain’s parameters — the right derivation paths and the right address prefix/HRP. A wrong coin-type or bech32 prefix produces valid-looking addresses that belong to nobody.
- A server to query. A mobile wallet doesn’t run a full node; it talks to an Electrum-style indexer (electrs/ElectrumX) that watches your chain and answers balance and broadcast requests.
Our wallet is a self-custodial Android app on BDK with a custom address codec for the demo chain — and, again, the chain-specific address handling is the awkward part, not the screens.
03 · The mining pool — producing blocks at scale
On a small chain, a lone miner can wait an impractically long time to find a block. A mining pool combines many miners’ work, shares the burden of finding blocks, and divides the result by how much each contributed.
Why you need it: if you want more than a couple of people able to participate, solo mining doesn’t scale. The pool is what lets a crowd contribute and be accounted for fairly.
Architecturally the pool sits between miners and your node. Miners connect over the Stratum protocol; the pool hands out work, collects valid shares, submits found blocks to the node over RPC, and tracks contributions. The two recurring traps:
- Endianness. Stratum and the node disagree on the byte order of several fields (previous-block hash, nbits, ntime). Reverse one and the pool looks alive but never submits a valid block. We hit this exactly.
- Reward scheme. PPS+ pays per share with the pool absorbing variance; PPLNS pays from a sliding window when a block is found. Different risk distributions, not right-and-wrong — and switching between them has its own gotchas, which we documented in PPS+ to PPLNS without losing a cycle.
The pool in our stack runs real Stratum against the demo chain with those byte-order bugs already fixed — which is precisely the part that’s slow to debug from zero.
04 · The block explorer — reading the chain
The explorer is the read-only window onto the network: blocks, transactions, addresses, confirmations. It’s typically an indexer (electrs/esplora) plus a web frontend that turns raw chain data into something a human can browse.
Why you need it: without an explorer your chain is a black box. A user who sends a transaction has no way to confirm it landed except by interrogating a node. The explorer is the single most reassuring thing you can put in front of someone, because it lets them see their transaction confirm — which is exactly the moment a sceptic starts to trust the system.
It also doubles as an operator’s debugging tool: when something looks wrong, the explorer is usually the fastest way to see what the chain actually did versus what you expected.
05 · The faucet — distributing test coins
A faucet dispenses small amounts of testnet coins so people can try the system without first having to mine. It’s a web form plus a service that sends a small amount to a requested address, rate-limited so one person can’t drain it.
Why you need it: on a testnet, a newcomer has no coins and no easy way to get any. The faucet is the on-ramp — it’s how a stranger gets enough valueless test coins to send their first transaction and watch it confirm in the explorer.
This is also the clearest illustration of why testnet framing matters. A faucet giving coins away only makes sense because those coins have no monetary value — it’s a developer convenience, not a giveaway of anything worth anything. The moment a coin had real-world value, “free faucet” would be a completely different and heavily regulated proposition. Our public demo chains the faucet to the rest of the stack: claim test coins, send a transaction, see it confirm — all on testnet.
06 · The website — the front door
The website is where everyone arrives. It’s the marketing site, the documentation, the download links for the wallet, the pool connection details, the explorer link, the faucet form — the surface that ties the other five components into something a person can actually navigate.
Why you need it: the best chain in the world is invisible without a front door. The website is how someone discovers what the project is, downloads the wallet, finds the pool’s Stratum address, and reaches the explorer. It’s also where your framing lives — and on a regulated topic, framing is load-bearing. Every word has to stay factual and software-focused, with no profit, return or yield language anywhere, because the website is the most public surface and the one a regulator would read first.
In a white-label stack the website is the most-rebranded component: the buyer swaps logos, colours, copy and domain to make it theirs, while the structure and the compliance-safe framing stay intact.
07 · How the pieces fit — and why “complete” matters
The components aren’t a menu; they’re a chain of dependencies. The node provides the network. The wallet and explorer both read it through an Electrum-style indexer. The pool feeds blocks into it and lets miners contribute. The faucet seeds new users with valueless test coins. The website is the door all of this is reached through. Remove any single box and something a real user touches stops working — a wallet with no indexer can’t show balances; a chain with no explorer can’t be verified; a network with no faucet can’t be tried.
That’s the real meaning of “complete stack”: not six features bolted together, but six components wired into a system where each depends on the others. When you assemble this from open-source parts, the time sink is rarely any one component — it’s the integration, the chain-specific glue (the genesis ceremony, the address codec, the de-bugged Stratum byte order) and making them all agree.
A pre-built white-label stack is, at its core, that integration already done and proven on testnet. What it gives you is the wired-together system; what stays yours is the decision of what to do with it — and, the moment you run it under your own brand, the responsibility of being its operator. Understanding the six pieces is how you judge whether any stack, mine or otherwise, is actually complete or just a collection of parts.