mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2026-01-28 10:35:21 +00:00
Compare commits
13 Commits
section/ca
...
sav-concep
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0a5a59b441 | ||
|
|
ab9d0d54ae | ||
|
|
3853484deb | ||
|
|
c9a560441f | ||
|
|
a789936ad2 | ||
|
|
5455108464 | ||
|
|
2b1216012e | ||
|
|
8f853ffb0b | ||
|
|
ba7a756e39 | ||
|
|
24ba1687f9 | ||
|
|
e4aa7010d9 | ||
|
|
4eeb2d2d49 | ||
|
|
e4cdb7ccea |
@@ -124,9 +124,9 @@ XRP Ledgerは、スパム対策として、需要に基づいて[トランザク
|
||||
|
||||
XRP Ledgerネットワークはオープンネットワークであり、すべての取引はオープンに公開されています。
|
||||
|
||||
Rippleは Ledgerネットワーク全体のAMLフラグを監視・報告し、該当する疑わしい活動をFinCENに報告することにコミットしています。
|
||||
Rippleは XRP Ledgerネットワーク全体のAMLフラグを監視・報告し、該当する疑わしい活動をFinCENに報告することにコミットしています。
|
||||
|
||||
[XRP Forensics / xrplorer](https://xrplorer.com/)は、XRP Ledgerのマネーロンダリング、詐欺、詐欺、不正使用を追跡し、最小限に抑えるための勧告リストを維持しています。取引所やその他のサービス・プロバイダは、金融犯罪を防止し対応するためにこのサービスを利用することができます。
|
||||
[XRP Forensics / xrplorer](https://xrplorer.com/)は、XRP Ledgerのマネーロンダリング、詐欺、不正使用を追跡し、最小限に抑えるための勧告リストを維持しています。取引所やその他のサービス・プロバイダは、金融犯罪を防止し対応するためにこのサービスを利用することができます。
|
||||
|
||||
|
||||
## セキュリティ上の懸念
|
||||
|
||||
@@ -26,14 +26,14 @@ labels:
|
||||
- `RippleState`
|
||||
- `Check`
|
||||
- アカウントがレジャー内に所有するオブジェクトが1000個未満であること。
|
||||
- トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.md)(現在2XRP)に相当する特別な[トランザクションコスト][]を支払う必要があります。
|
||||
- トランザクションの送信時、少なくとも1つ分の[所有者準備金](reserves.md)(現在{% $env.PUBLIC_OWNER_RESERVE %})に相当する特別な[トランザクションコスト][]を支払う必要があります。
|
||||
|
||||
|
||||
## 削除コスト
|
||||
|
||||
{% admonition type="warning" name="注意" %}アカウントの削除要件を満たしていないためにトランザクションが失敗した場合でも、[AccountDeleteトランザクション][]のトランザクションコストは、トランザクションが検証済みレジャーに含まれる場合常に発生します。アカウントを削除できなかった場合に高いトランザクションコストを支払う可能性を減らすには、AccountDeleteトランザクションを送信するときに`fail_hard`オプションを使用してください。{% /admonition %}
|
||||
|
||||
ビットコインや他の多くの暗号通貨とは異なり、XRP Ledgerの公開レジャーチェーンのそれぞれの新しいレジャーバージョンは、レジャーの完全な状態を含んでおり、新しいアカウントが増えるごとにサイズが増加します。そのため、必要な場合を除き、新しいXRP Ledgerアカウントを作成すべきではありません。アカウントを削除することで、アカウントの10XRPの[準備金](reserves.md)の一部を回復することができますが、そのためには少なくとも2XRPを破棄する必要があります。
|
||||
ビットコインや他の多くの暗号通貨とは異なり、XRP Ledgerの公開レジャーチェーンのそれぞれの新しいレジャーバージョンは、レジャーの完全な状態を含んでおり、新しいアカウントが増えるごとにサイズが増加します。そのため、必要な場合を除き、新しいXRP Ledgerアカウントを作成すべきではありません。アカウントを削除することで、アカウントの{% $env.PUBLIC_BASE_RESERVE %}の[準備金](reserves.md)の一部を回復することができますが、そのためには少なくとも{% $env.PUBLIC_OWNER_RESERVE %}を破棄する必要があります。
|
||||
|
||||
取引所など、多くのユーザのために価値の送受信を行う組織は、[**送信元タグ**と**宛先タグ**](../transactions/source-and-destination-tags.md)を使用することで、XRP Ledgerのアカウントを1つだけ(または少数)使用するだけで、ユーザの支払いを区別することができます。
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
|
||||
|
||||
- [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
|
||||
- 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。{% amendment-disclaimer name="DepositPreauth" /%}
|
||||
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金(現時点では10XRP)以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
|
||||
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金(現時点では{% $env.PUBLIC_BASE_RESERVE %})以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
|
||||
- **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
|
||||
- PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
|
||||
- PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
|
||||
|
||||
@@ -46,7 +46,7 @@ XRP Ledgerでアカウントを取得する一般的な方法は次のとおり
|
||||
|
||||
- 例えば、一般的な取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを出金することができます。
|
||||
|
||||
{% admonition type="warning" name="注意" %}自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.md)(現在は10XRP)を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。{% /admonition %}
|
||||
{% admonition type="warning" name="注意" %}自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.md)(現在は{% $env.PUBLIC_BASE_RESERVE %})を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般的な取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。{% /admonition %}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引
|
||||
|
||||
上記の例では、シーケンス番号105または作成した3つのチケットのいずれかを使用してトランザクションを送信できます。チケット103を使ってトランザクションを送信すると、それによってチケット103は元帳から削除されます。その後の次のトランザクションでは、シーケンス番号105、チケット102、またはチケット104を使用できます。
|
||||
|
||||
{% admonition type="warning" name="注意" %}チケットは1枚ごとに[所有者準備金](reserves.md#所有者準備金)としてカウントされますので、チケット1枚につき2XRPを確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります)一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。{% /admonition %}
|
||||
{% admonition type="warning" name="注意" %}チケットは1枚ごとに[所有者準備金](reserves.md#所有者準備金)としてカウントされますので、チケット1枚につき{% $env.PUBLIC_OWNER_RESERVE %}を確保する必要があります。 (このXRPは、チケットを使用した後に再び使用可能になります)一度に多くのチケットを作成すると、このコストはすぐに膨れ上がります。{% /admonition %}
|
||||
|
||||
シーケンス番号と同様に、トランザクションの送信は、そのトランザクションが[コンセンサス](../consensus-protocol/index.md)によって確認された場合にのみ、チケットを使用します。しかし、意図した通りにならなかった取引でも、[`tec`クラスの結果コード](../../references/protocol/transactions/transaction-results/tec-codes.md)を用いてコンセンサスで確認することができます。
|
||||
|
||||
@@ -51,7 +51,7 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引
|
||||
- 各チケットは一度しか使用できません。同じチケットシーケンスを使用する複数の異なるトランザクション候補があることは可能ですが、コンセンサスで検証できるのはそのうちの1つだけです。
|
||||
- 各アカウントでは、一度に250枚以上のチケットをレジャーに登録することはできません。また、一度に250枚以上のチケットを作成することもできません。
|
||||
- チケットを使って別のチケットを作ることは _できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
|
||||
- 各チケットは[所有者準備金](reserves.md#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
|
||||
- 各チケットは[所有者準備金](reserves.md#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき{% $env.PUBLIC_OWNER_RESERVE %}を確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントをご覧ください)。
|
||||
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントをご覧ください)。
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
html: consensus-protections.html
|
||||
parent: consensus.html
|
||||
seo:
|
||||
description: Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system. #TODO: translate
|
||||
description: 分散型金融システムで発生する可能性のあるさまざまな問題や攻撃から、XRP Ledgerコンセンサスプロトコルがどのように保護されているかを学びます。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
|
||||
@@ -12,11 +12,11 @@ NFTをミントし、保有し、販売するためには、XRPを準備金と
|
||||
|
||||
## 基本準備金
|
||||
|
||||
アカウントでは、基本準備金(現在10XRP)を用意する必要があります。基本準備金のXRPの金額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)をご覧ください。
|
||||
アカウントでは、基本準備金(現在{% $env.PUBLIC_BASE_RESERVE %})を用意する必要があります。基本準備金のXRPの金額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)をご覧ください。
|
||||
|
||||
## 所有者準備金
|
||||
|
||||
XRP Ledgerで所有する各オブジェクトには、現在2XRPの所有者準備金が必要とされています。これは、ユーザが不必要なデータで台帳にスパムをかけることを抑制し、不要になったデータを削除することを促すためのものです。所有者準備金の額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)をご覧ください。
|
||||
XRP Ledgerで所有する各オブジェクトには、現在{% $env.PUBLIC_OWNER_RESERVE %}の所有者準備金が必要とされています。これは、ユーザが不必要なデータで台帳にスパムをかけることを抑制し、不要になったデータを削除することを促すためのものです。所有者準備金の額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)をご覧ください。
|
||||
|
||||
NFTの場合、 _オブジェクト_ はそれぞれのNFTを指すのではなく、アカウントが所有する`NFTokenPage`オブジェクトを指します。`NFTokenPage`オブジェクトは最大32個のNFTを格納することができます。
|
||||
|
||||
@@ -38,7 +38,7 @@ NFTの保有枚数や保有ページ数によって、所有者準備金の総
|
||||
|
||||
## `NFTokenOffer`の準備金
|
||||
|
||||
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに対して準備金の1つの増加を必要とします。この記事の執筆時点では、準備金の増分は2XRPです。準備金は、オファーをキャンセルすることで取り戻すことができます。また、オファーが受け入れられると、XRP Ledgerからオファーが削除され、準備金は取り戻されます。
|
||||
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに対して準備金の1つの増加を必要とします。この記事の執筆時点では、準備金の増分は{% $env.PUBLIC_OWNER_RESERVE %}です。準備金は、オファーをキャンセルすることで取り戻すことができます。また、オファーが受け入れられると、XRP Ledgerからオファーが削除され、準備金は取り戻されます。
|
||||
|
||||
## Practical Considerations
|
||||
|
||||
@@ -55,7 +55,7 @@ NFTをミントし、保有し、売買のオファーをする場合、必要
|
||||
|
||||
{% admonition type="info" name="注記" %}準備金要件ではありませんが、ミントと売却のプロセスにおけるトランザクションの些細な手数料(通常12drops、または.000012XRP)を負担するために、少なくとも必要準備金より1XRPより多く用意しておきくべきです。{% /admonition %}
|
||||
|
||||
仮に200個のNFTをミントし、それぞれに「NFTokenSellOffer」を作成すると、436XRPもの準備金が必要になります。
|
||||
仮に200個のNFTをミントし、それぞれに「NFTokenSellOffer」を作成すると、43.6XRPもの準備金が必要になります。
|
||||
|
||||
| 準備金の種類 | 準備金の額 |
|
||||
|:--------------------|--------:|
|
||||
|
||||
@@ -72,7 +72,7 @@ labels:
|
||||
|
||||
### `NFTokenOffer`の準備金
|
||||
|
||||
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに1つ分の準備金の増額を要求します。執筆時点では、準備金の増分は2XRPです。この準備金は、オファーをキャンセルすることで取り戻すことができます。
|
||||
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに1つ分の準備金の増額を要求します。執筆時点では、準備金の増分は{% $env.PUBLIC_OWNER_RESERVE %}です。この準備金は、オファーをキャンセルすることで取り戻すことができます。
|
||||
|
||||
|
||||
### `NFTokenOfferID`のフォーマット
|
||||
|
||||
@@ -48,7 +48,7 @@ AMMを表す[AMMエントリ][]と[特殊なAccountRootエントリ](../../ledge
|
||||
|
||||
## 特殊なトランザクションコスト
|
||||
|
||||
各AMMインスタンスはAccountRootレジャーエントリ、AMMレジャーエントリ、プール内の各トークンのトラストラインを含むため、AMMCreateトランザクションは台帳スパムを抑止するために通常よりもはるかに高い[トランザクションコスト][]を必要とします。標準的な最低0.00001XRPの代わりに、AMMCreateは少なくとも所有者準備金の増分(現在は2XRP)を破棄しなければなりません。これは[AccountDeleteトランザクション][]と同じ特別なトランザクションコストです。
|
||||
各AMMインスタンスはAccountRootレジャーエントリ、AMMレジャーエントリ、プール内の各トークンのトラストラインを含むため、AMMCreateトランザクションは台帳スパムを抑止するために通常よりもはるかに高い[トランザクションコスト][]を必要とします。標準的な最低0.00001XRPの代わりに、AMMCreateは少なくとも所有者準備金の増分(現在は{% $env.PUBLIC_OWNER_RESERVE %})を破棄しなければなりません。これは[AccountDeleteトランザクション][]と同じ特別なトランザクションコストです。
|
||||
|
||||
## エラーケース
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ labels:
|
||||
|
||||
- トランザクションを送信するための十分なXRPが供給されていて、新しい署名者リストの[必要準備金](../../../concepts/accounts/reserves.md)を満たしている資金供給のあるXRP Ledger[アドレス](../../../concepts/accounts/index.md)が必要です。
|
||||
|
||||
- [MultiSignReserve Amendment][]が有効な場合、マルチシグを使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として2 XRPが必要です。(MultiSignReserve Amendmentは**2019年4月7日**以降、本番環境のXRP Ledgerで有効になっています。)
|
||||
- [MultiSignReserve Amendment][]が有効な場合、マルチシグを使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として{% $env.PUBLIC_OWNER_RESERVE %}が必要です。(MultiSignReserve Amendmentは**2019年4月7日**以降、本番環境のXRP Ledgerで有効になっています。)
|
||||
|
||||
- [MultiSignReserve Amendment][]が有効ではないテストネットワークでは、マルチシグを使用するには[アカウント準備金](../../../concepts/accounts/reserves.md)に通常よりも多くのXRPが必要となります。必要額は、リストの署名者の数に応じて増加します。
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ XRP Ledgerの分散型取引所(DEX)には、「アルゴリズムトレード
|
||||
|
||||
裁定取引を行うには、XRP Ledgerの内部と関連する部分の両方で、多くの方法があります。以下の例は潜在的な戦略を説明するためのものですが、他の方法も可能です。
|
||||
|
||||
**循環支払い**を利用して、マルチアセットトレードを完了し利益を得ることができます。XRP Ledgerは、XRPが真ん中のアセットである3つのアセットセットセットと同様に、アセットペア間の重複した取引を自動的に接続します。しかし、XRP Ledgerのプロトコルは、他のより長い、あるいはより複雑な経路のトレードを自動的に見つけて競うことはしません。(可能な限り最善の経路を見つけることは、計算集約型な問題のカテゴリとして知られています。)したがって、XRP Ledgerが独自の経路を見つける場合、XRP Ledgerのプロトコルは自動的に他の、より長い、あるいはより複雑な経路の取引を見つけ、競争させることはありません。したがって、自分で経路探索(PathFinding)を行えば、このような有益な裁定取引の機会を見つけることが可能です。その場合は、[Paymentトランザクション](../../references/protocol/transactions/types/payment.md)でそれらの[経路(Paths)](../../concepts/tokens/fungible-tokens/paths.md)を明示的に指定できます。1つのFOOを使って2つのBARを買い、その2つのBARを使って3つのTSTを買い、最後に3つのTSTを使って1.1 FOOを買えば、0.1 FOOから取引に関わるトークンの[送金手数料](../../concepts/tokens/fungible-tokens/transfer-fees.md)などのコストを差し引いた利益を得ることができます。
|
||||
**循環支払い**を利用して、マルチアセットトレードを完了し利益を得ることができます。XRP Ledgerは、XRPが真ん中のアセットである3つのアセットセットと同様に、アセットペア間の重複した取引を自動的に接続します。しかし、XRP Ledgerのプロトコルは、他のより長い、あるいはより複雑な経路のトレードを自動的に見つけて競うことはしません。(可能な限り最善の経路を見つけることは、計算集約型な問題のカテゴリとして知られています。)したがって、自分で経路探索(PathFinding)を行えば、このような有益な裁定取引の機会を見つけることが可能です。その場合は、[Paymentトランザクション](../../references/protocol/transactions/types/payment.md)でそれらの[経路(Paths)](../../concepts/tokens/fungible-tokens/paths.md)を明示的に指定できます。1つのFOOを使って2つのBARを買い、その2つのBARを使って3つのTSTを買い、最後に3つのTSTを使って1.1 FOOを買えば、0.1 FOOから取引に関わるトークンの[送金手数料](../../concepts/tokens/fungible-tokens/transfer-fees.md)などのコストを差し引いた利益を得ることができます。
|
||||
|
||||
資産の価格が異なる複数の取引所(CEX)に口座を持っている場合、**取引所間の裁定取引**を行うことができます。例えば、ACME取引所でXRPを1XRPあたり0.45ドルで購入し、そのXRPをWayGate取引所に移動して1XRPあたり0.50ドルで売却した場合、XRPあたり0.05ドルの利益を得ることができます。より複雑な例として、ACME取引所でBTC:ETHの価格が変動し、BTCに対してETHが安くなった場合、ある取引所でETH→XRPを売却し、そのXRPをACME取引所に移動し、XRP→BTC→ETHを取引して利益を得ることで、この価格変動を利用できる可能性があります。XRP Ledgerの取引は数秒で決済されますが、イーサリアムの取引は数分、ビットコインの取引は数時間かかることがあるため、XRPをブリッジ通貨として使用することで、ACME取引所でETH→BTC→BTC→ETHと取引するよりも早くこの機会を利用できる可能性があります。(これはもちろん、XRPへの交換が利益以上のコストにならないだけの十分な流動性と狭いスプレッドがある場合にのみ機能します)
|
||||
|
||||
@@ -48,7 +48,7 @@ XRP Ledgerの分散型取引所(DEX)には、「アルゴリズムトレード
|
||||
|
||||
## テストとよくある間違い
|
||||
|
||||
どのような取引でもそうですが、アルゴリズムトレー ドは確実に儲かる方法ではありません。手作業によるトレードと比べると、アルゴリズムトレードはエラーの余地が非常に少なくなります。小さなミスを犯しても、そのミスを大量のトレードで倍増させようとすれば、問題を修正する前に損失があっという間に膨らんでしまいます。したがって、自分のトレード戦略が実際に利益を上げるかどうかを確認するために、さまざまなテストを行うのが賢明です。戦略やその実際の実装(よく _ボット_ と呼ばれます)をテストするために、次のようなことを行うことができます。
|
||||
どのような取引でもそうですが、アルゴリズムトレードは確実に儲かる方法ではありません。手作業によるトレードと比べると、アルゴリズムトレードはエラーの余地が非常に少なくなります。小さなミスを犯しても、そのミスを大量のトレードで倍増させようとすれば、問題を修正する前に損失があっという間に膨らんでしまいます。したがって、自分のトレード戦略が実際に利益を上げるかどうかを確認するために、さまざまなテストを行うのが賢明です。戦略やその実際の実装(よく _ボット_ と呼ばれます)をテストするために、次のようなことを行うことができます。
|
||||
|
||||
- 現在のレジャーの状態または過去のトレードに基づいて、潜在的な利益を手動で計算します。
|
||||
- 過去のデータを記録してボットに送り、ボットがどのようなアクションを取ったかを記録し、実際の過去の値動きと結果を比較します。
|
||||
@@ -61,7 +61,7 @@ XRP Ledgerの分散型取引所(DEX)には、「アルゴリズムトレード
|
||||
- 通常、四捨五入の違いや、計算時と約定時の値動きの違いを考慮し、金額を調整する必要があります。この金額は「スリッページ」と呼ばれ、適切な金額を設定することが重要です。スリッページが低すぎると、トレードがまったく約定しない可能性があります。一方、スリッページが高すぎると、フロントランニングの影響を受けやすくなり、スリッページが高ければ高いほど、値動きによって利益が削られる可能性が高くなります。
|
||||
- **余分なコストと遅延を考慮しないこと**: 例えば、2つのステーブルコインの裏付けが米ドルであるにもかかわらず、ある発行者が0.5%の送金手数料を請求し、別の発行者が0.25%の[送金手数料](../../concepts/tokens/fungible-tokens/transfer-fees.md)を請求した場合、そのステーブルコインの取引価格には約0.25%の差が生じます。トランザクションを送信するためのコストは、通常は少額ですが、その他の潜在的な遅延の影響も忘れないでください。例えば、オフレジャーの取引所が現時点で有利な価格を示していたとしても、その取引所の入金処理に数時間から数日かかる場合、その取引所で事前に流動性を持っていない限り、その価格を利用することはできません。
|
||||
- **稀な事象を考慮していないこと**: 前例のない出来事(「ブラック・スワン」)はさておき、個々の異常値によって計算結果がゆがむことがあります。一例として(これは実話ですが)、あるトレーダーが、ある戦略の潜在的な利益を特定の時間帯で計算したところ、利益の80%以上が、他のユーザが誤って価格にゼロを追加してしまった1つの「入力ミス」の取引によるものであったと報じました。同じ戦略を、これらの異常値の取引を含まない時間範囲に対して計算すると、利益ははるかに少なくなりました。
|
||||
- **トランザクションのフラグを確認しないこ**と: XRP Ledgerのトランザクションのフラグは、そのトランザクションの処理方法や、プロトコルがそれを「成功」とマークするタイミングに大きな影響を与える可能性があります。例えば、"Offer"トランザクションのフラグは、全額がすぐに得られる場合にのみトレードされる"Fill or Kill"注文にすることができます。"Payment"トランザクションのフラグは、意図した宛先に全額を届けることができなくても成功する[partial payments](../../concepts/payment-types/partial-payments.md)にすることができます。トランザクションの`Flags`フィールドを解析するためにビット演算をする必要がありますが、それをスキップしてしまうと、予想と結果が全く異なったものとなってしまう可能性があります。
|
||||
- **トランザクションのフラグを確認しないこと**: XRP Ledgerのトランザクションのフラグは、そのトランザクションの処理方法や、プロトコルがそれを「成功」とマークするタイミングに大きな影響を与える可能性があります。例えば、"Offer"トランザクションのフラグは、全額がすぐに得られる場合にのみトレードされる"Fill or Kill"注文にすることができます。"Payment"トランザクションのフラグは、意図した宛先に全額を届けることができなくても成功する[partial payments](../../concepts/payment-types/partial-payments.md)にすることができます。トランザクションの`Flags`フィールドを解析するためにビット演算をする必要がありますが、それをスキップしてしまうと、予想と結果が全く異なったものとなってしまう可能性があります。
|
||||
|
||||
## 税金とライセンス
|
||||
|
||||
@@ -72,7 +72,7 @@ XRP Ledgerの分散型取引所(DEX)には、「アルゴリズムトレード
|
||||
|
||||
### トレードの発注
|
||||
|
||||
XRP Ledgerの分散型取引所で _代替可能_ トークンとXRPを売買するには、通常[OfferCreateトランザクション](../../references/protocol/transactions/types/offercreate.md)を送信します。この方法でトレードを行うためのコードと技術的ステップの詳細なウォークスルーについては、[分散型取引所でのトレード](../../tutorials/how-tos/use-tokens/trade-in-the-decentralized-exchange.md)をご覧ください。[Paymentトランザクション](../../references/protocol/transactions/types/payment.md)を使用して通貨を両替することも可能です。[クロスカレンしー支払い](../../concepts/payment-types/cross-currency-payments.md)を他のユーザに送ったり、長い[パス](../../concepts/tokens/fungible-tokens/paths.md)を使って裁定取引の機会を1つの操作にまとめることで、自分自身に送り返すこともできます。
|
||||
XRP Ledgerの分散型取引所で _代替可能_ トークンとXRPを売買するには、通常[OfferCreateトランザクション](../../references/protocol/transactions/types/offercreate.md)を送信します。この方法でトレードを行うためのコードと技術的ステップの詳細なウォークスルーについては、[分散型取引所でのトレード](../../tutorials/how-tos/use-tokens/trade-in-the-decentralized-exchange.md)をご覧ください。[Paymentトランザクション](../../references/protocol/transactions/types/payment.md)を使用して通貨を両替することも可能です。[クロスカレンシー支払い](../../concepts/payment-types/cross-currency-payments.md)を他のユーザに送ったり、長い[パス](../../concepts/tokens/fungible-tokens/paths.md)を使って裁定取引の機会を1つの操作にまとめることで、自分自身に送り返すこともできます。
|
||||
|
||||
NFTをトレードするためのコードと技術的な手順については、[JavaScriptを使用したNFTokenの送信](../../tutorials/javascript/nfts/transfer-nfts.md)をご覧ください。
|
||||
|
||||
|
||||
@@ -48,9 +48,9 @@ NFTをオークション形式で販売することができます。[NFTオー
|
||||
|
||||
### 準備金要件
|
||||
|
||||
販売用のNFTをミントする際には、XRPの準備金が必要となります。各NFTokenページには、2XRPの準備金が必要です。NFTokenページは16~32個のNFTを保管することができます。
|
||||
販売用のNFTをミントする際には、XRPの準備金が必要となります。各NFTokenページには、{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。NFTokenページは16~32個のNFTを保管することができます。
|
||||
|
||||
各`NFTokenOffer`オブジェクトは、2XRPの準備金が必要です。
|
||||
各`NFTokenOffer`オブジェクトは、{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。
|
||||
|
||||
`NFTokenOffer`を作成したり、NFTを売却したりする際には、些細な送金手数料(およそ6000ドロップ、または0.006 XRP)が発生します。大量に販売する場合、こうした少額の手数料はすぐにかさみますので、ビジネスのコストとして考慮する必要があります。
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ NFTokenのURLは、NFTのコンテンツが保存されている場所へのリ
|
||||
|
||||
[認可Minter](../../concepts/tokens/nfts/authorizing-another-minter.md)をご覧ください。
|
||||
|
||||
ミント済みのNFTは、`NFTokenPage`に記録されます。アカウント上の`NFTokenPage`1つにつき2XRPの準備金が必要です。[NFT準備金](../../concepts/tokens/nfts/reserve-requirements.md)をご覧ください。
|
||||
ミント済みのNFTは、`NFTokenPage`に記録されます。アカウント上の`NFTokenPage`1つにつき{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。[NFT準備金](../../concepts/tokens/nfts/reserve-requirements.md)をご覧ください。
|
||||
|
||||
各「NFTokenPage」は16~32個のNFTを保持します。大量のNFTをミントすると、あなたのXRPを大量に準備金としてロックすることになります。オンデマンドミント(または _遅延ミント_ )を行うことで、XRPを柔軟に維持することができます。[遅延ミント](../../concepts/tokens/nfts/batch-minting.md#mint-on-demand-lazy-minting)と[スクリプトミント](../../concepts/tokens/nfts/batch-minting.md#scripted-minting)をご覧下さい。
|
||||
|
||||
@@ -89,9 +89,9 @@ NFTをオークション形式で販売することができます。[NFTオー
|
||||
|
||||
#### 準備金要件
|
||||
|
||||
販売用のNFTをミントする際には、XRPの準備金が必要となります。各NFTokenページには、2XRPの準備金が必要です。NFTokenページは16~32個のNFTを保管することができます。
|
||||
販売用のNFTをミントする際には、XRPの準備金が必要となります。各NFTokenページには、{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。NFTokenページは16~32個のNFTを保管することができます。
|
||||
|
||||
各`NFTokenOffer`オブジェクトは、2XRPの準備金が必要です。
|
||||
各`NFTokenOffer`オブジェクトは、{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。
|
||||
|
||||
`NFTokenOffer`を作成したり、NFTを売却したりする際には、些細な送金手数料(およそ6000ドロップ、または0.006 XRP)が発生します。大量に販売する場合、こうした少額の手数料はすぐにかさみますので、ビジネスのコストとして考慮する必要があります。
|
||||
|
||||
|
||||
@@ -44,9 +44,9 @@ NFTをオークション形式で販売することができます。[NFTオー
|
||||
|
||||
### 準備金要件
|
||||
|
||||
販売用のNFTをミントする際には、XRPの準備金が必要となります。各NFTokenページには、2XRPの準備金が必要です。NFTokenページは16~32個のNFTを保管することができます。
|
||||
販売用のNFTをミントする際には、XRPの準備金が必要となります。各NFTokenページには、{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。NFTokenページは16~32個のNFTを保管することができます。
|
||||
|
||||
各`NFTokenOffer`オブジェクトは、2XRPの準備金が必要です。
|
||||
各`NFTokenOffer`オブジェクトは、{% $env.PUBLIC_OWNER_RESERVE %}の準備金が必要です。
|
||||
|
||||
`NFTokenOffer`を作成したり、NFTを売却したりする際には、些細な送金手数料(およそ6000ドロップ、または0.006 XRP)が発生します。大量に販売する場合、こうした少額の手数料はすぐにかさみますので、ビジネスのコストとして考慮する必要があります。
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ metadata:
|
||||
---
|
||||
# リソース
|
||||
|
||||
XRP Ledgerの理解や開発ためのリソース。Other resources to help understand the XRPL and develop on it.
|
||||
XRP Ledgerの理解や開発ためのリソース。
|
||||
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
@@ -248,6 +248,13 @@
|
||||
[UNLModify pseudo-transaction]: /docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
|
||||
[UNLModify pseudo-transactions]: /docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
|
||||
[UNLModify]: /docs/references/protocol/transactions/pseudo-transaction-types/unlmodify.md
|
||||
[Vault entry]: /docs/references/protocol/ledger-data/ledger-entry-types/vault.md
|
||||
[VaultCreate transaction]: /docs/references/protocol/transactions/types/vaultcreate.md
|
||||
[VaultDelete transaction]: /docs/references/protocol/transactions/types/vaultdelete.md
|
||||
[VaultDeposit transaction]: /docs/references/protocol/transactions/types/vaultdeposit.md
|
||||
[VaultSet transaction]: /docs/references/protocol/transactions/types/vaultset.md
|
||||
[VaultWithdraw transaction]: /docs/references/protocol/transactions/types/vaultwithdraw.md
|
||||
[VaultClawback transaction]: /docs/references/protocol/transactions/types/vaultclawback.md
|
||||
[XChainAddAccountCreateAttestation transaction]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
|
||||
[XChainAddAccountCreateAttestation transactions]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
|
||||
[XChainAddAccountCreateAttestation]: /docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
|
||||
@@ -447,5 +454,7 @@
|
||||
[validator_list_sites method]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validator_list_sites.md
|
||||
[validators command]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md
|
||||
[validators method]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md
|
||||
[vault_info command]: /docs/references/http-websocket-apis/public-api-methods/vault-methods/vault_info.md
|
||||
[vault_info method]: /docs/references/http-websocket-apis/public-api-methods/vault-methods/vault_info.md
|
||||
[wallet_propose command]: /docs/references/http-websocket-apis/admin-api-methods/key-generation-methods/wallet_propose.md
|
||||
[wallet_propose method]: /docs/references/http-websocket-apis/admin-api-methods/key-generation-methods/wallet_propose.md
|
||||
|
||||
33
docs/concepts/accounts/pseudo-accounts.md
Normal file
33
docs/concepts/accounts/pseudo-accounts.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
seo:
|
||||
description: A pseudo-account is a special type of XRPL account that holds assets on behalf of an on-chain protocol.
|
||||
labels:
|
||||
- Single Asset Vault
|
||||
- AMM
|
||||
- Lending Protocol
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# Pseudo-Accounts
|
||||
|
||||
The XRP Ledger is an account-based blockchain where assets like XRP, trust line tokens, and Multi-Purpose Tokens (MPTs) are held by accounts, and are represented on-chain by an [AccountRoot](../../references/protocol/ledger-data/ledger-entry-types/accountroot) ledger entry. However, certain use cases require assets to be transferable to and from an object, which is why a pseudo-account is needed.
|
||||
|
||||
A pseudo-account is a special type of account that holds assets on behalf of an on-chain protocol. Use cases for pseudo-accounts include:
|
||||
|
||||
- **Automated Market Makers (AMM)**: The [XLS-30 amendment](../../../resources/known-amendments#amm) introduced pseudo-accounts for AMMs by adding the `AMMID` field to the `AccountRoot` ledger entry. This field links a pseudo-account to an AMM instance, allowing it to track XRP and token balances in the pool and issue `LPTokens` on behalf of the AMM instance.
|
||||
|
||||
- **Single Asset Vaults**: A single asset vault pseudo-account is used to store deposited funds and issue MPT shares. A new `VaultID` field is introduced in the `AccountRoot` ledger entry, which links the pseudo-account with the vault.
|
||||
|
||||
- **Lending Protocol**: The Lending Protocol also uses the single asset vault's pseudo-account, with each `LoanBroker` tracked in the pseudo-account's owner directory. The pseudo-account holds first-loss capital that protects vault depositors from loan defaults, as well as the loan funds themselves.
|
||||
|
||||
A pseudo-account has strict limitations. It cannot receive payments from other accounts, cannot send transactions since it has no signing authority, and exists solely to store or issue assets.
|
||||
|
||||
## Reserve Requirements
|
||||
|
||||
The cost of creating a pseudo-account depends on whether it is owned and controlled by another account:
|
||||
|
||||
- **Owned pseudo-accounts**: For objects like a `Vault` where a single account owns and controls the associated pseudo-account, the creation transaction increases the owner's XRP reserve by one [incremental owner reserve](../accounts/reserves#base-reserve-and-owner-reserve) (currently {% $env.PUBLIC_OWNER_RESERVE %}). This is in addition to any other reserve requirements of the transaction (for example, the Vault object itself).
|
||||
|
||||
- **Unowned pseudo-accounts**: For objects like an `AMM` that are not owned by any account, the creation transaction must charge a special, higher-than-normal transaction fee. This fee must be at least the value of one incremental owner reserve. This amount is burned, compensating for the permanent ledger space without tying the reserve to a specific owner.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
251
docs/concepts/tokens/single-asset-vault.md
Normal file
251
docs/concepts/tokens/single-asset-vault.md
Normal file
@@ -0,0 +1,251 @@
|
||||
---
|
||||
seo:
|
||||
description: A single asset vault aggregates assets from multiple depositors and makes them available to other on-chain protocols.
|
||||
labels:
|
||||
- Single Asset Vault
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# Single Asset Vault
|
||||
|
||||
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. 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).
|
||||
|
||||
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.
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%}.)_
|
||||
|
||||
## Public vs. Private Vaults
|
||||
|
||||
A vault can be **public** or **private**, depending on the required level of access control.
|
||||
|
||||
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.
|
||||
|
||||
{% admonition type="warning" name="Warning" %}
|
||||
If a depositor's credentials expire, they can no longer deposit assets in a private vault, but can always redeem their existing shares.
|
||||
{% /admonition %}
|
||||
|
||||
To prevent the Vault Owner from locking funds away, any shareholder in a private vault can redeem their shares for assets.
|
||||
|
||||
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.
|
||||
|
||||
## Vault Share Distribution and Redemption
|
||||
|
||||
Depositors can deposit assets to receive shares, which represent their proportional ownership of the vault, or redeem shares for assets.
|
||||
|
||||
[{% 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.")
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
The scale behavior varies based on the type of asset held by the vault:
|
||||
|
||||
- **XRP**: Uses a fixed scale that aligns with XRP's native structure, where one share represents one drop.
|
||||
- **Trust Line Token**: Allows configurable precision (default preserves 6 decimal places).
|
||||
- **MPT**: Uses a 1-to-1 relationship between MPT units and shares.
|
||||
|
||||
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.
|
||||
|
||||
The value of each share depends on the total assets in the vault:
|
||||
|
||||
- If the vault earns yield over time, shares represent a larger claim, allowing depositors to redeem them for more assets.
|
||||
- If the vault incurs losses, shares hold less value, resulting in lower redemptions.
|
||||
|
||||
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.
|
||||
|
||||
### Exchange Algorithm
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
#### Unrealized Loss
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
1. The new exchange rate is calculated as:
|
||||
|
||||
```js
|
||||
// ExchangeRate = (AssetsTotal - LossUnrealized) / SharesTotal
|
||||
exchangeRate = (1,000,000 - 900,000) / 1,000,000
|
||||
```
|
||||
|
||||
The exchange rate value is now **0.1**.
|
||||
|
||||
2. After the unrealized loss is cleared, the new effective exchange rate would be:
|
||||
|
||||
```js
|
||||
// ExchangeRate = AssetsTotal / SharesTotal
|
||||
exchangeRate = 1,000,000 / 1,000,000
|
||||
```
|
||||
|
||||
The exchange rate is now **1.0**.
|
||||
|
||||
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.
|
||||
|
||||
To mitigate this, the vault uses separate exchange rates for deposits and redemptions.
|
||||
|
||||
#### Exchange Rates
|
||||
|
||||
A single asset vault uses **two distinct exchange rates**:
|
||||
|
||||
- **Deposit Exchange Rate**: Protects new depositors from prior losses and ensures fair share allocation.
|
||||
- **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.
|
||||
- **Redemptions**: The vault burns shares so the depositor can receive proportional assets.
|
||||
- **Withdrawals**: The vault determines the shares to burn based on the requested asset amount.
|
||||
|
||||
These exchange rates ensure fairness and prevent manipulation, maintaining the integrity of deposits and redemptions.
|
||||
|
||||
To understand how the exchange rates are applied, here are the key variables used in the calculations:
|
||||
|
||||
- `Γ_assets`: The total balance of assets held within the vault.
|
||||
- `Γ_shares`: The total number of shares currently issued by the vault.
|
||||
- `Δ_assets`: The amount of assets being deposited, withdrawn, or redeemed.
|
||||
- `Δ_shares`: The number of shares being issued or burned.
|
||||
- `l`: The vault's total unrealized loss.
|
||||
- `σ`: The scaling factor (σ = 10<sup>Scale</sup>) used to convert fractional assets into whole number shares.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Deposit" %}
|
||||
The vault computes the number of shares a depositor will receive as follows:
|
||||
|
||||
- **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.
|
||||
|
||||
```js
|
||||
Δ_shares = Δ_assets * σ // σ = 10^Scale
|
||||
```
|
||||
|
||||
- **Subsequent Deposits**: For all other deposits, shares are calculated proportionally. The resulting share value is rounded **down** to the nearest whole number.
|
||||
|
||||
```js
|
||||
Δ_shares = (Δ_assets * Γ_shares) / Γ_assets
|
||||
```
|
||||
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:
|
||||
|
||||
```js
|
||||
Δ_assets = (Δ_shares * (Γ_assets - l)) / Γ_shares
|
||||
```
|
||||
|
||||
After a successful deposit, the _total assets_ and _total shares_ values are updated like so:
|
||||
|
||||
```js
|
||||
Γ_assets = Γ_assets + Δ_assets // New balance of assets in the vault.
|
||||
Γ_shares = Γ_shares + Δ_shares // New share balance in the vault.
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Redeem" %}
|
||||
The vault computes the number of assets returned by burning shares as follows:
|
||||
|
||||
```js
|
||||
Δ_assets = (Δ_shares * (Γ_assets - l)) / Γ_shares
|
||||
```
|
||||
|
||||
After a successful redemption, the _total assets_ and _total shares_ values are updated like so:
|
||||
|
||||
```js
|
||||
Γ_assets = Γ_assets - Δ_assets // New balance of assets in the vault.
|
||||
Γ_shares = Γ_shares - Δ_shares // New share balance in the vault.
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Withdraw" %}
|
||||
When a depositor requests a specific asset amount, the vault uses a two-step process to determine the final payout:
|
||||
|
||||
1. The requested asset amount (`Δ_assets_requested`) is converted into shares.
|
||||
|
||||
```js
|
||||
Δ_shares = (Δ_assets_requested * Γ_shares) / (Γ_assets - l)
|
||||
```
|
||||
|
||||
The calculated share amount is rounded to the **nearest** whole number.
|
||||
|
||||
2. The rounded number of shares is used to calculate the final asset payout (`Δ_assets_out`), using the same logic as a redemption.
|
||||
|
||||
```js
|
||||
Δ_assets_out = (Δ_shares * (Γ_assets - l)) / Γ_shares
|
||||
```
|
||||
|
||||
Due to rounding in step 1, the final payout may differ slightly from the requested amount.
|
||||
|
||||
After a successful withdrawal, the _total asset_ and _total share_ values are updated like so:
|
||||
|
||||
```js
|
||||
Γ_assets = Γ_assets - Δ_assets_out // New balance of assets in the vault.
|
||||
Γ_shares = Γ_shares - Δ_shares // New share balance in the vault.
|
||||
```
|
||||
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### Can a Depositor Transfer Shares to Another Account?
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
{% admonition type="info" name="Note" %}
|
||||
It is important to remember that a vault must be **configured** to allow share transfers, or this will not be possible.
|
||||
{% /admonition %}
|
||||
|
||||
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:
|
||||
|
||||
- The vault is private and the payee lacks credentials in the vault's permissioned domain.
|
||||
- The vault shares are configured as non-transferable.
|
||||
- There is a global freeze (trust line tokens) or lock (MPTs) on the underlying asset.
|
||||
- The underlying asset is an MPT and is locked for the payer, payee, or vault pseudo-account.
|
||||
- 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.
|
||||
|
||||
If the transfer succeeds and the payee already holds vault shares, their balance increases. Otherwise, a new MPT entry is created for their account.
|
||||
|
||||
## Compliance
|
||||
|
||||
### Frozen Assets
|
||||
|
||||
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:
|
||||
|
||||
1. Withdrawals can only be made to the asset’s issuer.
|
||||
2. The asset cannot be deposited into the vault.
|
||||
3. Its corresponding shares also cannot be transferred.
|
||||
|
||||
### Clawback
|
||||
|
||||
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.
|
||||
|
||||
## Why Use a Single Asset Vault?
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Depending on the connected on-chain protocol, vaults can be applied to various use cases, such as:
|
||||
|
||||
- Lending markets
|
||||
- Aggregators
|
||||
- Yield-bearing tokens
|
||||
- Asset management
|
||||
|
||||
The only supported use cases right now are _asset management_ and [_lending markets_](https://github.com/XRPLF/XRPL-Standards/discussions/190).
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Credentials](../../concepts/decentralized-storage/credentials.md) - Define access requirements for private vaults.
|
||||
- [Permissioned Domains](../tokens/decentralized-exchange/permissioned-domains.md) - Control access to private vaults.
|
||||
- [Pseudo-Accounts](../accounts/pseudo-accounts.md) - Special accounts that hold assets on behalf of on-chain protocols.
|
||||
- **References:**
|
||||
- [Vault entry][] - Data structure on the ledger that records vault information.
|
||||
- [VaultClawback transaction][] - Allow asset issuers to recover assets from the vault.
|
||||
- [VaultCreate transaction][] - Create a new vault for aggregating assets.
|
||||
- [VaultDelete transaction][] - Delete an existing vault entry.
|
||||
- [VaultDeposit transaction][] - Add assets to a vault in exchange for shares.
|
||||
- [VaultSet transaction][] - Update the configuration of an existing vault.
|
||||
- [VaultWithdraw transaction][] - Redeem liquidity from a vault.
|
||||
- [vault_info method][] - Retrieve information about a vault and its shares.
|
||||
1
docs/img/single-asset-vault-img.svg
Normal file
1
docs/img/single-asset-vault-img.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 39 KiB |
@@ -1,9 +1,7 @@
|
||||
---
|
||||
html: private-network-with-docker.html
|
||||
name: Run a Private Network with Docker
|
||||
parent: use-stand-alone-mode.html
|
||||
seo:
|
||||
description: Learn how to set up your own XRP private ledger network with Docker and Docker Compose.
|
||||
description: Learn how to set up your own XRP private ledger network with Docker and Docker Compose.
|
||||
labels:
|
||||
- Core Server
|
||||
---
|
||||
@@ -261,17 +259,25 @@ For each validator node, follow these steps:
|
||||
|
||||
Now that you have created the configuration files for your validators, you need to add a `validator.txt` file. This file defines which validators are trusted by your network.
|
||||
|
||||
For each node, follow these steps:
|
||||
Follow these steps to add validator configuration files to each validator:
|
||||
|
||||
1. Create a `validators.txt` file in the configuration directory.
|
||||
1. Create a `validators.txt` file.
|
||||
2. Copy the public keys from the `validator-keys.json` files that you generated at the [beginning](#generate-the-validator-keys) of the tutorial.
|
||||
3. Add the public keys of _all_ the validators. For example:
|
||||
|
||||
```
|
||||
[validators]
|
||||
nHBgaEDL8buUECuk4Rck4QBYtmUgbAoeYJLpWLzG9iXsznTRYrQu
|
||||
nHBCHX7iLDTyap3LumqBNuKgG7JLA5tc6MSJxpLs3gjkwpu836mY
|
||||
nHU5STUKTgWdreVqJDx6TopLUymzRUZshTSGcWNtjfByJkYdiiRc
|
||||
nHBgaEDL8buUECuk4Rck4QBYtmUgbAoeYJLpWLzG9iXsznTRYrQu
|
||||
nHBCHX7iLDTyap3LumqBNuKgG7JLA5tc6MSJxpLs3gjkwpu836mY
|
||||
nHU5STUKTgWdreVqJDx6TopLUymzRUZshTSGcWNtjfByJkYdiiRc
|
||||
```
|
||||
|
||||
4. Copy the same `validators.txt` file into the `config` directory for _each_ validator.
|
||||
|
||||
```sh
|
||||
cp validators.txt validator_1/config/
|
||||
cp validators.txt validator_2/config/
|
||||
cp validators.txt validator_3/config/
|
||||
```
|
||||
|
||||
## Start the Network
|
||||
@@ -285,7 +291,6 @@ To start running your private network, follow these steps:
|
||||
1. Create a `docker-compose.yml` file in the root of the private network directory, `xrpl-private-network`, and add the following content:
|
||||
|
||||
```
|
||||
version: "3.9"
|
||||
services:
|
||||
validator_1:
|
||||
platform: linux/amd64
|
||||
@@ -338,9 +343,15 @@ To start running your private network, follow these steps:
|
||||
|
||||
Now that the private ledger network is up, you need to verify that **each** validator node is running as expected:
|
||||
|
||||
1. In your terminal, run `docker exec -it <validator_name> bin/bash` to execute commands in the validator Docker container. Replace `<validator_name>` with the name of the container (e.g., `validator_1`).
|
||||
1. Open a terminal in the validator_1 container:
|
||||
|
||||
2. Run the `rippled server_info` command to check the state of the validator:
|
||||
```
|
||||
docker exec -it validator_1 bin/bash
|
||||
```
|
||||
|
||||
{% admonition type="success" name="Tip" %}You can use the same syntax to execute commands in the other Docker containers. Replace `bin/bash` with the command to run and `validator_1` with the name of the container.{% /admonition %}
|
||||
|
||||
3. Run the `rippled server_info` command to check the state of the validator:
|
||||
|
||||
```
|
||||
rippled server_info | grep server_state
|
||||
@@ -354,7 +365,7 @@ Now that the private ledger network is up, you need to verify that **each** vali
|
||||
|
||||
{% admonition type="info" name="Note" %}If the state is not updated to **proposing**, repeat step **2** after a few minutes as the ledger can take some time to update.{% /admonition %}
|
||||
|
||||
3. Verify the number of peers connected to the validator.
|
||||
4. Verify the number of peers connected to the validator.
|
||||
|
||||
```
|
||||
rippled server_info | grep peers
|
||||
@@ -366,10 +377,10 @@ Now that the private ledger network is up, you need to verify that **each** vali
|
||||
"peers" : 2
|
||||
```
|
||||
|
||||
4. Run the following command to check the genesis account information:
|
||||
5. Run the following command to check the genesis account information:
|
||||
|
||||
```
|
||||
rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated strict
|
||||
rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated
|
||||
```
|
||||
|
||||
Sample Output:
|
||||
@@ -396,7 +407,9 @@ Now that the private ledger network is up, you need to verify that **each** vali
|
||||
}
|
||||
```
|
||||
|
||||
5. To leave the Docker container shell, enter `exit` in the terminal.
|
||||
If the ledger does not have `"validated": true`, double check that you put matching `validators.txt` files with all three public keys in each container's config directory, and restart the container if you need to make changes.
|
||||
|
||||
6. To leave the Docker container shell, enter `exit` in the terminal.
|
||||
|
||||
### Perform a test transaction
|
||||
|
||||
@@ -439,7 +452,7 @@ Perform a **test** transaction to ensure you can send money to an account.
|
||||
|
||||
```
|
||||
docker exec -it validator_1 \
|
||||
rippled account_info r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs validated strict
|
||||
rippled account_info r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs validated
|
||||
```
|
||||
|
||||
Sample Output:
|
||||
|
||||
@@ -115,6 +115,11 @@ Use these methods to perform convenient tasks, such as ping and random number ge
|
||||
* **[`ping`](utility-methods/ping.md)** - Confirm connectivity with the server.
|
||||
* **[`random`](utility-methods/random.md)** - Generate a random number.
|
||||
|
||||
## [Vault Methods](vault-methods/index.md)
|
||||
|
||||
Use these methods to retrieve vault information.
|
||||
|
||||
* **[`vault_info`](vault-methods/vault_info.md)** - Get information about a specific vault.
|
||||
|
||||
## Deprecated Methods
|
||||
|
||||
|
||||
@@ -977,6 +977,54 @@ rippled json ledger_entry '{ "mptoken": {"mpt_issuance_id": "05EECEBE97A7D635DE2
|
||||
|
||||
{% try-it method="ledger_entry-mptoken" /%}
|
||||
|
||||
### Get Vault Entry
|
||||
|
||||
Retrieve a `Vault` object from the ledger. This is similar to the [vault_info method][], but the `ledger_entry` version returns only the ledger entry as stored.
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%}.)_
|
||||
|
||||
| Field | Type | Description |
|
||||
|:-------------|:-----------------|:----------------------|
|
||||
| `vault` | String | The [ledger entry ID](../../../protocol/ledger-data/common-fields.md#ledger-entry-id) of a [Vault](../../../protocol/ledger-data/ledger-entry-types/vault.md) object to retrieve. |
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": "example_get_vault_entry",
|
||||
"command": "ledger_entry",
|
||||
"vault": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166",
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "ledger_entry",
|
||||
"params": [
|
||||
{
|
||||
"vault": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166",
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```sh
|
||||
rippled json ledger_entry '{ "vault": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166", "ledger_index": "validated" }'
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
<!-- TODO: Add when deployed to Devnet/Testnet -->
|
||||
<!-- {% try-it method="ledger_entry-single-asset-vault" server="testnet" /%} -->
|
||||
|
||||
## Response Format
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
# Vault Methods
|
||||
|
||||
A `Vault` object in the XRP Ledger represents the state of a tokenized vault. Use these methods to interact with vaults.
|
||||
|
||||
{% child-pages /%}
|
||||
@@ -0,0 +1,294 @@
|
||||
---
|
||||
seo:
|
||||
description: Retrieve information about a vault, its owner, available assets, and details on issued shares.
|
||||
labels:
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# vault_info
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/rpc/handlers/VaultInfo.cpp "Source")
|
||||
|
||||
The `vault_info` command retrieves information about a vault, its owner, available assets, and details on issued shares. All information retrieved is relative to a particular version of the ledger. {% badge href="https://github.com/XRPLF/rippled/releases/tag/3.3.0" %}New in: rippled 3.3.0{% /badge %}
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"command": "vault_info",
|
||||
"vault_id": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
{
|
||||
"method": "vault_info",
|
||||
"params": [
|
||||
{
|
||||
"vault_id": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```sh
|
||||
#Syntax: vault_info [<vault_id>]
|
||||
rippled vault_info 45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
<!-- TODO: Add this when available on Devnet -->
|
||||
<!-- {% try-it method="vault_info" /%} -->
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
| :--------- | :----- | :----------------------------------------- |
|
||||
| `vault_id` | String | The object ID of the Vault to be returned. |
|
||||
| `owner` | String | The account address of the Vault Owner. |
|
||||
| `seq` | Number | The transaction sequence number that created the vault. |
|
||||
|
||||
You can provide either the `vault_id`, or both `owner` and `seq` values in the request.
|
||||
|
||||
## Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"ledger_current_index": 222403,
|
||||
"validated": false,
|
||||
"vault": {
|
||||
"Account": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"Asset": {
|
||||
"currency": "USD",
|
||||
"issuer": "rXJSJiZMxaLuH3kQBUV5DLipnYtrE6iVb"
|
||||
},
|
||||
"AssetsAvailable": "0",
|
||||
"AssetsMaximum": "1000000",
|
||||
"AssetsTotal": "0",
|
||||
"Data": "5661756C74206D65746164617461",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "Vault",
|
||||
"LossUnrealized": "0",
|
||||
"Owner": "rNGHoQwNG753zyfDrib4qDvvswbrtmV8Es",
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "39CBBE3629AD9ADF9BA5CBAC5BF18665E785D0B199D2B2773A8A1EAA6CBC622B",
|
||||
"PreviousTxnLgrSeq": 219033,
|
||||
"Scale": 6,
|
||||
"Sequence": 200370,
|
||||
"ShareMPTID": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175",
|
||||
"WithdrawalPolicy": 1,
|
||||
"index": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166",
|
||||
"shares": {
|
||||
"AssetScale": 6,
|
||||
"Flags": 56,
|
||||
"Issuer": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"LedgerEntryType": "MPTokenIssuance",
|
||||
"MPTokenMetadata": "7B2274223A225473745368617265222C226E223A2254657374205661756C74205368617265222C2264223A22412074657374207661756C742073686172652E222C2269223A226578616D706C652E6F72672F73686172652D69636F6E2E706E67222C226163223A22727761222C226173223A22657175697479222C22696E223A224D53205465737420497373756572222C227573223A5B7B2275223A226578616D706C657969656C642E636F2F7473747368617265222C2263223A2277656273697465222C2274223A2250726F647563742050616765227D2C7B2275223A226578616D706C657969656C642E636F2F646F6373222C2263223A22646F6373222C2274223A225969656C6420546F6B656E20446F6373227D5D2C226169223A7B22766F6C6174696C697479223A226C6F77227D7D",
|
||||
"OutstandingAmount": "0",
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "39CBBE3629AD9ADF9BA5CBAC5BF18665E785D0B199D2B2773A8A1EAA6CBC622B",
|
||||
"PreviousTxnLgrSeq": 219033,
|
||||
"Sequence": 1,
|
||||
"index": "10D193CFF4619D2C7D552746A8C9F76AD6335E6D4452712CB39F8C7F096AE474",
|
||||
"mpt_issuance_id": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175"
|
||||
}
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"ledger_current_index": 222403,
|
||||
"status": "success",
|
||||
"validated": false,
|
||||
"vault": {
|
||||
"Account": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"Asset": {
|
||||
"currency": "USD",
|
||||
"issuer": "rXJSJiZMxaLuH3kQBUV5DLipnYtrE6iVb"
|
||||
},
|
||||
"AssetsAvailable": "0",
|
||||
"AssetsMaximum": "1000000",
|
||||
"AssetsTotal": "0",
|
||||
"Data": "5661756C74206D65746164617461",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "Vault",
|
||||
"LossUnrealized": "0",
|
||||
"Owner": "rNGHoQwNG753zyfDrib4qDvvswbrtmV8Es",
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "39CBBE3629AD9ADF9BA5CBAC5BF18665E785D0B199D2B2773A8A1EAA6CBC622B",
|
||||
"PreviousTxnLgrSeq": 219033,
|
||||
"Scale": 6,
|
||||
"Sequence": 200370,
|
||||
"ShareMPTID": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175",
|
||||
"WithdrawalPolicy": 1,
|
||||
"index": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166",
|
||||
"shares": {
|
||||
"AssetScale": 6,
|
||||
"Flags": 56,
|
||||
"Issuer": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"LedgerEntryType": "MPTokenIssuance",
|
||||
"MPTokenMetadata": "7B2274223A225473745368617265222C226E223A2254657374205661756C74205368617265222C2264223A22412074657374207661756C742073686172652E222C2269223A226578616D706C652E6F72672F73686172652D69636F6E2E706E67222C226163223A22727761222C226173223A22657175697479222C22696E223A224D53205465737420497373756572222C227573223A5B7B2275223A226578616D706C657969656C642E636F2F7473747368617265222C2263223A2277656273697465222C2274223A2250726F647563742050616765227D2C7B2275223A226578616D706C657969656C642E636F2F646F6373222C2263223A22646F6373222C2274223A225969656C6420546F6B656E20446F6373227D5D2C226169223A7B22766F6C6174696C697479223A226C6F77227D7D",
|
||||
"OutstandingAmount": "0",
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "39CBBE3629AD9ADF9BA5CBAC5BF18665E785D0B199D2B2773A8A1EAA6CBC622B",
|
||||
"PreviousTxnLgrSeq": 219033,
|
||||
"Sequence": 1,
|
||||
"index": "10D193CFF4619D2C7D552746A8C9F76AD6335E6D4452712CB39F8C7F096AE474",
|
||||
"mpt_issuance_id": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result": {
|
||||
"ledger_current_index": 222403,
|
||||
"validated": false,
|
||||
"vault": {
|
||||
"Account": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"Asset": {
|
||||
"currency": "USD",
|
||||
"issuer": "rXJSJiZMxaLuH3kQBUV5DLipnYtrE6iVb"
|
||||
},
|
||||
"AssetsAvailable": "0",
|
||||
"AssetsMaximum": "1000000",
|
||||
"AssetsTotal": "0",
|
||||
"Data": "5661756C74206D65746164617461",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "Vault",
|
||||
"LossUnrealized": "0",
|
||||
"Owner": "rNGHoQwNG753zyfDrib4qDvvswbrtmV8Es",
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "39CBBE3629AD9ADF9BA5CBAC5BF18665E785D0B199D2B2773A8A1EAA6CBC622B",
|
||||
"PreviousTxnLgrSeq": 219033,
|
||||
"Scale": 6,
|
||||
"Sequence": 200370,
|
||||
"ShareMPTID": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175",
|
||||
"WithdrawalPolicy": 1,
|
||||
"index": "45E6742527EDE6A2B537AE8A77B8D8CCFEFE115A22B3BF664A39407631F9A166",
|
||||
"shares": {
|
||||
"AssetScale": 6,
|
||||
"Flags": 56,
|
||||
"Issuer": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"LedgerEntryType": "MPTokenIssuance",
|
||||
"MPTokenMetadata": "7B2274223A225473745368617265222C226E223A2254657374205661756C74205368617265222C2264223A22412074657374207661756C742073686172652E222C2269223A226578616D706C652E6F72672F73686172652D69636F6E2E706E67222C226163223A22727761222C226173223A22657175697479222C22696E223A224D53205465737420497373756572222C227573223A5B7B2275223A226578616D706C657969656C642E636F2F7473747368617265222C2263223A2277656273697465222C2274223A2250726F647563742050616765227D2C7B2275223A226578616D706C657969656C642E636F2F646F6373222C2263223A22646F6373222C2274223A225969656C6420546F6B656E20446F6373227D5D2C226169223A7B22766F6C6174696C697479223A226C6F77227D7D",
|
||||
"OutstandingAmount": "0",
|
||||
"OwnerNode": "0",
|
||||
"PreviousTxnID": "39CBBE3629AD9ADF9BA5CBAC5BF18665E785D0B199D2B2773A8A1EAA6CBC622B",
|
||||
"PreviousTxnLgrSeq": 219033,
|
||||
"Sequence": 1,
|
||||
"index": "10D193CFF4619D2C7D552746A8C9F76AD6335E6D4452712CB39F8C7F096AE474",
|
||||
"mpt_issuance_id": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175"
|
||||
}
|
||||
}
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
The response follows the [standard format][], with a successful result containing following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
| :--------------------- | :--------------- | :---------- |
|
||||
| `ledger_hash` | [Hash][] | _(Omitted if `ledger_current_index` is provided instead)_ The identifying hash of the ledger version that was used when retrieving this data. |
|
||||
| `ledger_current_index` | [Ledger Index][] | _(Omitted if `ledger_index` is provided instead)_ The [ledger index][] of the current in-progress ledger, which was used when retrieving this information. |
|
||||
| `ledger_index` | [Ledger Index][] | _(Omitted if `ledger_current_index` is provided instead)_ The [ledger index][] of the ledger version used when retrieving this information. |
|
||||
| `validated` | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. |
|
||||
| `vault` | Object | The [**Vault Description Object**](#vault-description-object) that represents the current status of the vault. |
|
||||
|
||||
### Vault Description Object
|
||||
|
||||
The `vault` field is an object describing the current status of a Vault entry in the ledger, and contains the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
| :--------------------- | :------------------- | :---------- |
|
||||
| `Account` | String - [Address][] | The address of the vault's pseudo-account. |
|
||||
| `Asset` | Object | The [**Asset**](#asset-object) of the vault. An asset can be XRP, a trust line token, or an MPT. |
|
||||
| `AssetsAvailable` | Number | The asset amount that is available in the vault. |
|
||||
| `AssetsMaximum` | Number | The maximum asset amount that can be held in the vault. If set to 0, this indicates there is no cap. |
|
||||
| `AssetsTotal` | Number | The total value of the vault. |
|
||||
| `Flags` | String | Set of bit-flags for this ledger object. |
|
||||
| `LossUnrealized` | Number | The potential loss amount that is not yet realized, expressed as the vault's asset. |
|
||||
| `ShareMPTID` | String | The identifier of the share `MPTokenIssuance` object. |
|
||||
| `WithdrawalPolicy` | String | Indicates the withdrawal strategy used by the vault. |
|
||||
| `index` | String | The unique index of the vault ledger entry. |
|
||||
| `shares` | Object | A [**Shares Object**](#shares-object) containing details about the vault's issued shares. |
|
||||
| `Scale` | Number | Specifies decimal precision for share calculations. Assets are multiplied by 10<sup>Scale</sup > to convert fractional amounts into whole number shares. For example, with a `Scale` of `6`, depositing 20.3 units creates 20,300,000 shares (20.3 × 10<sup>Scale</sup >). For **trust line tokens** this can be configured at vault creation, and valid values are between 0-18, with the default being `6`. For **XRP** and **MPTs**, this is fixed at `0`. |
|
||||
|
||||
### Asset Object
|
||||
|
||||
The `asset` object contains the following nested fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
| :--------------------- | :------------------- | :---------- |
|
||||
| `currency` | String | _(Omitted if the asset is an MPT)_ The currency code of the asset stored in the vault. |
|
||||
| `issuer` | String - [Address][] | _(Omitted if the asset is XRP or an MPT)_ The address of the asset issuer. |
|
||||
| `mpt_issuance_id` | String | _(Omitted if the asset is XRP or a trust line token)_ The identifier of the asset's `MPTokenIssuance` object. |
|
||||
|
||||
### Shares Object
|
||||
|
||||
The `shares` object contains the following nested fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
| :--------------------- | :--------------- | :---------- |
|
||||
| `DomainID` | String | _(Omitted if the vault is public)_ The permissioned domain associated with the vault's shares. |
|
||||
| `Flags` | Number | Set of bit-flags for this ledger object. |
|
||||
| `Issuer` | String | The address issuing the shares. This is always the vault's pseudo-account. |
|
||||
| `LedgerEntryType` | String | The ledger object type (i.e., `MPTokenIssuance`). |
|
||||
| `OutstandingAmount` | String | The total outstanding shares issued. |
|
||||
| `OwnerNode` | String | Identifies the page where this item is referenced in the owner's directory. |
|
||||
| `PreviousTxnID` | String | Identifies the transaction ID that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | The sequence of the ledger that contains the transaction that most recently modified this object. |
|
||||
| `Sequence` | Number | The transaction sequence number that created the shares. |
|
||||
| `index` | String | The unique index of the shares ledger entry. |
|
||||
| `mpt_issuance_id` | String | The identifier of the `MPTokenIssuance` object. This is always equal to the vault's `ShareMPTID`. |
|
||||
| `AssetScale` | Number | The decimal precision for share calculations. |
|
||||
|
||||
## Possible Errors
|
||||
|
||||
- Any of the [universal error types][].
|
||||
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -57,6 +57,7 @@ Flags are properties or other options associated with the `NFToken` object.
|
||||
| `lsfTrustLine` | `0x0004` | **DEPRECATED** If enabled, automatically create [trust lines](../../../concepts/tokens/fungible-tokens/index.md) to hold transfer fees. Otherwise, buying or selling this `NFToken` for a fungible token amount fails if the issuer does not have a trust line for that token. The [fixRemoveNFTokenAutoTrustLine amendment][] makes it invalid to enable this flag. |
|
||||
| `lsfTransferable` | `0x0008` | If enabled, this `NFToken` can be transferred from one holder to another. Otherwise, it can only be transferred to or from the issuer. |
|
||||
| `lsfReservedFlag` | `0x8000` | This flag is reserved for future use. Attempts to set this flag fail. |
|
||||
| `lsfMutable` | `0x0010` | If enabled, the `URI` field of the `NFToken` can be updated using the `NFTokenModify` transaction. |
|
||||
|
||||
`NFToken` flags are immutable: they can only be set during the [NFTokenMint transaction][] and cannot be changed later.
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
|:------------------------------|:----------|:------------------|:----------|:-------------|
|
||||
| `Account` | String | AccountID | Yes | The identifying (classic) address of this [account](../../../../concepts/accounts/index.md). |
|
||||
| `AccountTxnID` | String | UInt256 | No | The identifying hash of the transaction most recently sent by this account. This field must be enabled to use the [`AccountTxnID` transaction field](../../transactions/common-fields.md#accounttxnid). To enable it, send an [AccountSet transaction with the `asfAccountTxnID` flag enabled](../../transactions/types/accountset.md#accountset-flags). |
|
||||
| `AMMID` | String | UInt256 | No | {% amendment-disclaimer name="AMM" /%} The ledger entry ID of the corresponding AMM ledger entry. Set during account creation; cannot be modified. If present, indicates that this is a special AMM AccountRoot; always omitted on non-AMM accounts. |
|
||||
| `AMMID` | String | UInt256 | No | {% amendment-disclaimer name="AMM" /%} The ledger entry ID of the corresponding AMM ledger entry. Set during account creation; cannot be modified. If present, indicates that this is a special AMM [pseudo-account](../../../../concepts/accounts/pseudo-accounts.md) AccountRoot; always omitted on non-AMM accounts. |
|
||||
| `Balance` | String | Amount | No | The account's current [XRP balance in drops][XRP, in drops], represented as a string. |
|
||||
| `BurnedNFTokens` | Number | UInt32 | No | How many total of this account's issued [non-fungible tokens](../../../../concepts/tokens/nfts/index.md) have been burned. This number is always equal or less than `MintedNFTokens`. |
|
||||
| `Domain` | String | Blob | No | A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. [Cannot be more than 256 bytes in length.](https://github.com/XRPLF/rippled/blob/70d5c624e8cf732a362335642b2f5125ce4b43c1/include/xrpl/protocol/Protocol.h#L98) |
|
||||
@@ -53,15 +53,18 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes |The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `RegularKey` | String | AccountID | No | The address of a [key pair](../../../../concepts/accounts/cryptographic-keys.md) that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
|
||||
| `Sequence` | Number | UInt32 | Yes | The [sequence number](../../data-types/basic-data-types.md#account-sequence) of the next valid transaction for this account. |
|
||||
| `TicketCount` | Number | UInt32 | No | How many [Tickets](../../../../concepts/accounts/tickets.md) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. {% amendment-disclaimer name="TicketBatch" /%} |
|
||||
| `TickSize` | Number | UInt8 | No | How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. {% amendment-disclaimer name="TickSize" /%} |
|
||||
| `TicketCount` | Number | UInt32 | No | How many [Tickets](../../../../concepts/accounts/tickets.md) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. _(Added by the [TicketBatch amendment][].)_ |
|
||||
| `TickSize` | Number | UInt8 | No | How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Added by the [TickSize amendment][].)_ |
|
||||
| `TransferRate` | Number | UInt32 | No | A [transfer fee](../../../../concepts/tokens/fungible-tokens/transfer-fees.md) to charge other users for sending currency issued by this account to each other. |
|
||||
| `VaultID` | String | UInt256 | No | _(Requires the [SingleAssetVault amendment][] {% not-enabled /%}.)_ The ID of the `Vault` entry associated with this account. Set during account creation; cannot be modified. If present, indicates that this is a special Vault [pseudo-account](../../../../concepts/accounts/pseudo-accounts.md) AccountRoot; always omitted on non-Vault accounts. |
|
||||
| `WalletLocator` | String | UInt256 | No | An arbitrary 256-bit value that users can set. |
|
||||
| `WalletSize` | Number | UInt32 | No | Unused. (The code supports this field but there is no way to set it.) |
|
||||
|
||||
## Special AMM AccountRoot Entries
|
||||
## Special AMM AccountRoot (Pseudo-Account)
|
||||
|
||||
Automated Market Makers use an AccountRoot ledger entry to issue their LP Tokens and hold the assets in the AMM pool, and an [AMM ledger entry](amm.md) for tracking some of the details of the AMM. The address of an AMM's AccountRoot is randomized so that users cannot identify and fund the address in advance of the AMM being created. Unlike normal accounts, AMM AccountRoot objects are created with the following settings:
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
Automated Market Makers use an AccountRoot ledger entry (pseudo-account) to issue their LP Tokens and hold the assets in the AMM pool, and an [AMM ledger entry](amm.md) for tracking some of the details of the AMM. The address of an AMM's AccountRoot is randomized so that users cannot identify and fund the address in advance of the AMM being created. Unlike normal accounts, AMM AccountRoot objects are created with the following settings:
|
||||
|
||||
- `lsfDisableMaster` **enabled** and no means of authorizing transactions. This ensures no one can control the account directly, and it cannot send transactions.
|
||||
- `lsfDepositAuth` **enabled** and no accounts preauthorized. This ensures that the only way to add money to the AMM Account is using the [AMMDeposit transaction][].
|
||||
@@ -76,7 +79,21 @@ In addition, the following special rules apply to an AMM's AccountRoot entry:
|
||||
|
||||
Other than those exceptions, these accounts are like ordinary accounts; the LP Tokens they issue behave like other [tokens](../../../../concepts/tokens/index.md) except that those tokens can also be used in AMM-related transactions. You can check an AMM's balances and the history of transactions that affected it the same way you would with a regular account.
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
## Special Vault AccountRoot (Pseudo-Account)
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%}.)_
|
||||
|
||||
Vaults use an AccountRoot ledger entry (pseudo-account) to issue their shares and hold the assets deposited into the vault, and a [Vault entry][] for tracking the vault's configuration and state. The address of a vault's AccountRoot is randomized so that users cannot identify and fund the address in advance of the vault being created. Unlike normal accounts, vault AccountRoot objects are created with the following settings:
|
||||
|
||||
- `lsfDisableMaster` **enabled** and no means of authorizing transactions. This ensures no one can control the account directly, and it cannot send transactions.
|
||||
- `lsfDepositAuth` **enabled** and no accounts pre-authorized. This ensures that the only way to add money to the vault's AccountRoot is using the [VaultDeposit transaction][].
|
||||
- `lsfDefaultRipple` **enabled**. This enables rippling for the vault's pseudo-account.
|
||||
|
||||
In addition, the following special rules apply to a Vault's AccountRoot entry:
|
||||
|
||||
- The vault owner account must pay one [incremental owner reserve](../../../../concepts/accounts/reserves#base-reserve-and-owner-reserve) (currently {% $env.PUBLIC_OWNER_RESERVE %}) when creating the vault to cover the pseudo-account.
|
||||
- The `Sequence` number is always `0` and never changes, preventing the pseudo-account from submitting transactions.
|
||||
- A pseudo-account is automatically deleted when the vault is deleted, and cannot exist independently of a Vault entry.
|
||||
|
||||
## AccountRoot Flags
|
||||
|
||||
@@ -104,7 +121,7 @@ AccountRoot objects can have the following flags combined in the `Flags` field:
|
||||
|
||||
## {% $frontmatter.seo.title %} Reserve
|
||||
|
||||
The [reserve](../../../../concepts/accounts/reserves.md) for an AccountRoot entry is the base reserve, currently {% $env.PUBLIC_BASE_RESERVE %}, except in the case of a special AMM AccountRoot.
|
||||
The [reserve](../../../../concepts/accounts/reserves.md) for an AccountRoot entry is the base reserve, currently {% $env.PUBLIC_BASE_RESERVE %}, except in the case of a special AMM or Vault AccountRoot.
|
||||
|
||||
This XRP cannot be sent to others but it can be burned as part of the [transaction cost][].
|
||||
|
||||
@@ -117,6 +134,9 @@ The ID of an AccountRoot entry is the [SHA-512Half][] of the following values, c
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Pseudo-Accounts](../../../../concepts/accounts/pseudo-accounts.md)
|
||||
|
||||
- **Transactions:**
|
||||
- [AccountSet transaction][]
|
||||
- [AccountDelete transaction][]
|
||||
|
||||
152
docs/references/protocol/ledger-data/ledger-entry-types/vault.md
Normal file
152
docs/references/protocol/ledger-data/ledger-entry-types/vault.md
Normal file
@@ -0,0 +1,152 @@
|
||||
---
|
||||
seo:
|
||||
description: A Vault object defines the state of a tokenized vault.
|
||||
labels:
|
||||
- Vault
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# Vault
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/detail/ledger_entries.macro#L484-L504 "Source")
|
||||
|
||||
A {% code-page-name /%} object defines the state of a tokenized vault. It contains key details such as available assets, shares, total value, and other relevant information. You can create a {% code-page-name /%} object with the [VaultCreate](../../transactions/types/vaultcreate.md) transaction.
|
||||
|
||||
The {% code-page-name /%} object is tracked in an [Owner Directory](../../../protocol/ledger-data/ledger-entry-types/directorynode) owned by the Vault Owner account.
|
||||
Additionally, to facilitate `Vault` object lookup, the object is tracked in the owner directory of the vault's [pseudo-account](../../../../concepts/accounts/pseudo-accounts.md).
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example Vault JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"LedgerEntryType": "Vault",
|
||||
"Account": "rwCNM7SeUHTajEBQDiNqxDG8p1Mreizw85",
|
||||
"Asset": {
|
||||
"currency": "USD",
|
||||
"issuer": "rXJSJiZMxaLuH3kQBUV5DLipnYtrE6iVb"
|
||||
},
|
||||
"AssetsAvailable": "0",
|
||||
"AssetsMaximum": "1000000",
|
||||
"AssetsTotal": "0",
|
||||
"Data": "5661756C74206D65746164617461",
|
||||
"Flags": 0,
|
||||
"LossUnrealized": "0",
|
||||
"Owner": "rNGHoQwNG753zyfDrib4qDvvswbrtmV8Es",
|
||||
"OwnerNode": "0",
|
||||
"Scale": 6,
|
||||
"Sequence": 200370,
|
||||
"ShareMPTID": "0000000169F415C9F1AB6796AB9224CE635818AFD74F8175",
|
||||
"WithdrawalPolicy": 1,
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common ledger entry fields](../../../protocol/ledger-data/common-fields), {% code-page-name /%} {% code-page-name /%} entries have the following fields:
|
||||
|
||||
| Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
| :------------------ | :------------ | :---------------- | :-------- | -----------------|
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | Ledger object type. The default value is `0x0081`. |
|
||||
| `LedgerIndex` | String | UInt16 | Yes | The unique identifier of the ledger object. |
|
||||
| `Flags` | String | UInt32 | Yes | Set of bit-flags for this ledger object. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | Identifies the transaction ID that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The sequence of the ledger that contains the transaction that most recently modified this object. |
|
||||
| `Sequence` | Number | UInt32 | Yes | The transaction sequence number that created the vault. |
|
||||
| `OwnerNode` | Number | UInt64 | Yes | Identifies the page where this item is referenced in the owner's directory. |
|
||||
| `Owner` | String | AccountID | Yes | The account address of the Vault Owner. |
|
||||
| `Account` | String | AccountID | Yes | The address of the vault's pseudo-account. |
|
||||
| `Data` | String | Blob | No | Arbitrary metadata, in hex format, about the vault. Limited to 256 bytes. See [Data Field Format](#data-field-format) for more information. |
|
||||
| `Asset` | Object | Issue | Yes | The asset of the vault. The vault supports XRP, trust line tokens, and MPTs. |
|
||||
| `AssetsTotal` | Number | Number | Yes | The total value of the vault. |
|
||||
| `AssetsAvailable` | Number | Number | Yes | The asset amount that is available in the vault. |
|
||||
| `AssetsMaximum` | Number | Number | No | The maximum asset amount that can be held in the vault. If set to 0, this indicates there is no cap. |
|
||||
| `LossUnrealized` | Number | Number | Yes | The potential loss amount that is not yet realized, expressed as the vault's asset. Only a protocol connected to the vault can modify this attribute. |
|
||||
| `ShareMPTID` | String | UInt192 | Yes | The identifier of the share `MPTokenIssuance` object. |
|
||||
| `WithdrawalPolicy` | String | UInt8 | Yes | Indicates the withdrawal strategy used by the vault. |
|
||||
| `Scale` | Number | UInt8 | No | Specifies decimal precision for share calculations. Assets are multiplied by 10<sup>Scale</sup > to convert fractional amounts into whole number shares. For example, with a `Scale` of `6`, depositing 20.3 units creates 20,300,000 shares (20.3 × 10<sup>Scale</sup >). For **trust line tokens** this can be configured at vault creation, and valid values are between 0-18, with the default being `6`. For **XRP** and **MPTs**, this is fixed at `0`. See [Scaling Factor](#scaling-factor) for more information. |
|
||||
|
||||
### Data Field Format
|
||||
|
||||
While any data structure is allowed in the `Data` field, the following format is recommended:
|
||||
|
||||
| Field Name | Key | Type | Description |
|
||||
| ---------- | --- | ------ | ------------------------------------------------------------------------------------------ |
|
||||
| Name | n | String | Human-readable name of the vault. Should clearly reflect the vault's strategy or mandate. |
|
||||
| Website | w | String | Website associated with the vault. Omit protocol (`https://`) and `www` to conserve space. |
|
||||
|
||||
To fit within the 256-byte limit, vault metadata should use the _compressed_ JSON keys.
|
||||
|
||||
Following this format helps XRPL explorers and other tools parse and display vault information in a standardized way, improving discoverability and user experience.
|
||||
|
||||
#### Example JSON
|
||||
|
||||
For a vault named "LATAM Fund II" with website "examplefund.com":
|
||||
|
||||
```json
|
||||
{
|
||||
"n": "LATAM Fund II",
|
||||
"w": "examplefund.com"
|
||||
}
|
||||
```
|
||||
|
||||
1. Remove any whitespace from the JSON:
|
||||
|
||||
`{"n":"LATAM Fund II","w":"examplefund.com"}`
|
||||
|
||||
2. Hex-encode the JSON. For example:
|
||||
|
||||
```sh
|
||||
# Using xxd (macOS/Linux)
|
||||
echo -n '{"n":"LATAM Fund II","w":"examplefund.com"}' | xxd -p | tr -d '\n'
|
||||
```
|
||||
|
||||
You should see this result: `7b226e223a224c4154414d2046756e64204949222c2277223a226578616d706c6566756e642e636f6d227d`
|
||||
|
||||
### Scaling Factor
|
||||
|
||||
The **`Scale`** field enables the vault to accurately represent fractional asset values using integer-only MPT shares, which prevents the loss of value from decimal truncation. It defines a scaling factor, calculated as 10<sup>Scale</sup>, that converts a decimal asset amount into a corresponding whole number of shares.
|
||||
|
||||
The scaling factor behavior varies by asset type:
|
||||
|
||||
- **Trust line token**: When a vault holds a trust line token, the `Scale` is configurable by the Vault Owner when creating the vault. The value can range from **0** to a maximum of **18**, with a default of **6**. This flexibility allows issuers to set a level of precision appropriate for their specific token.
|
||||
|
||||
- **XRP**: When a vault holds XRP, the `Scale` is fixed at **0**. This aligns with XRP's native structure, where one share represents one drop, and one XRP equals 1,000,000 drops. Therefore, a deposit of 10 XRP to an empty vault will result in the issuance of 10,000,000 shares.
|
||||
|
||||
- **MPT**: When a vault holds an MPT, its `Scale` is fixed at **0**. This creates a 1-to-1 relationship between deposited MPT units and the shares issued. For example, depositing 10 MPTs to an empty vault issues 10 shares. The value of a single MPT is determined at the issuer's discretion.
|
||||
|
||||
{% admonition type="warning" name="Warning" %}
|
||||
If an MPT is set to represent a large value, the vault owner and the depositor must be cautious. Since only whole MPT units are used in calculations, any value that is not a multiple of a single MPT's value may be lost due to rounding during a transaction.
|
||||
{% /admonition %}
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
{% code-page-name /%} entries can have the following flags:
|
||||
|
||||
| Flag Name | Flag Value | Description |
|
||||
| :---------------- | :----------- | :---------------------------|
|
||||
| `lsfVaultPrivate` | `0x00010000` | If set, indicates that the vault is private. This flag can only be set when _creating_ the vault. |
|
||||
|
||||
## Vault ID Format
|
||||
|
||||
The ID of a {% code-page-name /%} entry is the [SHA-512Half][] of the following values, concatenated in order:
|
||||
|
||||
- The {% code-page-name /%} space key `0x0056` (capital V).
|
||||
- The [AccountID](../../../protocol/binary-format/#accountid-fields) of the account submitting the transaction (for example, the vault owner).
|
||||
- The transaction `Sequence` number. If the transaction used a [Ticket](../../../../concepts/accounts/tickets), use the `TicketSequence` value.
|
||||
|
||||
## See Also
|
||||
|
||||
**API Methods**:
|
||||
- [vault_info method][]
|
||||
|
||||
**Transactions**:
|
||||
- [VaultClawback transaction][]
|
||||
- [VaultCreate transaction][]
|
||||
- [VaultDelete transaction][]
|
||||
- [VaultDeposit transaction][]
|
||||
- [VaultSet transaction][]
|
||||
- [VaultWithdraw transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
70
docs/references/protocol/transactions/types/vaultclawback.md
Normal file
70
docs/references/protocol/transactions/types/vaultclawback.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
seo:
|
||||
description: Allows the issuer of a trust line token or MPT to claw back funds from the vault.
|
||||
labels:
|
||||
- Transactions
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# VaultClawback
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/VaultClawback.cpp "Source")
|
||||
|
||||
Performs a [Clawback](../../../../use-cases/tokenization/stablecoin-issuer#clawback) from the vault, exchanging the shares of an account for assets.
|
||||
|
||||
Under the hood, the transaction performs a [VaultWithdraw](./vaultwithdraw.md) on behalf of the account from which assets are clawed back, converting its shares into assets and transferring the funds to the asset’s issuing account. Because of this, {% code-page-name /%} must respect any applicable fees or penalties (e.g., unrealized loss).
|
||||
|
||||
{% admonition type="warning" name="Warning" %}
|
||||
Clawbacks cannot be performed on native XRP.
|
||||
{% /admonition %}
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "VaultClawback",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108682,
|
||||
"Sequence": 8,
|
||||
"VaultID": "77D6234D074E505024D39C04C3F262997B773719AB29ACFA83119E4210328776",
|
||||
"Holder": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
|
||||
"Amount" : "10000"
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
| :--------- | :-------- | :---------------- | :-------- | :---------- |
|
||||
| `VaultID` | String | Hash256 | Yes | The unique identifier of the vault from which assets are withdrawn. |
|
||||
| `Holder` | String | AccountID | Yes | The unique identifier of the account from which to claw back the assets. |
|
||||
| `Amount` | Number | Number | No | The asset amount to claw back. When this field is set to 0, the transaction claws back all funds, up to the total shares the `Holder` owns. |
|
||||
|
||||
If the requested amount exceeds the vault’s available assets, the transaction claws back only up to the vault's `AssetsAvailable` balance. Otherwise, it retrieves the exact asset amount specified in the transaction.
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
There are no flags defined for {% code-page-name /%} transactions.
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](../../../protocol/transactions/transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
| :---------------------- | :---------- |
|
||||
| `tecNO_ENTRY` | The `Vault` object with the specified `VaultID` does not exist on the ledger. |
|
||||
| `tecNO_PERMISSION` | The transaction attempts to claw back XRP, or the asset is a trust line token or MPT and the transaction isn't submitted by the issuing account. |
|
||||
| `tecWRONG_ASSET` | The asset in the transaction does not match the vault's asset type. |
|
||||
| `tecINSUFFICIENT_FUNDS` | The `MPToken` object for the vault share of the `Holder` account does not exist, or the `MPToken.MPTAmount` is 0. |
|
||||
| `temDISABLED` | The Single Asset Vault amendment is not enabled. |
|
||||
| `temMALFORMED` | The transaction was not validly formatted. For example, if the `VaultID` is not provided. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
99
docs/references/protocol/transactions/types/vaultcreate.md
Normal file
99
docs/references/protocol/transactions/types/vaultcreate.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
seo:
|
||||
description: Creates a new vault object in the ledger.
|
||||
labels:
|
||||
- Transactions
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# VaultCreate
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/VaultCreate.cpp "Source")
|
||||
|
||||
Creates a new `Vault` ledger entry, an `MPTokenIssuance` ledger entry for the vault’s shares, and an `AccountRoot` for the vault’s [pseudo-account](../../../../concepts/accounts/pseudo-accounts.md).
|
||||
|
||||
Only the Vault Owner can initiate this transaction.
|
||||
|
||||
{% admonition type="info" name="Note" %}
|
||||
Currently, the same account that creates the vault must also create other protocols, though this may change in the future.
|
||||
{% /admonition %}
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "VaultCreate",
|
||||
"Account": "rNGHoQwNG753zyfDrib4qDvvswbrtmV8Es",
|
||||
"Asset": {
|
||||
"currency": "USD",
|
||||
"issuer": "rXJSJiZMxaLuH3kQBUV5DLipnYtrE6iVb"
|
||||
},
|
||||
"AssetsMaximum": "1000000",
|
||||
"Data": "5661756C74206D65746164617461",
|
||||
"Fee": "5000000",
|
||||
"Flags": 0,
|
||||
"MPTokenMetadata": "7B2274223A225473745368617265222C226E223A2254657374205661756C74205368617265222C2264223A22412074657374207661756C742073686172652E222C2269223A226578616D706C652E6F72672F73686172652D69636F6E2E706E67222C226163223A22727761222C226173223A22657175697479222C22696E223A224D53205465737420497373756572222C227573223A5B7B2275223A226578616D706C657969656C642E636F2F7473747368617265222C2263223A2277656273697465222C2274223A2250726F647563742050616765227D2C7B2275223A226578616D706C657969656C642E636F2F646F6373222C2263223A22646F6373222C2274223A225969656C6420546F6B656E20446F6373227D5D2C226169223A7B22766F6C6174696C697479223A226C6F77227D7D",
|
||||
"Scale": 6,
|
||||
"Sequence": 200370,
|
||||
"WithdrawalPolicy": 1
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](../../../../references/protocol/transactions/common-fields#transaction-common-fields), {% code-page-name /%} transactions use the following fields:
|
||||
|
||||
| Field Name | JSON Type | [Internal Type][] | Required? |Description |
|
||||
|:-------------------|:--------------|:------------------|:----------|:------------------|
|
||||
| `Data` | String | Blob | No | Arbitrary vault metadata, in hex format, limited to 256 bytes. See [Data Field Format](../../ledger-data/ledger-entry-types/vault.md#data-field-format) for the recommended format. |
|
||||
| `Asset` | Object | Issue | Yes | The asset to be held in the vault. This can be XRP, a trust line token, or an MPT. If the asset is a trust line token, the transaction creates a [trust line](../../../../concepts/tokens/fungible-tokens/trust-line-tokens.md#structure) between the vault's pseudo-account and the issuer of the asset. If the asset is an MPT, the transaction creates an `MPToken` object for the vault's pseudo-account. |
|
||||
| `AssetsMaximum` | Number | UInt64 | No | The maximum asset amount that can be held in a vault. |
|
||||
| `MPTokenMetadata` | String | Blob | No | Arbitrary metadata about the share `MPToken`, in hex format, limited to 1024 bytes. |
|
||||
| `WithdrawalPolicy` | Number | UInt8 | No | Indicates the withdrawal strategy used by the vault. The default value is `0x0001`, mapped to the string `vaultStrategyFirstComeFirstServe`. See [WithdrawalPolicy](#withdrawalpolicy). |
|
||||
| `DomainID` | String | Hash256 | No | The [PermissionedDomain](../../../../concepts/tokens/decentralized-exchange/permissioned-domains.md) object ID associated with the shares of this vault. If provided, the transaction creates a private vault, which restricts access to accounts with [credentials](../../../../concepts/decentralized-storage/credentials.md) in the specified Permissioned Domain. |
|
||||
| `Scale` | Number | UInt8 | No | _(Trust line tokens only)_ Specifies decimal precision for share calculations. Assets are multiplied by 10<sup>Scale</sup > to convert fractional amounts into whole number shares. For example, with a `Scale` of `6`, depositing 20.3 units creates 20,300,000 shares (20.3 × 10<sup>Scale</sup >). For **trust line tokens** this can be configured at vault creation, and valid values are between 0-18, with the default being `6`. For **XRP** and **MPTs**, this is fixed at `0`.|
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
{% code-page-name /%} transactions support additional values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Value | Description |
|
||||
| :---------------------------- | :------------| -------------------------|
|
||||
| `tfVaultPrivate` | `0x00010000` | Indicates that the vault is private. This flag can only be set when _creating_ the vault. |
|
||||
| `tfVaultShareNonTransferable` | `0x00020000` | Indicates the vault share is non-transferable. This flag can only be set when _creating_ the vault. |
|
||||
|
||||
## WithdrawalPolicy
|
||||
|
||||
A `WithdrawalPolicy` defines the strategy for processing withdrawal requests from a vault. This policy governs how liquidity is removed. Currently, only one strategy is supported:
|
||||
|
||||
| Policy Name | Value | Description |
|
||||
| :--------------------------------- | :------- | -------------------------|
|
||||
| `vaultStrategyFirstComeFirstServe` | `0x0001` | Requests are processed on a first-come, first-served basis. With this strategy, a depositor can redeem any amount of assets, provided they hold a sufficient number of shares. |
|
||||
|
||||
## Transaction Cost
|
||||
|
||||
Since the {% code-page-name /%} transaction creates a new `AccountRoot` object for a vault’s pseudo-account, it incurs a higher than usual [transaction cost](../../../../concepts/transactions/transaction-cost) to deter ledger spam. Instead of the standard minimum of 0.00001 XRP, {% code-page-name /%} must destroy an [incremental owner reserve](../../../../concepts/accounts/reserves#base-reserve-and-owner-reserve), currently 0.2 XRP.
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](../transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
| :------------------------ | :----------------------------------|
|
||||
| `tecNO_AUTH` | The asset is an MPT and the `lsfMPTCanTransfer` flag is not set in the `MPTokenIssuance` object, meaning the vault cannot be created with a non-transferable MPT. |
|
||||
| `tecLOCKED` | The asset is an MPT and the `lsfMPTLocked` flag is set in the `MPTokenIssuance` object, meaning the asset is locked. |
|
||||
| `tecFROZEN` | The issuer has frozen the asset to be held in the vault. |
|
||||
| `tecOBJECT_NOT_FOUND` | A ledger entry specified in the transaction does not exist. For example, the provided `DomainID` does not exist. |
|
||||
| `temMALFORMED` | The transaction was not validly formatted. For example, the `Data` field is larger than 256 bytes. |
|
||||
| `tecINSUFFICIENT_RESERVE` | There is insufficient `AccountRoot.Balance` for the Owner Reserve. |
|
||||
| `terNO_RIPPLE` | The issuer of the asset has not enabled the [Default Ripple flag](../../../../concepts/tokens/fungible-tokens/stablecoins/configuration#default-ripple). |
|
||||
| `terNO_ACCOUNT` | The issuer account of the vault's asset does not exist. |
|
||||
| `temDISABLED` | Either the Single Asset Vault amendment is not enabled, a `DomainID` is provided and the Permissioned Domains amendment is not enabled, or the MPTokensV1 amendment is not enabled. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
59
docs/references/protocol/transactions/types/vaultdelete.md
Normal file
59
docs/references/protocol/transactions/types/vaultdelete.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
seo:
|
||||
description: Deletes an existing Vault object from the ledger.
|
||||
labels:
|
||||
- Transactions
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# VaultDelete
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/VaultDelete.cpp "Source")
|
||||
|
||||
Permanently deletes an existing `Vault` object from the ledger, removes all associated ledger entries, and frees up the reserve requirement for the Vault Owner.
|
||||
|
||||
Only the Vault Owner can initiate this transaction, and the vault must be completely empty before deletion.
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "VaultDelete",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108682,
|
||||
"Sequence": 8,
|
||||
"VaultID": "77D6234D074E505024D39C04C3F262997B773719AB29ACFA83119E4210328776"
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](https://xrpl.org/docs/references/protocol/transactions/common-fields#transaction-common-fields), {% code-page-name /%} transactions use the following fields:
|
||||
|
||||
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
| :----------------- | :-------- | :---------------- | :-------- | :------------|
|
||||
| `VaultID` | String | Hash256 | Yes | The unique identifier of the vault that needs to be deleted. |
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
There are no flags defined for {% code-page-name /%} transactions.
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, VaultCreate transactions can result in the following [transaction result codes](../../../protocol/transactions/transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
| :------------------------ | :----------------------------------|
|
||||
| `tecNO_ENTRY` | The `Vault` object with the provided `VaultID` does not exist on the ledger. |
|
||||
| `tecNO_PERMISSION` | The account submitting the transaction is not the `Owner` of the vault. |
|
||||
| `tecHAS_OBLIGATIONS` | The vault to be deleted is connected to objects that cannot be deleted in the ledger. For example, the owner directory of the vault's pseudo-account contains references to any objects other than the vault, shares, or assets. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
95
docs/references/protocol/transactions/types/vaultdeposit.md
Normal file
95
docs/references/protocol/transactions/types/vaultdeposit.md
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
seo:
|
||||
description: Deposits a specified number of assets into a vault in exchange for shares.
|
||||
labels:
|
||||
- Transactions
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# VaultDeposit
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/VaultDeposit.cpp "Source")
|
||||
|
||||
Deposits a specified number of assets into a vault in exchange for shares.
|
||||
|
||||
For private vaults, the depositor must be authorized to interact with the vault’s shares and have [Credentials](../../../../concepts/decentralized-storage/credentials.md) in the [Permissioned Domain](../../../../concepts/tokens/decentralized-exchange/permissioned-domains.md) of the share.
|
||||
|
||||
Public vaults require no authorization, and anyone can deposit as long as they meet the asset type requirement and have sufficient funds.
|
||||
|
||||
{% admonition type="warning" name="Warning" %}
|
||||
A depositor cannot deposit assets into the vault if:
|
||||
|
||||
- The asset is frozen for the depositor.
|
||||
- The trust line between the pseudo-account and the issuer is frozen, or the `MPToken` is locked.
|
||||
- The vault is private and the depositor's credentials have expired.
|
||||
{% /admonition %}
|
||||
|
||||
If successful, the transaction moves the assets from the depositor's account to the vault's pseudo-account, issues the corresponding vault shares, and updates the vault’s balance.
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "VaultDeposit",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108682,
|
||||
"Sequence": 8,
|
||||
"VaultID": "77D6234D074E505024D39C04C3F262997B773719AB29ACFA83119E4210328776",
|
||||
"Amount" : {
|
||||
"currency" : "TST",
|
||||
"issuer" : "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd",
|
||||
"value" : "2.5"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](../../../protocol/transactions/common-fields#transaction-common-fields), {% code-page-name /%} transactions use the following fields:
|
||||
|
||||
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
| :-----------------------| :------------ | :---------------- | :-------- | :-------------------|
|
||||
| `VaultID` | String | Hash256 | Yes | The unique identifier of the vault to which the asset is deposited. |
|
||||
| `Amount` | Object | Amount | Yes | The asset and quantity to be deposited into the vault.|
|
||||
|
||||
The deposited asset must match the vault’s designated asset for the transaction to succeed. Depending on the asset type, the following changes occur:
|
||||
|
||||
- **XRP**: The vault’s pseudo-account balance increases, and the depositor’s balance decreases.
|
||||
- **Trust line token**: The [trust line](../../../../concepts/tokens/fungible-tokens/trust-line-tokens.md#structure) balance between the vault's pseudo-account and the asset issuer is adjusted.
|
||||
- **MPT**: The `MPToken.MPTAmount` of both the depositor and the vault's pseudo-account is updated.
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
There are no flags defined for {% code-page-name /%} transactions.
|
||||
|
||||
## Transfer Fees
|
||||
|
||||
A single asset vault does not apply the [transfer fee](../../../../concepts/tokens/fungible-tokens/transfer-fees) to {% code-page-name /%} transactions. Additionally, whenever a protocol moves assets from or to a vault, the transfer fee isn't charged.
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](../../../protocol/transactions/transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
| :---------------------- | :----------------------------------|
|
||||
| `tecNO_ENTRY` | The `Vault` object with the provided `VaultID` does not exist on the ledger. |
|
||||
| `tecOBJECT_NOT_FOUND` | A ledger entry specified in the transaction does not exist. |
|
||||
| `tecWRONG_ASSET` | The asset of the vault does not match the asset being deposited. |
|
||||
| `tecINSUFFICIENT_FUNDS` | The depositor does not have sufficient funds to make a deposit. |
|
||||
| `tecLIMIT_EXCEEDED` | Adding the provided `Amount` to the `AssetsTotal` exceeds the `AssetsMaximum` value. |
|
||||
| `tecNO_AUTH` | Either the vault is private and the depositing account does not have credentials in the share's Permissioned Domain, or the asset is a non-transferable MPT. |
|
||||
| `tecFROZEN` | Either the trust line between the issuer and the depositor is frozen, or the asset is globally frozen. |
|
||||
| `tecLOCKED` | Either the MPT asset is locked for the depositor, or if the asset is globally locked. |
|
||||
| `temMALFORMED` | The transaction was not validly formatted. For example, if the `VaultID` is not provided. |
|
||||
| `temDISABLED` | The Single Asset Vault amendment is not enabled. |
|
||||
| `temBAD_AMOUNT` | The `Amount` field of the transaction is invalid. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
70
docs/references/protocol/transactions/types/vaultset.md
Normal file
70
docs/references/protocol/transactions/types/vaultset.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
seo:
|
||||
description: Modifies a single asset vault that you own.
|
||||
labels:
|
||||
- Transactions
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# VaultSet
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/VaultSet.cpp "Source")
|
||||
|
||||
Modifies a single asset vault that you own. This transaction allows the Vault Owner to update certain mutable fields, including vault metadata and the maximum asset amount.
|
||||
|
||||
{% admonition type="warning" name="Warning" %}
|
||||
Once a vault is created, its public or private status is permanent and cannot be changed. The [tfVaultPrivate](../../ledger-data/ledger-entry-types/vault.md#vault-flags) flag determines this status, and once set, it cannot be updated.
|
||||
{% /admonition %}
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "VaultSet",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108682,
|
||||
"Sequence": 8,
|
||||
"VaultID": "77D6234D074E505024D39C04C3F262997B773719AB29ACFA83119E4210328776",
|
||||
"Data": "5468697320697320617262697472617279206D657461646174612061626F757420746865207661756C742E",
|
||||
"AssetsMaximum": 5,
|
||||
"DomainID": "77D6234D074E505024D39C04C3F262997B773719AB29ACFA83119E4210328776"
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](../../../protocol/transactions/common-fields#transaction-common-fields), {% code-page-name /%} transactions use the following fields:
|
||||
|
||||
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
| :---------------- | :-------- | :---------------- | :-------- | :-------------------|
|
||||
| `VaultID` | String | Hash256 | Yes | The unique identifier of the vault that needs to be updated. |
|
||||
| `Data` | String | Blob | No | Arbitrary vault metadata, limited to 256 bytes. See [Data Field Format](../../ledger-data/ledger-entry-types/vault.md#data-field-format) for the recommended format. |
|
||||
| `AssetsMaximum` | Number | Number | No | The maximum asset amount that can be held in a vault. The value cannot be lower than the current `AssetsTotal`, unless the value is 0. |
|
||||
| `DomainID` | String | Hash256 | No | The [PermissionedDomain](../../../../concepts/tokens/decentralized-exchange/permissioned-domains.md) object ID associated with the shares of this vault. The `DomainID` is only required when updating a private vault. |
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
There are no flags defined for {% code-page-name /%} transactions.
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](../../../protocol/transactions/transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
| :-------------------- | :-------------------------------------|
|
||||
| `tecNO_ENTRY` | The transaction attempted to modify a vault that does not exist. Check the `VaultID` field of the transaction. |
|
||||
| `tecOBJECT_NOT_FOUND` | The `PermissionedDomain` object with the provided `DomainID` does not exist. |
|
||||
| `tecNO_PERMISSION` | The account submitting the transaction is not the `Owner` of the vault, or is trying to set a `DomainID` for a public vault. |
|
||||
| `temMALFORMED` | The transaction was not validly formatted. For example, the `Data` field is larger than 256 bytes. |
|
||||
| `tecLIMIT_EXCEEDED` | The _new_ `AssetsMaximum` value is **lower** than the vault's _current_ `AssetsTotal`. |
|
||||
| `temDISABLED` | Either the Single Asset Vault amendment is not enabled, or a `DomainID` is provided and the Permissioned Domains amendment is not enabled. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
89
docs/references/protocol/transactions/types/vaultwithdraw.md
Normal file
89
docs/references/protocol/transactions/types/vaultwithdraw.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
seo:
|
||||
description: Redeem vault shares for assets.
|
||||
labels:
|
||||
- Transactions
|
||||
- Single Asset Vault
|
||||
---
|
||||
|
||||
# VaultWithdraw
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/VaultWithdraw.cpp "Source")
|
||||
|
||||
Redeem vault shares for assets. The amount of assets received depends on the [exchange rate](../../../../concepts/tokens/single-asset-vault.md#exchange-algorithm), which adjusts based on the vault’s total assets and any [unrealized losses](../../../../concepts/tokens/single-asset-vault.md#unrealized-loss).
|
||||
|
||||
{% admonition type="info" name="Note" %}
|
||||
The `VaultWithdraw` transaction does not respect the Permissioned Domain rules. In other words, any account that holds the shares of the vault can redeem them. This is to avoid a situation where a depositor deposits assets to a private vault to then have their access revoked by invalidating their credentials, and thus losing access to their funds.
|
||||
{% /admonition %}
|
||||
|
||||
A depositor cannot redeem liquidity if the trust line between the pseudo-account and the issuer of the vault asset is frozen, or the `MPToken` is locked.
|
||||
|
||||
_(Requires the [SingleAssetVault amendment][] {% not-enabled /%})_
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "VaultWithdraw",
|
||||
"Account": "rGFBE8WA2ZKfqGGB7CFkLusVt7hsVT4r8H",
|
||||
"Amount": {
|
||||
"mpt_issuance_id": "000000016E1417CA9DFD23400B05E43FDE5BB8D8FFA817CA",
|
||||
"value": "5"
|
||||
},
|
||||
"Destination": "rGFBE8WA2ZKfqGGB7CFkLusVt7hsVT4r8H",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"Sequence": 200380,
|
||||
"VaultID": "A7B7B3ED3F5BD8E58C9064278EB29519CD6475D87A4517707DE108E65AE9C08C",
|
||||
}
|
||||
```
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](../../../protocol/transactions/common-fields#transaction-common-fields), {% code-page-name /%} transactions use the following fields:
|
||||
|
||||
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
| :-----------------------| :------------ | :---------------- | :-------- | :-------------------|
|
||||
| `VaultID` | String | Hash256 | Yes | The unique identifier of the vault to which the assets are deposited. |
|
||||
| `Amount` | Number | Amount | Yes | The exact amount of vault asset to withdraw or vault share to redeem. |
|
||||
| `Destination` | String | AccountID | No | An account to receive the assets. This account must be able to receive the vault asset or the transaction fails. |
|
||||
| `DestinationTag` | Number | UInt32 | No | Arbitrary tag identifying the reason for the withdrawal to the destination. |
|
||||
|
||||
There are two ways to specify the transaction `Amount` field:
|
||||
|
||||
<!-- Added extra column to avoid first column text from being automatically bolded -->
|
||||
| |Specify Assets | Specify Shares |
|
||||
|:--- |:-------------- |:--------------- |
|
||||
| |<ul><li>If the `Amount` field specifies an **asset amount** (e.g., 100 XRP), the transaction burns the necessary number of shares to provide the requested amount.</li><li>If the vault has an **unrealized loss**, withdrawing the same amount of assets requires burning more shares.</li></ul> | <ul><li>If the `Amount` field specifies a **share amount** (e.g., 500 vault shares), the transaction converts those shares into the corresponding amount of assets.</li><li>If the vault has an **unrealized loss**, each share is worth less, meaning fewer assets are received.</li></ul> |
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
There are no flags defined for {% code-page-name /%} transactions.
|
||||
|
||||
## Transfer Fees
|
||||
|
||||
A single asset vault does not apply the [transfer fee](../../../../concepts/tokens/fungible-tokens/transfer-fees) to {% code-page-name /%} transactions. Additionally, whenever a protocol moves assets from or to a vault, the Transfer Fee must not be charged.
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](../../../protocol/transactions/transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
| :---------------------- | :----------------------------------|
|
||||
| `tecNO_ENTRY` | The `Vault` object with the provided `VaultID` does not exist on the ledger. |
|
||||
| `tecOBJECT_NOT_FOUND` | A ledger entry specified in the transaction does not exist. |
|
||||
| `tecNO_PERMISSION` | The destination account specified does not have permission to receive the asset. |
|
||||
| `tecWRONG_ASSET` | The unit of `Amount` is neither a share or asset of the vault. |
|
||||
| `tecINSUFFICIENT_FUNDS` | There is insufficient liquidity in the vault to fill the request. |
|
||||
| `tecFROZEN` | Either the trust line between the issuer and the destination account is frozen, or the asset is globally frozen. |
|
||||
| `tecLOCKED` | The MPT asset is locked for the depositor, destination account, or if the asset is globally locked. |
|
||||
| `temMALFORMED` | The transaction is not validly formatted. For example, the `VaultID` is not provided. |
|
||||
| `temDISABLED` | The Single Asset Vault amendment is not enabled. |
|
||||
| `temBAD_AMOUNT` | The `Amount` field of the transaction is invalid. For example, the provided amount is set to 0. |
|
||||
| `tecNO_AUTH` | The asset is a non-transferable MPT. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Vault entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -1783,8 +1783,7 @@ When this amendment is activated, the XRP Ledger will undergo a brief scheduled
|
||||
|
||||
Creates a structure for aggregating assets from multiple depositors. This is intended to be used with the proposed on-chain Lending Protocol.
|
||||
|
||||
Specification: [XLS-65](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0065d-single-asset-vault).
|
||||
|
||||
Specification: [XLS-65](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0065-single-asset-vault).
|
||||
|
||||
### SortedDirectories
|
||||
[SortedDirectories]: #sorteddirectories
|
||||
|
||||
@@ -155,6 +155,7 @@
|
||||
- page: docs/concepts/tokens/decentralized-exchange/automated-market-makers.md
|
||||
- page: docs/concepts/tokens/decentralized-exchange/permissioned-domains.md
|
||||
- page: docs/concepts/tokens/decentralized-exchange/permissioned-dexes.md
|
||||
- page: docs/concepts/tokens/single-asset-vault.md
|
||||
- page: docs/concepts/accounts/index.md
|
||||
expanded: false
|
||||
items:
|
||||
@@ -168,6 +169,7 @@
|
||||
- page: docs/concepts/accounts/depositauth.md
|
||||
- page: docs/concepts/accounts/tickets.md
|
||||
- page: docs/concepts/accounts/permission-delegation.md
|
||||
- page: docs/concepts/accounts/pseudo-accounts.md
|
||||
- page: docs/concepts/xrpl-sidechains/index.md
|
||||
expanded: false
|
||||
items:
|
||||
@@ -386,6 +388,7 @@
|
||||
- page: docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
|
||||
- page: docs/references/protocol/ledger-data/ledger-entry-types/signerlist.md
|
||||
- page: docs/references/protocol/ledger-data/ledger-entry-types/ticket.md
|
||||
- page: docs/references/protocol/ledger-data/ledger-entry-types/vault.md
|
||||
- page: docs/references/protocol/ledger-data/ledger-entry-types/xchainownedclaimid.md
|
||||
- page: docs/references/protocol/ledger-data/ledger-entry-types/xchainownedcreateaccountclaimid.md
|
||||
- page: docs/references/protocol/transactions/index.md
|
||||
@@ -444,6 +447,12 @@
|
||||
- page: docs/references/protocol/transactions/types/signerlistset.md
|
||||
- page: docs/references/protocol/transactions/types/ticketcreate.md
|
||||
- page: docs/references/protocol/transactions/types/trustset.md
|
||||
- page: docs/references/protocol/transactions/types/vaultclawback.md
|
||||
- page: docs/references/protocol/transactions/types/vaultcreate.md
|
||||
- page: docs/references/protocol/transactions/types/vaultdelete.md
|
||||
- page: docs/references/protocol/transactions/types/vaultdeposit.md
|
||||
- page: docs/references/protocol/transactions/types/vaultset.md
|
||||
- page: docs/references/protocol/transactions/types/vaultwithdraw.md
|
||||
- page: docs/references/protocol/transactions/types/xchainaccountcreatecommit.md
|
||||
- page: docs/references/protocol/transactions/types/xchainaddaccountcreateattestation.md
|
||||
- page: docs/references/protocol/transactions/types/xchainaddclaimattestation.md
|
||||
@@ -588,6 +597,12 @@
|
||||
- page: docs/references/http-websocket-apis/public-api-methods/utility-methods/json.md
|
||||
- page: docs/references/http-websocket-apis/public-api-methods/utility-methods/ping.md
|
||||
- page: docs/references/http-websocket-apis/public-api-methods/utility-methods/random.md
|
||||
|
||||
- page: docs/references/http-websocket-apis/public-api-methods/vault-methods/index.md
|
||||
expanded: false
|
||||
items:
|
||||
- page: docs/references/http-websocket-apis/public-api-methods/vault-methods/vault_info.md
|
||||
|
||||
- page: docs/references/http-websocket-apis/admin-api-methods/index.md
|
||||
expanded: false
|
||||
items:
|
||||
|
||||
Reference in New Issue
Block a user