From 64d4638929fc8406c87d797e7a0f4ba2e0c67342 Mon Sep 17 00:00:00 2001 From: Maria Date: Mon, 10 Aug 2026 14:00:53 +0100 Subject: [PATCH 1/3] Update landing pages and remove docs --- docs/_snippets/common-links.md | 18 +- docs/xls-56-batch-transactions/index.page.tsx | 30 ++- .../concepts/sponsored-fees-and-reserves.md | 124 ----------- .../index.page.tsx | 16 +- .../references/apis/account_sponsoring.md | 206 ----------------- .../references/apis/updated-apis.md | 193 ---------------- .../references/ledger-entries/sponsorship.md | 81 ------- .../ledger-entries/updated-ledger-entries.md | 101 --------- .../references/transactions/sponsorshipset.md | 83 ------- .../transactions/sponsorshiptransfer.md | 136 ------------ .../updated-common-transaction-fields.md | 125 ----------- .../transactions/updated-transactions.md | 69 ------ .../index.page.tsx | 44 +++- docs/xls-94-dynamic-mpts/dynamic-mpts.md | 38 ---- docs/xls-94-dynamic-mpts/index.page.tsx | 18 +- docs/xls-94-dynamic-mpts/reference.md | 192 ---------------- .../concepts/confidential-transfers.md | 208 ------------------ .../index.page.tsx | 23 +- .../transactions/confidentialmptclawback.md | 64 ------ .../transactions/confidentialmptconvert.md | 71 ------ .../confidentialmptconvertback.md | 79 ------- .../transactions/confidentialmptmergeinbox.md | 53 ----- .../transactions/confidentialmptsend.md | 84 ------- .../transactions/updated-transactions.md | 68 ------ .../references/updated-ledger-entries.md | 53 ----- redirects.yaml | 64 ++++++ sidebars.yaml | 59 +---- 27 files changed, 165 insertions(+), 2135 deletions(-) delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/concepts/sponsored-fees-and-reserves.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/apis/account_sponsoring.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/apis/updated-apis.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/updated-ledger-entries.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-common-transaction-fields.md delete mode 100644 docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-transactions.md delete mode 100644 docs/xls-94-dynamic-mpts/dynamic-mpts.md delete mode 100644 docs/xls-94-dynamic-mpts/reference.md delete mode 100644 docs/xls-96-confidential-transfers/concepts/confidential-transfers.md delete mode 100644 docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback.md delete mode 100644 docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert.md delete mode 100644 docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback.md delete mode 100644 docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox.md delete mode 100644 docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend.md delete mode 100644 docs/xls-96-confidential-transfers/references/transactions/updated-transactions.md delete mode 100644 docs/xls-96-confidential-transfers/references/updated-ledger-entries.md diff --git a/docs/_snippets/common-links.md b/docs/_snippets/common-links.md index 06f199ca..1d73b2ef 100644 --- a/docs/_snippets/common-links.md +++ b/docs/_snippets/common-links.md @@ -5,11 +5,11 @@ [amendment]: https://xrpl.org/docs/concepts/networks-and-servers/amendments [common fields]: https://xrpl.org/docs/references/protocol/transactions/common-fields/ [common ledger entry fields]: https://xrpl.org/docs/references/protocol/ledger-data/common-fields/ -[ConfidentialMPTClawback transaction]: /docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback.md -[ConfidentialMPTConvert transaction]: /docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert.md -[ConfidentialMPTConvertBack transaction]: /docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback.md -[ConfidentialMPTMergeInbox transaction]: /docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox.md -[ConfidentialMPTSend transaction]: /docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend.md +[ConfidentialMPTClawback transaction]: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptclawback +[ConfidentialMPTConvert transaction]: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptconvert +[ConfidentialMPTConvertBack transaction]: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptconvertback +[ConfidentialMPTMergeInbox transaction]: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptmergeinbox +[ConfidentialMPTSend transaction]: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptsend [ConfidentialTransfers amendment]: https://xls.xrpl.org/xls/XLS-0096-confidential-mpt.html [credentials]: https://xrpl.org/docs/concepts/decentralized-storage/credentials [DynamicMPT amendment]: https://xls.xrpl.org/xls/XLS-0094-dynamic-MPT.html @@ -31,10 +31,10 @@ [SHA-512Half]: https://xrpl.org/docs/references/protocol/data-types/basic-data-types#hashes [Specifying Ledgers]: https://xrpl.org/docs/references/protocol/data-types/basic-data-types/#specifying-ledgers [Sponsor amendment]: https://xls.xrpl.org/xls/XLS-0068-sponsored-fees-and-reserves.html -[Sponsorship ledger entry]: /docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship.md -[SponsorshipSet transaction]: /docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset.md -[SponsorshipTransfer]: /docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md -[SponsorshipTransfer transaction]: /docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md +[Sponsorship ledger entry]: https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/sponsorship +[SponsorshipSet transaction]: https://xrpl.org/docs/references/protocol/transactions/types/sponsorshipset +[SponsorshipTransfer]: https://xrpl.org/docs/references/protocol/transactions/types/sponsorshiptransfer +[SponsorshipTransfer transaction]: https://xrpl.org/docs/references/protocol/transactions/types/sponsorshiptransfer [standard format]: https://xrpl.org/docs/references/http-websocket-apis/api-conventions/response-formatting/ [transaction result codes]: https://xrpl.org/docs/references/protocol/transactions/transaction-results [universal error types]: https://xrpl.org/docs/references/http-websocket-apis/api-conventions/error-formatting#universal-errors diff --git a/docs/xls-56-batch-transactions/index.page.tsx b/docs/xls-56-batch-transactions/index.page.tsx index 49e9f72e..923ce7f3 100644 --- a/docs/xls-56-batch-transactions/index.page.tsx +++ b/docs/xls-56-batch-transactions/index.page.tsx @@ -46,11 +46,9 @@ export default function Page() { keyDates={keyDates} /> - @@ -77,6 +75,17 @@ export default function Page() {

Read the Concepts + +

+ An overview of the feature and why it matters to developers, explained in our blog post. +

+ +

- The performance testing report to assess the performance implications of the feature. + The performance testing report to assess the performance implications of the feature.

- + + +

+ The QA Test Report presents results of QA testing performed on the feature across rippled and Clio servers. +

+ + + ); diff --git a/docs/xls-68-sponsored-fees-and-reserves/concepts/sponsored-fees-and-reserves.md b/docs/xls-68-sponsored-fees-and-reserves/concepts/sponsored-fees-and-reserves.md deleted file mode 100644 index 1e105f1d..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/concepts/sponsored-fees-and-reserves.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -seo: - description: Sponsors can pay transaction fees and reserve requirements on behalf of other accounts on the XRP Ledger. -labels: - - Fees - - Accounts - - Sponsorship -status: not_enabled ---- -# Sponsored Fees and Reserves - -The Sponsored Fees and Reserves feature allows an account to pay transaction fees and reserve requirements on behalf of another account. The account that pays is called the _Sponsor_, and the account that benefits is called the _Sponsee_. Sponsees maintain full control over their keys and accounts. - -{% admonition type="info" name="Note" %} -Sponsorship does not transfer XRP to the sponsee's wallet. The sponsor can cover transaction fees, and for reserve sponsorship, the ledger tracks which account is responsible for the reserve. This is not an "onramp" for the sponsee; it is a mechanism for the sponsor to cover costs on the sponsee's behalf. -{% /admonition %} - -Without sponsorship, accounts must self-fund both transaction fees and reserves before they can transact on the XRP Ledger. Sponsorship provides a mechanism for entities with established XRP balances to subsidize these costs while maintaining strong on-chain accountability. - -Sponsorship enables several important use cases, including: - -- **Token distribution**: Issuers can distribute tokens without requiring recipients to hold XRP first. -- **Enterprise onboarding**: Businesses can onboard customers seamlessly without blockchain friction. - -{% admonition type="success" name="Tip" %} -Similar features on other chains are often called "sponsored transactions", "meta-transactions", or "relays". -{% /admonition %} - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## How Sponsorship Works - -XRP Ledger accounts can be sponsored in one of two ways: **co-signing** or **pre-funding**. -Co-signing requires sponsors to sign each transaction, allowing them to pay the transaction cost and the reserve for any accounts or objects created in the transaction. Pre-funding lets sponsors allocate funds in advance to cover fees and reserves so they do not need to sign every sponsored transaction. - -For example, consider Spencer (sponsor) who wants to cover costs for Alice (sponsee): - -- **Co-signing**: Alice constructs her transaction, including Spencer's account and the sponsorship type. Both parties then sign the same transaction. This gives Spencer fine-grained control over every sponsored transaction. - -- **Pre-funding**: Spencer submits a [SponsorshipSet transaction][] to allocate funds for Alice. This can cover both transaction fees and reserves for new objects, such as trust lines, escrows, or payment channels. From then on, Alice can submit transactions that reference Spencer as her sponsor without needing his signature each time. Spencer's involvement ends after the initial setup. - -### Enabling Sponsorship and Covering Costs - -For a transaction to be sponsored, at least one of the following flags must be enabled: - -- `spfSponsorFee`: This flag indicates that the sponsor pays the transaction fee. -- `spfSponsorReserve`: This flag indicates that the sponsor covers the reserve for accounts or objects created in a transaction. No XRP is transferred to the sponsee; the sponsor's XRP stays in their own account, and the ledger simply tracks which account is responsible for holding the reserve. - -If a transaction has **both** flags enabled, the sponsor pays for the fee and any reserves for newly created accounts or objects. Additionally, a single transaction cannot have different sponsors for the fee and the reserve; both must come from the same sponsor. - -{% admonition type="info" name="Note" %} -[Pseudo-transactions](https://xrpl.org/docs/references/protocol/transactions/pseudo-transaction-types) don't support either sponsorship flag as they simply don't have fees or reserves at all. - -All other transaction types can use the `spfSponsorFee` flag, but only certain transactions are permitted to use `spfSponsorReserve`. See [Updated Common Transaction Fields](../references/transactions/updated-common-transaction-fields.md#sponsorflags) for the list of allowed transactions. -{% /admonition %} - -### Reserve Calculation - -Sponsorship modifies the reserve formula, shifting the burden from the sponsee to the sponsor. - -The standard reserve calculation is: - -```txt -acctReserve + objReserve × acct.OwnerCount -``` - -With sponsorship, the calculation becomes: - -```txt -(acct.Sponsor ? 0 : acctReserve) + -objReserve × (acct.OwnerCount + acct.SponsoringOwnerCount - acct.SponsoredOwnerCount) + -acctReserve × acct.SponsoringAccountCount -``` - -- If the account has a `Sponsor` field, meaning its account reserve is sponsored, the base account reserve requirement is 0 for that account, and the sponsor covers it instead. -- `SponsoringOwnerCount` tracks objects this account sponsors. -- `SponsoredOwnerCount` tracks objects owned by this account that are sponsored by others. -- `SponsoringAccountCount` tracks accounts this account sponsors. - -### Security Considerations - -Sponsorship includes safeguards to protect both parties from misuse: - -- **Co-signed flow**: Both parties must consent to each transaction by providing their signatures. The sponsor signs the entire transaction, including the sponsee's `Account` and `Sequence` fields, which prevents signature replay attacks. The sponsor also approves the `Fee` value and any fields that affect reserve requirements, such as `Destination`. - -- **Pre-funded flow**: The sponsor consents once when submitting a `SponsorshipSet` transaction. The sponsee cannot modify the terms or exceed the limits the sponsor set. The sponsor can limit usage with `FeeAmount`, `MaxFee`, and `RemainingOwnerCount`, or require their signature for specific transactions using the `lsfSponsorshipRequireSignForFee` or `lsfSponsorshipRequireSignForReserve` flags. - -The sponsee cannot unilaterally change the sponsorship type, and the sponsor's funds cannot be used beyond the agreed terms. Only the sponsee can transfer a sponsorship to a new sponsor, and the new sponsor must co-sign the transaction to consent. Either party can exit a sponsorship relationship at any time by submitting a [SponsorshipTransfer transaction][]. - -## Managing Sponsorships - -Over time, sponsors may want to recoup their reserves, and sponsees may want to change sponsors or take on the reserve burden themselves. The [SponsorshipTransfer transaction][] supports three operations: - -- **Create sponsorship**: Only the sponsee can create a new sponsorship. The new sponsor provides their signature via the standard signing flow. -- **Reassign sponsorship**: Only the sponsee can transfer an existing sponsorship to a new sponsor. The old sponsor is not directly involved. -- **End sponsorship**: Either the sponsor or sponsee can end a sponsorship at any time. The reserve burden returns to the object owner. - -{% admonition type="warning" name="Warning" %} -When ending account sponsorship, the sponsee must have enough XRP to cover the account reserve. If they do not, and the sponsor needs to exit the sponsorship relationship quickly, the sponsor can send XRP to the sponsee with the `Payment` transaction. However, the sponsor will **not** get their reserve back. - -These steps can be executed atomically via a [Batch transaction](https://xrpl.org/docs/concepts/transactions/batch-transactions), to ensure that the sponsee cannot use the funds for something else before the transfer is validated. -{% /admonition %} - -### Recouping Object Reserves - -A sponsor who wants to recoup the reserve held for a sponsee's object, such as an escrow or trust line, can use the [SponsorshipTransfer transaction][] to transfer the reserve burden back to the sponsee or to a different sponsor. - -### Recouping Account Reserves - -A sponsor who wants to recoup the reserve held for a sponsee's account has two options: - -- **If the sponsee is done using their account**: The sponsee can submit an [AccountDelete transaction](https://xrpl.org/docs/references/protocol/transactions/types/accountdelete). The destination, where leftover XRP goes, must be the sponsor's account. This ensures the sponsor gets their reserve back. - - {% admonition type="info" name="Note" %} - Sponsored objects owned by the sponsee, such as trust lines, escrows, checks, payment channels, and MPTokens, are [deletion blockers](https://xrpl.org/docs/concepts/accounts/deleting-accounts/#deletion-blockers) and must be removed before the account can be deleted. - {% /admonition %} - -- **If the sponsee wants to keep their account**: Use the [SponsorshipTransfer transaction][] to remove the sponsorship or transfer it to a different sponsor. - -### Deleting a Sponsor's Account - -A sponsor's account cannot be deleted if it is sponsoring any existing accounts or objects. To unblock deletion, the sponsor can ask the sponsee to delete those objects, or use a [SponsorshipTransfer transaction][] to transfer the reserve burden back to the sponsee or to another sponsor. Sponsors cannot delete sponsored objects directly. - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/index.page.tsx b/docs/xls-68-sponsored-fees-and-reserves/index.page.tsx index 6e93477d..9242790b 100644 --- a/docs/xls-68-sponsored-fees-and-reserves/index.page.tsx +++ b/docs/xls-68-sponsored-fees-and-reserves/index.page.tsx @@ -3,7 +3,8 @@ import { LandingContainer, LandingLayout, FeatureHeader, - FeatureContent + FeatureContent, + ButtonToXRPL } from "../../components/landing"; import { AmendmentTracker } from "../../components/AmendmentTracker"; import { Button } from "@redocly/theme"; @@ -67,16 +68,15 @@ export default function Page() {

- Explore key concepts, find detailed references, and follow - step-by-step tutorials. + Documentation on the feature, including how it works and why.

- + + Read the Concepts + -[[Source]](https://github.com/XRPLF/clio "Source") - -The `account_sponsoring` method returns all objects an account is currently sponsoring, where the queried account is the `Sponsor`, or for trust lines, the `HighSponsor` or `LowSponsor`. It has a very similar API to [account_objects](https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_objects). - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -{% admonition type="info" name="Note" %} -This API method is available in **Clio only**, not in `rippled`. This is because this API would require an additional database to track sponsorship relationships, which would be too expensive to maintain in `rippled`. -{% /admonition %} - -## Request Format - -An example of a request format: - -{% tabs %} - -{% tab label="WebSocket" %} -```json -{ - "id": 1, - "command": "account_sponsoring", - "account": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "ledger_index": "validated", - "limit": 10 -} -``` -{% /tab %} - -{% tab label="JSON-RPC" %} -```json -{ - "method": "account_sponsoring", - "params": [ - { - "account": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "ledger_index": "validated", - "limit": 10 - } - ] -} -``` -{% /tab %} - -{% /tabs %} - -The request includes the following parameters: - -| Field | Type | Required? | Description | -|:-------------------------|:---------------------------|:----------|:------------| -| `account` | String | Yes | The sponsor account to query. | -| `deletion_blockers_only` | Boolean | No | If `true`, the response only includes objects that would block this account from being deleted. The default is `false`. | -| `ledger_hash` | String | No | A 20-byte hex string for the ledger version to use. See [Specifying Ledgers][]. | -| `ledger_index` | String or Unsigned Integer | No | The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. See [Specifying Ledgers][]. | -| `limit` | Number | No | The maximum number of objects to include in the results. | -| `marker` | Marker | No | Value from a previous paginated response. Resume retrieving data where that response left off. | -| `type` | String | No | Filter results by a ledger entry type. Some examples are `check` and `escrow`. See [ledger entry types][] for a complete list. | - -## Response Format - -An example of a successful response: - -{% tabs %} - -{% tab label="WebSocket" %} -```json -{ - "id": 1, - "result": { - "account": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "sponsored_objects": [ - { - "Balance": { - "currency": "USD", - "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value": "100" - }, - "Flags": 65536, - "HighLimit": { - "currency": "USD", - "issuer": "rSponsee1ABC123XYZ456DEF789GHI", - "value": "1000" - }, - "HighNode": "0000000000000000", - "HighSponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "LedgerEntryType": "RippleState", - "LowLimit": { - "currency": "USD", - "issuer": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "value": "0" - }, - "LowNode": "0000000000000000", - "PreviousTxnID": "E3FE6EA3D48F0C2B639448020EA4F03D4F4F8FFDB243A852A0F59177921B4879", - "PreviousTxnLgrSeq": 14090896, - "index": "9ED4406351B7A511A012A9B5E7FE4059FA2F7650621379C0013492C315E25B97" - }, - { - "Account": "rSponsee2XYZ789ABC123DEF456GHI", - "Balance": "1000000", - "Flags": 0, - "LedgerEntryType": "AccountRoot", - "OwnerCount": 3, - "PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D", - "PreviousTxnLgrSeq": 14091574, - "Sequence": 1, - "Sponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8" - } - ], - "ledger_hash": "4C99E5F63C0D0B1C2283D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3", - "ledger_index": 14091625, - "validated": true - }, - "status": "success", - "type": "response" -} -``` -{% /tab %} - -{% tab label="JSON-RPC" %} -```json -{ - "result": { - "account": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "sponsored_objects": [ - { - "Balance": { - "currency": "USD", - "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value": "100" - }, - "Flags": 65536, - "HighLimit": { - "currency": "USD", - "issuer": "rSponsee1ABC123XYZ456DEF789GHI", - "value": "1000" - }, - "HighNode": "0000000000000000", - "HighSponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "LedgerEntryType": "RippleState", - "LowLimit": { - "currency": "USD", - "issuer": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "value": "0" - }, - "LowNode": "0000000000000000", - "PreviousTxnID": "E3FE6EA3D48F0C2B639448020EA4F03D4F4F8FFDB243A852A0F59177921B4879", - "PreviousTxnLgrSeq": 14090896, - "index": "9ED4406351B7A511A012A9B5E7FE4059FA2F7650621379C0013492C315E25B97" - }, - { - "Account": "rSponsee2XYZ789ABC123DEF456GHI", - "Balance": "1000000", - "Flags": 0, - "LedgerEntryType": "AccountRoot", - "OwnerCount": 3, - "PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D", - "PreviousTxnLgrSeq": 14091574, - "Sequence": 1, - "Sponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8" - } - ], - "ledger_hash": "4C99E5F63C0D0B1C2283D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3D3", - "ledger_index": 14091625, - "validated": true, - "status": "success" - } -} -``` -{% /tab %} - -{% /tabs %} - -The response follows the [standard format][], with a successful result containing the following fields: - -| Field | Type | Description | -|:-----------------------|:--------|:------------| -| `account` | String | The account this request corresponds to. | -| `sponsored_objects` | Array | Array of ledger entries that this account is sponsoring. Includes objects owned by this account and objects owned by others, such as escrows where this account is the destination. Each member is a ledger entry in its raw ledger format. This may contain fewer entries than the maximum specified in the `limit` field. | -| `ledger_hash` | String | _(May be omitted)_ The identifying hash of the ledger that was used to generate this response. | -| `ledger_index` | Number | _(May be omitted)_ The ledger index of the ledger that was used to generate this response. | -| `ledger_current_index` | Number | _(May be omitted)_ The ledger index of the current in-progress ledger, which was used when retrieving this data. | -| `limit` | Number | _(May be omitted)_ The limit that was used in this request, if any. | -| `marker` | Marker | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. | -| `validated` | Boolean | _(May be omitted)_ If `true`, the information in this response comes from a validated ledger version. Otherwise, the information is subject to change. | - -## Possible Errors - -- Any of the [universal error types][]. -- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. -- `actNotFound` - The address specified in the `account` field of the request does not correspond to an account in the ledger. -- `lgrNotFound` - The ledger specified by the `ledger_hash` or `ledger_index` does not exist, or it does exist but the server does not have it. - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/apis/updated-apis.md b/docs/xls-68-sponsored-fees-and-reserves/references/apis/updated-apis.md deleted file mode 100644 index cdeda187..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/apis/updated-apis.md +++ /dev/null @@ -1,193 +0,0 @@ -# Updated APIs - -This page describes updates to existing RPC methods introduced by XLS-68: Sponsored Fees and Reserves. - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## account_objects - -The [account_objects method](https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_objects) adds a new optional filter parameter to query sponsored objects. - -| Field | Type | Required? | Description | -|:------------|:--------|:----------|:------------| -| `sponsored` | Boolean | No | If `true`, returns only sponsored objects (objects with a `Sponsor`, `HighSponsor`, or `LowSponsor` field). If `false`, returns only non-sponsored objects. If omitted, returns all objects (existing behavior). | - -### Request Format - -An example of the request format: - -{% tabs %} - -{% tab label="WebSocket" %} -```json -{ - "id": 1, - "command": "account_objects", - "account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "sponsored": true, - "ledger_index": "validated", - "type": "state" -} -``` -{% /tab %} - -{% tab label="JSON-RPC" %} -```json -{ - "method": "account_objects", - "params": [ - { - "account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "sponsored": true, - "ledger_index": "validated", - "type": "state" - } - ] -} -``` -{% /tab %} - -{% /tabs %} - -### Response Format - -An example of a successful response: - -{% tabs %} - -{% tab label="WebSocket" %} -```json -{ - "id": 1, - "result": { - "account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "account_objects": [ - { - "Balance": { - "currency": "USD", - "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value": "100" - }, - "Flags": 65536, - "HighLimit": { - "currency": "USD", - "issuer": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "value": "1000" - }, - "HighNode": "0000000000000000", - "HighSponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "LedgerEntryType": "RippleState", - "LowLimit": { - "currency": "USD", - "issuer": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", - "value": "0" - }, - "LowNode": "0000000000000000", - "PreviousTxnID": "1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF", - "PreviousTxnLgrSeq": 12345678, - "index": "ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890" - } - ], - "ledger_hash": "FEDCBA0987654321FEDCBA0987654321FEDCBA0987654321FEDCBA0987654321", - "ledger_index": 56789012, - "validated": true - }, - "status": "success", - "type": "response" -} -``` -{% /tab %} - -{% tab label="JSON-RPC" %} -```json -{ - "result": { - "account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "account_objects": [ - { - "Balance": { - "currency": "USD", - "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value": "100" - }, - "Flags": 65536, - "HighLimit": { - "currency": "USD", - "issuer": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "value": "1000" - }, - "HighNode": "0000000000000000", - "HighSponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "LedgerEntryType": "RippleState", - "LowLimit": { - "currency": "USD", - "issuer": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", - "value": "0" - }, - "LowNode": "0000000000000000", - "PreviousTxnID": "1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF", - "PreviousTxnLgrSeq": 12345678, - "index": "ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890" - } - ], - "ledger_hash": "FEDCBA0987654321FEDCBA0987654321FEDCBA0987654321FEDCBA0987654321", - "ledger_index": 56789012, - "validated": true, - "status": "success" - } -} -``` -{% /tab %} - -{% /tabs %} - -## ledger_entry - -The [ledger_entry method](https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_entry) adds a new `sponsorship` field to retrieve a [Sponsorship ledger entry][] directly. - -| Field | Type | Required? | Description | -|:----------------------|:---------------------|:----------|:------------| -| `sponsorship` | Object or String | Yes | Retrieve a [Sponsorship ledger entry][]. If a string, must be the [ledger entry ID][] of the entry as hexadecimal. If an object, requires the `sponsor` and `sponsee` sub-fields. | -| `sponsorship.sponsor` | String - [Address][] | No | The address of the sponsor account. | -| `sponsorship.sponsee` | String - [Address][] | No | The address of the sponsee account. | - -### Request Format - -An example of the request format: - -{% tabs %} - -{% tab label="WebSocket" %} -```json -{ - "id": 1, - "command": "ledger_entry", - "sponsorship": { - "sponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "sponsee": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf" - }, - "ledger_index": "validated" -} -``` -{% /tab %} - -{% tab label="JSON-RPC" %} -```json -{ - "method": "ledger_entry", - "params": [ - { - "sponsorship": { - "sponsor": "rSponsor1VktvzBz8JF2oJC6qaww6RZ7Lw", - "sponsee": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf" - }, - "ledger_index": "validated" - } - ] -} -``` -{% /tab %} - -{% /tabs %} - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship.md b/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship.md deleted file mode 100644 index eb6bb491..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -seo: - description: A Sponsorship ledger entry represents a sponsoring relationship between two accounts. -labels: - - Fees - - Accounts - - Sponsorship -status: not_enabled ---- -# Sponsorship - -[[Source]](https://github.com/XRPLF/rippled/blob/develop/include/xrpl/protocol/detail/ledger_entries.macro#L627-L637 "Source") - -A {% code-page-name /%} ledger entry represents a sponsoring relationship between a sponsor and a sponsee. This allows sponsors to _pre-fund_ sponsees, if they so desire. - -{% admonition type="info" name="Note" %} -This ledger entry does not need to be created in order to sponsor accounts. It is an offered convenience, so that sponsors do not have to co-sign every sponsored transaction if they don't want to, especially for transaction fees. It also allows sponsors to set a maximum balance even if they still want to co-sign transactions. -{% /admonition %} - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## Example JSON - -```json -{ - "LedgerEntryType": "Sponsorship", - "Flags": 0, - "Owner": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "Sponsee": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", - "FeeAmount": "1000000", - "MaxFee": "1000", - "RemainingOwnerCount": 5, - "OwnerNode": "0000000000000000", - "SponseeNode": "0000000000000000", - "PreviousTxnID": "1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF", - "PreviousTxnLgrSeq": 12345678 -} -``` - -## {% $frontmatter.seo.title %} Fields - -In addition to the [common ledger entry fields](./updated-ledger-entries.md#common-ledger-entry-updates), a {% code-page-name /%} entry has the following fields: - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :------------------ | :-------- | :---------------- | :-------- | :---------- | -| `FeeAmount` | String | Amount | No | The remaining amount of XRP that the sponsor has provided for the sponsee to use for transaction fees. | -| `MaxFee` | String | Amount | No | The maximum fee per transaction that the sponsor will cover. This field helps prevent excessive draining of the pre-funded fee pool. If the sponsee submits a transaction with a fee exceeding this value, the transaction fails. | -| `Owner` | String | AccountID | Yes | The address of the sponsor account. This account pays the reserve for this entry. | -| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the sponsor's owner directory links to this entry, in case the directory consists of multiple pages. | -| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this entry. | -| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [ledger index](https://xrpl.org/docs/references/protocol/data-types/basic-data-types#ledger-index) of the ledger that contains the transaction that most recently modified this entry. | -| `RemainingOwnerCount` | Number | UInt32 | No | The remaining number of owner reserves the sponsor has pre-funded for the sponsee. | -| `Sponsee` | String | AccountID | Yes | The address of the sponsee account associated with this relationship. | -| `SponseeNode` | String | UInt64 | Yes | A hint indicating which page of the sponsee's owner directory links to this entry, in case the directory consists of multiple pages. | - -## {% $frontmatter.seo.title %} Flags - -A {% code-page-name /%} entry can have the following flags: - -| Flag Name | Flag Value | Description | -| :------------------------------------ | :----------- | :---------- | -| `lsfSponsorshipRequireSignForFee` | `0x00010000` | If enabled, every transaction that uses this sponsorship for fees requires a signature from the sponsor. If disabled, no signature is necessary, as the existence of the {% code-page-name /%} ledger entry is sufficient. | -| `lsfSponsorshipRequireSignForReserve` | `0x00020000` | If enabled, every transaction that uses this sponsorship for reserves requires a signature from the sponsor. If disabled, no signature is necessary, as the existence of the {% code-page-name /%} ledger entry is sufficient. | - -## Deleting a Sponsorship Ledger Entry - -Either the sponsor or the sponsee can delete a {% code-page-name /%} ledger entry using the [SponsorshipSet transaction][] with the `tfDeleteObject` flag enabled. - -{% admonition type="warning" name="Warning" %} -The {% code-page-name /%} ledger entry is a [deletion blocker](https://xrpl.org/docs/concepts/accounts/deleting-accounts#requirements) for both parties. Because the entry appears in both the sponsor's and the sponsee's owner directories, neither the sponsor nor the sponsee can delete their account until the ledger entry is removed. -{% /admonition %} - -## Sponsorship ID Format - -The ID of a {% code-page-name /%} entry is the [SHA-512Half](https://xrpl.org/docs/references/protocol/data-types/basic-data-types#hashes) of the following values, concatenated in order: - -1. The Sponsorship space key (`0x003E`) -2. The AccountID of the sponsor (`Owner` field) -3. The AccountID of the `Sponsee` - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/updated-ledger-entries.md b/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/updated-ledger-entries.md deleted file mode 100644 index c2ea34ef..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/updated-ledger-entries.md +++ /dev/null @@ -1,101 +0,0 @@ -# Updated Ledger Entries - -This page describes changes to existing ledger entry types for Sponsored Fees and Reserves. - -## Common Ledger Entry Updates - -A new `Sponsor` field is added to the [common ledger entry fields](https://xrpl.org/docs/references/protocol/ledger-data/common-fields): - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :--------- | :-------- | :---------------- | :-------- | :---------- | -| `Sponsor` | String | AccountID | No | The sponsor paying the owner reserve for this ledger object. When present, this indicates that the reserve burden for this object has shifted from the owner to the sponsor. | - -The `Sponsor` field may appear on the following ledger entry types: - -- `AccountRoot` -- `Check` -- `Credential` -- `Delegate` -- `DepositPreauth` -- `Escrow` -- `MPToken` -- `MPTokenIssuance` -- `PayChannel` -- `SignerList` - -`RippleState` entries also support sponsorship, but use the `HighSponsor` and `LowSponsor` fields instead of `Sponsor`. See [RippleState Updates](#ripplestate-updates). - -## AccountRoot Updates - -### Example JSON - -```json -{ - "LedgerEntryType": "AccountRoot", - "Account": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", - "Balance": "100000000", // 100 XRP in drops - "OwnerCount": 5, - "Sponsor": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "SponsoredOwnerCount": 2, - "SponsoringOwnerCount": 1, - "SponsoringAccountCount": 1, - "PreviousTxnID": "1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF", - "PreviousTxnLgrSeq": 12345679 -} -``` - -### AccountRoot Fields - -[AccountRoot ledger entries](https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/accountroot) can include the following new fields: - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :----------------------- | :-------- | :---------------- | :-------- | :---------- | -| `Sponsor` | String | AccountID | No | The sponsor paying the account reserve for this account. | -| `SponsoredOwnerCount` | Number | UInt32 | No | The number of objects this account owns that are sponsored by another account. | -| `SponsoringOwnerCount` | Number | UInt32 | No | The number of objects this account is sponsoring the reserve for. | -| `SponsoringAccountCount` | Number | UInt32 | No | The number of accounts this account is sponsoring the account reserve for. | - -## RippleState Updates - -### Example JSON - -```json -{ - "LedgerEntryType": "RippleState", - "Balance": { - "currency": "USD", - "issuer": "rLowAccountAddressXXXXXXXXXXXXXXX", - "value": "-10" - }, - "HighLimit": { - "currency": "USD", - "issuer": "rHighAccountAddressXXXXXXXXXXXXXX", - "value": "100" - }, - "LowLimit": { - "currency": "USD", - "issuer": "rLowAccountAddressXXXXXXXXXXXXXXX", - "value": "0" - }, - "HighSponsor": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "LowSponsor": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "Flags": 262144, - "HighNode": "0000000000000000", - "LowNode": "0000000000000000", - "PreviousTxnID": "ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789", - "PreviousTxnLgrSeq": 12345680 -} -``` - -### RippleState Fields - -[RippleState ledger entries](https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/ripplestate) can include the following new fields: - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :------------ | :-------- | :---------------- | :-------- | :---------- | -| `HighSponsor` | String | AccountID | No | The sponsor paying the reserve on behalf of the _high account_ on the trust line. | -| `LowSponsor` | String | AccountID | No | The sponsor paying the reserve on behalf of the _low account_ on the trust line. | - -The `HighSponsor` and `LowSponsor` fields exist because bidirectional trust lines may have the reserve held by two accounts. - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset.md b/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset.md deleted file mode 100644 index 0a76b0b1..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -seo: - description: Create, update, or delete a Sponsorship ledger entry on the XRP Ledger. -labels: - - Fees - - Accounts - - Sponsorship -status: not_enabled ---- -# SponsorshipSet - -[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/libxrpl/tx/transactors/sponsor/SponsorshipSet.cpp "Source") - -Create, update, or delete a [Sponsorship ledger entry][] on the XRP Ledger. - -{% admonition type="warning" name="Warning" %} -This transaction requires that you specify either the **CounterpartySponsor** or **Sponsee**, but not both. -{% /admonition %} - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## Example JSON - -```json -{ - "TransactionType": "SponsorshipSet", - "Account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "Sponsee": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", - "FeeAmount": "1000000", - "MaxFee": "1000", - "RemainingOwnerCount": 5, - "Fee": "12", - "Sequence": 42 -} -``` - -## {% $frontmatter.seo.title %} Fields - -In addition to the [common fields](./updated-common-transaction-fields.md#new-common-fields), {% code-page-name /%} transactions use the following fields: - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :-------------------- | :-------- | :---------------- | :-------- | :---------- | -| `CounterpartySponsor` | String | AccountID | No | The sponsor associated with this relationship. This account also pays for the reserve of this entry. If this field is included, the `Account` is assumed to be the sponsee. | -| `FeeAmount` | String | Amount | No | The remaining amount of XRP that the sponsor has provided for the sponsee to use for fees. This value replaces what is currently in the `Sponsorship.FeeAmount` field, if it exists, rather than adding to it. Raising `FeeAmount` deducts the additional XRP from the sponsor, while lowering it refunds the difference back to the sponsor. | -| `MaxFee` | String | Amount | No | The maximum fee per transaction that will be sponsored. This prevents abuse or excessive draining of the sponsored fee pool. | -| `RemainingOwnerCount` | Number | UInt32 | No | The remaining amount of reserves that the sponsor has provided for the sponsee to use. This value replaces what is currently in the `Sponsorship.RemainingOwnerCount` field, if it exists. | -| `Sponsee` | String | AccountID | No | The sponsee associated with this relationship. If this field is included, the `Account` is assumed to be the sponsor. | - -A sponsorship entry must keep at least some fee budget (`FeeAmount`) or reserve budget (`RemainingOwnerCount`). If you try to create or update the entry with neither, the transaction fails, because an empty entry still consumes an owner reserve while giving the sponsee nothing to draw on. - -## {% $frontmatter.seo.title %} Flags - -{% code-page-name /%} transactions support additional values in the `Flags` field, as follows: - -| Flag Name | Hex Value | Decimal Value | Description | -| :------------------------------------------ | :----------- | :------------ | :---------- | -| `tfSponsorshipSetRequireSignForFee` | `0x00010000` | 65536 | Adds the restriction that every use of this sponsor for sponsoring fees requires a signature from the sponsor. | -| `tfSponsorshipClearRequireSignForFee` | `0x00020000` | 131072 | Removes the restriction that every use of this sponsor for sponsoring fees requires a signature from the sponsor. | -| `tfSponsorshipSetRequireSignForReserve` | `0x00040000` | 262144 | Adds the restriction that every use of this sponsor for sponsoring reserves requires a signature from the sponsor. | -| `tfSponsorshipClearRequireSignForReserve` | `0x00080000` | 524288 | Removes the restriction that every use of this sponsor for sponsoring reserves requires a signature from the sponsor. | -| `tfDeleteObject` | `0x00100000` | 1048576 | Deletes the `Sponsorship` ledger entry. When enabled, no other fields (except `Sponsee` and `CounterpartySponsor`) or flag-setting fields may be specified. Deleting returns any remaining XRP in `FeeAmount` to the sponsor's account. | - -## Deleting a Sponsorship Ledger Entry - -To delete a `Sponsorship` ledger entry, the sponsor or sponsee submits a {% code-page-name /%} transaction with the `tfDeleteObject` flag enabled. Any remaining XRP in `FeeAmount` is returned to the sponsor's account upon deletion. - -Deleting the `Sponsorship` entry only removes the pre-funded fee and reserve arrangement between the sponsor and sponsee. Ledger entries that were previously created using sponsored reserves retain their `Sponsor` field and remain sponsored. To transfer or dissolve sponsorship for those existing ledger entries, use the [SponsorshipTransfer transaction][]. - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](https://xrpl.org/docs/references/protocol/transactions/transaction-results): - -| Error Code | Description | -| :---------------- | :---------- | -| `tecNO_DST` | The sponsor or sponsee account does not exist on the ledger. | -| `tecNO_ENTRY` | The `tfDeleteObject` flag is enabled but the `Sponsorship` ledger entry does not exist. | -| `tecNO_PERMISSION` | The transaction is not permitted. This can occur when:
  • Creating or updating the entry would leave it with no budget (neither a positive `FeeAmount` nor a positive `RemainingOwnerCount`). Empty `Sponsorship` ledger entries are not allowed.
  • The sponsor or sponsee is a pseudo-account, which cannot participate in sponsorship.
| -| `tecUNFUNDED` | The sponsor does not have sufficient XRP to fund the `FeeAmount` or to cover the reserve for the `Sponsorship` ledger entry. | -| `temBAD_AMOUNT` | An amount field is invalid. This can occur when:
  • `FeeAmount` is negative or not denominated in XRP.
  • `MaxFee` is negative or not denominated in XRP.
| -| `temINVALID_FLAG` | The transaction has invalid flags. This can occur when:
  • Conflicting flags are enabled, such as both `tfSponsorshipSetRequireSignForFee` and `tfSponsorshipClearRequireSignForFee`.
  • The `tfDeleteObject` flag is enabled along with additional flags. `tfDeleteObject` must be the only flag.
| -| `temMALFORMED` | The transaction is malformed. This can occur when:
  • The `Account` is not equal to either the sponsor or sponsee.
  • Both `CounterpartySponsor` and `Sponsee` are specified.
  • Neither `CounterpartySponsor` nor `Sponsee` is specified.
  • The sponsee attempts to create or update the entry. Only the sponsor can create or update.
  • The `tfDeleteObject` flag is enabled and `FeeAmount`, `MaxFee`, or `RemainingOwnerCount` is specified.
  • The sponsor and sponsee are the same account.
| - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md b/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md deleted file mode 100644 index 5ea282a3..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -seo: - description: Create, transfer, or end reserve sponsorship for a ledger object or account. -labels: - - Fees - - Accounts - - Sponsorship -status: not_enabled ---- -# SponsorshipTransfer - -[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/libxrpl/tx/transactors/sponsor/SponsorshipTransfer.cpp "Source") - -Create, transfer, or end reserve sponsorship for a ledger object or account. The transaction can be submitted by the sponsor or sponsee, depending on the required operation. See [Sponsorship Scenarios](#sponsorship-scenarios) for details on each operation. - -{% admonition type="warning" name="Warning" %} -This transaction cannot be [delegated](https://xrpl.org/docs/concepts/accounts/permission-delegation) to another account. -{% /admonition %} - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## Example JSON - -```json -{ - "TransactionType": "SponsorshipTransfer", - "Account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", - "ObjectID": "1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF", - "Sponsor": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", - "SponsorFlags": 2, // spfSponsorReserve - "Flags": 131072, // tfSponsorshipCreate - "Fee": "12", - "Sequence": 43 -} -``` - -## {% $frontmatter.seo.title %} Fields - -In addition to the [common fields](./updated-common-transaction-fields.md#new-common-fields), {% code-page-name /%} transactions use the following fields: - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :--------- | :-------- | :---------------- | :-------- | :---------- | -| `ObjectID` | String | Hash256 | No | The ID of the ledger object to transfer sponsorship. Required if the transaction is dealing with a sponsored object, rather than a sponsored account. If omitted, the transaction refers to the `Account` sending the transaction. | -| `Sponsee` | String | AccountID | No | The wallet address of the sponsee account. Required if the sponsor is ending a sponsorship on behalf of a sponsee. If omitted, the `Account` field is assumed to be the sponsee. | - -{% admonition type="info" name="Note" %} -Which of these fields you must include, and whether they are required, depends on the operation. See [Sponsorship Scenarios](#sponsorship-scenarios) for the exact fields each operation needs. -{% /admonition %} - -## {% $frontmatter.seo.title %} Flags - -{% code-page-name /%} transactions support additional values in the `Flags` field, as follows: - -| Flag Name | Hex Value | Decimal Value | Description | -| :---------------------- | :----------- | :------------ | :---------- | -| `tfSponsorshipEnd` | `0x00010000` | 65536 | End an existing sponsorship. The reserve burden returns to the object's owner. | -| `tfSponsorshipCreate` | `0x00020000` | 131072 | Create a new sponsorship for an unsponsored object or account. | -| `tfSponsorshipReassign` | `0x00040000` | 262144 | Transfer an existing sponsorship to a new sponsor. | - -## Sponsorship Scenarios - -A {% code-page-name /%} transaction performs one of three operations: **create**, **reassign**, or **end** a sponsorship. Each is selected by its own flag (`tfSponsorshipCreate`, `tfSponsorshipReassign`, or `tfSponsorshipEnd`), and the fields you include and who can submit the transaction differ for each. - -The tabs below describe the requirements for each operation. - -{% tabs %} - -{% tab label="Create Sponsorship" %} -Use the `tfSponsorshipCreate` flag to sponsor an object or account that isn't currently sponsored. Only the sponsee can submit the transaction with this configuration. The reserve sponsorship transfers to the account specified in the `Sponsor` field. - -To submit a transaction for this scenario: - -- Include the `ObjectID` field when sponsoring an object. Omit when sponsoring an account. -- The target object must be a [ledger entry type that supports sponsorship](../ledger-entries/updated-ledger-entries.md#common-ledger-entry-updates). Sponsoring any other object type fails with `tecNO_PERMISSION`. -- The target object or account must not currently be sponsored. -- Provide the `Sponsor` field and the `SponsorFlags.spfSponsorReserve` flag. -- Include the `SponsorSignature` when sponsoring an account. This is optional when sponsoring an object. -- Do not include the `Sponsee` field. - -When successful: - -- The `Sponsor` field is set on the object or account. -- The new sponsor's `SponsoringOwnerCount` or `SponsoringAccountCount` is incremented. -- For objects, the owner's `SponsoredOwnerCount` is also incremented. -{% /tab %} - -{% tab label="Reassign Sponsorship" %} -Use the `tfSponsorshipReassign` flag to transfer an existing sponsorship to a new sponsor specified in the `Sponsor` field. Only the sponsee can submit the transaction with this configuration. - -To submit a transaction for this scenario: - -- Include the `ObjectID` field when reassigning sponsorship of an object. Omit when reassigning sponsorship of an account. -- The target object or account must currently be sponsored. -- Provide the `Sponsor` field with the `SponsorFlags.spfSponsorReserve` flag. -- Include the `SponsorSignature` when sponsoring an account. This is optional when sponsoring an object. -- Do not include the `Sponsee` field. - -When successful: - -- The `Sponsor` field is updated to the new sponsor. -- The old sponsor's `SponsoringOwnerCount` or `SponsoringAccountCount` is decremented. -- The new sponsor's `SponsoringOwnerCount` or `SponsoringAccountCount` is incremented. -{% /tab %} - -{% tab label="End Sponsorship" %} -Use the `tfSponsorshipEnd` flag to dissolve an existing sponsorship. Either the sponsor or the sponsee can submit the transaction with this configuration. The reserve burden returns to the object or account owner. - -To submit a transaction for this scenario: - -- Provide the `ObjectID` when ending sponsorship for an object. Omit when ending sponsorship for an account. -- The target object or account must currently be sponsored. -- Do not include the `Sponsor` and `SponsorFlags` fields. - -When successful: - -- The `Sponsor` field is removed from the object or account. -- The old sponsor's `SponsoringOwnerCount` or `SponsoringAccountCount` is decremented. -- For objects, the owner's `SponsoredOwnerCount` is also decremented. -{% /tab %} - -{% /tabs %} - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes](https://xrpl.org/docs/references/protocol/transactions/transaction-results): - -| Error Code | Description | -| :------------------------ | :---------- | -| `tecINSUFFICIENT_RESERVE` | The owner or new sponsor does not have sufficient XRP to cover the reserve for this object or account. | -| `tecNO_ENTRY` | The `ObjectID` is specified but does not exist on the ledger. | -| `tecNO_PERMISSION` | The transaction lacks the required permissions. This can occur when:
  • The object is a ledger entry type that does not support sponsorship.
  • The submitter is not the current sponsor or owner when ending a sponsorship.
  • The submitter is not the owner when creating or reassigning a sponsorship.
  • The object or account is already sponsored when creating a sponsorship.
  • The object or account is not sponsored when reassigning or ending a sponsorship.
| -| `temINVALID_FLAG` | The transaction has invalid flags. This can occur when:
  • The transaction does not have exactly one of `tfSponsorshipCreate`, `tfSponsorshipReassign`, or `tfSponsorshipEnd` set.
  • The `spfSponsorReserve` flag is missing when creating or reassigning a sponsorship.
  • The `SponsorFlags` field is present when ending a sponsorship.
| -| `temMALFORMED` | The transaction is malformed. This can occur when:
  • The `Sponsor` field is missing when creating or reassigning a sponsorship.
  • The `Sponsor` field is present when ending a sponsorship.
  • The `Sponsee` field is present when creating or reassigning a sponsorship.
  • The `Sponsee` field is the same as the `Account` field.
  • Sponsoring an account without providing the `SponsorSignature` field.
| -| `terNO_ACCOUNT` | The `Sponsee` field is specified when ending a sponsorship, but that account does not exist on the ledger. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-common-transaction-fields.md b/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-common-transaction-fields.md deleted file mode 100644 index 377386ca..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-common-transaction-fields.md +++ /dev/null @@ -1,125 +0,0 @@ -# Updated Common Transaction Fields - -This page describes the new fields and flags added to all transactions to support Sponsored Fees and Reserves. These fields extend the existing [common transaction fields](https://xrpl.org/docs/references/protocol/transactions/common-fields). - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## New Common Fields - -The following fields are added to the common transaction fields: - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :-------------------------------------- | :-------- | :---------------- | :-------- | :----------- | -| `Sponsor` | String | AccountID | No | The address of the sponsoring account. | -| [`SponsorFlags`](#sponsorflags) | Number | UInt32 | No | Flags indicating the type of sponsorship. If included, at least one flag must be set. | -| [`SponsorSignature`](#sponsorsignature) | Object | Object | No | Contains the signing information for the sponsorship. | - -### SponsorFlags - -The `SponsorFlags` field allows the user to specify which sponsorship type(s) they wish to participate in. - -| Flag Name | Hex Value | Decimal Value | Description | -| :------------------ | :----------- | :------------ | :---------- | -| `spfSponsorFee` | `0x00000001` | 1 | Sponsoring the fee of the transaction. | -| `spfSponsorReserve` | `0x00000002` | 2 | Sponsoring the reserve for any objects created in the transaction. | - -{% admonition type="info" name="Note" %} -Both flags can be used together in a single transaction. At least one flag must be set if the `Sponsor` field is included. -{% /admonition %} - -[Pseudo-transactions](https://xrpl.org/docs/references/protocol/transactions/pseudo-transaction-types) do not support either sponsorship flag as they simply don't have fees or reserves at all. For all other transactions: - -- The **`spfSponsorFee`** flag can be used with any transaction type. -- The **`spfSponsorReserve`** flag can only be used with the following transactions: - - [AccountSet](https://xrpl.org/docs/references/protocol/transactions/types/accountset) - - [CheckCancel](https://xrpl.org/docs/references/protocol/transactions/types/checkcancel) - - [CheckCash](https://xrpl.org/docs/references/protocol/transactions/types/checkcash) - - [CheckCreate](https://xrpl.org/docs/references/protocol/transactions/types/checkcreate) - - [Clawback](https://xrpl.org/docs/references/protocol/transactions/types/clawback) - - [CredentialAccept](https://xrpl.org/docs/references/protocol/transactions/types/credentialaccept) - - [CredentialCreate](https://xrpl.org/docs/references/protocol/transactions/types/credentialcreate) - - [CredentialDelete](https://xrpl.org/docs/references/protocol/transactions/types/credentialdelete) - - [DelegateSet](https://xrpl.org/docs/references/protocol/transactions/types/delegateset) - - [DepositPreauth](https://xrpl.org/docs/references/protocol/transactions/types/depositpreauth) - - [EscrowCancel](https://xrpl.org/docs/references/protocol/transactions/types/escrowcancel) - - [EscrowCreate](https://xrpl.org/docs/references/protocol/transactions/types/escrowcreate) - - [EscrowFinish](https://xrpl.org/docs/references/protocol/transactions/types/escrowfinish) - - [MPTokenAuthorize](https://xrpl.org/docs/references/protocol/transactions/types/mptokenauthorize) - - [MPTokenIssuanceCreate](https://xrpl.org/docs/references/protocol/transactions/types/mptokenissuancecreate) - - [MPTokenIssuanceDestroy](https://xrpl.org/docs/references/protocol/transactions/types/mptokenissuancedestroy) - - [MPTokenIssuanceSet](https://xrpl.org/docs/references/protocol/transactions/types/mptokenissuanceset) - - [Payment](https://xrpl.org/docs/references/protocol/transactions/types/payment) - - [PaymentChannelClaim](https://xrpl.org/docs/references/protocol/transactions/types/paymentchannelclaim) - - [PaymentChannelCreate](https://xrpl.org/docs/references/protocol/transactions/types/paymentchannelcreate) - - [PaymentChannelFund](https://xrpl.org/docs/references/protocol/transactions/types/paymentchannelfund) - - [SetRegularKey](https://xrpl.org/docs/references/protocol/transactions/types/setregularkey) - - [SignerListSet](https://xrpl.org/docs/references/protocol/transactions/types/signerlistset) - - [SponsorshipTransfer](./sponsorshiptransfer.md) - - [TrustSet](https://xrpl.org/docs/references/protocol/transactions/types/trustset) - -{% admonition type="info" name="Note" %} -Fee-sponsored transactions cannot be queued. If a fee-sponsored transaction does not make it into the open ledger, it fails with `telCAN_NOT_QUEUE` instead of entering the transaction queue. -{% /admonition %} - -### SponsorSignature - -The `SponsorSignature` field is an object containing the sponsor's signing information. - -| Field Name | JSON Type | [Internal Type][] | Required? | Description | -| :-------------- | :-------- | :---------------- | :-------- | :----------- | -| `SigningPubKey` | String | Blob | No | The `SigningPubKey` for the `Sponsor`, if single-signing. | -| `TxnSignature` | String | Blob | No | A signature of the transaction from the sponsor, to indicate their approval of this transaction, if single-signing. | -| `Signers` | Array | Array | No | An array of signatures of the transaction from the sponsor's signers to indicate their approval of this transaction, if the sponsor is [multi-signing](https://xrpl.org/multi-signing.html). | - -These fields are not included in transaction signatures, though they are still included in the stored transaction. There is no additional transaction fee for using `TxnSignature`. - -{% admonition type="info" name="Note" %} -A sponsor signature is only required if no pre-funded `Sponsorship` ledger entry exists, or if the `lsfSponsorshipRequireSignForFee` or `lsfSponsorshipRequireSignForReserve` flags are enabled on the [Sponsorship ledger entry][]. -{% /admonition %} - -#### Transaction Fee Calculation - -If the `SponsorSignature.Signers` field is necessary, the total fee of the transaction will be increased due to the extra signatures that need to be processed. This is similar to the additional fees for multi-signing. - -The total fee calculation for signatures is: - -```text -(1 + |tx.Signers| + |tx.SponsorSignature.Signers|) × base_fee (+ any transaction-specific fees) -``` - -## Batch Transactions - -The `SponsorFlags` apply at opposite levels of a Batch. Reserve sponsorship goes on the _inner_ transactions, because the outer Batch doesn't support `spfSponsorReserve`. Fee sponsorship works the other way, so `spfSponsorFee` is valid **only** on the _outer_ Batch, not on the inner transactions. - -When a reserve sponsor co-signs an inner transaction, that transaction's `SponsorSignature` field must be present but **empty**. The sponsor signs the outer Batch transaction instead and appears as a `BatchSigners` entry. - -## Delegated Transactions - -For transactions that include a `Delegate` field, note the following: - -- Fee sponsorship applies to the delegate, since the delegate pays the transaction fee. -- When using pre-funded fee sponsorship, the _delegate_ must be the sponsee instead of the account sending the transaction. -- Reserve sponsorship cannot be combined with delegation and fails with `temINVALID`. - -## Error Cases - - -The following failure conditions have been added to transactions using the sponsorship fields: - -| Error Code | Description | -| :------------------------ | :---------- | -| `temDISABLED` | The Sponsor amendment is not enabled. | -| `temMALFORMED` | The transaction is malformed. This can occur when:
  • The sponsor and the transaction sender are the same account.
  • The transaction includes a sponsor signature but does not specify a sponsor.
  • The sponsor signature contains an invalid combination of signing fields.
| -| `temINVALID` | The transaction has an invalid sponsor configuration. This can occur when:
  • The sponsor signature is invalid.
  • The transaction combines the `spfSponsorReserve` flag with a `Delegate` field. Reserve sponsorship cannot be combined with delegation.
| -| `temINVALID_FLAG` | The transaction has invalid flags. This can occur when:
  • The `SponsorFlags` field contains invalid flags. Valid flags are `spfSponsorFee` and `spfSponsorReserve`.
  • The transaction includes `SponsorFlags` but does not specify a sponsor.
  • The `SponsorFlags` field is included but set to zero.
  • The `spfSponsorReserve` flag is set on a transaction type that does not support reserve sponsorship.
| -| `terNO_ACCOUNT` | The sponsor account does not exist. | -| `tefBAD_AUTH` | The sponsor signature is invalid. The public key does not match the sponsor account's master key or regular key, or the key type is unknown. | -| `tefNOT_MULTI_SIGNING` | The sponsor account does not have a signer list. | -| `tefBAD_SIGNATURE` | The sponsor multi-signature is invalid. A signer is not in the signer list, a public key is invalid, or a signature is invalid. | -| `tefBAD_QUORUM` | The sponsor multi-signature does not meet the required quorum. | -| `terNO_PERMISSION` | The transaction does not meet the sponsorship requirements. This can occur when:
  • The transaction requires a sponsor signature, but none was provided and no pre-funded `Sponsorship` exists.
  • The `Sponsorship` requires a signature for fee sponsorship.
  • The `Sponsorship` requires a signature for reserve sponsorship.
| -| `terINSUF_FEE_B` | The sponsor cannot pay the transaction fee: the co-signing sponsor's balance above its own reserve, or the pre-funded `Sponsorship`'s `FeeAmount` (capped by `MaxFee`), is insufficient. Returned against the open ledger, or when the fee payer has nothing spendable at all. | -| `tecINSUFF_FEE` | The same insufficient-fee condition as `terINSUF_FEE_B`, returned when the transaction is applied in a closed ledger and the fee payer has some spendable balance (non-zero) but not enough. | -| `tecINSUFFICIENT_RESERVE` | The sponsor does not have enough XRP to cover the reserve, or the pre-funded `Sponsorship` does not have enough `RemainingOwnerCount`. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-transactions.md b/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-transactions.md deleted file mode 100644 index fa959bd0..00000000 --- a/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-transactions.md +++ /dev/null @@ -1,69 +0,0 @@ -# Updated Transactions - -This page describes the changes to existing transaction types introduced by Sponsored Fees and Reserves. - -_(Requires the [Sponsor amendment][] {% not-enabled /%})_ - -## Payment Transaction Updates - -### Example JSON - -```json -{ - "TransactionType": "Payment", - "Account": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", // The sponsor funding the account creation - "Destination": "rfkDkFai4jUfCvAJiZ5Vm7XvvWjYvDqeYo", // The new account being created and sponsored - "Amount": "1", // 1 drop, the minimum - "Flags": 524288, // tfSponsorCreatedAccount - "Fee": "10", - "Sequence": 3 -} -``` - -### Payment Flags - -A new flag is added to the [Payment transaction](https://xrpl.org/docs/references/protocol/transactions/types/payment) for sponsoring new accounts: - -| Flag Name | Hex Value | Decimal Value | Description | -| :------------------------ | :----------- | :------------ | :---------- | -| `tfSponsorCreatedAccount` | `0x00080000` | 524288 | This flag is only valid if the Payment is used to create an account. If it is enabled, the created account will be sponsored by the `Account` submitting the transaction. | - -### Error Cases - -When `tfSponsorCreatedAccount` is enabled, the following additional error cases apply: - -| Error Code | Description | -| :------------------------- | :---------- | -| `temINVALID_FLAG` | `tfNoRippleDirect`, `tfPartialPayment`, or `tfLimitQuality` are enabled. The `tfSponsorCreatedAccount` flag cannot be combined with these flags. | -| `temBAD_AMOUNT` | The `Amount` specifies a non-XRP currency. | -| `tecNO_SPONSOR_PERMISSION` | The `Destination` already exists. This flag is only valid when creating a new account. | -| `tecUNFUNDED_PAYMENT` | The sponsoring `Account` does not have enough XRP to deliver the `Amount` while still covering its own reserve (or the transaction fee, whichever is greater). | - -## AccountDelete Transaction Updates - -The [AccountDelete transaction](https://xrpl.org/docs/references/protocol/transactions/types/accountdelete) adds new constraints for sponsored accounts. If the account being deleted has a `Sponsor` field, the `Destination` must equal the `Sponsor` value to ensure the sponsor can recoup their reserve. - -On successful deletion, the sponsor's `SponsoringAccountCount` is decremented by one. - -### Example JSON - -```json -{ - "TransactionType": "AccountDelete", - "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", - "Destination": "rN7n7otQDd6FczFgLdlqtyMVrn3HMfXpf", // The sponsor - "Fee": "5000000", - "Sequence": 2470665 -} -``` - -### Error Cases - -The following additional error cases apply for `AccountDelete` transactions: - -| Error Code | Description | -| :------------------------- | :---------- | -| `tecNO_SPONSOR_PERMISSION` | The `AccountRoot` has a `Sponsor` field, but the `Destination` is not equal to the sponsor. Sponsored account funds must go to the sponsor. | -| `tecHAS_OBLIGATIONS` | The `AccountRoot` has a non-zero `SponsoringOwnerCount` or `SponsoringAccountCount` field. The account cannot be deleted until those sponsorships are transferred or dissolved. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-75-permission-delegation/index.page.tsx b/docs/xls-75-permission-delegation/index.page.tsx index c90e66c4..a38f54bc 100644 --- a/docs/xls-75-permission-delegation/index.page.tsx +++ b/docs/xls-75-permission-delegation/index.page.tsx @@ -19,13 +19,21 @@ export const frontmatter = { }; export default function Page() { - const keyDates = [ - { date: "May 8, 2025", event: "XLS Spec Live" }, - { date: "TBA", event: "Available to Test on Devnet" }, - { date: "TBA", event: "Open for Voting on Mainnet" }, - { date: "TBA", event: "Vote Consensus" } + const KEY_DATE_EVENTS = [ + "XLS Spec Live", + "Available to Test on Devnet", + "Open for Voting on Mainnet", + "Vote Consensus" ]; + const [keyDates, setKeyDates] = React.useState( + KEY_DATE_EVENTS.map(event => ({ date: "🔄 Loading...", event })) + ); + + const handleKeyDatesUpdate = React.useCallback((newKeyDates: any[]) => { + setKeyDates(newKeyDates); + }, []); + return ( @@ -34,11 +42,17 @@ export default function Page() { subtitle="An on-chain primitive for delegating transaction permissions between accounts." /> - + + - +

- Explore key concepts, find detailed references, and follow - step-by-step tutorials. + Documentation on the feature, including how it works and why.

- Read the Docs + Read the Concepts @@ -101,12 +114,21 @@ export default function Page() {

- The performance testing report to assess the performance implications of the feature. + The performance testing report to assess the performance implications of the feature.

+ + +

+ The QA Test Report presents results of QA testing performed on the feature across rippled and Clio servers. +

+ + diff --git a/docs/xls-94-dynamic-mpts/dynamic-mpts.md b/docs/xls-94-dynamic-mpts/dynamic-mpts.md deleted file mode 100644 index 1007fa3f..00000000 --- a/docs/xls-94-dynamic-mpts/dynamic-mpts.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -seo: - description: Create MPTs with the option of changing specific fields or flags. -labels: - - Multi-Purpose Tokens (MPTs), MPT ---- - -# Dynamic Multi-Purpose Tokens - -Multi-Purpose Tokens (MPT) become immutable after issuance, but some use cases may require the capability to update an MPT's properties after its initial issuance. - -The Dynamic MPT amendment extends Multi-Purpose Tokens by allowing issuers to set specific properties as mutable when creating an MPT issuance. This enables some properties to be updated later as business needs evolve. For example, an issuer might need to adjust transfer fees based on market conditions, or update token metadata. Issuers can achieve this by explicitly declaring which specific fields and flags can be modified when they issue the MPT. Fields not marked as mutable during initial issuance remain immutable. - -_(Requires the [DynamicMPT amendment][] {% not-enabled /%})_ - -## Creating a Dynamic MPT - -When you issue an MPT, you can declare selected fields and MPT issuance flags as mutable in the `MutableFlags` field of the `MPTokenIssuanceCreate` transaction. Field mutability supports operational updates such as _metadata_ changes and _transfer fee_ adjustments without requiring a new issuance. All other fields and flags must remain immutable. - -## Modifying a Dynamic MPT - -After creating an MPT with mutable properties, you can update those specific fields or enable mutable MPT issuance flags using the `MPTokenIssuanceSet` transaction. You provide new values for mutable fields, or use a separate set of flags to enable mutable MPT issuance flags. - -Mutable MPT issuance flags are intentionally **one-way**: if the corresponding mutability flag was set during creation, the issuer may later enable the MPT issuance flag through `MPTokenIssuanceSet`, but once enabled, that flag cannot be disabled. - -## Security Considerations - -Mutability is opt-in and strictly bounded by the issuer's original declaration: - -- A field or MPT issuance flag can only be changed if it was explicitly declared mutable during `MPTokenIssuanceCreate`. -- Only the issuer of the `MPTokenIssuance` can use `MPTokenIssuanceSet` to modify mutable fields or enable mutable MPT issuance flags. -- Mutable MPT issuance flags are one-way and cannot be disabled through `MPTokenIssuanceSet` after they are enabled. This prevents an issuer from weakening issuance behavior after participants may have relied on the enabled flag. - -## See Also - -- [Dynamic MPT Reference Documentation](./reference.md) - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-94-dynamic-mpts/index.page.tsx b/docs/xls-94-dynamic-mpts/index.page.tsx index 5fcddc36..cecd0a2a 100644 --- a/docs/xls-94-dynamic-mpts/index.page.tsx +++ b/docs/xls-94-dynamic-mpts/index.page.tsx @@ -1,8 +1,8 @@ import * as React from 'react'; -import { - LandingContainer, - LandingLayout, -// ButtonToXRPL, // TODO: Uncomment when we move docs to xrpl.org +import { + LandingContainer, + LandingLayout, + ButtonToXRPL, FeatureHeader, FeatureContent } from "../../components/landing"; @@ -49,7 +49,7 @@ export default function Page() { /> @@ -62,11 +62,11 @@ export default function Page() { - +

Documentation on the feature, including how it works and why.

- + + Read the Concepts + diff --git a/docs/xls-94-dynamic-mpts/reference.md b/docs/xls-94-dynamic-mpts/reference.md deleted file mode 100644 index 7524768d..00000000 --- a/docs/xls-94-dynamic-mpts/reference.md +++ /dev/null @@ -1,192 +0,0 @@ ---- -seo: - description: Create MPTs with the option of changing specific fields or flags. -labels: - - Multi-Purpose Tokens (MPTs), MPT ---- -# Dynamic MPT Reference - -The Dynamic MPT amendment does not create any new data types, but it modifies several transactions and the `MPTokenIssuance` ledger entry. - -- **Transactions:** - - [MPTokenIssuanceCreate](#mptokenissuancecreate-transaction-changes) - The new `MutableFlags` field specifies which fields or flags are mutable after issuance. - - [MPTokenIssuanceSet](#mptokenissuanceset-transaction-changes) - Several new fields let you update mutable metadata and transfer fees, and enable MPT issuance flags that were declared mutable. -- **Ledger Entries:** - - [MPTokenIssuance](#mptokenissuance-entry-changes) - The new `MutableFlags` field stores mutability settings. - -_(Requires the [DynamicMPT amendment][] {% not-enabled /%})_ - -## MPTokenIssuanceCreate Transaction Changes - -To allow future changes to specific fields or flags of a token, issuers must clearly specify which ones should be mutable when creating the `MPTokenIssuance` object. - -### Example JSON - -This example creates an MPT issuance with mutable metadata: - -```json -{ - "TransactionType": "MPTokenIssuanceCreate", - "Account": "rNFta7UKwcoiCpxEYbhH2v92numE3cceB6", - "AssetScale": 4, - "TransferFee": 0, - "MaximumAmount": "50000000", - "MutableFlags": 65536, // tmfMPTCanMutateMetadata - "MPTokenMetadata": "464F4F", - "Fee": "12", - "Flags": 122, - "Sequence": 99536574 -} -``` - -### MPTokenIssuanceCreate Fields - -MPTokenIssuanceCreate transactions can include the following new field: - -| Field | JSON Type | [Internal Type][] | Required? | Description | -|:-----------------|:--------------------|:------------------|:----------|-------------| -| `MutableFlags` | Number | UInt32 | No | A bitwise combination of flags indicating which fields may be modified after issuance, and which MPT issuance flags may be enabled after issuance. See [MPTokenIssuanceCreate Mutable Flags](#mptokenissuancecreate-mutable-flags). | - -{% admonition type="warning" name="Warning" %} -Only the specified fields and flags may be declared mutable; all other fields remain immutable. -{% /admonition %} - -### MPTokenIssuanceCreate Mutable Flags - -The following flags are stored in the `MutableFlags` field, which is separate from the `Flags` field of the `MPTokenIssuanceCreate` transaction. MPT issuance flags that are declared mutable are one-way: they can be enabled after issuance via `MPTokenIssuanceSet`, but once enabled they cannot be disabled. Mutable fields (`MPTokenMetadata` and `TransferFee`) can always be modified. - -| Flag Name | Hex Value | Decimal Value | Description | -|:----------------------------- |:-------------|:--------------|:------------| -| `tmfMPTCanEnableCanLock` | `0x00000002` | 2 | If enabled, the MPT's **Can Lock** flag, which gives the issuer the power to lock/unlock holders' balances, can be enabled after issuance. | -| `tmfMPTCanEnableRequireAuth` | `0x00000004` | 4 | If enabled, the MPT's **Require Auth** flag, which indicates that individual holders must be authorized, can be enabled after issuance. | -| `tmfMPTCanEnableCanEscrow` | `0x00000008` | 8 | If enabled, the MPT's **Can Escrow** flag, which indicates that the token can be placed in escrow, can be enabled after issuance. | -| `tmfMPTCanEnableCanTrade` | `0x00000010` | 16 | If enabled, the MPT's **Can Trade** flag, which indicates that individual holders can trade their balances using the XRP Ledger DEX or AMM, can be enabled after issuance. | -| `tmfMPTCanEnableCanTransfer` | `0x00000020` | 32 | If enabled, the MPT's **Can Transfer** flag, which indicates that tokens held by non-issuers can be transferred to other accounts, can be enabled after issuance. | -| `tmfMPTCanEnableCanClawback` | `0x00000040` | 64 | If enabled, the MPT's **Can Clawback** flag, which indicates that the issuer can claw back value from individual holders, can be enabled after issuance. | -| `tmfMPTCanMutateMetadata` | `0x00010000` | 65536 | If enabled, the `MPTokenMetadata` field, which stores additional information about the token, can be modified. | -| `tmfMPTCanMutateTransferFee` | `0x00020000` | 131072 | If enabled, the `TransferFee` field, which determines the fee percentage charged on transfers between users, can be modified. | - -### Error Cases - -The following failure conditions have been added to the `MPTokenIssuanceCreate` transaction: - -| Error Code | Description | -|:-------------------|:------------| -| `temDISABLED` | The `MutableFlags` field is present but the DynamicMPT amendment is not enabled. | -| `temINVALID_FLAG` | The `MutableFlags` field contains an invalid value. | - -## MPTokenIssuanceSet Transaction Changes - -When updating mutable fields, issuers can change the field value to any allowed value. When enabling MPT issuance flags that were declared mutable, issuers can only enable them; mutable flags are one-way and cannot be disabled by `MPTokenIssuanceSet` once enabled. - -### Example JSON - -This example updates the MPT metadata: - -```json -{ - "TransactionType": "MPTokenIssuanceSet", - "Account": "rNFta7UKwcoiCpxEYbhH2v92numE3cceB6", - "MPTokenIssuanceID": "05EECEBE97A7D635DE2393068691A015FED5A89AD203F5AA", - "MPTokenMetadata": "575C5C", // Updated metadata from `464F4F` to `575C5C` - "Fee": "10", - "Flags": 1, - "Sequence": 99536577 -} -``` - -### MPTokenIssuanceSet Fields - -MPTokenIssuanceSet transactions can include the following new fields: - -| Field | JSON Type | [Internal Type][] | Required? | Description | -|:-----------------|:--------------------|:------------------|:----------|-------------| -| `MPTokenMetadata`| String | Blob | No | New metadata to replace the existing value. Setting an empty value removes the field. Only valid if `lsmfMPTCanMutateMetadata` was set when creating the `MPTokenIssuance` object. | -| `TransferFee` | Number | UInt16 | No | The new transfer fee value. Setting this to zero removes the field. Only valid if `lsmfMPTCanMutateTransferFee` was enabled when creating the `MPTokenIssuance` object. See [Transfer Fee Rules](#transfer-fee-rules). | -| `MutableFlags` | Number | UInt32 | No | Enable MPT issuance flags that were declared mutable when creating the `MPTokenIssuance` object. See [MPTokenIssuanceSet Mutable Flags](#mptokenissuanceset-mutable-flags). | - -### MPTokenIssuanceSet Mutable Flags - -The following flags are stored in the `MutableFlags` field, which is separate from the `Flags` field of the `MPTokenIssuanceSet` transaction. All of these flags are one-way: each one only enables an MPT issuance flag that was declared mutable at creation. Once enabled, the underlying MPT issuance flag cannot be disabled by `MPTokenIssuanceSet`. - -| Flag Name | Hex Value | Decimal Value | Description | -|:-------------------------- |:-------------|:--------------|:------------| -| `tmfMPTSetCanLock` | `0x00000001` | 1 | Enables the MPT's **Can Lock** flag, which allows the token to be locked both individually and globally. Once enabled, this flag cannot be disabled. | -| `tmfMPTSetRequireAuth` | `0x00000002` | 2 | Enables the MPT's **RequireAuth** flag, which requires individual holders to be authorized to hold the token. Once enabled, this flag cannot be disabled. | -| `tmfMPTSetCanEscrow` | `0x00000004` | 4 | Enables the MPT's **Can Escrow** flag, which allows holders to place balances into escrow. Once enabled, this flag cannot be disabled. | -| `tmfMPTSetCanTrade` | `0x00000008` | 8 | Enables the MPT's **Can Trade** flag, which allows holders to trade balances on the XRPL DEX. Once enabled, this flag cannot be disabled. | -| `tmfMPTSetCanTransfer` | `0x00000010` | 16 | Enables the MPT's **Can Transfer** flag, which allows tokens to be transferred to non-issuer accounts. Once enabled, this flag cannot be disabled. | -| `tmfMPTSetCanClawback` | `0x00000020` | 32 | Enables the MPT's **Can Clawback** flag, which allows the issuer to claw back tokens. Once enabled, this flag cannot be disabled. | - -{% admonition type="success" name="Tip" %} -Re-setting an MPT issuance flag that is already enabled is valid and has no additional effect. -{% /admonition %} - -### Transfer Fee Rules - -The ability to modify the `TransferFee` depends on two flags: - -- `lsfMPTCanTransfer`: must already be enabled to allow any non-zero `TransferFee`. Note that this flag can be enabled through `tmfMPTSetCanTransfer` if `lsmfMPTCanEnableCanTransfer` is set. Once enabled, it cannot be disabled. -- `lsmfMPTCanMutateTransferFee`: must be enabled at creation of the MPT issuance to allow any modification of the `TransferFee` field. - -{% admonition type="info" name="Note" %} -If the MPT's transfer fee and **Can Transfer** flag are both mutable, you can enable **Can Transfer** first, then modify the transfer fee in a second transaction. -{% /admonition %} - -The following table describes how setting a zero or non-zero transfer fee through the `MPTokenIssuanceSet` transaction behaves, based on the existing state of the `MPTokenIssuance` object on-ledger. The first two columns represent the ledger state (`lsfMPTCanTransfer` and `lsmfMPTCanMutateTransferFee`), while the third column represents the `TransferFee` value being set in the transaction. - -| Can Transfer | Can Mutate Transfer Fee | Transfer Fee Value | Result | Description | -|:-------------|:------------------------|:-------------------|:-------|:------------| -| Disabled | Enabled | Zero | ✅ | Removes the `TransferFee` field. | -| Disabled | Disabled | Zero | ❌ | Not allowed to modify `TransferFee`. | -| Disabled | Enabled/Disabled | Non-zero | ❌ | Always invalid regardless of mutability. | -| Enabled | Enabled | Non-zero | ✅ | Modifies the `TransferFee` field. | -| Enabled | Disabled | Non-zero | ❌ | Not allowed to modify `TransferFee`. | -| Enabled | Enabled | Zero | ✅ | Removes the `TransferFee` field. | -| Enabled | Disabled | Zero | ❌ | Not allowed to modify `TransferFee`. | - -### Error Cases - -The following failure conditions have been added to the `MPTokenIssuanceSet` transaction: - -| Error Code | Description | -|:----------------------|:------------| -| `tecNO_PERMISSION` | The sender does not have permission to modify the specified field or flag. For example:
  • The `MutableFlags` field attempts to modify a flag that was not declared as mutable during creation.
  • The `MPTokenMetadata` field is provided but `lsmfMPTCanMutateMetadata` was not set during creation.
  • The `TransferFee` field is provided but `lsmfMPTCanMutateTransferFee` was not set during creation.
  • A non-zero `TransferFee` is specified but `lsfMPTCanTransfer` is not currently enabled on the issuance.
| -| `temDISABLED` | The `MutableFlags`, `MPTokenMetadata`, or `TransferFee` is present but the DynamicMPT amendment is not enabled. | -| `temBAD_TRANSFER_FEE` | The `TransferFee` exceeds the maximum allowed value of 50,000. | -| `temINVALID_FLAG` | The `MutableFlags` field contains an invalid value, including `0`. | -| `temMALFORMED` | The transaction is malformed. For example:
  • The `Holder` field is provided when mutating the MPT issuance.
  • The `Flags` field is set when mutation fields (`MutableFlags`, `MPTokenMetadata`, or `TransferFee`) are present.
  • The `MPTokenMetadata` field exceeds the maximum length of 1024 bytes.
| - -## MPTokenIssuance Entry Changes - -MPTokenIssuance ledger entries can include the following new field: - -| Field | JSON Type | [Internal Type][] | Required? | Description | -|:-----------------|:--------------------|:------------------|:----------|-------------| -| `MutableFlags` | Number | UInt32 | No | Indicates which fields of this token issuance can be modified after creation, and which MPT issuance flags can be enabled after creation. See [MPTokenIssuance Mutable Flags](#mptokenissuance-mutable-flags). | - -### MPTokenIssuance Mutable Flags - -The following flags are stored in the `MutableFlags` field, which is separate from the `Flags` field of the `MPTokenIssuance` ledger entry: - -| Flag Name | Hex Value | Decimal Value | Description | -|:--------------------------------- |:-------------|:--------------|:------------| -| `lsmfMPTCanEnableCanLock` | `0x00000002` | 2 | Allows the **Can Lock** flag to be enabled after issuance. | -| `lsmfMPTCanEnableRequireAuth` | `0x00000004` | 4 | Allows the **Require Auth** flag to be enabled after issuance. | -| `lsmfMPTCanEnableCanEscrow` | `0x00000008` | 8 | Allows the **Can Escrow** flag to be enabled after issuance. | -| `lsmfMPTCanEnableCanTrade` | `0x00000010` | 16 | Allows the **Can Trade** flag to be enabled after issuance. | -| `lsmfMPTCanEnableCanTransfer` | `0x00000020` | 32 | Allows the **Can Transfer** flag to be enabled after issuance. | -| `lsmfMPTCanEnableCanClawback` | `0x00000040` | 64 | Allows the **Can Clawback** flag to be enabled after issuance. | -| `lsmfMPTCanMutateMetadata` | `0x00010000` | 65536 | Allows the `MPTokenMetadata` field to be modified. | -| `lsmfMPTCanMutateTransferFee` | `0x00020000` | 131072 | Allows the `TransferFee` field to be modified. | - -## Amendment Information - -| Amendment | DynamicMPT | -|:------------------------------------- |:---------- | -| Amendment ID | `58E92F338758479C06084E1B6BA366BAD8F75E5329A7F0EEAFFFDA51E5106B7F` | -| Status | In Development | -| Default Vote (Latest stable release) | No | -| Pre-amendment functionality retired? | No | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/concepts/confidential-transfers.md b/docs/xls-96-confidential-transfers/concepts/confidential-transfers.md deleted file mode 100644 index e60c68dc..00000000 --- a/docs/xls-96-confidential-transfers/concepts/confidential-transfers.md +++ /dev/null @@ -1,208 +0,0 @@ ---- -seo: - description: Confidential transfers keep MPT balances and transaction amounts private while maintaining public auditability of the total token supply. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# Confidential Transfers - -Confidential Transfers on the XRP Ledger allow Multi-Purpose Token (MPT) holders to keep their balances and transfer amounts private using [EC-ElGamal encryption](https://en.wikipedia.org/wiki/ElGamal_encryption) and [Zero-Knowledge Proofs (ZKPs)](https://en.wikipedia.org/wiki/Zero-knowledge_proof). Individual balances and transfer amounts remain shielded from the public ledger while maintaining compliance mechanisms for issuers and regulators to verify total supply and meet regulatory obligations. This addresses the need for institutional-grade privacy in financial applications while preserving auditability. - -Public and confidential balances can coexist for the same token, meaning the same MPT can have some balances held publicly and others held privately. Token holders can convert their public balance to confidential form and back as needed. - -{% admonition type="info" name="Note" %} -Confidential transfers are only available for direct payments between accounts. They do not work with other transaction types, such as those involving the XRPL DEX, escrows, or checks. -{% /admonition %} - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## Key Features of Confidential Transfers - -The Confidential Transfers feature is built on three core design principles: issuer second account model, a multi-ciphertext architecture for privacy and compliance, and the split-balance model for reliable transfers. - -### Issuer Second Account Model - -Issuers introduce confidential tokens into circulation via a dedicated **second account** instead of their primary issuer account. The issuer's primary account cannot hold confidential balances because its balance doesn't count toward tokens in circulation. - -To issue confidential tokens, issuers fund their second account with a public balance, then use the second account to convert the public balance to confidential form using the [ConfidentialMPTConvert transaction][]. - -The flow to issue confidential tokens is as follows: - -1. The Issuer creates an MPT issuance. -2. The Issuer creates a dedicated _second account_. -3. The Issuer sends a public MPT amount to the dedicated _second account_. -4. The dedicated _second account_ converts the public balance to a confidential balance. - -Because the XRP Ledger treats the second account as a regular _holder_, its balance counts towards tokens in circulation, which allows validators to enforce [supply caps](https://xrpl.org/docs/concepts/tokens/fungible-tokens/multi-purpose-tokens#supply-cap) without needing to decrypt confidential balances. - -In summary, this approach enables confidential distribution, where the issuer converts tokens once on the second account and distributes them directly to users, rather than requiring each holder to individually convert their balances from public to private. - -### Multi-Ciphertext Architecture - -A single confidential balance is represented by multiple parallel ciphertexts, each serving a distinct purpose: - -- **Holder encryption:** The holder's balance is encrypted under their own public key, granting exclusive spending authority. - -- **Issuer encryption:** The holder's balance is also encrypted under the issuer's public key, creating an encrypted mirror for supply verification and compliance without granting spending capability. - -- **Optional auditor encryption:** If configured, the holder's balance is additionally encrypted under an auditor's public key, enabling independent verification and [on-chain selective disclosure](#on-chain-selective-disclosure). - -Public keys must be generated off-chain using EC-ElGamal over secp256k1 encryption. - -{% admonition type="info" name="Note" %} -This encryption method is not considered quantum-safe. In the future, the XRP Ledger may migrate to post-quantum friendly schemes, such as those based on lattice cryptography. The specific migration path and timeline for achieving quantum resistance remains an open area of research. -{% /admonition %} - -#### Key Registration - -To participate in confidential transfers, holders must first convert their public balance to confidential form using the [ConfidentialMPTConvert transaction][]. This initial conversion serves as the opt-in mechanism and registers the holder's ElGamal public key on the ledger, enabling them to receive and [manage confidential balances](#managing-confidential-balances). - -Issuers and auditors register their keys when [enabling confidential transfers](#privacy-controls) on an MPT issuance. - -{% admonition type="danger" name="Warning" %} -**If a holder loses their private key, their confidential funds are permanently lost.** -Issuer and auditor keys also cannot be changed or cleared once registered. -{% /admonition %} - -#### Zero-Knowledge Proofs - -The XRP Ledger relies on a set of ZKPs to validate confidential transactions without revealing balances or transfer amounts. The following proof types are used: - -- **Schnorr Proof of Knowledge:** Proves ownership of the private key associated with an ElGamal public key. Required when a holder first registers their encryption key. - -- **Compact sigma proofs:** Cryptographic proofs, also called _AND-composed compact sigma proofs_, that bundle multiple zero-knowledge statements into a single fixed-size proof verified in one pass. Each confidential transaction type uses its own dedicated compact sigma proof to verify that encrypted values are consistent and correctly linked. - -- **Range proofs (Bulletproofs):** Prove that confidential amounts and post-transfer balances are non-negative and within a valid range, preventing overspending. - -Validators can verify confidential transactions by checking these cryptographic proofs without ever learning the underlying amounts. For example, when a holder sends tokens confidentially, the transaction includes encrypted values and proofs that mathematically demonstrate: -- The sender has sufficient balance. -- The amount is non-negative. -- All encrypted copies of the transfer amount are consistent across the sender, receiver, issuer, and optional auditor. - -Validators can only check the mathematical correctness of these proofs to ensure the transaction is valid, but cannot see the actual amounts involved. - -### Split-Balance Model - -To prevent the _stale proof_ problem, where an incoming transfer could invalidate a proof that a holder just created for an outgoing transfer, each account's confidential balance is divided into two parts: - -- **Spending Balance:** A stable balance used to generate proofs for outgoing transactions. -- **Inbox Balance:** Receives all incoming confidential transfers. - -When a holder receives a confidential transfer, the amount goes into their inbox. Before it can be spent, the holder must merge it into their spending balance using the [ConfidentialMPTMergeInbox transaction][]. If a merge is not explicitly performed, incoming funds accumulate in the inbox, remaining safe but unspendable until consolidated into the spending balance. - -After a merge, the inbox is reset to a deterministic "encrypted zero" value. This zero value is a valid ElGamal ciphertext that represents zero, but is indistinguishable from other ciphertexts to observers without the private key. - -#### Version Counter - -Each time your spending balance changes, a **version counter** increments by 1 and is bound to newly generated proofs to prevent [replay attacks](https://en.wikipedia.org/wiki/Replay_attack). This ensures that old proofs cannot be reused maliciously. - -## Privacy Properties - -Confidential transfers keep transaction amounts and balances private while certain information remains publicly visible on the ledger. - -**Private:** - -- Transaction amounts are encrypted. -- Account balances are encrypted and only visible to the holder, issuer, and any configured auditors. Validators and network observers see only encrypted ciphertexts and cryptographic proofs, never the underlying amounts. -- Distribution of confidential supply across holders. The ledger does not publicly reveal which specific accounts hold how much of the confidential supply. - -**Public:** - -- Sender and receiver addresses. -- The type of transaction being submitted. -- Total token supply. The ledger publicly tracks two plaintext values: `OutstandingAmount` (total tokens in circulation) and `ConfidentialOutstandingAmount` (how much of that total is held confidentially). Validators use these values to enforce supply caps without decrypting any balances. -- Conversion amounts when converting between public and confidential forms. - -Note that in low-volume scenarios, publicly visible elements can reveal patterns. For example, if an account converts 1,000,000 tokens to confidential form and later converts 800,000 tokens back to public form, observers know that 200,000 tokens remain in confidential form. However, they cannot determine whether those tokens were transferred to other accounts or are still held by the original account, because encrypted balances for zero are indistinguishable from non-zero balances. - -It's important to keep in mind that privacy is stronger when more participants make confidential transactions. - -## Auditability and Compliance - -The XRP Ledger supports two approaches for auditing hidden balances, on-chain selective disclosure and issuer-mediated auditing, along with a specialized clawback compliance mechanism. - -### On-Chain Selective Disclosure - -Issuers can configure an auditor when creating an MPT issuance by registering the auditor's ElGamal public key. This encrypts each holder's confidential balance under the auditor's public key, allowing the auditor to independently decrypt and verify balances off-chain without requiring cooperation from the issuer or holder. For example, a regulator designated as an auditor can use their own private key to decrypt a holder's confidential balance from the ledger, providing independent verification. - -### Issuer-Mediated Auditing - -As an alternative, issuers can provide auditing access by sharing their own ElGamal private key with auditors. Since the issuer maintains an encrypted mirror of all holder balances, the issuer's key provides read-only access to all confidential balances and transaction amounts. For example, when a regulator requests access to a user's transaction history, the issuer can provide the regulator with their ElGamal private key. The regulator can then use this key to decrypt the relevant confidential balances and transaction amounts directly from the ledger. - -This approach is operationally simpler but requires the auditor to trust that the issuer is providing complete and accurate information, and it grants the auditor the same decryption capabilities as the issuer. - -### Confidential Clawback - -While issuers retain the same [compliance controls](https://xrpl.org/docs/concepts/tokens/fungible-tokens/multi-purpose-tokens#compliance-controls) they have with public transactions, clawback operations work differently for confidential balances. - -The [ConfidentialMPTClawback transaction][] allows issuers to claw back a holder's **entire** confidential balance. Off-chain, the issuer decrypts their mirror copy of the holder's balance and generates a cryptographic proof validating the plaintext amount. The issuer then submits the transaction with the plaintext amount and proof. - -{% admonition type="danger" name="Warning" %} -The clawback proof can become stale if a holder's confidential balance changes between proof generation and validation. To ensure proof correctness and state consistency so the transaction doesn't fail on-ledger, issuers should follow the recommended flow for confidential clawbacks: - -1. [Lock](https://xrpl.org/docs/concepts/tokens/fungible-tokens/deep-freeze#how-does-mpt-freezelock-behavior-differ-from-iou) the MPT issuance for the holder by sending an [MPTokenIssuanceSet transaction](https://xrpl.org/docs/references/protocol/transactions/types/mptokenissuanceset) with the `tfMPTLock` flag enabled. -2. Submit the ConfidentialMPTClawback transaction. - -{% /admonition %} - -Validators verify the proof provides cryptographic certainty that the plaintext amount matches the encrypted balance. If valid, both the holder's spending and inbox balances are set to encrypted zero, the version counter is reset to 0, and the clawed back tokens are removed from circulation. - -## Privacy Controls - -Issuers can enable confidential features by setting the **Can Confidential Amount** flag on an MPT issuance. This can be done either during the initial [MPTokenIssuanceCreate transaction](../references/transactions/updated-transactions.md#mptokenissuancecreate) or later using an [MPTokenIssuanceSet transaction](../references/transactions/updated-transactions.md#mptokenissuanceset). - -By default, the privacy setting is mutable, so it can be toggled on and off as long as no confidential balances exist. Once confidential balances exist, the flag can no longer be disabled. - -When enabling confidential transfers, the issuer must also register their ElGamal public key, and if required, an auditor's public key. The MPT issuance must have a transfer fee of **0**, since transfer fees cannot be applied to encrypted amounts. If the issuance has a non-zero transfer fee, the issuer must remove it before enabling confidential transfers. - -{% admonition type="warning" name="Warning" %} -If the issuer enables the **Cannot Mutate Can Confidential Amount** flag at any time, the privacy setting becomes permanent and cannot be changed, even if no confidential balances exist. -{% /admonition %} - -## Managing Confidential Balances - -Token holders can manage confidential balances through four operations: - -- **Convert to confidential:** The [ConfidentialMPTConvert transaction][] converts public tokens to confidential form. The conversion amount is visible in plaintext, and the holder's public key is registered during their first conversion. - -- **Send confidentially:** The [ConfidentialMPTSend transaction][] transfers confidential tokens between holders. The transfer amount remains encrypted and hidden from public view, with ZKPs ensuring transaction validity. This transaction supports the same authorization requirements as standard MPT payments, including [Deposit Authorization](https://xrpl.org/docs/concepts/accounts/depositauth) and [Credential](https://xrpl.org/docs/concepts/decentralized-storage/credentials) requirements. - -- **Merge incoming transfers:** The [ConfidentialMPTMergeInbox transaction][] consolidates received tokens into the Spending Balance, making them available to send. This operation increments a version counter to prevent replay attacks. - -- **Convert back to public:** The [ConfidentialMPTConvertBack transaction][] converts confidential tokens back to public form, making the amount visible on the ledger again. - - -{% admonition type="info" name="Note" %} -Confidential transactions are larger and more computationally expensive than standard MPT transactions due to the inclusion of encrypted ciphertexts and ZKPs. They incur a higher [transaction cost](https://xrpl.org/docs/concepts/transactions/transaction-cost) than standard transactions: - -| Transaction | Cost Before Load Scaling | -|:---------------------------------------------|:------------------------ | -| Confidential MPT Transaction (single-signed) | 100 drops | -| Confidential MPT Transaction (multi-signed) | 10 drops × (10 + Number of Signatures Provided) | - -{% /admonition %} - -## Amendment Status - -| Amendment | ConfidentialTransfers | -|:------------------------------------ |:---------------------| -| Amendment ID | 2110E4A19966E2EF517C0A8C56A5F35099D7665B0BB89D7B126B30D50B86AAD5 | -| Status | In Development | -| Default Vote (Latest stable release) | No | -| Pre-amendment functionality retired? | No | - -## See Also - -- **Concepts:** - - [Multi-Purpose Tokens](https://xrpl.org/docs/concepts/tokens/fungible-tokens/multi-purpose-tokens) -- **References:** - - [ConfidentialMPTConvert transaction][] - - [ConfidentialMPTConvertBack transaction][] - - [ConfidentialMPTSend transaction][] - - [ConfidentialMPTMergeInbox transaction][] - - [ConfidentialMPTClawback transaction][] - - [Updated Ledger Entries](../references/updated-ledger-entries.md) - - [Updated Transactions](../references/transactions/updated-transactions.md) - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/index.page.tsx b/docs/xls-96-confidential-transfers/index.page.tsx index dbbd1019..1e8f0fd6 100644 --- a/docs/xls-96-confidential-transfers/index.page.tsx +++ b/docs/xls-96-confidential-transfers/index.page.tsx @@ -48,10 +48,6 @@ export default function Page() { <> The Confidential Transfers feature provides institutional-grade privacy for Multi-Purpose Tokens using advanced cryptography (EC-ElGamal and ZKPs). Individual balances and transfer amounts remain shielded from the public ledger while maintaining compliance mechanisms for authorized parties (issuers, auditors, or designated entities) to verify total supply and meet regulatory obligations. -

- Confidential Devnet: https://confidential.devnet.rippletest.net -
- Devnet Faucet: https://confidential-faucet.devnet.rippletest.net } keyDates={keyDates} @@ -78,13 +74,24 @@ export default function Page() { - +

- Explore key concepts, find detailed references, and follow - step-by-step tutorials. + Documentation on the feature, including how it works and why. +

+ + Read the Concepts + + + + +

+ The security audit performed by third-party security experts, including a link to the full, detailed security audit report.

diff --git a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback.md b/docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback.md deleted file mode 100644 index 7643fd24..00000000 --- a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -seo: - description: Claw back a holder's entire confidential balance, removing it from circulation. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# ConfidentialMPTClawback - -[[Source]](https://github.com/XRPLF/rippled/blob/eeb0d15ea97ed506c65406635edf301eff62a6fd/src/libxrpl/tx/transactors/token/ConfidentialMPTClawback.cpp "Source") - -Claw back a holder's _entire_ confidential balance (inbox and spending), removing it from circulation. - -Unlike a regular [Clawback](https://xrpl.org/docs/references/protocol/transactions/types/clawback), confidential balances are encrypted, so the issuer must provide the plaintext total amount to claw back and a Zero-Knowledge Proof (ZKP) validating the amount. - -{% admonition type="danger" name="Warning" %} -Issuers should **lock** the MPT issuance for the holder before submitting this transaction to ensure state consistency during proof verification. See [Confidential Clawback](../../concepts/confidential-transfers#confidential-clawback). -{% /admonition %} - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## Example {% $frontmatter.seo.title %} JSON - -```json -{ - "TransactionType": "ConfidentialMPTClawback", - "Account": "rIssuerAccount...", - "Holder": "rMaliciousHolder...", - "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864", - "MPTAmount": "1000", - "ZKProof": "a1b2...", - "Fee": "12", - "Sequence": 2470665, - "Flags": 2147483648 -} -``` - -## {% $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 | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------- |:--------- |:----------------- |:--------- |:------------| -| `Holder` | String | AccountID | Yes | The account from which funds are being clawed back. | -| `MPTokenIssuanceID` | String | UInt192 | Yes | The unique identifier for the MPT issuance. | -| `MPTAmount` | String | UInt64 | Yes | The plaintext total amount being removed. | -| `ZKProof` | String | Blob | Yes | A 64-byte compact Clawback sigma proof that proves the issuer's on-ledger balance mirror (`IssuerEncryptedBalance`) decrypts to the plaintext total amount (`MPTAmount`) being clawed back. | - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes][]: - -| Error Code | Description | -|:----------------------- |:----------- | -| `temDISABLED` | The ConfidentialTransfer amendment is not enabled. | -| `temMALFORMED` | The transaction is malformed. This can occur if:
  • The `Account` is not the issuer of the `MPTokenIssuanceID`.
  • The `Account` is attempting to claw back from itself.
  • The `ZKProof` length is incorrect.
| -| `temBAD_AMOUNT` | `MPTAmount` is zero or exceeds the maximum limits. | -| `tecNO_TARGET` | The `Holder` account does not exist. | -| `tecOBJECT_NOT_FOUND` | The `MPTokenIssuance` or the holder's `MPToken` object does not exist. | -| `tecNO_PERMISSION` | The transaction lacks the required permissions. This can occur if:
  • The issuance does not have the **Can Clawback** flag set.
  • The issuance is missing the `IssuerEncryptionKey`.
  • The holder's `MPToken` is missing the `IssuerEncryptedBalance`.
| -| `tecINSUFFICIENT_FUNDS` | The `MPTAmount` exceeds the global `ConfidentialOutstandingAmount`. | -| `tecBAD_PROOF` | The ZKP fails to prove that the `IssuerEncryptedBalance` (the mirror balance) encrypts the plaintext `MPTAmount`. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert.md b/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert.md deleted file mode 100644 index 2ffb31f5..00000000 --- a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -seo: - description: Convert a public MPT balance to a confidential one. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# ConfidentialMPTConvert - -[[Source]](https://github.com/XRPLF/rippled/blob/eeb0d15ea97ed506c65406635edf301eff62a6fd/src/libxrpl/tx/transactors/token/ConfidentialMPTConvert.cpp "Source") - -Convert your public MPT balance to an encrypted confidential balance. The converted amount is credited to your confidential inbox balance, requiring an explicit [ConfidentialMPTMergeInbox transaction][] to merge it into your spending balance before use. - -This transaction also serves as the opt-in mechanism for confidential transfer participation. By executing it, including with a zero-amount conversion, your `HolderEncryptionKey` is recorded on your `MPToken` object, enabling you to receive and manage confidential funds. Issuers can convert tokens through a separate holder account that they control, which participates as a regular holder with no special privileges. - -{% admonition type="info" name="Note" %} -This transaction converts only your **own** balance. To send confidential tokens to another account, first convert your balance, then use [ConfidentialMPTSend transaction][]. -{% /admonition %} - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## Example {% $frontmatter.seo.title %} JSON - -```json -{ - "TransactionType": "ConfidentialMPTConvert", - "Account": "rBob...", - "MPTokenIssuanceID": "610F33...", - "MPTAmount": "1000", - "HolderEncryptionKey": "038d...", - "HolderEncryptedAmount": "AD3F...", - "IssuerEncryptedAmount": "BC2E...", - "BlindingFactor": "EE21...", - "ZKProof": "ABCD...", - "Fee": "12", - "Sequence": 2470665, - "Flags": 2147483648 -} -``` - -## {% $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 | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------- |:--------- |:----------------- |:--------- |:------------| -| `MPTokenIssuanceID` | String | UInt192 | Yes | The unique identifier for the MPT issuance being converted. | -| `MPTAmount` | String | UInt64 | Yes | The public plaintext amount to convert into a confidential balance. Must be non-negative. | -| `HolderEncryptionKey` | String | Blob | No | The holder's ElGamal public key for confidential balances. Required when enabling confidential transfers for the first time. Forbidden if a key is already registered. | -| `HolderEncryptedAmount` | String | Blob | Yes | 66-byte ElGamal ciphertext credited to the holder's inbox balance. | -| `IssuerEncryptedAmount` | String | Blob | Yes | 66-byte ElGamal ciphertext credited to the issuer's mirror balance. | -| `AuditorEncryptedAmount` | String | Blob | No | A 66-byte ElGamal Ciphertext for the auditor. Required if `AuditorEncryptionKey` is present on the issuance. | -| `BlindingFactor` | String | UInt256 | Yes | The 32-byte scalar value used to encrypt the amount. Used by validators to verify the ciphertexts match the plaintext `MPTAmount`. | -| `ZKProof` | String | Blob | No | A Schnorr Proof of Knowledge. Required only when `HolderEncryptionKey` is present. | - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes][]: - -| Error Code | Description | -|:----------------------- |:----------- | -| `temDISABLED` | The ConfidentialTransfers amendment is not enabled. | -| `temMALFORMED` | The transaction is malformed for one of the following reasons:
  • `HolderEncryptionKey` is provided but `ZKProof` is not.
  • `HolderEncryptionKey` is not provided but `ZKProof` is.
  • `HolderEncryptionKey` length is not exactly 33 bytes.
  • `BlindingFactor` length is not 32 bytes.
  • `ZKProof` length is not 64 bytes.
| -| `temBAD_AMOUNT` | The `MPTAmount` is less than 0 or exceeds the maximum allowable MPT amount. | -| `temBAD_CIPHERTEXT` | One or more encrypted amount fields (`HolderEncryptedAmount`, `IssuerEncryptedAmount`, or `AuditorEncryptedAmount`) have incorrect length or represent an invalid elliptic curve point. | -| `tecNO_PERMISSION` | The issuance has `AuditorEncryptionKey` set, but the transaction does not include `AuditorEncryptedAmount`. | -| `tecDUPLICATE` | A public key is provided in the transaction, but the account already has a registered key. | -| `tecINSUFFICIENT_FUNDS` | The holder does not have sufficient public MPT balance to cover the MPTAmount. | -| `tecBAD_PROOF` | The ZKP verification failed for one of the following reasons:
  • The `BlindingFactor` fails to reconstruct the provided ciphertexts given the plaintext `MPTAmount`.
  • The Schnorr ZKP fails to verify the holder's knowledge of the secret key.
| - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback.md b/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback.md deleted file mode 100644 index 2272e940..00000000 --- a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -seo: - description: Convert a confidential MPT balance into a public one. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# ConfidentialMPTConvertBack - -[[Source]](https://github.com/XRPLF/rippled/blob/eeb0d15ea97ed506c65406635edf301eff62a6fd/src/libxrpl/tx/transactors/token/ConfidentialMPTConvertBack.cpp "Source") - -Convert your confidential MPT balance back to a public balance. This debits the confidential spending balance and credits the public balance with the plaintext amount. For the issuer's _second account_, this returns confidential supply to the issuer account reserve. - -{% admonition type="info" name="Note" %} -Only the spending balance can be converted back. Amounts in the inbox must first be merged into the spending balance using the [ConfidentialMPTMergeInbox transaction][]. -{% /admonition %} - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## Example {% $frontmatter.seo.title %} JSON - -```json -{ - "TransactionType": "ConfidentialMPTConvertBack", - "Account": "rUserAccount...", - "MPTokenIssuanceID": "610F33...", - "MPTAmount": "500", - "HolderEncryptedAmount": "AD3F...", - "IssuerEncryptedAmount": "BC2E...", - "AuditorEncryptedAmount": "C1A9...", - "BlindingFactor": "12AB...", - "ZKProof": "ABCD...", - "BalanceCommitment": "038A...", - "Fee": "12", - "Sequence": 2470665, - "Flags": 2147483648 -} -``` - -## {% $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 | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------- |:--------- |:----------------- |:--------- |:------------| -| `MPTokenIssuanceID` | String | UInt192 | Yes | The unique identifier for the MPT issuance. | -| `MPTAmount` | String | UInt64 | Yes | The plaintext amount to credit to the public balance. | -| `HolderEncryptedAmount` | String | Blob | Yes | 66-byte Ciphertext to be subtracted from the holder's `ConfidentialBalanceSpending`. | -| `IssuerEncryptedAmount` | String | Blob | Yes | 66-byte Ciphertext to be subtracted from the issuer's mirror balance. | -| `AuditorEncryptedAmount` | String | Blob | No | 66-byte Ciphertext for the auditor. Required if `AuditorEncryptionKey` is present on the issuance. | -| `BlindingFactor` | String | UInt256 | Yes | The 32-byte scalar value used to encrypt the amount. Used by validators to verify the ciphertexts match the plaintext `MPTAmount`. | -| `BalanceCommitment` | String | Blob | Yes | A 33-byte cryptographic commitment to the user's confidential spending balance. | -| `ZKProof` | String | Blob | Yes | An 816-byte proof bundle containing a compact ConvertBack sigma proof and a single Bulletproof range proof. See [Proof Structure](#proof-structure) for details. | - -## Proof Structure - -The `ZKProof` field contains an 816-byte bundle made up of two parts: - -- A **compact ConvertBack sigma proof (128 bytes)** that verifies the holder owns the spending balance and that the `BalanceCommitment` is correctly derived from it. - -- A **single Bulletproof range proof (688 bytes)** that verifies that the remaining balance after withdrawal is non-negative. - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes][]: - -| Error Code | Description | -|:----------------------- |:----------- | -| `temDISABLED` | The ConfidentialTransfer is not enabled. | -| `temMALFORMED` | The account is the Issuer, or the `BlindingFactor` is not exactly 32 bytes. | -| `temBAD_CIPHERTEXT` | Ciphertext lengths or formats are invalid. | -| `temBAD_AMOUNT` | `MPTAmount` is zero or greater than the maximum allowable supply. | -| `tecOBJECT_NOT_FOUND` | The `MPToken` or `MPTokenIssuance` does not exist. | -| `tecNO_PERMISSION` | One of the following occurred:
  • The issuance does not have the **Can Confidential Amount** flag.
  • The user's `MPToken` is missing the `ConfidentialBalanceSpending` or `HolderEncryptionKey` fields.
  • The issuance has `AuditorEncryptionKey` set but the transaction does not include `AuditorEncryptedAmount`.
| -| `tecINSUFFICIENT_FUNDS` | The global `ConfidentialOutstandingAmount` is less than the requested `MPTAmount`, or the user's confidential balance is insufficient. | -| `tecBAD_PROOF` | One of the following occurred:
  • The `BlindingFactor` fails to verify the integrity of the ciphertexts.
  • The provided `ZKProof` fails the compact sigma or range proof check.
| -| `tecLOCKED` | The MPT asset is locked for the account, or the asset is globally locked. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox.md b/docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox.md deleted file mode 100644 index 32c1cde7..00000000 --- a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -seo: - description: Merge your inbox balance into the spending balance for confidential transfers. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# ConfidentialMPTMergeInbox - -[[Source]](https://github.com/XRPLF/rippled/blob/eeb0d15ea97ed506c65406635edf301eff62a6fd/src/libxrpl/tx/transactors/token/ConfidentialMPTMergeInbox.cpp "Source") - -Merge your confidential _inbox_ balance into your _spending_ balance. This moves all funds from the inbox balance into the spending balance and resets the inbox to encrypted zero, ensuring that proofs reference only stable spending balances. - -{% admonition type="info" name="Note" %} -Even if the inbox is already empty (contains encrypted zero), this transaction is valid and succeeds. -{% /admonition %} - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## Example {% $frontmatter.seo.title %} JSON - -```json -{ - "TransactionType": "ConfidentialMPTMergeInbox", - "Account": "rUserAccount...", - "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864", - "Fee": "12", - "Sequence": 2470665, - "Flags": 2147483648 -} -``` - -## {% $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 | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------- |:--------- |:----------------- |:--------- |:----------- | -| `MPTokenIssuanceID` | String | UInt192 | Yes | The unique identifier for the MPT issuance. | - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes][]: - -| Error Code | Description | -|:----------------------- |:----------- | -| `temDISABLED` | The ConfidentialTransfer amendment is not enabled. | -| `temMALFORMED` | The account submitting the transaction is the Issuer. | -| `tecOBJECT_NOT_FOUND` | The `MPTokenIssuance` or the user's `MPToken` object does not exist. | -| `tecNO_PERMISSION` | The issuance does not have the **Can Confidential Amount** flag enabled, or the user's `MPToken` object has not been initialized (missing `ConfidentialBalanceInbox` or `ConfidentialBalanceSpending`). | -| `tefINTERNAL` | A system invariant failure where the issuer attempts to merge. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend.md b/docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend.md deleted file mode 100644 index d3b1c565..00000000 --- a/docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -seo: - description: Send MPT tokens to another account while keeping the transfer amount hidden. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# ConfidentialMPTSend - -[[Source]](https://github.com/XRPLF/rippled/blob/eeb0d15ea97ed506c65406635edf301eff62a6fd/src/libxrpl/tx/transactors/token/ConfidentialMPTSend.cpp "Source") - -Send MPT tokens to another account while keeping the transfer amount hidden. The transferred amount is credited to the receiver's confidential inbox balance to avoid proof staleness. The receiver can later merge these funds into the spending balance via the [ConfidentialMPTMergeInbox transaction][]. - -Confidential sends respect the same authorization requirements as standard MPT payments, including Deposit Authorization and Credential requirements. - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## Example {% $frontmatter.seo.title %} JSON - -```json -{ - "TransactionType": "ConfidentialMPTSend", - "Account": "rSenderAccount...", - "Destination": "rReceiverAccount...", - "MPTokenIssuanceID": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864", - "SenderEncryptedAmount": "AD3F...", - "DestinationEncryptedAmount": "DF4E...", - "IssuerEncryptedAmount": "BC2E...", - "ZKProof": "84af...", - "AmountCommitment": "038A...", - "BalanceCommitment": "02F1...", - "Fee": "12", - "Sequence": 2470665, - "Flags": 2147483648 -} -``` - -## {% $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 | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------- |:--------- |:----------------- |:--------- |:------------| -| `Destination` | String | AccountID | Yes | The receiver's account. | -| `MPTokenIssuanceID` | String | UInt192 | Yes | Identifier of the MPT issuance being transferred. | -| `SenderEncryptedAmount` | String | Blob | Yes | Ciphertext used to homomorphically debit the sender's spending balance. | -| `DestinationEncryptedAmount` | String | Blob | Yes | Ciphertext credited to the receiver's inbox balance. | -| `IssuerEncryptedAmount` | String | Blob | Yes | Ciphertext used to update the issuer mirror balance. | -| `ZKProof` | String | Blob | Yes | A 946-byte proof bundle containing a compact Send sigma proof and an aggregated Bulletproof range proof. See [Proof Structure](#proof-structure) for details. | -| `AmountCommitment` | String | Blob | Yes | A cryptographic commitment to the amount being transferred. | -| `BalanceCommitment` | String | Blob | Yes | A cryptographic commitment to the user's confidential spending balance. | -| `AuditorEncryptedAmount` | String | Blob | No | Ciphertext for the auditor. Required if `AuditorEncryptionKey` is present on the issuance. | -| `CredentialIDs` | Array | Vector256 | No | Array of Credential IDs. If present, the transaction can only succeed if the sender is authorized by credentials that match these IDs. | - -## Proof Structure - -The `ZKProof` field contains a 946-byte bundle made up of two parts: - -- A **compact Send sigma proof (192 bytes)** which simultaneously verifies: - - - **Ciphertext consistency:** All encrypted copies of the transfer amount (sender, receiver, issuer, and optional auditor) encrypt the same value. - - **Amount linkage:** The `AmountCommitment` commits to the same transfer amount as the ciphertexts. - - **Balance linkage:** The `BalanceCommitment` encodes the same spending balance as the sender's on-ledger encrypted balance. - -- An **aggregated Bulletproof range proof (754 bytes)** which verifies that both the transfer amount and the remaining balance are non-negative. - -## Error Cases - -Besides errors that can occur for all transactions, {% code-page-name /%} transactions can result in the following [transaction result codes][]: - -| Error Code | Description | -|:----------------------- |:----------- | -| `temDISABLED` | The ConfidentialTransfer amendment is not enabled. | -| `temMALFORMED` | The sender is the issuer, or the account attempts to send to itself. | -| `temBAD_CIPHERTEXT` | The `AuditorEncryptedAmount`, if present, has invalid length or represents an invalid elliptic curve point. | -| `tecNO_TARGET` | The destination account does not exist. | -| `tecNO_AUTH` | The issuance does not have the **Can Transfer** flag enabled. | -| `tecNO_PERMISSION` | The transaction lacks required permissions. This can occur if:
  • The issuance does not have the **Can Confidential Amount** flag enabled.
  • One of the participating accounts lacks a registered ElGamal public key or required confidential fields.
  • The destination account has Deposit Authorization enabled and the sender is not preauthorized.
  • The destination account requires credentials, but the transaction does not include valid matching credentials in the `CredentialIDs` field.
| -| `tecNO_ENTRY` | A credential ID specified in `CredentialIDs` does not exist on the ledger. | -| `tecEXPIRED` | A credential specified in `CredentialIDs` has expired. | -| `terFROZEN` | Either the sender or receiver's balance is currently frozen. | -| `tecBAD_PROOF` | The provided Zero-Knowledge Proof fails the compact sigma or range proof check. This can occur if the proof was generated with an outdated `ConfidentialBalanceVersion`. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/references/transactions/updated-transactions.md b/docs/xls-96-confidential-transfers/references/transactions/updated-transactions.md deleted file mode 100644 index 2db99709..00000000 --- a/docs/xls-96-confidential-transfers/references/transactions/updated-transactions.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -seo: - description: The Confidential Transfers amendment updates the MPTokenIssuanceCreate and MPTokenIssuanceSet transactions to support configuring confidential transfer capabilities. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# Updated Transactions - -The Confidential Transfers amendment updates the following transactions to support configuring confidential transfer capabilities: - -- [MPTokenIssuanceCreate](#mptokenissuancecreate) - Set initial privacy flags when creating an MPT issuance. -- [MPTokenIssuanceSet](#mptokenissuanceset) - Configure encryption keys and toggle privacy settings after creation. - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## MPTokenIssuanceCreate - -### MPTokenIssuanceCreate Flags - -In addition to the existing [MPTokenIssuanceCreate flags](https://xrpl.org/docs/references/protocol/transactions/types/mptokenissuancecreate#mptokenissuancecreate-flags), confidential `MPTokenIssuanceCreate` transactions support: - -| Flag Name | Hex Value | Decimal Value | Description | -|:-----------------------------|:-------------|:--------------|:------------| -| `tfMPTCanConfidentialAmount` | `0x00000080` | 128 | If enabled, the MPT issuance supports confidential transfers. | - -### MPTokenIssuanceCreate Mutable Flags - -Confidential MPTokenIssuanceCreate transactions support the following value in the `MutableFlags` field: - -| Flag Name | Hex Value | Decimal Value | Description | -|:-------------------------------------------|:-------------|:--------------|:------------| -| `tmfMPTCannotMutateCanConfidentialAmount` | `0x00040000` | 262144 | If enabled, issuers cannot change the **Can Confidential Amount** flag after the token is issued. | - -## MPTokenIssuanceSet - -This transaction is the **only** way to register issuer and auditor public keys or modify the privacy status of an MPT issuance. - -### MPTokenIssuanceSet Fields - -In addition to the existing [MPTokenIssuanceSet](https://xrpl.org/docs/references/protocol/transactions/types/mptokenissuanceset) transaction fields, confidential MPTokenIssuanceSet transactions support: - -| Field | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------- |:-------------------- |:------------------ |:---------- |:------------| -| `IssuerEncryptionKey` | String | Blob | No | The 33-byte EC-ElGamal public key used for the issuer's mirror balances. | -| `AuditorEncryptionKey` | String | Blob | No | Optional 33-byte EC-ElGamal public key used for regulatory oversight. Must be provided together with `IssuerEncryptionKey` in the same transaction. | -| `MutableFlags` | Number | UInt32 | No | Flags to enable or disable mutable properties of the MPT issuance. | - -#### MPTokenIssuanceSet Mutable Flags - -The `MutableFlags` field allows an issuer to enable or disable specific flags on an MPT issuance. For confidential MPTs, the following flags are relevant: - -| Flag Name | Hex Value | Decimal Value | Description | -|:---------------------|:-------------|:--------------|:------------| -| `tmfMPTSetCanConfidentialAmount` | `0x00001000` | 4096 | Enable confidential transfers for this MPT issuance by enabling the **Can Confidential Amount** flag. Can only be used if the **Cannot Mutate Can Confidential Amount** flag is _disabled_ and there is no existing confidential outstanding amount. | -| `tmfMPTClearCanConfidentialAmount` | `0x00002000` | 8192 | Disable confidential transfers for this MPT issuance by disabling the **Can Confidential Amount** flag. Can only be used if the **Cannot Mutate Can Confidential Amount** flag is disabled and there is no existing confidential outstanding amount. | - -### Error Cases - -Besides errors that can occur for all transactions, `MPTokenIssuanceSet` transactions can result in the following [transaction result codes][]: - -| Error Code | Description | -|:-----------|:------------| -| `temINVALID_FLAG` | Both `tmfMPTSetCanConfidentialAmount` and `tmfMPTClearCanConfidentialAmount` flags were specified in the same transaction, which is not allowed. | -| `temMALFORMED` | The `AuditorEncryptionKey` was provided without `IssuerEncryptionKey`, or the public key length is incorrect (must be 33 bytes). | -| `tecNO_PERMISSION` | One of the following occurred:
  • Attempted to update a public key that has already been set.
  • Attempted to change the privacy flag when the **Cannot Mutate Can Confidential Amount** flag is enabled.
  • Attempted to set public keys when the **Can Confidential Amount** flag is disabled.
  • Attempted to change the privacy setting when confidential balances already exist.
  • Attempted to set public keys when the `ConfidentialOutstandingAmount` field is present.
| - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/docs/xls-96-confidential-transfers/references/updated-ledger-entries.md b/docs/xls-96-confidential-transfers/references/updated-ledger-entries.md deleted file mode 100644 index d89dd065..00000000 --- a/docs/xls-96-confidential-transfers/references/updated-ledger-entries.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -seo: - description: The Confidential Transfers amendment updates the MPTokenIssuance and MPToken ledger entries for confidential balances and transfers. -labels: - - Multi-Purpose Tokens, MPTs, Tokens - - Confidential Transfers ---- -# Updated Ledger Entries - -The Confidential Transfers amendment updates two existing ledger entry types to support confidential balances and transfers: - -- [MPTokenIssuance](#mptokenissuance) - Adds fields for issuer and auditor public keys, and tracks total confidential supply. -- [MPToken](#mptoken) - Adds fields for holder public keys and encrypted confidential balances. - -_(Requires the [ConfidentialTransfers amendment][] {% not-enabled /%})_ - -## MPTokenIssuance - -### MPTokenIssuance Fields - -In addition to the existing [MPTokenIssuance fields](https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance#mptokenissuance-fields), confidential MPTokenIssuance entries support: - -| Name | JSON Type | [Internal Type][] | Required? | Description | -|:------------------------------- |:------------------- |:----------------- |:----------- |:----------- | -| `IssuerEncryptionKey` | String | Blob | No | A 33-byte compressed ElGamal public key for the issuer. | -| `AuditorEncryptionKey` | String | Blob | No | A 33-byte compressed ElGamal public key for an optional on-chain auditor. | -| `ConfidentialOutstandingAmount` | Number | UInt64 | No | The total amount of this token that is currently held in confidential balances. | - -### MPTokenIssuance Flags - -In addition to the existing [MPTokenIssuance flags](https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance#mptokenissuance-flags), confidential MPTokenIssuance entries support: - -| Flag Name | Hex Value | Decimal Value | Description | -| :--------------------------- |:------------ |:------------ |:------------| -| `lsfMPTCanConfidentialAmount` | `0x00000080` | 128 |If enabled, indicates that confidential transfers and conversions are enabled for this token issuance. | -| `lsfMPTCannotMutateCanConfidentialAmount` | `0x00040000` | 262144 |If enabled, the **Can Confidential Amount** flag cannot be changed after the token is issued, permanently locking the confidentiality setting. | - -## MPToken - -### MPToken Fields - -In addition to the existing [MPToken fields](https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/mptoken#mptoken-fields), confidential MPToken entries support: - -| Name | JSON Type | [Internal Type][] | Required? | Description | -|:----------------------------- |:-------------------- |:----------------- |:---------- |:------------ | -| `HolderEncryptionKey` | String | Blob | No | The holder's ElGamal public key for confidential balances. Present when the holder has a confidential balance. | -| `ConfidentialBalanceInbox` | String | Blob | No | Encrypted inbox balance that receives incoming confidential transfers. Before it can be spent, the holder must merge it into their spending balance using the [ConfidentialMPTMergeInbox transaction][]. Present when the holder has a confidential balance. | -| `ConfidentialBalanceSpending` | String | Blob | No | Encrypted spending balance used to generate proofs for outgoing transactions. Present when the holder has a confidential balance. | -| `ConfidentialBalanceVersion` | Number | UInt32 | No | Version number that increments each time the spending balance changes. This version is cryptographically bound to ZKPs in outgoing transactions to prevent replay attacks and ensure proof validity. If the version changes between proof generation and submission, the transaction will fail. | -| `IssuerEncryptedBalance` | String | Blob | No | Copy of the holder's total confidential balance encrypted for the issuer to audit supply. Present when the holder has a confidential balance. | -| `AuditorEncryptedBalance` | String | Blob | No | The holder's total confidential balance encrypted under the auditor's key for independent auditing. Only present if an auditor is configured. | - -{% raw-partial file="/docs/_snippets/common-links.md" /%} diff --git a/redirects.yaml b/redirects.yaml index 17a70ae5..ea05fd10 100644 --- a/redirects.yaml +++ b/redirects.yaml @@ -570,3 +570,67 @@ docs/xls-73d/ammclawback: /docs/xls-33d-multi-purpose-tokens/reference/payment: to: https://xrpl.org/docs/references/protocol/transactions/types/payment type: 301 + + +# dynamic mpt docs (XLS-94) +/docs/xls-94-dynamic-mpts/dynamic-mpts: + to: https://xrpl.org/docs/concepts/tokens/fungible-tokens/mutable-mpts + type: 301 +/docs/xls-94-dynamic-mpts/reference: + to: https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance + type: 301 + +# confidential transfers docs (XLS-96) +/docs/xls-96-confidential-transfers/concepts/confidential-transfers: + to: https://xrpl.org/docs/concepts/tokens/fungible-tokens/confidential-transfers + type: 301 +/docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback: + to: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptclawback + type: 301 +/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert: + to: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptconvert + type: 301 +/docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback: + to: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptconvertback + type: 301 +/docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox: + to: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptmergeinbox + type: 301 +/docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend: + to: https://xrpl.org/docs/references/protocol/transactions/types/confidentialmptsend + type: 301 +/docs/xls-96-confidential-transfers/references/transactions/updated-transactions: + to: https://xrpl.org/docs/concepts/tokens/fungible-tokens/confidential-transfers + type: 301 +/docs/xls-96-confidential-transfers/references/updated-ledger-entries: + to: https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance + type: 301 + +# sponsored fees and reserves docs (XLS-68) +/docs/xls-68-sponsored-fees-and-reserves/concepts/sponsored-fees-and-reserves: + to: https://xrpl.org/docs/concepts/accounts/sponsored-fees-and-reserves + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship: + to: https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/sponsorship + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/updated-ledger-entries: + to: https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/sponsorship + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset: + to: https://xrpl.org/docs/references/protocol/transactions/types/sponsorshipset + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer: + to: https://xrpl.org/docs/references/protocol/transactions/types/sponsorshiptransfer + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-common-transaction-fields: + to: https://xrpl.org/docs/references/protocol/transactions/common-fields + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-transactions: + to: https://xrpl.org/docs/concepts/accounts/sponsored-fees-and-reserves + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/apis/account_sponsoring: + to: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_objects + type: 301 +/docs/xls-68-sponsored-fees-and-reserves/references/apis/updated-apis: + to: https://xrpl.org/docs/references/http-websocket-apis/public-api-methods/account-methods/account_objects + type: 301 diff --git a/sidebars.yaml b/sidebars.yaml index ff1d1c10..148e1300 100644 --- a/sidebars.yaml +++ b/sidebars.yaml @@ -13,65 +13,12 @@ - page: docs/xls-66-lending-protocol/index.page.tsx - page: docs/xls-65-single-asset-vault/index.page.tsx - page: docs/xls-56-batch-transactions/index.page.tsx - - group: - page: docs/xls-94-dynamic-mpts/index.page.tsx - expanded: false - items: - - page: docs/xls-94-dynamic-mpts/dynamic-mpts.md - label: About Dynamic MPTs - - page: docs/xls-94-dynamic-mpts/reference.md - label: Reference Documentation - - group: XLS-96 Confidential Transfers - page: docs/xls-96-confidential-transfers/index.page.tsx - expanded: false - items: - - group: Concepts - expanded: false - items: - - page: docs/xls-96-confidential-transfers/concepts/confidential-transfers.md - - group: References - expanded: false - items: - - group: Transactions - expanded: false - items: - - page: docs/xls-96-confidential-transfers/references/transactions/confidentialmptclawback.md - - page: docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvert.md - - page: docs/xls-96-confidential-transfers/references/transactions/confidentialmptconvertback.md - - page: docs/xls-96-confidential-transfers/references/transactions/confidentialmptmergeinbox.md - - page: docs/xls-96-confidential-transfers/references/transactions/confidentialmptsend.md - - page: docs/xls-96-confidential-transfers/references/transactions/updated-transactions.md - - page: docs/xls-96-confidential-transfers/references/updated-ledger-entries.md + - page: docs/xls-94-dynamic-mpts/index.page.tsx + - page: docs/xls-96-confidential-transfers/index.page.tsx - page: docs/xls-100-smart-escrows/index.page.tsx expanded: false items: - page: docs/xls-100-smart-escrows/concepts/programmability.md - - group: XLS-68 Sponsored Fees and Reserves - page: docs/xls-68-sponsored-fees-and-reserves/index.page.tsx - items: - - group: Concepts - expanded: false - items: - - page: docs/xls-68-sponsored-fees-and-reserves/concepts/sponsored-fees-and-reserves.md - - group: References - expanded: false - items: - - group: Ledger Entries - expanded: false - items: - - page: docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/sponsorship.md - - page: docs/xls-68-sponsored-fees-and-reserves/references/ledger-entries/updated-ledger-entries.md - - group: Transactions - expanded: false - items: - - page: docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshipset.md - - page: docs/xls-68-sponsored-fees-and-reserves/references/transactions/sponsorshiptransfer.md - - page: docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-common-transaction-fields.md - - page: docs/xls-68-sponsored-fees-and-reserves/references/transactions/updated-transactions.md - - group: APIs - expanded: false - items: - - page: docs/xls-68-sponsored-fees-and-reserves/references/apis/account_sponsoring.md - - page: docs/xls-68-sponsored-fees-and-reserves/references/apis/updated-apis.md + - page: docs/xls-68-sponsored-fees-and-reserves/index.page.tsx - page: docs/xls-82-mpt-dex/index.page.tsx From 0efa5c85a76c270133fd68ce595bf21cc3e6cf59 Mon Sep 17 00:00:00 2001 From: Maria Date: Mon, 10 Aug 2026 15:25:38 +0100 Subject: [PATCH 2/3] Fix AmendmentTracker component API error --- components/AmendmentTracker.tsx | 49 +++++++++++++++++++++++++-------- 1 file changed, 37 insertions(+), 12 deletions(-) diff --git a/components/AmendmentTracker.tsx b/components/AmendmentTracker.tsx index 076a8e6e..4f58a93c 100644 --- a/components/AmendmentTracker.tsx +++ b/components/AmendmentTracker.tsx @@ -330,19 +330,39 @@ export const AmendmentTracker: React.FC = ({ throw new Error('Could not extract version number'); } - // Create the release branch name - const releaseBranch = `release-${majorMinorVersion}`; - - const buildInfoCommitsResponse = await fetch( - `${GITHUB_API_BASE_URI}/commits?path=src/libxrpl/protocol/BuildInfo.cpp&sha=${releaseBranch}&per_page=100` - ); + // rippled's release branches moved from "release-X.Y" (e.g. release-3.1) + // to "release/X.Y.x" (e.g. release/3.3.x), so try the current scheme + // first, then the legacy one, then the version tag. + const candidateRefs = [ + `release/${majorMinorVersion}.x`, + `release-${majorMinorVersion}`, + baseVersion, + ]; + + // Match "Set version to X.Y.Z" or "Bump version to X.Y.Z" for the exact + // release only; the lookahead excludes -rc and -b pre-releases. + const escapedVersion = baseVersion.replace(/\./g, '\\.'); + const versionPattern = new RegExp(`(?:Set|Bump) version to ${escapedVersion}(?![\\d.-])`, 'i'); + + let buildInfoFetched = false; + for (const ref of candidateRefs) { + const buildInfoCommitsResponse = await fetch( + `${GITHUB_API_BASE_URI}/commits?path=src/libxrpl/protocol/BuildInfo.cpp&sha=${ref}&per_page=100` + ); + + if (!buildInfoCommitsResponse.ok) { + // Only keep trying other refs when the branch genuinely doesn't + // exist (404). On rate limiting (403) or other errors, stop so we + // don't spend extra requests, matching the original single call. + if (buildInfoCommitsResponse.status !== 404) { + break; + } + continue; + } + buildInfoFetched = true; - if (buildInfoCommitsResponse.ok) { const buildInfoCommits = await buildInfoCommitsResponse.json(); - - // Create pattern to match "Set version to X.Y.Z" (exact version, no rc/b builds) - const versionPattern = new RegExp(`Set version to ${baseVersion.replace(/\./g, '\\.')}`, 'i'); - + // Search through BuildInfo.cpp commit messages for (const commitData of buildInfoCommits) { if (versionPattern.test(commitData.commit.message)) { @@ -358,7 +378,12 @@ export const AmendmentTracker: React.FC = ({ break; } } - } else { + if (versionCommit) { + break; + } + } + + if (!buildInfoFetched) { throw new Error(); } } catch (error) { From a925237a027a518a182de2b4b3e5a27134b29972 Mon Sep 17 00:00:00 2001 From: Maria Date: Wed, 12 Aug 2026 11:47:49 +0100 Subject: [PATCH 3/3] Address review feedback --- redirects.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/redirects.yaml b/redirects.yaml index ea05fd10..881ea4ee 100644 --- a/redirects.yaml +++ b/redirects.yaml @@ -577,7 +577,7 @@ docs/xls-73d/ammclawback: to: https://xrpl.org/docs/concepts/tokens/fungible-tokens/mutable-mpts type: 301 /docs/xls-94-dynamic-mpts/reference: - to: https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance + to: https://xrpl.org/docs/concepts/tokens/fungible-tokens/mutable-mpts type: 301 # confidential transfers docs (XLS-96)