|
| 1 | +--- |
| 2 | +seo: |
| 3 | + description: A single asset vault aggregates assets from multiple depositors and makes them available to other on-chain protocols. |
| 4 | +labels: |
| 5 | + - Single Asset Vault |
| 6 | +status: not_enabled |
| 7 | +--- |
| 8 | + |
| 9 | +# Single Asset Vault |
| 10 | + |
| 11 | +A single asset vault is an XRP Ledger primitive that aggregates assets from multiple depositors and makes them available to other on-chain protocols, such as the Lending Protocol (currently in development). A vault asset can be [XRP](../../introduction/what-is-xrp.md), a [trust line token](../tokens/fungible-tokens/index.md), or an [MPT (Multi-Purpose Token)](../tokens/fungible-tokens/multi-purpose-tokens.md). |
| 12 | + |
| 13 | +A Vault Owner account manages the vault and can create, update, or delete it as needed. When creating a vault, the Vault Owner can also specify whether shares are transferable or non-transferable. Non-transferable shares cannot be transferred to any other account, and can only be redeemed. |
| 14 | + |
| 15 | +_(Requires the [SingleAssetVault amendment][] {% not-enabled /%}.)_ |
| 16 | + |
| 17 | +## Public vs. Private Vaults |
| 18 | + |
| 19 | +A vault can be **public** or **private**, depending on the required level of access control. |
| 20 | + |
| 21 | +In a public vault, anyone can deposit or redeem liquidity as long as they hold sufficient shares. In contrast, a private vault restricts access, allowing only depositors with the necessary [Credentials](../../concepts/decentralized-storage/credentials.md), managed through [Permissioned Domains](./decentralized-exchange/permissioned-domains.md), to deposit assets. |
| 22 | + |
| 23 | +{% admonition type="warning" name="Warning" %} |
| 24 | +If a depositor's credentials expire, they can no longer deposit assets in a private vault, but can always redeem their existing shares. |
| 25 | +{% /admonition %} |
| 26 | + |
| 27 | +To prevent the Vault Owner from locking funds away, any shareholder in a private vault can redeem their shares for assets. |
| 28 | + |
| 29 | +Choosing between a public or private vault depends on your use case. For example, if depositor identity verification is required, use a private vault and issue credentials only to verified accounts. |
| 30 | + |
| 31 | +## Vault Share Distribution and Redemption |
| 32 | + |
| 33 | +Depositors can deposit assets to receive shares, which represent their proportional ownership of the vault, or redeem shares for assets. |
| 34 | + |
| 35 | +[{% inline-svg file="../../img/single-asset-vault-img.svg" /%}](../../img/single-asset-vault-img.svg "Diagram: an example of an asset being deposited into the vault and shares being redeemed.") |
| 36 | + |
| 37 | +Since the XRP Ledger is an account-based blockchain, all assets must be held by an account. A `Vault` ledger entry cannot hold assets directly, so a [pseudo-account](../accounts/pseudo-accounts.md) is created to hold assets on its behalf. This stand-alone account cannot receive funds or send transactions, and exists solely to store assets and issue shares. |
| 38 | + |
| 39 | +Each share is represented on-chain as an MPT, issued by the vault's pseudo-account. Since MPTs can only exist as whole number units, the vault uses a `Scale` setting to convert fractional asset amounts into whole number shares. |
| 40 | + |
| 41 | +The scale behavior varies based on the type of asset held by the vault: |
| 42 | + |
| 43 | +- **XRP**: Uses a fixed scale that aligns with XRP's native structure, where one share represents one drop. |
| 44 | +- **Trust Line Token**: Allows configurable precision (default preserves 6 decimal places). |
| 45 | +- **MPT**: Uses a 1-to-1 relationship between MPT units and shares. |
| 46 | + |
| 47 | +Depending on the connected protocol, vault shares may be yield-bearing, meaning shareholders could redeem shares for more or less liquidity than they originally deposited. This is because the total asset balance in the vault can grow or shrink over time, affecting the value of each share. However, the vault asset (e.g., USDC, XRP) does not generate yield on its own. |
| 48 | + |
| 49 | +The value of each share depends on the total assets in the vault: |
| 50 | + |
| 51 | +- If the vault earns yield over time, shares represent a larger claim, allowing depositors to redeem them for more assets. |
| 52 | +- If the vault incurs losses, shares hold less value, resulting in lower redemptions. |
| 53 | + |
| 54 | +A vault could generate yield through mechanisms like lending or staking, with yield paid in the same asset deposited. The specific logic for this depends on how the connected on-chain protocol generates yield. For example, if a vault is used by a lending protocol, it could earn yield from interest paid by borrowers. |
| 55 | + |
| 56 | +### Exchange Algorithm |
| 57 | + |
| 58 | +A single asset vault uses an **exchange algorithm** to define how assets convert into shares during deposits and how shares convert back into assets during redemptions. |
| 59 | + |
| 60 | +A vault's total value can fluctuate due to factors like _unrealized losses_, which impact the exchange rate for deposits and redemptions. To ensure fairness, the algorithm adjusts the exchange rate dynamically, so depositors receive shares or redeem them for assets at a rate that accurately reflects the vault’s true value. |
| 61 | + |
| 62 | +#### Unrealized Loss |
| 63 | + |
| 64 | +To prevent depositors from exploiting potential losses by redeeming shares early and shifting the full loss onto the remaining depositors, the vault tracks unrealized losses (or paper loss) using the `LossUnrealized` attribute in the `Vault` ledger entry. |
| 65 | + |
| 66 | +Because the unrealized loss temporarily decreases the vault's value, a malicious depositor may take advantage of this by depositing assets at a lowered price and redeeming shares once the price increases. |
| 67 | + |
| 68 | +For example, consider a vault with a total value of $1.0m and total shares of 1.0m. Let's assume the unrealized loss for the vault is $900k: |
| 69 | + |
| 70 | +1. The new exchange rate is calculated as: |
| 71 | + |
| 72 | + ```js |
| 73 | + // ExchangeRate = (AssetsTotal - LossUnrealized) / SharesTotal |
| 74 | + exchangeRate = (1,000,000 - 900,000) / 1,000,000 |
| 75 | + ``` |
| 76 | + |
| 77 | + The exchange rate value is now **0.1**. |
| 78 | + |
| 79 | +2. After the unrealized loss is cleared, the new effective exchange rate would be: |
| 80 | + |
| 81 | + ```js |
| 82 | + // ExchangeRate = AssetsTotal / SharesTotal |
| 83 | + exchangeRate = 1,000,000 / 1,000,000 |
| 84 | + ``` |
| 85 | + |
| 86 | + The exchange rate is now **1.0**. |
| 87 | + |
| 88 | +A depositor could deposit $100k assets at a 0.1 exchange rate and get 1.0m shares. Once the unrealized loss is cleared, their shares would be worth $1.0m. |
| 89 | + |
| 90 | +To mitigate this, the vault uses separate exchange rates for deposits and redemptions. |
| 91 | + |
| 92 | +#### Exchange Rates |
| 93 | + |
| 94 | +A single asset vault uses **two distinct exchange rates**: |
| 95 | + |
| 96 | +- **Deposit Exchange Rate**: Protects new depositors from prior losses and ensures fair share allocation. |
| 97 | +- **Withdrawal Exchange Rate**: Ensures all shareholders share losses proportionally. Whether redeeming shares or withdrawing assets, the vault always calculates payouts using the actual current value (total assets minus losses), so depositors get their fair share of what's actually in the vault. |
| 98 | + - **Redemptions**: The vault burns shares so the depositor can receive proportional assets. |
| 99 | + - **Withdrawals**: The vault determines the shares to burn based on the requested asset amount. |
| 100 | +
|
| 101 | +These exchange rates ensure fairness and prevent manipulation, maintaining the integrity of deposits and redemptions. |
| 102 | +
|
| 103 | +To understand how the exchange rates are applied, here are the key variables used in the calculations: |
| 104 | +
|
| 105 | +- `Γ_assets`: The total balance of assets held within the vault. |
| 106 | +- `Γ_shares`: The total number of shares currently issued by the vault. |
| 107 | +- `Δ_assets`: The amount of assets being deposited, withdrawn, or redeemed. |
| 108 | +- `Δ_shares`: The number of shares being issued or burned. |
| 109 | +- `l`: The vault's total unrealized loss. |
| 110 | +- `σ`: The scaling factor (σ = 10<sup>Scale</sup>) used to convert fractional assets into whole number shares. |
| 111 | + |
| 112 | +{% tabs %} |
| 113 | + {% tab label="Deposit" %} |
| 114 | + The vault computes the number of shares a depositor will receive as follows: |
| 115 | + |
| 116 | + - **Initial Deposit (Empty Vault)**: For the first deposit into an empty vault, shares are calculated using the scaling factor to properly represent fractional assets as whole numbers. |
| 117 | + |
| 118 | + ```js |
| 119 | + Δ_shares = Δ_assets * σ // σ = 10^Scale |
| 120 | + ``` |
| 121 | + |
| 122 | + - **Subsequent Deposits**: For all other deposits, shares are calculated proportionally. The resulting share value is rounded **down** to the nearest whole number. |
| 123 | + |
| 124 | + ```js |
| 125 | + Δ_shares = (Δ_assets * Γ_shares) / Γ_assets |
| 126 | + ``` |
| 127 | + Because the share amount is rounded down, the actual assets taken from the depositor are recalculated. This ensures the depositor isn't overcharged and that new shares are valued against the vault's true value, accounting for any unrealized loss: |
| 128 | + |
| 129 | + ```js |
| 130 | + Δ_assets = (Δ_shares * (Γ_assets - l)) / Γ_shares |
| 131 | + ``` |
| 132 | + |
| 133 | + After a successful deposit, the _total assets_ and _total shares_ values are updated like so: |
| 134 | + |
| 135 | + ```js |
| 136 | + Γ_assets = Γ_assets + Δ_assets // New balance of assets in the vault. |
| 137 | + Γ_shares = Γ_shares + Δ_shares // New share balance in the vault. |
| 138 | + ``` |
| 139 | + {% /tab %} |
| 140 | + |
| 141 | + {% tab label="Redeem" %} |
| 142 | + The vault computes the number of assets returned by burning shares as follows: |
| 143 | + |
| 144 | + ```js |
| 145 | + Δ_assets = (Δ_shares * (Γ_assets - l)) / Γ_shares |
| 146 | + ``` |
| 147 | + |
| 148 | + After a successful redemption, the _total assets_ and _total shares_ values are updated like so: |
| 149 | + |
| 150 | + ```js |
| 151 | + Γ_assets = Γ_assets - Δ_assets // New balance of assets in the vault. |
| 152 | + Γ_shares = Γ_shares - Δ_shares // New share balance in the vault. |
| 153 | + ``` |
| 154 | + |
| 155 | + {% /tab %} |
| 156 | + |
| 157 | + {% tab label="Withdraw" %} |
| 158 | + When a depositor requests a specific asset amount, the vault uses a two-step process to determine the final payout: |
| 159 | + |
| 160 | + 1. The requested asset amount (`Δ_assets_requested`) is converted into shares. |
| 161 | + |
| 162 | + ```js |
| 163 | + Δ_shares = (Δ_assets_requested * Γ_shares) / (Γ_assets - l) |
| 164 | + ``` |
| 165 | + |
| 166 | + The calculated share amount is rounded to the **nearest** whole number. |
| 167 | + |
| 168 | + 2. The rounded number of shares is used to calculate the final asset payout (`Δ_assets_out`), using the same logic as a redemption. |
| 169 | + |
| 170 | + ```js |
| 171 | + Δ_assets_out = (Δ_shares * (Γ_assets - l)) / Γ_shares |
| 172 | + ``` |
| 173 | + |
| 174 | + Due to rounding in step 1, the final payout may differ slightly from the requested amount. |
| 175 | + |
| 176 | + After a successful withdrawal, the _total asset_ and _total share_ values are updated like so: |
| 177 | + |
| 178 | + ```js |
| 179 | + Γ_assets = Γ_assets - Δ_assets_out // New balance of assets in the vault. |
| 180 | + Γ_shares = Γ_shares - Δ_shares // New share balance in the vault. |
| 181 | + ``` |
| 182 | + |
| 183 | + {% /tab %} |
| 184 | +{% /tabs %} |
| 185 | + |
| 186 | +### Can a Depositor Transfer Shares to Another Account? |
| 187 | + |
| 188 | +Vault shares are a first-class asset, meaning that they can be transferred and used in other on-ledger protocols that support MPTs. However, the payee (or the receiver) must have permission to hold both the shares and the underlying asset. |
| 189 | + |
| 190 | +For example, if a private vault holds USDC, the destination account must belong to the vault’s Permissioned Domain and have permission to hold USDC. Any compliance mechanisms applied to USDC also apply to the shares. If the USDC issuer freezes the payee’s trust line, the payee cannot receive shares representing USDC. |
| 191 | + |
| 192 | +{% admonition type="info" name="Note" %} |
| 193 | +It is important to remember that a vault must be **configured** to allow share transfers, or this will not be possible. |
| 194 | +{% /admonition %} |
| 195 | + |
| 196 | +A depositor can transfer vault shares to another account by making a [Payment](../../references/protocol/transactions/types/payment) transaction. Nothing changes in the way the payment transaction is submitted for transferring vault shares. However, there are new failure scenarios to watch out for if the transaction fails: |
| 197 | + |
| 198 | +- The vault is private and the payee lacks credentials in the vault's permissioned domain. |
| 199 | +- The vault shares are configured as non-transferable. |
| 200 | +- There is a global freeze (trust line tokens) or lock (MPTs) on the underlying asset. |
| 201 | +- The underlying asset is an MPT and is locked for the payer, payee, or vault pseudo-account. |
| 202 | +- The underlying asset is a trust line token and the trust line is frozen between the issuer and the payer, payee, or vault pseudo-account. |
| 203 | +
|
| 204 | +If the transfer succeeds and the payee already holds vault shares, their balance increases. Otherwise, a new MPT entry is created for their account. |
| 205 | +
|
| 206 | +## Compliance |
| 207 | +
|
| 208 | +### Frozen Assets |
| 209 | +
|
| 210 | +The issuer of a vault asset can enact a [freeze](./fungible-tokens/freezes) for trust line tokens or [lock an MPT](./fungible-tokens/deep-freeze#how-does-mpt-freeze/lock-behavior-differ-from-iou). When a vault asset is frozen: |
| 211 | +
|
| 212 | +1. Withdrawals can only be made to the asset’s issuer. |
| 213 | +2. The asset cannot be deposited into the vault. |
| 214 | +3. Its corresponding shares also cannot be transferred. |
| 215 | +
|
| 216 | +### Clawback |
| 217 | +
|
| 218 | +An asset issuer can perform a [Clawback](../../use-cases/tokenization/stablecoin-issuer#clawback) on vault assets by forcing redemption of shares held by an account. This exchanges the holder's shares for the underlying assets, which are sent directly to the issuer. This mechanism allows asset issuers to recover their issued assets from vault depositors when necessary for fraud prevention or regulatory compliance. |
| 219 | + |
| 220 | +## Why Use a Single Asset Vault? |
| 221 | + |
| 222 | +With a single asset vault you don't have to manage liquidity at the protocol level. Instead, you can use the vault to handle deposits, redemptions, and asset tracking separately. |
| 223 | +
|
| 224 | +Vaults handle asset-to-share conversion, ensure accurate pricing, and eliminate the need to add custom logic to calculate exchange rates or account for unrealized losses. |
| 225 | +
|
| 226 | +Depending on the connected on-chain protocol, vaults can be applied to various use cases, such as: |
| 227 | +
|
| 228 | +- Lending markets |
| 229 | +- Aggregators |
| 230 | +- Yield-bearing tokens |
| 231 | +- Asset management |
| 232 | +
|
| 233 | +The only supported use cases right now are _asset management_ and [_lending markets_](https://github.com/XRPLF/XRPL-Standards/discussions/190). |
| 234 | +
|
| 235 | +{% raw-partial file="/docs/_snippets/common-links.md" /%} |
| 236 | +
|
| 237 | +## See Also |
| 238 | +
|
| 239 | +- **Concepts:** |
| 240 | + - [Credentials](../../concepts/decentralized-storage/credentials.md) - Define access requirements for private vaults. |
| 241 | + - [Permissioned Domains](../tokens/decentralized-exchange/permissioned-domains.md) - Control access to private vaults. |
| 242 | + - [Pseudo-Accounts](../accounts/pseudo-accounts.md) - Special accounts that hold assets on behalf of on-chain protocols. |
| 243 | +- **References:** |
| 244 | + - [Vault entry][] - Data structure on the ledger that records vault information. |
| 245 | + - [VaultClawback transaction][] - Allow asset issuers to recover assets from the vault. |
| 246 | + - [VaultCreate transaction][] - Create a new vault for aggregating assets. |
| 247 | + - [VaultDelete transaction][] - Delete an existing vault entry. |
| 248 | + - [VaultDeposit transaction][] - Add assets to a vault in exchange for shares. |
| 249 | + - [VaultSet transaction][] - Update the configuration of an existing vault. |
| 250 | + - [VaultWithdraw transaction][] - Redeem liquidity from a vault. |
| 251 | + - [vault_info method][] - Retrieve information about a vault and its shares. |
0 commit comments