Overview

The XRP Ledger (XRPL) is a blockchain built for one job: moving value. Sending money, issuing currencies, and trading assets all settle in 3–5 seconds for a fraction of a cent.

By the end of this module you'll understand where the XRPL came from, how accounts and reserves work, how every native feature is reachable through a single API, and how the network agrees on a new ledger every 3–5 seconds without mining.

A short history: built for payments

By 2012, blockchains had proven that strangers could share a tamper-proof ledger, but the first generation was awkward for everyday money: proof-of-work burns enormous energy and takes minutes to settle a payment with confidence. The XRP Ledger launched in 2012 to fix exactly those limitations of crypto and traditional fiat rails, specifically for financial use cases, above all payments.

Three names get tangled together, so keep them distinct:

The XRP Ledger (XRPL) is the Layer-1 blockchain itself (a base network, not built on top of another chain), open-source, decentralized, and maintained by a global community.
XRP is the ledger's native asset, the way ETH is native to Ethereum. It pays transaction fees, deters spam, and acts as a bridge currency inside the ledger's built-in exchange, which you will meet in the DeFi module.
Ripple is a company that builds payment products on top of the XRPL. It's one of many contributors, not the ledger, and not its owner.

The ledger has run continuously since 2012 without a failure or breach, settling billions of transactions: proof in production that a payments-first design can be both fast and durable.

The account and reserve model

Content by Chris Dangerfield, licensed under CC BY-SA 4.0

To do anything on the XRPL you need an account, identified by an address (a string starting with r, like rPT1S...). Under the hood an account is a key pair: the address is derived from the public key, and the private key is what signs, and therefore authorizes, every transaction from the account.

You already saw this in practice at the faucet: an address doesn't exist on the ledger until it's funded. To stop the shared database from filling with empty accounts, the XRPL makes every account hold a small amount of XRP it can't spend away: the reserve. On Mainnet today that's a base reserve of 1 XRP to keep the account alive, plus an owner reserve of 0.2 XRP per object the account owns (a trust line, an escrow, an offer, an NFT). The reserve isn't a fee paid to anyone: it stays in your account, simply locked while you hold those objects and released when you remove them.

The practical consequence: you create an account by sending it enough XRP to meet the reserve, and there's no separate "register" step. It's also why your spendable balance is never quite your whole balance.

The architecture: one API for everything

The XRPL was designed, from day one, around moving value: sending money, issuing currencies, and trading assets, all settled in 3–5 seconds for a fraction of a cent. That focus shaped the architecture: much of what you would normally bolt on with smart contracts (a token standard, an exchange, escrow) is already built into the protocol itself.

This has a very practical consequence: the whole ledger is reachable through a single API. On most chains, building a product means stitching together disparate systems: one contract for tokens, another for the exchange, an indexer to read state. On the XRPL you connect to one endpoint and every native feature is already there:

Account management: create and configure accounts.
Monetary emission: issue your own tokens and currencies. The XRPL was the first blockchain to support tokens beyond its native asset, years before token standards appeared on other chains.
Payments: send XRP and issued tokens in seconds.
Non-fungible tokens: mint and trade NFTs natively.
Decentralized exchange and AMM: place offers and trade against liquidity pools.
Decentralized identifiers: anchor digital identity on the ledger.
Oracles: read real-world data published on-chain.

The XRPL was deliberately designed in this direction to make it convenient for companies. Because the features are native and sit behind one endpoint, a business does not need to hire a specialized Web3 engineer to ship a decentralized application. The API is available through seven SDKs and libraries, covering languages such as JavaScript, Python, and Java, so a team that already has a stack built in one of them can integrate blockchain and decentralized features into its own tooling quickly, with a first working payment fitting in a few lines of code.

Consensus without mining

So how does the network agree on a new ledger every 3–5 seconds without mining? The XRPL uses the XRP Ledger Consensus Protocol, whose core idea is the opposite of an anonymous mining race: agreement comes from a set of known, trusted validators.

Each server keeps a Unique Node List (UNL): the validators it trusts not to collude. Each round, validators propose the transactions they think belong in the next ledger and compare proposals over several quick passes until a strong supermajority agrees. The bar is high: more than 80% of trusted validators would have to collude to confirm an invalid transaction, and the network keeps progressing as long as fewer than 20% are faulty. Validators are run by a diverse, transparent set of universities, exchanges, businesses, and individuals.

The payoffs are exactly what a payments network wants:

No mining: no electricity burned in a competitive race, so a very low carbon footprint.
Fast finality: a ledger closes every 3–5 seconds, and once validated the result is final, with no waiting for confirmations to pile up.
Low cost: fees are a tiny fraction of a cent, paid in XRP mainly to deter spam.

Every transaction you submit for the rest of this journey is settled by this same protocol.

A quick wrap-up