mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-21 04:05:49 +00:00
further revisions per mduo13 review
This commit is contained in:
@@ -1,33 +1,33 @@
|
|||||||
# Checks
|
# Checks
|
||||||
|
|
||||||
In the XRP Ledger (XRPL), a Check is similar to a personal paper check. Like traditional checks, XRPL Checks start with the sender of the funds creating a Check that specifies an amount and receiver. The receiver cashes the check to pull the funds from the sender's account into the receiver's account. No money moves until the receiver cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the receiver tries to cash it, just like traditional checks. If there's a failure cashing the check, the sender can retry until the check expires.
|
In the XRP Ledger, a Check is similar to a personal paper check. Like traditional checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and receiver. The receiver cashes the check to pull the funds from the sender's account into the receiver's account. No money moves until the receiver cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the receiver tries to cash it, just like traditional checks. If there's a failure cashing the check, the sender can retry until the check expires.
|
||||||
|
|
||||||
XRPL Checks have expiration times after which they may no longer be cashed. If the receiver doesn't successfully cash the Check before it expires, the Check object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and receiver can cancel the Check before it expires or is cashed. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it.
|
XRP Ledger Checks have expiration times after which they may no longer be cashed. If the receiver doesn't successfully cash the Check before it expires, the Check object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and receiver can cancel the Check before it expires or is cashed. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it.
|
||||||
|
|
||||||
Checks are similar to [Escrow](https://ripple.com/build/escrow/#escrow) and [Payment Channels](https://ripple.com/build/payment-channels-tutorial/). Because they are both executed in multiple steps, Checks and Payment Channels allow you to send funds without syncing to the XRP Ledger for each step. There are two important differences between the other two methods and Checks:
|
Checks are similar to [Escrow](concept-escrow.html) and [Payment Channels](tutorial-paychan.html). But there are two important differences between those methods and Checks:
|
||||||
|
|
||||||
* You can send issued currency with Checks. With Payment Channels and Escrow, you can only send XRP.
|
* You can send issued currency with Checks. With Payment Channels and Escrow, you can only send XRP.
|
||||||
|
|
||||||
* Checks do not tie up any funds. The XRP involved in Payment Channels and Escrow cannot be spent until it is redeemed with a claim provided by the sender (Payment Channels), or released by an expiration or crypto-condition (Escrow).
|
* Checks do not tie up any funds. The XRP involved in Payment Channels and Escrow cannot be spent until it is redeemed with a claim provided by the sender (Payment Channels), or released by an expiration or crypto-condition (Escrow).
|
||||||
|
|
||||||
|
|
||||||
***Note:*** The [Checks](https://ripple.com/build/known-amendments/#checks) amendment changes the expiration behavior of the [OfferCreate transaction](https://ripple.com/build/transactions/#offercreate). For more information, see [OfferCreate](reference-transaction-format.html#expiration).
|
***Note:*** The [Checks](reference-amendments.html#checks) amendment changes the expiration behavior of the [OfferCreate transaction](reference-transaction-format.html#offercreate). For more information, see [OfferCreate](reference-transaction-format.html#expiration).
|
||||||
|
|
||||||
|
|
||||||
## Why Checks?
|
## Why Checks?
|
||||||
|
|
||||||
Traditional paper checks allow people to transfer balances without immediately exchanging physical currency. XRPL Checks allow people to exchange funds asynchronously using a process that is familiar to and accepted by the banking industry.
|
Traditional paper checks allow people to transfer balances without immediately exchanging physical currency. XRP Ledger Checks allow people to exchange funds asynchronously using a process that is familiar to and accepted by the banking industry.
|
||||||
|
|
||||||
XRPL Checks also solve a problem that is unique to the XRP Ledger: they allow users to reject unwanted payments or accept only a portion of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons.
|
XRP Ledger Checks also solve a problem that is unique to the XRP Ledger: they allow users to reject unwanted payments or accept only a portion of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons.
|
||||||
|
|
||||||
Checks potentially enable many other use cases. Ripple encourages the community to find new and creative applications for Checks.
|
Checks potentially enable many other use cases. Ripple encourages the community to find new and creative applications for Checks.
|
||||||
|
|
||||||
|
|
||||||
### Use Case: Payment Authorization
|
### Use Case: Payment Authorization
|
||||||
|
|
||||||
**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](https://ripple.com/build/gateway-guide/#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to disclose the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant overhead cost to these institutions' compliance departments, including potential fines or penalties.
|
**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](tutorial-gateway-guide.html#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to disclose the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties.
|
||||||
|
|
||||||
**Solution:** Institutions can enable [Deposit Authorization](https://ripple.com/build/deposit-authorization/#deposit-authorization) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](https://ripple.com/build/transactions/#accountset-flags). This makes the account unable to accept Payment transactions. The only way for accounts with Deposit Authorization set to receive funds is through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled.
|
**Solution:** Institutions can enable [Deposit Authorization](concept-deposit-auth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](reference-transaction-format.html#accountset-flags). This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled.
|
||||||
|
|
||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
@@ -39,16 +39,16 @@ Checks typically have the lifecycle described below.
|
|||||||
|
|
||||||
[](img/checks-happy_path.png)
|
[](img/checks-happy_path.png)
|
||||||
|
|
||||||
**Step 1:** To create a Check, the sender submits a [CheckCreate](https://ripple.com/build/transactions/#checkcreate) transaction and specifies the receiver (`Destination`), expiration time (`Expiration`), and maximum amount that may be debited from the sender's account (`SendMax`).
|
**Step 1:** To create a Check, the sender submits a [CheckCreate](reference-transaction-format.html#checkcreate) transaction and specifies the receiver (`Destination`), expiration time (`Expiration`), and maximum amount that may be debited from the sender's account (`SendMax`).
|
||||||
|
|
||||||
|
|
||||||
**Step 2:** After the CheckCreate transaction is processed, a [Check object](https://ripple.com/build/ledger-format/#check) (`tlCheck`) is created on the XRP Ledger. This object contains the properties of the Check as defined by the transaction that created it. The object can only be modified by the sender (by canceling it with a [CheckCancel](https://ripple.com/build/transactions/#checkcancel) transaction) or receiver (by canceling it or cashing it) before the expiration time passes. After the expiration time, anyone may cancel the Check.
|
**Step 2:** After the CheckCreate transaction is processed, a [Check object](reference-ledger-format.html#check) (`tlCheck`) is created on the XRP Ledger. This object contains the properties of the Check as defined by the transaction that created it. The object can only be modified by the sender (by canceling it with a [CheckCancel](reference-transaction-format.html#checkcancel) transaction) or receiver (by canceling it or cashing it) before the expiration time passes. After the expiration time, anyone may cancel the Check.
|
||||||
|
|
||||||
**Step 3:** To cash the check, the receiver submits a [CheckCash](https://ripple.com/build/transactions/#checkcash) transaction. The receiver has two options for cashing the check:
|
**Step 3:** To cash the check, the receiver submits a [CheckCash](reference-transaction-format.html#checkcash) transaction. The receiver has two options for cashing the check:
|
||||||
|
|
||||||
* `Amount` — The receiver can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](https://ripple.com/build/transfer-fees/) and the receiver can only accept the exact amount on an invoice or other contract.
|
* `Amount` — The receiver can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](concept-transfer-fees.html) and the receiver can only accept the exact amount on an invoice or other contract.
|
||||||
|
|
||||||
* `DeliverMin` — The receiver can use this option to specify the minimum amount they are willing to receive from the check. If the receiver uses this option, `rippled` attempts to deliver as much as possible and will deliver at least this amount. The transaction fails if the sender doesn't have at least this amount in their account.
|
* `DeliverMin` — The receiver can use this option to specify the minimum amount they are willing to receive from the Check. If the receiver uses this option, `rippled` attempts to deliver as much as possible and will deliver at least this amount. The transaction fails if the amount that can be credited to the receiver is not at least this amount.
|
||||||
|
|
||||||
If the sender has enough funds to cover the Check and the expiration time has not passed, the funds are debited from the sender's account and credited to the receiver's account, and the Check object is is destroyed.
|
If the sender has enough funds to cover the Check and the expiration time has not passed, the funds are debited from the sender's account and credited to the receiver's account, and the Check object is is destroyed.
|
||||||
|
|
||||||
@@ -61,22 +61,22 @@ In the case of expirations, Checks have the lifecycle described below.
|
|||||||
<!--{# Diagram sources: https://docs.google.com/drawings/d/1JOgI3H5tpV1yasYe5WLrdxVXLhcQu0bhPfN0mzzS1YQ/edit #}-->
|
<!--{# Diagram sources: https://docs.google.com/drawings/d/1JOgI3H5tpV1yasYe5WLrdxVXLhcQu0bhPfN0mzzS1YQ/edit #}-->
|
||||||
|
|
||||||
|
|
||||||
[](img/checks-expiration.png)
|
[](img/checks_expiration.png)
|
||||||
|
|
||||||
|
|
||||||
All Checks start the same way, so **Steps 1 and 2** are the same.
|
All Checks start the same way, so **Steps 1 and 2** are the same.
|
||||||
|
|
||||||
**Step 3a:** If the Check expires before the receiver can cash it, the Check can no longer be cashed but remains in the Ledger.
|
**Step 3a:** If the Check expires before the receiver can cash it, the Check can no longer be cashed but remains in the ledger.
|
||||||
|
|
||||||
**Step 4a:** After a Check expires, anyone may cancel it by submitting a [CheckCancel](https://ripple.com/build/transactions/#checkcancel) transaction. That transaction removes the Check from the Ledger.
|
**Step 4a:** After a Check expires, anyone may cancel it by submitting a [CheckCancel](reference-transaction-format.html#checkcancel) transaction. That transaction removes the Check from the ledger.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Availability of Checks
|
## Availability of Checks
|
||||||
|
|
||||||
Checks were enabled in `rippled` v0.90.0 with the ["Checks" amendment](https://ripple.com/build/known-amendments/#checks).
|
Checks require `rippled` v0.90.0 or later and have been enabled on the production XRP Ledger since 2018-03-15.
|
||||||
|
|
||||||
You can check the status of the Checks amendment using the [`feature` command](https://ripple.com/build/rippled-apis/#feature).
|
When not using the production XRP Ledger, you can check the status of the Checks amendment using the [`feature` command](reference-rippled.html#feature).
|
||||||
|
|
||||||
|
|
||||||
## Further Reading
|
## Further Reading
|
||||||
@@ -85,14 +85,14 @@ For more information about Checks in the XRP Ledger, see:
|
|||||||
|
|
||||||
<!--{#TODO: add link to Checks tutorial#}-->
|
<!--{#TODO: add link to Checks tutorial#}-->
|
||||||
|
|
||||||
* [Transaction Reference](https://ripple.com/build/transactions/#transaction-types)
|
* [Transaction Reference](reference-transaction-format.html#transaction-types)
|
||||||
* [Checks amendment](https://ripple.com/build/known-amendments/#checks)
|
* [Checks amendment](reference-amendments.html#checks)
|
||||||
* [CheckCreate](https://ripple.com/build/transactions/#checkcreate)
|
* [CheckCreate](reference-transaction-format.html#checkcreate)
|
||||||
* [CheckCash](https://ripple.com/build/transactions/#checkcash)
|
* [CheckCash](reference-transaction-format.html#checkcash)
|
||||||
* [CheckCancel](https://ripple.com/build/transactions/#checkcancel)
|
* [CheckCancel](reference-transaction-format.html#checkcancel)
|
||||||
|
|
||||||
For more information about related features, see:
|
For more information about related features, see:
|
||||||
|
|
||||||
* [Deposit Authorization](https://ripple.com/build/deposit-authorization/)
|
* [Deposit Authorization](concept-deposit-auth.html)
|
||||||
* [Escrow](https://ripple.com/build/escrow/)
|
* [Escrow](concept-escrow.html)
|
||||||
* [Payment Channels Tutorial](https://ripple.com/build/payment-channels-tutorial/)
|
* [Payment Channels Tutorial](tutorial-paychan.html)
|
||||||
|
|||||||
@@ -169,6 +169,12 @@ pages:
|
|||||||
- local
|
- local
|
||||||
- ripple.com
|
- ripple.com
|
||||||
|
|
||||||
|
- md: concept-checks.md
|
||||||
|
category: Technical Overview
|
||||||
|
targets:
|
||||||
|
- local
|
||||||
|
- ripple.com
|
||||||
|
|
||||||
- md: concept-fees.md
|
- md: concept-fees.md
|
||||||
category: Technical Overview
|
category: Technical Overview
|
||||||
targets:
|
targets:
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 109 KiB After Width: | Height: | Size: 99 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 128 KiB After Width: | Height: | Size: 124 KiB |
Reference in New Issue
Block a user