A few weekends ago, I was privileged to attend the ILP Summit 2019 put on by the community developing the Interledger Protocol. The Interledger protocol (hereafter ILP) is intended to facilitate a degree of ledger-agnosticism for users of payment networks, by allowing both the sender and receiver of a payment to use the individual ledgers of their choice, with the ILP network handling any routing and conversion activities needed to make transaction happen. Example: a customer may wish to pay with BTS, but the merchant wishes to receive BTC. Interledger aims to create a network that satisfies both parties.
An interesting aspect of ILP is that the ledgers involved need not necessarily be crypto ledgers or blockchain ledgers. They can as well be fiat ledgers mediated by traditional banking networks.
ILP presents numerous interesting opportunities and use cases for BitShares, but understanding all possible use cases is daunting and was not my goal. I focused on a more narrow question: can ILP streamline, improve, or possibly revolutionize the "gateway" mechanism for getting assets (and users) onto and off of the BitShares chain? Or in other words: Can we build a better gateway?
The obvious motivation here is that the easier it is to acquire assets on the chain, the easier it is to onboard new users and get them using the BitShares platform right away. And because ILP is unique in attempting to connect both traditional fiat and blockchain networks, the ideal I have in mind is to easily use a fiat bank account to securely and reliably purchase the corresponding stable coin to use on the DEX. Example: directly purchasing bitUSD via an ACH pull against a USD bank account. Can this type of transaction be made, if not perfectly trustless, at least more trustless, via ILP?
The summit was attended by a few dozen participants who convened from four separate continents in order to gather in San Francisco for the two day event. There was a heavy contingent from the broader Ripple community, as several of the companies and projects represented, including the Interledger project itself, are spin-offs of the original Ripple project. The summit was developer-focused, with a goal of inspiring or supporting new projects, and facilitating new ledger integrations with the Interledger network.
This is not an exhaustive list but includes several of the companies and projects that I found most interesting. In no particular order: (All company descriptions are based on my own recollection and might not be 100% free of misrepresentations.)
- Coil — https://coil.com — Coil is focused on using the streaming payment features of ILP to facilitate web monetization. For example: making continuous micro-payments to a website per second spent browsing, for an advertisement-free experience.
- Xpring — https://xpring.co — Xpring is a contributor to the open-source Interledger Protocol and an incubator for companies and projects developing on the XRP ledger and ILP ecosystem.
- Kava — https://kava.io — Kava is a developer of "Interledger solutions." From their FAQ: "Kava builds Interledger integrations and connectivity with the world’s premier blockchains, wallets, and exchanges." At the summit, Kava demonstrated Switch, an "Interledger wallet for non-custodial crypto trading and streaming payments." It offered functionality somewhat like ShapeShift.io, but instead of relying on a centralized third-party, it essentially achieves currency exchanges by sending an ILP payment to yourself, specifying the desired currency to receive.
- Strata Labs — https://www.stratalabs.io — Strata is a connector operator on the ILP network and provides tutorials on their site for getting your own connectors up and running.
- Stronghold — https://stronghold.co — Stronghold is an issuer of fiat-backed stable coins that are connected to the ILP network. They demonstrated Stronghold USD (USDS) at the summit.
ILP has gone through quite a process of revision, refinement, and simplification to arrive at a bare-essentials spec with additional details and features to be defined at layers above and below the ILP protocol layer. They've borrowed heavily from the design of Internet specs, including an analogy to the OSI Networking model. The current version of the spec is referred to as ILPv4. The spec is very well articulated in a collection of RFC documents maintained by the Interledger project.
ILP has a lot of nice features, but the two most significant to me were:
-
Route Finding: Alice wants to pay in ETH, but Bob want to receive BTS. Bob gives Alice a "payment pointer" that specifies what he wishes to receive and how he's connected to the network. Alice then makes her own connection to the Interledger Network, where ILP allows for the discovery of a route across whatever intermediary hops are needed to move the payment and effect the conversion of currency.
-
Packetized payments: This allows a bigger payment to be broken up into potentially millions of smaller micro-payments, and streamed to an end point. This enables "cool" features like paying for a video per second viewed (and not a penny more!), but also opens up the route finding in a network where individual connector nodes may be maintaining payment channels with each other with only limited collateralization. Thus it may be difficult to find a route that can handle a single "big" payment, but finding a route than can handle multiple iterations of "small" payments may be trivial.
The fundamental element on the Interledger network is the connector node. A connector node maintains connections between any or all of the following:
- Other connector nodes
- People making payments
- People receiving payments
- The underlying ledgers on which those connectors operate.
Some connectors maintain connections on multiple ledgers and therefore allow for exchanges between currencies.
Right now the Interledger network has "connections" into only a very few blockchains. These include XRP, XLM, BTC (Including the Lightning Network), and Ethereum. Perhaps a few others. If we were to build a connector plugin to the BitShares network, we would be among the "early adopters" of the ILP, and this could give a competitive advantage to BitShares.
"If we were to build a connector plugin to the BitShares network, we would be among the "early adopters" of the ILP, and this could give a competitive advantage to BitShares."
- Strata Labs' tutorial on "Running a Node"
- Rafiki: a new Interledger Connector Implementation — An effort from the Coil team to offer an improved Connector code base.
For an ILP connector to be able to route payments into or out of BitShares, a "ledger adaptor" needs to be written. Once written, connector operators will be able to offer connections originating in or terminating in the BitShares blockchain. Or in other words, it will become possible to route payments to and from BitShares user accounts.
A question I haven't grasped a full answer to yet is exactly what new features the BitShares protocol will need in order to offer full connectivity to the Interledger, although I think I've developed a basic understanding. And if I've understood correctly, then it seems that we could offer partial connectivity even now, with no additional protocol features, allowing for basic transfers in and out of BitShares. This would enable simple use cases, but restrict advanced use cases. (Principally, sub-dust-limit packets would be impractical to route, since each packet would imply a chain operation and associated fee. To be practical, payments would have to use a small number of macroscopic sized packets, rather than a large number of micropayment packets.) However, (and if I'm understanding correctly), full interoperability would become possible if and when BitShares implements Payment Channels. Payment channels would allow settlement claims to be negotiated off-chain, and therefore enable streaming micropayments with final settlement to the chain only happening at channel close.
Developers working on a BitShares ledger adaptor may find the following resources useful:
- This discussion of "Settlement Engines"
- (Note that the terminology here is in flux, as the Interledger community is working on modularizing the connector architecture, and separating connector logic from settlement logic. The terms "plugin", "settlement engine," and "ledger adaptor" are at times used to represent the same thing.)
There are, of course, existing gateway providers that offer fiat-to-on-chain asset conversion. And most (all?) of them are respected and have good track records. However, I personally have always been hesitant to use the fiat gateway services, preferring instead to acquire bitcoin or another asset and then "gateway-in" through that, even though it's more work. I'm sure others have felt this same hesitancy.
In what follows I describe a way to remove the trust nucleus of handling fiat from the gateway and place it in a different location. (It is impossible, of course, to make a fiat transaction completely trustless, but we can focus on isolating and limiting our exposure to the counterparty risks.)
A few sections above I had mentioned Stronghold, a company providing an Interledger-connected USD stable coin (USDS). That actually was not the most interesting aspect of what they offered. In fact, USDS is a permissioned coin, and as such might otherwise be regarded as "uninteresting" to some in the crypto community. What was interesting was that they offered an API into the traditional banking world that business customers (e.g. the gateways) could utilize. Instead of touching fiat directly, the gateway debits a customer via an API call. Instead of trusting the gateway to handle the fiat transaction, the trust nucleus is moved to a company whose entire business model is establishing themselves as a trust-worthy "crypto wrapper" around a fiat asset. Additionally, although the customer has in a sense bought USDS, upon clearing the fiat transaction the USDS will near-immediately be transmuted into the desired final asset through the ILP network, thus limiting the customer's temporal exposure to the trust nucleus.
To my knowledge, Stronghold is the first and so far only company offering an Interledger-connected USD stable coin with an API into the traditional world of ACH and Wire transfers. I assume there will eventually be competition in this space. Thus in my designs and descriptions here, I am using their company name as an exemplar of just such a service. What I am writing here is about getting the design articulated, and is NOT meant as any kind of endorsement or recommendation of any particular companies or products.
Now here's how a BitShares Gateway could use a service like Stronghold's:
We'll describe a "BitGateway" for converting fiat USD into the market-pegged bitUSD on the BitShares platform. Note already that we differ from the existing gateway model in that we aren't relying on a gateway coin or on any external reserves held by the gateway to back such a coin. We are going directly to the bitAsset!
The BitGateway (for lack of a better name) could offer a friendly interface in which the user could specify how much bitUSD they wish to purchase. The BitGateway then asks the user to authorize an ACH pull for the amount (plus appropriate fees) in fiat. Upon authorization, the BitGateway initiates the ACH pull via Stronghold's API, rather than interacting with the ACH network themselves. (The gateway never touches actual fiat.) As part of that API call, an ILP Payment Pointer is provided specifying where that payment is ultimately intended to end up: the user's BitShares account, as bitUSD. When the ACH transaction clears, the USDS is created by Stronghold, but then immediately routed through the Interledger network, and the user receives their bitUSD. Thus, although the user indirectly (and perhaps unknowingly) used USDS to facilitate the transaction, the user does not hold USDS, nor do they need to trust in it's continued solvency. It's merely a way to connect the bitAsset world to the corresponding fiat world, and removes any concerns they may have about whether the gateway company is holding adequate reserves.
ILP offers a very promising, refined protocol with numerous potential use cases for ledger-to-ledger interoperability. Integration with ILP could allow BitShares to become more useful, since users of BitShares could more easily transact with non-users of BitShares, and new users of BitShares can be more easily on-boarded via refinements to the gateway mechanism. It appears that basic-level integration could occur right away if an appropriate "ledger adaptor" is developed. Additional features unlocking the full potential of packetized streaming payments could be delivered if the BitShares protocol adapts a "layer 2" solution such as payment channels.
Christopher Sanborn is a developer with the BitShares Core Development Team. He has a background in scientific computing and physical simulations. He holds a Ph.D. in physics and is passionate about technologies that makes the world a better, freer place.