From 451fc83debd8c631ee2d7039339604ad085aa157 Mon Sep 17 00:00:00 2001 From: Dennis Dawson Date: Tue, 17 Jun 2025 12:45:01 -0700 Subject: [PATCH] Add Delegate to Draft Branch --- .../protocol/transactions/common-fields.md | 41 ++++++++++++++++++- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/docs/references/protocol/transactions/common-fields.md b/docs/references/protocol/transactions/common-fields.md index 3c1e0dfff3..fd810beb54 100644 --- a/docs/references/protocol/transactions/common-fields.md +++ b/docs/references/protocol/transactions/common-fields.md @@ -45,7 +45,6 @@ One situation in which this is useful is if you have a primary system for submit The `AccountTxnID` field cannot be used on transactions that use [Tickets](../../../concepts/accounts/tickets.md). Transactions that use `AccountTxnID` cannot be placed in the [transaction queue](../../../concepts/transactions/transaction-queue.md). - ## Auto-fillable Fields Some fields can be automatically filled in before a transaction is signed, either by a `rippled` server or by a [client library](../../client-libraries.md). Auto-filling values requires an active connection to the XRP Ledger to get the latest state, so it cannot be done offline. The details can vary by library, but auto-filling always provides suitable values for at least the following fields: @@ -60,6 +59,45 @@ For a production system, we recommend _not_ leaving these fields to be filled by The [`Paths` field](types/payment.md#paths) of the [Payment transaction][] type can also be automatically filled in. +## Delegate + +The `Delegate` ledger object stores a set of permissions that an XRPL account has delegated to another account. You create `Delegate` objects using the [`DelegateSet`](./delegate-set.md) transaction. + +### Structure + +A `Delegate` object has the following fields: + +| Field Name | Required? | JSON Type | Internal Type | Description | +|------------|-----------|-----------|---------------|-------------| +| `LedgerIndex` | ✔️ | string | Hash256 | The unique ID of the ledger object. | +| `LedgerEntryType` | ✔️ | string | UInt16 | The ledger object's type (`Delegate`) | +| `Account` | ✔️ | string | AccountID | The account that delegates permissions to another account. | +| `Authorize` | ✔️ | string | AccountID | The account to which permissions are delegated. | +| `Permissions` | ✔️ | string | STArray | The transaction permissions that the `Authorize` account has been granted. | +| `OwnerNode` | | string | UInt64 | A hint indicating which page of the sender's owner directory links to this object, in case the directory consists of multiple pages. | +| `PreviousTxnID` | | string | Hash256 | The identifying hash of the transaction that most recently modified this object. | +| `PreviousTxnLgrSeqNumber`| | number | UInt32 |The index of the ledger that contains the transaction that most recently modified this object. | + +### Retrieving Delegate Objects + +You can retrieve `Delegate` ledger objects using the `ledger_entry` RPC method. The unique ID of a `Delegate` object is a hash of the `Account` and `Authorize` fields, combined with the unique space key for Delegate objects. + +### Account Deletion + +A `Delegate` object is not a deletion blocker. This means that deleting an account removes any `Delegate` objects associated with it. + +### Example Delegate JSON + +This sample `Delegate` object shows that the _rISAAC_ account has delegated `TrustLineAuthorize` permission to the _rKYLIE_ account. + +```json +{ + "LedgerEntryType": "Delegate", + "Account": "rISAAC......", + "Authorize": "rKYLIE......", + "Permissions": [{"Permission": {"PermissionValue": "TrustlineAuthorize"}}], +} +``` ## Flags Field @@ -96,7 +134,6 @@ A transaction's `Flags` field can contain flags that apply at different levels o {% admonition type="info" name="Note" %}The [AccountSet transaction][] type has [its own non-bitwise flags](types/accountset.md#accountset-flags), which serve a similar purpose to type-based flags. [Ledger objects](../ledger-data/ledger-entry-types/index.md) also have a `Flags` field with different bitwise flag definitions.{% /admonition %} - ## Memos Field The `Memos` field includes arbitrary messaging data with the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields: