---

name: distributed-ledger description: | Distributed-ledger / blockchain architecture in general (engine-agnostic): when a ledger beats a database, consensus families (PoW/PoS/BFT), L1 vs L2 (rollups, channels, sidechains), permissioned vs permissionless, UTXO vs account models, and the scalability trilemma. Architect-level, not coin-specific.

USE WHEN: designing/evaluating a blockchain or DLT system in general, "L2", "rollup", "zk vs optimistic", "PoS vs PoW", "permissioned ledger", "consortium chain", "UTXO vs account", "do we even need a blockchain", token/state design.

DO NOT USE FOR: Bitcoin-specific work (use the bitcoin/* skills); raw consensus internals (use distributed-consensus); ordinary app data (use database / data-intensive skills). allowed-tools: Read, Grep, Glob

Distributed-Ledger Architecture (general)

Generalizes the Bitcoin-specific bitcoin/* skills into engine-agnostic ledger design. For deep Bitcoin/Lightning specifics, defer to those skills.

First question: do you actually need a ledger?

A ledger is an append-only, replicated, tamper-evident log agreed by mutually-distrusting parties. Use one only when you genuinely have: multi-party lack of trust, a need for shared auditable state, and no acceptable trusted intermediary. If a single org controls the data, a normal (possibly append-only/audited) database is simpler, faster, and cheaper — most "blockchain" projects should be databases.

Consensus family (builds on distributed-consensus)

Family	Sybil resistance	Trade-off
PoW	Burn energy	Robust, slow, energy-heavy, probabilistic finality
PoS	Stake capital	Efficient, fast finality, weak-subjectivity/validator-set concerns
BFT (PBFT/Tendermint)	Known validator set	Fast deterministic finality, bounded validators → more permissioned

Permissionless (open validator set) favors PoW/PoS; permissioned/consortium favors BFT.

Layering: L1 vs L2

• L1 = base chain (security + data availability). Scaling it directly hits the trilemma.
• L2 moves execution off L1 while inheriting its security:
  • Rollups post compressed data + proofs to L1. ZK rollups (validity proofs, fast finality, harder to build) vs optimistic rollups (fraud proofs, challenge window/withdrawal delay).
  • State/payment channels (e.g. Lightning) — off-chain bilateral updates, on-chain settlement; great for high-frequency payments.
  • Sidechains — own security, bridged; weaker guarantees.

Other decisions

• Permissioned vs permissionless: trust model + regulatory needs.
• State model: UTXO (parallelizable, privacy, harder smart contracts) vs account (stateful contracts, simpler, sequential nonces).
• Trilemma: decentralization / security / scalability — you optimize two; L2s are the usual escape valve.
• Finality: probabilistic (PoW) vs deterministic/instant (BFT) — affects UX and bridge safety.

Guidance

Single trust domain → database. Multi-party, open → permissionless L1 + L2 for scale. Known consortium → permissioned BFT chain. High-frequency payments → channels. Always justify the ledger over a database first.