ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 23:25:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add Delegate to Draft Branch

Browse Source
This commit is contained in:
Dennis Dawson
2025-06-17 12:45:01 -07:00
committed by Oliver Eggert
parent 88d9fce053
commit 451fc83deb
1 changed files with 39 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/references/protocol/transactions/common-fields.md
View File

@@ -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: