Design a Blockchain-Based Payment System

Problem statement

Design a decentralized payment network in which strangers transfer value without a central ledger owner. Users hold keys in wallets, sign transactions, broadcast them to peers, and rely on a consensus protocol to impose a single total order on conflicting transfers so double spending is impossible. Validators package transactions into blocks, execute an optional smart-contract layer for escrow and recurring payments, and expose confirmation status to clients that must decide when a payment is safe to treat as final.

The defining constraint is that correctness must survive adversaries and partitions: some participants are Byzantine, the network can split, and every byte propagated costs bandwidth for every honest node. Unlike a payments backend that can retry a database write, a blockchain must make irreversible decisions with only partial information, and once a block is finalized the system must never roll it back without violating its own safety guarantee.

Why this problem is distinctive

A conventional ledger answers 'what is the balance?' from one authoritative database. A blockchain answers it from replicated state that thousands of mutually distrusting nodes converge on. Therefore the design separates four planes: the consensus plane orders and finalizes blocks; the execution plane applies transactions deterministically and meters gas; the state plane stores accounts, contracts, and Merkle proofs; and the access plane serves wallets, merchants, RPC clients, indexers, and fiat on-ramps. A strong interview answer keeps these planes explicit because each has a different consistency model, failure mode, and scaling lever.

Public operating baseline versus design assumptions

Public figures anchor the design space. Bitcoin settles roughly 300,000 to 400,000 transactions per day at a ten-minute block interval, which is single-digit transactions per second, while its UTXO set exceeds one hundred million entries. Ethereum produces a block every twelve seconds and settles on the order of one to two million transactions per day with finality through Casper FFG epoch checkpoints. Solana publishes sub-second slot times and sustains thousands of non-vote transactions per second using proof-of-history plus Tower BFT. Visa, as a centralized contrast, reports capacity in the tens of thousands of transactions per second. Those are cited public characteristics, not requirements for our fictional chain.

For capacity planning this answer explicitly assumes a payment-optimized proof-of-stake chain with 50 million registered wallets, 8 million settled transactions per day, a sustained peak of 3,000 on-chain TPS, an additional 40,000 TPS absorbed by payment channels and rollups, 150 validators with BLS aggregate votes, and two-second deterministic finality at p99. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

1. Consensus plane: leader election or rotation, proposal, voting, quorum certificates, finality, slashing, sync.
2. Execution plane: deterministic VM, gas metering, parallel or serial application, receipt generation.
3. State plane: account or UTXO database, Merkle trie roots, snapshots, pruning, archive tiers.
4. Access plane: P2P gossip, RPC gateways, mempool admission, wallets, indexers, bridges, compliance rails.

Keeping the planes separate lets the access plane degrade (slow RPC, stale indexers) without weakening consensus safety, and lets execution upgrade (parallelism, new VM) without re-litigating finality.