0073 XLS-73d: AMMClawback

[yinyiqian1]

Title:       AMMClawback
Type:        draft

Author:      Shawn Xie
             Yinyi Qian
Affiliation: Ripple

AMMClawback

Abstract

The AMMClawback amendment enables token issuers to claw back tokens from wallets that have deposited into AMM pools, ensuring regulatory compliance. We introduced a new transaction type AMMClawback in this amendment and the AMMClawback transaction is allowed only when lsfAllowTrustLineClawback is enabled by the issuer. lsfAllowTrustLineClawback can be set only if the account has an empty owner directory through AccountSet.

1. Overview

This proposal introduces new improvements on how AMM interacts with frozen asset and clawback.

1.1. AMM and Frozen Asset

Currently if an asset in the AMM pool is frozen (either global or individual), we can still deposit the paired token into the AMM pool (if the paired asset is not frozen). This proposal introduces:

• Prohibit a wallet from depositing new tokens (single-sided and double-sided) into an AMM pool if at least one of the tokens the wallet owns has been frozen (either individually or globally) by the token issuer.

1.2. AMM and Unauthorized Asset

At present, if an account is not authorized to hold a token in the AMM pool, it can still make a single deposit of the other paired token, provided it is authorized for that token. This proposal introduces:

• Prevent a wallet from depositing new tokens (either single-sided or double-sided) into an AMM pool if it is not authorized to hold one or both of the tokens in the pool.

1.3. AMM and Clawback

Currently, accounts that have enabled clawback cannot create AMM pools. This proposal introduces the following:

• Allow an account to create AMM pool even if one of the tokens has enabled lsfAllowTrustLineClawback. However, token issuers will not be allowed to claw back from the AMM account using the Clawback transaction.
• Introduce a new AMMClawback transaction to allow token issuers to exclusively claw back from AMM pools that has one of their tokens, according to the current proportion in the pool.

2. Specification

2.1. Prohibiting the Deposit of New Tokens

This proposal introduces changes to the behavior of the AMMDeposit transaction when tokens in trustlines interact with Automated Market Maker (AMM) pools.

2.1.1. AMMDeposit for Frozen Asset

Assume we have created an Automated Market Maker (AMM) pool with two assets: A and B. Currently, asset A is frozen (either individually or globally). The following table outlines whether specific scenarios are allowed or prohibited for the current behavior and proposed behavior:

Scenario	Current Behavior	Proposed Behavior
Double-Asset Deposit	Prohibited	Prohibited
Only Deposit A (frozen)	Prohibited	Prohibited
Only Deposit B	Allowed	Prohibited

As illustrated in the table above, the primary change is that when one asset in the AMM pool is frozen, depositing the other asset is no longer allowed. This means that deposits are prohibited for the non-frozen asset when its paired asset is frozen.

2.1.1. AMMDeposit for Unauthorized Asset

Assume we have created an Automated Market Maker (AMM) pool with two assets: A and B. The issuer of A has set lsfRequireAuth and the holder is not authorized to hold A.
The table below summarizes the allowed and prohibited scenarios under the current and proposed behavior:

Scenario	Current Behavior	Proposed Behavior
Double-Asset Deposit	Prohibited	Prohibited
Only Deposit A (Unauthorized)	Prohibited	Prohibited
Only Deposit B	Allowed	Prohibited

The primary change is that when the holder is not allowed to hold one of the token in the AMM pool, depositing the other asset is no longer allowed.

2.2. Allowing AMM Pool Creation with Clawback-Enabled Tokens

Currently, when clawback is enabled for the issuer account by setting lsfAllowTrustLineClawback flag, AMMCreate is prohibited against this issuer. After the AMMClawback amendment, AMMCreate is allowed for clawback-enabled issuer. But the issuer can not clawback from the AMM account using Clawback transaction. AMMClawback transaction is needed for the issuer to clawback from an AMM account.

Example: Illustrating the AMMClawback Amendment

Suppose an issuer has enabled clawback by setting the lsfAllowTrustLineClawback flag through an AccountSet transaction. Additionally, two trustlines have been established between the holder and the issuer for currencies A and B

• Pre-Amendment Behavior:

  • If the holder attempts to create an AMM pool (AMMCreate) using the pair of trustline assets A and B associated with the issuer, the transaction will fail with a tecNO_PERMISSION error.

• Post-Amendment Behavior:

  • After the AMMClawback amendment, if the holder submits an AMMCreate transaction to create an AMM pool with assets A and B, the transaction will be successful.
  • However, if the issuer wants to clawback assets from the AMM account, they must use the AMMClawback transaction instead of the regular Clawback transaction.

This change allows for the creation of AMM pools with clawback-enabled issuers while introducing a new transaction type (AMMClawback) for issuers to clawback assets from AMM accounts.

2.3. Introducing a New Transaction for Clawback from AMM Pools

This proposal introduces a new transaction type AMMClawback to allow asset issuers to claw back their assets from the AMM pool.

Issuers can only claw back issued tokens in the AMM pool only if the lsfAllowTrustLineClawback flag is enabled. Attempting to do so without this flag set will result in an error code tecNO_PERMISSION.

By designating the holder account, asset, asset2 and amount, this transaction will:

• Claw back the specified amount of asset held by the specified holder account that are in the specified AMM account.
• This transaction will initiate a two-asset withdrawal of the specified amount of tokens on the current proportion from the AMM pool.
• Provided Asset's issuer should match Account. Otherwise, temMALFORMED will be returned.
• If the issuer only issues one token in the AMM pool:
  • The issuer's asset will return to the issuer's account.
  • The paired asset2 which is not issued by the issuer will be transferred back to the holder's account.
• If the two assets in the AMM pool are both issued by the issuer, this transaction will:
  • The issuer's asset will return to the issuer's account.
  • If tfClawTwoAssets flag is set, the paired asset2 which is also issued by the issuer, will return to issuer as well.
  • If tfClawTwoAssets flag is not set, the paired asset2 will go back to the holder.
• tfClawTwoAssets flag can only be set if the issuer issues both assets in the AMM pool. Otherwise, tecNO_PERMISSION will be returned.
• If the requested amount of tokens exceeds the holder's available balance in the AMM pool, all the tokens owned by the specified holder will be clawed back.
• If amount is not given in the request, all the tokens owned by the specified holder will be clawed back from the pool.

2.3.1. Fields for AMMClawback transaction

Field Name	Required?	JSON Type	Internal Type
TransactionType	✔️	string	UINT16

TransactionType specifies the new transaction type AMMClawback. The integer value is 31. The recommended name is ttAMM_CLAWBACK.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	ACCOUNT ID

Account designates the issuer of the asset being clawed back, and must match the account submitting the transaction.

---

Field Name	Required?	JSON Type	Internal Type
Holder	✔️	string	ACCOUNT ID

Holder specifies the holder account of the asset to be clawed back.

---

Field Name	Required?	JSON Type	Internal Type
Asset	✔️	object	ISSUE

Asset specifies the token that the issuer wants to claw back from the AMM pool. Asset's issuer must match with Account. If it does not, the system will return an error: temMALFORMED. Notice always put the token to be clawed back in Asset insead of Asset2.

It has the following subfields:

Field name	Required?	Description
issuer	✔️	specifies the issuer of the token being clawed back, this should be the same as the Account field
currency	✔️	specifies the currency to be clawed back

---

Field Name	Required?	JSON Type	Internal Type
Asset2	✔️	object	ISSUE

Asset2 specifies the other asset in the AMM pool.

It has the following subfields:

Field name	Required?	Description
issuer		specifies the paired token's issuer, omit for xrp
currency	✔️	specifies the paired token's currency

---

Field Name	Required?	JSON Type	Internal Type
Amount		object	AMOUNT

Amount specifies the amount of token to be clawed back from the AMM account. It should match the Asset field.

• If Amount is not given, all the specified asset will be clawed back.
• If Amount exceeds the holder's current balance in the AMM pool, all the specified token will be clawed back.

It has the following subfields:

Field name	Required?	Description
issuer	✔️	specifies the issuer of the token being clawed back, this should be the same as the Account field
currency	✔️	specifies the currency to be clawed back
value	✔️	specifies the maximum amount of this currency to be clawed back

---

2.3.2. Flags

Flag Name	Hex Value	Description
tfClawTwoAssets	0x00000001	Indicates if the issuer wants to claw back both tokens in the pool. The two assets must both issued by the issuer

• It can be set only when the issuer issues both assets in the AMM pool.
• If set, both the Asset token and the paired toke Asset2 will be clawed back.
• If not set, only the Asset token will be clawed back, and the paired token Asset2 will go back to the holder.

2.3.3. AMMClawback transaction examples

2.3.3.1 Only one token is issued by the issuer

Assume we have an AMM pool consisting two tokens FOO and Bar. And the proportion of FOO and BAR is 1:2. And the issuer rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL only issues FOO, BAR is issued by some other account.

{
  "TransactionType": "AMMClawback",
  "Account": "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
  "Holder": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Asset": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  "Asset2" : {
      "currency" : "BAR",
      "issuer" : "rHtptZx1yHf6Yv43s1RWffM3XnEYv3XhRg"
  },
  "Amount": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
      "value" : "1000"
  }
}

• Upon execution, this transaction enables the issuer rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL to claw back at most 1000 FOO owned by holder rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B from AMM pool FOO/BAR.
• The transaction will result in the withdrawal of two corresponding assets from the AMM account on the current proportion:
  • The asset issued by the Account will be returned to the issuer Account. So 1000 FOO will be returned to the issuer rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL.
  • The other asset will be transferred back to the holder's wallet. Since the proportion of FOO and BAR is 1:2, 2000 BAR will be transferred back to the holder's wallet.
  • If Amount is not given or its subfield value exceeds the holder's available balance, then all the holder's FOO will be clawed back from the AMM pool.
• tfClawTwoAssets can not be set because BAR is not issued by the issuer.

2.3.3.2 Both tokens are issued by the same issuer

Assume we have an AMM pool consisting two tokens FOO and Bar. And the proportion of FOO and BAR is 1:2. And the issuer rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL issues both FOO and BAR.

{
  "TransactionType": "AMMClawback",
  "Account": "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
  "Holder": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Asset": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  "Asset2": {
      "currency" : "BAR",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  "Amount": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
      "value" : "1000"
  },
  "Flags": 1
}

• In this example, tfClawTwoAssets is set in the Flags, so 1000 FOO and 2000 BAR will both go back to the issuer. (If tfClawTwoAssets is not set in the Flags, 1000 FOO will go back to the issuer and 2000 BAR will be transferred back to the holder.)
• If Amount is not given or its subfield value exceeds the holder's available balance, then we will claw back the holder's existing balance of FOO in the AMM pool. And whether BAR will be clawed back or go back to the holder is still determined by the flag tfClawTwoAssets.

2.3.3.3 Clawback all the tokens

{
  "TransactionType": "AMMClawback",
  "Account": "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
  "Holder": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Asset": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  "Asset2" : {
      "currency" : "BAR",
      "issuer" : "rHtptZx1yHf6Yv43s1RWffM3XnEYv3XhRg"
  }
}

• Issuer will clawback all of the holder's FOO token balance in the AMM pool by omitting the Amount field.
• In this example, since BAR is issued by a different issuer, then tfClawTwoAssets is not allowed to be set. All holder's FOO in the AMM pool will be clawed back. And the corresponding BAR will go back to the holder.

2.3.3.4 Clawback all the tokens issued by the same issuer

{
  "TransactionType": "AMMClawback",
  "Account": "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
  "Holder": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Asset": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  "Asset2" : {
      "currency" : "BAR",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  Flags: 1
}

• In this example, both FOO and BAR are issued by the same issuer. So tfClawTwoAssets is allowed to be set.
• Since Amount is not given and tfClawTwoAssets is set, the issuer will clawback all the holder's FOO and the corresponding BAR from the AMM pool. (FOO and BAR clawed back amounts reflect the two-asset withdrawal amounts from redeeming all holder's LPtokens in the AMM pool.)
• tfClawTwoAssets is used to determine if BAR will be clawed back or goes back to the holder.

2.3.3.5 Clawback token from a pool containing XRP

{
  "TransactionType": "AMMClawback",
  "Account": "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
  "Holder": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Asset": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL"
  },
  "Asset2" : {
      "currency" : "XRP",
  },
  "Amount": {
      "currency" : "FOO",
      "issuer" : "rPdYxU9dNkbzC5Y2h4jLbVJ3rMRrk7WVRL",
      "value" : "1000"
  }
}

• In this example, the issuer will clawback 1000 FOO from the AMM pool FOO/XRP. And the corresponding proportion of XRP will go back to the holder.
• Notice XRP can not be clawed back.

[ximinez]

The way the new AMMClawback transaction will work is pretty neat. If I'm understanding correctly, it's effectively simulating two transactions atomically:

1. Simulating as if the Holder account submitted an AMMWithdraw with the tfWithdrawAll flag.
2. Issuing a Clawback from the issuer with the amount set to the entire amount of the issuer's token withdrawn by step 1.

Except it will (presumably) avoid rounding issues.

Is this roughly an accurate description?

Two questions:

1. Why not include an Amount field (maybe optional), like the one in Clawback so that the issuer can only take back a portion of the holdings?
2. If the issuer issued both of the tokens in the AMM, do they get all of both tokens withdrawn by the AMMClawback?

[gregtatcam]

I think issuer has to match AMMAccount in this case, right?

[yinyiqian1]

I think issuer has to match AMMAccount in this case, right?

yes make sense. It should be AMMAccount

[ximinez]

That could introduce a race condition if the Holder is watching for something like this.

could you elaborate on this?

I don't think there's anything in AMMClawback / Clawback that requires the trust line to be frozen. If I'm wrong about this, my whole point is moot. So imagine the scenario:

1. Holder holds two tokens issued by Issuer and puts them into an AMM using those two tokens.
2. Holder knows Issuer is upset with them going to be doing something, so watches the ledger.
3. Issuer neglects to freeze the trust lines, and sends an AMMClawback for one of the tokens.
4. At about the same time, Issuer sends a regular Clawback for the other token.
5. Holder sees the AMMClawback, and quickly sends a Payment transaction to send the other token somewhere else.
6. Now the Clawback and Payment are in a race to see which gets processed first. Chances are the Clawback will win because of the canonical transaction ordering, but it's not guaranteed if Issuer's two transactions are in two different ledgers.

Put another way, for the Issuer to guarantee their clawback would work, they'd have to send a bunch of transactions:

1. Freeze one trust line
2. Freeze the other trust line
3. AMMClawback
4. Regular Clawback
5. Unfreeze one trust line
6. Unfreeze the other trust line.

That's why I think requiring Amount to be the LPToken solves all these problems. It removes all the ambiguity, and rolls those 6 transactions into 1.

[gregtatcam]

I think Amount can still be used for one token and Amount of another token can be calculated proportionally to the pool balances. Then can use equalWithdrawLimit() with both amounts specified. This is still going to be atomic clawback.

[yinyiqian1]

The situation that an issuer issues both assets is rare.
I'm hesitant to include both Amount and Amount2 as it may cause confusion among most issuers, who typically only want to claw the asset they issued and do not care about the other asset. Although Amount and Amount2 are optional fields, their presence may lead to unnecessary complexity.
Issuers who have issued both assets can safely clawback both, provided they follow best practices and freeze the trustlines initially. This scenario is expected to be rare. And we can mention it in the doc.
And issuers mostly prefer to specify the token they issued instead of the lptokens.

[mvadari]

Prohibit a wallet from depositing new tokens (single-sided and double-sided) into an AMM pool if at least one of the tokens the wallet owns has been frozen (either individually or globally) by the token issuer

Is withdrawing already prohibited? If not, is there a reason why it is not being prohibited in this proposal?

[gregtatcam]

Is withdrawing already prohibited? If not, is there a reason why it is not being prohibited in this proposal?

Withdrawing of a frozen token is prohibited.

[Laszlo23]

So can you withdrawle a frozen token? This is still a little confusing for me

[joynancy]

Currently, without this proposed amendment, users cannot withdraw from the AMMPool if the pool contains a pair involving the user's frozen asset.

[cindyyan317]

AMMCreate is allowed for clawback-enabled issuer

For such pool, do we need to include a boolean allowClawback in amm_info's response? eg. account_info also includes allowTrustLineClawback

[yinyiqian1]

Yes. We can add it later

[yinyiqian1]

This is still on the account level. So we will not add it on the amm level.

[DeFiDev589]

Is the clawback feature able to be used to prohibit an account that is not on a blacklist but just trying to single deposit Asset “A” which is an asset that anyone can acquire on the XRP Ledger (For example: XRP or RLUSD) into an AMM Pool paired to Asset “B” which is a regulated asset that they are not authorized to acquire or hold?
It’s my understanding that prior to this amendment anyone could single deposit and single withdraw just ASSET “A” without ever directly interacting with
ASSET “B” but the liquidity provider is able to gain exposure to 50:50 of both assets in the Pool expressed through the LP Token which accrues the AMM fees, CAM revenue, Harvesting Volatility, but also any other benefits that are inherently embedded in ASSET “B”
I hope this new amendment doesn’t remove this accessibility. My understanding is liquidity provider who single deposits only ASSET “A” (XRP or RLUSD)

In a hypothetical AMM Pool between RLUSD/TBILL a retail user could actually single deposit RLUSD and gain exposure to 50% of $TBILL which accrues the off-chain T-Bill Yield in its value gradually increasing.

This makes the LP Token extremely powerful because It’s effectively a Super Stablecoin that is accruing multi Yield Streams that include the On-Chain AMM FEES, CAM revenue , Harvesting Volatility BUT with the addition of OFF-CHAIN Yield from short term US Treasury T-Bills on 50% of the value LP Tokens which is their ownership share. WoW 🤩These hypothetical LP Tokens are Ultra Pristine COLLATERAL. Perfect to use as collateral to borrower $RLUSD or $XRP creating borrow side demand in a secured DeFi Money Market Protocol on EVM Sidechain.

I appreciate your response as it will help the community understand what the possible potential opportunities w we might see built out by Dapp Devs on EVM sidechain utilizing the AMM LP Tokens or in Future on XRPL once supporting amendments are passed and implemented.
Unique advantage is the guaranteed redemption by the XRP Ledger which could trigger liquidation, which I think is extremely unlikely and would only occur if there was a complete collapse of either asset or critical security bug.

Thank You to all the brilliant minds who have been rigorously working continuously enhancing and maintaining the XRPL. Including all those individuals and businesses and universities and projects building on XRPL that run critical infrastructure including nodes, validators, and others. The community XRP Ledger Devs, Cryptographers, Mathematicians, Researchers, and Engineers that are executing on Ripple’s brilliant and very ambitious Roadmap for creating the foundation to support RWA Tokenization, Compliance, Identity Verification, and new enhancements to the core ledger or supporting the necessary
infrastructure to support TradFi adoption institutional DeFi Roadmap.

Final question, can the current XLS-30d AMM SPEC be used with a Stablecoin like RLUSD and an Asset like TBILL tokens that are based on ERC-4626 Vault Contract that gradually but slowly increases the price from the Vault contract distribution of the Yield directly into the the TBILL Token market price,
Thank You

-Mickey B. Fresh “The DeFi Standard"

[yinyiqian1]

Is the clawback feature able to be used to prohibit an account that is not on a blacklist but just trying to single deposit Asset “A” which is an asset that anyone can acquire on the XRP Ledger (For example: XRP or RLUSD) into an AMM Pool paired to Asset “B” which is a regulated asset that they are not authorized to acquire or hold?

If a holder is frozen for asset A, he can not withdraw either A or B(which is the pair asset with A in the AMM pool). Imagine if the holder asset A is frozen for a while and unfrozen later, we don't want him to do some unnecessary things like depositing B into the pool and get any potential loss because he's not able to withdraw anyway.

Final question, can the current XLS-30d AMM SPEC be used with a Stablecoin like RLUSD and an Asset like TBILL tokens that are based on ERC-4626 Vault Contract that gradually but slowly increases the price from the Vault contract distribution of the Yield directly into the the TBILL Token market price

TBILL is based on MPToken. And MPToken interacting with AMM pools is on the roadmap.

[DeFiDev589]

Is the clawback feature able to be used to prohibit an account that is not on a blacklist but just trying to single deposit Asset “A” which is an asset that anyone can acquire on the XRP Ledger (For example: XRP or RLUSD) into an AMM Pool paired to Asset “B” which is a regulated asset that they are not authorized to acquire or hold?

If a holder is frozen for asset A, he can not withdraw either A or B(which is the pair asset with A in the AMM pool). Imagine if the holder asset A is frozen for a while and unfrozen later, we don't want him to do some unnecessary things like depositing B into the pool and get any potential loss because he's not able to withdraw anyway.

Final question, can the current XLS-30d AMM SPEC be used with a Stablecoin like RLUSD and an Asset like TBILL tokens that are based on ERC-4626 Vault Contract that gradually but slowly increases the price from the Vault contract distribution of the Yield directly into the the TBILL Token market price

TBILL is based on MPToken. And MPToken interacting with AMM pools is on the roadmap.

THANK YOU 🙏 for your response
It does make a lot of sense that the “TBILL token” will be based on MPToken spec. After watching the presentation on MPTokens from APEX 2024, I’m so excited for new possibilities MPTokens will bring to the XRP Ledger and the XRPL ecosystem in the future. Especially, with tokenized RWA’s .
Keep up the great work and looking forward to hearing more about this in the future. Thank You!

-Mickey B. Fresh “The DeFi Standard”

[gregtatcam]

Why are we only blocking offer where TakerGets has a frozen LPToken? TakerPays also enables to transfer LPToken into the owner's account.

[yinyiqian1]

The freeze lptoken part will be moved to another amendment.

[gregtatcam]

Providing Asset in AMMClawback is redundant if Amount is also included. Why not only include Amount only? If an issuer wants to clawback everything then Amount is 0.

[yinyiqian1]

updated to use Asset and Asset2 to identify the AMM instance.

[gregtatcam]

AMMClawback uses AMMAccount to identify AMM instance. All AMM transactions (except for AMMCreate) identify AMM by the token pair. The general consensus was that it's simpler for developers. Why are we changing to AMMAccount and making it inconsistent with other AMM transactions? Now developers have to maintain both the token pair and the account. Let's replace AMMAccount with Asset2. Then Asset and Asset2 identify AMM instance. Asset also identifies the token being claw backed. Amount then can be omitted if an issuer wants to claw back all tokens.

[yinyiqian1]

updated to use Asset and Asset2

[yinyiqian1]

Per the new XLS Contributing process, I propose that we can move this discussion to a draft spec: #233

Please comment here if you would like to object to moving this spec/discussion forward in the process into a DRAFT spec.

[nhartner]

Related to a previous question, what's the behavior of AMMClawback transaction against a Holder in an AMM pool where the Holder is only authorized to hold one of the assets from 2 different issuers?
Scenario:

• Token 1: FOO - issued by FOO that has no restrictions
• Token 2: BAR - issued by BAR that has authorized trustlines enabled.
• HOLDER owns 100 FOO tokens
• HOLDER does not have an authorized trustline to issuer BAR so cannot hold BAR tokens
• HOLDER deposits 100 FOO into the FOO/BAR AMM pool. HOLDER receives LP tokens representing 10% of the pool which now has 500 FOO and 500 BAR.
• Issuer FOO submits an AMMClawback transaction against HOLDER and the FOO/BAR AMM pool

What is the result of the AMMClawback transaction? Under normal circumstances, I understand that 50 FOO would be transferred from the AMM pool to Issuer FOO and 50 BAR would be transferred to HOLDER. But in this scenario, HOLDER is not authorized to hold BAR. As such, I can see a few possible options:

• AMMClawback transaction is rejected. Issuer FOO will not be able to clawback tokens from this HOLDER in the pool.
• 100 FOO are transferred from AMM to Issuer FOO. No BAR tokens are removed from pool.

[yinyiqian1]

Yes, a trustline will be create for BAR

[mvadari]

Would the user be charged a reserve for that trustline? What if they don't have the XRP for that?

Why not, in this situation, just withdraw all the liquidity in FOO?

[joynancy]

If a user holds LP tokens representing FOO/BAR 1:1 in an AMM pool, and the FOO issuer initiates a clawback of all of the user's FOO from AMMs:

Current Design (A):

50% of the user's value, represented in FOO, is clawed back by the issuer. The remaining 50% in BAR is returned to the user, even if no trust line had been previously established for BAR (setting aside the XRP reserve requirement for now).

Alternative Design (B):

Because of user has no trust line established for BAR, and system to avoid establishing a new trust line on-behalf, in this case, when AMMClawback, a single-sided clawback on FOO is initiated, resulting in 100% of the user's value being clawed back by the issuer, leading to a double loss for the user.

In comparison, other LP token holders with both trust lines face only a 50% clawback of their value.

From my perspective, adopting Design B offers no clear benefit. It significantly disadvantages the user, penalizing them more than necessary. Moreover, I believe issuer is not meant to reclaim more than the 50% value held in FOO by the user. If I were the user being clawback, if 10 XRP reserve is needed, I'd rather pay to keep my 50% value of BAR.

---

Separately for the XRP reserve, I recall from my experience trading on DEX that even if I swap into an asset for which I don’t have an established trust line, I can still receive the new token. However, in order to use the token, I need to approve the trust line and pay the XRP reserve. This implies that to fully activate a trust line, the user must manually approve it and cover the XRP reserve fee. However, my observation is subject to validation.

[mvadari]

• What if BAR is an authorized token, and the issuer hasn't authorized the user to hold the token?
• What if the user doesn't want to hold BAR (perhaps for compliance or tax reasons)?

Separately for the XRP reserve, I recall from my experience trading on DEX that even if I swap into an asset for which I don’t have an established trust line, I can still receive the new token. However, in order to use the token, I need to approve the trust line and pay the XRP reserve. This implies that to fully activate a trust line, the user must manually approve it and cover the XRP reserve fee. However, my observation is subject to validation.

Yes, but the user essentially signed up to hold that asset by placing the order. They did no such thing when depositing into an AMM - they only signed up to hold the LP Token.

[joynancy]

What if BAR is an authorized token, and the issuer hasn't authorized the user to hold the token?

Refer to 1.2 in the specs: Prevent a wallet from depositing new tokens (either single-sided or double-sided) into an AMM pool if it is not authorized to hold one or both of the tokens in the pool.
Once the change is implemented, I think such scenario shouldn't happen.

What if the user doesn't want to hold BAR (perhaps for compliance or tax reasons)?

AMMClawback is essentially an edge case, typically applied when the account holder has been identified as involved in criminal activity or is subject to sanctions. The process of clawback is inherently unpleasant for the affected user, and it is unlikely that any solution will fully satisfy the user. The purpose of creating this primitive is to provide issuers with a compliance tool, allowing them to take whatever actions are necessary to protect the integrity of the financial system. At the same time, the blockchain itself should remain neutral, acting as a platform for enforcement without taking a position on the decisions made by the issuer.

[yinyiqian1]

Since we had more discussions, I'll check it again:

Per the new XLS Contributing process, I propose that we can move this discussion to a draft spec: #233

Please comment here if you would like to object to moving this spec/discussion forward in the process into a DRAFT spec.