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

Ledger entries: clean up reference for consistency

Browse Source
This commit is contained in:
mDuo13
2023-09-18 16:41:21 -07:00
parent 047da87b49
commit 52b100b004
42 changed files with 408 additions and 319 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
content/concepts/ledgers/ledger-object-ids.ja.md
View File

@@ -1,24 +0,0 @@
---
html: ledger-object-ids.html
parent: ledger-data-formats.html
blurb: レジャーの状態ツリーのすべてのオブジェクトには一意のIDがあります。
labels:
- データ保持
---
# レジャーオブジェクトID
<a id="sha512half"></a>
レジャーの状態ツリーのすべてのオブジェクトには一意のIDがあります。このフィールドは、オブジェクトの内容と同じレベルでJSONの`index`フィールドとして返されます。IDは、オブジェクトの重要な内容をハッシュし、[名前空間ID](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L99)を使用して生成されます。[レジャーオブジェクトタイプ](ledger-object-types.html)により、使用する名前空間IDとハッシュに含める内容が決定します。これにより、すべてのIDが一意になります。ハッシュを計算するため、`rippled`はSHA-512を使用し、その結果を最初の256バイトで切り捨てます。**SHA-512ハーフ**と呼ばれるこのアルゴリズム出力は、SHA-256と同等のセキュリティで、64ビットプロセッサーでは実行にかかる時間が短くなります。
{{ include_svg("img/ledger-object-ids.ja.svg", "図: rippledによる、SHA-512ハーフを使用したレジャーオブジェクトIDの生成。スペースキーは、異なるオブジェクトタイプIDの競合を防止します。") }}
## 関連項目
- XRP Ledgerでは、ハッシュがどのように生成、使用されているかについての詳細は、[ハッシュ](basic-data-types.html#ハッシュ)を参照してください。
- レジャーの基本的な説明については、[レジャー](ledgers.html)を参照してください。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

30
content/concepts/ledgers/ledger-object-ids.md
View File

@@ -1,30 +0,0 @@
---
html: ledger-object-ids.html
parent: ledger-data-formats.html
blurb: All objects in a ledger's state tree have a unique ID.
labels:
- Data Retention
---
# Ledger Object IDs
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp)
<a id="sha512half"></a>
Each [object in a ledger's state data](ledger-object-types.html) has a unique ID. The ID is derived by hashing important contents of the object, along with a [namespace identifier](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L99). The [ledger object type](ledger-object-types.html) 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 bits. This algorithm, informally called **SHA-512Half**, provides an output that has comparable security to SHA-256, but runs faster on 64-bit processors.
Generally, a ledger object's ID is returned as the `index` field in JSON, at the same level as the object's contents. In [transaction metadata](transaction-metadata.html), the ledger object's ID in JSON is `LedgerIndex`.
**Tip:** The `index` or `LedgerIndex` field of an object in the ledger is the ledger object ID. This is not the same as a [ledger index][].
{{ include_svg("img/ledger-object-ids.svg", "Diagram: rippled uses SHA-512Half to generate IDs for ledger objects. The space key prevents IDs for different object types from colliding.") }}
## See Also
- For more information how the XRP Ledger creates and uses hashes, see [Hashes](basic-data-types.html#hashes).
- For ledger basics, see [Ledgers](ledgers.html).
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/references/protocol-reference/ledger-data/ledger-data-formats.ja.md
View File

@@ -2,8 +2,6 @@
html: ledger-data-formats.html
parent: protocol-reference.html
blurb: XRP Ledgerの共有状態を構成する個別のデータオブジェクトについて説明します。
labels:
- データ保持
---
# レジャーのデータ型

2
content/references/protocol-reference/ledger-data/ledger-data-formats.md
View File

@@ -2,8 +2,6 @@
html: ledger-data-formats.html
parent: protocol-reference.html
blurb: Learn about individual entries that comprise the XRP Ledger's shared state data.
labels:
- Data Retention
---
# Ledger Data Formats

39
content/references/protocol-reference/ledger-data/ledger-entry-common-fields.md Normal file
View File

@@ -0,0 +1,39 @@
---
html: ledger-entry-common-fields.html
blurb: 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](ledgers.html)'s state data has the same set of common fields, plus additional fields based on the [ledger entry type](ledger-entry-types.html). 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.html) 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.html) 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](transaction-metadata.html), 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.
{{ include_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`.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/references/protocol-reference/ledger-data/ledger-entry-types/accountroot.ja.md
View File

@@ -1,6 +1,6 @@
---
html: accountroot.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: あるアカウントの設定、XRP残高、その他のメタデータです。
labels:
- アカウント

30
content/references/protocol-reference/ledger-data/ledger-entry-types/accountroot.md
View File

@@ -1,6 +1,6 @@
---
html: accountroot.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: The settings, XRP balance, and other metadata for one account.
labels:
- Accounts
@@ -34,7 +34,7 @@ An `AccountRoot` ledger entry type describes a single [account](accounts.html),
## {{currentpage.name}} Fields
An `AccountRoot` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:------------------------------|:----------|:------------------|:----------|:-------------|
@@ -46,7 +46,6 @@ An `AccountRoot` object has the following fields:
| `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](non-fungible-tokens.html). _(Added by the [fixNFTokenRemint amendment][] :not_enabled:)_ |
| [`Flags`](#accountroot-flags) | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this account. |
| `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](non-fungible-tokens.html) have been minted by and on behalf of this account. _(Added by the [NonFungibleTokensV1_1 amendment][])_ |
@@ -83,20 +82,20 @@ Other than those exceptions, these accounts are like ordinary accounts; the LP T
## 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`**.
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 flag values:
AccountRoot objects can have the following flags combined in the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Corresponding [AccountSet Flag](accountset.html#accountset-flags) | Description |
|-----------------------------------|--------------|-------------------|-----------------------------------|----|
`lsfAllowTrustLineClawback` | `0x80000000` | 2147483648 | `asfAllowTrustLineClawback` | Enable [Clawback](clawing-back-tokens.html) for this account. |
|`lsfDefaultRipple` | `0x00800000` | 8388608 | `asfDefaultRipple` | Enable [rippling](rippling.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. |
| `lsfAllowTrustLineClawback` | `0x80000000` | 2147483648 | `asfAllowTrustLineClawback` | Enable [Clawback](clawing-back-tokens.html) for this account. _(Requires the [Clawback amendment][].)_ |
| `lsfDefaultRipple` | `0x00800000` | 8388608 | `asfDefaultRipple` | Enable [rippling](rippling.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. |
| `lsfDepositAuth` | `0x01000000` | 16777216 | `asfDepositAuth` | This account has [DepositAuth](depositauth.html) enabled, meaning it can only receive funds from transactions it sends, and from [preauthorized](depositauth.html#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. _(Requires the [DisallowIncoming amendment][] :not_enabled:.)_ |
| `lsfDisallowIncomingNFTokenOffer` | `0x04000000` | 67108864 | `asfDisallowIncomingNFTokenOffer` | This account blocks incoming NFTokenOffers. _(Requires the [DisallowIncoming amendment][] :not_enabled:.)_ |
| `lsfDisallowIncomingPayChan` | `0x10000000` | 268435456 | `asfDisallowIncomingPayChan` | This account blocks incoming Payment Channels. _(Requires the [DisallowIncoming amendment][] :not_enabled:.)_ |
| `lsfDisallowIncomingTrustline` | `0x20000000` | 536870912 | `asfDisallowIncomingTrustline` | This account blocks incoming trust lines. _(Requires the [DisallowIncoming amendment][] :not_enabled:.)_ |
| `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. |
@@ -104,10 +103,15 @@ AccountRoot objects can have the following flag values:
| `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. |
## {{currentpage.name}} Reserve
## AccountRoot ID Format
The [reserve](reserves.html) for an AccountRoot entry is the base reserve, currently {{target.base_reserve}}, except in the case of a special AMM AccountRoot.
The ID of an AccountRoot object is the [SHA-512Half][] of the following values, concatenated in order:
This XRP cannot be sent to others but it can be burned as part of the [transaction cost][].
## {{currentpage.name}} 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

2
content/references/protocol-reference/ledger-data/ledger-entry-types/amendments.ja.md
View File

@@ -1,6 +1,6 @@
---
html: amendments-object.html #amendments.html is taken by the concept page
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 有効化されているAmendmentと保留中のAmendmentのステータスを持つシングルトンオブジェクトです。
labels:
- ブロックチェーン

24
content/references/protocol-reference/ledger-data/ledger-entry-types/amendments.md
View File

@@ -1,14 +1,14 @@
---
html: amendments-object.html #amendments.html is taken by the concept page
parent: ledger-object-types.html
blurb: Singleton object with status of enabled and pending amendments.
parent: ledger-entry-types.html
blurb: 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` object type contains a list of [Amendments](amendments.html) that are currently active. Each ledger version contains **at most one** `Amendments` object.
The `Amendments` ledger entry type contains a list of [Amendments](amendments.html) that are currently active. Each ledger version contains **at most one** `Amendments` entry.
## Example {{currentpage.name}} JSON
@@ -36,6 +36,8 @@ The `Amendments` object type contains a list of [Amendments](amendments.html) th
## {{currentpage.name}} Fields
In addition to the [common fields](ledger-entry-common-fields.html), the `{{currentpage.name}}` ledger entry has the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|-------------------|-----------|-------------------|-----------|-------------|
| `Amendments` | Array | Vector256 | No | Array of 256-bit [amendment IDs](amendments.html) for all currently enabled amendments. If omitted, there are no enabled amendments. |
@@ -54,15 +56,25 @@ In the [amendment process](amendments.html#amendment-process), a consensus of va
**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
## {{currentpage.name}} Flags
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:
There are no flags defined for the `{{currentpage.name}}` entry.
## {{currentpage.name}} Reserve
The `{{currentpage.name}}` entry does not require a reserve.
## {{currentpage.name}} 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 object type with the Amendment ID of an individual amendment.)
(Don't mix up the ID of the `Amendments` ledger entry type with the Amendment ID of an individual amendment.)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/references/protocol-reference/ledger-data/ledger-entry-types/amm.ja.md
View File

@@ -1,6 +1,6 @@
---
html: amm.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 自動マーケットメーカー（AMM）インスタンスの定義と詳細。
labels:
- AMM

19
content/references/protocol-reference/ledger-data/ledger-entry-types/amm.md
View File

@@ -1,6 +1,6 @@
---
html: amm.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: The definition and details of an Automated Market Maker (AMM) instance.
labels:
- AMM
@@ -11,7 +11,7 @@ status: not_enabled
_(Requires the [AMM amendment][] :not_enabled:)_
The `AMM` object type describes a single [Automated Market Maker](automated-market-makers.html) (AMM) instance.
An `AMM` ledger entry describes a single [Automated Market Maker](automated-market-makers.html) (AMM) instance. This is always paired with a [special AccountRoot entry](#special-amm-accountroot-objects).
## Example AMM JSON
@@ -69,7 +69,7 @@ The `AMM` object type describes a single [Automated Market Maker](automated-mark
## AMM Fields
The `AMM` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:-----------------|:--------------------|:------------------|:----------|--------------|
@@ -103,13 +103,20 @@ The `VoteSlots` field contains an array of `VoteEntry` objects with the followin
| `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. |
## AMM Flags
There are currently no flags defined for `AMM` objects.
## {{currentpage.name}} Reserve
`{{currentpage.name}}` entries do not require a reserve.
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## AMM ID Format
The ID of an `AMM` object is the [SHA-512Half][] of the following values, concatenated in order:
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.

2
content/references/protocol-reference/ledger-data/ledger-entry-types/check.ja.md
View File

@@ -1,6 +1,6 @@
---
html: check.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 送信先が清算して資金にできるCheckです。
labels:
- Checks

25
content/references/protocol-reference/ledger-data/ledger-entry-types/check.md
View File

@@ -1,6 +1,6 @@
---
html: check.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: A check that can be redeemed for money by its destination.
labels:
- Checks
@@ -10,7 +10,7 @@ labels:
_(Added by the [Checks amendment][].)_
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](escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.)
A `Check` entry describes a [check](checks.html), similar to a paper personal check, which can be cashed by its destination to get money from its sender.
## Example {{currentpage.name}} JSON
@@ -35,7 +35,7 @@ A `Check` object describes a check, similar to a paper personal check, which can
## {{currentpage.name}} Fields
A `Check` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Field | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:-----------------|:------------------|:----------|:----------------|
@@ -44,10 +44,9 @@ A `Check` object has the following fields:
| `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. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Check` objects. The value is always `0`. |
| `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. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
| `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. |
@@ -55,14 +54,24 @@ A `Check` object has the following fields:
| `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. |
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## {{currentpage.name}} Reserve
`{{currentpage.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` object is the [SHA-512Half][] of the following values, concatenated in order:
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` object
* The `Sequence` number of the [CheckCreate transaction][] that created the `Check` object.
* 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](tickets.html), use the `TicketSequence` value instead.
See the tutorial showing how to [Send a Check](send-a-check.html).

2
content/references/protocol-reference/ledger-data/ledger-entry-types/depositpreauth.ja.md
View File

@@ -1,6 +1,6 @@
---
html: depositpreauth-object.html #depositpreauth.html is taken by the tx type
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 承認を必要とするアカウントへの送金ペイメントの事前承認の記録です。
labels:
- セキュリティ

15
content/references/protocol-reference/ledger-data/ledger-entry-types/depositpreauth.md
View File

@@ -1,6 +1,6 @@
---
html: depositpreauth-object.html #depositpreauth.html is taken by the tx type
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: A record of preauthorization for sending payments to an account that requires authorization.
labels:
- Security
@@ -8,7 +8,7 @@ labels:
# DepositPreauth
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L172-L178 "Source")
A `DepositPreauth` object tracks a preauthorization from one account to another. [DepositPreauth transactions][] create these objects.
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](depositauth.html). 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.
@@ -29,19 +29,26 @@ This has no effect on processing of transactions unless the account that provide
## {{currentpage.name}} Fields
A `DepositPreauth` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.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.) |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `DepositPreauth` objects. The value is always `0`. |
| `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. |
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## {{currentpage.name}} Reserve
`{{currentpage.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:

2
content/references/protocol-reference/ledger-data/ledger-entry-types/directorynode.ja.md
View File

@@ -1,6 +1,6 @@
---
html: directorynode.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 他のオブジェクトへのリンクを含みます。
labels:
- 分散型取引所

12
content/references/protocol-reference/ledger-data/ledger-entry-types/directorynode.md
View File

@@ -1,6 +1,6 @@
---
html: directorynode.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: Contains links to other objects.
labels:
- Data Retention
@@ -75,6 +75,16 @@ There are two kinds of Directories:
| `TakerPaysIssuer` | String | Hash160 | No | (Offer Directories only) The issuer of the `TakerPays` amount from the offers in this directory. |
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## {{currentpage.name}} Reserve
`{{currentpage.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:

2
content/references/protocol-reference/ledger-data/ledger-entry-types/escrow.ja.md
View File

@@ -1,6 +1,6 @@
---
html: escrow-object.html #escrow.html is taken by the concept page
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 条件付き決済のために保有されているXRPを含みます。
labels:
- Escrow

50
content/references/protocol-reference/ledger-data/ledger-entry-types/escrow.md
View File

@@ -1,6 +1,6 @@
---
html: escrow-object.html #escrow.html is taken by the concept page
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: Contains XRP held for a conditional payment.
labels:
- Escrow
@@ -10,12 +10,7 @@ labels:
_(Added by the [Escrow amendment][].)_
The `Escrow` object type represents a held payment of XRP waiting to be executed or canceled. An [EscrowCreate transaction][] creates an `Escrow` object in the ledger. A successful [EscrowFinish][] or [EscrowCancel][] transaction deletes the object. If the ``Escrow`` object has a [_crypto-condition_](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), the payment can only succeed if an EscrowFinish transaction provides the corresponding _fulfillment_ that satisfies the condition. (The only supported crypto-condition type is [PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1).) If the `Escrow` object has a `FinishAfter` time, the held payment can only execute after that time.
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.
An `Escrow` ledger entry represents an [escrow](escrow.html), which holds XRP until specific conditions are met.
## Example {{currentpage.name}} JSON
@@ -41,33 +36,42 @@ An `Escrow` object is associated with two addresses:
## {{currentpage.name}} Fields
An `Escrow` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.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 held payment. This is the account that provided the XRP, and gets it back if the held payment is canceled. |
| `Amount` | String | Amount | Yes | The amount of XRP, in drops, to be delivered by the held payment. |
| `CancelAfter` | Number | UInt32 | No | The held payment 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. |
| `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 held payment is successful. |
| `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 held payment, such as a hosted recipient at the destination address. |
| `FinishAfter` | Number | UInt32 | No | The time, in [seconds since the Ripple Epoch][], after which this held payment can be finished. Any [EscrowFinish transaction][] before this time fails. (Specifically, this is compared with the close time of the previous validated ledger.) |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Escrow` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0075`, mapped to the string `Escrow`, indicates that this object is an `Escrow` object. |
| `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. **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. |
| `SourceTag` | Number | UInt32 | No | An arbitrary tag to further specify the source for this held payment, such as a hosted recipient at the owner's address. |
| `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. |
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## {{currentpage.name}} Reserve
`{{currentpage.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` object is the [SHA-512Half][] of the following values, concatenated in order:
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` object
* The Sequence number of the [EscrowCreate transaction][] that created the `Escrow` object
* 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](tickets.html), use the `TicketSequence` value instead.
<!--{# common link defs #}-->

2
content/references/protocol-reference/ledger-data/ledger-entry-types/feesettings.ja.md
View File

@@ -1,6 +1,6 @@
---
html: feesettings.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: コンセンサスで承認された基本トランザクションコストと必要準備金があるシングルトンオブジェクトです。
labels:
- 手数料

17
content/references/protocol-reference/ledger-data/ledger-entry-types/feesettings.md
View File

@@ -1,6 +1,6 @@
---
html: feesettings.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: Singleton object with consensus-approved base transaction cost and reserve requirements.
labels:
- Fees
@@ -8,12 +8,10 @@ labels:
# FeeSettings
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120 "Source")
The `FeeSettings` object type contains the current base [transaction cost](transaction-cost.html) and [reserve amounts](reserves.html) as determined by [fee voting](fee-voting.html). Each ledger version contains **at most one** `FeeSettings` object.
The `FeeSettings` entry contains the current base [transaction cost](transaction-cost.html) and [reserve amounts](reserves.html) as determined by [fee voting](fee-voting.html). Each ledger version contains **at most one** `FeeSettings` entry.
## Example {{currentpage.name}} JSON
Example `FeeSettings` object:
```json
{
"BaseFee": "000000000000000A",
@@ -28,7 +26,7 @@ Example `FeeSettings` object:
## {{currentpage.name}} Fields
The `FeeSettings` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), the `{{currentpage.name}}` ledger entry has the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:-----------------------|
@@ -39,7 +37,7 @@ The `FeeSettings` object has the following fields:
| `ReserveBase` | Number | UInt32 | Yes | The [base reserve](reserves.html#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. |
| `ReserveIncrement` | Number | UInt32 | Yes | The incremental [owner reserve](reserves.html#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
**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][Currency Amount].
**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:
@@ -53,9 +51,14 @@ If the _[XRPFees amendment][]_ is enabled, the `FeeSettings` object has these fi
| `ReserveIncrementDrops` | String | Amount | Yes | The incremental [owner reserve](reserves.html#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
## {{currentpage.name}} Flags
There are no flags defined for the `{{currentpage.name}}` entry.
## 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:
The ID of the `FeeSettings` entry is the hash of the `FeeSettings` space key (`0x0065`) only. This means that the ID is always:
```
4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651

2
content/references/protocol-reference/ledger-data/ledger-entry-types/ledger-object-types.ja.md → content/references/protocol-reference/ledger-data/ledger-entry-types/ledger-entry-types.ja.md
View File

@@ -1,5 +1,5 @@
---
html: ledger-object-types.html
html: ledger-entry-types.html
parent: ledger-data-formats.html
template: pagetype-category.html.jinja
labels:

4
content/references/protocol-reference/ledger-data/ledger-entry-types/ledger-object-types.md → content/references/protocol-reference/ledger-data/ledger-entry-types/ledger-entry-types.md
View File

@@ -1,9 +1,7 @@
---
html: ledger-object-types.html
html: ledger-entry-types.html
parent: ledger-data-formats.html
template: pagetype-category.html.jinja
labels:
- Data Retention
---
# Ledger Object Types

2
content/references/protocol-reference/ledger-data/ledger-entry-types/ledgerhashes.ja.md
View File

@@ -1,6 +1,6 @@
---
html: ledgerhashes.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 履歴検索用に以前のレジャーバージョンのハッシュをリスト表示します。
labels:
- ブロックチェーン

19
content/references/protocol-reference/ledger-data/ledger-entry-types/ledgerhashes.md
View File

@@ -1,6 +1,6 @@
---
html: ledgerhashes.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: Lists of prior ledger versions' hashes for history lookup.
labels:
- Blockchain
@@ -39,22 +39,25 @@ Example `LedgerHashes` object (trimmed for length):
}
```
A `LedgerHashes` object has the following fields:
## {{currentpage.name}} Fields
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:----------------------|:-----------------|:------------------|:----------|:------------|
| `FirstLedgerSequence` | Number | UInt32 | Yes | **DEPRECATED** Do not use. (The "recent hashes" object of the production XRP Ledger has the value `2` in this field as a result of a previous `rippled` software. 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](parallel-networks.html) started with more recent versions of `rippled`.) |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `LedgerHashes` objects. The value is always `0`. |
| `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](parallel-networks.html) 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 | Yes | The [Ledger Index][] of the last entry in this object's `Hashes` array. |
| `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.
@@ -63,6 +66,12 @@ 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.
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## LedgerHashes ID Formats
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L26-L42)

2
content/references/protocol-reference/ledger-data/ledger-entry-types/negativeunl.ja.md
View File

@@ -1,6 +1,6 @@
---
html: negativeunl.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 現在オフラインと思われるバリデーターの一覧を表します。
labels:
- ブロックチェーン

20
content/references/protocol-reference/ledger-data/ledger-entry-types/negativeunl.md
View File

@@ -1,6 +1,6 @@
---
html: negativeunl.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: List of validators currently believed to be offline.
labels:
- Blockchain
@@ -9,9 +9,9 @@ labels:
_(Added by the [NegativeUNL amendment][].)_
The `NegativeUNL` object type contains the current status of the [Negative UNL](negative-unl.html), a list of trusted validators currently believed to be offline.
The `NegativeUNL` ledger entry type contains the current status of the [Negative UNL](negative-unl.html), a list of trusted validators currently believed to be offline.
Each ledger version contains **at most one** `NegativeUNL` object. If no validators are currently disabled or scheduled to be disabled, there is no `NegativeUNL` object in the ledger.
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 {{currentpage.name}} JSON
@@ -31,18 +31,18 @@ Each ledger version contains **at most one** `NegativeUNL` object. If no validat
}
```
## {{currentpage.name}} Fields
A `NegativeUNL` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), the `{{currentpage.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. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags. No flags are defined for the NegativeUNL object type, so this value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x004E`, mapped to the string `NegativeUNL`, indicates that this object is the Negative UNL. |
| `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
### 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:
@@ -53,10 +53,14 @@ Each `DisabledValidator` object represents one disabled validator. In JSON, a `D
| `PublicKey` | String | Blob | The master public key of the validator, in hexadecimal. |
## {{currentpage.name}} Flags
There are no flags defined for the `{{currentpage.name}}` entry.
## NegativeUNL ID Format
The `NegativeUNL` object ID is the hash of the `NegativeUNL` space key (`0x004E`) only. This means that the ID of the `NegativeUNL` object in a ledger is always:
The ID of the `NegativeUNL` entry is the hash of the `NegativeUNL` space key (`0x004E`) only. This means that the ID is always:
```
2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244

2
content/references/protocol-reference/ledger-data/ledger-entry-types/nftokenoffer.ja.md
View File

@@ -1,6 +1,6 @@
---
html: nftokenoffer.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: NFTを売買するオファーを作成する。
labels:
- Non-fungible Tokens, NFTs

19
content/references/protocol-reference/ledger-data/ledger-entry-types/nftokenoffer.md
View File

@@ -1,13 +1,13 @@
---
html: nftokenoffer.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: Create offers to buy or sell NFTs.
labels:
- Non-fungible Tokens, NFTs
---
# NFTokenOffer
Tokens that have the `lsfTransferable` flag set can be transferred among participants using offers. The `NFTokenOffer` object represents an offer to buy, sell or transfer an `NFToken` object. The owner of a `NFToken` can use `NFTokenCreateOffer` to start a transaction.
An `NFTokenOffer` entry represents an offer to buy, sell or transfer an [NFT](non-fungible-tokens.html).
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
@@ -29,15 +29,14 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
```
### NFTokenOffer Fields
### {{currentpage.name}} 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. |
| `Flags` | number | UInt32 | Yes | A set of flags associated with this object, used to specify various options or settings. Flags are listed in the table below. |
| `LedgerEntryType` | string | UInt16 | Yes | The value `0x0074`, mapped to the string `NFTokenOffer`, indicates that this is an offer to trade a `NFToken`. |
| `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. |
@@ -46,13 +45,15 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
| `PreviousTxnLgrSeq` | number | UInt32 | Yes | Index of the ledger that contains the transaction that most recently modified this object. |
## {{currentpage.name}} Flags
#### NFTokenOffer Flags
{{currentpage.name}} 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](offers.html), 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 buy a `NFToken`. Similarly, a seller must _explicitly_ choose to accept a specific `NFTokenOffer` that offers to buy a `NFToken` object that they own.
@@ -64,14 +65,14 @@ The transactions for `NFToken` trading are:
- [NFTokenAcceptOffer][]
### Locating NFTokenOffer objects
## Locating NFTokenOffer entries
Each `NFToken` has two [directories](directorynode.html): one contains offers to buy the token and the other contains offers to sell the token. 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.
Each unique NFT has up to two [directories](directorynode.html): 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
Each `NFTokenOffer` object costs the account placing the offer one incremental reserve. As of this writing the incremental reserve is 2 XRP. The reserve can be recovered by cancelling the offer.
`{{currentpage.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

2
content/references/protocol-reference/ledger-data/ledger-entry-types/nftokenpage.ja.md
View File

@@ -1,6 +1,6 @@
---
html: nftokenpage.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: NFTokenを記録するためのレジャー構造。
labels:
- Non-fungible Tokens, NFTs

33
content/references/protocol-reference/ledger-data/ledger-entry-types/nftokenpage.md
View File

@@ -1,13 +1,13 @@
---
html: nftokenpage.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: Ledger structure for recording NFTokens.
labels:
- Non-fungible Tokens, NFTs
---
# NFTokenPage
The `NFTokenPage` object represents a collection of `NFToken` objects owned by the same account. An account can have multiple `NFTokenPage` ledger objects, which form a doubly linked list.
The `NFTokenPage` object represents a collection of [NFTs](non-fungible-tokens.html) owned by the same account. An account can have multiple `NFTokenPage` entries, which form a doubly linked list.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
@@ -39,14 +39,9 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
```
In the interest of minimizing the size of a page and optimizing storage, the `Owner` field is not present, since it is encoded as part of the object's ledger identifier.
## {{currentpage.name}} Fields
An `NFTokenPage` object can have the following required and optional fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Field Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:------------|
@@ -86,22 +81,24 @@ To add an `NFToken`, find the `NFTokenPage` it should be in (using the same tech
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.
## Reserve for NFTokenPage objects
## {{currentpage.name}} Reserve
Each `NFTokenPage` counts as one item towards an account's [owner reserve](reserves.html#owner-reserves). Since each page can hold up to 32 `NFToken` entries, the _effective_ reserve cost per `NFToken` can be as low as _R_/32 where _R_ is the incremental reserve.
Each `NFTokenPage` counts as one item towards its owner's [owner reserve](reserves.html#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 `NFToken` objects, each page can have as few as 16 `NFToken` objects, or as many as 32, with the typical case being around 24 `NFToken` objects per page.
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 `NFToken` objects owned under various scenarios:
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:
| `NFTokens` 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 |
| 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.

2
content/references/protocol-reference/ledger-data/ledger-entry-types/offer.ja.md
View File

@@ -1,6 +1,6 @@
---
html: offer.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 通貨取引を行う注文
labels:
- 分散型取引所

37
content/references/protocol-reference/ledger-data/ledger-entry-types/offer.md
View File

@@ -1,6 +1,6 @@
---
html: offer.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: An order to make a currency trade.
labels:
- Decentralized Exchange
@@ -10,7 +10,7 @@ labels:
The `Offer` ledger entry describes an [Offer](offers.html) to exchange currencies in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). (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 prunes any unfunded Offers that those transactions come across. (Otherwise, unfunded Offers remain, because _only_ transactions can change the ledger state.)
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 {{currentpage.name}} JSON
@@ -38,37 +38,40 @@ An Offer can become unfunded through other activities in the network, while rema
## {{currentpage.name}} Fields
An `Offer` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.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.html) that links to this Offer. |
| `BookNode` | String | UInt64 | Yes | A hint indicating which page of the offer directory links to this object, in case the directory consists of multiple pages. |
| `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. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this offer. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x006F`, mapped to the string `Offer`, indicates that this object describes an Offer. |
| `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. **Note:** The offer 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. |
| `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` object. Used in combination with the `Account` to identify this Offer. |
| `TakerPays` | String or Object | Amount | Yes | The remaining amount and type of currency requested by the Offer creator. |
| `TakerGets` | String or Object | Amount | Yes | The remaining amount and type of currency being provided by the Offer creator. |
| `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
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`**.
`Offer` objects can have the following flag values:
`Offer` entries can have the following flags combined into the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Corresponding [OfferCreate Flag](offercreate.html#offercreate-flags) | Description |
|--------------|--------------|---------------|-------------|------------------------|
| `lsfPassive` | `0x00010000` | 65536 | `tfPassive` | The object was placed as a passive Offer. This has no effect on the object in the ledger. |
| `lsfSell` | `0x00020000` | 131072 | `tfSell` | 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). |
| `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. |
## {{currentpage.name}} Reserve
`{{currentpage.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` object is the [SHA-512Half][] of the following values, concatenated in order:
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

2
content/references/protocol-reference/ledger-data/ledger-entry-types/paychannel.ja.md
View File

@@ -1,6 +1,6 @@
---
html: paychannel.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 非同期XRP支払い用のチャネルです。
labels:
- Payment Channel

39
content/references/protocol-reference/ledger-data/ledger-entry-types/paychannel.md
View File

@@ -1,6 +1,6 @@
---
html: paychannel.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: A channel for asynchronous XRP payments.
labels:
- Payment Channels
@@ -10,13 +10,8 @@ labels:
_(Added by the [PayChan amendment][].)_
The `PayChannel` object type represents a payment channel. Payment channels enable small, rapid off-ledger payments of XRP that can be later reconciled with the consensus ledger. A payment channel holds a balance of XRP that can only be paid out to a specific destination address until the channel is closed. Any unspent XRP is returned to the channel's owner (the source address that created and funded it) when the channel closes.
A `PayChannel` entry represents a [payment channel](payment-channels.html).
The [PaymentChannelCreate transaction][] type creates a `PayChannel` object. The [PaymentChannelFund][] and [PaymentChannelClaim transaction][] types modify existing `PayChannel` objects.
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.
For an example of using payment channels, see the [Payment Channels Tutorial](use-payment-channels.html).
## Example {{currentpage.name}} JSON
@@ -44,7 +39,7 @@ For an example of using payment channels, see the [Payment Channels Tutorial](us
## {{currentpage.name}} Fields
A `PayChannel` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:-----------------------|
@@ -54,20 +49,22 @@ A `PayChannel` object has the following fields:
| `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.html). 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 object, 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.html). See [Setting Channel Expiration](#setting-channel-expiration) for more details. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `PayChannel` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0078`, mapped to the string `PayChannel`, indicates that this object is a payment channel object. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the source address'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. |
| `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.html). 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. |
## Setting Channel Expiration
## 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.html) 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.
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.html) 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
@@ -94,9 +91,15 @@ The destination address cannot set the `Expiration` field. However, the destinat
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.
## {{currentpage.name}} Reserve
`{{currentpage.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` object is the [SHA-512Half][] of the following values, concatenated in order:
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

2
content/references/protocol-reference/ledger-data/ledger-entry-types/ripplestate.ja.md
View File

@@ -1,6 +1,6 @@
---
html: ripplestate.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: 2つのアカウントをリンクし、それらのアカウント間の特定の通貨の残高を追跡します。トラストラインのコンセプトは、このオブジェクトタイプを抽象化することです。
labels:
- トークン

49
content/references/protocol-reference/ledger-data/ledger-entry-types/ripplestate.md
View File

@@ -1,20 +1,20 @@
---
html: ripplestate.html
parent: ledger-object-types.html
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.
parent: ledger-entry-types.html
blurb: 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")
The `RippleState` object type connects two accounts in a single currency. Conceptually, a `RippleState` object represents two [trust lines](trust-lines-and-issuing.html) 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.
A `RippleState` ledger entry represents a [trust line](trust-lines-and-issuing.html) 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` object per currency for any given pair of accounts. Since no account is privileged in the XRP Ledger, a `RippleState` object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when [decoded](addresses.html#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.
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](addresses.html#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"](trust-lines-and-issuing.html) for the balance in a trust line depends on whether the balance is positive or negative. If a `RippleState` object 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.
The ["issuer"](trust-lines-and-issuing.html) 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 {{currentpage.name}} JSON
@@ -48,34 +48,32 @@ The ["issuer"](trust-lines-and-issuing.html) for the balance in a trust line dep
## {{currentpage.name}} Fields
A `RippleState` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.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](addresses.html#special-addresses). |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean options enabled for this object. |
| `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 object, in case the directory consists of multiple pages. |
| `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 object is a RippleState object. |
| `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 object, in case the directory consists of multiple pages. |
| `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 object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `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
There are several options which can be either enabled or disabled for a trust line. These options can be changed with a [TrustSet 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`**.
RippleState objects can have the following flag values:
`RippleState` entries can have the following flags combined into the `Flags` field:
| Flag Name | Hex Value | Decimal Value | Corresponding [TrustSet Flag](trustset.html#trustset-flags) | Description |
|-------------------|--------------|---------------|-----------------|---------|
| `lsfLowReserve` | `0x00010000` | 65536 | (None) | This RippleState object [contributes to the low account's owner reserve](#contributing-to-the-owner-reserve). |
| `lsfHighReserve` | `0x00020000` | 131072 | (None) | This RippleState object [contributes to the high account's owner reserve](#contributing-to-the-owner-reserve). |
| `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](rippling.html) from this trust line. |
@@ -83,9 +81,15 @@ RippleState objects can have the following flag values:
| `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. |
## Contributing to the Owner Reserve
The two accounts connected by the trust line can each change their own settings with a [TrustSet transaction][].
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](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.
## {{currentpage.name}} Reserve
<a id="contributing-to-the-owner-reserve"></a>
A `RippleState` entry counts as one item towards the owner reserve of [owner reserve](reserves.html#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:
@@ -100,15 +104,16 @@ The values that count towards a trust line's non-default state are as follows:
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.html#accountroot-flags) in their corresponding AccountRoot objects. 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.
The default state of the two No Ripple flags depends on the state of the [`lsfDefaultRipple` flag](accountroot.html#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).
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 Default Ripple 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.
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 object is the [SHA-512Half][] of the following values, concatenated in order:
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

2
content/references/protocol-reference/ledger-data/ledger-entry-types/signerlist.ja.md
View File

@@ -1,6 +1,6 @@
---
html: signerlist.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: マルチシグトランザクションのアドレスのリストです。
labels:
- セキュリティ

23
content/references/protocol-reference/ledger-data/ledger-entry-types/signerlist.md
View File

@@ -1,6 +1,6 @@
---
html: signerlist.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: A list of addresses for multi-signing transactions.
labels:
- Security
@@ -10,7 +10,7 @@ labels:
_(Added by the [MultiSign amendment][].)_
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 signer list using a [SignerListSet transaction][].
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 {{currentpage.name}} JSON
@@ -50,12 +50,11 @@ The `SignerList` object type represents a list of parties that, as a group, are
## {{currentpage.name}} Fields
A `SignerList` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Name | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:--------------|:----------|:---------------------------|
| `Flags` | Number | UInt32 | Yes | A bit-map of Boolean flags enabled for this signer list. For more information, see [SignerList Flags](#signerlist-flags). |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0053`, mapped to the string `SignerList`, indicates that this object is a SignerList object. |
| `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. |
@@ -75,29 +74,31 @@ Each member of the `SignerEntries` field is an object that describes that signer
| `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 object](accountroot.html), then only the [master private key](cryptographic-keys.html) 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.
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.html), then only the [master private key](cryptographic-keys.html) 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.
## {{currentpage.name}} Flags
_(Added by the [MultiSignReserve amendment][].)_
SignerList objects can have the following flag value:
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](reserves.html#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](reserves.html).
A signer list contributes to its owner's [reserve requirement](reserves.html). Removing the signer list frees up the reserve.
The [MultiSignReserve amendment][] (enabled 2019-04-17) made it so each signer list counts as one object, regardless of how many members it has. As a result, the owner reserve associated with a new signer list is 2 XRP.
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 {{target.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][].
A signer list created before the [MultiSignReserve amendment][] itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with the signer list is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](ripplestate.html)) or [Offer](offer.html) object in the ledger. 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 signer list object is the SHA-512Half of the following values, concatenated in order:
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

2
content/references/protocol-reference/ledger-data/ledger-entry-types/ticket.ja.md
View File

@@ -1,6 +1,6 @@
---
html: ticket.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: チケットは、将来使用するために確保されたアカウントのシーケンス番号を追跡します。
labels:
- トランザクション送信

26
content/references/protocol-reference/ledger-data/ledger-entry-types/ticket.md
View File

@@ -1,6 +1,6 @@
---
html: ticket.html
parent: ledger-object-types.html
parent: ledger-entry-types.html
blurb: A Ticket tracks an account sequence number that has been set aside for future use.
labels:
- Transaction Sending
@@ -11,7 +11,7 @@ labels:
_(Added by the [TicketBatch amendment][].)_
The `Ticket` object type represents a [Ticket](tickets.html), 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][]. [New in: rippled 1.7.0][]
A `Ticket` entry type represents a [Ticket](tickets.html), 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 {{currentpage.name}} JSON
@@ -29,18 +29,28 @@ The `Ticket` object type represents a [Ticket](tickets.html), which tracks an ac
## {{currentpage.name}} Fields
A `Ticket` object has the following fields:
In addition to the [common fields](ledger-entry-common-fields.html), `{{currentpage.name}}` entries have the following fields:
| Name | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:--------------|:----------|:---------------------------|
| `Account` | String | AccountID | Yes | The [account](accounts.html) that owns this Ticket. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Ticket` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0054`, mapped to the string `Ticket`, indicates that this object is a {{currentpage.name}} object. |
| `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. **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](transactions.html) 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. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0054`, mapped to the string `Ticket`, indicates that this is a {{currentpage.name}} 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](transactions.html) 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. |
## {{currentpage.name}} Reserve
`{{currentpage.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.
## {{currentpage.name}} Flags
There are no flags defined for `{{currentpage.name}}` entries.
## {{currentpage.name}} ID Format
The ID of a Ticket object is the SHA-512Half of the following values, concatenated in order:

109
dactyl-config.yml
View File

@@ -68,6 +68,9 @@ default_keys: &defaults
light_theme_enabled: true
# Script tags used in a variety of tools & examples.
ripple_lib_tag: '<script type="application/javascript" src="assets/js/xrpl-2.11.0.min.js"></script>'
# Current reserves values on Mainnet. These strings can be overwritten by language if necessary for localization.
base_reserve: 10 XRP
owner_reserve: 2 XRP
targets:
# First member is the default that gets built when target not specified
@@ -941,14 +944,6 @@ pages:
- en
- ja
- md: concepts/ledgers/ledger-object-ids.md
targets:
- en
- md: concepts/ledgers/ledger-object-ids.ja.md
targets:
- ja
# TODO: add a "ledger history" page that doesn't go too deep into
# server management topics.
@@ -2439,151 +2434,177 @@ pages:
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/ledger-object-types.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ledger-entry-types.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/ledger-object-types.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ledger-entry-types.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/accountroot.md
# TODO: translate
- md: references/protocol-reference/ledger-data/ledger-entry-types/ledger-entry-types.md
targets:
- en
- ja
# redirect from old "ledger object types" URL
- name: Ledger Entry Types
html: ledger-object-types.html
template: pagetype-redirect.html.jinja
redirect_url: ledger-entry-types.html
nav_omit: true
targets:
- en
- ja
# redirect from old ledger object IDs URL
- name: Ledger Entry IDs
html: ledger-object-ids.html
template: pagetype-redirect.html.jinja
redirect_url: ledger-entry-common-fields.html
nav_omit: true
targets:
- en
- ja
- md: references/protocol-reference/ledger-data/ledger-entry-types/accountroot.md
targets:
- en
# TODO: update translation for rippled v1.11.0 & AMM
- md: references/protocol-reference/ledger-data/ledger-entries/accountroot.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/accountroot.ja.md
outdated_translation: true
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/amendments.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/amendments.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/amendments.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/amendments.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/amm.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/amm.md
targets:
- en
# TODO: update translation
- md: references/protocol-reference/ledger-data/ledger-entries/amm.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/amm.ja.md
outdated_translation: true
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/check.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/check.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/check.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/check.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/depositpreauth.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/depositpreauth.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/depositpreauth.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/depositpreauth.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/directorynode.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/directorynode.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/directorynode.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/directorynode.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/escrow.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/escrow.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/escrow.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/escrow.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/feesettings.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/feesettings.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/feesettings.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/feesettings.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/ledgerhashes.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ledgerhashes.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/ledgerhashes.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ledgerhashes.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/negativeunl.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/negativeunl.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/negativeunl.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/negativeunl.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/nftokenoffer.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/nftokenoffer.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/nftokenoffer.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/nftokenoffer.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/nftokenpage.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/nftokenpage.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/nftokenpage.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/nftokenpage.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/offer.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/offer.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/offer.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/offer.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/paychannel.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/paychannel.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/paychannel.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/paychannel.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/ripplestate.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ripplestate.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/ripplestate.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ripplestate.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/signerlist.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/signerlist.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/signerlist.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/signerlist.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-entries/ticket.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ticket.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-entries/ticket.ja.md
- md: references/protocol-reference/ledger-data/ledger-entry-types/ticket.ja.md
targets:
- ja