0065 XLS - 65d: Managed Single Asset Tokenized Pool

[Tapanito]

    
Title:        Managed Single Asset Tokenized Pool
Revision:     1 (2024-04-12)

Authors:    
  Vytautas Vito Tumas
  Aanchal Malhotra

Affiliation:
  Ripple

Managed Single Asset Tokenized Pool

Abstract

We propose a tokenized Pool object standard to represent ownership shares of XRP or a single Fungible Token. We also propose standard interfaces to interact with the Pool object. Tokenized pools serve diverse purposes, such as lending markets, aggregators, yield-bearing tokens, etc. While the specific protocol design & implementation for each of these use cases may vary, this document establishes a universal framework to enable a unified and common standard that fosters the development and expansion of diverse use cases.

1. Introduction

Tokenized Pools have well-established standards in the broader blockchain ecosystem. To facilitate the adoption of the XRP Ledger in the cryptocurrency ecosystem, we propose following the ERC-4626 standard. The standard introduces a minimal interface implemented by protocols relying on tokenized pools.

An early standard establishes minimum functional requirements for protocols requiring a Tokenized Pool. Furthermore, a single standard lowers the effort required for future protocol design and implementation.
Adopting an already established standard will simplify the integration of XRP Ledger with existing frontends.

Goals

• Introduce a flexible ledger entry to represent a tokenized pool. Think of this as a building block in the arsenal of future protocol designers.
• Introduce abstract transactions to create, delete and modify the state of a Pool.
  • The concrete implementation logic of these transactions is protocol-specific.
• Introduce abstract read-only methods to interact with a Pool instance.

1.1. Terminology

1. Pool: A construct that locks user-deposited assets in a shared yield-bearing pool.
2. Asset: The currency of a pool. It is either XRP or a Fungible Token.
3. LPTokens: Liquidity Provider Tokens (LPTokens) represent the liquidity providers' share of the pool instance. LPTokens are Fungible Token issued by the pseudo-account of the Pool. A Trust Line maintains the balance of LPTokens between the Liquidity Provider and the pools pseudo-account.

1.2. Actors

1. Pool Delegate: An account responsible for creating, deleting, and managing a pool day-to-day. Specific obligations and capabilities are implementation-specific.
2. Liquidity Provider: An entity that deposits and withdraws assets to and from a pool.

2. New Pool Ledger Entry

A Pool Ledger Entry represents the state of a tokenized pool. It contains fields necessary to identify a pool and general field details containing protocol-specific fields.

A Pool requires a unique ID to identify the object. We do not limit the number of pools a single account may create. Therefore, the unique pool `ID' must uniquely identify multiple pools created by the same account for the same Asset.

We propose to use a similar technique to generate a Pool ID as is used to create an Offer Object ID:

• Calculate SHA512-Half of the following values:
  • The Pool space key 0x0050 (capital P)
  • The AccountID of the account creating the pool.
  • The Sequence number of the transaction creating the Pool. If the transaction used a Ticket, use the TicketSequence value.

The Pool ledger entry contains the following fields:

1. Account specifies the ID of the AccountRoot object associated with the Pool ledger entry.
2. DelegateAccountID specifies the ID of the account creating the Pool object. Note that DelegateAccountID != Account.
3. DelegateAccountURI specifies an URI to an off-chain identifier of the Pool Delegate.
4. PoolSequence specifies the Sequence number of the transaction that created the Pool.
5. Asset specifies the Asset of the Pool instance.
6. LPTokenBalance specifies the balance of the outstanding liquidity provider tokens (LPTokens).
7. AvailableLiquidity specifies the liquidity available in the Pool.
8. Type specifies the concrete type of the Pool. For example, LendingPool, Aggregator or others.
9. Frozen indicates whether the Pool is frozen.
10. Details specifies protocol-specific fields. A protocol that uses a Pool instance specifies the content of this object. The details field allows for a flexible design and reduces the number of unique ledger entry types needed.

2.1. LPTokens

Liquidity Provider Tokens (LPTokens) represent a share of the Pool the holder owns. A Trust Line tracks the balance of LPTokens. However, some pools may require LPTokens to be non-transferable. Therefore, configuring whether assets are transferable is left to a specific implementation.

LPTokens are uniquely identified by the following:

• issuer the Pool instance Account ID and;
• currency the currency code for LPTokens is formed deterministically LPTokenID = 0x03 + first 19 bytes from the unique PoolID. We also leave the option open for the protocol to implement their currency code generation scheme.

2.2. AccountRoot Entry

An AccountRoot entry tracks the balance of XRP or Token, issued LP Tokens, and other protocol-specific assets, such as collateral.

The following rules must apply to the AccountRoot ledger entry associated with a pool:

• It is not subject to the reserve requirement.
• It cannot be the destination of Checks, Escrows, or Payment Channels. Any transactions creating such entries MUST fail with the result code tecNO_PERMISSION.
• Users cannot create trust lines to it for anything other than the LP Tokens. Transactions creating such trust lines MUST fail with result code tecNO_PERMISSION.
• An issuer of the Pool's Token cannot clawback funds.

Special Considerations for the pseudo-account

• lsfDefaultRipple controls whether users can send pseudo-account issued tokens amongst themselves. It is an implementation-specific flag.

3. CUD Pool instance transactions

This proposal introduces transactions to interact with a Pool object. It specifies general fields and rules for Create, Update and Delete transactions. However, the protocol-specific logic is left to the users of the Pool.

3.1. Create a Pool instance transaction

A transaction creating a Pool MUST include the following fields.

3.1.1 Common transaction fields

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

TransactionType specifies the new transaction type. The integer value is 55.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	AMOUNT

Fee specifies the integer amount of XRP, in drops, to be destroyed as a cost of creating a Pool instance.

---

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

Asset specifies the asset, XRP or Fungible Token, of the Pool instance.

---

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

Type specifies the concrete type of the Pool. This is a protocol-specific value.

---

Field Name	Required?	JSON Type	Internal Type
PoolDelegateURI		string	BLOB

---

Field Name	Required?	JSON Type	Internal Type
Details	✔️	object	BLOB

Details specifies the protocol-specific values for the Pool.

---

3.1.2. Failure Conditions

The Create transaction MUST fail when:

• The account creating the Pool is NOT the issuer of the Token AND
  • The RequireAuth flag for the Token is set AND
  • The account initiating the transaction is not authorized.
• The asfGlobalFreeze is NOT set for the issuer account.
• The issuer of the Token has the DefaultRipple flag disabled.
• Pool Type is not supported.

3.1.3. State Changes

If the transaction is successful:

• Three new ledger entries [Pool, AccountRoot, DirectoryNode] are created.
  The regular key for the AccountRoot ledger entry is set to account zero, and the master key is disabled. This effectively prevents all ways of signing transactions from this account.

3.1.3. Trustlines

A successful Create transaction will automatically create at least the following trust lines:

• If the deposited Asset is a Fungible Token, a Trust Line to track the balance between the Pool account and the issuer of the Fungible Token.
• Create a Trust Line for the Pool's LPTokens.

Specific protocols may create additional Trust Lines.

3.1.4. Pool Reserve Funds

The account that creates a Pool object incurs one owner reserve (2 XRP at the time of writing this document).

3.2. Update a Pool instance transaction

A transaction updating a Pool MUST include the following fields.

3.2.1 Common transaction fields

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

TransactionType specifies the new transaction type. The integer value is 56.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

Indicates the account that initiated the transaction. Account must equal the Pool.DelegateAccountID field.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	AMOUNT

Fee specifies the integer amount of XRP, in drops, to be destroyed as a cost of modifying a Pool instance.

---

Field Name	Required?	JSON Type	Internal Type
PoolSequence	✔️	number	UINT32

Sequence number of the Pool instance.

---

Field Name	Required?	JSON Type	Internal Type
PoolDelegateURI		string	BLOB

---

Field Name	Required?	JSON Type	Internal Type
Frozen		'boolean'	BOOL

---

Field Name	Required?	JSON Type	Internal Type
Details	✔️	struct	BLOB

Details is a struct with the protocol-specific fields.

---

3.2.2 Failure Conditions

The transaction MUST fail if the AccountID of the transaction DOES NOT equal PoolDelegateID.

3.2.3 State Changes

The transaction modifies the Details field of the Pool.

3.3. Delete a Pool instance transaction.

3.3.1. Common transaction fields

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

TransactionType specifies the new transaction type. The integer value is 57.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

Indicates the account that initiated the transaction. Account must equal the Pool.DelegateAccountID field.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	AMOUNT

Fee specifies the integer amount of XRP, in drops, to be destroyed as a cost of deleting a Pool instance. TODO: what is the specific fee?

---

Field Name	Required?	JSON Type	Internal Type
PoolSequence	✔️	number	UINT32

Sequence number of the Pool instance.

---

3.3.2 Failure Conditions

The transaction MUST fail if the AccountID of the transaction DOES NOT equal PoolDelegateID.
The transaction MUST fail if the LPTokenBalance of the Pool are NOT zero.

3.3.3 State Changes

Delete the Pool ledger entry.
Delete the AccountRoot object.
Delete the DirectoryNode object.
Delete all associated Trust Lines.
Release Owner Funds.

4. LiquidityProvider Transactions

The following transactions add or remove assets to a Pool instance. Protocols may constrain who can make the transactions and the amount of tokens that can be deposited or withdrawn.

1. Deposit: The deposit transaction adds liquidity to the Pool in exchange for shares of the instance in the form of LPTokens.
2. Withdraw: The withdraw transaction removes liquidity from the Pool instance in exchange for LPTokens issued by the AccountRoot of the Pool.
3. Redeem: The redeem transaction exchanges some amount of LPTokens for the equivalent amount of assets in the Pool.

4.1 Deposit transaction

The Deposit transaction adds Liqudity in exchange for LPTokens of the Pool.

4.1.1 Computing LPToken shares

Assume the following variables that define the pool balance:

• $\Gamma_{LPTokens}$ - the total number of LPTokens issued by the Pool.

• $\Gamma_{Asset}$ - the total assets in the Pool, including any accrued yield. How to compute this value is protocol-specific.

• $\Delta_{Asset}$ - the change in the total amount of assets.

• $\Delta_{LPTokens}$ - che change in the total amount of LPTokens.

We compute the number of shares a liquidity provider will issue as follows:

$$\Delta_{LPTokens} = \frac{\Delta_{Assets} \times (\Gamma_{LPTokens} + 0^{LPTokens})}{\Gamma_{Assets} + 0^{Assets}} $$

Following is the updated pool composition after the successful deposit:

• $\Gamma_{Assets} = \Gamma_{Assets} + \Delta_{Assets}$ New balance of assets in the pool.
• $\Gamma_{LPTokens} = \Gamma_{LPTokens} + \Delta_{LPTokens}$ New LPToken balance in the pool.

4.1.2 Common transaction fields

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

TransactionType specifies the new transaction type. The integer value is 58.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

Indicates the account that initiated the transaction.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	AMOUNT

Fee specifies the integer amount of XRP, in drops, to be destroyed as a cost of depositing assets to the Pool.

---

Field Name	Required?	JSON Type	Internal Type
Amount	✔️	string or object	AMOUNT

Amount specifies the amount of the pool asset to deposit. Amount is a string when the Asset of the Pool is XRP. Otherwise, it is an AMOUNT object.

---

Field Name	Required?	JSON Type	Internal Type
PoolSequence	✔️	number	UINT32

Sequence number of the Pool instance.

---

Field Name	Required?	JSON Type	Internal Type
PoolDelegateID	✔️	String	AccountID

The PoolDelegateID of the Pool.

---

4.1.3 Failure Conditions

The transaction MUST fail when:

• The liquidity provider does not have sufficient funds to make a deposit.
• The asset type of the Pool does not match the asset type the Liquidity Provider is depositing.
• The Pool is frozen.

4.1.4 State Changes

• If the deposited Asset is XRP, it is transferred from the account initiating the transaction to the AccountRoot of the Pool, updating the Balance field of both accounts.
• If the deposited Asset is a Token, the balance between the Pool instance account and the issuer account is adjusted.
• The Pool account issues $\Delta_{LPTokens}$ to the account that issued the transaction. Create a new Trust Line if one does not exist.
• Increase the LPTokensBalance of the Pool by $\Delta_{LPTokens}$.
• Increase the AvailableLiquidity of the Pool by $\Delta_{Assets}$.

4.2. Withdraw transaction

The Withdraw transaction withdraws Tokens in exchange for an equivalent number of LPTokens.

4.2.1. Computing LPToken shares

Assume the following variables that define the pool balance:

• $\Gamma_{LPTokens}$ - the total number of LPTokens issued by the Pool.

• $\Gamma_{Asset}$ - the total assets in the Pool, including any accrued yield. Computing this value is protocol-specific.

• $\Delta_{Asset}$ - the amount of assets the Liquidity Provider wants to withdraw.

• $\Delta_{LPTokens}$ - the amount of LPTokens to burn.

We compute the number of LPTokens to burn to withdraw $\Delta_{Assets}$ as follows:
$$\Delta_{LPTokens} = \frac{\Delta_{Assets} \times (\Gamma_{LPTokens} + 0^{\Gamma_{LPTokens}})}{\Gamma_{Assets} + 0^{\Gamma_{Assets}}} $$

Following is the updated pool composition after the successful deposit:

• $\Gamma_{Assets} = \Gamma_{Assets} - \Delta_{Assets}$ New balance of assets in the pool.
• $\Gamma_{LPTokens} = \Gamma_{LPTokens} - \Delta_{LPTokens}$ New LPToken balance in the pool.

4.2.2 Common transaction fields

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

TransactionType specifies the new transaction type. The integer value is 59.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

The ID of the account that initiated the transaction and received the funds.

---

Field Name	Required?	JSON Type	Internal Type
Destination		string	AccountID

Destination is an optional field. It indicates a separate account to receive the assets. The destination account must meet all the requirements to hold the Asset.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	AMOUNT

Fee specifies the integer amount of XRP, in drops, to be destroyed as a cost of depositing assets to the Pool.

---

Field Name	Required?	JSON Type	Internal Type
Amount	✔️	string or object	AMOUNT

Amount specifies the amount of the pool asset to withdraw. Amount is a string when the Asset of the Pool is XRP. Otherwise, it is an AMOUNT object.

---

Field Name	Required?	JSON Type	Internal Type
PoolSequence	✔️	number	UINT32

Sequence number of the Pool instance.

---

Field Name	Required?	JSON Type	Internal Type
PoolDelegateID	✔️	String	AccountID

The PoolDelegateID of the Pool.

---

4.2.3. Failure Conditions

• The liquidity provider does not have sufficient LPTokens to withdraw funds from the Pool.
• The asset type of the Pool does not match the asset type the Liquidity Provider is withdrawing.
• The Pool is frozen.

4.2.4. State Changes

• If the withdrawn Asset is XRP, it is transferred from the Pool instance account to the account initiating the transaction, updating each account's Balance field.
• If the withdrawn Asset is a token, the balance between the Pool instance account and the issuer account is adjusted.
• The Pool account burns $\Delta_{LPTokens}$ from the account that issued the transaction. Delete the Trust Line if its balance is zero.
• Decrease the LPTokensBalance of the Pool by $\Delta_{LPTokens}$.
• Decrease the AvailableLiquidity of the Pool by $\Delta_{Asset}$.

4.2.5. Frozen Assets

An IOU issuer may enact a Global Freeze on issued Fungible Tokens. If a frozen token is in a Pool, it is withdrawable by specifying the Destination account as the issuer of the Asset.

4.3. Redeem transaction

The Redeem transaction burns a specified number of LPTokens in exchange for Tokens of the Pool.

4.3.1. Computing assets

Assume the following variables that define the pool balance:

• $\Gamma_{LPTokens}$ - the total number of LPTokens issued by the Pool.

• $\Gamma_{Asset}$ - the total assets in the Pool, including any accrued yield. Computing this value is protocol-specific.

• $\Delta_{Asset}$ - the amount of assets the user will receive.

• $\Delta_{LPTokens}$ - the amount of LPTokens the user wants to burn.

We compute the number of assets returned by burning $\Delta_{LPTokens}$ as follows:

$$\Delta_{Assets} = \frac{\Delta_{LPTokens} \times (\Gamma_{Assets} + 0^{Assets})}{\Gamma_{LPTokens} + 0^{LPTokens}} $$

Following is the updated pool composition after the successful deposit:

• $\Gamma_{Assets} = \Gamma_{Assets} - \Delta_{Assets}$ New balance of assets in the pool.
• $\Gamma_{LPTokens} = \Gamma_{LPTokens} - \Delta_{LPTokens}$ New LPToken balance in the pool.

4.3.2. Common transaction fields

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

TransactionType specifies the new transaction type. The integer value is 60.

---

Field Name	Required?	JSON Type	Internal Type
Account	✔️	string	AccountID

Indicates the account that initiated the transaction.

---

Field Name	Required?	JSON Type	Internal Type
Fee	✔️	string	AMOUNT

Fee specifies the integer amount of XRP, in drops, to be destroyed as a cost of depositing assets to the Pool.

---

Field Name	Required?	JSON Type	Internal Type
LPTokensOut	✔️	string	AMOUNT

LPTokensOut specifies the maximum amount of LPTokens the account instantiating the transaction is willing to exchange.

---

Field Name	Required?	JSON Type	Internal Type
PoolSequence	✔️	number	UINT32

Sequence number of the Pool instance.

---

Field Name	Required?	JSON Type	Internal Type
PoolDelegateID	✔️	String	AccountID

The PoolDelegateID of the Pool.

---

Field Name	Required?	JSON Type	Internal Type
Destination		string	AccountID

Destination is an optional field. It indicates a separate account to receive the assets. The destination account must meet all the requirements to hold the Asset.

---

4.3.3. Failure Conditions

• The liquidity provider does not have sufficient LPTokens to redeem funds from the Pool.
• The issuer of LPTokensOut does not match the pseudo-account of the Pool.
• The Pool is frozen.

4.3.4. State Changes

• If the withdrawn Asset is XRP, it is transferred from the Pool instance account to the account initiating the transaction, updating each account's Balance field.
• If the withdrawn Asset is a token, the balance between the Pool instance account and the issuer account is adjusted.
• The Pool account burns $\Delta_{LPTokens}$ from the account that issued the transaction. Delete the Trust Line if its balance is zero.
• Decrease the LPTokensBalance of the Pool by $\Delta_{LPTokens}$.
• Decrease the AvailableLiquidity of the Pool by $\Delta_{Asset}$.

4.2.5 Frozen Assets

An IOU issuer may enact a Global Freeze on issued Fungible Tokens. If a frozen token is in a Pool, it is only redeemable by specifying the Destination account as the issuer of the Asset.

5. Read-Only Methods

We introduce the following read-only methods to simplify the interaction with the Pool.

• ConvertTo: methods are rough estimates that do not account for operation-specific details like withdrawal fees, slippage, etc. They are for frontends and applications that need an average value of shares or assets, not an exact value.

• Preview: methods are for applications that need an exact value that attempts to account for fees and slippage. We include a preview method to match each mutable transaction. These methods must not account for deposit or withdrawal limits to ensure they are easily composable.

• Max: methods provide the maximum asset amount an account may deposit or withdraw from a Pool.

5.1. ConvertToLPTokens

The ConvertToLPTokens method returns the amount of LPTokens the Pool would exchange for the Tokens provided.

The result:

• MUST NOT include any fees.
• MUST NOT show any variations depending on the caller.
• MUST NOT reflect any on-chain conditions when performing the actual exchange.
• MUST round down towards 0.

This calculation MAY NOT reflect the per-user price-per-share. Instead, it should reflect the “average user’s” price-per-share, meaning what the average user should expect to see when exchanging to and from.

5.2 ConvertToAssets

The ConvertToAssets method returns the amount of Tokens the Pool would exchange for the LPTokens provided.

The result:

• MUST NOT include any fees charged against Tokens in the Pool.
• MUST NOT show any variations depending on the caller.
• MUST NOT reflect on-chain conditions.
• MUST round down towards 0.

This calculation MAY NOT reflect the per-user price-per-share. Instead, it should reflect the “average user’s” price-per-share, meaning what the average user should expect to see when exchanging to and from.

5.3 PreviewDeposit

The PreviewDeposit method simulates the effects of the Deposit transaction at the current ledger, given the current XRP Ledger state.

The result:

• MUST NOT modify the XRP Ledger state.
• MUST return as close to and no more than the LPTokens minted by a Deposit transaction. I.e. Deposit should return the same or more LPTokens as PreviewDeposit if executed in the same ledger.
• MUST NOT account for deposit limits like those returned from MaxDeposit and should always act as though the deposit would be accepted, regardless of whether the user has enough assets.
• MUST be inclusive of any fees. Integrators should be aware of the existence of deposit fees.
• MUST NOT fail due to pool-specific user/global limits.
• MAY fail due to other conditions that would cause Deposit to fail.

Note that an unfavourable discrepancy between ConvertToLPTokens and PreviewDeposit SHOULD be considered slippage in share price or other conditions, meaning the depositor will lose assets by depositing.

5.4 PreviewWithdraw

The PreviewWithdraw method simulates the effects of the Withdraw transaction at the current ledger, given the current XRP Ledger state.

The result:

• MUST NOT modify the XRP Ledger state.
• MUST return as close to and no more than the LPTokens burned by a Withdraw transaction. I.e. Withdraw should return the same or more LPTokens as PreviewWithdraw if executed in the same ledger.
• MUST NOT account for withdrawal limits like those returned from MaxWithdraw and should always act as though the withdrawal would be accepted, regardless of whether the user has enough LPTokens.
• MUST be inclusive of any fees. Integrators should be aware of the existence of withdrawal fees.
• MUST NOT fail due to pool-specific user/global limits.
• MAY fail due to other conditions that would cause Withdraw to fail.

Note that an unfavourable discrepancy between ConvertToLPTokens and PreviewWithdraw SHOULD be considered slippage in share price or other conditions, meaning the withdrawer will lose assets by withdrawing.

5.5 PreviewRedeem

The PreviewRedeem method simulates the effects of the Redeem transaction at the current ledger, given the current XRP Ledger state.

The result:

• MUST NOT modify the XRP Ledger state.
• The assets returned by a 'Redeem' transaction MUST be as close as possible to and no more than those returned by a PreviewRedeem transaction. For example, Redeem should return the same or more assets as PreviewRedeem if executed in the same ledger.
• MUST NOT account for redeem limits like those returned from MaxRedeem and should always act as though the redeem would be accepted, regardless of whether the user has enough LPTokens.
• MUST be inclusive of any fees. Integrators should be aware of the existence of redemption fees.
• MUST NOT fail due to pool-specific user/global limits.
• MAY fail due to other conditions that would cause Redeem to fail.

Note that an unfavourable discrepancy between ConvertToAssets and PreviewRedeem SHOULD be considered slippage in share price or other conditions, meaning the redeemer will lose assets by redeeming.

5.6 MaxDeposit

The MaxDeposit method returns the maximum asset amount a user can deposit into the Pool with the Deposit transaction given the current XRP Ledger state.

The result:

• MUST return as close as possible and no more than the assets deposited by a Deposit transaction. I.e., MaxDeposit must be lower than the Deposit transaction.
• MUST assume the user has sufficient assets.
• MUST factor in global and user-specific limits.
• MUST return zero when depositing is disabled (even temporarily).
• MUST return $2^{256} - 1$ when the maximum depositable asset amount is unlimited.

5.7 MaxWithdraw

The MaxWithdraw method returns the maximum asset amount a user can withdraw from the Pool with the Withdraw transaction given the current XRP Ledger state.

The result:

• MUST return as close as possible and no more than the assets withdrawn by a Withdraw transaction. For example, MaxWithdraw must be lower than the Withdraw transaction.
• MUST assume the user has sufficient LPTokens.
• MUST factor in global and user-specific limits.
• MUST return zero when withdrawing is disabled (even temporarily).

5.8 MaxRedeem

The MaxRedeem method returns the maximum LPToken amount a user can withdraw from the Pool with the Redeem transaction given the current XRP Ledger state.

The result:

• MUST return as close as possible and no more than the LPTokens burned by a Redeem transaction. I.e. MaxRedeem must be lower than the Redeem transaction.
• MUST assume the user has sufficient LPTokens.
• MUST factor in global and user-specific limits.
• MUST return zero when redeeming is disabled (even temporarily).

[xVet]

For the CUD operations, i wonder, why is the PoolDelegate the only account able to perform update operations and delete operations. Including updates to the PoolDelegateID.

I would expect that the AccountID creating the Pool is the owner and delegates to the PoolDelegate limited functionality.

[rothexD]

Yes Flash-Loan-Pool would be a type of public Pool that would have weighted fee voting shares. I just used it as an example because it was the first hing that came to mind, will have to think about how this applies to protocol based amms

Another shared governance scenario that I was thinking about for a longer time would be a type of Pool where users can lock up assets up to a specific date and after that date if at least 50% of LP-token holders and 50% of LP-tokens agree the funds will be released to a beneficiary. If a quorum is not reached until an end date the assets can be reclaimed by their original holders. This would allow some type of shared community investment/funding (I am not sure about the legal side of this). You could then also do some type of release rounds where x% of assets get released. I have done no research yet if the community would even be interested in something like that. For example a community could fund the development of a video game using that and their next round of fund/ will only be released if milestones are reached and agreed on in a quorum.

I think a lot of what i think about lately can be solved using hooks but not sure if those ever come to main :D

[rothexD]

I think flash loans would only be useful if aams have experienced single side deposits and you can then use this imbalance to balance out all of the aams that have related pairs.

For example:

XRP-Flash-Loan-Pool

XRP/USDX
USDX/KUI
KUI/XRP

For example a lot of KUI are single side deposited into the USDX/KUI pair, you could then flash-loan and get XRP to trade for USDX and put those USDX back into the USDX/KUI pair while taking out KUI to swap it back to XRP.

I hope I didn't miss something there... :D

[xVet]

Thanks @xVet !

The idea is that a PoolDelegate is the pool's owner, and thus, the PoolDelegateID is not changeable. However, now that I think about it, there is no "delegacy" in this case.

Do you think it would be better to have a separate PoolOwner and PoolDelegate where the PoolOwner has all permissions of the Delegate, including deleting the pool and changing the PoolDelegate. Whereas the PoolDelegate may only perform protocol specific operations?

Exactly! I think it makes sense to change the name to PoolOwner and give the owner AccountID the ability to do a AccountSet Flag asfPoolDelegate for delegating functionality to a delegate.

Thoughts on that ?

[mvadari]

I think it makes sense to change the name to PoolOwner and give the owner AccountID the ability to do a AccountSet Flag asfPoolDelegate for delegating functionality to a delegate.

I don't quite understand the need for the flag. Do you mean something similar to NFTokenMinter? If so, IMO in this case that should be on the pool and not on the account.

[Tapanito]

Exactly! I think it makes sense to change the name to PoolOwner and give the owner AccountID the ability to do an AccountSet Flag asfPoolDelegate for delegating functionality to a delegate.

If we introduce a second entity, PoolOwner, I agree with 1). However, I'm not sure about the asfPoolDelegate flag. I think the Pool should be self-contained. The spec should not introduce Pool specific changes to other ledger entries. That is primarily to minimize coupling with other ledger entries. By minimizing coupling, we make the ledger entry easier to change. Or that is the hope at least.

That said, we can achieve the same functionality by introducing two fields, PoolDelegate and PoolOwner to the Pool object. What do you think about that?