mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Merge pull request #352 from mDuo13/doc1484
Add complex payment types concepts
This commit is contained in:
@@ -0,0 +1,25 @@
|
||||
# Cross-Currency Payments
|
||||
|
||||
In the XRP Ledger, you can send cross-currency payments that exchange one or more issued currencies, XRP, or both. Like [direct XRP payments](TODO-link), these payments use the [Payment transaction type][Payment]. Cross-currency payments within the XRP Ledger are fully atomic, meaning that either the payment fully executes or no part of it executes.
|
||||
|
||||
By default, cross-currency payments deliver a fixed amount to their destination at a variable cost to their source. Cross-currency payments can also be [partial payments](partial-payments.html), which deliver a variable amount to the destination within a fixed sending limit.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- By definition, a cross-currency payment involves at least two currencies, which means that at least one currency involved must be a non-XRP issued currency.
|
||||
- Typically, this means using one or more currencies issued by an [XRP Ledger Gateway](become-an-xrp-ledger-gateway.html). Such currencies are backed by funds outside the XRP Ledger, and can be withdrawn through the gateway.
|
||||
- You could also use digital tokens that are only issued within the XRP Ledger and has no outside backing, as long as the parties transacting are willing to send or receive those tokens and treat them as something of value.
|
||||
- There must be at least one [Path](paths.html) between the sender and receiver, and the total liquidity across all paths must be enough to facilitate the payment. For cross-currency payments, this usually means consuming [Offers](offers.html) to convert from one currency to another.
|
||||
|
||||
|
||||
## Autobridging
|
||||
|
||||
Cross-currency payments that exchange two issued currencies automatically use XRP, when it decreases the cost of the payment, by connecting order books to deepen the pool of available liquidity. For example, a payment sending from USD to MXN automatically converts USD to XRP and then XRP to MXN if doing so is cheaper than converting USD to MXN directly.
|
||||
|
||||
For more information, see [Autobridging](autobridging.html).
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -102,4 +102,7 @@ Using [the `delivered_amount` field](#the-delivered-amount-field) when processin
|
||||
- Add additional sanity checks to your business logic for processing withdrawals. Never process a withdrawal if the total balance you hold in the XRP Ledger does not match your expected assets and obligations.
|
||||
- Follow "Know Your Customer" guidelines and strictly verify your customers' identities. You may be able to recognize and block malicious users in advance, or pursue legal action against a malicious actor who exploits your system.
|
||||
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
37
content/concepts/complex-payment-types/payment-channels.md
Normal file
37
content/concepts/complex-payment-types/payment-channels.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Payment Channels
|
||||
|
||||
Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later.
|
||||
|
||||
The XRP for a payment channel is set aside for a given time period. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](consensus.html). (This is an _asychronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims.
|
||||
|
||||
Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECSDA signatures. Research has <a href="https://ed25519.cr.yp.to/ed25519-20110926.pdf">demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second <i class="fa fa-external-link" aria-hidden="true"></i></a> on commodity hardware in 2011.
|
||||
|
||||
|
||||
## Why Use Payment Channels
|
||||
|
||||
The process of using a payment channel always involves two parties, a payer and a payee. The payer is an individual person or institution using the XRP Ledger who is a customer of the payee. The payee is a person or business who is receives XRP as payment for goods or services.
|
||||
|
||||
Payment Channels do not intrinsically specify anything about what you can buy and sell with them. However, the types of goods and services that are a good fit for payment channels are:
|
||||
|
||||
- Things that can be transmitted near-instantly, like digital items
|
||||
- Inexpensive things, where the cost of processing a transaction is a non-trivial part of the price
|
||||
- Things normally bought in bulk, where the exact quantity desired is not known in advance
|
||||
|
||||
|
||||
## Payment Channel Lifecycle
|
||||
|
||||
The following diagram summarizes the lifecycle of a payment channel:
|
||||
|
||||
[](img/paychan-flow.png)
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- [Use Payment Channels](use-payment-channels.html), a tutorial stepping through the process of using a payment channel.
|
||||
|
||||
- [Escrow](escrow.html), a similar feature for higher-value, lower-speed conditional XRP payments.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user