A PROPOSAL ON HOW TO ISSUE AND REDEEM ASSETS FROM FLARE ON THE XRP LEDGER IN A TRUSTLESS MANNER.

OBJECTIVE.

Currently very few assets on the XRP Ledger can be said to be trustless. Almost all Issued Currencies (IC’s), often referred to as “IOUs”, are dependent on the issuer to settle that IOU with the claimant in the real world. This means the user of that currency has to trust that the issuer won’t default. It further means that a currency representation, say a “dollar”, issued by a party A is not perfectly exchangeable for another “dollar” issued by a party B. This lack of fungibility is due to divergence between the risk profiles, charges and other metrics of different issuers.
This brief summary aims to put forward a high level concept for using Flare to trustlessly issue highly fungible assets on the XRP Ledger. In doing so, the Flare Network would not just be providing additional utility for the digital asset, XRP, but would also be providing utility directly to the XRP Ledger.

DEFINITIONS:

Issued currency (IC):

Issued currency is the term used in the XRP Ledger for any token that is not XRP. This can theoretically represent any asset such as a currency, a share, a piece of art etc. We will refer to this throughout as an IC.

Trustless:

The definition of trustless used here is that if you own an IC on the XRP Ledger, that conforms to the details set out below, you do not need to trust anyone in order to be able to redeem that currency on Flare.

Trustlines:

A trustline on the XRP Ledger is extended by an account to an issuer and has an amount associated with it. If account A extends a trustline to issuer 1 for $50 this means that account A will allow issuer 1 to owe them a maximum of $50.

Master Key pair:

The cryptographic key pair intrinsically linked with an account.

Regular Key pair:

An alternate key pair that may be optionally associated with an account and used to sign transactions.

Rippling:

A system of atomic net settlement used on the XRP Ledger enabling payments between parties who do not trust the same issuers.

Flare State Connector:

A decentralised system that allows Flare to “digest” the state of the XRP Ledger.

Account_One:

A “blackhole” account on XRP Ledger.

Proposal Pre-Amble:

For the purposes of this document let us proceed with the scenario where FXRP (XRP on Flare) has been locked in a collateralized debt position (CDP) smart contract to collateralize the issuance of a dollar pegged stable token. The Flare Time Series Oracle provides an XRP/USD price for this CDP based asset. This system would be similar to Maker and the Dai token, except the collateral is XRP based. Instead of Dai let’s call this asset USF (US Dollar Flare).

The objective is then to the issue an IC on the XRP Ledger representing USF such that there is no reliance on a centralized third party when trading and redeeming back to Flare. IE A trustless issuance and  redemption of USF IC’s on XRP Ledger. Let’s call this IC, USFX.

ISSUANCE PROCESS:

Let’s say Alice holds 100 USF on Flare. Alice will complete the following steps to trustlessly issue USFX on the XRP Ledger.

A) Alice sets up two XRPL accounts allowing her to issue USF on XRPL as USFX. These two accounts are an issuing account and a receiving account.

B) Alice locks her 100 USF in a smart contract on Flare. In the process of doing so Alice also submits the issuing address on the XRP Ledger to the smart contract.

C) Alice issues USFX on the XRP Ledger using the process set out below.

The smart contract on Flare is designed to achieve 3 things: a) Penalize Alice if she follows the issuance process incorrectly. b) Safely hold the USF such that it is available for redemption to any Flare address upon demand. (See redemption below) c) Maintain a list of valid XRPL issuer accounts.

To successfully complete the issuance process on the XRP Ledger, Alice now needs to undertake the following six steps:

  1. Set a trustline from her receiving account to her issuing account for 100 USFX.
  2. Set the issuing account to the “Default Ripple” Flag.
  3. Issue precisely 100 USFX from her issuing account to her receiving account.
  4. Ensure there is no signer list set on the issuing account.
  5. Set the regular key of the issuing account to Account_One.
  6. Disable the issuing account Masterkey using the Masterkey.

Flare’s state connector will observe the actions taken by Alice’s issuing account and if all the steps above are completed correctly the smart contract system on Flare will add Alice’s XRPL issuing address to the list of valid addresses.

Alice now has 100 units of USFX in her receiving address, her USF on Flare is locked and her issuing address is incapable of issuing any more USFX, or indeed of signing any transactions (steps 4 – 6). Other parties on the XRP Ledger can reference the “valid list” trustlessly maintained by the smart contracts on Flare and extend a trustline on the XRP Ledger to Alice’s issuance account for the amount of 100 USFX. Alice’s USFX can now be used trustlessly as currency on the XRP Ledger. Her USFX can be traded around the XRP Ledger and the owner of it does not need to rely on Alice in anyway, including not needing to rely on Alice to honor redemption into the underlying asset (USF) on Flare. Redemption is now managed in a decentralized and trustless manner by the Flare network.

ISSUANCE FAILURE:

If Alice fails somewhere in the issuance process her issuance address is not added to the valid list. Her USF will be returned, potentially with a penalty.

REDEMPTION:

1) To redeem USFX on XRPL for USF on Flare a holder of USFX simply sends their USFX back to its issuing account with the Flare address they wish to credit in the Memo field of the transaction.

2) The Flare state Connector observes this transaction and the smart contract on Flare sends the requisite amount of USF to the redeemer’s chosen account.

NOTES AND BENEFITS:

  • This system allows for the creation of an issued currency on the XRP Ledger that does not require any participant to trust the issuer. Hence the issuers in this system can be called “trustless issuers”.
  • The issued currency can relate to any asset that exists on Flare. Examples include stable tokens representing currencies (Collateralized or Fiat), equities, bonds, commodities etc.
  • Previously on the XRP Ledger, despite using the same currency code, issued currencies from different issuers would have different characteristics (risk, fees, etc.). All units of an IC issued under the method defined above would be identical even though they have different issuers. The only due diligence a participant needs to undertake on an issuer is to check if they are a valid “trustless issuer” by referencing the decentralized list maintained by smart contracts on Flare. More generally we can say that all IC units issued in this way are perfectly fungible for each other, regardless of the issuer. This homogeneity should incentivize substantially higher liquidity at the XRPL Dex than if this were not the case.
  • Because each “trustless issuer” on XRP Ledger is fully and trustlessly collateralized on Flare, trustlines to “trustless issuers” do not require subjective financial risk analysis. Therefore any trustline that is extended to a “trustless issuer” by a participant should be for the total amount issued by that “trustless issuer”.
  • With regards to atomic net settlement “rippling”, the two properties above, fungibility and maximal trustline size, dramatically lower the barrier to achieving a large multiply connected graph (defined by trustlines) across which maximal net settlement (rippling) can occur. In short this means payments can occur between a much larger set of parties for much larger amounts.