Testnet of Testnets design

This is a work in progress.

The idea for the testnet-of-testnets is that it will be one connected Interledger network, meaning (up to some bandwidth limitations, maybe) you can always pay from any account to any account. Accounts will come in two types: on-ledger and off-ledger.

An on-ledger account is tied to one account on one of the testnets (XRP testnet, Ethereum Rinkeby, Ethereum Ropsten, and more to come), and its balance is whatever its balance is according to that testnet.

An off-ledger account is a user's account at a connector. So far there are no connectors yet that offer sign-up, but this is something we're working on. The web interfaces of connectors, as well as their off-ledger API endpoints, will be listed on this wiki.

The idea is you sign up at one of the connector to get your off-ledger account. It will have some fake money in it when it's created. From there, you can make Interledger payments to any other off-ledger account at any of the connectors, and to any on-ledger account at any of the testnets.

If you have a wallet at one of the testnets, with some balance in it, then you can also make Interledger payments from there, as long as you know the address of at least one connector that is at the same testnet as you. The on-ledger interfaces of connectors will also be listed on this wiki.

Connectors are connected to each other via off-ledger trustlines, and make API calls to each other to forward your payment to its destination.

The source code of the connectors we set up will all be available so anybody can set up a new connector and add it to the wiki. To peer with other existing connectors, simply sign up at each connector you want to peer with, and use those credentials to set up your trustline.

When your off-ledger account is empty, you can refill it by making a payment to your self, from an on-ledger account you own, to your off-ledger account. It is useful to always keep a bit of balance in your off-ledger account, because for small payments it's usually cheaper and faster to pay from/to an off-ledger account.

For big amounts where it's ok to wait a bit longer (paying or getting paid), it's probably better to pay from your on-ledger account, because that way you don't have to trust the connector for the full in-flight amount (we call this paying through a trustless connector). Your connector may require you to link your on-ledger wallet to your off-ledger account so that it can charge you a rollback fee if the payment fails. The rollback fee is typically:

destinationAmount = sourceAmount / exchangeRateAtStartTime
refundAmount = destinationAmount * exchangeRateAtRefundTime
rollbackFee = sourceAmount - refundAmount

To give an example, say the rate from XRP to ETH is 100:1. That means you need to pay a source amount of 1000 XRP to get a destination amount of 10 ETH. If that payment fails, and by the time that payment rolls back the price of 1 ETH has dropped from 100 XRP down to 99 XRP, then since the connector has had to keep ETH on hold during this price drop, they cannot give you back the full 1000 XRP you put in; you would only get back:

exchangeRateAtStartTime = 100 XRP/ETH
exchangeRateAtRefundTime = 99 XRP/ETH
sourceAmount = 1000 XRP
destinationAmount = 10 ETH
refundAmount = sourceAmount / exchangeRateAtStart * exchangeRateAtRefundTime =
1000 XRP / (100/1) * (99/1) = 990 XRP
rollbackFee = sourceAmount - refundAmount = 1000 XRP - 990 XRP = 10 XRP

The way this would be implemented would be that the full 1000 XRP rolls back into your on-ledger wallet, but the connector takes the difference of 10 XRP out of your off-ledger account, as a rollback fee.

If you repeatedly pay your connector from your on-ledger wallet, then it may make sense to set up a payment channel from your on-ledger wallet to your connector's on-ledger interface. You can set up this channel on-ledger, and then send claim updates for it to your connector's API. Also, you could ask your connector to set up a payment channel to your on-ledger account (the connector would charge you interest over this channel's outstanding amount), and the connector would then make updated claims available to you from its API.

Further down the line, we can also experiment with more complex payment channels, for instance bi-directional channels, where one party can 'give back' a claim for a higher amount by revealing its claim secret, and conditional payment channels where a claim you send has the same hashlock on it as the transaction that lead to it, so that it automatically becomes useless if that transaction was rolled back.