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

Re-level non-docs content to top of repo and rename content→docs

Browse Source
This commit is contained in:
mDuo13
2024-01-31 16:24:01 -08:00
parent f841ef173c
commit c10beb85c2
2907 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/references/protocol/ledger-data/common-fields.md Normal file
View File

@@ -0,0 +1,39 @@
---
html: ledger-entry-common-fields.html
seo:
description: These common fields are part of every ledger entry.
---
# Ledger Entry Common Fields
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp)
Every entry in a [ledger](../../../concepts/ledgers/index.md)'s state data has the same set of common fields, plus additional fields based on the [ledger entry type](ledger-entry-types/index.md). Field names are case-sensitive. The common fields for all ledger entries are:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:-------------------------|:----------|:------------------|:----------|:------------|
| `index` or `LedgerIndex` | String | Hash256 | No | The unique ID for this ledger entry. In JSON, this field is represented with different names depending on the context and API method. (Note, even though this is specified as "optional" in the code, every ledger entry should have one unless it's legacy data from very early in the XRP Ledger's history.) |
| `LedgerEntryType` | String | UInt16 | Yes | The type of ledger entry. Valid [ledger entry types](ledger-entry-types/index.md) include `AccountRoot`, `Offer`, `RippleState`, and others. |
| `Flags` | Number | UInt32 | Yes | Set of bit-flags for this ledger entry. |
**Caution:** In JSON, the ledger entry ID is in the `index` or `LedgerIndex` field. This is not the same as a [ledger index][] in the `ledger_index` field.
## Ledger Entry ID
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp)
Each ledger entry has a unique ID. The ID is derived by hashing important contents of the entry, along with a [namespace identifier](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/LedgerFormats.h). The [ledger entry type](ledger-entry-types/index.md) determines the namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. The hash function is [SHA-512Half][].
Generally, a ledger entry's ID is returned as the `index` field in JSON, at the same level as the object's contents. In [transaction metadata](../transactions/metadata.md), the ledger object's ID in JSON is `LedgerIndex`.
Offer directories have special IDs, where part of the hash is replaced with the exchange rate of Offers in that directory.
[{% inline-svg file="/img/ledger-object-ids.svg" /%}](/img/ledger-object-ids.svg "Diagram: ID calculations for different types of ledger entries. The space key prevents IDs for different types from colliding.")
## Flags
Flags are on/off settings, which are represented as binary values that are combined into a single number using bitwise-OR operations. The bit values for the flags in ledger entries are different than the values used to enable or disable those flags in a transaction. Ledger state flags have names that begin with **`lsf`**.
The possible values for the flags field vary based on the ledger entry type. Some ledger entry types have no flags defined. In these cases, the `Flags` field always has the value `0`.
{% raw-partial file="/_snippets/common-links.md" /%}

22
docs/references/protocol/ledger-data/index.md Normal file
View File

@@ -0,0 +1,22 @@
---
html: ledger-data-formats.html
parent: protocol-reference.html
seo:
description: Learn about individual entries that comprise the XRP Ledger's shared state data.
metadata:
indexPage: true
---
# Ledger Data Formats
Each [ledger version](../../../concepts/ledgers/index.md) in the XRP Ledger is made up of three parts:
- **[Ledger Header](ledger-header.md)**: Data about this ledger version itself.
- **[Transaction Set](../transactions/index.md)**: The transactions that were executed to create this ledger version.
- **[State Data](ledger-entry-types/index.md)**: A list of ledger entries, representing all accounts, settings, and balances as of this ledger version. (This is also called the "account state".)
## State Data
{% partial file="/_snippets/ledger-objects-intro.md" /%}
{% child-pages /%}

120
docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md Normal file
View File

@@ -0,0 +1,120 @@
---
html: accountroot.html
parent: ledger-entry-types.html
seo:
description: The settings, XRP balance, and other metadata for one account.
labels:
- Accounts
- XRP
---
# AccountRoot
[[Source]](https://github.com/XRPLF/rippled/blob/264280edd79b7f764536e02459f33f66a59c0531/src/ripple/protocol/impl/LedgerFormats.cpp#L36-L60 "Source")
An `AccountRoot` ledger entry type describes a single [account](../../../../concepts/accounts/accounts.md), its settings, and XRP balance.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"AccountTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D",
"Balance": "148446663",
"Domain": "6D64756F31332E636F6D",
"EmailHash": "98B4375E1D753E5B91627516F6D70977",
"Flags": 8388608,
"LedgerEntryType": "AccountRoot",
"MessageKey": "0000000000000000000000070000000300",
"OwnerCount": 3,
"PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D",
"PreviousTxnLgrSeq": 14091160,
"Sequence": 336,
"TransferRate": 1004999999,
"index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:------------------------------|:----------|:------------------|:----------|:-------------|
| `Account` | String | AccountID | Yes | The identifying (classic) address of this [account](../../../../concepts/accounts/accounts.md). |
| `AccountTxnID` | String | Hash256 | No | The identifying hash of the transaction most recently sent by this account. This field must be enabled to use the [`AccountTxnID` transaction field](../../transactions/common-fields.md#accounttxnid). To enable it, send an [AccountSet transaction with the `asfAccountTxnID` flag enabled](../../transactions/types/accountset.md#accountset-flags). |
| `AMMID` | String | Hash256 | No | _(Requires the [AMM amendment][] {% not-enabled /%})_ The ledger entry ID of the corresponding AMM ledger entry. Set during account creation; cannot be modified. If present, indicates that this is a special AMM AccountRoot; always omitted on non-AMM accounts. |
| `Balance` | String | Amount | No | The account's current [XRP balance in drops][XRP, in drops], represented as a string. |
| `BurnedNFTokens` | Number | UInt32 | No | How many total of this account's issued [non-fungible tokens](../../../../concepts/tokens/nfts/index.md) have been burned. This number is always equal or less than `MintedNFTokens`. |
| `Domain` | String | Blob | No | A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. [Cannot be more than 256 bytes in length.](https://github.com/xrplf/rippled/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
| `EmailHash` | String | Hash128 | No | The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). |
| `FirstNFTokenSequence` | Number | UInt32 | No | The account's [Sequence Number][] at the time it minted its first [non-fungible-token](../../../../concepts/tokens/nfts/index.md). _(Added by the [fixNFTokenRemint amendment][] {% not-enabled /%})_ |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0061`, mapped to the string `AccountRoot`, indicates that this is an AccountRoot object. |
| `MessageKey` | String | Blob | No | A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. Must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. |
| `MintedNFTokens` | Number | UInt32 | No | How many total [non-fungible tokens](../../../../concepts/tokens/nfts/index.md) have been minted by and on behalf of this account. _(Added by the [NonFungibleTokensV1_1 amendment][])_ |
| `NFTokenMinter` | String | AccountID | No | Another account that can mint [non-fungible tokens](../../../../concepts/tokens/nfts/index.md) on behalf of this account. _(Added by the [NonFungibleTokensV1_1 amendment][])_ |
| `OwnerCount` | Number | UInt32 | Yes | The number of objects this account owns in the ledger, which contributes to its owner reserve. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes |The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `RegularKey` | String | AccountID | No | The address of a [key pair](../../../../concepts/accounts/cryptographic-keys.md) that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
| `Sequence` | Number | UInt32 | Yes | The [sequence number](../../data-types/basic-data-types.md#account-sequence) of the next valid transaction for this account. |
| `TicketCount` | Number | UInt32 | No | How many [Tickets](../../../../concepts/accounts/tickets.md) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. _(Added by the [TicketBatch amendment][].)_ |
| `TickSize` | Number | UInt8 | No | How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Added by the [TickSize amendment][].)_ |
| `TransferRate` | Number | UInt32 | No | A [transfer fee](../../../../concepts/tokens/transfer-fees.md) to charge other users for sending currency issued by this account to each other. |
| `WalletLocator` | String | Hash256 | No | An arbitrary 256-bit value that users can set. |
| `WalletSize` | Number | UInt32 | No | Unused. (The code supports this field but there is no way to set it.) |
## Special AMM AccountRoot Entries
_(Requires the [AMM amendment][] {% not-enabled /%})_
Automated Market Makers use an AccountRoot ledger entry to issue their LP Tokens and hold the assets in the AMM pool, and an [AMM ledger entry](amm.md) for tracking some of the details of the AMM. The address of an AMM's AccountRoot is randomized so that users cannot identify and fund the address in advance of the AMM being created. Unlike normal accounts, AMM AccountRoot objects are created with the following settings:
- `lsfDisableMaster` **enabled** and no means of authorizing transactions. This ensures no one can control the account directly, and it cannot send transactions.
- `lsfDepositAuth` **enabled** and no accounts preauthorized. This ensures that the only way to add money to the AMM Account is using the [AMMDeposit transaction][].
- `lsfDefaultRipple` **enabled**. This ensures that users can send and trade the AMM's LP Tokens among themselves.
In addition, the following special rules apply to an AMM's AccountRoot entry:
- It is not subject to the [reserve requirement](../../../../concepts/accounts/reserves.md). It can hold XRP only if XRP is one of the two assets in the AMM's pool.
- It cannot be the destination of Checks, Escrows, or Payment Channels. Any transactions that would create such entries instead fail with the result code `tecNO_PERMISSION`.
- Users cannot create trust lines to it for anything other than the AMM's LP Tokens. Transactions that would create such trust lines instead fail with result code `tecNO_PERMISSION`. (The AMM does have two trust lines to hold the tokens in its pool, or one trust line if the other asset in its pool is XRP.)
- If the [Clawback amendment][] is also enabled, the issuer cannot clawback funds from an AMM.
Other than those exceptions, these accounts are like ordinary accounts; the LP Tokens they issue behave like other [tokens](https://xrpl.org/tokens.html) except that those tokens can also be used in AMM-related transactions. You can check an AMM's balances and the history of transactions that affected it the same way you would with a regular account.
## AccountRoot Flags
Many AccountRoot flags correspond to options you can change with an [AccountSet transaction][]. However, the bit values used in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with **`lsf`**.
AccountRoot objects can have the following flags combined in the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Corresponding [AccountSet Flag](../../transactions/types/accountset.md#accountset-flags) | Description |
|-----------------------------------|--------------|-------------------|-----------------------------------|----|
| `lsfAllowTrustLineClawback` | `0x80000000` | 2147483648 | `asfAllowTrustLineClawback` | Enable [Clawback](../../../../concepts/tokens/fungible-tokens/clawing-back-tokens.md) for this account. _(Requires the [Clawback amendment][].)_ |
| `lsfDefaultRipple` | `0x00800000` | 8388608 | `asfDefaultRipple` | Enable [rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. |
| `lsfDepositAuth` | `0x01000000` | 16777216 | `asfDepositAuth` | This account has [DepositAuth](../../../../concepts/accounts/depositauth.md) enabled, meaning it can only receive funds from transactions it sends, and from [preauthorized](../../../../concepts/accounts/depositauth.md#preauthorization) accounts. _(Added by the [DepositAuth amendment][])_ |
| `lsfDisableMaster` | `0x00100000` | 1048576 | `asfDisableMaster` | Disallows use of the master key to sign transactions for this account. |
| `lsfDisallowIncomingCheck` | `0x08000000` | 134217728 | `asfDisallowIncomingCheck` | This account blocks incoming Checks. _(Added by the [DisallowIncoming amendment][].)_ |
| `lsfDisallowIncomingNFTokenOffer` | `0x04000000` | 67108864 | `asfDisallowIncomingNFTokenOffer` | This account blocks incoming NFTokenOffers. _(Added by the [DisallowIncoming amendment][].)_ |
| `lsfDisallowIncomingPayChan` | `0x10000000` | 268435456 | `asfDisallowIncomingPayChan` | This account blocks incoming Payment Channels. _(Added by the [DisallowIncoming amendment][].)_ |
| `lsfDisallowIncomingTrustline` | `0x20000000` | 536870912 | `asfDisallowIncomingTrustline` | This account blocks incoming trust lines. _(Added by the [DisallowIncoming amendment][].)_ |
| `lsfDisallowXRP` | `0x00080000` | 524288 | `asfDisallowXRP` | Client applications should not send XRP to this account. (Advisory; not enforced by the protocol.) |
| `lsfGlobalFreeze` | `0x00400000` | 4194304 | `asfGlobalFreeze` | All assets issued by this account are frozen. |
| `lsfNoFreeze` | `0x00200000` | 2097152 | `asfNoFreeze` | This account cannot freeze trust lines connected to it. Once enabled, cannot be disabled. |
| `lsfPasswordSpent` | `0x00010000` | 65536 | (None) | This account has used its free SetRegularKey transaction. |
| `lsfRequireAuth` | `0x00040000` | 262144 | `asfRequireAuth` | This account must individually approve other users for those users to hold this account's tokens. |
| `lsfRequireDestTag` | `0x00020000` | 131072 | `asfRequireDest` | Requires incoming payments to specify a Destination Tag. |
## {% $frontmatter.seo.title %} Reserve
The [reserve](../../../../concepts/accounts/reserves.md) for an AccountRoot entry is the base reserve, currently {% $env.PUBLIC_BASE_RESERVE %}, except in the case of a special AMM AccountRoot.
This XRP cannot be sent to others but it can be burned as part of the [transaction cost][].
## {% $frontmatter.seo.title %} ID Format
The ID of an AccountRoot entry is the [SHA-512Half][] of the following values, concatenated in order:
* The Account space key (`0x0061`)
* The AccountID of the account
{% raw-partial file="/_snippets/common-links.md" /%}

80
docs/references/protocol/ledger-data/ledger-entry-types/amendments.md Normal file
View File

@@ -0,0 +1,80 @@
---
html: amendments-object.html #amendments.html is taken by the concept page
parent: ledger-entry-types.html
seo:
description: Singleton ledger entry with status of enabled and pending amendments.
labels:
- Blockchain
---
# Amendments
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L138-L144 "Source")
The `Amendments` ledger entry type contains a list of [Amendments](../../../../concepts/networks-and-servers/amendments.md) that are currently active. Each ledger version contains **at most one** `Amendments` entry.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Majorities": [
{
"Majority": {
"Amendment": "1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146",
"CloseTime": 535589001
}
}
],
"Amendments": [
"42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE",
"4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373",
"6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC",
"740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11"
],
"Flags": 0,
"LedgerEntryType": "Amendments",
"index": "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), the {% code-page-name /%} ledger entry has the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|-------------------|-----------|-------------------|-----------|-------------|
| `Amendments` | Array | Vector256 | No | Array of 256-bit [amendment IDs](../../../../concepts/networks-and-servers/amendments.md) for all currently enabled amendments. If omitted, there are no enabled amendments. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Amendments` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0066`, mapped to the string `Amendments`, indicates that this object describes the status of amendments to the XRP Ledger. |
| `Majorities` | Array | STArray | No | Array of objects describing the status of amendments that have majority support but are not yet enabled. If omitted, there are no pending amendments with majority support. |
Each member of the `Majorities` field, if it is present, is an object with one field, `Majority`, whose contents are a nested object with the following fields:
| Name | JSON Type | [Internal Type][] | Description |
|-------------------|-----------|-------------------|-------------|
| `Amendment` | String | Hash256 | The Amendment ID of the pending amendment. |
| `CloseTime` | Number | UInt32 | The [`close_time` field](../ledger-header.md) of the ledger version where this amendment most recently gained a majority. |
In the [amendment process](../../../../concepts/networks-and-servers/amendments.md#amendment-process), a consensus of validators adds a new amendment to the `Majorities` field using an [EnableAmendment][] pseudo-transaction with the `tfGotMajority` flag when 80% or more of validators support it. If support for a pending amendment goes below 80%, an [EnableAmendment][] pseudo-transaction with the `tfLostMajority` flag removes the amendment from the `Majorities` array. If an amendment remains in the `Majorities` field for at least 2 weeks, an [EnableAmendment][] pseudo-transaction with no flags removes it from `Majorities` and permanently adds it to the `Amendments` field.
**Note:** Technically, all transactions in a ledger are processed based on which amendments are enabled in the ledger version immediately before it. While applying transactions to a ledger version where an amendment becomes enabled, the rules don't change mid-ledger. After the ledger is closed, the next ledger uses the new rules as defined by any new amendments that applied.
## {% $frontmatter.seo.title %} Flags
There are no flags defined for the {% code-page-name /%} entry.
## {% $frontmatter.seo.title %} Reserve
The {% code-page-name /%} entry does not require a reserve.
## {% $frontmatter.seo.title %} ID Format
The ID of the `Amendments` entry is the hash of the `Amendments` space key (`0x0066`) only. This means that the ID is always:
```
7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4
```
(Don't mix up the ID of the `Amendments` ledger entry type with the Amendment ID of an individual amendment.)
{% raw-partial file="/_snippets/common-links.md" /%}

130
docs/references/protocol/ledger-data/ledger-entry-types/amm.md Normal file
View File

@@ -0,0 +1,130 @@
---
html: amm.html
parent: ledger-entry-types.html
seo:
description: The definition and details of an Automated Market Maker (AMM) instance.
labels:
- AMM
status: not_enabled
---
# AMM
[[Source]](https://github.com/XRPLF/rippled/blob/89780c8e4fd4d140fcb912cf2d0c01c1b260539e/src/ripple/protocol/impl/LedgerFormats.cpp#L272-L284 "Source")
_(Requires the [AMM amendment][] {% not-enabled /%})_
An `AMM` ledger entry describes a single [Automated Market Maker](../../../../concepts/tokens/decentralized-exchange/automated-market-makers.md) (AMM) instance. This is always paired with a [special AccountRoot entry](accountroot.md#special-amm-accountroot-entries).
## Example AMM JSON
```json
{
"Account" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"Asset" : {
"currency" : "XRP"
},
"Asset2" : {
"currency" : "TST",
"issuer" : "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
},
"AuctionSlot" : {
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
"AuthAccounts" : [
{
"AuthAccount" : {
"Account" : "rMKXGCbJ5d8LbrqthdG46q3f969MVK2Qeg"
}
},
{
"AuthAccount" : {
"Account" : "rBepJuTLFJt3WmtLXYAxSjtBWAeQxVbncv"
}
}
],
"DiscountedFee" : 60,
"Expiration" : 721870180,
"Price" : {
"currency" : "039C99CD9AB0B70B32ECDA51EAAE471625608EA2",
"issuer" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"value" : "0.8696263565463045"
}
},
"Flags" : 0,
"LPTokenBalance" : {
"currency" : "039C99CD9AB0B70B32ECDA51EAAE471625608EA2",
"issuer" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"value" : "71150.53584131501"
},
"TradingFee" : 600,
"VoteSlots" : [
{
"VoteEntry" : {
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
"TradingFee" : 600,
"VoteWeight" : 100000
}
}
]
}
```
## AMM Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:-----------------|:--------------------|:------------------|:----------|--------------|
| `Asset` | Object | STIssue | Yes | The definition for one of the two assets this AMM holds. In JSON, this is an object with `currency` and `issuer` fields. |
| `Asset2` | Object | STIssue | Yes | The definition for the other asset this AMM holds. In JSON, this is an object with `currency` and `issuer` fields. |
| `Account` | String | AccountID | Yes | The address of the [special account](accountroot.md#special-amm-accountroot-entries) that holds this AMM's assets. |
| `AuctionSlot` | Object | STObject | No | Details of the current owner of the auction slot, as an [Auction Slot object](#auction-slot-object). |
| `LPTokenBalance` | [Currency Amount][] | Amount | Yes | The total outstanding balance of liquidity provider tokens from this AMM instance. The holders of these tokens can vote on the AMM's trading fee in proportion to their holdings, or redeem the tokens for a share of the AMM's assets which grows with the trading fees collected. |
| `TradingFee` | Number | UInt16 | Yes | The percentage fee to be charged for trades against this AMM instance, in units of 1/100,000. The maximum value is 1000, for a 1% fee. |
| `VoteSlots` | Array | STArray | No | A list of vote objects, representing votes on the pool's trading fee. |
### Auction Slot Object
The `AuctionSlot` field contains an object with the following nested fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:----------------|:--------------------|:------------------|:----------|:--|
| `Account` | String - Address | AccountID | Yes | The current owner of this auction slot. |
| `AuthAccounts` | Array | STArray | No | A list of at most 4 additional accounts that are authorized to trade at the discounted fee for this AMM instance. |
| `DiscountedFee` | String | UInt32 | Yes | The trading fee to be charged to the auction owner, in the same format as `TradingFee`. Normally, this is 1/10 of the normal fee for this AMM. |
| `Price` | [Currency Amount][] | Amount | Yes | The amount the auction owner paid to win this slot, in LP Tokens. |
| `Expiration` | String | UInt32 | Yes | The time when this slot expires, in [seconds since the Ripple Epoch][]. |
## VoteEntry Object
The `VoteSlots` field contains an array of `VoteEntry` objects with the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:-----------------|:--------------------|:------------------|:----------|--------------|
| `Account` | String - Address | AccountID | Yes | The account that cast the vote. |
| `TradingFee` | Number | UInt16 | Yes | The proposed trading fee, in units of 1/100,000; a value of 1 is equivalent to 0.001%. The maximum value is 1000, indicating a 1% fee. |
| `VoteWeight` | Number | UInt32 | Yes | The weight of the vote, in units of 1/100,000. For example, a value of 1234 means this vote counts as 1.234% of the weighted total vote. The weight is determined by the percentage of this AMM's LP Tokens the account owns. The maximum value is 100000. |
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries do not require a reserve.
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## AMM ID Format
The ID of an `AMM` entry is the [SHA-512Half][] of the following values, concatenated in order:
1. The `AMM` space key (`0x0041`)
0. The AccountID of the first asset's issuer.
0. The 160-bit currency code of the first token.
0. The AccountID of the second asset's issuer.
0. The 160-bit currency code of the second token.
For XRP, use all 0's for both the token and the issuer.
{% raw-partial file="/_snippets/common-links.md" /%}

72
docs/references/protocol/ledger-data/ledger-entry-types/bridge.md Normal file
View File

@@ -0,0 +1,72 @@
---
html: bridge.html
parent: ledger-entry-types.html
seo:
description: A `bridge` object represents a single cross-chain bridge that connects and enables value to move efficiently between two blockchains.
labels:
- Interoperability
status: not_enabled
---
# Bridge
_(Requires the [XChainBridge amendment][] {% not-enabled /%})_
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L286-L300 "Source")
The `Bridge` ledger entry represents a single cross-chain bridge that connects the XRP Ledger with another blockchain, such as its sidechain, and enables value in the form of XRP and other tokens (IOUs) to move efficiently between the two blockchains.
## Example Bridge JSON
```json
{
"Account": "r3nCVTbZGGYoWvZ58BcxDmiMUU7ChMa1eC",
"Flags": 0,
"LedgerEntryType": "Bridge",
"MinAccountCreateAmount": "2000000000",
"OwnerNode": "0",
"PreviousTxnID": "67A8A1B36C1B97BE3AAB6B19CB3A3069034877DE917FD1A71919EAE7548E5636",
"PreviousTxnLgrSeq": 102,
"SignatureReward": "204",
"XChainAccountClaimCount": "0",
"XChainAccountCreateCount": "0",
"XChainBridge": {
"IssuingChainDoor": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"IssuingChainIssue": {
"currency": "XRP"
},
"LockingChainDoor": "r3nCVTbZGGYoWvZ58BcxDmiMUU7ChMa1eC",
"LockingChainIssue": {
"currency": "XRP"
}
},
"XChainClaimID": "1",
"index": "9F2C9E23343852036AFD323025A8506018ABF9D4DBAA746D61BF1CFB5C297D10"
}
```
## Bridge Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field | JSON Type | Internal Type | Required? | Description |
|:---------------------------|:--------------------|:------------------|:----------|:------------|
| `Account` | String | Account | Yes | The account that submitted the `XChainCreateBridge` transaction on the blockchain. |
| `MinAccountCreateAmount` | [Currency Amount][] | Amount | No | The minimum amount, in XRP, required for an `XChainAccountCreateCommit` transaction. If this isn't present, the `XChainAccountCreateCommit` transaction will fail. This field can only be present on XRP-XRP bridges. |
| `SignatureReward` | [Currency Amount][] | Amount | Yes | The total amount, in XRP, to be rewarded for providing a signature for cross-chain transfer or for signing for the cross-chain reward. This amount will be split among the signers. |
| `XChainAccountClaimCount` | Number | UInt64 | Yes | A counter used to order the execution of account create transactions. It is incremented every time a `XChainAccountCreateCommit` transaction is "claimed" on the destination chain. When the "claim" transaction is run on the destination chain, the `XChainAccountClaimCount` must match the value that the `XChainAccountCreateCount` had at the time the `XChainAccountClaimCount` was run on the source chain. This orders the claims so that they run in the same order that the `XChainAccountCreateCommit` transactions ran on the source chain, to prevent transaction replay. |
| `XChainAccountCreateCount` | Number | UInt64 | Yes | A counter used to order the execution of account create transactions. It is incremented every time a successful `XChainAccountCreateCommit` transaction is run for the source chain. |
| `XChainBridge` | XChainBridge | XChain_Bridge | Yes | The door accounts and assets of the bridge this object correlates to. |
| `XChainClaimID` | Number | UInt64 | Yes | The value of the next `XChainClaimID` to be created. |
### XChainBridge Fields
| Field | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:----------------|
| `IssuingChainDoor` | String | Account | Yes | The door account on the issuing chain. For an XRP-XRP bridge, this must be the genesis account (the account that is created when the network is first started, which contains all of the XRP). |
| `IssuingChainIssue` | Issue | Issue | Yes | The asset that is minted and burned on the issuing chain. For an IOU-IOU bridge, the issuer of the asset must be the door account on the issuing chain, to avoid supply issues. |
| `LockingChainDoor` | String | Account | Yes | The door account on the locking chain. |
| `LockingChainIssue` | Issue | Issue | Yes | The asset that is locked and unlocked on the locking chain. |
{% raw-partial file="/_snippets/common-links.md" /%}

80
docs/references/protocol/ledger-data/ledger-entry-types/check.md Normal file
View File

@@ -0,0 +1,80 @@
---
html: check.html
parent: ledger-entry-types.html
seo:
description: A check that can be redeemed for money by its destination.
labels:
- Checks
---
# Check
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170 "Source")
_(Added by the [Checks amendment][].)_
A `Check` entry describes a [check](../../../../concepts/payment-types/checks.md), similar to a paper personal check, which can be cashed by its destination to get money from its sender.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
"Destination": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
"DestinationNode": "0000000000000000",
"DestinationTag": 1,
"Expiration": 570113521,
"Flags": 0,
"InvoiceID": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
"LedgerEntryType": "Check",
"OwnerNode": "0000000000000000",
"PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
"PreviousTxnLgrSeq": 6,
"SendMax": "100000000",
"Sequence": 2,
"index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:-----------------|:------------------|:----------|:----------------|
| `Account` | String | Account | Yes | The sender of the Check. Cashing the Check debits this address's balance. |
| `Destination` | String | Account | Yes | The intended recipient of the Check. Only this address can cash the Check, using a [CheckCash transaction][]. |
| `DestinationNode` | String | UInt64 | No | A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. |
| `DestinationTag` | Number | UInt32 | No | An arbitrary tag to further specify the destination for this Check, such as a hosted recipient at the destination address. |
| `Expiration` | Number | UInt32 | No | Indicates the time after which this Check is considered expired. See [Specifying Time][] for details. |
| `InvoiceID` | String | Hash256 | No | Arbitrary 256-bit hash provided by the sender as a specific reason or identifier for this Check. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0043`, mapped to the string `Check`, indicates that this object is a Check object. |
| `OwnerNode` | String | UInt64 | Yes | 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 | Yes | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes |The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `SendMax` | String or Object | Amount | Yes | The maximum amount of currency this Check can debit the sender. If the Check is successfully cashed, the destination is credited in the same currency for up to this amount. |
| `Sequence` | Number | UInt32 | Yes | The sequence number of the [CheckCreate transaction][] that created this check. |
| `SourceTag` | Number | UInt32 | No | An arbitrary tag to further specify the source for this Check, such as a hosted recipient at the sender's address. |
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries count as one item towards the owner reserve of the sender of the Check as long as the entry is in the ledger. This reserve is freed up when the check is cashed or canceled.
## Check ID Format
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L193-L200 "Source")
The ID of a `Check` entry is the [SHA-512Half][] of the following values, concatenated in order:
* The Check space key (`0x0043`)
* The AccountID of the sender of the [CheckCreate transaction][] that created the `Check`
* The `Sequence` number of the [CheckCreate transaction][] that created the `Check`.
If the CheckCreate transaction used a [Ticket](../../../../concepts/accounts/tickets.md), use the `TicketSequence` value instead.
See the tutorial showing how to [Send a Check](../../../../tutorials/use-specialized-payment-types/use-checks/send-a-check.md).
{% raw-partial file="/_snippets/common-links.md" /%}

61
docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth.md Normal file
View File

@@ -0,0 +1,61 @@
---
html: depositpreauth-object.html #depositpreauth.html is taken by the tx type
parent: ledger-entry-types.html
seo:
description: A record of preauthorization for sending payments to an account that requires authorization.
labels:
- Security
---
# DepositPreauth
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L172-L178 "Source")
A `DepositPreauth` entry tracks a preauthorization from one account to another. [DepositPreauth transactions][] create these entries.
This has no effect on processing of transactions unless the account that provided the preauthorization requires [Deposit Authorization](../../../../concepts/accounts/depositauth.md). In that case, the account that was preauthorized can send payments and other transactions directly to the account that provided the preauthorization. Preauthorizations are one-directional, and have no effect on payments going the opposite direction.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"LedgerEntryType": "DepositPreauth",
"Account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
"Authorize": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"Flags": 0,
"OwnerNode": "0000000000000000",
"PreviousTxnID": "3E8964D5A86B3CD6B9ECB33310D4E073D64C865A5B866200AD2B7E29F8326702",
"PreviousTxnLgrSeq": 7,
"index": "4A255038CC3ADCC1A9C91509279B59908251728D0DAADB248FFE297D0F7E068C"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:-----------------|:------------------|:----------|:----------------|
| `Account` | String | Account | Yes | The account that granted the preauthorization. (The destination of the preauthorized payments.) |
| `Authorize` | String | Account | Yes | The account that received the preauthorization. (The sender of the preauthorized payments.) |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0070`, mapped to the string `DepositPreauth`, indicates that this is a DepositPreauth object. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the sender's owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries count as one item towards the owner reserve of the account that granted preauthorization, as long as the entry is in the ledger. Unauthorizing the counterparty frees up the reserve.
## DepositPreauth ID Format
The ID of a `DepositPreauth` object is the [SHA-512Half][] of the following values, concatenated in order:
* The DepositPreauth space key (`0x0070`)
* The AccountID of the owner of this object (the sender of the [DepositPreauth transaction][] that created this object; in other words, the one that granted the preauthorization)
* The AccountID of the preauthorized account (the `Authorized` field of the [DepositPreauth transaction][] that created this object; in other words, the one that received the preauthorization)
{% raw-partial file="/_snippets/common-links.md" /%}

68
docs/references/protocol/ledger-data/ledger-entry-types/did.md Normal file
View File

@@ -0,0 +1,68 @@
---
html: did.html
parent: ledger-entry-types.html
seo:
description: The definition and details of a Decentralized Identifier (DID).
labels:
- DID
status: not_enabled
---
# DID
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L330-L341 "Source")
_(Requires the [DID amendment][] {% not-enabled /%})_
A `DID` ledger entry holds references to, or data associated with, a single [DID](../../../../concepts/accounts/decentralized-identifiers.md).
## Example DID JSON
```json
{
"Account": "rpfqJrXg5uidNo2ZsRhRY6TiF1cvYmV9Fg",
"DIDDocument": "646F63",
"Data": "617474657374",
"Flags": 0,
"LedgerEntryType": "DID",
"OwnerNode": "0",
"PreviousTxnID": "A4C15DA185E6092DF5954FF62A1446220C61A5F60F0D93B4B09F708778E41120",
"PreviousTxnLgrSeq": 4,
"URI": "6469645F6578616D706C65",
"index": "46813BE38B798B3752CA590D44E7FEADB17485649074403AD1761A2835CE91FF"
}
```
## DID Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|--------------|
| `Account` | String | AccountID | Yes | The account that controls the DID. |
| `DIDDocument` | String | Blob | No | The W3C standard DID document associated with the DID. The `DIDDocument` field isn't checked for validity and is limited to a maximum length of 256 bytes. |
| `Data` | String | Blob | No | The public attestations of identity credentials associated with the DID. The `Data` field isn't checked for validity and is limited to a maximum length of 256 bytes. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0049`, mapped to the string `DID`, indicates that this object is a DID object. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the sender'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 object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The index of the ledger that contains the transaction that most recently modified this object. |
| `URI` | String | Blob | No | The Universal Resource Identifier that points to the corresponding DID document or the data associated with the DID. This field can be an HTTP(S) URL or IPFS URI. This field isn't checked for validity and is limited to a maximum length of 256 bytes. |
## {% $frontmatter.seo.title %} Reserve
The account that creates the {% code-page-name /%} object incurs one owner reserve.
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## DID ID Format
The ID of a `DID` entry is the [SHA-512Half][] of the following values, concatenated in order:
1. The `DID` space key (`0x0049`).
2. The AccountID that controls the DID.
{% raw-partial file="/_snippets/common-links.md" /%}

118
docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md Normal file
View File

@@ -0,0 +1,118 @@
---
html: directorynode.html
parent: ledger-entry-types.html
seo:
description: Contains links to other objects.
labels:
- Data Retention
- Decentralized Exchange
---
# DirectoryNode
[[Source]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
The `DirectoryNode` ledger entry type provides a list of links to other entries in the ledger's state data. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode entries each containing up to 32 [IDs of other entries](../common-fields.md). The first DirectoryNode entry is called the root of the directory, and all entries other than the root can be added or deleted as necessary.
There are two kinds of Directories:
* **Owner directories** list other entries owned by an account, such as [`RippleState` (trust line)](ripplestate.md) or [`Offer`](offer.md) entries.
* **Offer directories** list the offers available in the [decentralized exchange](../../../../concepts/tokens/decentralized-exchange/index.md). A single Offer directory contains all the offers that have the same exchange rate for the same token (currency code and issuer).
## Example {% $frontmatter.seo.title %} JSON
{% tabs %}
{% tab label="Offer Directory" %}
```json
{
"ExchangeRate": "4F069BA8FF484000",
"Flags": 0,
"Indexes": [
"AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD"
],
"LedgerEntryType": "DirectoryNode",
"RootIndex": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000",
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
"TakerPaysCurrency": "0000000000000000000000004A50590000000000",
"TakerPaysIssuer": "5BBC0F22F61D9224A110650CFE21CC0C4BE13098",
"index": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000"
}
```
{% /tab %}
{% tab label="Owner Directory" %}
```json
{
"Flags": 0,
"Indexes": [
"AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD",
"E83BBB58949A8303DF07172B16FB8EFBA66B9191F3836EC27A4568ED5997BAC5"
],
"LedgerEntryType": "DirectoryNode",
"Owner": "rpR95n1iFkTqpoy1e878f4Z1pVHVtWKMNQ",
"RootIndex": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94",
"index": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"
}
```
{% /tab %}
{% /tabs %}
## {% $frontmatter.seo.title %} Fields
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:------------|
| `ExchangeRate` | String | UInt64 | No | (Offer Directories only) **DEPRECATED**. Do not use. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `DirectoryNode` objects. The value is always `0`. |
| `Indexes` | Array | Vector256 | Yes | The contents of this Directory: an array of IDs of other objects. |
| `IndexNext` | Number | UInt64 | No | If this Directory consists of multiple pages, this ID links to the next object in the chain, wrapping around at the end. |
| `IndexPrevious` | Number | UInt64 | No | If this Directory consists of multiple pages, this ID links to the previous object in the chain, wrapping around at the beginning. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0064`, mapped to the string `DirectoryNode`, indicates that this object is part of a Directory. |
| `Owner` | String | AccountID | No | (Owner Directories only) The address of the account that owns the objects in this directory. |
| `RootIndex` | String | Hash256 | Yes | The ID of root object for this directory. |
| `TakerGetsCurrency` | String | Hash160 | No | (Offer Directories only) The currency code of the `TakerGets` amount from the offers in this directory. |
| `TakerGetsIssuer` | String | Hash160 | No | (Offer Directories only) The issuer of the `TakerGets` amount from the offers in this directory. |
| `TakerPaysCurrency` | String | Hash160 | No |(Offer Directories only) The currency code of the `TakerPays` amount from the offers in this directory. |
| `TakerPaysIssuer` | String | Hash160 | No | (Offer Directories only) The issuer of the `TakerPays` amount from the offers in this directory. |
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries do not require a reserve.
## Directory ID Formats
There are three different formulas for creating the ID of a DirectoryNode, depending on which of the following the DirectoryNode represents:
* The first page (also called the root) of an Owner Directory
* The first page of an Offer Directory
* Later pages of either type
**The first page of an Owner Directory** has an ID that is the [SHA-512Half][] of the following values, concatenated in order:
* The Owner Directory space key (`0x004F`)
* The AccountID from the `Owner` field.
**The first page of an Offer Directory** has a special ID: the higher 192 bits define the order book, and the remaining 64 bits define the exchange rate of the offers in that directory. (The ID is big-endian, so the book is in the more significant bits, which come first, and the quality is in the less significant bits which come last.) This provides a way to iterate through an order book from best offers to worst. Specifically: the first 192 bits are the first 192 bits of the [SHA-512Half][] of the following values, concatenated in order:
* The Book Directory space key (`0x0042`)
* The 160-bit currency code from the `TakerPaysCurrency`
* The 160-bit currency code from the `TakerGetsCurrency`
* The AccountID from the `TakerPaysIssuer`
* The AccountID from the `TakerGetsIssuer`
The lower 64 bits of an Offer Directory's ID represent the `TakerPays` amount divided by `TakerGets` amount from the offer(s) in that directory as a 64-bit number in the XRP Ledger's internal amount format.
**If the DirectoryNode is not the first page in the Directory** (regardless of whether it is an Owner Directory or an Offer Directory), then it has an ID that is the [SHA-512Half][] of the following values, concatenated in order:
* The DirectoryNode space key (`0x0064`)
* The ID of the root DirectoryNode
* The page number of this object. (Since 0 is the root DirectoryNode, this value is an integer 1 or higher.)
{% raw-partial file="/_snippets/common-links.md" /%}

78
docs/references/protocol/ledger-data/ledger-entry-types/escrow.md Normal file
View File

@@ -0,0 +1,78 @@
---
html: escrow-object.html #escrow.html is taken by the concept page
parent: ledger-entry-types.html
seo:
description: Contains XRP held for a conditional payment.
labels:
- Escrow
---
# Escrow
[[Source]](https://github.com/XRPLF/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101 "Source")
_(Added by the [Escrow amendment][].)_
An `Escrow` ledger entry represents an [escrow](../../../../concepts/payment-types/escrow.md), which holds XRP until specific conditions are met.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Amount": "10000",
"CancelAfter": 545440232,
"Condition": "A0258020A82A88B2DF843A54F58772E4A3861866ECDB4157645DD9AE528C1D3AEEDABAB6810120",
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"DestinationTag": 23480,
"FinishAfter": 545354132,
"Flags": 0,
"LedgerEntryType": "Escrow",
"OwnerNode": "0000000000000000",
"DestinationNode": "0000000000000000",
"PreviousTxnID": "C44F2EB84196B9AD820313DBEBA6316A15C9A2D35787579ED172B87A30131DA7",
"PreviousTxnLgrSeq": 28991004,
"SourceTag": 11747,
"index": "DC5F3851D8A1AB622F957761E5963BC5BD439D5C24AC6AD7AC4523F0640244AC"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:-----------------------|
| `Account` | String | AccountID | Yes | The address of the owner (sender) of this escrow. This is the account that provided the XRP, and gets it back if the escrow is canceled. |
| `Amount` | String | Amount | Yes | The amount of XRP, in drops, currently held in the escrow. |
| `CancelAfter` | Number | UInt32 | No | The escrow can be canceled if and only if this field is present _and_ the time it specifies has passed. Specifically, this is specified as [seconds since the Ripple Epoch][] and it "has passed" if it's earlier than the close time of the previous validated ledger. |
| `Condition` | String | Blob | No | A [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1), as hexadecimal. If present, the [EscrowFinish transaction][] must contain a fulfillment that satisfies this condition. |
| `Destination` | String | AccountID | Yes | The destination address where the XRP is paid if the escrow is successful. |
| `DestinationNode` | String | UInt64 | No | A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. Omitted on escrows created before enabling the [fix1523 amendment][]. |
| `DestinationTag` | Number | UInt32 | No | An arbitrary tag to further specify the destination for this escrow, such as a hosted recipient at the destination address. |
| `FinishAfter` | Number | UInt32 | No | The time, in [seconds since the Ripple Epoch][], after which this escrow can be finished. Any [EscrowFinish transaction][] before this time fails. (Specifically, this is compared with the close time of the previous validated ledger.) |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0075`, mapped to the string `Escrow`, indicates that this is an `Escrow` entry. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the sender'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 [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. |
| `SourceTag` | Number | UInt32 | No | An arbitrary tag to further specify the source for this escrow, such as a hosted recipient at the owner's address. |
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries count as one item towards the sender's owner reserve as long as the entry is in the ledger. Finishing or canceling the escrow frees up this reserve.
## Escrow ID Format
The ID of an `Escrow` entry is the [SHA-512Half][] of the following values, concatenated in order:
* The Escrow space key (`0x0075`)
* The AccountID of the sender of the [EscrowCreate transaction][] that created the `Escrow` entry
* The Sequence number of the [EscrowCreate transaction][] that created the `Escrow` entry
If the EscrowCreate transaction used a [Ticket](../../../../concepts/accounts/tickets.md), use the `TicketSequence` value instead.
{% raw-partial file="/_snippets/common-links.md" /%}

68
docs/references/protocol/ledger-data/ledger-entry-types/feesettings.md Normal file
View File

@@ -0,0 +1,68 @@
---
html: feesettings.html
parent: ledger-entry-types.html
seo:
description: Singleton object with consensus-approved base transaction cost and reserve requirements.
labels:
- Fees
---
# FeeSettings
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120 "Source")
The `FeeSettings` entry contains the current base [transaction cost](../../../../concepts/transactions/transaction-cost.md) and [reserve amounts](../../../../concepts/accounts/reserves.md) as determined by [fee voting](../../../../concepts/consensus-protocol/fee-voting.md). Each ledger version contains **at most one** `FeeSettings` entry.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"BaseFee": "000000000000000A",
"Flags": 0,
"LedgerEntryType": "FeeSettings",
"ReferenceFeeUnits": 10,
"ReserveBase": 20000000,
"ReserveIncrement": 5000000,
"index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), the {% code-page-name /%} ledger entry has the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:-----------------------|
| `BaseFee` | String | UInt64 | Yes | The [transaction cost](../../../../concepts/transactions/transaction-cost.md) of the "reference transaction" in drops of XRP as hexadecimal. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `FeeSettings` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. |
| `ReferenceFeeUnits` | Number | UInt32 | Yes | The `BaseFee` translated into "fee units". |
| `ReserveBase` | Number | UInt32 | Yes | The [base reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. |
| `ReserveIncrement` | Number | UInt32 | Yes | The incremental [owner reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
**Warning:** The JSON format for this ledger entry type is unusual. The `BaseFee`, `ReserveBase`, and `ReserveIncrement` indicate drops of XRP but ***not*** in the usual format for [specifying XRP][Currency Amount].
If the _[XRPFees amendment][]_ is enabled, the `FeeSettings` object has these fields instead:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:------------------------|:----------|:------------------|:----------|:-----------------------|
| `BaseFeeDrops` | String | Amount | Yes | The [transaction cost](../../../../concepts/transactions/transaction-cost.md) of the "reference transaction" in drops of XRP. |
| `Flags` | Number | UInt32 | Yes | A bitmap of boolean flags enabled for this object. Currently, the protocol defines no flags for `FeeSettings` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. |
| `ReserveBaseDrops` | String | Amount | Yes | The [base reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. |
| `ReserveIncrementDrops` | String | Amount | Yes | The incremental [owner reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
## {% $frontmatter.seo.title %} Flags
There are no flags defined for the {% code-page-name /%} entry.
## FeeSettings ID Format
The ID of the `FeeSettings` entry is the hash of the `FeeSettings` space key (`0x0065`) only. This means that the ID is always:
```
4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651
```
{% raw-partial file="/_snippets/common-links.md" /%}

12
docs/references/protocol/ledger-data/ledger-entry-types/index.md Normal file
View File

@@ -0,0 +1,12 @@
---
html: ledger-entry-types.html
parent: ledger-data-formats.html
metadata:
indexPage: true
---
# Ledger Entry Types
{% partial file="/_snippets/ledger-objects-intro.md" /%}
{% child-pages /%}

90
docs/references/protocol/ledger-data/ledger-entry-types/ledgerhashes.md Normal file
View File

@@ -0,0 +1,90 @@
---
html: ledgerhashes.html
parent: ledger-entry-types.html
seo:
description: Lists of prior ledger versions' hashes for history lookup.
labels:
- Blockchain
---
# LedgerHashes
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L104-L108 "Source")
(Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.)
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](../../../../concepts/transactions/index.md) or [pseudo-transaction](../../transactions/pseudo-transaction-types/pseudo-transaction-types.md).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains:
- Exactly one "recent history" `LedgerHashes` object
- A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, the XRP Ledger adds a new "previous history" object every 65536 ledger versions. <!-- STYLE_OVERRIDE: a number of -->
**Note:** As an exception, a new genesis ledger has no `LedgerHashes` objects at all, because it has no ledger history.
Example `LedgerHashes` object (trimmed for length):
```json
{
"LedgerEntryType": "LedgerHashes",
"Flags": 0,
"FirstLedgerSequence": 2,
"LastLedgerSequence": 33872029,
"Hashes": [
"D638208ADBD04CBB10DE7B645D3AB4BA31489379411A3A347151702B6401AA78",
"254D690864E418DDD9BCAC93F41B1F53B1AE693FC5FE667CE40205C322D1BE3B",
"A2B31D28905E2DEF926362822BC412B12ABF6942B73B72A32D46ED2ABB7ACCFA",
"AB4014846DF818A4B43D6B1686D0DE0644FE711577C5AB6F0B2A21CCEE280140",
"3383784E82A8BA45F4DD5EF4EE90A1B2D3B4571317DBAC37B859836ADDE644C1",
... (up to 256 ledger hashes) ...
],
"index": "B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:----------------------|:-----------------|:------------------|:----------|:------------|
| `FirstLedgerSequence` | Number | UInt32 | No | **DEPRECATED** Do not use. (The "recent hashes" object on Mainnet has the value `2` in this field as a result of an old software bug. That value gets carried forward as the "recent hashes" object is updated. New "previous history" objects do not have this field, nor do "recent hashes" objects in [parallel networks](../../../../concepts/networks-and-servers/parallel-networks.md) started with more recent versions of `rippled`.) |
| `Hashes` | Array of Strings | Vector256 | Yes | An array of up to 256 ledger hashes. The contents depend on which sub-type of `LedgerHashes` object this is. |
| `LastLedgerSequence` | Number | UInt32 | No | The [Ledger Index][] of the last entry in this object's `Hashes` array. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0068`, mapped to the string `LedgerHashes`, indicates that this object is a list of ledger hashes. |
## Recent History LedgerHashes
There is exactly one `LedgerHashes` object of the "recent history" sub-type in every ledger after the genesis ledger. This object contains the identifying hashes of the most recent 256 ledger versions (or fewer, if the ledger history has less than 256 ledgers total) in the `Hashes` array. Whenever a new ledger is closed, part of the process of closing it involves updating the "recent history" object with the hash of the previous ledger version this ledger version is derived from (also known as this ledger version's _parent ledger_). When there are more than 256 hashes, the oldest one is removed.
Using the "recent history" `LedgerHashes` object of a given ledger, you can get the hash of any ledger index within the 256 ledger versions before the given ledger version.
## Previous History LedgerHashes
The "previous history" `LedgerHashes` entries collectively contain the hash of every 256th ledger version (also called "flag ledgers") in the full history of the ledger. When the child of a flag ledger closes, the flag ledger's hash is added to the `Hashes` array of the newest "previous history" `LedgerHashes` object. Every 65536 ledgers, `rippled` creates a new `LedgerHashes` object, so that each "previous history" object has the hashes of 256 flag ledgers.
**Note:** The oldest "previous history" `LedgerHashes` object contains only 255 entries because the genesis ledger has ledger index 1, not 0.
The "previous history" `LedgerHashes` objects act as a [skip list](https://en.wikipedia.org/wiki/Skip_list) so you can get the hash of any historical flag ledger from its index. From there, you can use that flag ledger's "recent history" object to get the hash of any other ledger.
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## LedgerHashes ID Formats
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L26-L42)
There are two formats for `LedgerHashes` object IDs, depending on whether the object is a "recent history" sub-type or a "previous history" sub-type.
The **"recent history"** `LedgerHashes` object has an ID that is the [SHA-512Half][] of the `LedgerHashes` space key (`0x0073`). In other words, the "recent history" always has the ID `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`.
The **"previous history"** `LedgerHashes` objects have an ID that is the [SHA-512Half][] of the following values, concatenated in order:
- The `LedgerHashes` space key (`0x0073`)
- The 32-bit [Ledger Index][] of a flag ledger in the object's `Hashes` array, divided by 65536.
**Tip:** Dividing by 65536 keeps the most significant 16 bits, which are the same for all the flag ledgers listed in a "previous history" object, and only those ledgers. You can use this fact to look up the `LedgerHashes` object that contains the hash of any flag ledger.
{% raw-partial file="/_snippets/common-links.md" /%}

70
docs/references/protocol/ledger-data/ledger-entry-types/negativeunl.md Normal file
View File

@@ -0,0 +1,70 @@
---
html: negativeunl.html
parent: ledger-entry-types.html
seo:
description: List of validators currently believed to be offline.
labels:
- Blockchain
---
# NegativeUNL
_(Added by the [NegativeUNL amendment][].)_
The `NegativeUNL` ledger entry type contains the current status of the [Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md), a list of trusted validators currently believed to be offline.
Each ledger version contains **at most one** `NegativeUNL` entry. If no validators are currently disabled or scheduled to be disabled, there is no `NegativeUNL` entry.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"DisabledValidators": [
{
"DisabledValidator": {
"FirstLedgerSequence": 1609728,
"PublicKey": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE"
}
}
],
"Flags": 0,
"LedgerEntryType": "NegativeUNL",
"index": "2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), the {% code-page-name /%} ledger entry has the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:----------------------|:----------|:------------------|:----------|:---------------------|
| `DisabledValidators` | Array | Array | No | A list of `DisabledValidator` objects (see below), each representing a trusted validator that is currently disabled. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x004E`, mapped to the string `NegativeUNL`, indicates that this entry is the Negative UNL. |
| `ValidatorToDisable` | String | Blob | No | The public key of a trusted validator that is scheduled to be disabled in the next flag ledger. |
| `ValidatorToReEnable` | String | Blob | No | The public key of a trusted validator in the Negative UNL that is scheduled to be re-enabled in the next flag ledger. |
### DisabledValidator Objects
<!-- SPELLING_IGNORE: DisabledValidator -->
Each `DisabledValidator` object represents one disabled validator. In JSON, a `DisabledValidator` object has one field, `DisabledValidator`, which in turn contains another object with the following fields:
| Name | JSON Type | [Internal Type][] | Description |
|:----------------------|:----------|:------------------|:---------------------|
| `FirstLedgerSequence` | Number | UInt32 | The [ledger index][] when the validator was added to the Negative UNL. |
| `PublicKey` | String | Blob | The master public key of the validator, in hexadecimal. |
## {% $frontmatter.seo.title %} Flags
There are no flags defined for the {% code-page-name /%} entry.
## NegativeUNL ID Format
The ID of the `NegativeUNL` entry is the hash of the `NegativeUNL` space key (`0x004E`) only. This means that the ID is always:
```
2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244
```
{% raw-partial file="/_snippets/common-links.md" /%}

87
docs/references/protocol/ledger-data/ledger-entry-types/nftokenoffer.md Normal file
View File

@@ -0,0 +1,87 @@
---
html: nftokenoffer.html
parent: ledger-entry-types.html
seo:
description: Create offers to buy or sell NFTs.
labels:
- Non-fungible Tokens, NFTs
---
# NFTokenOffer
An `NFTokenOffer` entry represents an offer to buy, sell or transfer an [NFT](../../../../concepts/tokens/nfts/index.md).
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Amount": "1000000",
"Flags": 1,
"LedgerEntryType": "NFTokenOffer",
"NFTokenID": "00081B5825A08C22787716FA031B432EBBC1B101BB54875F0002D2A400000000",
"NFTokenOfferNode": "0",
"Owner": "rhRxL3MNvuKEjWjL7TBbZSDacb8PmzAd7m",
"OwnerNode": "17",
"PreviousTxnID": "BFA9BE27383FA315651E26FDE1FA30815C5A5D0544EE10EC33D3E92532993769",
"PreviousTxnLgrSeq": 75443565,
"index": "AEBABA4FAC212BF28E0F9A9C3788A47B085557EC5D1429E7A8266FB859C863B3"
}
```
### {% $frontmatter.seo.title %} Fields
| Name |JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:-----------------|:------------------|:------------|:-----------|
| `Amount` | [Currency Amount][] | AMOUNT | Yes | Amount expected or offered for the NFToken. If the token has the `lsfOnlyXRP` flag set, the amount must be specified in XRP. Sell offers that specify assets other than XRP must specify a non-zero amount. Sell offers that specify XRP can be 'free' (that is, the Amount field can be equal to `"0"`). |
| `Destination` | string | AccountID | No | The AccountID for which this offer is intended. If present, only that account can accept the offer. |
| `Expiration` | number | UInt32 | No | The time after which the offer is no longer active. The value is the number of seconds since the Ripple Epoch. |
| `LedgerEntryType` | string | UInt16 | Yes | The value `0x0037`, mapped to the string `NFTokenOffer`, indicates that this is an offer to trade a `NFToken`. |
| `NFTokenID` | string | Hash256 | Yes | The `NFTokenID` of the NFToken object referenced by this offer. |
| `NFTokenOfferNode` | string | UInt64 | No | Internal bookkeeping, indicating the page inside the token buy or sell offer directory, as appropriate, where this token is being tracked. This field allows the efficient deletion of offers. |
| `Owner` | string | AccountID | Yes | Owner of the account that is creating and owns the offer. Only the current Owner of an NFToken can create an offer to sell an NFToken, but any account can create an offer to buy an NFToken. |
| `OwnerNode` | string | UInt64 | No | Internal bookkeeping, indicating the page inside the owner directory where this token is being tracked. This field allows the efficient deletion of offers. |
| `PreviousTxnID` | string | Hash256 | Yes | Identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | number | UInt32 | Yes | Index of the ledger that contains the transaction that most recently modified this object. |
## {% $frontmatter.seo.title %} Flags
{% $frontmatter.seo.title %} entries can have the following flags combined in the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Description |
|------------------|--------------|---------------|-------------|
| `lsfSellNFToken` | `0x00000001` | 1 | If enabled, the offer is a sell offer. Otherwise, the offer is a buy offer. |
## NFTokenOffer Transactions
Unlike [Offers for fungible tokens](../../../../concepts/tokens/decentralized-exchange/offers.md), a `NFTokenOffer` is not stored in an order book and is never automatically matched or executed. A buyer must _explicitly_ choose to accept an `NFTokenOffer` that offers to sell a `NFToken`. Similarly, a seller must _explicitly_ choose to accept a specific `NFTokenOffer` that offers to buy a `NFToken` object that they own.
The transactions for `NFToken` trading are:
- [NFTokenCreateOffer][]
- [NFTokenCancelOffer][]
- [NFTokenAcceptOffer][]
## Locating NFTokenOffer entries
Each unique NFT has up to two [directories](directorynode.md): one contains offers to buy the token and the other contains offers to sell the token. (These two directories are created as necessary and deleted if empty.) Marketplaces or other client applications can use these directories to find and display offers to trade `NFToken` objects to users or even automatically match them and accept them.
### NFTokenOffer Reserve
{% code-page-name /%} entries each count as one item towards the owner reserve of the account placing the offer, as long as the entry is in the ledger. Accepting or canceling the offer frees up the reserve.
### NFTokenOffer ID Format
The unique ID (`NFTokenOfferID`) of a `NFTokenOffer` object is the result of the following values concatenated in order:
* The `NFTokenOffer` space key, `0x0037`;
* The `AccountID` of the account placing the offer; and
* The `Sequence` (or `Ticket`) of the `NFTokenCreateOffer` transaction that created the `NFTokenOffer`.
{% raw-partial file="/_snippets/common-links.md" /%}

106
docs/references/protocol/ledger-data/ledger-entry-types/nftokenpage.md Normal file
View File

@@ -0,0 +1,106 @@
---
html: nftokenpage.html
parent: ledger-entry-types.html
seo:
description: Ledger structure for recording NFTokens.
labels:
- Non-fungible Tokens, NFTs
---
# NFTokenPage
The `NFTokenPage` object represents a collection of [NFTs](../../../../concepts/tokens/nfts/index.md) owned by the same account. An account can have multiple `NFTokenPage` entries, which form a doubly linked list.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {% $frontmatter.seo.title %} JSON
```json
{
"LedgerEntryType": "NFTokenPage",
"PreviousPageMin":
"8A244DD75DAF4AC1EEF7D99253A7B83D2297818B2297818B70E264D2000002F2",
"NextPageMin":
"8A244DD75DAF4AC1EEF7D99253A7B83D2297818B2297818BE223B0AE0000010B",
"PreviousTxnID":
"95C8761B22894E328646F7A70035E9DFBECC90EDD83E43B7B973F626D21A0822",
"PreviousTxnLgrSeq":
42891441,
"NFTokens": [
{
"NFToken": {
"NFTokenID":
"000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65",
"URI": "697066733A2F2F62616679626569676479727A74357366703775646D37687537367568377932366E6634646675796C71616266336F636C67747179353566627A6469"
}
},
/* potentially more objects */
]
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:------------|
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0050`, mapped to the string `NFTokenPage`, indicates that this is a page containing `NFToken` objects.|
| `NextPageMin` | String | Hash256 | No | The locator of the next page, if any. Details about this field and how it should be used are outlined below. |
| `NFTokens` | Array | Array | Yes | The collection of `NFToken` objects contained in this NFTokenPage object. This specification places an upper bound of 32 NFToken objects per page. Objects are sorted from low to high with the `NFTokenID` used as the sorting parameter.|
| `PreviousPageMin` | String | Hash256 | No | The locator of the previous page, if any. Details about this field and how it should be used are outlined below. |
| `PreviousTxnID` | String | Hash256 | No | Identifies the transaction ID of the transaction that most recently modified this NFTokenPage object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | No | The sequence of the ledger that contains the transaction that most recently modified this NFTokenPage object.|
### NFTokenPage ID Format
`NFTokenPage` identifiers are constructed to allow a more efficient paging structure, ideally suited for `NFToken` objects.
The identifier of an `NFTokenPage` is derived by concatenating the 160-bit `AccountID` of the owner of the page, followed by a 96 bit value that indicates whether a particular `NFTokenID` can be contained in this page.
More specifically, a `NFToken` with the `NFTokenID` value `A` can be included in a page with `NFTokenPage` ID `B` if and only if `low96(A) >= low96(B)`.
This uses a function `low96(x)` which returns the low 96 bits of a 256-bit value, For example, applying the `low96` function to the `NFTokenID` of `000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65` returns the value `42540EE208C3098E00000D65`.
This design allows for efficient lookups of individual `NFToken` objects without needing to check each `NFTokenPage` in a list.
### Finding NFTokens
To find a specific `NFToken`, you need to know its `NFTokenID` and current owner. Compute the `NFTokenPage` ID as described above. Search for a ledger entry whose identifier is less than or equal to that value. If that entry does not exist or is not an `NFTokenPage`, that account does not own that `NFToken`.
### Adding NFTokens
To add an `NFToken`, find the `NFTokenPage` it should be in (using the same technique as searching for an `NFToken` object) and add it to that page. If the `NFTokenPage` is already full, find the previous and next pages (if any) and balance those three pages, inserting a new `NFTokenPage` as needed.
### Removing NFTokens
Removing `NFToken` objects works like adding them. If the number of `NFToken` objects in the page goes below a certain threshold, the ledger combines the page with a previous or next page if possible.
## {% $frontmatter.seo.title %} Reserve
Each `NFTokenPage` counts as one item towards its owner's [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves). Burning or trading away enough NFTs to remove the page frees up the reserve.
Since each page can hold up to 32 entries, the _effective_ reserve cost per NFT can be as low as _R_/32 where _R_ is the incremental owner reserve for one item.
### The reserve in practice
Because of the way splitting and combining pages works, the actual number of `NFToken` objects per page is somewhat unpredictable and depends on the actual `NFTokenID` values involved. In practice, after minting or receiving a large number of NFTs, each page can have as few as 16 items, or as many as 32, with the typical case being around 24 `NFToken` objects per page.
Currently, the reserve per item is 2 XRP. The table below shows how much the **total owner reserve** is for various numbers of NFTs owned under various scenarios:
| NFTs Owned | Best Case | Typical | Worst Case |
|:------------|:----------|:--------|:-----------|
| 32 or fewer | 2 XRP | 2 XRP | 2 XRP |
| 50 | 4 XRP | 6 XRP | 8 XRP |
| 200 | 14 XRP | 18 XRP | 26 XRP |
| 1000 | 64 XRP | 84 XRP | 126 XRP |
These numbers are estimates; the actual numbers may vary.
{% raw-partial file="/_snippets/common-links.md" /%}

83
docs/references/protocol/ledger-data/ledger-entry-types/offer.md Normal file
View File

@@ -0,0 +1,83 @@
---
html: offer.html
parent: ledger-entry-types.html
seo:
description: An order to make a currency trade.
labels:
- Decentralized Exchange
---
# Offer
[[Source]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57 "Source")
The `Offer` ledger entry describes an [Offer](../../../../concepts/tokens/decentralized-exchange/offers.md) to exchange currencies in the XRP Ledger's [decentralized exchange](../../../../concepts/tokens/decentralized-exchange/index.md). (In finance, this is more traditionally known as an _order_.) An [OfferCreate transaction][] only creates an `Offer` entry in the ledger when the Offer cannot be fully executed immediately by consuming other Offers already in the ledger.
An Offer can become unfunded through other activities in the network, while remaining in the ledger. When processing transactions, the network automatically removes any unfunded Offers that those transactions come across. (Otherwise, unfunded Offers remain, because _only_ transactions can change the ledger state.)
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Account": "rBqb89MRQJnMPq8wTwEbtz4kvxrEDfcYvt",
"BookDirectory": "ACC27DE91DBA86FC509069EAF4BC511D73128B780F2E54BF5E07A369E2446000",
"BookNode": "0000000000000000",
"Flags": 131072,
"LedgerEntryType": "Offer",
"OwnerNode": "0000000000000000",
"PreviousTxnID": "F0AB71E777B2DA54B86231E19B82554EF1F8211F92ECA473121C655BFC5329BF",
"PreviousTxnLgrSeq": 14524914,
"Sequence": 866,
"TakerGets": {
"currency": "XAG",
"issuer": "r9Dr5xwkeLegBeXq6ujinjSBLQzQ1zQGjH",
"value": "37"
},
"TakerPays": "79550000000",
"index": "96F76F27D8A327FC48753167EC04A46AA0E382E6F57F32FD12274144D00F1797"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:-----------------|:------------------|:----------|:------------|
| `Account` | String | AccountID | Yes | The address of the account that owns this Offer. |
| `BookDirectory` | String | Hash256 | Yes | The ID of the [Offer Directory](directorynode.md) that links to this Offer. |
| `BookNode` | String | UInt64 | Yes | A hint indicating which page of the offer directory links to this entry, in case the directory consists of multiple pages. |
| `Expiration` | Number | UInt32 | No | Indicates the time after which this Offer is considered unfunded. See [Specifying Time][] for details. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x006F`, mapped to the string `Offer`, indicates that this is an Offer entry. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the 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 [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `Sequence` | Number | UInt32 | Yes | The `Sequence` value of the [OfferCreate][] transaction that created this offer. Used in combination with the `Account` to identify this offer. |
| `TakerPays` | [Currency Amount][] | Amount | Yes | The remaining amount and type of currency requested by the Offer creator. |
| `TakerGets` | [Currency Amount][] | Amount | Yes | The remaining amount and type of currency being provided by the Offer creator. |
## Offer Flags
`Offer` entries can have the following flags combined into the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Corresponding [OfferCreate Flag](../../transactions/types/offercreate.md#offercreate-flags) | Description |
|--------------|--------------|---------------|-------------|------------------------|
| `lsfPassive` | `0x00010000` | 65536 | `tfPassive` | The offer was placed as "passive". This has no effect after the offer is placed into the ledger. |
| `lsfSell` | `0x00020000` | 131072 | `tfSell` | The offer was placed as a "Sell" offer. This has no effect after the offer is placed in the ledger, because `tfSell` only matters if you get a better rate than you asked for, which can only happen when the offer is initially placed. |
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries count as one item towards the owner reserve of the account that placed the offer, as long as the entry is in the ledger. Canceling or consuming the offer frees up the reserve. The reserve is also freed up if the offer is removed because it was found unfunded.
## Offer ID Format
The ID of an `Offer` entry is the [SHA-512Half][] of the following values, concatenated in order:
* The Offer space key (`0x006F`)
* The AccountID of the account placing the Offer
* The Sequence number of the [OfferCreate transaction][] that created the Offer.
If the OfferCreate transaction used a [Ticket](../../../../concepts/accounts/tickets.md), use the `TicketSequence` value instead.
{% raw-partial file="/_snippets/common-links.md" /%}

111
docs/references/protocol/ledger-data/ledger-entry-types/paychannel.md Normal file
View File

@@ -0,0 +1,111 @@
---
html: paychannel.html
parent: ledger-entry-types.html
seo:
description: A channel for asynchronous XRP payments.
labels:
- Payment Channels
---
# PayChannel
[[Source]](https://github.com/XRPLF/rippled/blob/c0a0b79d2d483b318ce1d82e526bd53df83a4a2c/src/ripple/protocol/impl/LedgerFormats.cpp#L180-L198 "Source")
_(Added by the [PayChan amendment][].)_
A `PayChannel` entry represents a [payment channel](../../../../concepts/payment-types/payment-channels.md).
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Account": "rBqb89MRQJnMPq8wTwEbtz4kvxrEDfcYvt",
"Destination": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Amount": "4325800",
"Balance": "2323423",
"PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A",
"SettleDelay": 3600,
"Expiration": 536027313,
"CancelAfter": 536891313,
"SourceTag": 0,
"DestinationTag": 1002341,
"DestinationNode": "0000000000000000",
"Flags": 0,
"LedgerEntryType": "PayChannel",
"OwnerNode": "0000000000000000",
"PreviousTxnID": "F0AB71E777B2DA54B86231E19B82554EF1F8211F92ECA473121C655BFC5329BF",
"PreviousTxnLgrSeq": 14524914,
"index": "96F76F27D8A327FC48753167EC04A46AA0E382E6F57F32FD12274144D00F1797"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:-----------------------|
| `Account` | String | AccountID | Yes | The source address that owns this payment channel. This comes from the sending address of the transaction that created the channel. |
| `Amount` | String | Amount | Yes | Total [XRP, in drops][], that has been allocated to this channel. This includes XRP that has been paid to the destination address. This is initially set by the transaction that created the channel and can be increased if the source address sends a PaymentChannelFund transaction. |
| `Balance` | String | Amount | Yes | Total [XRP, in drops][], already paid out by the channel. The difference between this value and the `Amount` field is how much XRP can still be paid to the destination address with PaymentChannelClaim transactions. If the channel closes, the remaining difference is returned to the source address. |
| `CancelAfter` | Number | UInt32 | No | The immutable expiration time for this payment channel, in [seconds since the Ripple Epoch][]. This channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](../ledger-header.md). This is optionally set by the transaction that created the channel, and cannot be changed. |
| `Destination` | String | AccountID | Yes | The destination address for this payment channel. While the payment channel is open, this address is the only one that can receive XRP from the channel. This comes from the `Destination` field of the transaction that created the channel. |
| `DestinationTag` | Number | UInt32 | No | An arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. |
| `DestinationNode` | String | UInt64 | No | A hint indicating which page of the destination's owner directory links to this entry, in case the directory consists of multiple pages. Omitted on payment channels created before enabling the [fixPayChanRecipientOwnerDir amendment][]. |
| `Expiration` | Number | UInt32 | No | The mutable expiration time for this payment channel, in [seconds since the Ripple Epoch][]. The channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](../ledger-header.md). See [Channel Expiration](#channel-expiration) for more details. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0078`, mapped to the string `PayChannel`, indicates that this is a payment channel entry. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the source address'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 [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. |
| `PublicKey` | String | Blob | Yes | Public key, in hexadecimal, of the key pair that can be used to sign claims against this channel. This can be any valid secp256k1 or Ed25519 public key. This is set by the transaction that created the channel and must match the public key used in claims against the channel. The channel source address can also send XRP from this channel to the destination without signed claims. |
| `SettleDelay` | Number | UInt32 | Yes | Number of seconds the source address must wait to close the channel if it still has any XRP in it. Smaller values mean that the destination address has less time to redeem any outstanding claims after the source address requests to close the channel. Can be any value that fits in a 32-bit unsigned integer (0 to 2^32-1). This is set by the transaction that creates the channel. |
| `SourceTag` | Number | UInt32 | No | An arbitrary tag to further specify the source for this payment channel, such as a hosted recipient at the owner's address. |
## Channel Expiration
The `Expiration` field of a payment channel is the mutable expiration time, in contrast to the immutable expiration time represented by the `CancelAfter` field. The expiration of a channel is always considered relative to the [`close_time` field](../ledger-header.md) of the previous ledger. The `Expiration` field is omitted when a `PayChannel` entry is created. There are several ways the `Expiration` field of a `PayChannel` entry can be updated, which can be summarized as follows: a channel's source address can set the `Expiration` of the channel freely as long as the channel always remains open at least `SettleDelay` seconds after the first attempt to close it.
When a payment channel expires, at first it remains on the ledger, because only new transactions can modify ledger contents. Transaction processing automatically closes a payment channel when any transaction accesses it after the expiration. To close an expired channel and return the unspent XRP to the owner, some address must send a new PaymentChannelClaim or PaymentChannelFund transaction accessing the channel.
### Source Address
The source address can set the `Expiration` directly with the PaymentChannelFund transaction type. The new value must not be earlier than whichever of the following values is earliest:
- The current `Expiration` value (if one is set)
- The previous ledger's close time plus the `SettleDelay` of the channel
In other words, the source address can always make the `Expiration` later if an expiration is already set. The source can make an `Expiration` value earlier or set an `Expiration` if one isn't currently set, as long as the new value is at least `SettleDelay` seconds in the future. If the source address attempts to set an invalid `Expiration` date, the transaction fails with the `temBAD_EXPIRATION` error code.
The source address can also set the `Expiration` with the `tfClose` flag of the PaymentChannelClaim transaction type. If the flag is enabled, the ledger automatically sets the `Expiration` to whichever of the following values is earlier:
- The current `Expiration` value (if one is set)
- The previous ledger's close time plus the `SettleDelay` of the channel
The source address can remove the `Expiration` with the `tfRenew` flag of the PaymentChannelClaim transaction type.
### Destination Address
The destination address cannot set the `Expiration` field. However, the destination address can use the PaymentChannelClaim's `tfClose` flag to close a channel immediately.
### Other Addresses
If any other address attempts to set an `Expiration` field, the transaction fails with the `tecNO_PERMISSION` error code. However, if the channel is already expired, the transaction causes the channel to close and results in `tesSUCCESS` instead.
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries count as one item towards the owner reserve of the account that created the payment channel, as long as the entry is in the ledger. Removing the channel frees up the reserve; this can only be done after the channel expires (including as a result of being explicitly closed).
## PayChannel ID Format
The ID of a `PayChannel` entry is the [SHA-512Half][] of the following values, concatenated in order:
* The PayChannel space key (`0x0078`)
* The AccountID of the source account
* The AccountID of the destination account
* The Sequence number of the [PaymentChannelCreate transaction][] that created the channel
If the PaymentChannelCreate transaction used a [Ticket](../../../../concepts/accounts/tickets.md), use the `TicketSequence` value instead.
{% raw-partial file="/_snippets/common-links.md" /%}

124
docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md Normal file
View File

@@ -0,0 +1,124 @@
---
html: ripplestate.html
parent: ledger-entry-types.html
seo:
description: This entry represents a trust line, tracking the net balance of tokens between them.
labels:
- Tokens
---
# RippleState
[[Source]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L70 "Source")
A `RippleState` ledger entry represents a [trust line](../../../../concepts/tokens/fungible-tokens/index.md) between two accounts. Each account can change its own limit and other settings, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as a trust line that does not exist and is automatically deleted.
## High vs. Low Account
There can only be one `RippleState` entry per currency for any given pair of accounts. Since no account is privileged in the XRP Ledger, a `RippleState` entry sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when [decoded](../../../../concepts/accounts/addresses.md#address-encoding) is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.
The ["issuer"](../../../../concepts/tokens/fungible-tokens/index.md) for the balance in a trust line depends on whether the balance is positive or negative. If a `RippleState` entry shows a positive balance, the high account is the issuer. If the balance is negative, the low account is the issuer. Often, the issuer has its limit set to 0 and the other account has a positive limit, but this is not reliable because limits can change without affecting an existing balance.
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Balance": {
"currency": "USD",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
"value": "-10"
},
"Flags": 393216,
"HighLimit": {
"currency": "USD",
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"value": "110"
},
"HighNode": "0000000000000000",
"LedgerEntryType": "RippleState",
"LowLimit": {
"currency": "USD",
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"value": "0"
},
"LowNode": "0000000000000000",
"PreviousTxnID": "E3FE6EA3D48F0C2B639448020EA4F03D4F4F8FFDB243A852A0F59177921B4879",
"PreviousTxnLgrSeq": 14090896,
"index": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:--------------|:----------|:------------|
| `Balance` | Object | Amount | Yes | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the high account holds tokens issued by the low account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](../../../../concepts/accounts/addresses.md#special-addresses). |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean options enabled for this entry. |
| `HighLimit` | Object | Amount | Yes | The limit that the high account has set on the trust line. The `issuer` is the address of the high account that set this limit. |
| `HighNode` | String | UInt64 | Yes | (Omitted in some historical ledgers) A hint indicating which page of the high account's owner directory links to this entry, in case the directory consists of multiple pages. |
| `HighQualityIn` | Number | UInt32 | No | The inbound quality set by the high account, as an integer in the implied ratio `HighQualityIn`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
| `HighQualityOut` | Number | UInt32 | No | The outbound quality set by the high account, as an integer in the implied ratio `HighQualityOut`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0072`, mapped to the string `RippleState`, indicates that this is a RippleState entry. |
| `LowLimit` | Object | Amount | Yes | The limit that the low account has set on the trust line. The `issuer` is the address of the low account that set this limit. |
| `LowNode` | String | UInt64 | Yes | (Omitted in some historical ledgers) A hint indicating which page of the low account's owner directory links to this entry, in case the directory consists of multiple pages. |
| `LowQualityIn` | Number | UInt32 | No | The inbound quality set by the low account, as an integer in the implied ratio `LowQualityIn`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
| `LowQualityOut` | Number | UInt32 | No | The outbound quality set by the low account, as an integer in the implied ratio `LowQualityOut`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this entry. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. |
## RippleState Flags
`RippleState` entries can have the following flags combined into the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Corresponding [TrustSet Flag](../../transactions/types/trustset.md#trustset-flags) | Description |
|-------------------|--------------|---------------|-----------------|---------|
| `lsfLowReserve` | `0x00010000` | 65536 | (None) | This entry [contributes to the low account's owner reserve](#ripplestate-reserve). |
| `lsfHighReserve` | `0x00020000` | 131072 | (None) | This entry [contributes to the high account's owner reserve](#ripplestate-reserve). |
| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | The low account has authorized the high account to hold tokens issued by the low account. |
| `lsfHighAuth` | `0x00080000` | 524288 | `tfSetAuth` | The high account has authorized the low account to hold tokens issued by the high account. |
| `lsfLowNoRipple` | `0x00100000` | 1048576 | `tfSetNoRipple` | The low account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | The high account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | The low account has frozen the trust line, preventing the high account from transferring the asset. |
| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | The high account has frozen the trust line, preventing the low account from transferring the asset. |
The two accounts connected by the trust line can each change their own settings with a [TrustSet transaction][].
## {% $frontmatter.seo.title %} Reserve
<a id="contributing-to-the-owner-reserve"></a>
A `RippleState` entry counts as one item towards the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves) of _one or both_ of the accounts it connects. In typical cases, the holder of a token owes a reserve and the issuer of the token does not.
Specifically, the entry counts towards an account's reserve if that account modifies a trust line to put it in a non-default state. The `lsfLowReserve` and `lsfHighReserve` flags indicate which account(s) are responsible for the owner reserve. The protocol automatically sets these flags when it modifies a trust line.
The values that count towards a trust line's non-default state are as follows:
| High account responsible if... | Low account responsible if... |
|-----------------------|----------------------|
| `Balance` is negative (the high account holds currency) | `Balance` is positive (the low account holds currency) |
| `HighLimit` is not `0` | `LowLimit` is not `0` |
| `LowQualityIn` is not `0` and not `1000000000` | `HighQualityIn` is not `0` and not `1000000000` |
| `LowQualityOut` is not `0` and not `1000000000` | `HighQualityOut` is not `0` and not `1000000000` |
| `lsfHighNoRipple` flag is not in its default state | `lsfLowNoRipple` flag is not in its default state |
| `lsfHighFreeze` flag is enabled | `lsfLowFreeze` flag is enabled |
The **`lsfLowAuth`** and **`lsfHighAuth`** flags do not count against the default state, because they cannot be disabled.
The default state of the two No Ripple flags depends on the state of the [`lsfDefaultRipple` flag](accountroot.md#accountroot-flags) in their corresponding AccountRoot entries. If Default Ripple is disabled (the default), then the default state of the `lsfNoRipple` flag is _enabled_ for all of an account's trust lines. If an account enables Default Ripple, then the `lsfNoRipple` flag is _disabled_ (rippling is enabled) for an account's trust lines by default.
**Note:** Prior to the introduction of the Default Ripple flag in `rippled` version 0.27.3 (March 10, 2015), the default state for all trust lines was with both No Ripple flags disabled (rippling enabled).
The XRP Ledger uses lazy evaluation to calculate the owner reserve. This means that even if an account changes the default state of all its trust lines by changing the Default Ripple flag, that account's reserve stays the same initially. When an account modifies a trust line, the protocol re-evaluates whether that individual trust line is in its default state and should contribute to the owner reserve.
## RippleState ID Format
The ID of a RippleState entry is the [SHA-512Half][] of the following values, concatenated in order:
* The RippleState space key (`0x0072`)
* The AccountID of the low account
* The AccountID of the high account
* The 160-bit currency code of the trust line(s)
{% raw-partial file="/_snippets/common-links.md" /%}

108
docs/references/protocol/ledger-data/ledger-entry-types/signerlist.md Normal file
View File

@@ -0,0 +1,108 @@
---
html: signerlist.html
parent: ledger-entry-types.html
seo:
description: A list of addresses for multi-signing transactions.
labels:
- Security
---
# SignerList
[[Source]](https://github.com/XRPLF/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
_(Added by the [MultiSign amendment][].)_
A `SignerList` entry represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a signer list using a [SignerListSet transaction][].
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Flags": 0,
"LedgerEntryType": "SignerList",
"OwnerNode": "0000000000000000",
"PreviousTxnID": "5904C0DC72C58A83AEFED2FFC5386356AA83FCA6A88C89D00646E51E687CDBE4",
"PreviousTxnLgrSeq": 16061435,
"SignerEntries": [
{
"SignerEntry": {
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SignerWeight": 2
}
},
{
"SignerEntry": {
"Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
"SignerWeight": 1
}
},
{
"SignerEntry": {
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
"SignerWeight": 1
}
}
],
"SignerListID": 0,
"SignerQuorum": 3,
"index": "A9C28A28B85CD533217F5C0A0C7767666B093FA58A0F2D80026FCC4CD932DDC7"
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:--------------|:----------|:---------------------------|
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0053`, mapped to the string `SignerList`, indicates that this is a SignerList ledger entry. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `SignerEntries` | Array | Array | Yes | An array of Signer Entry objects representing the parties who are part of this signer list. |
| `SignerListID` | Number | UInt32 | Yes | An ID for this signer list. Currently always set to `0`. If a future [amendment](../../../../concepts/networks-and-servers/amendments.md) allows multiple signer lists for an account, this may change. |
| `SignerQuorum` | Number | UInt32 | Yes | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. |
The `SignerEntries` may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys.
### Signer Entry Object
Each member of the `SignerEntries` field is an object that describes that signer in the list. A Signer Entry has the following fields:
| Name | JSON Type | Internal Type | Description |
|:----------------|:----------|:--------------|:-------------------------------|
| `Account` | String | AccountID | An XRP Ledger address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. |
| `SignerWeight` | Number | UInt16 | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the signer list's `SignerQuorum` value. |
| `WalletLocator` | String | Hash256 | _(Optional)_ Arbitrary hexadecimal data. This can be used to identify the signer or for other, related purposes. _(Added by the [ExpandedSignerList amendment][].)_ |
When processing a multi-signed transaction, the server looks up the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot ledger entry](accountroot.md), then only the [master private key](../../../../concepts/accounts/cryptographic-keys.md) associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.
## {% $frontmatter.seo.title %} Flags
_(Added by the [MultiSignReserve amendment][].)_
SignerList entries can have the following value in the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Description |
|:-------------------|:-------------|:--------------|:-------------------------|
| `lsfOneOwnerCount` | `0x00010000` | 65536 | If this flag is enabled, this SignerList counts as one item for purposes of the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves). Otherwise, this list counts as N+2 items, where N is the number of signers it contains. This flag is automatically enabled if you add or update a signer list after the [MultiSignReserve amendment][] is enabled. |
## Signer Lists and Reserves
A signer list contributes to its owner's [reserve requirement](../../../../concepts/accounts/reserves.md). Removing the signer list frees up the reserve.
The [MultiSignReserve amendment][] (enabled 2019-04-17) made it so each signer list counts as one item, regardless of how many members it has. As a result, the owner reserve for any signer list added or updated after this time is {% $env.PUBLIC_OWNER_RESERVE %}.
A signer list created before the [MultiSignReserve amendment][] itself counts as two items towards the owner reserve, and each member of the list counts as one. As a result, the total owner reserve associated with an old signer list is anywhere from 3 times to 10 times as much as a new signer list. To update a signer list to use the new, reduced reserve, update the signer list by sending a [SignerListSet transaction][].
## SignerList ID Format
The ID of a `SignerList` entry is the SHA-512Half of the following values, concatenated in order:
* The RippleState space key (`0x0053`)
* The AccountID of the owner of the signer list
* The `SignerListID` (currently always `0`)
{% raw-partial file="/_snippets/common-links.md" /%}

63
docs/references/protocol/ledger-data/ledger-entry-types/ticket.md Normal file
View File

@@ -0,0 +1,63 @@
---
html: ticket.html
parent: ledger-entry-types.html
seo:
description: A Ticket tracks an account sequence number that has been set aside for future use.
labels:
- Transaction Sending
---
# Ticket
[[Source]](https://github.com/XRPLF/rippled/blob/76a6956138c4ecd156c5c408f136ed3d6ab7d0c1/src/ripple/protocol/impl/LedgerFormats.cpp#L155-L164)
_(Added by the [TicketBatch amendment][].)_
A `Ticket` entry type represents a [Ticket](../../../../concepts/accounts/tickets.md), which tracks an account [sequence number][Sequence Number] that has been set aside for future use. You can create new tickets with a [TicketCreate transaction][].
## Example {% $frontmatter.seo.title %} JSON
```json
{
"Account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
"Flags": 0,
"LedgerEntryType": "Ticket",
"OwnerNode": "0000000000000000",
"PreviousTxnID": "F19AD4577212D3BEACA0F75FE1BA1644F2E854D46E8D62E9C95D18E9708CBFB1",
"PreviousTxnLgrSeq": 4,
"TicketSequence": 3
}
```
## {% $frontmatter.seo.title %} Fields
In addition to the [common fields](../common-fields.md), {% code-page-name /%} entries have the following fields:
| Name | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:--------------|:----------|:---------------------------|
| `Account` | String | AccountID | Yes | The [account](../../../../concepts/accounts/accounts.md) that owns this Ticket. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0054`, mapped to the string `Ticket`, indicates that this is a {% $frontmatter.seo.title %} entry. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this entry, in case the directory consists of multiple pages. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the [transaction](../../../../concepts/transactions/index.md) that most recently modified this entry. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. |
| `TicketSequence` | Number | UInt32 | Yes | The [Sequence Number][] this Ticket sets aside. |
## {% $frontmatter.seo.title %} Reserve
{% code-page-name /%} entries count as one item towards the owner reserve of the account that placed the created it, as long as the entry is in the ledger. Using the ticket frees up the reserve.
## {% $frontmatter.seo.title %} Flags
There are no flags defined for {% code-page-name /%} entries.
## {% $frontmatter.seo.title %} ID Format
The ID of a Ticket object is the SHA-512Half of the following values, concatenated in order:
* The Ticket space key (`0x0054`)
* The AccountID of the owner of the Ticket
* The `TicketSequence` number of the Ticket
{% raw-partial file="/_snippets/common-links.md" /%}

107
docs/references/protocol/ledger-data/ledger-entry-types/xchainownedclaimid.md Normal file
View File

@@ -0,0 +1,107 @@
---
html: xchainownedclaimid.html
parent: ledger-entry-types.html
seo:
description: An `XChainOwnedClaimID` object represents *one* cross-chain transfer of value.
labels:
- Interoperability
status: not_enabled
---
# XChainOwnedClaimID
_(Requires the [XChainBridge amendment][] {% not-enabled /%})_
[[Source]](https://github.com/seelabs/rippled/blob/xbridge/src/ripple/protocol/impl/LedgerFormats.cpp#L281-L293 "Source")
An `XChainOwnedClaimID` object represents *one* cross-chain transfer of value and includes information of the account on the source chain that locks or burns the funds on the source chain.
The `XChainOwnedClaimID` object must be acquired on the destination chain before submitting a `XChainCommit` on the source chain. Its purpose is to prevent transaction replay attacks and is also used as a place to collect attestations from witness servers.
An `XChainCreateClaimID` transaction is used to create a new `XChainOwnedClaimID`. The ledger object is destroyed when the funds are successfully claimed on the destination chain.
## Example XChainOwnedClaimID JSON
```json
{
"Account": "rBW1U7J9mEhEdk6dMHEFUjqQ7HW7WpaEMi",
"Flags": 0,
"OtherChainSource": "r9oXrvBX5aDoyMGkoYvzazxDhYoWFUjz8p",
"OwnerNode": "0",
"PreviousTxnID": "1CFD80E9CF232B8EED62A52857DE97438D12230C06496932A81DEFA6E66070A6",
"PreviousTxnLgrSeq": 58673,
"SignatureReward": "100",
"XChainBridge": {
"IssuingChainDoor": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"IssuingChainIssue": {
"currency": "XRP"
},
"LockingChainDoor": "rMAXACCrp3Y8PpswXcg3bKggHX76V3F8M4",
"LockingChainIssue": {
"currency": "XRP"
}
},
"XChainClaimAttestations": [
{
"XChainClaimProofSig": {
"Amount": "1000000",
"AttestationRewardAccount": "rfgjrgEJGDxfUY2U8VEDs7BnB1jiH3ofu6",
"AttestationSignerAccount": "rfsxNxZ6xB1nTPhTMwQajNnkCxWG8B714n",
"Destination": "rBW1U7J9mEhEdk6dMHEFUjqQ7HW7WpaEMi",
"PublicKey": "025CA526EF20567A50FEC504589F949E0E3401C13EF76DD5FD1CC2850FA485BD7B",
"WasLockingChainSend": 1
}
},
{
"XChainClaimProofSig": {
"Amount": "1000000",
"AttestationRewardAccount": "rUUL1tP523M8KimERqVS7sxb1tLLmpndyv",
"AttestationSignerAccount": "rEg5sHxZVTNwRL3BAdMwJatkmWDzHMmzDF",
"Destination": "rBW1U7J9mEhEdk6dMHEFUjqQ7HW7WpaEMi",
"PublicKey": "03D40434A6843638681E2F215310EBC4131AFB12EA85985DA073183B732525F7C9",
"WasLockingChainSend": 1
},
}
],
"XChainClaimID": "b5",
"LedgerEntryType": "XChainOwnedClaimID",
"LedgerIndex": "20B136D7BF6D2E3D610E28E3E6BE09F5C8F4F0241BBF6E2D072AE1BACB1388F5"
}
```
## XChainOwnedClaimID Fields
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------------|:--------------------|:------------------|:----------|:----------------|
| `Account` | String | Account | Yes | The account that owns this object. |
| `LedgerIndex` | String | Hash256 | Yes | The ledger index is a hash of a unique prefix for `XChainOwnedClaimID`s, the actual `XChainClaimID` value, and the fields in `XChainBridge`. |
| `OtherChainSource` | String | Account | Yes | The account that must send the corresponding `XChainCommit` on the source chain. The destination may be specified in the `XChainCommit` transaction, which means that if the `OtherChainSource` isn't specified, another account can try to specify a different destination and steal the funds. This also allows tracking only a single set of signatures, since we know which account will send the `XChainCommit` transaction. |
| `SignatureReward` | [Currency Amount][] | Amount | Yes | The total amount to pay the witness servers for their signatures. It must be at least the value of `SignatureReward` in the `Bridge` ledger object. |
| `XChainBridge` | XChainBridge | XChain_Bridge | Yes | The door accounts and assets of the bridge this object correlates to. |
| `XChainClaimAttestations` | Array | Array | Yes | Attestations collected from the witness servers. This includes the parameters needed to recreate the message that was signed, including the amount, which chain (locking or issuing), optional destination, and reward account for that signature. |
| `XChainClaimID` | String | UInt64 | Yes | The unique sequence number for a cross-chain transfer. |
### XChainClaimAttestations Fields
| Field | JSON Type | [Internal Type][] | Required | Description |
|-------------------------------|---------------------|-------------------|----------|-------------|
| `XChainClaimProofSig` | Array | Object | Yes | An attestation from one witness server. |
| `Amount` | [Currency Amount][] | Amount | Yes | The amount to claim in the `XChainCommit` transaction on the destination chain. |
| `AttestationRewardAccount` | String | Account | Yes | The account that should receive this signer's share of the `SignatureReward`. |
| `AttestationSignerAccount` | String | Account | Yes | The account on the door account's signer list that is signing the transaction. |
| `Destination` | String | Account | No | The destination account for the funds on the destination chain. |
| `PublicKey` | String | Blob | Yes | The public key used to verify the signature. |
| `WasLockingChainSend` | Number | UInt8 | Yes | A boolean representing the chain where the event occurred. |
### XChainBridge Fields
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:----------------|
| `IssuingChainDoor` | String | Account | Yes | The door account on the issuing chain. For an XRP-XRP bridge, this must be the genesis account (the account that is created when the network is first started, which contains all of the XRP). |
| `IssuingChainIssue` | Issue | Issue | Yes | The asset that is minted and burned on the issuing chain. For an IOU-IOU bridge, the issuer of the asset must be the door account on the issuing chain, to avoid supply issues. |
| `LockingChainDoor` | String | Account | Yes | The door account on the locking chain. |
| `LockingChainIssue` | Issue | Issue | Yes | The asset that is locked and unlocked on the locking chain. |
{% raw-partial file="/_snippets/common-links.md" /%}

90
docs/references/protocol/ledger-data/ledger-entry-types/xchainownedcreateaccountclaimid.md Normal file
View File

@@ -0,0 +1,90 @@
---
html: xchainownedcreateaccountclaimid.html
parent: ledger-entry-types.html
seo:
description: The `XChainOwnedCreateAccountClaimID` ledger object is used to collect attestations for creating an account via a cross-chain transfer.
labels:
- Interoperability
status: not_enabled
---
# XChainOwnedCreateAccountClaimID
_(Requires the [XChainBridge amendment][] {% not-enabled /%})_
[[Source]](https://github.com/seelabs/rippled/blob/xbridge/src/ripple/protocol/impl/LedgerFormats.cpp#L296-L306 "Source")
The `XChainOwnedCreateAccountClaimID` ledger object is used to collect attestations for creating an account via a cross-chain transfer.
It is created when an `XChainAddAccountCreateAttestation` transaction adds a signature attesting to a `XChainAccountCreateCommit` transaction and the `XChainAccountCreateCount` is greater than or equal to the current `XChainAccountClaimCount` on the `Bridge` ledger object.
The ledger object is destroyed when all the attestations have been received and the funds have transferred to the new account.
## Example XChainOwnedCreateAccountClaimID JSON
```json
{
"LedgerEntryType": "XChainOwnedCreateAccountClaimID",
"LedgerIndex": "5A92F6ED33FDA68FB4B9FD140EA38C056CD2BA9673ECA5B4CEF40F2166BB6F0C",
"Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"XChainAccountCreateCount": "66",
"XChainBridge": {
"IssuingChainDoor": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"IssuingChainIssue": {
"currency": "XRP"
},
"LockingChainDoor": "rMAXACCrp3Y8PpswXcg3bKggHX76V3F8M4",
"LockingChainIssue": {
"currency": "XRP"
}
},
"XChainCreateAccountAttestations": [
{
"XChainCreateAccountProofSig": {
"Amount": "20000000",
"AttestationRewardAccount": "rMtYb1vNdeMDpD9tA5qSFm8WXEBdEoKKVw",
"AttestationSignerAccount": "rL8qTrAvZ8Q1o1H9H9Ahpj3xjgmRvFLvJ3",
"Destination": "rBW1U7J9mEhEdk6dMHEFUjqQ7HW7WpaEMi",
"PublicKey": "021F7CC4033EFBE5E8214B04D1BAAEC14808DC6C02F4ACE930A8EF0F5909B0C438",
"SignatureReward": "100",
"WasLockingChainSend": 1
}
}
]
}
```
## XChainOwnedCreateAccountClaimID Fields
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:----------------------------------|:-------------|:------------------|:----------|:------------|
| `Account` | String | Account | Yes | The account that owns this object. |
| `LedgerIndex` | String | Hash256 | Yes | The ledger index is a hash of a unique prefix for `XChainOwnedCreateAccountClaimID`s, the actual `XChainAccountClaimCount` value, and the fields in `XChainBridge`. |
| `XChainAccountCreateCount` | Number | UInt64 | Yes | An integer that determines the order that accounts created through cross-chain transfers must be performed. Smaller numbers must execute before larger numbers. |
| `XChainBridge` | XChainBridge | XChain_Bridge | Yes | The door accounts and assets of the bridge this object correlates to. |
| `XChainCreateAccountAttestations` | Array | Array | Yes | Attestations collected from the witness servers. This includes the parameters needed to recreate the message that was signed, including the amount, destination, signature reward amount, and reward account for that signature. With the exception of the reward account, all signatures must sign the message created with common parameters. |
### XChainCreateAccountAttestations Fields
| Field | JSON Type | [Internal Type][] | Required | Description |
|-------------------------------|---------------------|-------------------|----------|-------------|
| `XChainCreateAccountProofSig` | Array | Object | Yes | An attestation from one witness server. |
| `Amount` | [Currency Amount][] | Amount | Yes | The amount committed by the `XChainAccountCreateCommit` transaction on the source chain. |
| `AttestationRewardAccount` | String | Account | Yes | The account that should receive this signer's share of the `SignatureReward`. |
| `AttestationSignerAccount` | String | Account | Yes | The account on the door account's signer list that is signing the transaction. |
| `Destination` | String | Account | Yes | The destination account for the funds on the destination chain. |
| `PublicKey` | String | Blob | Yes | The public key used to verify the signature. |
| `WasLockingChainSend` | Number | UInt8 | Yes | A boolean representing the chain where the event occurred. |
### XChainBridge Fields
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:----------------|
| `IssuingChainDoor` | String | Account | Yes | The door account on the issuing chain. For an XRP-XRP bridge, this must be the genesis account (the account that is created when the network is first started, which contains all of the XRP). |
| `IssuingChainIssue` | Issue | Issue | Yes | The asset that is minted and burned on the issuing chain. For an IOU-IOU bridge, the issuer of the asset must be the door account on the issuing chain, to avoid supply issues. |
| `LockingChainDoor` | String | Account | Yes | The door account on the locking chain. |
| `LockingChainIssue` | Issue | Issue | Yes | The asset that is locked and unlocked on the locking chain. |
{% raw-partial file="/_snippets/common-links.md" /%}

43
docs/references/protocol/ledger-data/ledger-header.md Normal file
View File

@@ -0,0 +1,43 @@
---
html: ledger-header.html
parent: ledger-data-formats.html
seo:
description: A unique header that describes the contents of a ledger version.
labels:
- Data Retention
- Blockchain
---
# Ledger Header
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
Every [ledger version](../../../concepts/ledgers/index.md) has a unique header that describes the contents. You can look up a ledger's header information with the [ledger method][]. The contents of the ledger header are as follows:
| Field | JSON Type | [Internal Type][] | Description |
|:------------------------------|:----------|:------------------|:--------------|
| `ledger_index` | String | UInt32 | The [ledger index][Ledger Index] of the ledger. Some API methods display this as a quoted integer; some display it as a native JSON number. |
| `ledger_hash` | String | Hash256 | The [SHA-512Half][] of this ledger version. This serves as a unique identifier for this ledger and all its contents. |
| `account_hash` | String | Hash256 | The [SHA-512Half][] of this ledger's state tree information. |
| [`close_flags`](#close-flags) | Number | UInt8 | A bit-map of flags relating to the closing of this ledger. |
| `close_time` | Number | UInt32 | The [approximate time this ledger version closed](../../../concepts/ledgers/ledger-close-times.md), as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00 UTC. This value is rounded based on the `close_time_resolution`. |
| `close_time_resolution` | Number | Uint8 | An integer in the range \[2,120\] indicating the maximum number of seconds by which the `close_time` could be rounded. |
| `closed` | Boolean | Boolean | If `true`, this ledger version is no longer accepting new transactions. (However, unless this ledger version is validated, it might be replaced by a different ledger version with a different set of transactions.) |
| `parent_hash` | String | Hash256 | The `ledger_hash` value of the previous ledger version that is the direct predecessor of this one. If there are different versions of the previous ledger index, this indicates from which one the ledger was derived. |
| `total_coins` | String | UInt64 | The total number of [drops of XRP][] owned by accounts in the ledger. This omits XRP that has been destroyed by transaction fees. The actual amount of XRP in circulation is lower because some accounts are "black holes" whose keys are not known by anyone. |
| `transaction_hash` | String | Hash256 | The [SHA-512Half][] of the transactions included in this ledger. |
## Ledger Index
{% partial file="/_snippets/data_types/ledger_index.md" /%}
## Close Flags
The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different [close times for the ledger](../../../concepts/ledgers/ledger-close-times.md), but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, official `close_time` value of the ledger is 1 second after that of the parent ledger.
## See Also
For ledger basics, see [Ledgers](../../../concepts/ledgers/index.md).
{% raw-partial file="/_snippets/common-links.md" /%}