XRP Ledger

XRP Ledger (XRPL)

The XRP Ledger was launched in the summer of 2012 by a core group of individuals including Arthur Britto, David Schwartz, and Jed McCaleb. They were quickly joined by Chris Larsen and formed a firm by the name NewCoin. After another branding iteration, the firm was renamed to OpenCoin, which lead to its current and most known form of Ripple. The XRP Ledger pre-minted 100B XRP with 20B being delivered to the founders of the project and 80B XRP allocated as a gift to Ripple with much of this amount being placed into a long-term, scheduled escrow release. XRP is the native asset of the XRPL and is the culmination of the protocol’s value.

The founders of the XRPL created it to improve on the original Bitcoin vision as a decentralized payment network. As Bitcoin utilizes the energy intensive Proof of Work (PoW) consensus, the XRPL makes use of a federated byzantine agreement (FBA) consensus protocol resulting in its ability to facilitate decentralized transactions at high speeds of 3-5 seconds. XRPL transactions cost fractions of a penny paid in XRP and can scale to 1,500 transactions per second. The underlying consensus of the XRPL is aptly named the Ripple Consensus Protocol. While the naming of the components and projects involved in the XRPL has been misconstrued overtime, XRP (formerly called Ripples) and the XRP Ledger (composed of the Ripple Protocol Consensus Algorithm) are the preferred terminology at present.

XRP Ledger Consensus Protocol

The XRPL Consensus Protocol was launched as a first of its kind to advance the shortcomings of Bitcoin. This includes some key properties to allow it to scale with minimal energy usage and advance the security properties of the blockchain. There is no need for a central administrator or single point of failure as all valid transactions are processed. Participants are free to leave or join whenever as the ledger can continue to progress. Anyone using the XRPL can agree on the ordering and processing of transactions with all other ecosystem participants. Instead of forking due to lack of consensus, the XRPL would just stall until an agreement can be reached.

Transactions are processed in blocks referred to as ledgers on the XRPL. For every ledger closing, three data fields are stored including the current state of all balances and objects, set of transactions resulting in a ledger closing, and metadata about the current ledger version. Each ledger version is indexed as the protocol progresses to ensure a public history of the XRPL. Every new ledger has stored the history of the entire protocol. Once an 80% agreement between the validators on transaction ordering and processing is made, a ledger is closed and becomes the parent ledger for the next subsequent version.

XRPL consensus utilizes a Unique Node Listing (UNL), which represents a set of chosen validators to progress its state. Each validator has a subset of nodes that have chosen to trust them. Each node and validator is able to freely choose which other nodes and validators they would like to trust, which creates a network of parties working to advance the XRPL. If the 80% agreement is not met, the validators will begin modeling their output for a particular ledger to match its trusted network. Once enough iterations have occurred to reach the 80% consensus requirement, the current ledger will be finalized and a new one will begin processing. This means that as long as less than 20% of the validators are not operating properly the XRPL will advance. Additionally, it also means that the collusion rate among validators would have to reach 80% to institute a double-spend attack.

XRPL Decentralized Exchange (DEX)

One of the often most overlooked aspects of the XRP Ledger is its on-chain, decentralized exchange (DEX). The XRPL DEX provides users with the ability to trade issued currencies, tokenized assets, NFTs, and counterparty-less assets (like XRP) through an order book exchange model. Offers are used on the XRPL DEX as a form of trading orders. Auto-bridging will automatically connect order books with XRP as the intermediary asset when it will reduce costs. Tick size flexibility allows users to set ranges to avoid lack of fulfillment in trading orders over minute variances in exchange rates. The XUMM and GateHub projects have partnered to create an application to trade on the XRPL DEX like you would on any other centralized exchange. 

Issued Currencies

All currency types aside from XRP can be represented as issued currencies on the XRPL with or without a counterparty. For example, Bitstamp issues fiat IOUs so that assets on the XRPL can trade against the US Dollar and be redeemed for real fiat. Additionally, the Flare Network can now issue assets onto the XRP Ledger without a centralized counterparty. Flare Network is the party through which the native version of the issued assets is redeemed from via projects like Trustline. The synergies between the XRPL and Flare Network can provide additional use cases to the XRPL DEX through the trustless issuance of crypto assets onto the XRPL. In both instances of counterparties to issued currencies, these entities issuing assets on the XRPL are referred to as gateways.

Issued currencies generally represent a liability for one entity and an asset for another on the XRPL. These issued currencies utilize a XRPL functionality called trustlines, which track accounting relationships between various parties. Each trustline represents a willingness to hold debt obligations from the gateway parties. The limits on how much a user is willing to hold of these debt obligations can be set and change depending on the trustworthiness of the issuing party (or gateway). Parties who have set up trustlines with one another can utilize a feature of the XRPL termed rippling. The functionality behind rippling allows users with a network of trustlines to move obligations due to one user to other users via this network on behalf of the original user a debt obligation may have been held with.

Paths on the XRPL represent a process for issued currency payments to move through intermediary steps on its way through the transaction between two parties. These paths can be best used to perform cross-currency payments and settle complex, off-setting debt obligations. The rippled API features a built-in pathfinding mechanism on the XRPL to assist users in finding possible paths of payment that can be weighed against each other by cost and efficiency. Paths utilize the XRPL DEX and rippling between user address with same currency trustlines.