Liquidity
Rafiki implements a clearing protocol - the Interledger Protocol. As such, it does not hold liquidity but keeps track of liquidity moving through it.
Types of Liquidity
Asset Liquidity
Asset Liquidity defines the amount of value, denominated in a given asset, Rafiki has at its disposal to send or forward ILP packets in. It increases if packets denominated in a given asset are received and decreases if packets denominated in a given asset are sent. It is always positive and cannot fall below 0.
Account Servicing Entities should define and adjust the asset liquidity based on their liquidity risk profile.
Example
Rafiki has been configured with 2 assets, EUR and USD, both with an asset scale of 0. The EUR liquidity is 10, the USD liquidity if 50.
In a cross-currency transaction, Rafiki receives packets worth 10 EUR and sends packets worth 11 USD. The EUR liquidity is increased to 20, the USD liquidity is reduced to 39.
A transaction where Rafiki receives 50 EUR and would have to sent 55 USD would fail because Rafiki does not have enough USD liquidity.
Peer Liquidity
Peer Liquidity defines the line of credit, denominated in the asset of the peering relationship, that Rafiki gives a certain peer. It should be defined in the peering agreement and depends on the trust between the transacting peers. If peer liquidity is not sufficient, payments will not be processed. Once the peer liquidity is used up, peers should settle and then reset their peer liquidity.
Example
A configured peer Cloud Nine Wallet within Rafiki has a peer liquidity of 100 USD. Rafiki can send packets up to 100 USD to wallet addresses issued by Cloud Nine Wallet. Once that liquidity is used up, we should settle with Cloud Nine Wallet and then reset their liquidity to 100 USD.
Payment Liquidity
When Open Payments incoming or outgoing payments are created, a liquidity account is created within the accounting database. Liquidity needs to be deposited to an outgoing payment before the payment can be processed. The Account Servicing Entity is notified to deposit liquidity via the outgoing_payment.created
event. Similarly, packets that are received for an incoming payment increase its liquidity. The Account Servicing Entity is notified to withdraw that liquidity via the incoming_payment.completed
event.
Depositing and Withdrawing Liquidity
Note: The
idempotencyKey
must be provided whenever calling mutations dealing with liquidity. This key allows safely retrying requests, without performing the operation multiple times. This should be a unique key (typically, a V4 UUID). For more information on Rafiki’s idempotency, see more.
Asset Liquidity
Deposit and withdraw asset liquidity via the Admin API (or UI):
where
and
where
Peer Liquidity
Deposit and withdraw peer liquidity via the Admin API (or UI):
where
and
where
Payment Liquidity
Outgoing payment
Deposit and withdraw outgoing payment liquidity via the Admin API only:
where
and
where
Incoming payment
Withdraw incoming payment liquidity via the Admin API only:
where