Bitcoin shipped in 2009 with a deliberately small design surface: a UTXO ledger, a stack-based script with no loops, and a fixed issuance schedule. Everything that followed in crypto can be read as a response to one of those three constraints — throughput, expressiveness, or monetary policy. This article walks each constraint, the systems built on top of it, and the trade-offs you inherit when you pick one. The goal is not to rank chains. It is to give you a mental model of the design space so you can evaluate the next protocol on its actual properties rather than its marketing.
Why Bitcoin's throughput is fixed
Bitcoin processes roughly seven transactions per second on the base layer. That number is not arbitrary. It falls out of two parameters: a 1 MB block size (later softened to ~4 MWU with SegWit) and a 10-minute average block interval. Increase either and you raise the cost of running a full node, which concentrates validation among fewer operators and weakens censorship resistance. The throughput ceiling is the price Bitcoin pays for letting a Raspberry Pi verify the chain.
The consequence shows up as fee markets. When mempool demand exceeds block space, miners pick the highest-fee transactions and the rest wait. In late 2017 and again in 2024, median fees crossed $30 and confirmation queues stretched to days. For a payment system, that is a hard product limit. Anything more frequent than weekly settlement needs a different layer.
Layer 2 (L2) is the umbrella term for systems that move execution off the base chain while inheriting some portion of its security. The base layer becomes a settlement court; L2s handle the day-to-day traffic and periodically post receipts. Three patterns dominate:
- Payment channels (Lightning Network). Two parties open a channel by locking funds in a 2-of-2 multisig output. They then exchange signed off-chain updates that reassign the balance. Only the opening and closing transactions touch the base chain. A merchant and a customer can settle thousands of micropayments for the cost of two on-chain transactions.
- Sidechains (Liquid, Rootstock). Independent chains with their own validators, pegged to Bitcoin via a two-way bridge. Throughput and programmability are higher, but security comes from the sidechain's validator set, not Bitcoin's miners.
- Rollups (dominant on Ethereum, emerging on Bitcoin). Transactions execute off-chain, but the resulting state transitions are posted to the base layer along with either a validity proof (zk-rollup) or a fraud-proof window (optimistic rollup). Security is anchored in the base layer; throughput is bounded by data availability, not execution.
Each Layer 2 trades a specific property for throughput: channels trade routing convenience, sidechains trade validator security, rollups trade latency or proving cost.
The pattern to internalize is that "scaling" is not a single problem. It is execution, data availability, and settlement, each of which can be moved independently. Modern designs (modular rollups, app-specific chains) compose these layers explicitly.
Smart contracts and the programmability gap
Bitcoin Script is intentionally non-Turing-complete. There are no loops, no persistent storage between transactions, and no way for one script to call another. The design prevents infinite computation and unbounded state growth, but it also means anything beyond "release funds if these signatures verify" requires an off-chain protocol or a hard fork.
Ethereum's EVM replaced Script with a stack machine that has loops, persistent contract storage, and inter-contract calls, metered by gas. A transaction declares a gas limit and price; each opcode consumes gas; the transaction reverts if it runs out. Gas is the mechanism that lets a Turing-complete machine exist in an adversarial network — it bounds computation economically rather than syntactically.
The shift from Script to EVM is roughly the shift from a calculator to a spreadsheet runtime. You can now encode application logic — order books, lending positions, collateral liquidations — directly into the consensus layer. Three primitives became possible:
- Decentralized exchanges (DEXs). Automated market makers like Uniswap replaced order books with a constant-product invariant (
x * y = k). Liquidity providers deposit token pairs; traders swap against the pool; prices adjust algorithmically. The matching engine is a few hundred lines of Solidity. - Lending protocols. Compound and Aave hold deposits in pooled contracts and let users borrow against collateral. Interest rates are functions of utilization. Liquidations are open to anyone — if a position falls below its collateral ratio, a third party can repay the debt and claim the collateral at a discount, triggered by a single on-chain call.
- Composability. Because contracts can call other contracts atomically within a single transaction, a user can flash-borrow USDC, swap it for ETH, deposit it as collateral, and borrow against it — all in one transaction that reverts if any step fails. This is the property no traditional financial system has.
The trade-off is attack surface. Bitcoin's script either verifies or it doesn't; there is no reentrancy bug in a stack machine without external calls. EVM contracts have shipped exploits that have cost over $3B cumulatively (The DAO, Parity multisig freeze, Ronin Bridge, Wormhole, Euler). The bugs are usually in application code, not the EVM itself, but the surface only exists because the platform allows it.
Token economics beyond fixed supply
Bitcoin's monetary policy is a constant: 21 million coin cap, a halving every 210,000 blocks (~4 years), no upgrade path that touches issuance. It is the simplest possible policy and one of the most defensible — there is no decision-maker to capture and no rule to renegotiate.
Most other tokens cannot use that policy because their purpose is not "be money." A stablecoin needs to track a fiat unit. A staking token needs to fund validator rewards. A governance token needs to align long-term holders with protocol performance. Each requires a different mechanism for issuance, redemption, and incentive alignment. The discipline of designing those mechanisms is what people now call tokenomics.
Stablecoins are the clearest example. The goal — a token worth $1 — can be reached three different ways, each with a different failure mode:
| Approach | Stability mechanism | Trust model | Capital efficiency | Notable failure mode |
|---|---|---|---|---|
| Fiat-backed | 1:1 fiat or T-bill reserves at a custodian | Trust the issuer and its banks | High (1:1) | USDC depeg during SVB collapse (2023) |
| Crypto-collateralized | Overcollateralized debt positions (e.g. DAI) | Trust the smart contract and oracles | Low (150%+ collateral) | Liquidation cascades in fast crashes |
| Algorithmic | Mint/burn against a paired volatile asset | Trust the economic incentive loop | High (no collateral) | UST/LUNA, ~$40B wiped in May 2022 |
Governance tokens distribute voting rights over protocol parameters: fee tiers, asset listings, treasury spending. The intent is to push control away from a founding team. The actual outcomes are mixed — token-weighted voting tends toward plutocracy, voter turnout is often below 10%, and protocols frequently route real decisions through informal forums and core contributor signaling. Good designs use delegation, time-locked voting power, and explicit separation between routine parameters and constitutional changes.
Proof-of-stake issuance is another departure from fixed supply. Ethereum's issuance varies with the amount of ETH staked: more stake means lower per-validator yield, fewer rewards minted, sometimes net-deflationary supply once EIP-1559 burns are accounted for. The policy is not fixed; it is a control loop targeting a specific staking ratio.
The recurring failure mode across all of these is unmodeled tail risk. UST worked until reflexivity went the wrong way. Algorithmic systems that pass simulation often fail when real liquidity dries up, oracle prices lag, or governance proposals are exploited. If you are designing a token, the question is not "does the model balance in equilibrium?" but "what happens at the worst hour of the worst day?"
What this means for builders
The choice of chain is now a choice of trade-off profile, not a choice of brand. A short checklist:
- Pick the security model before the chain. Decide what you need from base-layer settlement (full Bitcoin/Ethereum security, a rollup with a 7-day exit window, a sidechain with a third-party validator set) and let that constrain the candidate list. Going the other direction — picking a chain and rationalizing the security model — is how teams end up bridged into validator sets they cannot name.
- Treat L2 categories as different products. Channels, sidechains, and rollups all "scale Bitcoin" or "scale Ethereum," but they have different UX surfaces. Channels need always-on liquidity routing. Optimistic rollups have withdrawal latency. zk-rollups have proving costs that show up in fees. Match the topology to the workload.
- Budget for smart-contract risk explicitly. If your protocol holds user funds, the dominant operational risk is a contract bug, not chain failure. Multi-audit, formal verification on critical invariants, a public bug bounty, and a tested pause mechanism are table stakes. Assume you will need to upgrade and design the upgrade authority before launch.
- Stress-test token mechanics adversarially. Run your model at a 90% drawdown, at a single holder controlling 30% of supply, at oracle latency of several minutes. If a parameter only works inside a narrow band, document that band and decide who is on call when it breaks.
- Don't assume newer is better. Bitcoin's narrow scope buys it properties — predictable settlement, minimal contract risk, a clear monetary policy — that fuller platforms cannot match. For some workloads (long-horizon settlement, reserve assets, censorship-resistant payments) those properties matter more than expressiveness.
Conclusion
The three constraints — throughput, expressiveness, monetary policy — are not bugs in Bitcoin's design. They are coordinates in a trade-off space that every subsequent chain has had to position itself within. Layer 2s relax throughput at a security or latency cost. Smart contract platforms relax expressiveness at a complexity cost. Flexible tokenomics relax monetary rigidity at a governance and modeling cost.
The useful frame for engineering work is not "Bitcoin vs. Ethereum vs. the next chain." It is: which constraints does my workload actually require relaxing, what am I paying for the relaxation, and do I understand the failure mode well enough to be on call when it triggers. Most production mistakes in this space come from teams that picked a platform before they answered those questions.