Coin Selection, Parallelism, and the Architecture of Crypto Throughput
How Bitcoin, Ethereum, and Solana handle transaction parallelism differently, why coin selection matters at exchange scale, and how address design determines whether your platform serves retail and institutional customers equally well.
Engineering leader with 15 years leading engineering organizations across blockchain, digital health, and media platforms.
Parts 1 and 2 covered how exchanges manage the flow of funds between cold and hot wallets and why keeping hundreds of per-asset limits in balance is one of the hardest real-time problems in crypto operations. This post goes one level deeper: what happens after the funds arrive in the hot wallet and a customer requests a withdrawal. Specifically, which address do you use to send it, and why that decision determines everything from throughput to cost to compliance.
Two customers. One platform. Opposite needs.
Every major custodial platform serves two fundamentally different types of customers simultaneously, and their requirements for how funds should be held and distributed are almost entirely incompatible.
High volume, low value. Thousands of withdrawals per minute, each for a small amount. They need fast confirmation and parallel throughput. The platform needs many small addresses available simultaneously so withdrawals do not queue behind each other. Every second of delay is visible and damages trust.
Low volume, high value. A small number of transactions, each potentially worth tens or hundreds of millions of dollars. They need large single-address outputs ready to move immediately without aggregating dozens of small inputs, which would lock all of them simultaneously and slow settlement to an unacceptable crawl.
The same hot wallet has to serve both at the same time. The way funds are distributed across addresses after a cold-to-hot restore determines which customer type is served well and which is not. Getting this wrong has a direct financial cost beyond just customer experience. Every sweep, restore, consolidation, and address restructuring operation required to correct a poorly designed address pool is an on-chain transaction carrying a real fee. At the scale of hundreds of millions of addresses across multiple chains, those fees compound rapidly into a significant operational expense. Getting the architecture right from the start is a financial discipline, not just an engineering preference.
To understand how to solve this problem, you first need to understand how Bitcoin, Ethereum, and Solana each handle transactions differently, because the architecture shapes the solution.
Bitcoin: you own individual bills, not a balance
On Bitcoin, funds do not sit in a single balance the way they do in a bank account. Think of your wallet as a physical wallet holding individual bills. You might have a $10 bill, a $20 bill, and a $50 bill. You do not have “$80.” You literally own three separate pieces of currency. On Bitcoin these are called UTXOs: unspent transaction outputs.
When you want to send $25, you cannot cut a bill. Your wallet has to choose which bills to combine. It might pick the $20 and the $10, spending $30 total. But here is the part many people miss, and where real money has been lost: you must explicitly specify a change address for the $5 remainder to return to you. If you do not specify a change address when constructing the transaction, the remainder does not automatically come back. It disappears entirely, effectively paid to miners as an additional fee.
This is coin selection. For a personal wallet, the software may make a default choice on your behalf. At a custodial platform, there is no default. The engineering team writes the coin selection algorithm that decides which UTXOs to combine for every withdrawal. That algorithm is a deliberate engineering decision with direct consequences for throughput, cost, and privacy.
A well-designed coin selection algorithm achieves three things simultaneously. It minimizes transaction fees by selecting inputs that cover the required amount without unnecessary excess. It avoids creating many tiny change outputs, which fragment the wallet into micro-balances that become harder to deploy efficiently over time. And it protects privacy by not unnecessarily linking unrelated addresses as co-inputs in the same transaction.
That last point deserves more explanation. On a public blockchain, when multiple addresses appear as inputs in the same transaction, blockchain analysts apply what is called the common-input-ownership heuristic: the assumption that all inputs belong to the same controlling entity. Chain analysis firms including Chainalysis use this as a primary clustering technique to map organizational wallet structures. When a custodial platform carelessly combines UTXOs from different operational pools or customer segments in a single transaction, it permanently links those addresses on chain. That linkage reveals internal organizational structure, can expose customer flow patterns, and creates compliance exposure that is difficult to undo. At exchange scale, address hygiene is not optional.
The other critical property of UTXO-based chains is parallelism. If Alice owns UTXO A and Bob owns UTXO B, and both spend their UTXOs in the same block, there is no conflict. Bitcoin nodes can validate both transactions simultaneously because they touch completely different outputs. The throughput problem comes not from Bitcoin’s inability to parallelize, but from the locking constraint at the address level. Once an address is selected as an input for a broadcast transaction, the platform’s internal system marks that UTXO as in-use to prevent a conflicting transaction from being broadcast. This locking is enforced by the platform’s own software, not by Bitcoin itself. At the protocol level, Bitcoin will accept a conflicting transaction into the mempool and let miners decide which one to include. During network congestion, an unconfirmed transaction can remain pending for an hour or more, keeping that UTXO unavailable throughout that window.
Ethereum: one giant spreadsheet, edited sequentially
Ethereum does not use individual coins. Instead imagine one giant spreadsheet with a row for every account and a column for its balance. A transfer simply changes two rows. Alice sends 20 ETH to Bob: Alice’s row decrements by 20, Bob’s row increments by 20.
The problem with parallelizing this is not simple transfers. It is smart contracts. Consider a swap on Uniswap. The transaction calls a router, which calls a pool, which calls a token contract, which calls a fee collector, which may call an oracle. Nobody knows which storage slots will be modified until the code actually runs. The EVM has to execute the transaction to discover what it touches. This makes pre-declaring dependencies impossible for most real-world transactions, which is why Ethereum executes transactions in a strict sequential order, one after another, in a single globally agreed sequence.
For custodial platforms, this means EVM hot wallet throughput scales through address pool size rather than transaction parallelism. Each Ethereum address has its own independent nonce sequence, so the more independent addresses the platform maintains in its hot wallet pool, the more concurrent outgoing transactions it can support without one blocking another.
Solana: declare your accounts, then run in parallel
Solana takes a different approach entirely. Before a transaction is broadcast, the sender must explicitly declare every account the transaction will read from or write to. The validator sees this declaration before execution begins and uses it to detect conflicts without having to run the code first.
If transaction 1 touches Alice’s account and a USDC vault, and transaction 2 touches Bob’s account and an NFT marketplace, there is no overlap. Both run simultaneously on separate CPU cores. If both transactions write to Alice’s account, they conflict and Solana serializes them.
This design gives Solana significantly higher throughput than Ethereum under ideal conditions. The tradeoff is developer complexity: Solana developers must declare all accounts a transaction will touch before sending it, requiring knowledge of the execution path upfront. Ethereum developers simply write the code and let the EVM discover dependencies at runtime.
For custodial platforms on Solana, the parallelism benefit is real but the hot account constraint matters. When many users simultaneously interact with the same liquidity pool or token vault, all those transactions write to the same state and Solana serializes them. Platforms interacting with external liquidity sources have to route and time transactions carefully to avoid these bottlenecks.
Chunking the restore to serve both customer types
With the architectural context established, the chunking problem becomes clear. When 200 BTC arrives from the cold wallet into the hot wallet, it does not land in a single address and sit there. The platform immediately distributes it across multiple addresses in a pattern designed to serve both customer types simultaneously.
For retail throughput, 200 BTC might be split across 100 addresses of 2 BTC each. Each of those 100 addresses can now serve a separate customer withdrawal in parallel. While one address is locked waiting for its transaction to confirm, 99 others remain available. The throughput ceiling rises with the number of independently usable addresses.
For institutional settlement, the same 200 BTC might instead be split across 4 addresses of 50 BTC each. A customer wanting to move 50 BTC uses one address, signs one transaction, and confirms in one step. No aggregation required. No locking of 25 separate 2 BTC addresses simultaneously while the network processes a slow confirmation.
In practice, a single restore is distributed across both address sizes in a ratio calibrated to the platform’s historical mix of retail and institutional volume. The ratio adjusts based on observed patterns, time of day, market conditions, and anticipated demand signals. Getting this ratio wrong has a direct cost: every corrective consolidation or re-chunking operation is another on-chain transaction, another fee, another line added to the cost of doing business. Across hundreds of millions of addresses and multiple chains, those fees compound into a number that matters.
The cost of getting this wrong
Poor coin selection and address design create compounding problems that are not immediately visible but become serious at scale. If address chunking is too coarse for retail volume, thousands of customer withdrawals queue behind a small number of locked addresses during peak periods. Confirmation times stretch. Customers wait. The exchange appears slow even though the funds are fully available.
If chunking is too fine for institutional volume, a 50 BTC withdrawal requires aggregating 25 separate 2 BTC inputs simultaneously, locking all of them for the duration of one slow confirmation while hundreds of retail withdrawals wait behind it. The exchange optimized for one customer type at the direct expense of the other.
Engineering leader with 15 years leading engineering organizations across blockchain, digital health, and media platforms.