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

Merge pull request #346 from mDuo13/doc1475

Browse Source 
Reorg ledger data formats
This commit is contained in:
Rome Reginelli
2018-05-10 11:45:41 -07:00
committed by GitHub
parent 4532dd8474 3f13f2255d
commit 2bc4c131cd
16 changed files with 328 additions and 169 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
content/references/rippled-api/ledger-data-formats/ledger-data-formats.md
View File

@@ -1,11 +1,36 @@
# Ledger Data Formats
{{currentpage.blurb}}
The XRP Ledger is a shared, global ledger that is open to all. Individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The `rippled` server software accomplishes this by managing a ledger database that can only be updated according to very specific rules. Each instance of `rippled` keeps a full copy of the ledger, and the peer-to-peer network of `rippled` servers distributes candidate transactions among themselves. The consensus process determines which transactions get applied to each new version of the ledger. See also: [The Consensus Process](consensus.html).
* **[Ledger Header](x)**
<!--{# TODO: provide overview text of what this content is all about #}-->
![Diagram: Each ledger is the result of applying transactions to the previous ledger version.](img/ledger-process.png)
* **[Ledger Object Types](x)**
<!--{# TODO: provide overview text of what this content is all about #}-->
The shared global ledger is actually a series of individual ledgers, or ledger versions, which `rippled` keeps in its internal database. Every ledger version has a [ledger index](#ledger-index) which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a `rippled` instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be correct and immutable.
<!--{# TODO: This page may need to catch overflow of any doc from https://developers.ripple.com/reference-ledger-format.html#xrp-ledger-data-format that hasn't been moved out to Ledger Header and Ledger Object Type docsIf yes - need to adjust presentation of links to child pages above because they may look like anchor links to topics on the page and cause confusion. Ideally, we'd provide another page in this hierarchy that reflects the content in the overflow. #}-->
A single ledger version consists of several parts:
![Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info](img/ledger-components.png)
* A **header** - The [ledger index](#ledger-index), hashes of its other contents, and other metadata.
* A **transaction tree** - The [transactions](reference-transaction-format.html) that were applied to the previous ledger to make this one. Transactions are the _only_ way to change the ledger.
* A **state tree** - All the [ledger objects](#ledger-object-types) that contain the settings, balances, and objects in the ledger as of this version.
## Tree Format
As its name might suggest, a ledger's state tree is a tree data structure. Each object in the state tree is identified by a 256-bit object ID. In JSON, a ledger object's ID is the `index` field, which contains a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every object in the state tree has an ID that you can use to look up that object; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (ID) of a ledger object with the [`ledger_index` (sequence number) of a ledger](#ledger-index).
**Tip:** Sometimes, an object in the ledger's state tree is called a "ledger node". For example, transaction metadata returns a list of `AffectedNodes`. Do not confuse this with a "node" (server) in the peer-to-peer network.
In the case of transactions, the identifying hash is based on the signed transaction instructions, but the contents of the transaction object when you look it up also contain the results and metadata of the transaction, which are not taken into account when generating the hash.
## Object IDs
<a id="sha512half"></a>
All objects in a ledger' state tree have a unique ID. This field is returned as the `index` field in JSON, at the same level as the object's contents. The ID is derived by hashing important contents of the object, along with a [namespace identifier](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L97). The ledger object type determines which namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. To calculate the hash, `rippled` uses SHA-512 and then truncates the result to the first 256 bytes. This algorithm, informally called **SHA-512Half**, provides an output that has comparable security to SHA-256, but runs faster on 64-bit processors.
![Diagram: rippled uses SHA-512Half to generate IDs for ledger objects. The space key prevents IDs for different object types from colliding.](img/ledger-indexes.png)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

108
content/references/rippled-api/ledger-data-formats/ledger-format-old-monolith.md
View File

@@ -1,108 +0,0 @@
# XRP Ledger Data Format
The XRP Ledger is a shared, global ledger that is open to all. Individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The `rippled` server software accomplishes this by managing a ledger database that can only be updated according to very specific rules. Each instance of `rippled` keeps a full copy of the ledger, and the peer-to-peer network of `rippled` servers distributes candidate transactions among themselves. The consensus process determines which transactions get applied to each new version of the ledger. See also: [The Consensus Process](https://ripple.com/build/ripple-ledger-consensus-process/).
![Diagram: Each ledger is the result of applying transactions to the previous ledger version.](img/ledger-process.png)
The shared global ledger is actually a series of individual ledgers, or ledger versions, which `rippled` keeps in its internal database. Every ledger version has a [ledger index](#ledger-index) which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a `rippled` instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be correct and immutable.
A single ledger version consists of several parts:
![Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info](img/ledger-components.png)
* A **header** - The [ledger index](#ledger-index), hashes of its other contents, and other metadata.
* A **transaction tree** - The [transactions](reference-transaction-format.html) that were applied to the previous ledger to make this one. Transactions are the _only_ way to change the ledger.
* A **state tree** - All the [ledger objects](#ledger-object-types) that contain the settings, balances, and objects in the ledger as of this version.
## Tree Format
As its name might suggest, a ledger's state tree is a tree data structure. Each object in the state tree is identified by a 256-bit object ID. In JSON, a ledger object's ID is the `index` field, which contains a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every object in the state tree has an ID that you can use to look up that object; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (ID) of a ledger object with the [`ledger_index` (sequence number) of a ledger](#ledger-index).
**Tip:** Sometimes, an object in the ledger's state tree is called a "ledger node". For example, transaction metadata returns a list of `AffectedNodes`. Do not confuse this with a "node" (server) in the peer-to-peer network.
In the case of transactions, the identifying hash is based on the signed transaction instructions, but the contents of the transaction object when you look it up also contain the results and metadata of the transaction, which are not taken into account when generating the hash.
## Object IDs
<a id="sha512half"></a>
All objects in a ledger' state tree have a unique ID. This field is returned as the `index` field in JSON, at the same level as the object's contents. The ID is derived by hashing important contents of the object, along with a [namespace identifier](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L97). The ledger object type determines which namespace identifier to use and which contents to include in the hash. This ensures every ID is unique. To calculate the hash, `rippled` uses SHA-512 and then truncates the result to the first 256 bytes. This algorithm, informally called **SHA-512Half**, provides an output that has comparable security to SHA-256, but runs faster on 64-bit processors.
![Diagram: rippled uses SHA-512Half to generate IDs for ledger objects. The space key prevents IDs for different object types from colliding.](img/ledger-indexes.png)
## Header Format
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
Every ledger version 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`](#ledger-index) | String | UInt32 | The sequence number 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](#sha512half) of the ledger header, excluding the `ledger_hash` itself. This serves as a unique identifier for this ledger and all its contents. |
| `account_hash` | String | Hash256 | The [SHA-512Half](#sha512half) of this ledger's state tree information. |
| `close_time` | Number | UInt32 | The approximate time this ledger closed, as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00. This value is rounded based on the `close_time_resolution`, so later ledgers can have the same value. |
| `closed` | Boolean | bool | 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 that was used to build 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][XRP, in drops] 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](#sha512half) of the transactions included in this ledger. |
| `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. |
| [`closeFlags`](#close-flags) | (Omitted) | UInt8 | A bit-map of flags relating to the closing of this ledger. |
[Internal Type]: https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/SField.cpp
### Ledger Index
{% include '_snippets/data_types/ledger_index.md' %}
[Hash]: reference-rippled.html#hashes
### 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, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger version contains a `close_time` value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.)
The `closeFlags` field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.
# Ledger Object Types
There are several different kinds of objects that can appear in the ledger's state tree:
* [**AccountRoot** - The settings, XRP balance, and other metadata for one account.](#accountroot)
* [**Amendments** - Singleton object with status of enabled and pending amendments.](#amendments)
* [**Check** - A check that can be redeemed for money by its destination](#check)
* [**DirectoryNode** - Contains links to other objects.](#directorynode)
* [**Escrow** - Contains XRP held for a conditional payment.](#escrow)
* [**FeeSettings** - Singleton object with consensus-approved base transaction cost and reserve requirements.](#feesettings)
* [**LedgerHashes** - Lists of prior ledger versions' hashes for history lookup.](#ledgerhashes)
* [**Offer** - An offer to exchange currencies, known in finance as an _order_.](#offer)
* [**PayChannel** - A channel for asynchronous XRP payments.](#paychannel)
* [**RippleState** - Links two accounts, tracking the balance of one currency between them. The concept of a _trust line_ is really an abstraction of this object type.](#ripplestate)
* [**SignerList** - A list of addresses for multi-signing transactions.](#signerlist)
Each ledger object consists of several fields. In the peer protocol that `rippled` servers use to communicate with each other, ledger objects are represented in their raw binary format. In other [`rippled` APIs](reference-rippled.html), ledger objects are represented as JSON objects.
{% include 'ledger-objects/accountroot.md' %}
{% include 'ledger-objects/amendments.md' %}
{% include 'ledger-objects/check.md' %}
{% include 'ledger-objects/directorynode.md' %}
{% include 'ledger-objects/escrow.md' %}
{% include 'ledger-objects/feesettings.md' %}
{% include 'ledger-objects/ledgerhashes.md' %}
{% include 'ledger-objects/offer.md' %}
{% include 'ledger-objects/paychannel.md' %}
{% include 'ledger-objects/ripplestate.md' %}
{% include 'ledger-objects/signerlist.md' %}
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/tx-type-links.md' %}

36
content/references/rippled-api/ledger-data-formats/ledger-header.md Normal file
View File

@@ -0,0 +1,36 @@
# Ledger Header
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
Every ledger version 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`](#ledger-index) | String | UInt32 | The sequence number 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](#sha512half) of the ledger header, excluding the `ledger_hash` itself. This serves as a unique identifier for this ledger and all its contents. |
| `account_hash` | String | Hash256 | The [SHA-512Half](#sha512half) of this ledger's state tree information. |
| `close_time` | Number | UInt32 | The approximate time this ledger closed, as the number of seconds since the Ripple Epoch of 2000-01-01 00:00:00. This value is rounded based on the `close_time_resolution`, so later ledgers can have the same value. |
| `closed` | Boolean | bool | 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 that was used to build 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][XRP, in drops] 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](#sha512half) of the transactions included in this ledger. |
| `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. |
| [`closeFlags`](#close-flags) | (Omitted) | UInt8 | A bit-map of flags relating to the closing of this ledger. |
## Ledger Index
{% include '_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, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger version contains a `close_time` value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.)
The `closeFlags` field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

19
content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
View File

@@ -1,7 +1,9 @@
## AccountRoot
# AccountRoot
[[Source]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L27 "Source")
The `AccountRoot` object type describes a single _account_ object. Example `AccountRoot` object:
The `AccountRoot` object type describes a single [account](accounts.html), its settings, and XRP balance.
## Example {{currentpage.name}} JSON
```json
{
@@ -22,6 +24,8 @@ The `AccountRoot` object type describes a single _account_ object. Example `Acco
}
```
## {{currentpage.name}} Fields
The `AccountRoot` object has the following fields:
| Field | JSON Type | [Internal Type][] | Description |
@@ -44,13 +48,13 @@ The `AccountRoot` object has the following fields:
| `WalletLocator` | String | Hash256 | _(Optional)_ **DEPRECATED**. Do not use. |
| `WalletSize` | Number | UInt32 | _(Optional)_ **DEPRECATED**. Do not use. |
### AccountRoot Flags
## AccountRoot Flags
There are several options which can be either enabled or disabled for an account. These options can be changed with an [AccountSet transaction][]. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags 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 flag values:
| Flag Name | Hex Value | Decimal Value | Description | Corresponding [AccountSet Flag](reference-transaction-format.html#accountset-flags) |
| Flag Name | Hex Value | Decimal Value | Description | Corresponding [AccountSet Flag](accountset.html#accountset-flags) |
|-----------|-----------|---------------|-------------|-------------------------------|
| lsfDefaultRipple | 0x00800000 | 8388608 | Enable [rippling](concept-noripple.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. | asfDefaultRipple |
| lsfDepositAuth | 0x01000000 | 16777216 | This account can only receive funds from transactions it sends. (It has [DepositAuth](concept-depositauth.html) enabled.) | asfDepositAuth |
@@ -62,9 +66,14 @@ AccountRoot objects can have the following flag values:
| lsfRequireAuth | 0x00040000 | 262144 | This account must individually approve other users for those users to hold this account's issuances. | asfRequireAuth |
| lsfRequireDestTag | 0x00020000 | 131072 | Requires incoming payments to specify a Destination Tag. | asfRequireDest |
### AccountRoot ID Format
## AccountRoot ID Format
The ID of an AccountRoot object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Account space key (`0x0061`)
* The AccountID of the account
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

13
content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md
View File

@@ -1,9 +1,9 @@
## Amendments
# Amendments
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/LedgerFormats.cpp#L110-L113 "Source")
The `Amendments` object type contains a list of [Amendments](concept-amendments.html) that are currently active. Each ledger version contains **at most one** `Amendments` object.
Example `Amendments` object:
## Example {{currentpage.name}} JSON
```json
{
@@ -27,6 +27,8 @@ Example `Amendments` object:
}
```
## {{currentpage.name}} Fields
| Name | JSON Type | [Internal Type][] | Description |
|-------------------|-----------|-------------------|-------------|
| `Amendments` | Array | STI_VECTOR256 | _(Optional)_ Array of 256-bit [amendment IDs](concept-amendments.html#about-amendments) for all currently-enabled amendments. If omitted, there are no enabled amendments. |
@@ -45,7 +47,7 @@ In the [amendment process](concept-amendments.html#amendment-process), a consens
**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.
### Amendments ID Format
## Amendments ID Format
The `Amendments` object ID is the hash of the `Amendments` space key (`0x0066`) only. This means that the ID of the `Amendments` object in a ledger is always:
@@ -54,3 +56,8 @@ The `Amendments` object ID is the hash of the `Amendments` space key (`0x0066`)
```
(Don't mix up the ID of the `Amendments` ledger object type with the Amendment ID of an individual amendment.)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

15
content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md
View File

@@ -1,9 +1,11 @@
## Check
# Check
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/LedgerFormats.cpp#L158 "Source")
_Requires the [Checks Amendment](reference-amendments.html#checks)._
A `Check` object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an [Escrow](concept-escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.) Example `Check` object:
A `Check` object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an [Escrow](concept-escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.)
## Example {{currentpage.name}} JSON
```json
{
@@ -24,6 +26,8 @@ A `Check` object describes a check, similar to a paper personal check, which can
}
```
## {{currentpage.name}} Fields
A `Check` object has the following fields:
| Field | JSON Type | [Internal Type][] | Description |
@@ -44,7 +48,7 @@ A `Check` object has the following fields:
| `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this Check, such as a hosted recipient at the sender's address. |
### Check ID Format
## Check ID Format
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L193-L200 "Source")
The ID of a `Check` object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
@@ -52,3 +56,8 @@ The ID of a `Check` object is the [SHA-512Half](#sha512half) of the following va
* The Check space key (`0x0043`)
* The AccountID of the sender of the [CheckCreate transaction][] that created the `Check` object
* The Sequence number of the [CheckCreate transaction][] that created the `Check` object
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

13
content/references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md
View File

@@ -1,4 +1,4 @@
## DirectoryNode
# DirectoryNode
[[Source]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
The `DirectoryNode` object type provides a list of links to other objects in the ledger's state tree. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 [IDs](#tree-format) of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.
@@ -8,7 +8,7 @@ There are two kinds of Directories:
* **Owner directories** list other objects owned by an account, such as `RippleState` or `Offer` objects.
* **Offer directories** list the offers available in the distributed exchange. A single Offer directory contains all the offers that have the same exchange rate for the same issuances.
Example Directories:
## Example {{currentpage.name}} JSON
<!-- MULTICODE_BLOCK_START -->
@@ -49,6 +49,8 @@ Example Directories:
<!-- MULTICODE_BLOCK_END -->
## {{currentpage.name}} Fields
| Name | JSON Type | [Internal Type][] | Description |
|-------------------|-----------|---------------|-------------|
| `LedgerEntryType` | String | UInt16 | The value `0x0064`, mapped to the string `DirectoryNode`, indicates that this object is part of a Directory. |
@@ -64,7 +66,7 @@ Example Directories:
| `TakerGetsCurrency` | String | Hash160 | (Offer Directories only) The currency code of the TakerGets amount from the offers in this directory. |
| `TakerGetsIssuer` | String | Hash160 | (Offer Directories only) The issuer of the TakerGets amount from the offers in this directory. |
### Directory ID Formats
## Directory ID Formats
There are three different formulas for creating the ID of a DirectoryNode, depending on which of the following the DirectoryNode represents:
@@ -92,3 +94,8 @@ The lower 64 bits of an Offer Directory's ID represent the TakerPays amount divi
* 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.)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

13
content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
View File

@@ -1,4 +1,4 @@
## Escrow
# Escrow
[[Source]<br>](https://github.com/ripple/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101 "Source")
_(Requires the [Escrow Amendment](reference-amendments.html#escrow).)_
@@ -10,7 +10,7 @@ An `Escrow` object is associated with two addresses:
- The owner, who provides the XRP when creating the `Escrow` object. If the held payment is canceled, the XRP returns to the owner.
- The destination, where the XRP is paid when the held payment succeeds. The destination can be the same as the owner.
Example `Escrow` object:
## Example {{currentpage.name}} JSON
```json
{
@@ -32,6 +32,8 @@ Example `Escrow` object:
}
```
## {{currentpage.name}} Fields
An `Escrow` object has the following fields:
| Name | JSON Type | [Internal Type][] | Description |
@@ -52,10 +54,15 @@ An `Escrow` object has the following fields:
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. |
### Escrow ID Format
## Escrow ID Format
The ID of an `Escrow` object is the [SHA-512Half](#sha512half) 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` object
* The Sequence number of the [EscrowCreate transaction][] that created the `Escrow` object
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

13
content/references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.md
View File

@@ -1,8 +1,10 @@
## FeeSettings
# FeeSettings
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120 "Source")
The `FeeSettings` object type contains the current base [transaction cost](concept-transaction-cost.html) and [reserve amounts](concept-reserves.html) as determined by [fee voting](concept-fee-voting.html). Each ledger version contains **at most one** `FeeSettings` object.
## Example {{currentpage.name}} JSON
Example `FeeSettings` object:
```json
@@ -17,6 +19,8 @@ Example `FeeSettings` object:
}
```
## {{currentpage.name}} Fields
The `FeeSettings` object has the following fields:
| Name | JSON Type | [Internal Type][] | Description |
@@ -30,10 +34,15 @@ The `FeeSettings` object has the following fields:
**Warning:** The JSON format for this ledger object type is unusual. The `BaseFee`, `ReserveBase`, and `ReserveIncrement` indicate drops of XRP but ***not*** in the usual format for [specifying XRP](reference-rippled.html#specifying-currency-amounts).
### FeeSettings ID Format
## FeeSettings ID Format
The `FeeSettings` object ID is the hash of the `FeeSettings` space key (`0x0065`) only. This means that the ID of the `FeeSettings` object in a ledger is always:
```
4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651
```
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

17
content/references/rippled-api/ledger-data-formats/ledger-object-types/ledger-object-types.md Normal file
View File

@@ -0,0 +1,17 @@
# Ledger Object Types
There are several different kinds of objects that can appear in the ledger's state tree:
* [**AccountRoot** - The settings, XRP balance, and other metadata for one account.](accountroot.html)
* [**Amendments** - Singleton object with status of enabled and pending amendments.](amendments.html)
* [**Check** - A check that can be redeemed for money by its destination.](check.html)
* [**DirectoryNode** - Contains links to other objects.](directorynode.html)
* [**Escrow** - Contains XRP held for a conditional payment.](escrow.html)
* [**FeeSettings** - Singleton object with consensus-approved base transaction cost and reserve requirements.](feesettings.html)
* [**LedgerHashes** - Lists of prior ledger versions' hashes for history lookup.](ledgerhashes.html)
* [**Offer** - An offer to exchange currencies, known in finance as an _order_.](offer.html)
* [**PayChannel** - A channel for asynchronous XRP payments.](paychannel.html)
* [**RippleState** - Links two accounts, tracking the balance of one currency between them. The concept of a _trust line_ is really an abstraction of this object type.](ripplestate.html)
* [**SignerList** - A list of addresses for multi-signing transactions.](signerlist.html)
Each ledger object consists of several fields. In the peer protocol that `rippled` servers use to communicate with each other, ledger objects are represented in their raw binary format. In [`rippled` APIs](rippled-apis.html), ledger objects are represented as JSON objects.

13
content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md
View File

@@ -1,4 +1,4 @@
## LedgerHashes
# LedgerHashes
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L104-L107 "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.)
@@ -42,13 +42,13 @@ A `LedgerHashes` object has the following fields:
| `Hashes` | Array of Strings | STI_VECTOR256 | An array of up to 256 ledger hashes. The contents depend on which sub-type of `LedgerHashes` object this is. |
| `Flags` | Number | UInt32 | A bit-map of boolean flags for this object. No flags are defined for this type. |
### Recent History LedgerHashes
## 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
## 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.
@@ -56,7 +56,7 @@ The "previous history" `LedgerHashes` entries collectively contain the hash of e
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.
### LedgerHashes ID Formats
## LedgerHashes ID Formats
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/Indexes.cpp#L28-L43)
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.
@@ -69,3 +69,8 @@ The **"previous history"** `LedgerHashes` objects have an ID that is the [SHA-51
- The 32-bit [ledger index](#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.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

15
content/references/rippled-api/ledger-data-formats/ledger-object-types/offer.md
View File

@@ -1,11 +1,11 @@
## Offer
# Offer
[[Source]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57 "Source")
The `Offer` object type describes an offer to exchange currencies, more traditionally known as an _order_, in the XRP Ledger's distributed exchange. An [OfferCreate transaction][] only creates an `Offer` object 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. However, `rippled` automatically prunes any unfunded offers it happens across in the course of transaction processing (and _only_ transaction processing, because the ledger state must only be changed by transactions). For more information, see [lifecycle of an offer](reference-transaction-format.html#lifecycle-of-an-offer).
Example `Offer` object:
## Example {{currentpage.name}} JSON
```json
{
@@ -28,6 +28,8 @@ Example `Offer` object:
}
```
## {{currentpage.name}} Fields
An `Offer` object has the following fields:
| Name | JSON Type | [Internal Type][] | Description |
@@ -45,7 +47,7 @@ An `Offer` object has the following fields:
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. |
| `Expiration` | Number | UInt32 | (Optional) Indicates the time after which this offer is considered unfunded. See [Specifying Time](reference-rippled.html#specifying-time) for details. |
### Offer Flags
## Offer Flags
There are several options which can be either enabled or disabled when an [OfferCreate transaction][] creates an offer object. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags 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_.
@@ -56,10 +58,15 @@ There are several options which can be either enabled or disabled when an [Offer
| lsfPassive | 0x00010000 | 65536 | The object was placed as a passive offer. This has no effect on the object in the ledger. | tfPassive |
| lsfSell | 0x00020000 | 131072 | The object was placed as a sell offer. This has no effect on the object in the ledger (because tfSell only matters if you get a better rate than you asked for, which cannot happen after the object enters the ledger). | tfSell |
### Offer ID Format
## Offer ID Format
The ID of an `Offer` object is the [SHA-512Half](#sha512half) 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
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

28
content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
View File

@@ -1,4 +1,4 @@
## PayChannel
# PayChannel
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/LedgerFormats.cpp#L134 "Source")
_(Requires the [PayChan Amendment](reference-amendments.html#paychan).)_
@@ -11,9 +11,7 @@ When a payment channel expires, at first it remains on the ledger, because only
For an example of using payment channels, see the [Payment Channels Tutorial](tutorial-paychan.html).
<!--{# TODO: provide cross-references to tutorial, concept, and tx types when they are ready #}-->
Example `PayChannel` object:
## Example {{currentpage.name}} JSON
```json
{
@@ -36,6 +34,8 @@ Example `PayChannel` object:
}
```
## {{currentpage.name}} Fields
A `PayChannel` object has the following fields:
| Name | JSON Type | [Internal Type][] | Description |
@@ -53,16 +53,15 @@ A `PayChannel` object has the following fields:
| `Flags` | Number | UInt32 | A bit-map of boolean flags enabled for this payment channel. Currently, the protocol defines no flags for `PayChannel` objects. |
| `Expiration` | Number | UInt32 | _(Optional)_ The mutable expiration time for this payment channel, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). The channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](#header-format). See [Setting Channel Expiration](#setting-channel-expiration) for more details. |
| `CancelAfter` | Number | UInt32 | _(Optional)_ The immutable expiration time for this payment channel, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). This channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](#header-format). This is optionally set by the transaction that created the channel, and cannot be changed. |
| `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this payment channel, such as a hosted recipient at the owner's address. |
| `DestinationTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. |
| `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this payment channel, such as a hosted recipient at the owner's address. |
| `DestinationTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. |
[XRP, in drops]: reference-rippled.html#specifying-currency-amounts
### Setting Channel Expiration
## Setting 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](#header-format) of the previous ledger. The `Expiration` field is omitted when a `PayChannel` object is created. There are several ways the `Expiration` field of a `PayChannel` object 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.
#### Source Address
### 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:
@@ -78,16 +77,16 @@ The source address can also set the `Expiration` with the `tfClose` flag of the
The source address can remove the `Expiration` with the `tfRenew` flag of the PaymentChannelClaim transaction type.
#### Destination Address
### 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
### 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.
### PayChannel ID Format
## PayChannel ID Format
The ID of a `PayChannel` object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
@@ -95,3 +94,8 @@ The ID of a `PayChannel` object is the [SHA-512Half](#sha512half) of the followi
* The AccountID of the source account
* The AccountID of the destination account
* The Sequence number of the transaction that created the channel
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

19
content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md
View File

@@ -1,11 +1,11 @@
## RippleState
# RippleState
[[Source]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L70 "Source")
The `RippleState` object type connects two accounts in a single currency. Conceptually, a `RippleState` object represents two _trust lines_ between the accounts, one from each side. Each account can change the settings for its side of the `RippleState` object, 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, so `rippled` deletes `RippleState` objects when their properties are entirely default.
Since no account is privileged in the XRP Ledger, a `RippleState` object sorts their account addresses numerically, to ensure a canonical form. Whichever address is numerically lower is deemed the "low account" and the other is the "high account".
Example `RippleState` object:
## Example {{currentpage.name}} JSON
```json
{
@@ -34,7 +34,9 @@ Example `RippleState` object:
}
```
A RippleState object has the following fields:
## {{currentpage.name}} Fields
A `RippleState` object has the following fields:
| Name | JSON Type | Internal Type | Description |
|-----------------|-----------|---------------|-------------|
@@ -52,7 +54,7 @@ A RippleState object has the following fields:
| `HighQualityIn` | Number | UInt32 | (Optional) The inbound quality set by the high account, as an integer in the implied ratio HighQualityIn:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. |
| `HighQualityOut` | Number | UInt32 | (Optional) The outbound quality set by the high account, as an integer in the implied ratio HighQualityOut:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. |
### RippleState Flags
## RippleState Flags
There are several options which can be either enabled or disabled for a trust line. These options can be changed with a [TrustSet transaction](reference-transaction-format.html#trustset). In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags 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_.
@@ -69,7 +71,7 @@ RippleState objects can have the following flag values:
| lsfLowFreeze | 0x00400000 | 4194304 | The low account has frozen the trust line, preventing the high account from transferring the asset. | tfSetFreeze |
| lsfHighFreeze | 0x00800000 | 8388608 | The high account has frozen the trust line, preventing the low account from transferring the asset. | tfSetFreeze |
### Contributing to the Owner Reserve
## Contributing to the Owner Reserve
If an account modifies a trust line to put it in a non-default state, then that trust line counts towards the account's [owner reserve](concept-reserves.html#owner-reserves). In a RippleState object, the `lsfLowReserve` and `lsfHighReserve` flags indicate which account(s) are responsible for the owner reserve. The `rippled` server automatically sets these flags when it modifies a trust line.
@@ -92,7 +94,7 @@ The default state of the two NoRipple flags depends on the state of the [lsfDefa
Fortunately, `rippled` 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 DefaultRipple flag, that account's reserve stays the same initially. If an account modifies a trust line, `rippled` re-evaluates whether that individual trust line is in its default state and should contribute to the owner reserve.
### RippleState ID Format
## RippleState ID Format
The ID of a RippleState object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
@@ -100,3 +102,8 @@ The ID of a RippleState object is the [SHA-512Half](#sha512half) of the followin
* The AccountID of the low account
* The AccountID of the high account
* The 160-bit currency code of the trust line(s)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

17
content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
View File

@@ -1,9 +1,9 @@
## SignerList
# SignerList
[[Source]<br>](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
The `SignerList` object type 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 SignerList using the [SignerListSet transaction type](reference-transaction-format.html#signerlistset). This object type is introduced by the [MultiSign amendment](reference-amendments.html#multisign). [New in: rippled 0.31.0][]
Example SignerList object:
## Example {{currentpage.name}} JSON
```json
{
@@ -38,7 +38,9 @@ Example SignerList object:
}
```
A SignerList object has the following fields:
## {{currentpage.name}} Fields
A `SignerList` object has the following fields:
| Name | JSON Type | Internal Type | Description |
|-----------------|-----------|---------------|-------------|
@@ -64,14 +66,19 @@ Each member of the `SignerEntries` field is an object that describes that signer
When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot object](#accountroot), then only the master secret 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.
### SignerLists and Reserves
## SignerLists and Reserves
A SignerList contributes to its owner's [reserve requirement](concept-reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) object in the ledger.
### SignerList ID Format
## SignerList ID Format
The ID of a SignerList object is the SHA-512Half of the following values, concatenated in order:
* The RippleState space key (`0x0053`)
* The AccountID of the owner of the SignerList
* The SignerListID (currently always `0`)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

121
dactyl-config.yml
View File

@@ -682,27 +682,29 @@ pages:
supercategory: rippled API
category: Ledger Data Formats
blurb: Learn about individual data objects that comprise the XRP Ledger's shared state.
template: template-landing-children.html
template: template-landing-children.html #TODO: consider using the default template instead for page sidebar?
targets:
- local
- name: Ledger Header #TODO: break off from ledger-format-old-monolith.md file
- md: references/rippled-api/ledger-data-formats/ledger-header.md
html: ledger-header.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
blurb: A unique header that describes the contents of a ledger version.
targets:
- local
- name: Ledger Object Types #TODO: break off from ledger-format-old-monolith.md file
- md: references/rippled-api/ledger-data-formats/ledger-object-types/ledger-object-types.md
html: ledger-object-types.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
template: template-landing-children.html
template: template-landing-children.html #TODO: consider dropping the md since the page children handles this OK
blurb: Specifications for the types of objects that can be stored in a ledger's state tree.
targets:
- local
@@ -713,10 +715,119 @@ pages:
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: The settings, XRP balance, and other metadata for one account.
targets:
- local
# TODO: 10 other ledger object types
- md: references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md
html: amendments-object.html #amendments.html is taken by the concept page
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: Singleton object with status of enabled and pending amendments.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/check.md
html: check.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: A check that can be redeemed for money by its destination.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md
html: directorynode.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: Contains links to other objects.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
html: escrow-object.html #escrow.html is taken by the concept page
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: Contains XRP held for a conditional payment.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.md
html: feesettings.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: Singleton object with consensus-approved base transaction cost and reserve requirements.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md
html: ledgerhashes.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: Lists of prior ledger versions' hashes for history lookup.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/offer.md
html: offer.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: An order to make a currency trade.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
html: paychannel.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: A channel for asynchronous XRP payments.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md
html: ripplestate.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: Links two accounts, tracking the balance of one currency between them. The concept of a trust line is an abstraction of this object type.
targets:
- local
- md: references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
html: signerlist.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Ledger Data Formats
subcategory: Ledger Object Types
blurb: A list of addresses for multi-signing transactions.
targets:
- local
- md: references/rippled-api/transaction-formats/transaction-formats.md
html: transaction-formats.html