From 36aa1efc30784cbe8e5d8760a70586adefac43ea Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Tue, 16 Jul 2024 11:33:27 -0400 Subject: [PATCH 01/11] wip --- .../README.md | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 XLS-0073-disllow-frozen-trustline-receiving/README.md diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md new file mode 100644 index 00000000..7936cd9d --- /dev/null +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -0,0 +1,64 @@ +
+Title:       Disallow Receiving on Frozen Trustline
+Type:        draft
+
+Author:      Shawn Xie
+Affiliation: Ripple
+
+ +# Disallow Receiving on Frozen Trustline + +## Abstract + +This amendment empowers token issuers on the XRP Ledger to regulate tokens in an effort to prevent misuse by blacklisted accounts. This document proposes enhancements to the interactions between frozen assets and payment. This proposal will ensure that blacklisted token holders can no longer receive funds, which will significantly improve use cases such as stablecoins, where ensuring regulatory compliance is essential. + +## 1. Overview +This proposal introduces new improvements on how frozen trustlines interacts with payment, offers, DEX and AMM. In essence, trustlines, that have been frozen (either individually or globally), should not be able to receive funds in any way. + + +## 2. Specification +### 2.1. Payment Engine +Payment engine executes paths that is made of steps to connect the sender to the receiver. In general, funds can be deposited into a frozen trustline through one of the two steps: +* Rippling +* Order book or AMM + +This proposal proposes changes to both steps above to ensure a frozen trustline _cannot_ increase its balance. + +#### 2.1.1. Rippling +In the current behavior, after the issuer freezes a trustline by setting lsfHighFreeze/lsfLowFreeze on the trustline (individual freeze) or lsfGlobalFreeze on the account (global freeze), the trustline cannot decrease its balance but can still increase its balance (allowing the receipt of funds). This proposal suggests a change to the behavior: __any frozen trustline can no longer increase its balance as a result of any transaction__. In other words, any receipt of funds in the frozen trustline will result in failure. + +##### 2.1.1.1. Example +Let's take a look at an example where rippling is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. + +``` ++-------+ USD +--------+ USD +-------+ +| Alice | ----------------------> | Issuer | <---------------------- | Bob | ++-------+ +--------+ Issuer freezes Bob +-------+ + +``` + +Consider the following scenario: + +1. Issuer accounts issues USD to both Alice and Bob, each of which has a trustline +2. Issuer individually freezes Bob by setting lsfHighFreeze/lsfLowFreeze on Bob's trustline +3. Alice attempts to send a USD `Payment` transaction to Bob, who's frozen. In the existing behavior, Alice will be able to successfully send funds to Bob. + +In this proposal, it suggests to change the behavior at __Step 3__ to + +> Alice attempts to send a USD `Payment` to Bob, who's frozen. The `Payment` transaction _fails_ because Bob's USD trustline has been frozen and can no longer receive funds. + + +#### 2.1.2. Order Book and AMM +In the payment engine, offers and AMM pools can be consumed in the path when cross-currency exchange is involved, it will result in change of trustline balance. Currently, offers are allowed to be consumed despite the + + +### 2.2. `OfferCreate` transaction +This proposal proposes a new change to OfferCreate transaction. Currently, if the holder has been frozen, they are still allowed to submit a OfferCreate transaction that specifies `TakerPays` to be the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: +* `OfferCreate` returns `tecUNFUNDED_OFFER` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) + + + + + + + From d9181b4b36fed03aea77de1dc59cd05444377284 Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Tue, 16 Jul 2024 13:55:54 -0400 Subject: [PATCH 02/11] amm and offer --- .../README.md | 76 ++++++++++++++++--- 1 file changed, 67 insertions(+), 9 deletions(-) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md index 7936cd9d..c84eb828 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -1,12 +1,12 @@ 
-Title:       Disallow Receiving on Frozen Trustline
+Title:       Disallow Receiving on Frozen Trustlines
 Type:        draft
 
 Author:      Shawn Xie
 Affiliation: Ripple
-# Disallow Receiving on Frozen Trustline +# Disallow Receiving on Frozen Trustlines ## Abstract @@ -32,15 +32,15 @@ Let's take a look at an example where rippling is involved in transfering the fu ``` +-------+ USD +--------+ USD +-------+ -| Alice | ----------------------> | Issuer | <---------------------- | Bob | -+-------+ +--------+ Issuer freezes Bob +-------+ +| Alice | ----------------------> | Issuer | ----------------------> | Bob | ++-------+ +--------+ (Bob is frozen) +-------+ ``` Consider the following scenario: -1. Issuer accounts issues USD to both Alice and Bob, each of which has a trustline -2. Issuer individually freezes Bob by setting lsfHighFreeze/lsfLowFreeze on Bob's trustline +1. Issuer accounts issues USD to both Alice and Bob, each of which has a trustline. +2. Issuer individually freezes Bob's trustline. 3. Alice attempts to send a USD `Payment` transaction to Bob, who's frozen. In the existing behavior, Alice will be able to successfully send funds to Bob. In this proposal, it suggests to change the behavior at __Step 3__ to @@ -49,14 +49,72 @@ In this proposal, it suggests to change the behavior at __Step 3__ to #### 2.1.2. Order Book and AMM -In the payment engine, offers and AMM pools can be consumed in the path when cross-currency exchange is involved, it will result in change of trustline balance. Currently, offers are allowed to be consumed despite the +In the payment engine, offers and AMM pools can be consumed in the path when cross-currency exchange is involved, it will result in change of trustline balance. +##### 2.1.2.1. Order Book +Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays`, the payment path fails and the offer becomes _unfunded_.__ +##### 2.1.2.1.1. Example +Let's take a look at an example where offer is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. +``` + + Bob's Offer ++-------+ USD +--------------+ XRP +-------+ +| Alice | ----------------------> | Sell: 100 XRP| ----------------------> | Carol | ++-------+ SendMax: 100 USD +--------------+ +-------+ + Amount: 100 XRP | Buy: 100 USD | + +--------------+ + (Bob is frozen) + +``` + +Consider the following scenario: + +1. Issuer accounts issues USD to both Alice and Bob, each of which has a trustline. +2. Issuer individually freezes Bob's trustline. +3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. In the existing behavior, Alice will be able to successfully send 100 XRP to Carol, and Bob receives 100 USD. + +In this proposal, it suggests to change the behavior at __Step 3__ to + +> 3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. Alice fails to send XRP to Carol because Bob's offer is unfunded due to the frozen trustline. + + +##### 2.1.2.2. AMM +Similarly, an AMM step can increase the trustline balance of a token holder despite they've been individually frozen. This proposal introduces a new change: __a payment path fails if the token, that is swapped out, results in the increase of balance of a frozen trustline__ + +##### 2.1.2.2.1. Example +Let's take a look at an example where AMM is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. + +``` + + AMM Pool ++-------+ XRP +------------+ USD +-------+ +| Alice | ----------------------> | 100 XRP | ----------------------> | Bob | ++-------+ SendMax: 100 XRP +------------+ (Bob is frozen) +-------+ + Amount: 100 USD | 10000 USD | + +------------+ + + +``` + +Consider the following scenario: + +1. Issuer accounts issues USD to Bob, who has a trustline. +2. An AMM pool is created with USD and XRP assets and assume the pool has a quality good enough to provide XRP to USD swaps. +3. Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. In the existing behavior, Alice will be able to successfully send USD to Bob through the AMM pool by swapping XRP for USD. + +In this proposal, it suggests to change the behavior at __Step 3__ to + +> Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. Alice _fails_ to send USD to Bob through the AMM pool because Bob has been individually frozen. + ### 2.2. `OfferCreate` transaction -This proposal proposes a new change to OfferCreate transaction. Currently, if the holder has been frozen, they are still allowed to submit a OfferCreate transaction that specifies `TakerPays` to be the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: +This proposal introduces a new change to the OfferCreate transaction. Currently, if the holder has been frozen, they are still allowed to submit a OfferCreate transaction that specifies `TakerPays` to be the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: * `OfferCreate` returns `tecUNFUNDED_OFFER` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) - +### 2.3. `AMMDeposit` transaction +This proposal introduces a new change to the AMMDeposit transaction. Currently, `AMMDeposit` would allow an account to deposit tokens into the pool regardless whether the account's tokens are frozen. +This proposal introduces the following: +* `AMMDeposit` fails if one of the tokens has been frozen (either indivually or globally) by the issuer (for both single-sided and double-sided deposits). From ffeec8f9666415a866233fdc87a317c57798f00e Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Tue, 16 Jul 2024 14:30:16 -0400 Subject: [PATCH 03/11] fix --- .../README.md | 34 +++++++------------ 1 file changed, 13 insertions(+), 21 deletions(-) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md index c84eb828..27dab339 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -34,14 +34,13 @@ Let's take a look at an example where rippling is involved in transfering the fu +-------+ USD +--------+ USD +-------+ | Alice | ----------------------> | Issuer | ----------------------> | Bob | +-------+ +--------+ (Bob is frozen) +-------+ - ``` Consider the following scenario: -1. Issuer accounts issues USD to both Alice and Bob, each of which has a trustline. +1. Issuer account issues USD to both Alice and Bob, each of which has a trustline. 2. Issuer individually freezes Bob's trustline. -3. Alice attempts to send a USD `Payment` transaction to Bob, who's frozen. In the existing behavior, Alice will be able to successfully send funds to Bob. +3. Alice attempts to send a USD `Payment` transaction to Bob, who's frozen. In the current behavior, Alice will be able to successfully send funds to Bob. In this proposal, it suggests to change the behavior at __Step 3__ to @@ -51,13 +50,12 @@ In this proposal, it suggests to change the behavior at __Step 3__ to #### 2.1.2. Order Book and AMM In the payment engine, offers and AMM pools can be consumed in the path when cross-currency exchange is involved, it will result in change of trustline balance. ##### 2.1.2.1. Order Book -Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays`, the payment path fails and the offer becomes _unfunded_.__ +Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays` currency, the offer is considered to be _unfunded_ and therefore the payment path fails .__ ##### 2.1.2.1.1. Example Let's take a look at an example where offer is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. ``` - Bob's Offer +-------+ USD +--------------+ XRP +-------+ | Alice | ----------------------> | Sell: 100 XRP| ----------------------> | Carol | @@ -65,56 +63,50 @@ Let's take a look at an example where offer is involved in transfering the funds Amount: 100 XRP | Buy: 100 USD | +--------------+ (Bob is frozen) - ``` Consider the following scenario: -1. Issuer accounts issues USD to both Alice and Bob, each of which has a trustline. +1. Issuer account issues USD to both Alice and Bob, each of which has a trustline. 2. Issuer individually freezes Bob's trustline. -3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. In the existing behavior, Alice will be able to successfully send 100 XRP to Carol, and Bob receives 100 USD. +3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. In the current behavior, Alice will be able to successfully send 100 XRP to Carol, and Bob receives 100 USD. In this proposal, it suggests to change the behavior at __Step 3__ to > 3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. Alice fails to send XRP to Carol because Bob's offer is unfunded due to the frozen trustline. - ##### 2.1.2.2. AMM -Similarly, an AMM step can increase the trustline balance of a token holder despite they've been individually frozen. This proposal introduces a new change: __a payment path fails if the token, that is swapped out, results in the increase of balance of a frozen trustline__ +Similarly, an AMM step can increase the trustline balance of a token holder even if they have been individually frozen. This proposal introduces a new change: __a payment path fails if the token being swapped out results in an increase in the balance of a frozen trustline.__ ##### 2.1.2.2.1. Example Let's take a look at an example where AMM is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. ``` - AMM Pool +-------+ XRP +------------+ USD +-------+ | Alice | ----------------------> | 100 XRP | ----------------------> | Bob | +-------+ SendMax: 100 XRP +------------+ (Bob is frozen) +-------+ Amount: 100 USD | 10000 USD | - +------------+ - - + +------------+ ``` Consider the following scenario: -1. Issuer accounts issues USD to Bob, who has a trustline. +1. Issuer account issues USD to Bob, who has a trustline. 2. An AMM pool is created with USD and XRP assets and assume the pool has a quality good enough to provide XRP to USD swaps. -3. Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. In the existing behavior, Alice will be able to successfully send USD to Bob through the AMM pool by swapping XRP for USD. +3. Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. In the current behavior, Alice will be able to successfully send USD to Bob through the AMM pool by swapping XRP for USD. In this proposal, it suggests to change the behavior at __Step 3__ to > Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. Alice _fails_ to send USD to Bob through the AMM pool because Bob has been individually frozen. ### 2.2. `OfferCreate` transaction -This proposal introduces a new change to the OfferCreate transaction. Currently, if the holder has been frozen, they are still allowed to submit a OfferCreate transaction that specifies `TakerPays` to be the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: +This proposal introduces a new change to the `OfferCreate` transaction. Currently, if the holder has been frozen, they are still allowed to submit a `OfferCreate` transaction that specifies `TakerPays` as the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: * `OfferCreate` returns `tecUNFUNDED_OFFER` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) -### 2.3. `AMMDeposit` transaction -This proposal introduces a new change to the AMMDeposit transaction. Currently, `AMMDeposit` would allow an account to deposit tokens into the pool regardless whether the account's tokens are frozen. -This proposal introduces the following: -* `AMMDeposit` fails if one of the tokens has been frozen (either indivually or globally) by the issuer (for both single-sided and double-sided deposits). +## 3. Invariants +One potential invariant could be disallowing any increase in the balance of a frozen trustline as a result of a `Payment` transaction. + From 75239397594c9e7f3d4eb071a8e6bb402747e99b Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Tue, 16 Jul 2024 14:35:13 -0400 Subject: [PATCH 04/11] fix stuff --- .../README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md index 27dab339..d48ce30a 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -25,7 +25,7 @@ Payment engine executes paths that is made of steps to connect the sender to the This proposal proposes changes to both steps above to ensure a frozen trustline _cannot_ increase its balance. #### 2.1.1. Rippling -In the current behavior, after the issuer freezes a trustline by setting lsfHighFreeze/lsfLowFreeze on the trustline (individual freeze) or lsfGlobalFreeze on the account (global freeze), the trustline cannot decrease its balance but can still increase its balance (allowing the receipt of funds). This proposal suggests a change to the behavior: __any frozen trustline can no longer increase its balance as a result of any transaction__. In other words, any receipt of funds in the frozen trustline will result in failure. +In the current behavior, after the issuer freezes a trustline by setting `lsfHighFreeze`/`lsfLowFreeze` on the trustline (individual freeze) or `lsfGlobalFreeze` on the account (global freeze), the trustline cannot decrease its balance but can still increase its balance (allowing the receipt of funds). This proposal suggests a change to the behavior: __any frozen trustline can no longer increase its balance as a result of any transaction__. In other words, any receipt of funds in the frozen trustline will result in failure. ##### 2.1.1.1. Example Let's take a look at an example where rippling is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. @@ -42,7 +42,7 @@ Consider the following scenario: 2. Issuer individually freezes Bob's trustline. 3. Alice attempts to send a USD `Payment` transaction to Bob, who's frozen. In the current behavior, Alice will be able to successfully send funds to Bob. -In this proposal, it suggests to change the behavior at __Step 3__ to +This proposal suggests changing the behavior at __Step 3__ to > Alice attempts to send a USD `Payment` to Bob, who's frozen. The `Payment` transaction _fails_ because Bob's USD trustline has been frozen and can no longer receive funds. @@ -50,7 +50,7 @@ In this proposal, it suggests to change the behavior at __Step 3__ to #### 2.1.2. Order Book and AMM In the payment engine, offers and AMM pools can be consumed in the path when cross-currency exchange is involved, it will result in change of trustline balance. ##### 2.1.2.1. Order Book -Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays` currency, the offer is considered to be _unfunded_ and therefore the payment path fails .__ +Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays` currency, the offer is considered to be _unfunded_ and therefore the step fails .__ ##### 2.1.2.1.1. Example Let's take a look at an example where offer is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. @@ -71,12 +71,12 @@ Consider the following scenario: 2. Issuer individually freezes Bob's trustline. 3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. In the current behavior, Alice will be able to successfully send 100 XRP to Carol, and Bob receives 100 USD. -In this proposal, it suggests to change the behavior at __Step 3__ to +This proposal suggests changing the behavior at __Step 3__ to -> 3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. Alice fails to send XRP to Carol because Bob's offer is unfunded due to the frozen trustline. +> Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. Alice fails to send XRP to Carol because Bob's offer is unfunded due to the frozen trustline. ##### 2.1.2.2. AMM -Similarly, an AMM step can increase the trustline balance of a token holder even if they have been individually frozen. This proposal introduces a new change: __a payment path fails if the token being swapped out results in an increase in the balance of a frozen trustline.__ +Similarly, an AMM step can increase the trustline balance of a token holder even if they have been individually frozen. This proposal introduces a new change: __the step fails if the token being swapped out of an AMM pool results in an increase in the balance of a frozen trustline.__ ##### 2.1.2.2.1. Example Let's take a look at an example where AMM is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. @@ -96,7 +96,7 @@ Consider the following scenario: 2. An AMM pool is created with USD and XRP assets and assume the pool has a quality good enough to provide XRP to USD swaps. 3. Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. In the current behavior, Alice will be able to successfully send USD to Bob through the AMM pool by swapping XRP for USD. -In this proposal, it suggests to change the behavior at __Step 3__ to +This proposal suggests changing the behavior at __Step 3__ to > Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. Alice _fails_ to send USD to Bob through the AMM pool because Bob has been individually frozen. From 11ebff9acd55f5499b5f6040fb70a36f4fb8b2cb Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Tue, 16 Jul 2024 14:37:07 -0400 Subject: [PATCH 05/11] small --- XLS-0073-disllow-frozen-trustline-receiving/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md index d48ce30a..aedd62a4 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -48,7 +48,7 @@ This proposal suggests changing the behavior at __Step 3__ to #### 2.1.2. Order Book and AMM -In the payment engine, offers and AMM pools can be consumed in the path when cross-currency exchange is involved, it will result in change of trustline balance. +In the payment engine, offers and AMM pools can be consumed in the path when cross-currency payment is involved, it will result in change of trustline balance. ##### 2.1.2.1. Order Book Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays` currency, the offer is considered to be _unfunded_ and therefore the step fails .__ ##### 2.1.2.1.1. Example From 6d09303f4e56125f247f9451002509d455e9cbcb Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Mon, 22 Jul 2024 10:45:10 -0400 Subject: [PATCH 06/11] remove amm --- .../README.md | 56 ++++++------------- 1 file changed, 17 insertions(+), 39 deletions(-) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md index aedd62a4..1c5c9bdc 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -31,9 +31,9 @@ In the current behavior, after the issuer freezes a trustline by setting `lsfHig Let's take a look at an example where rippling is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. ``` -+-------+ USD +--------+ USD +-------+ -| Alice | ----------------------> | Issuer | ----------------------> | Bob | -+-------+ +--------+ (Bob is frozen) +-------+ ++-------+ USD +---------+ USD +-------+ +| Alice | ----------------------> | Gateway | ----------------------> | Bob | ++-------+ +---------+ (Bob is frozen) +-------+ ``` Consider the following scenario: @@ -48,62 +48,40 @@ This proposal suggests changing the behavior at __Step 3__ to #### 2.1.2. Order Book and AMM -In the payment engine, offers and AMM pools can be consumed in the path when cross-currency payment is involved, it will result in change of trustline balance. +In the payment engine, offers and AMM pools can be consumed in the path when cross-currency payment is involved, it will result in change of trustline balance. This proposal introduces behavior changes to how offers work, as they currently allow the receipt of funds on a frozen trustline. However, no changes are introduced for the AMM pool, as the AMM account already denies the receipt of funds if its trustlines are frozen by the issuer of the assets. + ##### 2.1.2.1. Order Book -Currently, consumption of offers is allowed even if the offer owner has been individually frozen on the trustline of the buy amount (`TakerPays`). This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays` currency, the offer is considered to be _unfunded_ and therefore the step fails .__ +Currently, consumption of offers is allowed even if the buy amount (`TakerPays`) has been individually frozen. This proposal introduces a new change: __if the offer owner has been individually frozen on the trustline of `TakerPays` currency, the offer is considered to be _unfunded_ and therefore the step fails .__ ##### 2.1.2.1.1. Example Let's take a look at an example where offer is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. ``` - Bob's Offer -+-------+ USD +--------------+ XRP +-------+ -| Alice | ----------------------> | Sell: 100 XRP| ----------------------> | Carol | -+-------+ SendMax: 100 USD +--------------+ +-------+ - Amount: 100 XRP | Buy: 100 USD | - +--------------+ - (Bob is frozen) + Bob's Offer ++-------+ USD +---------+ USD +--------------+ XRP +-------+ +| Alice | ---------------------> | Gateway | -------------------> | Sell: 100 XRP| ----------------------> | Carol | ++-------+ SendMax: 100 USD +---------+ +--------------+ +-------+ + Amount: 100 XRP | Buy: 100 USD | + +--------------+ + (Bob is frozen) ``` Consider the following scenario: 1. Issuer account issues USD to both Alice and Bob, each of which has a trustline. 2. Issuer individually freezes Bob's trustline. -3. Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. In the current behavior, Alice will be able to successfully send 100 XRP to Carol, and Bob receives 100 USD. +3. Alice attempts to send XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. In the current behavior, Alice will be able to successfully send 100 XRP to Carol, and Bob receives 100 USD. This proposal suggests changing the behavior at __Step 3__ to -> Alice attempts to send a XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. Alice fails to send XRP to Carol because Bob's offer is unfunded due to the frozen trustline. - -##### 2.1.2.2. AMM -Similarly, an AMM step can increase the trustline balance of a token holder even if they have been individually frozen. This proposal introduces a new change: __the step fails if the token being swapped out of an AMM pool results in an increase in the balance of a frozen trustline.__ - -##### 2.1.2.2.1. Example -Let's take a look at an example where AMM is involved in transfering the funds and compare how the result differs between the current and proposed behaviors. - -``` - AMM Pool -+-------+ XRP +------------+ USD +-------+ -| Alice | ----------------------> | 100 XRP | ----------------------> | Bob | -+-------+ SendMax: 100 XRP +------------+ (Bob is frozen) +-------+ - Amount: 100 USD | 10000 USD | - +------------+ -``` - -Consider the following scenario: - -1. Issuer account issues USD to Bob, who has a trustline. -2. An AMM pool is created with USD and XRP assets and assume the pool has a quality good enough to provide XRP to USD swaps. -3. Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. In the current behavior, Alice will be able to successfully send USD to Bob through the AMM pool by swapping XRP for USD. - -This proposal suggests changing the behavior at __Step 3__ to - -> Alice attempts to send a cross-currency `Payment` transaction to Bob, who's frozen. Alice _fails_ to send USD to Bob through the AMM pool because Bob has been individually frozen. +> Alice attempts to send XRP to Carol through a `Payment` transaction using Bob's offer to exchange USD for XRP. Alice fails to send XRP to Carol because Bob's offer is unfunded due to the frozen trustline. ### 2.2. `OfferCreate` transaction This proposal introduces a new change to the `OfferCreate` transaction. Currently, if the holder has been frozen, they are still allowed to submit a `OfferCreate` transaction that specifies `TakerPays` as the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: * `OfferCreate` returns `tecUNFUNDED_OFFER` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) +Moreover, any existing offers with `TakerPays` currency frozen _can no longer be consumed and will be considered as an _unfunded_ offer that will be implicitly cancelled by new Offers that cross it._ + ## 3. Invariants One potential invariant could be disallowing any increase in the balance of a frozen trustline as a result of a `Payment` transaction. From db1f53cfbd918a5d6f73ce057a46da437d24f6ef Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Wed, 24 Jul 2024 11:34:10 -0400 Subject: [PATCH 07/11] update tec code for offercreate --- XLS-0073-disllow-frozen-trustline-receiving/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disllow-frozen-trustline-receiving/README.md index 1c5c9bdc..836eb393 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disllow-frozen-trustline-receiving/README.md @@ -78,7 +78,7 @@ This proposal suggests changing the behavior at __Step 3__ to ### 2.2. `OfferCreate` transaction This proposal introduces a new change to the `OfferCreate` transaction. Currently, if the holder has been frozen, they are still allowed to submit a `OfferCreate` transaction that specifies `TakerPays` as the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: -* `OfferCreate` returns `tecUNFUNDED_OFFER` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) +* `OfferCreate` returns `tecFROZEN` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) Moreover, any existing offers with `TakerPays` currency frozen _can no longer be consumed and will be considered as an _unfunded_ offer that will be implicitly cancelled by new Offers that cross it._ From 0db505c751bc8d12c72e4a5e5a89aebcc0afbc4b Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Mon, 29 Jul 2024 10:07:31 -0400 Subject: [PATCH 08/11] comments --- .../README.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) rename {XLS-0073-disllow-frozen-trustline-receiving => XLS-0073-disallow-frozen-trustline-receiving}/README.md (81%) diff --git a/XLS-0073-disllow-frozen-trustline-receiving/README.md b/XLS-0073-disallow-frozen-trustline-receiving/README.md similarity index 81% rename from XLS-0073-disllow-frozen-trustline-receiving/README.md rename to XLS-0073-disallow-frozen-trustline-receiving/README.md index 836eb393..ccbbfbbc 100644 --- a/XLS-0073-disllow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disallow-frozen-trustline-receiving/README.md @@ -1,7 +1,7 @@ 
-Title:       Disallow Receiving on Frozen Trustlines
+Title:       XLS-73d Disallow Receiving on Frozen Trustlines
 Type:        draft
-
+Revision:    1 (2024-07-29)
 Author:      Shawn Xie
 Affiliation: Ripple
@@ -10,7 +10,7 @@ Affiliation: Ripple ## Abstract -This amendment empowers token issuers on the XRP Ledger to regulate tokens in an effort to prevent misuse by blacklisted accounts. This document proposes enhancements to the interactions between frozen assets and payment. This proposal will ensure that blacklisted token holders can no longer receive funds, which will significantly improve use cases such as stablecoins, where ensuring regulatory compliance is essential. +This amendment empowers token issuers on the XRP Ledger to regulate tokens to prevent misuse by blacklisted accounts. The document outlines enhancements to the interactions between frozen assets and payments, ensuring that blacklisted token holders can no longer receive funds. These changes will significantly improve use cases such as stablecoins, where ensuring regulatory compliance is essential. ## 1. Overview This proposal introduces new improvements on how frozen trustlines interacts with payment, offers, DEX and AMM. In essence, trustlines, that have been frozen (either individually or globally), should not be able to receive funds in any way. @@ -57,13 +57,13 @@ Let's take a look at an example where offer is involved in transfering the funds ``` - Bob's Offer -+-------+ USD +---------+ USD +--------------+ XRP +-------+ -| Alice | ---------------------> | Gateway | -------------------> | Sell: 100 XRP| ----------------------> | Carol | -+-------+ SendMax: 100 USD +---------+ +--------------+ +-------+ - Amount: 100 XRP | Buy: 100 USD | - +--------------+ - (Bob is frozen) + Bob's Offer ++-------+ USD +---------+ USD +--------------+ XRP +-------+ +| Alice | ---------------------> | Gateway | ---------------> | Sell: 100 XRP| -----------> | Carol | ++-------+ SendMax: 100 USD +---------+ +--------------+ +-------+ + Amount: 100 XRP | Buy: 100 USD | + +--------------+ + (Bob is frozen) ``` Consider the following scenario: @@ -83,7 +83,7 @@ This proposal introduces a new change to the `OfferCreate` transaction. Currentl Moreover, any existing offers with `TakerPays` currency frozen _can no longer be consumed and will be considered as an _unfunded_ offer that will be implicitly cancelled by new Offers that cross it._ ## 3. Invariants -One potential invariant could be disallowing any increase in the balance of a frozen trustline as a result of a `Payment` transaction. +One potential invariant could be disallowing any increase in the balance of a frozen trustline as a result of any type of transaction. From 3e506b244c5853f9f50428e988549e0a9172862f Mon Sep 17 00:00:00 2001 From: Shawn Xie Date: Mon, 29 Jul 2024 10:09:45 -0400 Subject: [PATCH 09/11] some more comments --- XLS-0073-disallow-frozen-trustline-receiving/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/XLS-0073-disallow-frozen-trustline-receiving/README.md b/XLS-0073-disallow-frozen-trustline-receiving/README.md index ccbbfbbc..7808d44b 100644 --- a/XLS-0073-disallow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disallow-frozen-trustline-receiving/README.md @@ -18,7 +18,7 @@ This proposal introduces new improvements on how frozen trustlines interacts wit ## 2. Specification ### 2.1. Payment Engine -Payment engine executes paths that is made of steps to connect the sender to the receiver. In general, funds can be deposited into a frozen trustline through one of the two steps: +Payment engine executes paths that is made of steps to connect the sender to the receiver. In general, funds can be deposited into a frozen trustline through one of two steps: * Rippling * Order book or AMM @@ -80,7 +80,7 @@ This proposal suggests changing the behavior at __Step 3__ to This proposal introduces a new change to the `OfferCreate` transaction. Currently, if the holder has been frozen, they are still allowed to submit a `OfferCreate` transaction that specifies `TakerPays` as the frozen token, allowing them to receive more funds despite already being frozen by the issuer. We propose the following change: * `OfferCreate` returns `tecFROZEN` if the currency of `TakerPays` has been frozen by the issuer (either individually or globally) -Moreover, any existing offers with `TakerPays` currency frozen _can no longer be consumed and will be considered as an _unfunded_ offer that will be implicitly cancelled by new Offers that cross it._ +Moreover, any existing offers with `TakerPays` currency frozen __can no longer be consumed and will be considered as an _unfunded_ offer that will be implicitly cancelled by new Offers that cross it.__ ## 3. Invariants One potential invariant could be disallowing any increase in the balance of a frozen trustline as a result of any type of transaction. From 0c83be020ffa6b992c50dfe7fd37b957be760717 Mon Sep 17 00:00:00 2001 From: Shawn Xie <35279399+shawnxie999@users.noreply.github.com> Date: Mon, 29 Jul 2024 15:54:12 -0400 Subject: [PATCH 10/11] Update XLS-0073-disallow-frozen-trustline-receiving/README.md Co-authored-by: David Fuelling --- XLS-0073-disallow-frozen-trustline-receiving/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XLS-0073-disallow-frozen-trustline-receiving/README.md b/XLS-0073-disallow-frozen-trustline-receiving/README.md index 7808d44b..f9f9531c 100644 --- a/XLS-0073-disallow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disallow-frozen-trustline-receiving/README.md @@ -10,7 +10,7 @@ Affiliation: Ripple ## Abstract -This amendment empowers token issuers on the XRP Ledger to regulate tokens to prevent misuse by blacklisted accounts. The document outlines enhancements to the interactions between frozen assets and payments, ensuring that blacklisted token holders can no longer receive funds. These changes will significantly improve use cases such as stablecoins, where ensuring regulatory compliance is essential. +This amendment empowers token issuers on the XRP Ledger to prevent token misuse by frozen account holders. The document outlines enhancements to the interactions between frozen assets and payments, ensuring that frozen token holders cannot receive funds until or unless their trustline is unfrozen. These changes will significantly improve use cases such as stablecoins and real world assets (RWA), where ensuring regulatory compliance is essential. ## 1. Overview This proposal introduces new improvements on how frozen trustlines interacts with payment, offers, DEX and AMM. In essence, trustlines, that have been frozen (either individually or globally), should not be able to receive funds in any way. From 1dc9b1cc7aa02646cf6bb9d5e3d720352cd49a26 Mon Sep 17 00:00:00 2001 From: Shawn Xie <35279399+shawnxie999@users.noreply.github.com> Date: Mon, 29 Jul 2024 15:54:25 -0400 Subject: [PATCH 11/11] Update XLS-0073-disallow-frozen-trustline-receiving/README.md Co-authored-by: Mayukha Vadari --- XLS-0073-disallow-frozen-trustline-receiving/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/XLS-0073-disallow-frozen-trustline-receiving/README.md b/XLS-0073-disallow-frozen-trustline-receiving/README.md index f9f9531c..52b9dc26 100644 --- a/XLS-0073-disallow-frozen-trustline-receiving/README.md +++ b/XLS-0073-disallow-frozen-trustline-receiving/README.md @@ -13,7 +13,7 @@ Affiliation: Ripple This amendment empowers token issuers on the XRP Ledger to prevent token misuse by frozen account holders. The document outlines enhancements to the interactions between frozen assets and payments, ensuring that frozen token holders cannot receive funds until or unless their trustline is unfrozen. These changes will significantly improve use cases such as stablecoins and real world assets (RWA), where ensuring regulatory compliance is essential. ## 1. Overview -This proposal introduces new improvements on how frozen trustlines interacts with payment, offers, DEX and AMM. In essence, trustlines, that have been frozen (either individually or globally), should not be able to receive funds in any way. +This proposal introduces new improvements on how frozen trustlines interacts with payment, offers, DEX and AMM. In essence, trustlines, that have been frozen (either individually or globally), should not be able to receive funds in any way. **This is a breaking change.** ## 2. Specification