Blockchain in Payments
Working principles, network types, consensus mechanisms, DeFi protocols, stablecoins, and CBDCs — a technical guide to blockchain technology and its integration with modern payment infrastructure.
How a Blockchain Works
Every blockchain shares the same core mechanics: transactions are broadcast to a peer-to-peer network, batched into blocks, secured by cryptography, and accepted through a consensus process. Here is how each layer works.
Live Block Chain
0000…f8e20000…3c191,9871,291,0340000…a3f10000…f8e22,3411,847,2930000…7c2a0000…a3f13,0123,921,8470000…7c2a???????Each block references the previous block's hash — forming a chain where altering any block invalidates every block after it. The rightmost block shows the live PoW simulation below.
0000841235 · prev:0000…7c2a · merkle:…0a7f3bc129e4d8f0123456789abcdef01Block Anatomy
0000…a3f10000…a3f117200000002048394756target < 0000…7a3c…8d010000…7c2aThe Merkle root commits every transaction to a single 32-byte hash. The Prev Hash links blocks — changing Block N breaks Block N+1's reference, invalidating the entire chain forward.
Merkle Tree — Transaction Commitment
Hash(AB + CD)H(TxA + TxB)H(TxC + TxD)Proving Tx C is in the block requires only Hash(TxD) + Hash AB + the Merkle root — logarithmic proof size, no full block download needed. This is how SPV wallets verify payments.
Transaction Lifecycle
Signing
The sender constructs a transaction, hashes it, and signs it with their private key using ECDSA (secp256k1). The signature proves ownership without revealing the key. The transaction includes a fee to incentivise inclusion.
Broadcast
The signed transaction is broadcast via P2P gossip. Each node relays it to peers. Within seconds it propagates to most of the network. Nodes validate the signature, check for double-spends, and verify the fee is sufficient.
Mempool
Valid transactions sit in each node's mempool ordered by fee rate. Miners/validators pick transactions for the next block. During congestion, low-fee transactions may wait hours or be dropped.
Block Inclusion
A miner/validator assembles transactions into a candidate block. In PoW: hash the header with different nonces until meeting the difficulty target. In PoS: a validator is pseudo-randomly selected to propose the block.
Validation & Propagation
Other nodes independently validate the block: correct proof, valid signatures, no double-spends, correct Merkle root. They add it to their chain and relay it. Forks resolve by the longest/heaviest chain rule.
Confirmations & Finality
Each additional block is one confirmation. Bitcoin: 6 confirmations ≈ 60 min. Ethereum PoS: economic finality in ~12.8 min. XRPL/Stellar: absolute finality in 3–5 s.
Consensus Mechanisms Compared
Proof of Work (PoW)
Nodes compete to find a nonce making SHA-256(block) < target. Winner earns block reward. Security from computational cost — 51% attack requires majority of global hash power.
Proof of Stake (PoS)
Validators lock native tokens as stake. Block proposer selected pseudo-randomly weighted by stake. Dishonest validators lose their stake (slashing). 99.95% less energy than PoW.
Byzantine Fault Tolerance (BFT)
A known set of validators vote on each block in rounds. Tolerates up to 1/3 malicious validators. Achieves instant finality — no probabilistic confirmation needed.
Proof of History (PoH)
A verifiable delay function creates a global clock of events, allowing validators to agree on ordering without waiting for network round-trips. Combined with PoS for block production.
Accounting Models: UTXO vs. Account-Based
UTXO Model (Bitcoin)
Every transaction consumes one or more Unspent Transaction Outputs (UTXOs) as inputs and creates new UTXOs as outputs. Your "balance" is the sum of UTXOs locked to your addresses.
- ✅ Enables parallel transaction validation
- ✅ Clear audit trail — trace any coin's history
- ✅ Privacy: each address used once ideally
- ⚠️ Complex for smart contracts
- ⚠️ Coin selection logic needed in wallets
Input: UTXO [0.5 BTC] + UTXO [0.3 BTC]Output: 0.7 BTC → Bob, 0.09 BTC → changeFee: 0.01 BTC (to miner)Account Model (Ethereum)
Each address maintains a balance and a nonce (transaction counter). Transactions debit and credit balances directly, like a bank account. Smart contracts are also accounts with code and storage.
- ✅ Simpler for smart contract interaction
- ✅ Easier to reason about balance state
- ✅ Natural fit for ERC-20 token ledgers
- ⚠️ Nonce ordering — transactions must be sequential
- ⚠️ Harder to trace original coin provenance
Alice balance: 1.0 ETH → 0.3 ETHBob balance: 0.0 ETH → 0.7 ETHFee: 0.002 ETH (gas burned + tip)