For many people, when they think of issuing tokens on a cryptocurrency blockchain, or representing a fiat currency as a stable coin, the first thing that comes to mind is Ethereum. Ethereum is a global, open-source platform for decentralized applications. It has been used for issuing tokens for ICOs; for stablecoins, such as USDT; and even other cryptocurrencies, such as wrapped BTC.
But many people might not be so aware that there is a blockchain that was created pretty much for this exact purpose and does it extremely well – the XRP Ledger. Many people may be aware of XRP, the native token of the XRP Ledger, but might not be so aware of the features the XRP Ledger offers for issuing currencies or that the XRP Ledger has a decentralized exchange built right in. This can offer a better solution to issuing currencies than using ERC-20 tokens.
But first, let's go back a bit and look at the history and origins of the XRP Ledger, as this will help you to understand some of the functionality and ethos behind it.
The development of the XRP Ledger was started in 2011, when three Bitcoin developers David Schwartz, Jed McCaleb, and Arthur Britto set about creating an alternative to Bitcoin. Their view was to create something more efficient than Bitcoin, and that focussed specifically on digital payments. The XRP Ledger launched in mid-2012 and later that year they went on to form a company, Ripple, along with Chris Larsen to further develop and their ideas. The full history of the XRP Ledger and Ripple the company subsequently formed by the developers is detailed on the XRP Ledger website.
The following year, a young Russian developer who was traveling the world, visited San Francisco and stayed with Ripple CTO Stefan Thomas for a few weeks. They spent time discussing the future of cryptocurrencies, and the concept of smart contracts. That developer? Vitalik Buterin.
Vitalik and Stefan took their ideas for smart contracts in radically different directions. Vitalik went on to create a completely new blockchain, Ethereum, in which smart contracts were implemented at layer 1 of the protocol as a core element of the blockchain, along with its own programming language (Solidity) and virtual machine to run the code on. Stefan went on to work on Codius, which was an off-chain smart contract system that could sit alongside the XRP Ledger, keeping the XRP Ledger simpler and enabling Codius to work with any programming language. Work on Codius was paused when it was realized that a cryptocurrency-agnostic way of paying smart contracts would be needed. Focus was shifted to Interledger, which amongst other things, allowed smart contracts to be paid by a variety of cryptocurrencies.
So now you know the history, what features of the XRP Ledger might you be interested in as an Ethereum developer? How do they compare? When would you use each one?
To illustrate this, I'm going to use the example of representing a commodity, coffee, in a tokenized form. We are going to imagine a token that represents 1kg of green (un-roasted) coffee beans. Let's look at some of the features of the XRP Ledger that may be of use for the use-case of issuing and trading an asset such as this on the XRP Ledger.
On Ethereum, if you wanted to represent an asset, such as a coffee token, then you would need to create an ERC-20 token to do so. This involves creating a smart contract, or adapting an existing one, to create your specific named token. The XRP Ledger was specifically designed to be able to handle multiple currencies, or assets as a core function. These are termed Issued Currencies or IOUs on the ledger. To issue a token, all we need to do is pick a currency code to use. For this example, I'm going to use
XCF. The XRP Ledger support standard three-character codes intended for use with ISO 4217, or an extended non-standard code which is represented as a 160-bit hexadecimal string. For this example, to keep things simple I will use the former.
An advantage of this feature is that it is much simpler and easier to issue currencies on the XRP Ledger than it is on the Ethereum blockchain. Whilst you don't have the full power and flexibility of smart contracts to create complex custom financial instruments, it is less prone to accidental security issues. You are not using a general-purpose smart contract language just to issue a token, so there is less scope for error and less attack surface.
Remember, Issued Currencies are sometimes called IOUs. That is because they represent an IOU for some currency, commodity, stock, bond, etc that is not able to be stored directly on the XRP Ledger. You cannot physically store actual coffee beans on a blockchain. So you represent that coffee in tokenized form as an IOU.
Transfers of these IOUs are accounted for on the ledger via a structure called a Trust Line and represent a liability from one side and an asset from another.
If I am a coffee seller and I issue my XCF token on the ledger, then the operation of me sending you 1000 XCF is recorded in the trust line between us as being a 1000 XCF asset to you and a 1000 XCF liability to me.
A trust line has a limit set that represents the maximum amount of an asset an issuer can owe you. As there is no way for a blockchain to enforce the physical settlement of the coffee, a trust line models explicitly the trust you are giving that issuer. If I send you 1000 XCF then you are trusting that I have 1000kg of coffee somewhere that you can redeem those tokens for from me at some later date. You can set the limit on the trust line to whatever you feel comfortable with based on how much you trust me.
One particularly important feature on the XRP Ledger from a compliance point of view is the ability for IOU issuers to 'freeze' the trust line. If, say, my coffee warehouse burned down, then from a regulatory point of view, I'd need to be able to prevent those IOUs for the coffee (that no longer physically exist) from being redeemed. You wouldn't want the holder of those 'bad' IOUs to be able to sell them on. An individual trust line to a holder can be frozen, or all trust lines for that IOU can be frozen globally. This feature can be disabled by an issuer if required. Note, that as this only operates on trust lines and IOUs, it cannot ever be used on XRP itself – XRP cannot be frozen by anyone as it is the native asset of the ledger, and not an IOU. Only the issuer of an IOU can freeze the trust line.
So, we have a token, XCF, that represents our coffee. How do we go about trading that token? How do you, as a buyer, buy 1000 XCF off me? The XRP Ledger has a built-in decentralized exchange. Due to the XRP Ledger using a deterministic consensus mechanism it was the first and is one of only a few blockchains able to run a decentralized, fair, on-chain, limit order book exchange in near real-time.
Offers to buy or sell XCF can be submitted to the XRP Ledger and will sit on the order books awaiting crossing offers to form a trade. Just like on a traditional, centralized, exchange you can create market or limit orders. You can specify additional options such as whether your order should be post-only or immediate fill-or-kill.
Let's say in our example you want to buy 1000 XCF, but you want to pay with USD. You hold some USD IOUs that have been issued by someone else on the XRP Ledger (e.g. Bitstamp). So you place an offer on the DEX for 1000 XCF and you are willing to pay $2.25 per XCF. If there is a corresponding seller who has a matching offer to sell at least 1000 XCF for $2.25 then the trade will execute immediately.
But what if there is someone willing to buy USD for XRP and someone else willing to sell XCF for XRP? The XRP Ledger will auto-bridge those two offers and complete the trade in a single atomic operation. In fact, the XRP Ledger will path-find amongst all the order books to find the best price for you automatically from all the offers. So it could potentially be that you want to buy Coffee with USD, and the actual trade is USD -> XRP -> Coffee.
This feature, vastly increases the potential liquidity on the exchange, as you don't need to have the exact offers on the order books, if you have offers between your asset and XRP, then you have a common bridge asset rather than needing to place orders for every possible combination of assets/currencies.
This also applies to making payments on the XRP Ledger. You can say "I want to send a payment of 1000 XCF but I want to fund it with EUR" and the XRP Ledger will consult the DEX for you and make the appropriate trades automatically to deliver the value in the desired currency.
Rippling is the process of moving debt obligations between entities. Much of this functionality was derived from the original RipplePay project that pre-dates Bitcoin or XRP. This can be used in two main ways:
- If Alice owes Bob $20 and Alice owes Charlie $10, then Bob can pay Charlie by instructing Alice to pay Charlie from some of the money she owes Bob. This can be used to create a social credit system.
- Imagine I am in a cafe and that cafe only accepts cash, and I want to buy a meal for $20, but only have a debit card on me. A third person, Carol, in the cafe wants to buy an iTunes voucher but has cash and no debit card to pay online. If this was represented on the XRP Ledger then: I would be able to use my debit card to buy Carol a $20 iTunes voucher online. In return she'd give me $20 cash. I then use that $20 cash to pay the cafe for my meal. This all works on the basis that $20 in value can be represented in various forms and by different 'issuers' e.g. the Federal Reserve (cash), Apple (iTunes voucher), Chase Bank (debit card). The debts can then be rippled between the different issuers.
More details of this strategy can be found at a great blog post by Richard Gendal Brown (where the above image was taken from)
Like most technology in this space, the XRP Ledger and its uses are continually evolving. Two specific examples that might be of interest to Ethereum developers are:
Hooks are an extension being built for the XRP Ledger by XRPL Labs that enable small snippets of code to run on any transaction. The code is written in any language that compiles down to WASM and executed on a WASM virtual machine on the blockchain. Hooks can accept or block transactions, keep internal state, or even emit new transactions. For example, a user can add a hook to their XRP Ledger account that donates 1% of every incoming payment to a charity. As hooks can keep state, they can also be used to receive data from oracles that can then be acted upon by other hooks.
Flare is an upcoming example of a hybrid of using the benefits of the speed, low latency, and scalability of XRP and the XRP Ledger with a smart contract blockchain that uses the Ethereum Virtual Machine. It would allow a bi-direction bridge between the Ethereum and XRP ecosystems.
One of the main benefits of the XRP Ledger though is the scalability and low fees. Each transaction on the XRP Ledger deterministically settled in just 3-4 seconds, so you don't have to wait for a number of confirmations to be sure the transaction is final. Also, the fees are very low, usually just 12 drops (a drop is 1 millionth of an XRP). At the time of writing that is just 8 thousandths of a cent.
Hopefully, this post has highlighted some of the features built into the XRP Ledger that might be of interest to Ethereum developers when looking for ways to handle issuing currencies, commodities, and assets in a secure, efficient, and decentralized manner.