| Private Server Using Public Hubs |
Low maintenance burden with a small amount of configuration. Provides easy access to safe connections to the network. Provides access to safe connections to the network. Compared to connecting using proxies, may be less likely to cause your private server to disconnect from the network due to a simultaneous peer outage. |
diff --git a/content/concepts/the-rippled-server/rippled-server-modes.md b/content/concepts/the-rippled-server/rippled-server-modes.md
index e221e50b70..2302fe6df4 100644
--- a/content/concepts/the-rippled-server/rippled-server-modes.md
+++ b/content/concepts/the-rippled-server/rippled-server-modes.md
@@ -23,7 +23,7 @@ You need to trust the `rippled` you use. If you connect to a malicious server, t
Additionally, running your own server gives you admin control over it, which allows you to run important admin-only and load-intensive commands. If you use a shared server, you have to worry about other users of the same server competing with you for the server's computing power. Many of the commands in the WebSocket API can put a lot of strain on the server, so `rippled` has the option to scale back its responses when it needs to. If you share a server with others, you may not always get the best results possible.
-Finally, if you run a validating server, you can use a stock server as a proxy to the public network while keeping your validating server on a private subnet only accessible to the outside world through the stock server. This makes it more difficult to compromise the integrity of your validating server.
+Finally, if you run a validating server, you can use a stock server as a proxy to the public network while keeping your validating server on a private network only accessible to the outside world through the stock server. This makes it more difficult to compromise the integrity of your validating server.
### Public Hubs
diff --git a/content/references/data-api.md b/content/references/data-api.md
index 01ae104c68..e766b205d6 100644
--- a/content/references/data-api.md
+++ b/content/references/data-api.md
@@ -772,7 +772,7 @@ Optionally, you can provide the following query parameters:
| `reduce` | Boolean | If `true`, aggregate all individual results. The default is `false`. |
| `limit` | Integer | Maximum results per page. The default is 200. Cannot be more than 20,000 if `reduce` is true. Otherwise cannot be more than 1,000. |
| `marker` | String | [Pagination](#pagination) key from previously returned response. |
-| `autobridged` | Boolean | If `true`, filter results to autobridged exchanges only. |
+| `autobridged` | Boolean | If `true`, filter results to return only exchanges made through [auto-bridging](autobridging.html). |
| `format` | String | Format of returned results: `csv` or `json`. The default is `json`. |
#### Response Format
@@ -910,7 +910,7 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
| `result` | String | The value `success` indicates that this is a successful response. |
| `rate` | Number | The requested exchange rate, or `0` if the exchange rate could not be determined. |
-All exchange rates are calcuated by converting the base currency and counter currency to XRP.
+All exchange rates are calculated by converting the base currency and counter currency to XRP.
The rate is derived from the volume weighted average over the calendar day specified, averaged with the volume weighted average of the last 50 trades within the last 14 days.
@@ -2683,9 +2683,9 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
| `validation_public_key` | String - Base-58 [Public Key][] | This validator's validator public key. |
| `domain` | String | (May be omitted) The DNS domain associated with this validator. |
| `chain` | String | Ledger hash chain which this validator is currently following. The value `main` indicates the main network and `altnet` indicates the XRP Test Network. Other forks are named `chain.{NUMBER}`, where `{NUMBER}` is a unique number for each fork. |
-| `unl` | Bool | True if the validator is part of the ledger chain's recommended UNL. |
+| `unl` | Boolean | True if the validator is part of the ledger chain's recommended UNL. |
| `current_index` | Number | Ledger index of most recently validated ledger. |
-| `partial` | Bool | True if the most recent validation was a partial one. |
+| `partial` | Boolean | True if the most recent validation was a partial one. |
| `agreement_1h` | Agreement Object | Object containing agreement stats for the most recent hour. |
| `agreement_24h` | Agreement Object | Object containing agreement stats for the most recent 24 hour period. |
@@ -2696,7 +2696,7 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
| `score` | String | Score of agreement with the ledger chain being followed. |
| `missed` | Integer | Number of ledgers not validated during the time period. |
| `total` | Integer | Number of ledgers that could have been validated during the time period. |
-| `incomplete` | Bool | True indicates the data does not cover the entire time period. |
+| `incomplete` | Boolean | True indicates the data does not cover the entire time period. |
#### Example
@@ -2779,9 +2779,9 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
| `validation_public_key` | String - Base-58 [Public Key][] | This validator's validator public key. |
| `domain` | String | (May be omitted) The DNS domain associated with this validator. |
| `chain` | String | Ledger hash chain which this validator is currently following. The value `main` indicates the main network and `altnet` indicates the XRP Test Network. Other forks are named `chain.{NUMBER}`, where `{NUMBER}` is a unique number for each fork. |
-| `unl` | Bool | True if the validator is part of the ledger chain's recommended UNL. |
+| `unl` | Boolean | True if the validator is part of the ledger chain's recommended UNL. |
| `current_index` | Number | Ledger index of most recently validated ledger. |
-| `partial` | Bool | True if the most recent validation was a partial one. |
+| `partial` | Boolean | True if the most recent validation was a partial one. |
| `agreement_1h` | Agreement Object | Object containing agreement stats for the most recent hour. |
| `agreement_24h` | Agreement Object | Object containing agreement stats for the most recent 24 hour period. |
@@ -2792,7 +2792,7 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
| `score` | String | Score of agreement with the ledger chain being followed. |
| `missed` | Integer | Number of ledgers not validated during the time period. |
| `total` | Integer | Number of ledgers that could have been validated during the time period. |
-| `incomplete` | Bool | True indicates the data does not cover the entire time period. |
+| `incomplete` | Boolean | True indicates the data does not cover the entire time period. |
#### Example
@@ -2861,7 +2861,7 @@ Response:
## Get Validator Manifests
[[Source]](https://github.com/ripple/rippled-historical-database/blob/master/api/routes/network/getManifests.js "Source")
-Retrieve manifests signed by a specified validator. (Manifests, also called _subkey authorizations_, designate the ephemeral key a validator uses to sign proposals and validations.) _(New in [v2.3.7][])_
+Retrieve manifests signed by a specified validator. (Manifests designate the ephemeral key a validator uses to sign proposals and validations.) _(New in [v2.3.7][])_
**Note:** The Data API does not have a comprehensive record of all manifests. The response only includes data that the Data API has recorded.
@@ -2996,7 +2996,7 @@ Optionally, you can provide the following query parameters:
|:---------|:-----------------------|:-----------------------------------------|
| `start` | String - [Timestamp][] | Start date and time for historical query. The default is to start 200 days before the current date. |
| `end` | String - [Timestamp][] | End date and time for historical query. The default is to end with the most recent data available. |
-| `descending` | Bool | Return results in reverse order. |
+| `descending` | Boolean | Return results in reverse order. |
| `format` | String | Format of returned results: `csv` or `json`. The default is `json`. |
#### Response Format
@@ -3022,7 +3022,7 @@ Each Single Validator Report Object describes a validator's performance on a giv
| `score` | String | Score of agreement with the ledger chain being followed. |
| `missed` | Integer | Number of ledgers not validated during the time period. |
| `total` | Integer | Number of ledgers that could have been validated during the time period. |
-| `incomplete` | Bool | True indicates the data does not cover the entire time period. |
+| `incomplete` | Boolean | True indicates the data does not cover the entire time period. |
#### Example
@@ -3106,15 +3106,15 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
Each member in the `reports` array describes one validator's performance on that day and has the following fields:
-| Field | Value | Description |
-|:---------------------|:--------------------------------|:-----------------------------|
-| `validation_public_key` | String - Base-58 [Public Key][] | Validator public key. |
-| `date` | String - [Timestamp][] | The start time of the date this object describes. |
-| `chain` | String | Ledger hash chain which this validator is currently following. The value `main` indicates the main network and `altnet` indicates the XRP Test Network. Other forks are named `chain.{NUMBER}`, where `{NUMBER}` is a unique number for each fork. |
-| `score` | String | Score of agreement with the ledger chain being followed. |
-| `missed` | Integer | Number of ledgers not validated during the time period. |
-| `total` | Integer | Number of ledgers that could have been validated during the time period. |
-| `incomplete` | Bool - Optional | True indicates the data does not cover the entire time period. |
+| Field | Value | Description |
+|:------------------------|:------------------------|:-------------------------|
+| `validation_public_key` | String - [Public Key][] | The validator's public key, in [base58][]. |
+| `date` | String - [Timestamp][] | The start time of the date this object describes. |
+| `chain` | String | Ledger hash chain which this validator is currently following. The value `main` indicates the main network and `altnet` indicates the XRP Test Network. Other forks are named `chain.{NUMBER}`, where `{NUMBER}` is a unique number for each fork. |
+| `score` | String | Score of agreement with the ledger chain being followed. |
+| `missed` | Integer | Number of ledgers not validated during the time period. |
+| `total` | Integer | Number of ledgers that could have been validated during the time period. |
+| `incomplete` | Boolean | _(Optional)_ True indicates the data does not cover the entire time period. |
#### Example
@@ -3966,7 +3966,7 @@ Response:
## Get Transaction By Account And Sequence
[[Source]](https://github.com/ripple/rippled-historical-database/blob/master/api/routes/accountTxSeq.js "Source")
-Retrieve a specifc transaction originating from a specified account
+Retrieve a specific transaction originating from a specified account
#### Request Format
@@ -4932,7 +4932,7 @@ Response:
## Basic Types
-As a REST API, the Data API v2 uses [JSON](http://json.org/)'s native datatypes to represent API fields, with some special cases.
+As a REST API, the Data API v2 uses [JSON](http://json.org/)'s native data types to represent API fields, with some special cases.
### Numbers and Precision
[String - Number]: #numbers-and-precision
@@ -5010,7 +5010,7 @@ Many queries may return more data than is reasonable to return in a single HTTP
The `limit` query parameter to many requests restricts the response to a specific number of results in the response. The types of results and default values vary based on the method. For most methods, the `limit` is **200** by default, and can be set as high as **1000**. If you specify a `limit` larger than the maximum, the API uses the maximum value instead.
-When a query has additional objects that are not contained in the current response, the JSON response contains a top-level field `marker` which indicates that you can retrieve additional results. To do so, make more requests with the previous value of the `marker` field as the `marker` query parameter. For each additional request, use the same parameters as the first request (except `marker`). When the response omits the `marker` parameter, that indicates that you have reached the end of the queryable data.
+When a query has additional objects that are not contained in the current response, the JSON response contains a top-level field `marker` which indicates that you can retrieve additional results. To do so, make more requests with the previous value of the `marker` field as the `marker` query parameter. For each additional request, use the same parameters as the first request (except `marker`). When the response omits the `marker` parameter, that indicates that you have reached the end of the data.
When a `marker` is or would be present, the response contains a [`Link` header](https://tools.ietf.org/html/rfc5988#section-5) with `rel="next"`. This is a full URL to the next page of results. You can use this to paginate over results when the response is in `csv` format instead of `json`. _(New in [v2.0.4][])_
@@ -5088,8 +5088,8 @@ A single transaction can cause several exchanges to occur. In this case, the sen
| `base_amount` | Number | The amount of the base currency that was traded. |
| `counter_amount` | Number | The amount of the counter currency that was traded. |
| `rate` | Number | The amount of the counter currency acquired per 1 unit of the base currency. |
-| `autobridged_currency` | String - [Currency Code][] | (May be omitted) If the offer was autobridged (XRP order books were used to bridge two non-XRP currencies), this is the other currency from the offer that executed this exchange. |
-| `autobridged_issuer` | String - [Address][] | (May be omitted) If the offer was autobridged (XRP order books were used to bridge two non-XRP currencies), this is the other currency from the offer that executed this exchange. |
+| `autobridged_currency` | String - [Currency Code][] | (May be omitted) If the offer was auto-bridged (XRP order books were used to bridge two non-XRP currencies), this is the other currency from the offer that executed this exchange. |
+| `autobridged_issuer` | String - [Address][] | (May be omitted) If the offer was auto-bridged (XRP order books were used to bridge two non-XRP currencies), this is the other currency from the offer that executed this exchange. |
| `base_currency` | String - [Currency Code][] | The base currency. |
| `base_issuer` | String - [Address][] | (Omitted for XRP) The account that issued the base currency. |
| `buyer` | String - [Address][] | The account that acquired the base currency. |
@@ -5193,7 +5193,7 @@ Balance Change Descriptors have the following fields:
|:----------------|:---------------------------|:------------------------------|
| `amount_change` | [String - Number][] | The difference in the amount of currency held before and after this change. _(Prior to [v2.0.6][], this field was called `change`.)_ |
| `final_balance` | [String - Number][] | The balance after the change occurred. |
-| `node_index` | Number (or `null`) | This balance change is represented by the entry at this index of the ModifiedNodes array within the metadata section of the transaction that executed this balance change. **Note:** When the transaction cost is combined with other changes to XRP balance, the transaction cost has a `node_index` of **null** instead. |
+| `node_index` | Number (or `null`) | This balance change is represented by the entry at this index of the `ModifiedNodes` array within the [metadata section](transaction-metadata.html) of the transaction that executed this balance change. **Note:** When the transaction cost is combined with other changes to XRP balance, the transaction cost has a `node_index` of **null** instead. |
| `tx_index` | Number | The transaction that executed this balance change is at this index in the array of transactions for the ledger that included it. |
| `change_type` | String | One of several [](#change-types) describing what caused this balance change to occur. |
| `currency` | String - [Currency Code][] | The change affected this currency. |
@@ -5233,7 +5233,7 @@ Volume objects represent the total volumes of money moved, in either payments or
[Server Object]: #server-objects
[Server Objects]: #server-objects
-A "Server Object" describes one `rippled` server in the XRP Ledger peer-to-peer network. Server objects are returned by the [Get Topology](#get-topology), [Get Toplogy Nodes](#get-topology-nodes), and [Get Topology Node](#get-topology-node) methods. The Data API collects reported network topology approximately every 30 seconds using the [peer crawler](peer-crawler.html).
+A "Server Object" describes one `rippled` server in the XRP Ledger peer-to-peer network. Server objects are returned by the [Get Topology](#get-topology), [Get Topology Nodes](#get-topology-nodes), and [Get Topology Node](#get-topology-node) methods. The Data API collects reported network topology approximately every 30 seconds using the [peer crawler](peer-crawler.html).
Server objects have the following fields, with some only appearing if the request specified a verbose response:
@@ -5256,7 +5256,7 @@ Server objects have the following fields, with some only appearing if the reques
| `region_code` | String | (Verbose only) The ISO code for the region where this server is located, according to IP geolocation. |
| `country_code` | String | (Verbose only) The ISO code for the country where this server is located, according to IP geolocation. |
| `postal_code` | String | (Verbose only) The postal code where this server is located, according to IP geolocation. |
-| `timezone` | String | (Verbose only) The ISO timezone where this server is located, according to IP geolocation. |
+| `timezone` | String | (Verbose only) The ISO time zone where this server is located, according to IP geolocation. |
| `lat` | String | (Verbose only) The latitude where this server is located, according to IP geolocation. |
| `long` | String | (Verbose only) The longitude where this server is located, according to IP geolocation. |
| `isp` | String | (Verbose only) The Internet Service Provider hosting this server's public IP address. |
diff --git a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/can_delete.md b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/can_delete.md
index dcada9f546..ccf2e39bb1 100644
--- a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/can_delete.md
+++ b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/can_delete.md
@@ -65,7 +65,7 @@ Use this command with no parameter to query the existing `can_delete` setting.
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
- `lgrNotFound` - The ledger specified by the `can_delete` field of the request does not exist, or it does exist but the server does not have it.
- `notEnabled` - If either online deletion or advisory deletion are not enabled in the server's configuration.
-- `notReady` - The server is not ready to run online deletion at the moment. This usually means the server has just started up and has not yet acquired a validated ledger.
+- `notReady` - The server is not ready to run online deletion at the moment. This usually means the server has recently started up and has not yet acquired a validated ledger.
## See Also
diff --git a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/download_shard.md b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/download_shard.md
index d3f0fa7565..40d553a441 100644
--- a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/download_shard.md
+++ b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/download_shard.md
@@ -1,7 +1,7 @@
# download_shard
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/DownloadShard.cpp "Source")
-Instructs the server to download a specific [shard of historical ledger data](history-sharding.html) from an external source. Your `rippled` server must be [configured to store history shards](configure-history-sharding.html). [New in: rippled 1.1.0][]
+Instructs the server to download a specific [shard of historical ledger data](history-sharding.html) from an external source. Your `rippled` server must be [configured to store history shards](configure-history-sharding.html). [Updated in: rippled 1.6.0][]
_The `download_shard` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
@@ -45,15 +45,23 @@ An example of the request format:
}
```
+*Commandline*
+
+```sh
+# Syntax: download_shard [[ ]]
+rippled download_shard 1 https://example.com/1.tar.lz4 2 https://example.com/2.tar.lz4 5 https://example.com/5.tar.lz4
+```
+
-The request includes the following fields:
+The request includes the following field:
| `Field` | Type | Description |
|:-----------|:--------|:------------------------------------------------------|
| `shards` | Array | List of Shard Descriptor objects (see below) describing shards to download and where to download them from. |
-| `validate` | Boolean | _(Optional)_ If `false`, skip validating the downloaded data. The default is `true`, which checks that the shard in the archive contains all the data objects for the shard and the shard is part of the ledger history of the current validated ledger. |
+
+The `validate` field is deprecated and may be removed in a future version. (The server always checks the integrity of shards when it imports them.) [Updated in: rippled 1.6.0][]
Each **Shard Descriptor object** in the `shards` array has the following fields:
@@ -94,6 +102,19 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+Loading: "/etc/rippled.cfg"
+Connecting to 127.0.0.1:5005
+
+{
+ "result": {
+ "message": "downloading shards 1-2,5",
+ "status": "success"
+ }
+}
+```
diff --git a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_cleaner.md b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_cleaner.md
index 8ae48d1bd6..c6778791f7 100644
--- a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_cleaner.md
+++ b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_cleaner.md
@@ -30,7 +30,7 @@ The request includes the following parameters:
| `ledger` | Number - [Ledger Index][] | _(Optional)_ If provided, check and correct the specified ledger only. |
| `max_ledger` | Number - [Ledger Index][] | _(Optional)_ Configure the ledger cleaner to check ledgers with ledger indexes equal or lower than this. |
| `min_ledger` | Number - [Ledger Index][] | _(Optional)_ Configure the ledger cleaner to check ledgers with ledger indexes equal or higher than this. |
-| `full` | Boolean | _(Optional)_ If true, fix ledger state objects and transations in the specified ledger(s). Defaults to false. Automatically set to `true` if `ledger` is provided. |
+| `full` | Boolean | _(Optional)_ If true, fix ledger state objects and transactions in the specified ledger(s). Defaults to false. Automatically set to `true` if `ledger` is provided. |
| `fix_txns` | Boolean | _(Optional)_ If true, correct transaction in the specified ledger(s). Overrides `full` if provided. |
| `check_nodes` | Boolean | _(Optional)_ If true, correct ledger state objects in the specified ledger(s). Overrides `full` if provided. |
| `stop` | Boolean | _(Optional)_ If true, disable the ledger cleaner. |
diff --git a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md
index 1eb1ad167c..f77e4abd97 100644
--- a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md
+++ b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/logrotate.md
@@ -3,7 +3,7 @@
The `logrotate` command closes and reopens the log file. This is intended to help with log rotation on Linux file systems.
-Most Linux systems come preinstalled with a [`logrotate`](https://linux.die.net/man/8/logrotate) program, which is separate from this command. Application specific log rotation scripts are placed in `/etc/logrotate.d`
+Most Linux systems come pre-installed with a [`logrotate`](https://linux.die.net/man/8/logrotate) program, which is separate from this command. Application specific log rotation scripts are placed in `/etc/logrotate.d`
The following script is a sample that can be created as `/etc/logrotate.d/rippled`
diff --git a/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.ja.md b/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.ja.md
index a92254f5d7..c4d049ce86 100644
--- a/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.ja.md
+++ b/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.ja.md
@@ -49,7 +49,7 @@ rippled connect 192.170.145.88 51235
| `Field` | 型 | 説明 |
|:--------|:-------|:----------------------------------------------------------|
| `ip` | 文字列 | 接続するサーバーのIPアドレス。 |
-| `port` | 数値 | _（省略可）_ 接続時に使用するポート番号。デフォルトでは6561です。 |
+| `port` | 数値 | _（省略可）_ 接続時に使用するポート番号。デフォルトでは**2459**です。 [新規: rippled 1.6.0][] |
### 応答フォーマット
diff --git a/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.md b/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.md
index 99b669cda3..9e4a589406 100644
--- a/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.md
+++ b/content/references/rippled-api/admin-rippled-methods/peer-management-methods/connect.md
@@ -49,7 +49,7 @@ The request includes the following parameters:
| `Field` | Type | Description |
|:--------|:-------|:----------------------------------------------------------|
| `ip` | String | IP address of the server to connect to |
-| `port` | Number | _(Optional)_ Port number to use when connecting. Defaults to 6561. |
+| `port` | Number | _(Optional)_ Port number to use when connecting. The default is **2459**. [Updated in: rippled 1.6.0][] |
### Response Format
diff --git a/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/validator_list_sites.md b/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/validator_list_sites.md
index 4220b72407..b4e76ce85f 100644
--- a/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/validator_list_sites.md
+++ b/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/validator_list_sites.md
@@ -133,7 +133,7 @@ The `last_refresh_status` field can have the following values:
| `accepted` | The site provided a valid list, which your server is now using. |
| `same_sequence` | The site provided a list with the same sequence number as your existing list, so your server continued using its existing list. |
| `unsupported_version` | The site provided a list, but your server does not support the list format version number in the list. You might need to [update `rippled`](install-rippled.html) to a newer software version. |
-| `untrusted` | The site provided a list from the site that is signed by a cryptographic keypair your server is not configured to trust. You may want to check for typos in your `validators.txt` file and check to see if the list publisher changed their cryptographic keys. |
+| `untrusted` | The site provided a list from the site that is signed by a cryptographic key pair your server is not configured to trust. You may want to check for typos in your `validators.txt` file and check to see if the list publisher changed their cryptographic keys. |
| `stale` | The site provided a list with a lower sequence number than the list your server is already using. |
| `invalid` | The site provided a list or signature that was not validly formed. |
diff --git a/content/references/rippled-api/api-conventions/basic-data-types.md b/content/references/rippled-api/api-conventions/basic-data-types.md
index 7bf6a9050a..c46f494bdf 100644
--- a/content/references/rippled-api/api-conventions/basic-data-types.md
+++ b/content/references/rippled-api/api-conventions/basic-data-types.md
@@ -41,7 +41,7 @@ Some types of hash appear in API requests and responses. Others are only calcula
| Unsigned Transaction (Single-signing) | N/A | `0x53545800` | `STX\0` |
| Unsigned Transaction (Multi-signing) | N/A | `0x534D5400` | `SMT\0` |
| Validation vote | N/A | `0x56414C00` | `VAL\0` |
-| Validator subkey authorization ("validator manifest") | N/A | `0x4D414E00` | `MAN\0` |
+| Validator manifest | N/A | `0x4D414E00` | `MAN\0` |
[ledger header]: ledger-header.html
[SHAMapv2]: known-amendments.html#shamapv2
@@ -93,7 +93,7 @@ XRP is specified as a string containing an integer number of "drops" of XRP, whe
"Amount": "13100000"
-- **Issued Currency** - To specify an `Amount` field with a value of 13.1 FOO issued by or to rf1B...:
+- **Issued Currency** - To specify an `Amount` field with a value of 13.1 FOO issued by or to `rf1B...`:
"Amount": {
"value": "13.1",
diff --git a/content/references/rippled-api/api-conventions/error-formatting.md b/content/references/rippled-api/api-conventions/error-formatting.md
index 490c86ba8b..ad9f2b8d27 100644
--- a/content/references/rippled-api/api-conventions/error-formatting.md
+++ b/content/references/rippled-api/api-conventions/error-formatting.md
@@ -112,4 +112,4 @@ All methods can potentially return any of the following values for the `error` c
* `noNetwork` - The server is having trouble connecting to the rest of the XRP Ledger peer-to-peer network (and is not running in stand-alone mode).
* `tooBusy` - The server is under too much load to do this command right now. Generally not returned if you are connected as an admin.
* `unknownCmd` - The request does not contain a [command](rippled-api.html) that the `rippled` server recognizes.
-* `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text.
+* `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text.
diff --git a/content/references/rippled-api/api-conventions/request-formatting.md b/content/references/rippled-api/api-conventions/request-formatting.md
index 96116bc5a1..7a41291106 100644
--- a/content/references/rippled-api/api-conventions/request-formatting.md
+++ b/content/references/rippled-api/api-conventions/request-formatting.md
@@ -60,11 +60,11 @@ See [Response Formatting](response-formatting.html) for the response from the se
## JSON-RPC Format
-To make a JSON-RPC request, send an HTTP **POST** request to the root path (`/`) on the port and IP where the `rippled` server is listening for JSON-RPC connections. You can use HTTP/1.0 or HTTP/1.1. If you use HTTPS, you should use TLS v1.2. For security reasons, `rippled` _does not support_ SSL v3 or earlier.
+To make a JSON-RPC request, send an HTTP **POST** request to the root path (`/`) on the port and IP where the `rippled` server is listening for JSON-RPC connections. You can use HTTP/1.0 or HTTP/1.1. If you use HTTPS, you should use TLS version 1.2. For security reasons, `rippled` _does not support_ SSL version 3 or earlier.
Always include a `Content-Type` header with the value `application/json`.
-If you plan on making multiple requests, use [Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3) so that you do not have to close and re-open the connection in between requests.
+If you plan on making multiple requests, use [Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3) so that you do not have to close and re-open the connection in between requests.
Send request body as a [JSON](https://en.wikipedia.org/wiki/JSON) object with the following fields:
diff --git a/content/references/rippled-api/api-conventions/serialization.md b/content/references/rippled-api/api-conventions/serialization.md
index e439b5d778..6081fa68d1 100644
--- a/content/references/rippled-api/api-conventions/serialization.md
+++ b/content/references/rippled-api/api-conventions/serialization.md
@@ -95,14 +95,14 @@ When you combine a field's type code and field code, you get the field's unique
| | Type Code < 16 | Type Code >= 16 |
|:-----------------|:------------------------------------------------------------------------------|:--|
| **Field Code < 16** |  |  |
-| **Field Code >= 16** |  |  |
+| **Field Code >= 16** |  |  |
When decoding, you can tell how many bytes the field ID is by which bits **of the first byte** are zeroes. This corresponds to the cases in the above table:
| | High 4 bits are nonzero | High 4 bits are zero |
|:-----------------|:------------------------------------------------------------------------------|:--|
| **Low 4 bits are nonzero** | 1 byte: high 4 bits define type; low 4 bits define field. | 2 bytes: low 4 bits of the first byte define field; next byte defines type |
-| **Low 4 bits are zero** | 2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field | 3 bytes: first byte is 0x00, second byte defines type; third byte defines field |
+| **Low 4 bits are zero** | 2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field | 3 bytes: first byte is `0x00`, second byte defines type; third byte defines field |
**Caution:** Even though the Field ID consists of the two elements that are used to sort fields, you should not sort by the serialized Field ID itself, because the byte structure of the Field ID changes the sort order.
@@ -342,6 +342,7 @@ When representing these fields in JSON objects, most are represented as JSON num
Another special case is the `TransactionType` field. In JSON, this field is conventionally represented as a string with the name of the transaction type, but in binary, this field is a UInt16. The `TRANSACTION_TYPES` object in the [definitions file](#definitions-file) maps these strings to specific numeric values.
+
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
diff --git a/content/references/rippled-api/commandline-usage.md b/content/references/rippled-api/commandline-usage.md
index dd41e01b00..39b9617321 100644
--- a/content/references/rippled-api/commandline-usage.md
+++ b/content/references/rippled-api/commandline-usage.md
@@ -46,7 +46,7 @@ Daemon mode is the default mode of operation for `rippled`. In addition to the [
| `--import` | Before fully starting, import ledger data from another `rippled` server's ledger store. Requires a valid `[import_db]` stanza in the config file. |
| `--net` | **DEPRECATED** Intended for debugging: do not build a local ledger until one can be obtained from the network. |
| `--nodetoshard` | Before fully starting, copy any complete [history shards](history-sharding.html) from the ledger store into the shard store, up to the shard store's configured maximum disk space. Uses large amounts of CPU and I/O. Caution: this command copies data (instead of moving it), so you must have enough disk space to store the data in both the shard store and the ledger store. |
-| `--quorum {QUORUM}` | This option is intended for bootstrapping [test networks](parallel-networks.html). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. **Warning:** If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration. |
+| `--quorum {QUORUM}` | This option is intended for starting [test networks](parallel-networks.html). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. **Warning:** If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration. |
| `--validateShards` | Check that the data in the shard store is valid and consistent with the network history. For more information on the shard store, see [History Sharding](history-sharding.html). |
## Stand-Alone Mode Options
@@ -59,7 +59,7 @@ Run in [stand-alone mode](rippled-server-modes.html). In this mode, `rippled` do
### Initial Ledger Options
-The following options determine which ledger to load first when starting up. These options are intended for replaying historical ledgers or bootstrapping test networks.
+The following options determine which ledger to load first when starting up. These options are intended for replaying historical ledgers or starting test networks.
| Option | Description |
|:----------------------|:-----------------------------------------------------|
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-header.md b/content/references/rippled-api/ledger-data-formats/ledger-header.md
index f4976e1d3b..503d3759f0 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-header.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-header.md
@@ -24,7 +24,7 @@ Every ledger version has a unique header that describes the contents. You can lo
## Close Flags
-The ledger has only one flag defined for closeFlags: **sLCF_NoConsensusTime** (value `1`). If this flag is enabled, it means that validators had different close times for the ledger, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger version contains a `close_time` value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.)
+The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different close times for the ledger, but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger version contains a `close_time` value that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.)
The `closeFlags` field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
index cceb8bba24..3ff2f6fd29 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md
@@ -31,17 +31,17 @@ The `AccountRoot` object has the following fields:
| Field | JSON Type | [Internal Type][] | Description |
|:------------------------------|:----------|:------------------|:-------------|
| `LedgerEntryType` | String | UInt16 | The value `0x0061`, mapped to the string `AccountRoot`, indicates that this is an AccountRoot object. |
-| `Account` | String | AccountID | The identifying address of this account, such as rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn. |
+| `Account` | String | AccountID | The identifying (classic) address of this [account](accounts.html). |
| `Balance` | String | Amount | The account's current [XRP balance in drops][XRP, in drops], represented as a string. |
| [`Flags`](#accountroot-flags) | Number | UInt32 | A bit-map of boolean flags enabled for this account. |
| `OwnerCount` | Number | UInt32 | The number of objects this account owns in the ledger, which contributes to its owner reserve. |
| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `Sequence` | Number | UInt32 | The sequence number of the next valid transaction for this account. (Each account starts with Sequence = 1 and increases each time a transaction is made.) |
-| `AccountTxnID` | String | Hash256 | _(Optional)_ The identifying hash of the transaction most recently sent by this account. This field must be enabled to use the [AccountTxnID transaction field](transaction-common-fields.html#accounttxnid). To enable it, send an [AccountSet transaction with the asfAccountTxnID flag enabled](accountset.html#accountset-flags). |
-| `Domain` | String | VariableLength | _(Optional)_ A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. |
+| `AccountTxnID` | String | Hash256 | _(Optional)_ The identifying hash of the transaction most recently sent by this account. This field must be enabled to use the [`AccountTxnID` transaction field](transaction-common-fields.html#accounttxnid). To enable it, send an [AccountSet transaction with the `asfAccountTxnID` flag enabled](accountset.html#accountset-flags). |
+| `Domain` | String | Blob | _(Optional)_ A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. |
| `EmailHash` | String | Hash128 | _(Optional)_ 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/). |
-| `MessageKey` | String | VariableLength | _(Optional)_ A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. No more than 33 bytes. |
+| `MessageKey` | String | Blob | _(Optional)_ A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. No more than 33 bytes. |
| `RegularKey` | String | AccountID | _(Optional)_ The address of a [key pair](cryptographic-keys.html) that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
| `TickSize` | Number | UInt8 | _(Optional)_ How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Added by the [TickSize amendment][].)_ |
| `TransferRate` | Number | UInt32 | _(Optional)_ A [transfer fee](https://ripple.com/knowledge_center/transfer-fees/) to charge other users for sending currency issued by this account to each other. |
@@ -50,21 +50,21 @@ The `AccountRoot` object has the following fields:
## 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_.
+There are several options which can be either enabled or disabled for an account. These options can be changed with an [AccountSet transaction][]. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with **`lsf`**.
AccountRoot objects can have the following flag values:
-| Flag Name | Hex Value | Decimal Value | Description | Corresponding [AccountSet Flag](accountset.html#accountset-flags) |
-|-----------|-----------|---------------|-------------|-------------------------------|
-| lsfDefaultRipple | 0x00800000 | 8388608 | Enable [rippling](rippling.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. | asfDefaultRipple |
-| lsfDepositAuth | 0x01000000 | 16777216 | This account can only receive funds from transactions it sends, and from [preauthorized](depositauth.html#preauthorization) accounts. (It has [DepositAuth](depositauth.html) enabled.) | asfDepositAuth |
-| lsfDisableMaster | 0x00100000 | 1048576 | Disallows use of the master key to sign transactions for this account. | asfDisableMaster |
-| lsfDisallowXRP | 0x00080000 | 524288 | Client applications should not send XRP to this account. Not enforced by `rippled`. | asfDisallowXRP |
-| lsfGlobalFreeze | 0x00400000 | 4194304 | All assets issued by this address are frozen. | asfGlobalFreeze |
-| lsfNoFreeze | 0x00200000 | 2097152 | This address cannot freeze trust lines connected to it. Once enabled, cannot be disabled. | asfNoFreeze |
-| lsfPasswordSpent | 0x00010000 | 65536 | The account has used its free SetRegularKey transaction. | (None) |
-| lsfRequireAuth | 0x00040000 | 262144 | This account must individually approve other users for those users to hold this account's issuances. | asfRequireAuth |
-| lsfRequireDestTag | 0x00020000 | 131072 | Requires incoming payments to specify a Destination Tag. | asfRequireDest |
+| Flag Name | Hex Value | Decimal Value | Corresponding [AccountSet Flag](accountset.html#accountset-flags) | Description |
+|---------------------|--------------|---------------|--------------------|----|
+| `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 can only receive funds from transactions it sends, and from [preauthorized](depositauth.html#preauthorization) accounts. (It has [DepositAuth](depositauth.html) enabled.) |
+| `lsfDisableMaster` | `0x00100000` | 1048576 | `asfDisableMaster` | Disallows use of the master key to sign transactions for this account. |
+| `lsfDisallowXRP` | `0x00080000` | 524288 | `asfDisallowXRP` | Client applications should not send XRP to this account. Not enforced by `rippled`. |
+| `lsfGlobalFreeze` | `0x00400000` | 4194304 | `asfGlobalFreeze` | All assets issued by this address are frozen. |
+| `lsfNoFreeze` | `0x00200000` | 2097152 | `asfNoFreeze` | This address cannot freeze trust lines connected to it. Once enabled, cannot be disabled. |
+| `lsfPasswordSpent` | `0x00010000` | 65536 | (None) | The account has used its free SetRegularKey transaction. |
+| `lsfRequireAuth` | `0x00040000` | 262144 | `asfRequireAuth` | This account must individually approve other users for those users to hold this account's issued currencies. |
+| `lsfRequireDestTag` | `0x00020000` | 131072 | `asfRequireDest` | Requires incoming payments to specify a Destination Tag. |
## AccountRoot ID Format
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md
index a4155e6741..1af3d0af79 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md
@@ -30,9 +30,9 @@ The `Amendments` object type contains a list of [Amendments](amendments.html) th
## {{currentpage.name}} Fields
| Name | JSON Type | [Internal Type][] | Description |
-|-------------------|-----------|-------------------|-------------|
-| `Amendments` | Array | STI_VECTOR256 | _(Optional)_ Array of 256-bit [amendment IDs](amendments.html#about-amendments) for all currently-enabled amendments. If omitted, there are no enabled amendments. |
-| `Majorities` | Array | STI_ARRAY | _(Optional)_ Array of objects describing the status of amendments that have majority support but are not yet enabled. If omitted, there are no pending amendments with majority support. |
+|-------------------|-----------|-----------|---------------------|
+| `Amendments` | Array | Vector256 | _(Optional)_ Array of 256-bit [amendment IDs](amendments.html#about-amendments) for all currently-enabled amendments. If omitted, there are no enabled amendments. |
+| `Majorities` | Array | STArray | _(Optional)_ Array of objects describing the status of amendments that have majority support but are not yet enabled. If omitted, there are no pending amendments with majority support. |
| `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for the Amendments object type, so this value is always `0`. |
| `LedgerEntryType` | String | UInt16 | The value `0x0066`, mapped to the string `Amendments`, indicates that this object describes the status of amendments to the XRP Ledger. |
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md
index c2a4a732e6..0768482396 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md
@@ -6,7 +6,7 @@ The `DirectoryNode` object type provides a list of links to other objects in the
There are two kinds of Directories:
* **Owner directories** list other objects owned by an account, such as `RippleState` or `Offer` objects.
-* **Offer directories** list the offers available in the distributed exchange. A single Offer directory contains all the offers that have the same exchange rate for the same issuances.
+* **Offer directories** list the offers available in the distributed exchange. A single Offer directory contains all the offers that have the same exchange rate for the same issued currency.
## Example {{currentpage.name}} JSON
@@ -61,10 +61,10 @@ There are two kinds of Directories:
| `IndexPrevious` | Number | UInt64 | (Optional) If this Directory consists of multiple pages, this ID links to the previous object in the chain, wrapping around at the beginning. |
| `Owner` | String | AccountID | (Owner Directories only) The address of the account that owns the objects in this directory. |
| `ExchangeRate` | Number | UInt64 | (Offer Directories only) **DEPRECATED**. Do not use. |
-| `TakerPaysCurrency` | String | Hash160 | (Offer Directories only) The currency code of the TakerPays amount from the offers in this directory. |
-| `TakerPaysIssuer` | String | Hash160 | (Offer Directories only) The issuer of the TakerPays amount from the offers in this directory. |
-| `TakerGetsCurrency` | String | Hash160 | (Offer Directories only) The currency code of the TakerGets amount from the offers in this directory. |
-| `TakerGetsIssuer` | String | Hash160 | (Offer Directories only) The issuer of the TakerGets amount from the offers in this directory. |
+| `TakerPaysCurrency` | String | Hash160 | (Offer Directories only) The currency code of the `TakerPays` amount from the offers in this directory. |
+| `TakerPaysIssuer` | String | Hash160 | (Offer Directories only) The issuer of the `TakerPays` amount from the offers in this directory. |
+| `TakerGetsCurrency` | String | Hash160 | (Offer Directories only) The currency code of the `TakerGets` amount from the offers in this directory. |
+| `TakerGetsIssuer` | String | Hash160 | (Offer Directories only) The issuer of the `TakerGets` amount from the offers in this directory. |
## Directory ID Formats
@@ -87,7 +87,7 @@ There are three different formulas for creating the ID of a DirectoryNode, depen
* The AccountID from the `TakerPaysIssuer`
* The AccountID from the `TakerGetsIssuer`
-The lower 64 bits of an Offer Directory's ID represent the TakerPays amount divided by TakerGets amount from the offer(s) in that directory as a 64-bit number in the XRP Ledger's internal amount format.
+The lower 64 bits of an Offer Directory's ID represent the `TakerPays` amount divided by `TakerGets` amount from the offer(s) in that directory as a 64-bit number in the XRP Ledger's internal amount format.
**If the DirectoryNode is not the first page in the Directory** (regardless of whether it is an Owner Directory or an Offer Directory), then it has an ID that is the [SHA-512Half][] of the following values, concatenated in order:
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
index 3ce1dc1f02..427ec34a92 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.md
@@ -36,22 +36,22 @@ An `Escrow` object is associated with two addresses:
An `Escrow` object has the following fields:
-| Name | JSON Type | [Internal Type][] | Description |
-|-------------------|-----------|---------------|-------------|
+| Name | JSON Type | [Internal Type][] | Description |
+|---------------------|-----------|-----------|--------------------------------|
| `LedgerEntryType` | String | UInt16 | The value `0x0075`, mapped to the string `Escrow`, indicates that this object is an `Escrow` object. |
-| `Account` | String | AccountID | 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. |
-| `Destination` | String | AccountID | The destination address where the XRP is paid if the held payment is successful. |
-| `Amount` | String | Amount | The amount of XRP, in drops, to be delivered by the held payment. |
-| `Condition` | String | VariableLength | _(Optional)_ 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. |
-| `CancelAfter` | Number | UInt32 | _(Optional)_ 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. |
-| `FinishAfter` | Number | UInt32 | _(Optional)_ 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 | A bit-map of boolean flags. No flags are defined for the Escrow type, so this value is always `0`. |
-| `SourceTag` | Number | UInt32 | _(Optional)_ 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 | _(Optional)_ An arbitrary tag to further specify the destination for this held payment, such as a hosted recipient at the destination address. |
+| `Account` | String | AccountID | 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. |
+| `Destination` | String | AccountID | The destination address where the XRP is paid if the held payment is successful. |
+| `Amount` | String | Amount | The amount of XRP, in drops, to be delivered by the held payment. |
+| `Condition` | String | Blob | _(Optional)_ 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. |
+| `CancelAfter` | Number | UInt32 | _(Optional)_ 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. |
+| `FinishAfter` | Number | UInt32 | _(Optional)_ 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 | A bit-map of boolean flags. No flags are defined for the Escrow type, so this value is always `0`. |
+| `SourceTag` | Number | UInt32 | _(Optional)_ 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 | _(Optional)_ An arbitrary tag to further specify the destination for this held payment, such as a hosted recipient at the destination address. |
| `OwnerNode` | String | UInt64 | 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`. |
| `DestinationNode` | String | UInt64 | _(Optional)_ 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][]. |
-| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
-| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
+| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
+| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
## Escrow ID Format
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md
index 836ad07079..0d1185be62 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.md
@@ -39,8 +39,8 @@ A `LedgerHashes` object has the following fields:
| `LedgerEntryType` | String | UInt16 | The value `0x0068`, mapped to the string `LedgerHashes`, indicates that this object is a list of ledger hashes. |
| `FirstLedgerSequence` | Number | UInt32 | **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`.) |
| `LastLedgerSequence` | Number | UInt32 | The [Ledger Index][] of the last entry in this object's `Hashes` array. |
-| `Hashes` | Array of Strings | STI_VECTOR256 | An array of up to 256 ledger hashes. The contents depend on which sub-type of `LedgerHashes` object this is. |
-| `Flags` | Number | UInt32 | A bit-map of boolean flags for this object. No flags are defined for this type. |
+| `Hashes` | Array of Strings | Vector256 | An array of up to 256 ledger hashes. The contents depend on which sub-type of `LedgerHashes` object this is. |
+| `Flags` | Number | UInt32 | A bit-map of boolean flags for this object. No flags are defined for this type. |
## Recent History LedgerHashes
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/offer.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/offer.md
index bf419563b8..879b769e04 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/offer.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/offer.md
@@ -51,14 +51,14 @@ An `Offer` object has the following fields:
## 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_.
+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:
-| Flag Name | Hex Value | Decimal Value | Description | Corresponding [OfferCreate Flag](offercreate.html#offercreate-flags) |
-|-----------|-----------|---------------|-------------|------------------------|
-| lsfPassive | 0x00010000 | 65536 | The object was placed as a passive offer. This has no effect on the object in the ledger. | tfPassive |
-| lsfSell | 0x00020000 | 131072 | The object was placed as a sell offer. This has no effect on the object in the ledger (because tfSell only matters if you get a better rate than you asked for, which cannot happen after the object enters the ledger). | tfSell |
+| 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). |
## Offer ID Format
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
index 3cac47dfe7..a4c897a2da 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md
@@ -45,7 +45,7 @@ A `PayChannel` object has the following fields:
| `Destination` | String | AccountID | 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. |
| `Amount` | String | Amount | Total [XRP, in drops][], that has been allocated to this channel. This includes XRP that has been paid to the destination address. This is initially set by the transaction that created the channel and can be increased if the source address sends a PaymentChannelFund transaction. |
| `Balance` | String | Amount | Total [XRP, in drops][], already paid out by the channel. The difference between this value and the `Amount` field is how much XRP can still be paid to the destination address with PaymentChannelClaim transactions. If the channel closes, the remaining difference is returned to the source address. |
-| `PublicKey` | String | PubKey | 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. |
+| `PublicKey` | String | Blob | 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 | 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. |
| `OwnerNode` | String | UInt64 | 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 | The identifying hash of the transaction that most recently modified this object. |
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md
index d257236800..8ca91b84cc 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md
@@ -7,7 +7,7 @@ The `RippleState` object type connects two accounts in a single currency. Concep
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](accounts.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. Frequently, 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` 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.
## Example {{currentpage.name}} JSON
@@ -54,27 +54,27 @@ A `RippleState` object has the following fields:
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `LowNode` | String | UInt64 | (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. |
| `HighNode` | String | UInt64 | (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. |
-| `LowQualityIn` | Number | UInt32 | (Optional) The inbound quality set by the low account, as an integer in the implied ratio LowQualityIn:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. |
-| `LowQualityOut` | Number | UInt32 | (Optional) The outbound quality set by the low account, as an integer in the implied ratio LowQualityOut:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. |
-| `HighQualityIn` | Number | UInt32 | (Optional) The inbound quality set by the high account, as an integer in the implied ratio HighQualityIn:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. |
-| `HighQualityOut` | Number | UInt32 | (Optional) The outbound quality set by the high account, as an integer in the implied ratio HighQualityOut:1,000,000,000. The value 0 is equivalent to 1 billion, or face value. |
+| `LowQualityIn` | Number | UInt32 | (Optional) 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 | (Optional) 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. |
+| `HighQualityIn` | Number | UInt32 | (Optional) 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 | (Optional) 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. |
## 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_.
+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:
-| Flag Name | Hex Value | Decimal Value | Description | Corresponding [TrustSet Flag](trustset.html#trustset-flags) |
-|-----------|-----------|---------------|-------------|------------------------|
-| lsfLowReserve | 0x00010000 | 65536 | This RippleState object [contributes to the low account's owner reserve](#contributing-to-the-owner-reserve). | (None) |
-| lsfHighReserve | 0x00020000 |131072 | This RippleState object [contributes to the high account's owner reserve](#contributing-to-the-owner-reserve). | (None) |
-| lsfLowAuth | 0x00040000 | 262144 | The low account has authorized the high account to hold the low account's issuances. | tfSetAuth |
-| lsfHighAuth | 0x00080000 | 524288 | The high account has authorized the low account to hold the high account's issuances. | tfSetAuth |
-| lsfLowNoRipple | 0x00100000 | 1048576 | The low account [has disabled rippling](rippling.html) from this trust line to other trust lines with the same account's NoRipple flag set. | tfSetNoRipple |
-| lsfHighNoRipple | 0x00200000 | 2097152 | The high account [has disabled rippling](rippling.html) from this trust line to other trust lines with the same account's NoRipple flag set. | tfSetNoRipple |
-| lsfLowFreeze | 0x00400000 | 4194304 | The low account has frozen the trust line, preventing the high account from transferring the asset. | tfSetFreeze |
-| lsfHighFreeze | 0x00800000 | 8388608 | The high account has frozen the trust line, preventing the low account from transferring the asset. | tfSetFreeze |
+| 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). |
+| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | The low account has authorized the high account to hold the low account's issued currency. |
+| `lsfHighAuth` | `0x00080000` | 524288 | `tfSetAuth` | The high account has authorized the low account to hold the high account's issued currency. |
+| `lsfLowNoRipple` | `0x00100000` | 1048576 | `tfSetNoRipple` | The low account [has disabled rippling](rippling.html) from this trust line. |
+| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | The high account [has disabled rippling](rippling.html) from this trust line. |
+| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | The low account has frozen the trust line, preventing the high account from transferring the asset. |
+| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | The high account has frozen the trust line, preventing the low account from transferring the asset. |
## Contributing to the Owner Reserve
@@ -88,16 +88,16 @@ The values that count towards a trust line's non-default state are as follows:
| `HighLimit` is not `0` | `LowLimit` is not `0` |
| `LowQualityIn` is not `0` and not `1000000000` | `HighQualityIn` is not `0` and not `1000000000` |
| `LowQualityOut` is not `0` and not `1000000000` | `HighQualityOut` is not `0` and not `1000000000` |
-| **lsfHighNoRipple** flag is not in its default state | **lsfLowNoRipple** flag is not in its default state |
-| **lsfHighFreeze** flag is enabled | **lsfLowFreeze** flag is enabled |
+| `lsfHighNoRipple` flag is not in its default state | `lsfLowNoRipple` flag is not in its default state |
+| `lsfHighFreeze` flag is enabled | `lsfLowFreeze` flag is enabled |
-The **lsfLowAuth** and **lsfHighAuth** flags do not count against the default state, because they cannot be disabled.
+The **`lsfLowAuth`** and **`lsfHighAuth`** flags do not count against the default state, because they cannot be disabled.
-The default state of the two NoRipple flags depends on the state of the [lsfDefaultRipple flag](accountroot.html#accountroot-flags) in their corresponding AccountRoot objects. If DefaultRipple 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 DefaultRipple, 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 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.
-**Note:** Prior to the introduction of the DefaultRipple flags in `rippled` version 0.27.3 (March 10, 2015), the default state for all trust lines was with both NoRipple flags disabled (rippling enabled).
+**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 DefaultRipple flag, that account's reserve stays the same initially. If an account modifies a trust line, `rippled` re-evaluates whether that individual trust line is in its default state and should contribute to the owner reserve.
+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.
## RippleState ID Format
diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
index ee4926972c..80f6c1a984 100644
--- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
+++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md
@@ -3,7 +3,7 @@
_(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 SignerList using a [SignerListSet transaction][].
+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][].
## Example {{currentpage.name}} JSON
@@ -48,26 +48,26 @@ A `SignerList` object has the following fields:
| Name | JSON Type | Internal Type | Description |
|:--------------------|:----------|:--------------|:---------------------------|
| `LedgerEntryType` | String | UInt16 | The value `0x0053`, mapped to the string `SignerList`, indicates that this object is a SignerList object. |
-| `Flags` | Number | UInt32 | A bit-map of Boolean flags enabled for this SignerList. For more information, see [SignerList Flags](#signerlist-flags). |
+| `Flags` | Number | UInt32 | A bit-map of Boolean flags enabled for this signer list. For more information, see [SignerList Flags](#signerlist-flags). |
| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `OwnerNode` | String | UInt64 | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. |
-| `SignerEntries` | Array | Array | An array of SignerEntry objects representing the parties who are part of this signer list. |
+| `SignerEntries` | Array | Array | An array of Signer Entry objects representing the parties who are part of this signer list. |
| `SignerListID` | Number | UInt32 | An ID for this signer list. Currently always set to `0`. If a future [amendment](amendments.html) allows multiple signer lists for an account, this may change. |
| `SignerQuorum` | Number | UInt32 | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. |
The `SignerEntries` may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys.
-### SignerEntry Object
+### Signer Entry Object
-Each member of the `SignerEntries` field is an object that describes that signer in the list. A SignerEntry has the following fields:
+Each member of the `SignerEntries` field is an object that describes that signer in the list. A Signer Entry has the following fields:
| Name | JSON Type | Internal Type | Description |
|:---------------|:----------|:--------------|:--------------------------------|
| `Account` | String | AccountID | An XRP Ledger address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. |
-| `SignerWeight` | Number | UInt16 | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. |
+| `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. |
-When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot object](accountroot.html), then only the master secret associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.
+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.
## {{currentpage.name}} Flags
@@ -75,27 +75,25 @@ _(Added by the [MultiSignReserve amendment][].)_
SignerList objects can have the following flag value:
-| 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. |
+| 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. |
-## SignerLists and Reserves
+## Signer Lists and Reserves
-A SignerList contributes to its owner's [reserve requirement](reserves.html).
+A signer list contributes to its owner's [reserve requirement](reserves.html).
-Without the [MultiSignReserve amendment][], the SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](ripplestate.html)) or [Offer](offer.html) object in the ledger.
+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 5 XRP.
-With the [MultiSignReserve amendment][] enabled, the SignerList counts as one object, regardless of how many members it has. As a result, the owner reserve associated with a SignerList is 5 XRP, regardless of how many members it has.
-
-The reserve requirement does not change for SignerLists created before the MultiSignReserve amendment. To take advantage of the new reserve, update the SignerList 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 SignerList object is the SHA-512Half of the following values, concatenated in order:
+The ID of a signer list object is the SHA-512Half of the following values, concatenated in order:
* The RippleState space key (`0x0053`)
-* The AccountID of the owner of the SignerList
-* The SignerListID (currently always `0`)
+* The AccountID of the owner of the signer list
+* The `SignerListID` (currently always `0`)
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/peer-port-methods/health-check.md b/content/references/rippled-api/peer-port-methods/health-check.md
new file mode 100644
index 0000000000..879094e711
--- /dev/null
+++ b/content/references/rippled-api/peer-port-methods/health-check.md
@@ -0,0 +1,109 @@
+# Health Check
+[[Source]](https://github.com/ripple/rippled/blob/de0c52738785de8bf837f9124da65c7905e7bb5a/src/ripple/overlay/impl/OverlayImpl.cpp#L1084-L1168 "Source")
+
+The Health Check is a special [peer port method](peer-port-methods.html) for reporting on the health of an individual `rippled` server. This method is intended for use in automated monitoring to recognize outages and prompt automated or manual interventions such as restarting the server. [New in: rippled 1.6.0][]
+
+This method checks several metrics to see if they are in ranges generally considered healthy. If all metrics are in normal ranges, this method reports that the server is healthy. If any metric is outside normal ranges, this method reports that the server is unhealthy and reports the metric(s) that are unhealthy. Since some metrics may rapidly fluctuate into and out of unhealthy ranges, you should not raise alerts unless the health check fails multiple times in a row.
+
+**Note:** Since the health check is a [peer port method](peer-port-methods.html), it is not available when testing the server in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode).
+
+
+## Request Format
+
+To request the Health Check information, make the following HTTP request:
+
+- **Protocol:** https
+- **HTTP Method:** GET
+- **Host:** (any `rippled` server, by hostname or IP address)
+- **Port:** (the port number where the `rippled` server uses the Peer Protocol, typically 51235)
+- **Path:** `/health`
+- **Security:** Most `rippled` servers use a self-signed certificate to respond to the request. By default, most tools (including web browsers) flag or block such responses for being untrusted. You must ignore the certificate checking (for example, if using cURL, add the `--insecure` flag) to display a response from those servers.
+
+
+
+## Example Response
+
+
+
+*Healthy*
+
+```json
+HTTP/1.1 200 OK
+Server: rippled-1.6.0-b8
+Content-Type: application/json
+Connection: close
+Transfer-Encoding: chunked
+
+{
+ "info": {}
+}
+```
+
+*Warning*
+
+```json
+HTTP/1.1 503 Service Unavailable
+Server: rippled-1.6.0
+Content-Type: application/json
+Connection: close
+Transfer-Encoding: chunked
+
+{
+ "info": {
+ "server_state": "connected",
+ "validated_ledger": -1
+ }
+}
+```
+
+*Critical*
+
+```json
+HTTP/1.1 500 Internal Server Error
+Server: rippled-1.6.0
+Content-Type: application/json
+Connection: close
+Transfer-Encoding: chunked
+
+{
+ "info": {
+ "peers": 0,
+ "server_state": "disconnected",
+ "validated_ledger":-1
+ }
+}
+```
+
+
+
+## Response Format
+
+The response's HTTP status code indicates the health of the server:
+
+| Status Code | Health Status | Description |
+|:------------------------------|:--------------|:-----------------------------|
+| **200 OK** | Healthy | All health metrics are within acceptable ranges. |
+| **503 Service Unavailable** | Warning | One or more metric is in the warning range. Manual intervention may or may not be necessary. |
+| **500 Internal Server Error** | Critical | One or more metric is in the critical range. There is a serious problem that probably needs manual intervention to fix. |
+
+The response body is a JSON object with a single `info` object at the top level. The `info` object contains values for each metric that is in a warning or critical range. The response omits metrics that are in a healthy range, so a fully healthy server has an empty object.
+
+The `info` object may contain the following fields:
+
+| `Field` | Value | Description |
+|:--------------------|:--------|:---------------------------------------------|
+| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, the server is [amendment blocked](amendments.html#amendment-blocked) and must be upgraded to remain synced with the network; this state is critical. If the server is not amendment blocked, this field is omitted. |
+| `load_factor` | Number | _(May be omitted)_ A measure of the overall load the server is under. This reflects I/O, CPU, and memory limitations. This is a warning if the load factor is over 100, or critical if the load factor is 1000 or higher. |
+| `peers` | Number | _(May be omitted)_ The number of [peer servers](peer-protocol.html) this server is connected to. This is a warning if connected to 7 or fewer peers, and critical if connected to zero peers. |
+| `server_state` | String | _(May be omitted)_ The current [server state](rippled-server-states.html). This is a warning if the server is in the `tracking`, `syncing`, or `connected` states. This is critical if the server is in the `disconnected` state. |
+| `validated_ledger` | Number | _(May be omitted)_ The number of seconds since the last time a ledger was validated by [consensus](intro-to-consensus.html). If there is no validated ledger available ([as during the initial sync period when starting the server](server-doesnt-sync.html#normal-syncing-behavior)), this is the value `-1` and is considered a warning. This metric is also a warning if the last validated ledger was at least 7 seconds ago, or critical if the last validated ledger was at least 20 seconds ago. |
+
+## See Also
+
+For guidance interpreting the results of the health check, see [Health Check Interventions](health-check-interventions.html).
+
+
+
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/references/rippled-api/peer-crawler.md b/content/references/rippled-api/peer-port-methods/peer-crawler.md
similarity index 86%
rename from content/references/rippled-api/peer-crawler.md
rename to content/references/rippled-api/peer-port-methods/peer-crawler.md
index d81fb93ab6..495193d33a 100644
--- a/content/references/rippled-api/peer-crawler.md
+++ b/content/references/rippled-api/peer-port-methods/peer-crawler.md
@@ -1,6 +1,6 @@
# Peer Crawler
-The Peer Crawler is a special API endpoint for reporting on the health and topology of the peer-to-peer network. This API method is available by default on a non-privileged basis through the [Peer Protocol](peer-protocol.html) port, which is also used for `rippled` servers' peer-to-peer communications about consensus, ledger history, and other necessary information.
+The Peer Crawler is a special [peer port method](peer-port-methods.html) for reporting on the health and topology of the peer-to-peer network. This API method is available by default on a non-privileged basis through the [Peer Protocol](peer-protocol.html) port, which is also used for `rippled` servers' peer-to-peer communications about consensus, ledger history, and other necessary information.
The information reported by the peer crawler is effectively public, and can be used to report on the overall XRP Ledger network, its health, and topology.
@@ -15,7 +15,7 @@ To request the Peer Crawler information, make the following HTTP request:
- **Path:** `/crawl`
- **Security:** Most `rippled` servers use a self-signed certificate to respond to the request. By default, most tools (including web browsers) flag or block such responses for being untrusted. You must ignore the certificate checking (for example, if using cURL, add the `--insecure` flag) to display a response from those servers.
-**Tip:** Since this request uses the GET method, you can test this request using just the URL bar of your web browser. For example, requests peer crawler information from one of Ripple's public servers.
+**Tip:** Since this request uses the GET method, you can test this request using the URL bar of your web browser. For example, requests peer crawler information from one of Ripple's public servers.
## Response Format
@@ -77,7 +77,7 @@ Response:
- [Peer Protocol](peer-protocol.html)
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
-- The [XRPL Network Crawler](https://github.com/ripple/rippled-network-crawler) is an example of a tool that uses the peer crawler data to collect and store information about the XRP Ledger network.
+- The [XRP Ledger Network Crawler](https://github.com/ripple/rippled-network-crawler) is an example of a tool that uses the peer crawler data to collect and store information about the XRP Ledger network.
diff --git a/content/references/rippled-api/validator-list.md b/content/references/rippled-api/peer-port-methods/validator-list.md
similarity index 76%
rename from content/references/rippled-api/validator-list.md
rename to content/references/rippled-api/peer-port-methods/validator-list.md
index f4575d9ee4..c933bb5979 100644
--- a/content/references/rippled-api/validator-list.md
+++ b/content/references/rippled-api/peer-port-methods/validator-list.md
@@ -6,7 +6,8 @@ Like the [Peer Crawler](peer-crawler.html), the validator list method is availab
## Request Format
-To request the Peer Crawler information, make the following HTTP request:
+To request the Validator List information, make the following HTTP
+request:
- **Protocol:** https
- **HTTP Method:** GET
@@ -20,7 +21,7 @@ To request the Peer Crawler information, make the following HTTP request:
The validator list contents are signed with a separate cryptographic key, so you can verify their integrity regardless of the TLS certificate used.
-**Tip:** Since this request uses the GET method, you can test this request using just the URL bar of your web browser. For example, requests Ripple's recommended list from one of Ripple's public servers.
+**Tip:** Since this request uses the GET method, you can test this request using the URL bar of your web browser. For example, requests Ripple's recommended list from one of Ripple's public servers.
## Response Format
@@ -47,15 +48,15 @@ One of the main purposes of manifests relates to rotating validator keys. When a
The data encoded in a manifest is as follows:
-| Field | Internal Type | Description |
-|:------------------|:--------------|:-----------------------------------------|
-| sfPublicKey | Blob | The master public key that uniquely identifies this person or organization. This can be a 33-byte secp256k1 public key, or a 32-byte Ed25519 public key prefixed with the byte `0xED`. |
-| sfMasterSignature | Blob | A signature of this manifest data from the master key pair. This proves the authenticity of the manifest. |
-| sfSequence | UInt32 | A sequence number for this manifest. A higher number indicates a newer manifest that invalidates all older manifests from the same master public key. |
-| sfVersion | UInt16 | A version number indicating the manifest format used. A higher number indicates a newer manifest format, including breaking changes compared to the previous manifest format. |
-| sfDomain | Blob | _(Optional)_ A domain name owned by this person or organization, ASCII-encoded. |
-| sfSigningPubKey | Blob | _(Optional)_ The ephemeral public key of the key pair that this person or organization is currently using. This must be a 33-byte secp256k1 public key. |
-| sfSignature | Blob | _(Optional)_ A signature of this manifest data from the ephemeral key pair. |
+| Field | Internal Type | Description |
+|:--------------------|:--------------|:-----------------------------------------|
+| `sfPublicKey` | Blob | The master public key that uniquely identifies this person or organization. This can be a 33-byte secp256k1 public key, or a 32-byte Ed25519 public key prefixed with the byte `0xED`. |
+| `sfMasterSignature` | Blob | A signature of this manifest data from the master key pair. This proves the authenticity of the manifest. |
+| `sfSequence` | UInt32 | A sequence number for this manifest. A higher number indicates a newer manifest that invalidates all older manifests from the same master public key. |
+| `sfVersion` | UInt16 | A version number indicating the manifest format used. A higher number indicates a newer manifest format, including breaking changes compared to the previous manifest format. |
+| `sfDomain` | Blob | _(Optional)_ A domain name owned by this person or organization, ASCII-encoded. |
+| `sfSigningPubKey` | Blob | _(Optional)_ The ephemeral public key of the key pair that this person or organization is currently using. This must be a 33-byte secp256k1 public key. |
+| `sfSignature` | Blob | _(Optional)_ A signature of this manifest data from the ephemeral key pair. |
The `sfMasterSignature` and `sfSignature` signatures are created from signing the [serialized](serialization.html) binary data of the manifest, excluding the signature fields (`sfMasterSignature` and `sfSignature`) themselves.
@@ -68,7 +69,7 @@ If you decode the `blob` from base64, the result is a JSON object with the follo
|:-------------|:-------|:-----------------------------------------------------|
| `sequence` | Number | Unique sequence number for this list. A larger sequence number indicates a newer list; only the newest list is valid at a time. |
| `expiration` | Number | The time this list expires, in [seconds since the Ripple Epoch][]. |
-| `validators | Array | A list of recommended validators. |
+| `validators` | Array | A list of recommended validators. |
Each member of the `validators` array has the following fields:
@@ -99,7 +100,7 @@ GET https://localhost:51235/vl
*cURL*
```
-curl --insecure https://localhost:51235/vl
+curl --insecure https://localhost:51235/vl/ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
```
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md
index c0e6e2ad50..b135a25f40 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md
@@ -39,7 +39,7 @@ An example of the request format:
```sh
#Syntax: account_currencies account [ledger_index|ledger_hash] [strict]
-rippled account_info rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn validated strict
+rippled account_currencies rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn validated strict
```
@@ -133,6 +133,21 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "ledger_hash" : "F43A801ED4562FA744A35755B86BE898D91C5643BF499924EA3C69491B8C28D1",
+ "ledger_index" : 56843649,
+ "receive_currencies" : [ "USD" ],
+ "send_currencies" : [ "NGN", "TRC" ],
+ "status" : "success",
+ "validated" : true
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md
index 4de670c1ac..690712944b 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md
@@ -166,6 +166,31 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "account_data" : {
+ "Account" : "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
+ "Balance" : "9986",
+ "Flags" : 1114112,
+ "LedgerEntryType" : "AccountRoot",
+ "OwnerCount" : 0,
+ "PreviousTxnID" : "0705FE3F52057924C288296EF0EBF668E0C1A3646FBA8FAF9B73DCC0A797B4B2",
+ "PreviousTxnLgrSeq" : 51948740,
+ "RegularKey" : "rhLkGGNZdjSpnHJw4XAFw1Jy7PD8TqxoET",
+ "Sequence" : 192220,
+ "index" : "92FA6A9FC8EA6018D5D16532D7795C91BFB0831355BDFDA177E86C8BF997985F"
+ },
+ "ledger_hash" : "8169428EDF7F046F817CE44F5F1DF23AD9FAEFFA2CBA7645C3254D66AA79B46E",
+ "ledger_index" : 56843712,
+ "status" : "success",
+ "validated" : true
+ }
+}
+```
+
The response follows the [standard format][], with the result containing the requested account, its data, and a ledger to which it applies, as the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md
index 9085d6c273..acbdfc95dd 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md
@@ -35,15 +35,15 @@ An example of the request format:
*Commandline*
```sh
-#Syntax:
-rippled account_lines [] []
+#Syntax: account_lines [] [|]
+rippled account_lines r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59
```
[Try it! >](websocket-api-tool.html#account_lines)
-The request accepts the following paramters:
+The request accepts the following parameters:
| `Field` | Type | Description |
|:---------------|:-------------------------------------------|:---------------|
@@ -152,6 +152,252 @@ An example of a successful response:
}
```
+*Commandline*
+```json
+{
+ "result" : {
+ "account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "ledger_current_index" : 56867265,
+ "lines" : [
+ {
+ "account" : "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
+ "balance" : "0",
+ "currency" : "ASP",
+ "limit" : "0",
+ "limit_peer" : "10",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
+ "balance" : "0",
+ "currency" : "XAU",
+ "limit" : "0",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "no_ripple_peer" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
+ "balance" : "5",
+ "currency" : "USD",
+ "limit" : "5",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rHpXfibHgSb64n8kK9QWDpdbfqSpYbM9a4",
+ "balance" : "481.992867407479",
+ "currency" : "MXN",
+ "limit" : "1000",
+ "limit_peer" : "0",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun",
+ "balance" : "0.793598266778297",
+ "currency" : "EUR",
+ "limit" : "1",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rnuF96W4SZoCJmbHYBFoJZpR8eCaxNvekK",
+ "balance" : "0",
+ "currency" : "CNY",
+ "limit" : "3",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E",
+ "balance" : "1.336889190631542",
+ "currency" : "DYM",
+ "limit" : "3",
+ "limit_peer" : "0",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "balance" : "0.3488146605801446",
+ "currency" : "CHF",
+ "limit" : "0",
+ "limit_peer" : "0",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "balance" : "0",
+ "currency" : "BTC",
+ "limit" : "3",
+ "limit_peer" : "0",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "balance" : "11.68225001668339",
+ "currency" : "USD",
+ "limit" : "5000",
+ "limit_peer" : "0",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rpgKWEmNqSDAGFhy5WDnsyPqfQxbWxKeVd",
+ "balance" : "-0.00111",
+ "currency" : "BTC",
+ "limit" : "0",
+ "limit_peer" : "10",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rBJ3YjwXi2MGbg7GVLuTXUWQ8DjL7tDXh4",
+ "balance" : "-0.0008744482690504699",
+ "currency" : "BTC",
+ "limit" : "0",
+ "limit_peer" : "10",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun",
+ "balance" : "0",
+ "currency" : "USD",
+ "limit" : "1",
+ "limit_peer" : "0",
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "razqQKzJRdB4UxFPWf5NEpEG3WMkmwgcXA",
+ "balance" : "9.07619790068559",
+ "currency" : "CNY",
+ "limit" : "100",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "balance" : "7.292695098901099",
+ "currency" : "JPY",
+ "limit" : "0",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
+ "balance" : "0",
+ "currency" : "AUX",
+ "limit" : "0",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "no_ripple_peer" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "r9vbV3EHvXWjSkeQ6CAcYVPGeq7TuiXY2X",
+ "balance" : "0.0004557360418801623",
+ "currency" : "USD",
+ "limit" : "1",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "balance" : "12.41688780720394",
+ "currency" : "EUR",
+ "limit" : "100",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rfF3PNkwkq1DygW2wum2HK3RGfgkJjdPVD",
+ "balance" : "35",
+ "currency" : "USD",
+ "limit" : "500",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rwUVoVMSURqNyvocPCcvLu3ygJzZyw8qwp",
+ "balance" : "-5",
+ "currency" : "JOE",
+ "limit" : "0",
+ "limit_peer" : "50",
+ "no_ripple_peer" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
+ "balance" : "0",
+ "currency" : "USD",
+ "limit" : "0",
+ "limit_peer" : "100",
+ "no_ripple_peer" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
+ "balance" : "0",
+ "currency" : "JOE",
+ "limit" : "0",
+ "limit_peer" : "100",
+ "no_ripple_peer" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rs9M85karFkCRjvc6KMWn8Coigm9cbcgcx",
+ "balance" : "0",
+ "currency" : "015841551A748AD2C1F76FF6ECB0CCCD00000000",
+ "limit" : "10.01037626125837",
+ "limit_peer" : "0",
+ "no_ripple" : true,
+ "quality_in" : 0,
+ "quality_out" : 0
+ },
+ {
+ "account" : "rEhDDUUNxpXgEHVJtC2cjXAgyx5VCFxdMF",
+ "balance" : "0",
+ "currency" : "USD",
+ "limit" : "0",
+ "limit_peer" : "1",
+ "quality_in" : 0,
+ "quality_out" : 0
+ }
+ ],
+ "status" : "success",
+ "validated" : false
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the address of the account and an array of trust line objects. Specifically, the result object contains the following fields:
@@ -176,12 +422,12 @@ Each trust line object has some combination of the following fields:
| `limit_peer` | String | The maximum amount of currency that the counterparty account is willing to owe the perspective account |
| `quality_in` | Unsigned Integer | Rate at which the account values incoming balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
| `quality_out` | Unsigned Integer | Rate at which the account values outgoing balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
-| `no_ripple` | Boolean | (May be omitted) `true` if this account has enabled the [NoRipple flag](rippling.html) for this line. If omitted, that is the same as `false`. |
-| `no_ripple_peer` | Boolean | (May be omitted) `true` if the peer account has enabled the [NoRipple flag](rippling.html). If omitted, that is the same as `false`. |
-| `authorized` | Boolean | (May be omitted) `true` if this account has [authorized this trust line](authorized-trust-lines.html). If omitted, that is the same as `false`. |
-| `peer_authorized`| Boolean | (May be omitted) `true` if the peer account has [authorized this trust line](authorized-trust-lines.html). If omitted, that is the same as `false`. |
-| `freeze` | Boolean | (May be omitted) `true` if this account has [frozen](freezes.html) this trust line. If omitted, that is the same as `false`. |
-| `freeze_peer` | Boolean | (May be omitted) `true` if the peer account has [frozen](freezes.html) this trust line. If omitted, that is the same as `false`. |
+| `no_ripple` | Boolean | _(May be omitted)_ `true` if this account has enabled the [No Ripple flag](rippling.html) for this line. If omitted, that is the same as `false`. |
+| `no_ripple_peer` | Boolean | _(May be omitted)_ `true` if the peer account has enabled the [No Ripple flag](rippling.html). If omitted, that is the same as `false`. |
+| `authorized` | Boolean | _(May be omitted)_ `true` if this account has [authorized this trust line](authorized-trust-lines.html). If omitted, that is the same as `false`. |
+| `peer_authorized`| Boolean | _(May be omitted)_ `true` if the peer account has [authorized this trust line](authorized-trust-lines.html). If omitted, that is the same as `false`. |
+| `freeze` | Boolean | _(May be omitted)_ `true` if this account has [frozen](freezes.html) this trust line. If omitted, that is the same as `false`. |
+| `freeze_peer` | Boolean | _(May be omitted)_ `true` if the peer account has [frozen](freezes.html) this trust line. If omitted, that is the same as `false`. |
## Possible Errors
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
index 168e0966c9..181d681f3d 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md
@@ -598,6 +598,598 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "account_objects" : [
+ {
+ "Balance" : {
+ "currency" : "ASP",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 65536,
+ "HighLimit" : {
+ "currency" : "ASP",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "ASP",
+ "issuer" : "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
+ "value" : "10"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "BF7555B0F018E3C5E2A3FF9437A1A5092F32903BE246202F988181B9CED0D862",
+ "PreviousTxnLgrSeq" : 1438879,
+ "index" : "2243B0B630EA6F7330B654EFA53E27A7609D9484E535AB11B7F946DF3D247CE9"
+ },
+ {
+ "Balance" : {
+ "currency" : "XAU",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 3342336,
+ "HighLimit" : {
+ "currency" : "XAU",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "XAU",
+ "issuer" : "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "79B26D7D34B950AC2C2F91A299A6888FABB376DD76CFF79D56E805BF439F6942",
+ "PreviousTxnLgrSeq" : 5982530,
+ "index" : "9ED4406351B7A511A012A9B5E7FE4059FA2F7650621379C0013492C315E25B97"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "5"
+ },
+ "Flags" : 1114112,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "5"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "2A5C5D95880A254A2C57BB5332558205BC33B9F2B38D359A170283CB4CBD080A",
+ "PreviousTxnLgrSeq" : 39498567,
+ "index" : "2DECFAC23B77D5AEA6116C15F5C6D4669EBAEE9E7EE050A40FE2B1E47B6A9419"
+ },
+ {
+ "Balance" : {
+ "currency" : "MXN",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "481.992867407479"
+ },
+ "Flags" : 65536,
+ "HighLimit" : {
+ "currency" : "MXN",
+ "issuer" : "rHpXfibHgSb64n8kK9QWDpdbfqSpYbM9a4",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "MXN",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "1000"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "A467BACE5F183CDE1F075F72435FE86BAD8626ED1048EDEFF7562A4CC76FD1C5",
+ "PreviousTxnLgrSeq" : 3316170,
+ "index" : "EC8B9B6B364AF6CB6393A423FDD2DDBA96375EC772E6B50A3581E53BFBDFDD9A"
+ },
+ {
+ "Balance" : {
+ "currency" : "EUR",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0.793598266778297"
+ },
+ "Flags" : 1114112,
+ "HighLimit" : {
+ "currency" : "EUR",
+ "issuer" : "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "EUR",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "1"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "E9345D44433EA368CFE1E00D84809C8E695C87FED18859248E13662D46A0EC46",
+ "PreviousTxnLgrSeq" : 5447146,
+ "index" : "4513749B30F4AF8DA11F077C448128D6486BF12854B760E4E5808714588AA915"
+ },
+ {
+ "Balance" : {
+ "currency" : "CNY",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "CNY",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "3"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "CNY",
+ "issuer" : "rnuF96W4SZoCJmbHYBFoJZpR8eCaxNvekK",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000008",
+ "PreviousTxnID" : "2FDDC81F4394695B01A47913BEC4281AC9A283CC8F903C14ADEA970F60E57FCF",
+ "PreviousTxnLgrSeq" : 5949673,
+ "index" : "578C327DA8944BDE2E10C9BA36AFA2F43E06C8D1E8819FB225D266CBBCFDE5CE"
+ },
+ {
+ "Balance" : {
+ "currency" : "DYM",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "1.336889190631542"
+ },
+ "Flags" : 65536,
+ "HighLimit" : {
+ "currency" : "DYM",
+ "issuer" : "rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "DYM",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "3"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "6DA2BD02DFB83FA4DAFC2651860B60071156171E9C021D9E0372A61A477FFBB1",
+ "PreviousTxnLgrSeq" : 8818732,
+ "index" : "5A2A5FF12E71AEE57564E624117BBA68DEF78CD564EF6259F92A011693E027C7"
+ },
+ {
+ "Balance" : {
+ "currency" : "CHF",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-0.3488146605801446"
+ },
+ "Flags" : 131072,
+ "HighLimit" : {
+ "currency" : "CHF",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "CHF",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0"
+ },
+ "LowNode" : "000000000000008C",
+ "PreviousTxnID" : "722394372525A13D1EAAB005642F50F05A93CF63F7F472E0F91CDD6D38EB5869",
+ "PreviousTxnLgrSeq" : 2687590,
+ "index" : "F2DBAD20072527F6AD02CE7F5A450DBC72BE2ABB91741A8A3ADD30D5AD7A99FB"
+ },
+ {
+ "Balance" : {
+ "currency" : "BTC",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 131072,
+ "HighLimit" : {
+ "currency" : "BTC",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "3"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "BTC",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000043",
+ "PreviousTxnID" : "03EDF724397D2DEE70E49D512AECD619E9EA536BE6CFD48ED167AE2596055C9A",
+ "PreviousTxnLgrSeq" : 8317037,
+ "index" : "767C12AF647CDF5FEB9019B37018748A79C50EDAF87E8D4C7F39F78AA7CA9765"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-11.68225001668339"
+ },
+ "Flags" : 131072,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "5000"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0"
+ },
+ "LowNode" : "000000000000004A",
+ "PreviousTxnID" : "8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B",
+ "PreviousTxnLgrSeq" : 43251698,
+ "index" : "826CF5BFD28F3934B518D0BDF3231259CBD3FD0946E3C3CA0C97D2C75D2D1A09"
+ },
+ {
+ "Balance" : {
+ "currency" : "BTC",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0.00111"
+ },
+ "Flags" : 65536,
+ "HighLimit" : {
+ "currency" : "BTC",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "BTC",
+ "issuer" : "rpgKWEmNqSDAGFhy5WDnsyPqfQxbWxKeVd",
+ "value" : "10"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "74F2F2A731C1350492FA03F8C67AF6C05EEC391160AACC04BF99329D9EAB0052",
+ "PreviousTxnLgrSeq" : 585437,
+ "index" : "94A9F05FEF9A153229E2E997E64919FD75AAE2028C8153E8EBDB4440BD3ECBB5"
+ },
+ {
+ "Balance" : {
+ "currency" : "BTC",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-0.0008744482690504699"
+ },
+ "Flags" : 131072,
+ "HighLimit" : {
+ "currency" : "BTC",
+ "issuer" : "rBJ3YjwXi2MGbg7GVLuTXUWQ8DjL7tDXh4",
+ "value" : "10"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "BTC",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "95221CD154317176B5748202A2E820D7A336597816E9787C27E3E4F25576877F",
+ "PreviousTxnLgrSeq" : 8208104,
+ "index" : "BC2AC65D7F9AD5CDAD131DEFE248727CA8A0FC219A33A3264E6202F50B4733C0"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 65536,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000002",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "1"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B",
+ "PreviousTxnLgrSeq" : 43251698,
+ "index" : "C493ABA2619D0FC6355BA862BC8312DF8266FBE76AFBA9636E857F7EAC874A99"
+ },
+ {
+ "Balance" : {
+ "currency" : "CNY",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-9.07619790068559"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "CNY",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "100"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "CNY",
+ "issuer" : "razqQKzJRdB4UxFPWf5NEpEG3WMkmwgcXA",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000005",
+ "PreviousTxnID" : "8EFE067DA1B2D57C485EFFCF875604548BA990EA00D019B466313D4CEE1E4668",
+ "PreviousTxnLgrSeq" : 8284705,
+ "index" : "C8554E6CE903505F631703E73D22D2D4D0662FDA9F524290997DF6B4D760C495"
+ },
+ {
+ "Balance" : {
+ "currency" : "JPY",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-7.292695098901099"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "JPY",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "JPY",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000076",
+ "PreviousTxnID" : "CE460D85F9AD93752E8EC8BCF4DFFE91DDF08B8C988836D64CB51EB7B447F672",
+ "PreviousTxnLgrSeq" : 5100078,
+ "index" : "CB1565898F19916A5EE49CC537B1D43CA075B9B96E82C6892E16EF6DFDEE7865"
+ },
+ {
+ "Balance" : {
+ "currency" : "AUX",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 3342336,
+ "HighLimit" : {
+ "currency" : "AUX",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "AUX",
+ "issuer" : "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "A6964735A14272742E7E10EB5AB5A7CE693473BBB4DAFA488971A15E181132CF",
+ "PreviousTxnLgrSeq" : 5982528,
+ "index" : "C61E113C767A9E7B27CD944162FB63EAA24C38C8664E984759821C3ADFFE097E"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0.0004557360418801623"
+ },
+ "Flags" : 1114112,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9vbV3EHvXWjSkeQ6CAcYVPGeq7TuiXY2X",
+ "value" : "0"
+ },
+ "HighNode" : "0000000000000003",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "1"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "F8F178712C0C3DA013A774A598B2A004BE6BA3D4542B8448D221A60D8A0D409A",
+ "PreviousTxnLgrSeq" : 38837233,
+ "index" : "D43180D7B2EEBB285C9D296590C4D5E5580C814F3026FC4D41FFDF3049FB547F"
+ },
+ {
+ "Balance" : {
+ "currency" : "EUR",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-12.41688780720394"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "EUR",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "100"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "EUR",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0"
+ },
+ "LowNode" : "000000000000008F",
+ "PreviousTxnID" : "1F0436C0688A8156EE2D7745B02C3F39C477A43F6BAD5D46C25A08949EF41739",
+ "PreviousTxnLgrSeq" : 5449071,
+ "index" : "F6B22B4D6A83B13A7F16E6A4A6EA8D3E26739C9D86C23DAC21C18E74B5E2C8CC"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-35"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "500"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "rfF3PNkwkq1DygW2wum2HK3RGfgkJjdPVD",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "99CB3C30FAEC301621951B944059C3C2EB78FDE7ED2E124A79901B6F2600E868",
+ "PreviousTxnLgrSeq" : 4339260,
+ "index" : "D23CF25053AC6A5106E9162A20AF52818EDC672CA77AD1625C0407A71D37102F"
+ },
+ {
+ "Balance" : {
+ "currency" : "JOE",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "-5"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "JOE",
+ "issuer" : "rwUVoVMSURqNyvocPCcvLu3ygJzZyw8qwp",
+ "value" : "50"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "JOE",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "F5B48F7631779C6562AF07DC79E0E4E25A0696C38823417BF811DF27C5D88168",
+ "PreviousTxnLgrSeq" : 5736288,
+ "index" : "FEECE8973F75156412E1604C52B8B9C6BC9EF21FA4A0FAA8B779AC416D039B34"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
+ "value" : "100"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "B1A7405C4A698E6A371E5B02836E779A942936AB754865FE82141E5280F09D1B",
+ "PreviousTxnLgrSeq" : 5718137,
+ "index" : "8DF1456AAB7470A760F6A095C156B457FF1038D43E6B11FD8011C2DF714E4FA1"
+ },
+ {
+ "Balance" : {
+ "currency" : "JOE",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "JOE",
+ "issuer" : "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
+ "value" : "100"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "JOE",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "8E488B0E939D4DACD62102A5BFA2FDC63679EFCC56F2FDA2FDF45283674BB711",
+ "PreviousTxnLgrSeq" : 5989200,
+ "index" : "273BD42DD72E7D84416ED759CEC92DACCD12A4502287E50BECF816233C021ED1"
+ },
+ {
+ "Balance" : {
+ "currency" : "015841551A748AD2C1F76FF6ECB0CCCD00000000",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 2228224,
+ "HighLimit" : {
+ "currency" : "015841551A748AD2C1F76FF6ECB0CCCD00000000",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "10.01037626125837"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "015841551A748AD2C1F76FF6ECB0CCCD00000000",
+ "issuer" : "rs9M85karFkCRjvc6KMWn8Coigm9cbcgcx",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "2B3E313FBDE15988425AACA1EA2EAEBBBCB8020E4FBAA7159BA678E1C4F6B4C3",
+ "PreviousTxnLgrSeq" : 5982458,
+ "index" : "BA92A0B9EB8A75E84C5463BA1A055F2B1C1B7CC20BFDA7B027C685F75E06629D"
+ },
+ {
+ "Balance" : {
+ "currency" : "USD",
+ "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji",
+ "value" : "0"
+ },
+ "Flags" : 131072,
+ "HighLimit" : {
+ "currency" : "USD",
+ "issuer" : "rEhDDUUNxpXgEHVJtC2cjXAgyx5VCFxdMF",
+ "value" : "1"
+ },
+ "HighNode" : "0000000000000000",
+ "LedgerEntryType" : "RippleState",
+ "LowLimit" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0"
+ },
+ "LowNode" : "0000000000000000",
+ "PreviousTxnID" : "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
+ "PreviousTxnLgrSeq" : 6592159,
+ "index" : "2CC2B211F6D1159B5CFD07AF8717A9C51C985E2497B2875C192EE87266AB0F81"
+ }
+ ],
+ "ledger_hash" : "06BF4DBE7D57FBFEAFD70D4CA7B00ED6EF404B94C446767063A0EF58A937FC4E",
+ "ledger_index" : 56843766,
+ "status" : "success",
+ "validated" : true
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md
index 2ad9efd489..308fb452a3 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md
@@ -36,7 +36,7 @@ An example of the request format:
```sh
#Syntax: account_offers account [ledger_index] [strict]
-rippled account_offers r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 current strict
+rippled account_offers rpP2JgiMyTF5jR5hLG3xHCPi1knBb1v9cM current strict
```
@@ -152,6 +152,31 @@ An example of a successful response:
}
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "account" : "rpP2JgiMyTF5jR5hLG3xHCPi1knBb1v9cM",
+ "ledger_current_index" : 57110969,
+ "offers" : [
+ {
+ "flags" : 0,
+ "quality" : "1499850014.892974",
+ "seq" : 7916201,
+ "taker_gets" : {
+ "currency" : "BCH",
+ "issuer" : "rcyS4CeCZVYvTiKcxj6Sx32ibKwcDHLds",
+ "value" : "0.5268598580881351"
+ },
+ "taker_pays" : "790210766"
+ }
+ ],
+ "status" : "success",
+ "validated" : false
+ }
+}
+```
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_tx.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_tx.md
index 827867b247..77acf8b15a 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/account_tx.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_tx.md
@@ -15,7 +15,7 @@ An example of the request format:
{
"id": 2,
"command": "account_tx",
- "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
"ledger_index_min": -1,
"ledger_index_max": -1,
"binary": false,
@@ -31,7 +31,7 @@ An example of the request format:
"method": "account_tx",
"params": [
{
- "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
"binary": false,
"forward": false,
"ledger_index_max": -1,
@@ -47,7 +47,7 @@ An example of the request format:
```
# Syntax: account_tx account [ledger_index_min [ledger_index_max]] [limit] [offset] [binary] [count] [descending]
# For binary/count/descending, use the parameter name for true and omit for false.
-rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 0 binary descending
+rippled -- account_tx rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w -1 -1 2 0 binary descending
```
@@ -88,16 +88,169 @@ An example of a successful response:
*WebSocket*
-```
+```json
+{
+ "id": 2,
+ "result": {
+ "account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "ledger_index_max": 57111999,
+ "ledger_index_min": 55886305,
+ "limit": 2,
+ "marker": {
+ "ledger": 57111981,
+ "seq": 16
+ },
+ "transactions": [
+ {
+ "meta": {
+ "AffectedNodes": [
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "Balance": "3732969177079",
+ "Flags": 131072,
+ "OwnerCount": 0,
+ "Sequence": 702817
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
+ "PreviousFields": {
+ "Balance": "3713891690008"
+ },
+ "PreviousTxnID": "D58864C16344ADCC15995C7986CFC607CB693E88F84D2E019F0A35FB29749202",
+ "PreviousTxnLgrSeq": 57111994
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
+ "Balance": "40010160",
+ "Flags": 131072,
+ "OwnerCount": 0,
+ "Sequence": 466334
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9",
+ "PreviousFields": {
+ "Balance": "19117497271",
+ "Sequence": 466333
+ },
+ "PreviousTxnID": "F6B8274D3D419A95A59681E5F55578084C395FF9051924360CA3EA745F5581E8",
+ "PreviousTxnLgrSeq": 57111993
+ }
+ }
+ ],
+ "TransactionIndex": 25,
+ "TransactionResult": "tesSUCCESS",
+ "delivered_amount": "19077487071"
+ },
+ "tx": {
+ "Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
+ "Amount": "19077487071",
+ "Destination": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "DestinationTag": 1,
+ "Fee": "40",
+ "Flags": 2147483648,
+ "LastLedgerSequence": 57112020,
+ "Sequence": 466333,
+ "SigningPubKey": "0381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A01",
+ "TransactionType": "Payment",
+ "TxnSignature": "3045022100CFC5FD057C7C685C690637AD1E639E2642BBC00EFD8E06E3F6C72FA924BC99D40220317D0708E814F69F874D641B6732E37A53B1220B493B2B8390D9EF51E8062515",
+ "date": 649200260,
+ "hash": "46BF0B576677B0DEA2D94591424A57A2DE8E3D89383631E16F40D09A513C656C",
+ "inLedger": 57111998,
+ "ledger_index": 57111998
+ },
+ "validated": true
+ },
+ {
+ "meta": {
+ "AffectedNodes": [
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "Balance": "3713891690008",
+ "Flags": 131072,
+ "OwnerCount": 0,
+ "Sequence": 702817
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
+ "PreviousFields": {
+ "Balance": "3714441690048",
+ "Sequence": 702816
+ },
+ "PreviousTxnID": "FDD5007913B39027BAF10B31144DBC1F7DC147528DF31FF048A06DC5D3108BD6",
+ "PreviousTxnLgrSeq": 57111981
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Account": "r9dU6Z7P2i7MrDi1VUZ7uyq6J77eg86YtB",
+ "Balance": "2629998983",
+ "Flags": 0,
+ "OwnerCount": 0,
+ "Sequence": 10
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "27B96FE681B33825CC95DA197358B30D3A1721F2125F2D76022D46B2418ABA0A",
+ "PreviousFields": {
+ "Balance": "2079998983"
+ },
+ "PreviousTxnID": "44A47AC04C0C7237C32BE9A532B578D07641705D3A59DB9B3C5B6225001E39B7",
+ "PreviousTxnLgrSeq": 56613857
+ }
+ }
+ ],
+ "TransactionIndex": 16,
+ "TransactionResult": "tesSUCCESS",
+ "delivered_amount": "550000000"
+ },
+ "tx": {
+ "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "Amount": "550000000",
+ "Destination": "r9dU6Z7P2i7MrDi1VUZ7uyq6J77eg86YtB",
+ "Fee": "40",
+ "Flags": 2147483648,
+ "LastLedgerSequence": 57112016,
+ "Sequence": 702816,
+ "SigningPubKey": "020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A",
+ "TransactionType": "Payment",
+ "TxnSignature": "3045022100D589029EF63F9E528F6100C7A36D26AFFF84085EC9AC16DA8E30E11F390D4E87022011466E0FE4A90B89142EE47E535545EEA4A2D65E0BD234DFB447721218B59C9B",
+ "date": 649200241,
+ "hash": "D58864C16344ADCC15995C7986CFC607CB693E88F84D2E019F0A35FB29749202",
+ "inLedger": 57111994,
+ "ledger_index": 57111994
+ },
+ "validated": true
+ }
+ ],
+ "validated": true
+ },
+ "status": "success",
+ "type": "response"
+}
+```
+
+*JSON-RPC*
+
+```json
+200 OK
{
- "id": 2,
- "status": "success",
- "type": "response",
"result": {
- "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "ledger_index_max": 6542489,
- "ledger_index_min": 32570,
+ "account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "ledger_index_max": 57112019,
+ "ledger_index_min": 56248229,
"limit": 2,
+ "marker": {
+ "ledger": 57112007,
+ "seq": 13
+ },
+ "status": "success",
"transactions": [
{
"meta": {
@@ -105,109 +258,61 @@ An example of a successful response:
{
"ModifiedNode": {
"FinalFields": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Balance": "9999999980",
- "Flags": 0,
- "OwnerCount": 2,
- "Sequence": 3
- },
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
- "PreviousFields": {
- "Balance": "9999999990",
- "OwnerCount": 1,
- "Sequence": 2
- },
- "PreviousTxnID": "389720F6FD8A144F171708F9ECB334D704CBCFEFBCDA152D931AC34FB5F9E32B",
- "PreviousTxnLgrSeq": 95405
- }
- },
- {
- "CreatedNode": {
- "LedgerEntryType": "RippleState",
- "LedgerIndex": "718C6D58DD3BBAAAEBFE48B8FBE3C32C9F6F2EBC395233BA95D0057078EE07DB",
- "NewFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "0"
- },
+ "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "Balance": "3732290013101",
"Flags": 131072,
- "HighLimit": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "100"
- },
- "LowLimit": {
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "value": "0"
- }
- }
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "Flags": 0,
- "Owner": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "RootIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
- },
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "Account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "Balance": "78991384535796",
- "Flags": 0,
- "OwnerCount": 3,
- "Sequence": 188
+ "OwnerCount": 0,
+ "Sequence": 702820
},
"LedgerEntryType": "AccountRoot",
- "LedgerIndex": "B33FDD5CF3445E1A7F2BE9B06336BEBD73A5E3EE885D3EF93F7E3E2992E46F1A",
- "PreviousTxnID": "E9E1988A0F061679E5D14DE77DB0163CE0BBDC00F29E396FFD1DA0366E7D8904",
- "PreviousTxnLgrSeq": 195455
+ "LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
+ "PreviousFields": {
+ "Balance": "3732745656171",
+ "Sequence": 702819
+ },
+ "PreviousTxnID": "7C031FD5B710E3C048EEF31254089BEEC505900BCC9A842257A0319453333998",
+ "PreviousTxnLgrSeq": 57112010
}
},
{
"ModifiedNode": {
"FinalFields": {
- "ExchangeRate": "4E11C37937E08000",
+ "Account": "raLPjTYeGezfdb6crXZzcC8RkLBEwbBHJ5",
+ "Balance": "4231510602153",
"Flags": 0,
- "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
- "TakerGetsCurrency": "0000000000000000000000000000000000000000",
- "TakerGetsIssuer": "0000000000000000000000000000000000000000",
- "TakerPaysCurrency": "0000000000000000000000004254430000000000",
- "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
+ "OwnerCount": 0,
+ "Sequence": 96486
},
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "39DC5D448DECEFC3CD20818788E3DA891CA943935E8D7B12FCB5B5871FCB1638",
+ "PreviousFields": {
+ "Balance": "4231054959123"
+ },
+ "PreviousTxnID": "33D2014C832610293730028CA37857AC183BFCE3E42B9979C491FB8B82B3E9DC",
+ "PreviousTxnLgrSeq": 57112004
}
}
],
- "TransactionIndex": 0,
- "TransactionResult": "tesSUCCESS"
+ "TransactionIndex": 12,
+ "TransactionResult": "tesSUCCESS",
+ "delivered_amount": "455643030"
},
"tx": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Fee": "10",
- "Flags": 0,
- "LimitAmount": {
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "value": "100"
- },
- "Sequence": 2,
- "SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
- "TransactionType": "TrustSet",
- "TxnSignature": "304402200EF81EC32E0DFA9BE376B20AFCA11765ED9FEA04CA8B77C7178DAA699F7F5AFF02202DA484DBD66521AC317D84F7717EC4614E2F5DB743E313E8B48440499CC0DBA4",
- "date": 413620090,
- "hash": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
- "inLedger": 195480,
- "ledger_index": 195480
+ "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "Amount": "455643030",
+ "Destination": "raLPjTYeGezfdb6crXZzcC8RkLBEwbBHJ5",
+ "DestinationTag": 18240312,
+ "Fee": "40",
+ "Flags": 2147483648,
+ "LastLedgerSequence": 57112037,
+ "Sequence": 702819,
+ "SigningPubKey": "020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A",
+ "TransactionType": "Payment",
+ "TxnSignature": "30450221008602B2E390C0C7B65182C6DBC86292052C1961B2BEFB79C2C8431722C0ADB911022024B74DCF910A4C8C95572CF662EB7F5FF67E1AC4D7B9B7BFE2A8EE851EC16576",
+ "date": 649200322,
+ "hash": "08EF5BDA2825D7A28099219621CDBECCDECB828FEA202DEB6C7ACD5222D36C2C",
+ "inLedger": 57112015,
+ "ledger_index": 57112015
},
"validated": true
},
@@ -217,102 +322,61 @@ An example of a successful response:
{
"ModifiedNode": {
"FinalFields": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Balance": "9999999970",
- "Flags": 0,
- "OwnerCount": 3,
- "Sequence": 4
- },
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
- "PreviousFields": {
- "Balance": "9999999980",
- "OwnerCount": 2,
- "Sequence": 3
- },
- "PreviousTxnID": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
- "PreviousTxnLgrSeq": 195480
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "Flags": 0,
- "Owner": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "RootIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
- },
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
- }
- },
- {
- "ModifiedNode": {
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "E0D7BDE68B468FF0B8D948FD865576517DA987569833A05374ADB9A72E870A06",
- "PreviousTxnID": "0222B59280D165D40C464EA75AAD08A4D152C46A38C0625DEECF6EE87FC5B9E1",
- "PreviousTxnLgrSeq": 343555
- }
- },
- {
- "CreatedNode": {
- "LedgerEntryType": "RippleState",
- "LedgerIndex": "EA4BF03B4700123CDFFB6EB09DC1D6E28D5CEB7F680FB00FC24BC1C3BB2DB959",
- "NewFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "0"
- },
+ "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "Balance": "3732745656171",
"Flags": 131072,
- "HighLimit": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "100"
- },
- "LowLimit": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "0"
- }
- }
+ "OwnerCount": 0,
+ "Sequence": 702819
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574",
+ "PreviousFields": {
+ "Balance": "3732246155784"
+ },
+ "PreviousTxnID": "CCBCCB528F602007C937C496F0828C118E073DF180084CCD3646EC1E414844E4",
+ "PreviousTxnLgrSeq": 57112007
}
},
{
"ModifiedNode": {
"FinalFields": {
- "ExchangeRate": "4E11C37937E08000",
- "Flags": 0,
- "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
- "TakerGetsCurrency": "0000000000000000000000000000000000000000",
- "TakerGetsIssuer": "0000000000000000000000000000000000000000",
- "TakerPaysCurrency": "0000000000000000000000004254430000000000",
- "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
+ "Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
+ "Balance": "236476361",
+ "Flags": 131072,
+ "OwnerCount": 0,
+ "Sequence": 466335
},
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9",
+ "PreviousFields": {
+ "Balance": "735976788",
+ "Sequence": 466334
+ },
+ "PreviousTxnID": "C528B32DD588EFAE2FE833E8AA92E6AE2DF2C8DB3DB8C6C4F334AD37B253D72A",
+ "PreviousTxnLgrSeq": 57112010
}
}
],
- "TransactionIndex": 0,
- "TransactionResult": "tesSUCCESS"
+ "TransactionIndex": 33,
+ "TransactionResult": "tesSUCCESS",
+ "delivered_amount": "499500387"
},
"tx": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Fee": "10",
- "Flags": 0,
- "LimitAmount": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "100"
- },
- "Sequence": 3,
- "SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
- "TransactionType": "TrustSet",
- "TxnSignature": "3044022058A89552068D1A274EE72BA71363E33E54E6608BC28A84DEC6EE530FC2B5C979022029F4D1EA1237A1F717C5F5EC526E6CFB6DF54C30BADD25EDDE7D2FDBC8F17E34",
- "date": 416347560,
- "hash": "53354D84BAE8FDFC3F4DA879D984D24B929E7FEB9100D2AD9EFCD2E126BCCDC8",
- "inLedger": 343570,
- "ledger_index": 343570
+ "Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg",
+ "Amount": "499500387",
+ "Destination": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "DestinationTag": 1,
+ "Fee": "40",
+ "Flags": 2147483648,
+ "LastLedgerSequence": 57112032,
+ "Sequence": 466334,
+ "SigningPubKey": "0381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A01",
+ "TransactionType": "Payment",
+ "TxnSignature": "3045022100C7EA1701FE48C75508EEBADBC9864CD3FFEDCEB48AB99AEA960BFA360AE163ED0220453C9577502924C9E1A9A450D4B950A44016813BC70E1F16A65A402528D730B7",
+ "date": 649200302,
+ "hash": "7C031FD5B710E3C048EEF31254089BEEC505900BCC9A842257A0319453333998",
+ "inLedger": 57112010,
+ "ledger_index": 57112010
},
"validated": true
}
@@ -322,238 +386,36 @@ An example of a successful response:
}
```
-*JSON-RPC*
+*Commandline*
-```
-200 OK
+```json
{
- "result": {
- "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "ledger_index_max": 8696227,
- "ledger_index_min": 32570,
- "limit": 2,
- "status": "success",
- "transactions": [
- {
- "meta": {
- "AffectedNodes": [
- {
- "ModifiedNode": {
- "FinalFields": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Balance": "9999999980",
- "Flags": 0,
- "OwnerCount": 2,
- "Sequence": 3
- },
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
- "PreviousFields": {
- "Balance": "9999999990",
- "OwnerCount": 1,
- "Sequence": 2
- },
- "PreviousTxnID": "389720F6FD8A144F171708F9ECB334D704CBCFEFBCDA152D931AC34FB5F9E32B",
- "PreviousTxnLgrSeq": 95405
- }
- },
- {
- "CreatedNode": {
- "LedgerEntryType": "RippleState",
- "LedgerIndex": "718C6D58DD3BBAAAEBFE48B8FBE3C32C9F6F2EBC395233BA95D0057078EE07DB",
- "NewFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "0"
- },
- "Flags": 131072,
- "HighLimit": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "100"
- },
- "LowLimit": {
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "value": "0"
- }
- }
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "Flags": 0,
- "Owner": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "RootIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
- },
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "77F65EFF930ED7E93C6CC839C421E394D6B1B6A47CEA8A140D63EC9C712F46F5"
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "Account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "Balance": "78991384535796",
- "Flags": 0,
- "OwnerCount": 3,
- "Sequence": 188
- },
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "B33FDD5CF3445E1A7F2BE9B06336BEBD73A5E3EE885D3EF93F7E3E2992E46F1A",
- "PreviousTxnID": "E9E1988A0F061679E5D14DE77DB0163CE0BBDC00F29E396FFD1DA0366E7D8904",
- "PreviousTxnLgrSeq": 195455
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "ExchangeRate": "4E11C37937E08000",
- "Flags": 0,
- "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
- "TakerGetsCurrency": "0000000000000000000000000000000000000000",
- "TakerGetsIssuer": "0000000000000000000000000000000000000000",
- "TakerPaysCurrency": "0000000000000000000000004254430000000000",
- "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
- },
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
- }
- }
- ],
- "TransactionIndex": 0,
- "TransactionResult": "tesSUCCESS"
- },
- "tx": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Fee": "10",
- "Flags": 0,
- "LimitAmount": {
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "value": "100"
- },
- "Sequence": 2,
- "SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
- "TransactionType": "TrustSet",
- "TxnSignature": "304402200EF81EC32E0DFA9BE376B20AFCA11765ED9FEA04CA8B77C7178DAA699F7F5AFF02202DA484DBD66521AC317D84F7717EC4614E2F5DB743E313E8B48440499CC0DBA4",
- "date": 413620090,
- "hash": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
- "inLedger": 195480,
- "ledger_index": 195480
- },
- "validated": true
- },
- {
- "meta": {
- "AffectedNodes": [
- {
- "ModifiedNode": {
- "FinalFields": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Balance": "9999999970",
- "Flags": 0,
- "OwnerCount": 3,
- "Sequence": 4
- },
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
- "PreviousFields": {
- "Balance": "9999999980",
- "OwnerCount": 2,
- "Sequence": 3
- },
- "PreviousTxnID": "002AA492496A1543DBD3680BF8CF21B6D6A078CE4A01D2C1A4B63778033792CE",
- "PreviousTxnLgrSeq": 195480
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "Flags": 0,
- "Owner": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "RootIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
- },
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "A39F044D860C5B5846AA7E0FAAD44DC8897F0A62B2F628AA073B21B3EC146010"
- }
- },
- {
- "ModifiedNode": {
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "E0D7BDE68B468FF0B8D948FD865576517DA987569833A05374ADB9A72E870A06",
- "PreviousTxnID": "0222B59280D165D40C464EA75AAD08A4D152C46A38C0625DEECF6EE87FC5B9E1",
- "PreviousTxnLgrSeq": 343555
- }
- },
- {
- "CreatedNode": {
- "LedgerEntryType": "RippleState",
- "LedgerIndex": "EA4BF03B4700123CDFFB6EB09DC1D6E28D5CEB7F680FB00FC24BC1C3BB2DB959",
- "NewFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "0"
- },
- "Flags": 131072,
- "HighLimit": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "100"
- },
- "LowLimit": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "0"
- }
- }
- }
- },
- {
- "ModifiedNode": {
- "FinalFields": {
- "ExchangeRate": "4E11C37937E08000",
- "Flags": 0,
- "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
- "TakerGetsCurrency": "0000000000000000000000000000000000000000",
- "TakerGetsIssuer": "0000000000000000000000000000000000000000",
- "TakerPaysCurrency": "0000000000000000000000004254430000000000",
- "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
- },
- "LedgerEntryType": "DirectoryNode",
- "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93"
- }
- }
- ],
- "TransactionIndex": 0,
- "TransactionResult": "tesSUCCESS"
- },
- "tx": {
- "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Fee": "10",
- "Flags": 0,
- "LimitAmount": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "100"
- },
- "Sequence": 3,
- "SigningPubKey": "02BC8C02199949B15C005B997E7C8594574E9B02BA2D0628902E0532989976CF9D",
- "TransactionType": "TrustSet",
- "TxnSignature": "3044022058A89552068D1A274EE72BA71363E33E54E6608BC28A84DEC6EE530FC2B5C979022029F4D1EA1237A1F717C5F5EC526E6CFB6DF54C30BADD25EDDE7D2FDBC8F17E34",
- "date": 416347560,
- "hash": "53354D84BAE8FDFC3F4DA879D984D24B929E7FEB9100D2AD9EFCD2E126BCCDC8",
- "inLedger": 343570,
- "ledger_index": 343570
- },
- "validated": true
- }
- ],
- "validated": true
- }
+ "result" : {
+ "account" : "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w",
+ "ledger_index_max" : 57112094,
+ "ledger_index_min" : 57105464,
+ "limit" : 2,
+ "marker" : {
+ "ledger" : 57112074,
+ "seq" : 9
+ },
+ "status" : "success",
+ "transactions" : [
+ {
+ "ledger_index" : 57112090,
+ "meta" : "201C0000002EF8E51100612503677617551E0297F38EF4FED7004E074D246B4EA3E550D9AE0F61BE40E08D3432091D52CE56140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574E624000AB96E624000037771BFD270E1E7220002000024000AB96F2D0000000062400003776C784A418114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911E1E1E311006156F7D315E0E992B1F1AC66B309C9D68961AA327FE770101B74D4C975F8C5DEC96AE8240367761A624000000005478807811403C95DC0C7CE402E8044A5F13304108013CE9963E1E1F1031000",
+ "tx_blob" : "120000228000000024000AB96E201B036776306140000000054788076840000000000000287321020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A74463044022054811EEF61ACCFA1B5FC6BB05D2FA49CF5174062740370328382E6EA557C0E6A0220480584D487638C333A87CA37100354BD36209E355E8DB9FE79791A56E24C1F268114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911831403C95DC0C7CE402E8044A5F13304108013CE9963",
+ "validated" : true
+ },
+ {
+ "ledger_index" : 57112087,
+ "meta" : "201C00000026F8E5110061250367760A556B80EE9A9AD3FC40F471F29DCB80C678375137CE36220718902EF1EDCD375E7156140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574E66240000376DEB77118E1E7220002000024000AB96E2D00000000624000037771BFD2708114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911E1E1E511006125036776155591DA498D40AFD90670555F3D719883B48D224B4E4E906C634DEFA21163E8197756CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9E62400071DA26240000001C0D849F8E1E722000200002400071DA32D0000000062400000012DCFE87881146914CB622B8E41E150DE431F48DA244A69809366E1E1F1031000",
+ "tx_blob" : "12000022800000002400071DA22E00000001201B0367762D61400000009308615868400000000000002873210381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A0174473045022100E592BCCFD85CCE0B39075EFC66D6BCA594EBB451F12AD5AD9EE533A267F1381B02203635AB46AC110848FC44E797BD19D77A19E10A0F463AA5540B1C62E5D48C81F081146914CB622B8E41E150DE431F48DA244A698093668314D2E44C9FAF7BE9C536219800A6E698E4C7D2C911",
+ "validated" : true
+ }
+ ],
+ "validated" : true
+ }
}
```
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md b/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md
index f0ddf11ed2..21a6d540e1 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md
@@ -6,6 +6,8 @@ The `gateway_balances` command calculates the total balances issued by a given a
## Request Format
An example of the request format:
+{% include '_snippets/no-cli-syntax.md' %}
+
*WebSocket*
@@ -40,6 +42,11 @@ An example of the request format:
}
```
+*Commandline*
+```
+rippled json gateway_balances ' {"account": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q", "hotwallet": ["rKm4uWpg9tfwbVSeATv4KxDe6mpE9yPkgJ", "ra7JkEzrgeKHdzKgo4EUUVBnxggY4z37kt"],"ledger_index": "validated","strict": true} '
+```
+
The request includes the following parameters:
@@ -193,9 +200,74 @@ An example of a successful response:
}
```
-
+*Commandline*
+```json
+{
+ "result" : {
+ "account" : "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
+ "assets" : {
+ "r9F6wk8HkXrgYWoJ7fsv4VrUBVoqDVtzkH" : [
+ {
+ "currency" : "BTC",
+ "value" : "5444166510000000e-26"
+ }
+ ],
+ "rPU6VbckqCLW4kb51CWqZdxvYyQrQVsnSj" : [
+ {
+ "currency" : "BTC",
+ "value" : "1029900000000000e-26"
+ }
+ ],
+ "rpR95n1iFkTqpoy1e878f4Z1pVHVtWKMNQ" : [
+ {
+ "currency" : "BTC",
+ "value" : "4000000000000000e-30"
+ }
+ ],
+ "rwmUaXsWtXU4Z843xSYwgt1is97bgY8yj6" : [
+ {
+ "currency" : "BTC",
+ "value" : "8700000000000000e-30"
+ }
+ ]
+ },
+ "balances" : {
+ "rKm4uWpg9tfwbVSeATv4KxDe6mpE9yPkgJ" : [
+ {
+ "currency" : "EUR",
+ "value" : "144816.1965999999"
+ }
+ ],
+ "ra7JkEzrgeKHdzKgo4EUUVBnxggY4z37kt" : [
+ {
+ "currency" : "USD",
+ "value" : "6677.38614"
+ }
+ ]
+ },
+ "frozen_balances" : {
+ "r4keXr5myiU4iTLh68ZqZ2CgsJ8dM9FSW6" : [
+ {
+ "currency" : "BTC",
+ "value" : "0.091207822800868"
+ }
+ ]
+ },
+ "ledger_hash" : "6C789EAF25A931565E5936042EED037F287F3348B61A70777649552E0385B0E4",
+ "ledger_index" : 57111383,
+ "obligations" : {
+ "BTC" : "1762.700511879441",
+ "EUR" : "813792.4267005104",
+ "GBP" : "4974.337212333351",
+ "USD" : "6739710.218284974"
+ },
+ "status" : "success",
+ "validated" : true
+ }
+}
+```
-**Note:** There is no command-line syntax for this method. Use the [json method][] to access this from the command line.
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md b/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md
index a09bef72b1..dbd5ac349b 100644
--- a/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md
+++ b/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md
@@ -1,16 +1,19 @@
# noripple_check
[[Source]](https://github.com/ripple/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/NoRippleCheck.cpp "Source")
-The `noripple_check` command provides a quick way to check the status of [the DefaultRipple field for an account and the NoRipple flag of its trust lines](rippling.html), compared with the recommended settings.
+The `noripple_check` command provides a quick way to check the status of [the Default Ripple field for an account and the No Ripple flag of its trust lines](rippling.html), compared with the recommended settings.
+
## Request Format
An example of the request format:
+{% include '_snippets/no-cli-syntax.md' %}
+
*WebSocket*
-```
+```json
{
"id": 0,
"command": "noripple_check",
@@ -24,7 +27,7 @@ An example of the request format:
*JSON-RPC*
-```
+```json
{
"method": "noripple_check",
"params": [
@@ -41,14 +44,13 @@ An example of the request format:
-**Note:** There is no command-line syntax for this method. Use the [json method][] to access this from the command line.
The request includes the following parameters:
| `Field` | Type | Description |
|:---------------|:---------------------------|:-------------------------------|
| `account` | String | A unique identifier for the account, most commonly the account's address. |
-| `role` | String | Whether the address refers to a `gateway` or `user`. Recommendations depend on the role of the account. Issuers must have DefaultRipple enabled and must disable NoRipple on all trust lines. Users should have DefaultRipple disabled, and should enable NoRipple on all trust lines. |
+| `role` | String | Whether the address refers to a `gateway` or `user`. Recommendations depend on the role of the account. Issuers must have Default Ripple enabled and must disable No Ripple on all trust lines. Users should have Default Ripple disabled, and should enable No Ripple on all trust lines. |
| `transactions` | Boolean | _(Optional)_ If `true`, include an array of suggested [transactions](transaction-formats.html), as JSON objects, that you can sign and submit to fix the problems. Defaults to false. |
| `limit` | Unsigned Integer | _(Optional)_ The maximum number of trust line problems to include in the results. Defaults to 300. |
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
@@ -62,7 +64,7 @@ An example of a successful response:
*WebSocket*
-```
+```json
{
"id": 0,
"status": "success",
@@ -114,8 +116,9 @@ An example of a successful response:
*JSON-RPC*
-```
+```json
200 OK
+
{
"result": {
"ledger_current_index": 14380381,
@@ -170,7 +173,7 @@ The response follows the [standard format][], with a successful result containin
| `Field` | Type | Description |
|:-----------------------|:-------|:-------------------------------------------|
| `ledger_current_index` | Number | The [ledger index][] of the ledger used to calculate these results. |
-| `problems` | Array | Array of strings with human-readable descriptions of the problems. This includes up to one entry if the account's DefaultRipple setting is not as recommended, plus up to `limit` entries for trust lines whose NoRipple setting is not as recommended. |
+| `problems` | Array | Array of strings with human-readable descriptions of the problems. This includes up to one entry if the account's Default Ripple setting is not as recommended, plus up to `limit` entries for trust lines whose No Ripple setting is not as recommended. |
| `transactions` | Array | (May be omitted) If the request specified `transactions` as `true`, this is an array of JSON objects, each of which is the JSON form of a [transaction](transaction-formats.html) that should fix one of the described problems. The length of this array is the same as the `problems` array, and each entry is intended to fix the problem described at the same index into that array. |
## Possible Errors
diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
index 065bfb72e0..a9dd374f3f 100644
--- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
+++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md
@@ -1,7 +1,7 @@
# ledger
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/LedgerHandler.cpp "Source")
-Retrieve information about the public ledger.
+Retrieve information about the public [ledger](ledgers.html).
## Request Format
An example of the request format:
@@ -185,7 +185,7 @@ The response follows the [standard format][], with a successful result containin
| `ledger` | Object | The complete header data of this ledger. |
| `ledger.account_hash` | String | Hash of all account state information in this ledger, as hex |
| `ledger.accountState` | Array | (Omitted unless requested) All the [account-state information](ledger-data-formats.html) in this ledger. |
-| `ledger.close_flags` | Integer | A bit-map of flags relating to the closing of this ledger. Currently, the ledger has only one flag defined for `close_flags`: **sLCF_NoConsensusTime** (value 1). If this flag is enabled, it means that validators were in conflict regarding the correct close time for the ledger, but build otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger contains a `close_time` that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.) |
+| `ledger.close_flags` | Integer | A bit-map of flags relating to the closing of this ledger. Currently, the ledger has only one flag defined for `close_flags`: **`sLCF_NoConsensusTime`** (value 1). If this flag is enabled, it means that validators were in conflict regarding the correct close time for the ledger, but build otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger contains a `close_time` that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.) |
| `ledger.close_time` | Integer | The time this ledger was closed, in [seconds since the Ripple Epoch][] |
| `ledger.close_time_human` | String | The time this ledger was closed, in human-readable format. Always uses the UTC time zone. [Updated in: rippled 1.5.0][] |
| `ledger.close_time_resolution` | Integer | Ledger close times are rounded to within this many seconds. |
diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_closed.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_closed.md
index c13fe32ec8..0a7106f851 100644
--- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_closed.md
+++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_closed.md
@@ -73,6 +73,18 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "ledger_hash" : "6F5D3B97F1CAA8440AFCED3CA10FB9DC6472F64DEBC2EFAE7CAE7FC0123F32DA",
+ "ledger_index" : 56843991,
+ "status" : "success"
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_current.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_current.md
index d23044e96c..f2e5572f46 100644
--- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_current.md
+++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_current.md
@@ -73,6 +73,17 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "ledger_current_index" : 56844050,
+ "status" : "success"
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following field:
diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md
index 6003619eba..f450d5b266 100644
--- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md
+++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md
@@ -6,6 +6,8 @@ The `ledger_data` method retrieves contents of the specified ledger. You can ite
## Request Format
An example of the request format:
+{% include '_snippets/no-cli-syntax.md' %}
+
*WebSocket*
@@ -37,7 +39,6 @@ An example of the request format:
-**Note:** There is no commandline syntax for `ledger_data`. You can use the [json method][] to access this method from the commandline instead.
A request can include the following fields:
@@ -97,7 +98,7 @@ An example of a successful response:
*WebSocket (binary:false)*
-```
+```json
{
"id": 2,
"result": {
@@ -245,9 +246,9 @@ The format of each object in the `state` array depends on whether `binary` was s
| `Field` | Type | Description |
|:--------------------|:----------|:-------------------------------------------|
-| `data` | String | (Only included if `"binary":true`) Hex representation of the requested data |
-| `LedgerEntryType` | String | (Only included if `"binary":false`) String indicating what type of ledger object this object represents. See [ledger data formats](ledger-data-formats.html) for the full list. |
-| (Additional fields) | (Various) | (Only included if `"binary":false`) Additional fields describing this object, depending on which LedgerEntryType it is. |
+| `data` | String | _(Only included if `"binary":true`)_ Hex representation of the requested data |
+| `LedgerEntryType` | String | _(Only included if `"binary":false`)_ String indicating what type of ledger object this object represents. See [ledger object types](ledger-object-types.html) for the full list. |
+| (Additional fields) | (Various) | _(Only included if `"binary":false`)_ Additional fields describing this object, depending on which [ledger object type](ledger-object-types.html) it is. |
| `index` | String | Unique identifier for this ledger entry, as hex. |
## Possible Errors
diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md
index 17ff28d244..a7aa04d72c 100644
--- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md
+++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md
@@ -3,12 +3,12 @@
The `ledger_entry` method returns a single ledger object from the XRP Ledger in its raw format. See [ledger format][] for information on the different types of objects you can retrieve.
-**Note:** There is no commandline version of this method. You can use the [json method][] to access this method from the commandline instead.
-
## Request Format
An example of the request format:
+{% include '_snippets/no-cli-syntax.md' %}
+
*WebSocket*
@@ -38,6 +38,12 @@ An example of the request format:
}
```
+*Commandline*
+
+```
+rippled json ledger_entry '{ "account_root": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", "ledger_index": "validated", "type": "account_root" }'
+```
+
[Try it! >](websocket-api-tool.html#ledger_entry)
@@ -94,7 +100,8 @@ An example of a successful response:
*WebSocket*
-```{
+```json
+{
"id": 3,
"result": {
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
@@ -118,7 +125,7 @@ An example of a successful response:
*JSON-RPC*
-```
+```json
200 OK
{
"result": {
@@ -141,6 +148,30 @@ An example of a successful response:
}
```
+*Commandline*
+```json
+{
+ "result" : {
+ "index" : "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
+ "ledger_hash" : "F434A8F21E401F84A2CDEDFDF801E6F3FC8B2567C6841818E684BEE019460179",
+ "ledger_index" : 56866309,
+ "node" : {
+ "Account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "Balance" : "13315612685",
+ "Flags" : 0,
+ "LedgerEntryType" : "AccountRoot",
+ "OwnerCount" : 17,
+ "PreviousTxnID" : "D2FA1C28EF87E53029327AA832C378674B3ACA0551CF9EA1F65BB8CA34913FAB",
+ "PreviousTxnLgrSeq" : 55180009,
+ "Sequence" : 1406,
+ "index" : "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
+ },
+ "status" : "success",
+ "validated" : true
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md
index 637f183787..7defa8b809 100644
--- a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md
+++ b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md
@@ -77,7 +77,7 @@ An example of a successful response:
*WebSocket*
-```
+```json
{
"id": 11,
"status": "success",
@@ -150,6 +150,78 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "ledger_current_index" : 56867201,
+ "offers" : [
+ {
+ "Account" : "rnixnrMHHvR7ejMpJMRCWkaNrq3qREwMDu",
+ "BookDirectory" : "7E5F614417C2D0A7CEFEB73C4AA773ED5B078DE2B5771F6D56038D7EA4C68000",
+ "BookNode" : "0000000000000000",
+ "Flags" : 131072,
+ "LedgerEntryType" : "Offer",
+ "OwnerNode" : "0000000000000000",
+ "PreviousTxnID" : "E43ADD1BD4AC2049E0D9DE6BC279B7FD95A99C8DE2C4694A4A7623F6D9AAAE29",
+ "PreviousTxnLgrSeq" : 47926685,
+ "Sequence" : 219,
+ "TakerGets" : {
+ "currency" : "EUR",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "2.459108753792364"
+ },
+ "TakerPays" : {
+ "currency" : "USD",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "24.59108753792364"
+ },
+ "index" : "3087B4828C6B5D8595EA325D69C0F396C57452893647799493A38F2C164990AB",
+ "owner_funds" : "2.872409153061363",
+ "quality" : "10"
+ },
+ {
+ "Account" : "rKwjWCKBaASEvtHCxtvReNd2i9n8DxSihk",
+ "BookDirectory" : "7E5F614417C2D0A7CEFEB73C4AA773ED5B078DE2B5771F6D56038D7EA4C68000",
+ "BookNode" : "0000000000000000",
+ "Flags" : 131072,
+ "LedgerEntryType" : "Offer",
+ "OwnerNode" : "0000000000000000",
+ "PreviousTxnID" : "B63B2ECD124FE6B02BC2998929517266BD221A02FEE51DDE4992C1BCB7E86CD3",
+ "PreviousTxnLgrSeq" : 43166305,
+ "Sequence" : 19,
+ "TakerGets" : {
+ "currency" : "EUR",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "3.52"
+ },
+ "TakerPays" : {
+ "currency" : "USD",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "35.2"
+ },
+ "index" : "89865F2C70D1140796D9D249AC2ED765AE2D007A52DEC6D6D64CCB1A77A6EB7F",
+ "owner_funds" : "3.523192614770459",
+ "quality" : "10",
+ "taker_gets_funded" : {
+ "currency" : "EUR",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "3.516160294182094"
+ },
+ "taker_pays_funded" : {
+ "currency" : "USD",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "35.16160294182094"
+ }
+ }
+ ],
+ "status" : "success",
+ "validated" : false
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
@@ -165,7 +237,7 @@ In addition to the standard Offer fields, the following fields may be included i
| `Field` | Type | Description |
|:--------------------|:---------------------------------|:--------------------|
-| `owner_funds` | String | Amount of the TakerGets currency the side placing the offer has available to be traded. (XRP is represented as drops; any other currency is represented as a decimal value.) If a trader has multiple offers in the same book, only the highest-ranked offer includes this field. |
+| `owner_funds` | String | Amount of the `TakerGets` currency the side placing the offer has available to be traded. (XRP is represented as drops; any other currency is represented as a decimal value.) If a trader has multiple offers in the same book, only the highest-ranked offer includes this field. |
| `taker_gets_funded` | String (XRP) or Object (non-XRP) | (Only included in partially-funded offers) The maximum amount of currency that the taker can get, given the funding status of the offer. |
| `taker_pays_funded` | String (XRP) or Object (non-XRP) | (Only included in partially-funded offers) The maximum amount of currency that the taker would pay, given the funding status of the offer. |
| `quality` | String | The exchange rate, as the ratio `taker_pays` divided by `taker_gets`. For fairness, offers that have the same quality are automatically taken first-in, first-out. (In other words, if multiple people offer to exchange currency at the same rate, the oldest offer is taken first.) |
diff --git a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md
index c2de39862b..a15a9282df 100644
--- a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md
+++ b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md
@@ -14,7 +14,7 @@ Although the `rippled` server tries to find the cheapest path or combination of
## path_find create
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp#L50-L56 "Source")
-The `create` subcommand of `path_find` creates an ongoing request to find possible paths along which a payment transaction could be made from one specified account such that another account receives a desired amount of some currency. The initial response contains a suggested path between the two addresses that would result in the desired amount being received. After that, the server sends additional messages, with `"type": "path_find"`, with updates to the potential paths. The frequency of updates is left to the discretion of the server, but it usually means once every few seconds when there is a new ledger version.
+The `create` sub-command of `path_find` creates an ongoing request to find possible paths along which a payment transaction could be made from one specified account such that another account receives a desired amount of some currency. The initial response contains a suggested path between the two addresses that would result in the desired amount being received. After that, the server sends additional messages, with `"type": "path_find"`, with updates to the potential paths. The frequency of updates is left to the discretion of the server, but it usually means once every few seconds when there is a new ledger version.
A client can only have one pathfinding request open at a time. If another pathfinding request is already open on the same connection, the old request is automatically closed and replaced with the new request.
@@ -48,7 +48,7 @@ The request includes the following parameters:
| `Field` | Type | Description |
|:----------------------|:-----------------|:----------------------------------|
-| `subcommand` | String | Use `"create"` to send the create subcommand |
+| `subcommand` | String | Use `"create"` to send the create sub-command |
| `source_account` | String | Unique address of the account to find a path from. (In other words, the account that would be sending a payment.) |
| `destination_account` | String | Unique address of the account to find a path to. (In other words, the account that would receive a payment.) |
| `destination_amount` | String or Object | [Currency Amount][] that the destination account would receive in a transaction. **Special case:** [New in: rippled 0.30.0][] You can specify `"-1"` (for XRP) or provide -1 as the contents of the `value` field (for non-XRP currencies). This requests a path to deliver as much as possible, while spending no more than the amount specified in `send_max` (if provided). |
@@ -463,7 +463,7 @@ In addition to the initial response, the server sends more messages in a similar
If the follow-up includes `"full_reply": true`, then this is the best path that rippled can find as of the current ledger.
-Here is an example of an asychronous follow-up from a path_find create request:
+Here is an example of an asynchronous follow-up from a path_find create request:
@@ -491,7 +491,7 @@ Here is an example of an asychronous follow-up from a path_find create request:
## path_find close
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp#L58-L67 "Source")
-The `close` subcommand of `path_find` instructs the server to stop sending information about the current open pathfinding request.
+The `close` sub-command of `path_find` instructs the server to stop sending information about the current open pathfinding request.
### Request Format
An example of the request format:
@@ -514,7 +514,7 @@ The request includes the following parameters:
| `Field` | Type | Description |
|:-------------|:-------|:-------------------------------------------|
-| `subcommand` | String | Use `"close"` to send the close subcommand |
+| `subcommand` | String | Use `"close"` to send the close sub-command |
### Response Format
@@ -536,7 +536,7 @@ If there was no outstanding pathfinding request, an error is returned instead.
## path_find status
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp#L69-L77 "Source")
-The `status` subcommand of `path_find` requests an immediate update about the client's currently-open pathfinding request.
+The `status` sub-command of `path_find` requests an immediate update about the client's currently-open pathfinding request.
### Request Format
An example of the request format:
@@ -559,7 +559,7 @@ The request includes the following parameters:
| `Field` | Type | Description |
|:-------------|:-------|:---------------------------------------------|
-| `subcommand` | String | Use `"status"` to send the status subcommand |
+| `subcommand` | String | Use `"status"` to send the status sub-command |
### Response Format
diff --git a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md
index 133cc80d1d..9477118446 100644
--- a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md
+++ b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md
@@ -309,6 +309,108 @@ An example of a successful response:
}
```
+*Commandline*
+```json
+{
+ "result" : {
+ "alternatives" : [
+ {
+ "paths_canonical" : [],
+ "paths_computed" : [
+ [
+ {
+ "currency" : "USD",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ]
+ ],
+ "source_amount" : "5212"
+ },
+ {
+ "paths_canonical" : [],
+ "paths_computed" : [
+ [
+ {
+ "account" : "r9vbV3EHvXWjSkeQ6CAcYVPGeq7TuiXY2X",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ },
+ {
+ "account" : "rnx1RNE5cJbYzMsJbF3XzyQMxZNBPqdCVd",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ }
+ ],
+ [
+ {
+ "account" : "r9vbV3EHvXWjSkeQ6CAcYVPGeq7TuiXY2X",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ },
+ {
+ "account" : "ragizZ31TmpachYAuG3n56XCb1R5vc3cTQ",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ }
+ ],
+ [
+ {
+ "account" : "r9vbV3EHvXWjSkeQ6CAcYVPGeq7TuiXY2X",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ },
+ {
+ "account" : "r9JS9fLbtLzgBCdFCnS3LpVPUBJAmg7PnM",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ }
+ ],
+ [
+ {
+ "account" : "r9vbV3EHvXWjSkeQ6CAcYVPGeq7TuiXY2X",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ },
+ {
+ "account" : "rDc9zKqfxm43S9LwpNkwV9KgW6PKUPrT5u",
+ "type" : 1,
+ "type_hex" : "0000000000000001"
+ }
+ ]
+ ],
+ "source_amount" : {
+ "currency" : "USD",
+ "issuer" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "value" : "0.001002"
+ }
+ }
+ ],
+ "destination_account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "destination_amount" : {
+ "currency" : "USD",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0.001"
+ },
+ "destination_currencies" : [
+ "USD",
+ "015841551A748AD2C1F76FF6ECB0CCCD00000000",
+ "BTC",
+ "DYM",
+ "CNY",
+ "EUR",
+ "JOE",
+ "MXN",
+ "XRP"
+ ],
+ "full_reply" : true,
+ "source_account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+ "status" : "success"
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md b/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md
index e1372db33b..2c94ee8bd5 100644
--- a/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md
+++ b/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md
@@ -15,12 +15,12 @@ An account in the XRP Ledger represents a holder of XRP and a sender of transact
* **[`account_offers`](account_offers.html)** - Get info about an account's currency exchange offers.
* **[`account_tx`](account_tx.html)** - Get info about an account's transactions.
* **[`gateway_balances`](gateway_balances.html)** - Calculate total amounts issued by an account.
-* **[`noripple_check`](noripple_check.html)** - Get recommended changes to an account's DefaultRipple and NoRipple settings.
+* **[`noripple_check`](noripple_check.html)** - Get recommended changes to an account's Default Ripple and No Ripple settings.
## [Ledger Methods](ledger-methods.html)
-A ledger version contains a header, a transaction tree, and a state tree, which contain account settings, trustlines, balances, transactions, and other data. Use these methods to retrieve ledger info.
+A ledger version contains a header, a transaction tree, and a state tree, which contain account settings, trust lines, balances, transactions, and other data. Use these methods to retrieve ledger info.
* **[`ledger`](ledger.html)** - Get info about a ledger version.
* **[`ledger_closed`](ledger_closed.html)** - Get the latest closed ledger version.
diff --git a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md
index e8b0eda960..5a69c7f832 100644
--- a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md
+++ b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md
@@ -491,8 +491,8 @@ The `info` object may have some arrangement of the following fields:
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] |
| `build_version` | String | The version number of the running `rippled` version. |
| `closed_ledger` | Object | (May be omitted) Information on the most recently closed ledger that has not been validated by consensus. If the most recently validated ledger is available, the response omits this field and includes `validated_ledger` instead. The member fields are the same as the `validated_ledger` field. |
-| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. This may be a disjoint sequence such as `24900901-24900984,24901116-24901158`. If the server does not have any complete ledgers (for example, it just started syncing with the network), this is the string `empty`. |
-| `hostid` | String | On an admin request, returns the hostname of the server running the `rippled` instance; otherwise, returns a single RFC1751 word based on the node public key. |
+| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. This may be a disjoint sequence such as `24900901-24900984,24901116-24901158`. If the server does not have any complete ledgers (for example, it recently started syncing with the network), this is the string `empty`. |
+| `hostid` | String | On an admin request, returns the hostname of the server running the `rippled` instance; otherwise, returns a single [RFC-1751][] word based on the node public key. |
| `io_latency_ms` | Number | Amount of time spent waiting for I/O operations, in milliseconds. If this number is not very, very low, then the `rippled` server is probably having serious load issues. |
| `jq_trans_overflow` | String - Number | The number of times (since starting up) that this server has had over 250 transactions waiting to be processed at once. A large number here may mean that your server is unable to handle the transaction load of the XRP Ledger network. For detailed recommendations of future-proof server specifications, see [Capacity Planning](capacity-planning.html). [New in: rippled 0.90.0][] |
| `last_close` | Object | Information about the last time the server closed a ledger, including the amount of time it took to reach a consensus and the number of trusted validators participating. |
@@ -513,7 +513,7 @@ The `info` object may have some arrangement of the following fields:
| `server_state_duration_us` | Number | The number of consecutive microseconds the server has been in the current state. [New in: rippled 1.2.0][] |
| `state_accounting` | Object | A map of various [server states](rippled-server-states.html) with information about the time the server spends in each. This can be useful for tracking the long-term health of your server's connectivity to the network. [New in: rippled 0.30.1][] |
| `state_accounting.*.duration_us` | String | The number of microseconds the server has spent in this state. (This is updated whenever the server transitions into another state.) [New in: rippled 0.30.1][] |
-| `state_accounting.*.transitions` | Number | The number of times the server has transitioned into this state. [New in: rippled 0.30.1][] |
+| `state_accounting.*.transitions` | Number | The number of times the server has changed into this state. [New in: rippled 0.30.1][] |
| `time` | String | The current time in UTC, according to the server's clock. [Updated in: rippled 1.5.0][] |
| `uptime` | Number | Number of consecutive seconds that the server has been operational. [New in: rippled 0.30.1][] |
| `validated_ledger` | Object | _(May be omitted)_ Information about the most recent fully-validated ledger. If the most recent validated ledger is not available, the response omits this field and includes `closed_ledger` instead. |
diff --git a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md
index 3a11888606..d0d8b0c8db 100644
--- a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md
+++ b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md
@@ -527,7 +527,7 @@ The `state` object may have some arrangement of the following fields:
|:---------------------------------|:----------------|:------------------------|
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] |
| `build_version` | String | The version number of the running `rippled` version. |
-| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. It is possible to be a disjoint sequence, e.g. "2500-5000,32570-7695432". If the server does not have any complete ledgers (for example, it just started syncing with the network), this is the string `empty`. |
+| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. It is possible to be a disjoint sequence, e.g. "2500-5000,32570-7695432". If the server does not have any complete ledgers (for example, it recently started syncing with the network), this is the string `empty`. |
| `closed_ledger` | Object | _(May be omitted)_ Information on the most recently closed ledger that has not been validated by consensus. If the most recently validated ledger is available, the response omits this field and includes `validated_ledger` instead. The member fields are the same as the `validated_ledger` field. |
| `io_latency_ms` | Number | Amount of time spent waiting for I/O operations, in milliseconds. If this number is not very, very low, then the `rippled` server is probably having serious load issues. |
| `jq_trans_overflow` | String - Number | The number of times this server has had over 250 transactions waiting to be processed at once. A large number here may mean that your server is unable to handle the transaction load of the XRP Ledger network. For detailed recommendations of future-proof server specifications, see [Capacity Planning](capacity-planning.html). [New in: rippled 0.90.0][] |
@@ -547,7 +547,7 @@ The `state` object may have some arrangement of the following fields:
| `server_state_duration_us` | Number | The number of consecutive microseconds the server has been in the current state. [New in: rippled 1.2.0][] |
| `state_accounting` | Object | A map of various [server states](rippled-server-states.html) with information about the time the server spends in each. This can be useful for tracking the long-term health of your server's connectivity to the network. [New in: rippled 0.30.1][] |
| `state_accounting.*.duration_us` | String | The number of microseconds the server has spent in this state. (This is updated whenever the server transitions into another state.) [New in: rippled 0.30.1][] |
-| `state_accounting.*.transitions` | Number | The number of times the server has transitioned into this state. [New in: rippled 0.30.1][] |
+| `state_accounting.*.transitions` | Number | The number of times the server has changed into this state. [New in: rippled 0.30.1][] |
| `time` | String | The current time in UTC, according to the server's clock. [Updated in: rippled 1.5.0][] |
| `uptime` | Number | Number of consecutive seconds that the server has been operational. [New in: rippled 0.30.1][] |
| `validated_ledger` | Object | _(May be omitted)_ Information about the most recent fully-validated ledger. If the most recent validated ledger is not available, the response omits this field and includes `closed_ledger` instead. |
diff --git a/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md b/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md
index 730fdeb3c1..b36018eff3 100644
--- a/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md
+++ b/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md
@@ -10,7 +10,7 @@ An example of the request format:
*Subscribe to accounts*
-```
+```json
{
"id": "Example watch Bitstamp's hot wallet",
"command": "subscribe",
@@ -20,7 +20,7 @@ An example of the request format:
*Subscribe to order book*
-```
+```json
{
"id": "Example subscribe to XRP/GateHub USD order book",
"command": "subscribe",
@@ -41,7 +41,7 @@ An example of the request format:
*Subscribe to ledger stream*
-```
+```json
{
"id": "Example watch for new validated ledgers",
"command": "subscribe",
@@ -110,9 +110,9 @@ An example of a successful response:
The response follows the [standard format][]. The fields contained in the response vary depending on what subscriptions were included in the request.
* `accounts` and `accounts_proposed` - No fields returned.
-* *Stream: server* - Information about the server status, such as `load_base` (the current load level of the server), `random` (a randomly-generated value), and others, subject to change.
-* *Stream: transactions*, *Stream: transactions_proposed*, *Stream: validations*, and *Stream: consensus* - No fields returned.
-* *Stream: ledger* - Information about the ledgers on hand and current fee schedule. This includes the same fields as a [ledger stream message](#ledger-stream), except that it omits the `type` and `txn_count` fields.
+* *Stream: `server`* - Information about the server status, such as `load_base` (the current load level of the server), `random` (a randomly-generated value), and others, subject to change.
+* *Stream: `transactions`*, *Stream: `transactions_proposed`*, *Stream: `validations`*, and *Stream: `consensus`* - No fields returned.
+* *Stream: `ledger`* - Information about the ledgers on hand and current fee schedule. This includes the same fields as a [ledger stream message](#ledger-stream), except that it omits the `type` and `txn_count` fields.
* `books` - No fields returned by default. If `"snapshot": true` is set in the request, returns `offers` (an array of offer definition objects defining the order book).
## Possible Errors
@@ -163,7 +163,7 @@ The fields from a ledger stream message are as follows:
| `reserve_base` | Number | The minimum [reserve](reserves.html), in [drops of XRP][], that is required for an account. If this ledger version includes a [SetFee pseudo-transaction](setfee.html) the new base reserve applies starting with the following ledger version. |
| `reserve_inc` | Number | The [owner reserve](reserves.html#owner-reserves) for each object an account owns in the ledger, in [drops of XRP][]. If the ledger includes a [SetFee pseudo-transaction](setfee.html) the new owner reserve applies after this ledger. |
| `txn_count` | Number | Number of new transactions included in this ledger version. |
-| `validated_ledgers` | String | _(May be omitted)_ Range of ledgers that the server has available. This may be discontiguous. This field is not returned if the server is not connected to the network, or if it is connected but has not yet obtained a ledger from the network. |
+| `validated_ledgers` | String | _(May be omitted)_ Range of ledgers that the server has available. This may be a disjoint sequence such as `24900901-24900984,24901116-24901158`. This field is not returned if the server is not connected to the network, or if it is connected but has not yet obtained a ledger from the network. |
## Validations Stream
@@ -204,7 +204,7 @@ The fields from a validations stream message are as follows:
| `type` | String | The value `validationReceived` indicates this is from the validations stream. |
| `amendments` | Array of Strings | (May be omitted) The [amendments](amendments.html) this server wants to be added to the protocol. [New in: rippled 0.32.0][] |
| `base_fee` | Integer | (May be omitted) The unscaled transaction cost (`reference_fee` value) this server wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
-| `flags` | Number | Bit-mask of flags added to this validation message. The flag 0x80000000 indicates that the validation signature is fully-canonical. The flag 0x00000001 indicates that this is a full validation; otherwise it's a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
+| `flags` | Number | Bit-mask of flags added to this validation message. The flag `0x80000000` indicates that the validation signature is fully-canonical. The flag `0x00000001` indicates that this is a full validation; otherwise it's a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
| `full` | Boolean | If `true`, this is a full validation. Otherwise, this is a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
| `ledger_hash` | String | The identifying hash of the proposed ledger is being validated. |
| `ledger_index` | String - Integer | The [Ledger Index][] of the proposed ledger. [New in: rippled 0.31.0][] |
diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/transaction_entry.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/transaction_entry.md
index 65ff0e79d4..f5d05afa50 100644
--- a/content/references/rippled-api/public-rippled-methods/transaction-methods/transaction_entry.md
+++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/transaction_entry.md
@@ -15,8 +15,8 @@ An example of the request format:
{
"id": 4,
"command": "transaction_entry",
- "tx_hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
- "ledger_index": 348734
+ "tx_hash": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
+ "ledger_index": 56865245
}
```
@@ -27,8 +27,8 @@ An example of the request format:
"method": "transaction_entry",
"params": [
{
- "tx_hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
- "ledger_index": 348734
+ "tx_hash": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
+ "ledger_index": 56865245
}
]
}
@@ -38,7 +38,7 @@ An example of the request format:
```
#Syntax: transaction_entry transaction_hash ledger_index|ledger_hash
-rippled transaction_entry E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 348734
+rippled transaction_entry C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9 56865245
```
@@ -63,131 +63,372 @@ An example of a successful response:
*WebSocket*
-```
+```json
+{
+ "id": 4,
+ "result": {
+ "ledger_hash": "793E56131D8D4ABFB27FA383BFC44F2978B046E023FF46C588D7E0C874C2472A",
+ "ledger_index": 56865245,
+ "metadata": {
+ "AffectedNodes": [
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "ExchangeRate": "4F04C66806CF7400",
+ "Flags": 0,
+ "RootIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "TakerGetsCurrency": "0000000000000000000000000000000000000000",
+ "TakerGetsIssuer": "0000000000000000000000000000000000000000",
+ "TakerPaysCurrency": "000000000000000000000000434E590000000000",
+ "TakerPaysIssuer": "CED6E99370D5C00EF4EBF72567DA99F5661BFB3A"
+ },
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400"
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Balance": "10404767991",
+ "Flags": 0,
+ "OwnerCount": 3,
+ "Sequence": 5037711
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "1DECD9844E95FFBA273F1B94BA0BF2564DDF69F2804497A6D7837B52050174A2",
+ "PreviousFields": {
+ "Balance": "10404768003",
+ "Sequence": 5037710
+ },
+ "PreviousTxnID": "4DC47B246B5EB9CCE92ABA8C482479E3BF1F946CABBEF74CA4DE36521D5F9008",
+ "PreviousTxnLgrSeq": 56865244
+ }
+ },
+ {
+ "DeletedNode": {
+ "FinalFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "BookNode": "0000000000000000",
+ "Flags": 0,
+ "OwnerNode": "0000000000000000",
+ "PreviousTxnID": "8F5FF57B404827F12BDA7561876A13C3E3B3095CBF75334DBFB5F227391A660C",
+ "PreviousTxnLgrSeq": 56865244,
+ "Sequence": 5037708,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ }
+ },
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "26AAE6CA8D29E28A47C92ADF22D5D96A0216F0551E16936856DDC8CB1AAEE93B"
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Flags": 0,
+ "IndexNext": "0000000000000000",
+ "IndexPrevious": "0000000000000000",
+ "Owner": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "RootIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ },
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ }
+ },
+ {
+ "CreatedNode": {
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "8BAEE3C7DE04A568E96007420FA11ABD0BC9AE44D35932BB5640E9C3FB46BC9B",
+ "NewFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "Sequence": 5037710,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ }
+ }
+ }
+ }
+ ],
+ "TransactionIndex": 0,
+ "TransactionResult": "tesSUCCESS"
+ },
+ "tx_json": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee": "12",
+ "Flags": 0,
+ "LastLedgerSequence": 56865248,
+ "OfferSequence": 5037708,
+ "Sequence": 5037710,
+ "SigningPubKey": "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ },
+ "TransactionType": "OfferCreate",
+ "TxnSignature": "3045022100A5023A0E64923616FCDB6D664F569644C7C9D1895772F986CD6B981B515B02A00220530C973E9A8395BC6FE2484948D2751F6B030FC7FB8575D1BFB406368AD554D9",
+ "hash": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9"
+ },
+ "validated": true
+ },
+ "status": "success",
+ "type": "response"
+}
+```
+
+*JSON-RPC*
+
+```json
{
- "id": 4,
"result": {
- "ledger_index": 348734,
+ "ledger_hash": "793E56131D8D4ABFB27FA383BFC44F2978B046E023FF46C588D7E0C874C2472A",
+ "ledger_index": 56865245,
"metadata": {
"AffectedNodes": [
{
"ModifiedNode": {
"FinalFields": {
- "Account": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "Balance": "59328999119",
+ "ExchangeRate": "4F04C66806CF7400",
"Flags": 0,
- "OwnerCount": 11,
- "Sequence": 89
+ "RootIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "TakerGetsCurrency": "0000000000000000000000000000000000000000",
+ "TakerGetsIssuer": "0000000000000000000000000000000000000000",
+ "TakerPaysCurrency": "000000000000000000000000434E590000000000",
+ "TakerPaysIssuer": "CED6E99370D5C00EF4EBF72567DA99F5661BFB3A"
},
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "E0D7BDE68B468FF0B8D948FD865576517DA987569833A05374ADB9A72E870A06",
- "PreviousFields": {
- "Balance": "59328999129",
- "Sequence": 88
- },
- "PreviousTxnID": "C26AA6B4F7C3B9F55E17CD0D11F12032A1C7AD2757229FFD277C9447A8815E6E",
- "PreviousTxnLgrSeq": 348700
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400"
}
},
{
"ModifiedNode": {
"FinalFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "-1"
- },
- "Flags": 131072,
- "HighLimit": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "100"
- },
- "HighNode": "0000000000000000",
- "LowLimit": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "0"
- },
- "LowNode": "0000000000000000"
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Balance": "10404767991",
+ "Flags": 0,
+ "OwnerCount": 3,
+ "Sequence": 5037711
},
- "LedgerEntryType": "RippleState",
- "LedgerIndex": "EA4BF03B4700123CDFFB6EB09DC1D6E28D5CEB7F680FB00FC24BC1C3BB2DB959",
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "1DECD9844E95FFBA273F1B94BA0BF2564DDF69F2804497A6D7837B52050174A2",
"PreviousFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "0"
+ "Balance": "10404768003",
+ "Sequence": 5037710
+ },
+ "PreviousTxnID": "4DC47B246B5EB9CCE92ABA8C482479E3BF1F946CABBEF74CA4DE36521D5F9008",
+ "PreviousTxnLgrSeq": 56865244
+ }
+ },
+ {
+ "DeletedNode": {
+ "FinalFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "BookNode": "0000000000000000",
+ "Flags": 0,
+ "OwnerNode": "0000000000000000",
+ "PreviousTxnID": "8F5FF57B404827F12BDA7561876A13C3E3B3095CBF75334DBFB5F227391A660C",
+ "PreviousTxnLgrSeq": 56865244,
+ "Sequence": 5037708,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
}
},
- "PreviousTxnID": "53354D84BAE8FDFC3F4DA879D984D24B929E7FEB9100D2AD9EFCD2E126BCCDC8",
- "PreviousTxnLgrSeq": 343570
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "26AAE6CA8D29E28A47C92ADF22D5D96A0216F0551E16936856DDC8CB1AAEE93B"
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Flags": 0,
+ "IndexNext": "0000000000000000",
+ "IndexPrevious": "0000000000000000",
+ "Owner": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "RootIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ },
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ }
+ },
+ {
+ "CreatedNode": {
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "8BAEE3C7DE04A568E96007420FA11ABD0BC9AE44D35932BB5640E9C3FB46BC9B",
+ "NewFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "Sequence": 5037710,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ }
+ }
}
}
],
"TransactionIndex": 0,
"TransactionResult": "tesSUCCESS"
},
+ "status": "success",
"tx_json": {
- "Account": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "Amount": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "1"
- },
- "Destination": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Fee": "10",
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee": "12",
"Flags": 0,
- "Paths": [
- [
- {
- "account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "type": 49,
- "type_hex": "0000000000000031"
- }
- ],
- [
- {
- "account": "rD1jovjQeEpvaDwn9wKaYokkXXrqo4D23x",
- "currency": "USD",
- "issuer": "rD1jovjQeEpvaDwn9wKaYokkXXrqo4D23x",
- "type": 49,
- "type_hex": "0000000000000031"
- },
- {
- "account": "rB5TihdPbKgMrkFqrqUC3yLdE8hhv4BdeY",
- "currency": "USD",
- "issuer": "rB5TihdPbKgMrkFqrqUC3yLdE8hhv4BdeY",
- "type": 49,
- "type_hex": "0000000000000031"
- },
- {
- "account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "type": 49,
- "type_hex": "0000000000000031"
- }
- ]
- ],
- "SendMax": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "1.01"
+ "LastLedgerSequence": 56865248,
+ "OfferSequence": 5037708,
+ "Sequence": 5037710,
+ "SigningPubKey": "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
},
- "Sequence": 88,
- "SigningPubKey": "02EAE5DAB54DD8E1C49641D848D5B97D1B29149106174322EDF98A1B2CCE5D7F8E",
- "TransactionType": "Payment",
- "TxnSignature": "30440220791B6A3E036ECEFFE99E8D4957564E8C84D1548C8C3E80A87ED1AA646ECCFB16022037C5CAC97E34E3021EBB426479F2ACF3ACA75DB91DCC48D1BCFB4CF547CFEAA0",
- "hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
- "inLedger": 348734,
- "ledger_index": 348734
- }
- },
- "status": "success",
- "type": "response"
+ "TransactionType": "OfferCreate",
+ "TxnSignature": "3045022100A5023A0E64923616FCDB6D664F569644C7C9D1895772F986CD6B981B515B02A00220530C973E9A8395BC6FE2484948D2751F6B030FC7FB8575D1BFB406368AD554D9",
+ "hash": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9"
+ },
+ "validated": true
+ }
+}
+```
+
+*Commandline*
+
+```json
+{
+ "result" : {
+ "ledger_hash" : "793E56131D8D4ABFB27FA383BFC44F2978B046E023FF46C588D7E0C874C2472A",
+ "ledger_index" : 56865245,
+ "metadata" : {
+ "AffectedNodes" : [
+ {
+ "ModifiedNode" : {
+ "FinalFields" : {
+ "ExchangeRate" : "4F04C66806CF7400",
+ "Flags" : 0,
+ "RootIndex" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "TakerGetsCurrency" : "0000000000000000000000000000000000000000",
+ "TakerGetsIssuer" : "0000000000000000000000000000000000000000",
+ "TakerPaysCurrency" : "000000000000000000000000434E590000000000",
+ "TakerPaysIssuer" : "CED6E99370D5C00EF4EBF72567DA99F5661BFB3A"
+ },
+ "LedgerEntryType" : "DirectoryNode",
+ "LedgerIndex" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400"
+ }
+ },
+ {
+ "ModifiedNode" : {
+ "FinalFields" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Balance" : "10404767991",
+ "Flags" : 0,
+ "OwnerCount" : 3,
+ "Sequence" : 5037711
+ },
+ "LedgerEntryType" : "AccountRoot",
+ "LedgerIndex" : "1DECD9844E95FFBA273F1B94BA0BF2564DDF69F2804497A6D7837B52050174A2",
+ "PreviousFields" : {
+ "Balance" : "10404768003",
+ "Sequence" : 5037710
+ },
+ "PreviousTxnID" : "4DC47B246B5EB9CCE92ABA8C482479E3BF1F946CABBEF74CA4DE36521D5F9008",
+ "PreviousTxnLgrSeq" : 56865244
+ }
+ },
+ {
+ "DeletedNode" : {
+ "FinalFields" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "BookNode" : "0000000000000000",
+ "Flags" : 0,
+ "OwnerNode" : "0000000000000000",
+ "PreviousTxnID" : "8F5FF57B404827F12BDA7561876A13C3E3B3095CBF75334DBFB5F227391A660C",
+ "PreviousTxnLgrSeq" : 56865244,
+ "Sequence" : 5037708,
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20160.75"
+ }
+ },
+ "LedgerEntryType" : "Offer",
+ "LedgerIndex" : "26AAE6CA8D29E28A47C92ADF22D5D96A0216F0551E16936856DDC8CB1AAEE93B"
+ }
+ },
+ {
+ "ModifiedNode" : {
+ "FinalFields" : {
+ "Flags" : 0,
+ "IndexNext" : "0000000000000000",
+ "IndexPrevious" : "0000000000000000",
+ "Owner" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "RootIndex" : "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ },
+ "LedgerEntryType" : "DirectoryNode",
+ "LedgerIndex" : "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ }
+ },
+ {
+ "CreatedNode" : {
+ "LedgerEntryType" : "Offer",
+ "LedgerIndex" : "8BAEE3C7DE04A568E96007420FA11ABD0BC9AE44D35932BB5640E9C3FB46BC9B",
+ "NewFields" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "Sequence" : 5037710,
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20160.75"
+ }
+ }
+ }
+ }
+ ],
+ "TransactionIndex" : 0,
+ "TransactionResult" : "tesSUCCESS"
+ },
+ "status" : "success",
+ "tx_json" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56865248,
+ "OfferSequence" : 5037708,
+ "Sequence" : 5037710,
+ "SigningPubKey" : "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20160.75"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100A5023A0E64923616FCDB6D664F569644C7C9D1895772F986CD6B981B515B02A00220530C973E9A8395BC6FE2484948D2751F6B030FC7FB8575D1BFB406368AD554D9",
+ "hash" : "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9"
+ },
+ "validated" : true
+ }
}
```
diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md
index 0d38f240f8..21092fbb25 100644
--- a/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md
+++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md
@@ -15,7 +15,7 @@ An example of the request format:
{
"id": 1,
"command": "tx",
- "transaction": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
+ "transaction": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
"binary": false
}
```
@@ -26,7 +26,7 @@ An example of the request format:
"method": "tx",
"params": [
{
- "transaction": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
+ "transaction": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
"binary": false
}
]
@@ -36,7 +36,7 @@ An example of the request format:
```sh
#Syntax: tx transaction [binary]
-rippled tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 false
+rippled tx C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9 false
```
@@ -64,127 +64,367 @@ An example of a successful response:
```json
{
- "id": 1,
+ "id": 1,
+ "result": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee": "12",
+ "Flags": 0,
+ "LastLedgerSequence": 56865248,
+ "OfferSequence": 5037708,
+ "Sequence": 5037710,
+ "SigningPubKey": "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ },
+ "TransactionType": "OfferCreate",
+ "TxnSignature": "3045022100A5023A0E64923616FCDB6D664F569644C7C9D1895772F986CD6B981B515B02A00220530C973E9A8395BC6FE2484948D2751F6B030FC7FB8575D1BFB406368AD554D9",
+ "date": 648248020,
+ "hash": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
+ "inLedger": 56865245,
+ "ledger_index": 56865245,
+ "meta": {
+ "AffectedNodes": [
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "ExchangeRate": "4F04C66806CF7400",
+ "Flags": 0,
+ "RootIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "TakerGetsCurrency": "0000000000000000000000000000000000000000",
+ "TakerGetsIssuer": "0000000000000000000000000000000000000000",
+ "TakerPaysCurrency": "000000000000000000000000434E590000000000",
+ "TakerPaysIssuer": "CED6E99370D5C00EF4EBF72567DA99F5661BFB3A"
+ },
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400"
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Balance": "10404767991",
+ "Flags": 0,
+ "OwnerCount": 3,
+ "Sequence": 5037711
+ },
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "1DECD9844E95FFBA273F1B94BA0BF2564DDF69F2804497A6D7837B52050174A2",
+ "PreviousFields": {
+ "Balance": "10404768003",
+ "Sequence": 5037710
+ },
+ "PreviousTxnID": "4DC47B246B5EB9CCE92ABA8C482479E3BF1F946CABBEF74CA4DE36521D5F9008",
+ "PreviousTxnLgrSeq": 56865244
+ }
+ },
+ {
+ "DeletedNode": {
+ "FinalFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "BookNode": "0000000000000000",
+ "Flags": 0,
+ "OwnerNode": "0000000000000000",
+ "PreviousTxnID": "8F5FF57B404827F12BDA7561876A13C3E3B3095CBF75334DBFB5F227391A660C",
+ "PreviousTxnLgrSeq": 56865244,
+ "Sequence": 5037708,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ }
+ },
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "26AAE6CA8D29E28A47C92ADF22D5D96A0216F0551E16936856DDC8CB1AAEE93B"
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Flags": 0,
+ "IndexNext": "0000000000000000",
+ "IndexPrevious": "0000000000000000",
+ "Owner": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "RootIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ },
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ }
+ },
+ {
+ "CreatedNode": {
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "8BAEE3C7DE04A568E96007420FA11ABD0BC9AE44D35932BB5640E9C3FB46BC9B",
+ "NewFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "Sequence": 5037710,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ }
+ }
+ }
+ }
+ ],
+ "TransactionIndex": 0,
+ "TransactionResult": "tesSUCCESS"
+ },
+ "validated": true
+ },
+ "status": "success",
+ "type": "response"
+}
+```
+
+*JSON-RPC*
+
+```json
+{
"result": {
- "Account": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "Amount": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "1"
- },
- "Destination": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "Fee": "10",
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee": "12",
"Flags": 0,
- "Paths": [
- [
- {
- "account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "type": 49,
- "type_hex": "0000000000000031"
- }
- ],
- [
- {
- "account": "rD1jovjQeEpvaDwn9wKaYokkXXrqo4D23x",
- "currency": "USD",
- "issuer": "rD1jovjQeEpvaDwn9wKaYokkXXrqo4D23x",
- "type": 49,
- "type_hex": "0000000000000031"
- },
- {
- "account": "rB5TihdPbKgMrkFqrqUC3yLdE8hhv4BdeY",
- "currency": "USD",
- "issuer": "rB5TihdPbKgMrkFqrqUC3yLdE8hhv4BdeY",
- "type": 49,
- "type_hex": "0000000000000031"
- },
- {
- "account": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "currency": "USD",
- "issuer": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
- "type": 49,
- "type_hex": "0000000000000031"
- }
- ]
- ],
- "SendMax": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "1.01"
+ "LastLedgerSequence": 56865248,
+ "OfferSequence": 5037708,
+ "Sequence": 5037710,
+ "SigningPubKey": "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
},
- "Sequence": 88,
- "SigningPubKey": "02EAE5DAB54DD8E1C49641D848D5B97D1B29149106174322EDF98A1B2CCE5D7F8E",
- "TransactionType": "Payment",
- "TxnSignature": "30440220791B6A3E036ECEFFE99E8D4957564E8C84D1548C8C3E80A87ED1AA646ECCFB16022037C5CAC97E34E3021EBB426479F2ACF3ACA75DB91DCC48D1BCFB4CF547CFEAA0",
- "hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
- "inLedger": 348734,
- "ledger_index": 348734,
+ "TransactionType": "OfferCreate",
+ "TxnSignature": "3045022100A5023A0E64923616FCDB6D664F569644C7C9D1895772F986CD6B981B515B02A00220530C973E9A8395BC6FE2484948D2751F6B030FC7FB8575D1BFB406368AD554D9",
+ "date": 648248020,
+ "hash": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
+ "inLedger": 56865245,
+ "ledger_index": 56865245,
"meta": {
"AffectedNodes": [
{
"ModifiedNode": {
"FinalFields": {
- "Account": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "Balance": "59328999119",
+ "ExchangeRate": "4F04C66806CF7400",
"Flags": 0,
- "OwnerCount": 11,
- "Sequence": 89
+ "RootIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "TakerGetsCurrency": "0000000000000000000000000000000000000000",
+ "TakerGetsIssuer": "0000000000000000000000000000000000000000",
+ "TakerPaysCurrency": "000000000000000000000000434E590000000000",
+ "TakerPaysIssuer": "CED6E99370D5C00EF4EBF72567DA99F5661BFB3A"
},
- "LedgerEntryType": "AccountRoot",
- "LedgerIndex": "E0D7BDE68B468FF0B8D948FD865576517DA987569833A05374ADB9A72E870A06",
- "PreviousFields": {
- "Balance": "59328999129",
- "Sequence": 88
- },
- "PreviousTxnID": "C26AA6B4F7C3B9F55E17CD0D11F12032A1C7AD2757229FFD277C9447A8815E6E",
- "PreviousTxnLgrSeq": 348700
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400"
}
},
{
"ModifiedNode": {
"FinalFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "-1"
- },
- "Flags": 131072,
- "HighLimit": {
- "currency": "USD",
- "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
- "value": "100"
- },
- "HighNode": "0000000000000000",
- "LowLimit": {
- "currency": "USD",
- "issuer": "r3PDtZSa5LiYp1Ysn1vMuMzB59RzV3W9QH",
- "value": "0"
- },
- "LowNode": "0000000000000000"
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Balance": "10404767991",
+ "Flags": 0,
+ "OwnerCount": 3,
+ "Sequence": 5037711
},
- "LedgerEntryType": "RippleState",
- "LedgerIndex": "EA4BF03B4700123CDFFB6EB09DC1D6E28D5CEB7F680FB00FC24BC1C3BB2DB959",
+ "LedgerEntryType": "AccountRoot",
+ "LedgerIndex": "1DECD9844E95FFBA273F1B94BA0BF2564DDF69F2804497A6D7837B52050174A2",
"PreviousFields": {
- "Balance": {
- "currency": "USD",
- "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
- "value": "0"
+ "Balance": "10404768003",
+ "Sequence": 5037710
+ },
+ "PreviousTxnID": "4DC47B246B5EB9CCE92ABA8C482479E3BF1F946CABBEF74CA4DE36521D5F9008",
+ "PreviousTxnLgrSeq": 56865244
+ }
+ },
+ {
+ "DeletedNode": {
+ "FinalFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "BookNode": "0000000000000000",
+ "Flags": 0,
+ "OwnerNode": "0000000000000000",
+ "PreviousTxnID": "8F5FF57B404827F12BDA7561876A13C3E3B3095CBF75334DBFB5F227391A660C",
+ "PreviousTxnLgrSeq": 56865244,
+ "Sequence": 5037708,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
}
},
- "PreviousTxnID": "53354D84BAE8FDFC3F4DA879D984D24B929E7FEB9100D2AD9EFCD2E126BCCDC8",
- "PreviousTxnLgrSeq": 343570
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "26AAE6CA8D29E28A47C92ADF22D5D96A0216F0551E16936856DDC8CB1AAEE93B"
+ }
+ },
+ {
+ "ModifiedNode": {
+ "FinalFields": {
+ "Flags": 0,
+ "IndexNext": "0000000000000000",
+ "IndexPrevious": "0000000000000000",
+ "Owner": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "RootIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ },
+ "LedgerEntryType": "DirectoryNode",
+ "LedgerIndex": "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ }
+ },
+ {
+ "CreatedNode": {
+ "LedgerEntryType": "Offer",
+ "LedgerIndex": "8BAEE3C7DE04A568E96007420FA11ABD0BC9AE44D35932BB5640E9C3FB46BC9B",
+ "NewFields": {
+ "Account": "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory": "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "Sequence": 5037710,
+ "TakerGets": "15000000000",
+ "TakerPays": {
+ "currency": "CNY",
+ "issuer": "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value": "20160.75"
+ }
+ }
}
}
],
"TransactionIndex": 0,
"TransactionResult": "tesSUCCESS"
},
+ "status": "success",
"validated": true
- },
- "status": "success",
- "type": "response"
+ }
+}
+```
+
+*Commandline*
+
+```json
+{
+ "result" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56865248,
+ "OfferSequence" : 5037708,
+ "Sequence" : 5037710,
+ "SigningPubKey" : "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20160.75"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100A5023A0E64923616FCDB6D664F569644C7C9D1895772F986CD6B981B515B02A00220530C973E9A8395BC6FE2484948D2751F6B030FC7FB8575D1BFB406368AD554D9",
+ "date" : 648248020,
+ "hash" : "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
+ "inLedger" : 56865245,
+ "ledger_index" : 56865245,
+ "meta" : {
+ "AffectedNodes" : [
+ {
+ "ModifiedNode" : {
+ "FinalFields" : {
+ "ExchangeRate" : "4F04C66806CF7400",
+ "Flags" : 0,
+ "RootIndex" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "TakerGetsCurrency" : "0000000000000000000000000000000000000000",
+ "TakerGetsIssuer" : "0000000000000000000000000000000000000000",
+ "TakerPaysCurrency" : "000000000000000000000000434E590000000000",
+ "TakerPaysIssuer" : "CED6E99370D5C00EF4EBF72567DA99F5661BFB3A"
+ },
+ "LedgerEntryType" : "DirectoryNode",
+ "LedgerIndex" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400"
+ }
+ },
+ {
+ "ModifiedNode" : {
+ "FinalFields" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Balance" : "10404767991",
+ "Flags" : 0,
+ "OwnerCount" : 3,
+ "Sequence" : 5037711
+ },
+ "LedgerEntryType" : "AccountRoot",
+ "LedgerIndex" : "1DECD9844E95FFBA273F1B94BA0BF2564DDF69F2804497A6D7837B52050174A2",
+ "PreviousFields" : {
+ "Balance" : "10404768003",
+ "Sequence" : 5037710
+ },
+ "PreviousTxnID" : "4DC47B246B5EB9CCE92ABA8C482479E3BF1F946CABBEF74CA4DE36521D5F9008",
+ "PreviousTxnLgrSeq" : 56865244
+ }
+ },
+ {
+ "DeletedNode" : {
+ "FinalFields" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "BookNode" : "0000000000000000",
+ "Flags" : 0,
+ "OwnerNode" : "0000000000000000",
+ "PreviousTxnID" : "8F5FF57B404827F12BDA7561876A13C3E3B3095CBF75334DBFB5F227391A660C",
+ "PreviousTxnLgrSeq" : 56865244,
+ "Sequence" : 5037708,
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20160.75"
+ }
+ },
+ "LedgerEntryType" : "Offer",
+ "LedgerIndex" : "26AAE6CA8D29E28A47C92ADF22D5D96A0216F0551E16936856DDC8CB1AAEE93B"
+ }
+ },
+ {
+ "ModifiedNode" : {
+ "FinalFields" : {
+ "Flags" : 0,
+ "IndexNext" : "0000000000000000",
+ "IndexPrevious" : "0000000000000000",
+ "Owner" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "RootIndex" : "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ },
+ "LedgerEntryType" : "DirectoryNode",
+ "LedgerIndex" : "47FAF5D102D8CE655574F440CDB97AC67C5A11068BB3759E87C2B9745EE94548"
+ }
+ },
+ {
+ "CreatedNode" : {
+ "LedgerEntryType" : "Offer",
+ "LedgerIndex" : "8BAEE3C7DE04A568E96007420FA11ABD0BC9AE44D35932BB5640E9C3FB46BC9B",
+ "NewFields" : {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "BookDirectory" : "02BAAC1E67C1CE0E96F0FA2E8061020536CEDD043FEB0FF54F04C66806CF7400",
+ "Sequence" : 5037710,
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20160.75"
+ }
+ }
+ }
+ }
+ ],
+ "TransactionIndex" : 0,
+ "TransactionResult" : "tesSUCCESS"
+ },
+ "status" : "success",
+ "validated" : true
+ }
}
```
diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/tx_history.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/tx_history.md
index e1b2b13682..c6b79b8c67 100644
--- a/content/references/rippled-api/public-rippled-methods/transaction-methods/tx_history.md
+++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/tx_history.md
@@ -876,6 +876,558 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "index" : 0,
+ "status" : "success",
+ "txs" : [
+ {
+ "Account" : "r96HghtYDxvpHNaru1xbCQPcsHZwqiaENE",
+ "Amount" : {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "value" : "10000"
+ },
+ "Destination" : "r96HghtYDxvpHNaru1xbCQPcsHZwqiaENE",
+ "Fee" : "11",
+ "Flags" : 2147942400,
+ "LastLedgerSequence" : 56845613,
+ "Paths" : [
+ [
+ {
+ "currency" : "BTC",
+ "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "EUR",
+ "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XRP",
+ "type" : 16,
+ "type_hex" : "0000000000000010"
+ },
+ {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ],
+ [
+ {
+ "currency" : "EUR",
+ "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "BTC",
+ "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XRP",
+ "type" : 16,
+ "type_hex" : "0000000000000010"
+ },
+ {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ],
+ [
+ {
+ "currency" : "USD",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XRP",
+ "type" : 16,
+ "type_hex" : "0000000000000010"
+ },
+ {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ],
+ [
+ {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "USD",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XRP",
+ "type" : 16,
+ "type_hex" : "0000000000000010"
+ },
+ {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ],
+ [
+ {
+ "currency" : "USD",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XLM",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XRP",
+ "type" : 16,
+ "type_hex" : "0000000000000010"
+ },
+ {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ],
+ [
+ {
+ "currency" : "XLM",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "USD",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ },
+ {
+ "currency" : "XRP",
+ "type" : 16,
+ "type_hex" : "0000000000000010"
+ },
+ {
+ "currency" : "CNT",
+ "issuer" : "rPFLkxQk6xUGdGYEykqe7PR25Gr7mLHDc8",
+ "type" : 48,
+ "type_hex" : "0000000000000030"
+ }
+ ]
+ ],
+ "SendMax" : "10000000000",
+ "Sequence" : 11629682,
+ "SigningPubKey" : "03E45D5E88ABB50151F5F00A02B2A7B66CB6CEC8E55304C4BF7D0B27BB59A14800",
+ "TransactionType" : "Payment",
+ "TxnSignature" : "30450221008E9DDFF13C5FD1BDC01F7C1AC74CFF6E9B40FEE33D9F0E3CC30D45EDCA9170E402202EEABBC0A045D0091C7F3B80F22A1C060DE6D6975B93DC2508FB6DAFC0FC9F61",
+ "hash" : "E9047DD5B43E9AB392D8AABE3799D8AD9A73177705570E76181E3568AA380DE1",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhXZDebYFALnTyWhFFPQJNqREGa27JPYiA",
+ "Fee" : "10",
+ "Flags" : 2147483648,
+ "LastLedgerSequence" : 56845615,
+ "OfferSequence" : 3400529,
+ "Sequence" : 3400607,
+ "SigningPubKey" : "03355CC886EB9C7FE8B69328D76AB2854525F35AB748839CC80D3B2F5CA9766DD1",
+ "TransactionType" : "OfferCancel",
+ "TxnSignature" : "3045022100F76589FEF96AD00DDFC07298A2FA7071B97D200879B65DE33AA138687946A187022079C3D1C571C4080F720677A99CB01BF3C4BDC14C0A663899391BC5F2A85A9B5A",
+ "hash" : "BD681EA79C5362FEF9101BFB565974794E937A22304051E7857ADD13B5BE0AD4",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhXZDebYFALnTyWhFFPQJNqREGa27JPYiA",
+ "Fee" : "10",
+ "Flags" : 2147483648,
+ "LastLedgerSequence" : 56845615,
+ "Sequence" : 3400606,
+ "SigningPubKey" : "03355CC886EB9C7FE8B69328D76AB2854525F35AB748839CC80D3B2F5CA9766DD1",
+ "TakerGets" : {
+ "currency" : "BTC",
+ "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL",
+ "value" : "0.00507205478630516"
+ },
+ "TakerPays" : "249657501",
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100C5DA644638C1FE4CF243D9E8A623AD3B86903F8F7D15F9488D7C4A283A7057FD022063A4166D7C077220BDD53B251784FEE78550FE714C7F7FB0B0F920EF0D622A63",
+ "hash" : "BB2A5A57AA020C297ABFB3533E1478778C0A723D0376494FF716D54E66238945",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhXZDebYFALnTyWhFFPQJNqREGa27JPYiA",
+ "Fee" : "10",
+ "Flags" : 2147483648,
+ "LastLedgerSequence" : 56845615,
+ "OfferSequence" : 3400527,
+ "Sequence" : 3400605,
+ "SigningPubKey" : "03355CC886EB9C7FE8B69328D76AB2854525F35AB748839CC80D3B2F5CA9766DD1",
+ "TransactionType" : "OfferCancel",
+ "TxnSignature" : "30450221008CCA40D79736F8845C73469860E1A11500C45CC9F96B6081FCCD260AB8B6C9A5022021F8665655D9FA378AC44CAAE181693A5FB6D545774C8ECE3BD403A28A523A6D",
+ "hash" : "493F0944765501302028E8A2528C6731DCAA4CA7A3C3136D7563A0FCB0E93692",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhXZDebYFALnTyWhFFPQJNqREGa27JPYiA",
+ "Fee" : "10",
+ "Flags" : 2147483648,
+ "LastLedgerSequence" : 56845615,
+ "Sequence" : 3400604,
+ "SigningPubKey" : "03355CC886EB9C7FE8B69328D76AB2854525F35AB748839CC80D3B2F5CA9766DD1",
+ "TakerGets" : {
+ "currency" : "BTC",
+ "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL",
+ "value" : "0.00507205478630516"
+ },
+ "TakerPays" : {
+ "currency" : "ETH",
+ "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h",
+ "value" : "0.202004149646394"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "304402203078ECCAD7CDBD9D1D29D50370E5D897781B53643ADA86DC31C588B80AF979A002203B9EDF215C13A151876B02785EA5FFA43A88BDE4039DD34B4B0B298E3357170D",
+ "hash" : "DDA8785FE70C4543B464DDFFB8418A98509F340E32AD587CA221249C32A211CB",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhXZDebYFALnTyWhFFPQJNqREGa27JPYiA",
+ "Fee" : "10",
+ "Flags" : 2147483648,
+ "LastLedgerSequence" : 56845615,
+ "OfferSequence" : 3400525,
+ "Sequence" : 3400603,
+ "SigningPubKey" : "03355CC886EB9C7FE8B69328D76AB2854525F35AB748839CC80D3B2F5CA9766DD1",
+ "TransactionType" : "OfferCancel",
+ "TxnSignature" : "304402201D09EB1E9AEC4E33CC7C714283393B1D32C005180C34B3F25D91BD0A0FDF91560220064F2A0904F9EEB5EC405814ADDF65A7096D0FC9A793A3523DE222489DE8ABEF",
+ "hash" : "5D44EF496DDBE4DEDE6FF3CA2666CF2C48538DB1B696B331369A6A188733476F",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhXZDebYFALnTyWhFFPQJNqREGa27JPYiA",
+ "Fee" : "10",
+ "Flags" : 2147483648,
+ "LastLedgerSequence" : 56845615,
+ "Sequence" : 3400602,
+ "SigningPubKey" : "03355CC886EB9C7FE8B69328D76AB2854525F35AB748839CC80D3B2F5CA9766DD1",
+ "TakerGets" : {
+ "currency" : "BTC",
+ "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL",
+ "value" : "0.00507205478630516"
+ },
+ "TakerPays" : {
+ "currency" : "BTC",
+ "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
+ "value" : "0.00517038081708025"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100CF63E5FB454C5D1939E950B843B8DE776A10643C3F675AEA13972833F3D18B2702203654A5C3FB25DF2FB48F7C25689716F7DBB9503B0760E45F823E2348846C2AB7",
+ "hash" : "766118E01073DEF7977601B9B800C13996B9885AECA744A6C421892235EF2B5C",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845615,
+ "OfferSequence" : 5021336,
+ "Sequence" : 5021338,
+ "SigningPubKey" : "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20874.44999999999"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100B368499CA2E5B3F6044E17AA9CBC93555B34993F92C56CBC445018F0ABEE0045022015F65F9F7ECA684F19F2F497EFBCF2A44D075EA887ABD5191D9A04EE6E8D7F4A",
+ "hash" : "90D9BF0A93DC3C2BE7C256338664265D7546C8AD2F247E73ADF9FEAFA65A06CA",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845615,
+ "OfferSequence" : 5021335,
+ "Sequence" : 5021337,
+ "SigningPubKey" : "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20812.8"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100D0C7E3CD774B9D5D5B9931119CCA0D80302669D8845DA72905677D19A334BCE202204A5D9DCD4D27F22D28B14153B8FE36779A11A27ECE6A442A883E04975019B50D",
+ "hash" : "3238F80A01E60420BBB909A47130A9DA717EB8AD9F8550CFAC124317C26A9354",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 5021334,
+ "Sequence" : 5021336,
+ "SigningPubKey" : "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20876.55"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100874C70F9AE0732D45573B65864282A505F932AA111DBB3FC15F70C21AA8B1973022004773A4E61E9DDBBF9E0BD11827921F7E2EBBAE1D4ED50AF8F4A8A0893E7FF37",
+ "hash" : "09592065F990A35096B5131A68449D417A57A9A6943C6D2842DB9E9B7BA783F3",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rhhh49pFH96roGyuC4E5P4CHaNjS1k8gzM",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 5021333,
+ "Sequence" : 5021335,
+ "SigningPubKey" : "03B51A3EDF70E4098DA7FB053A01C5A6A0A163A30ED1445F14F87C7C3295FCB3BE",
+ "TakerGets" : "15000000000",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y",
+ "value" : "20814.89999999999"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "304502210087EE970DA4C613FFDE3AF3FFD6810011892113550A34DDB91179B96D87A8235E022053487E63E2A426A9942A5974BF67C44C0D17A754B92D641A21B9EDE2F21530EE",
+ "hash" : "75F61FED9ADCC8F091A330119A73B4A6949F76982916E2EBD37A8B3ADF910E0F",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rh3VLyj1GbQjX7eA15BwUagEhSrPHmLkSR",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 41691946,
+ "Sequence" : 41691950,
+ "SigningPubKey" : "022D40673B44C82DEE1DDB8B9BB53DCCE4F97B27404DB850F068DD91D685E337EA",
+ "TakerGets" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "41318.81898853314"
+ },
+ "TakerPays" : "30915226849",
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100C9600476A340E9EABF57A0A11222341EDA58820CB9CBE68CEB1B091F6BD38F780220497BC21226C96956E119D2979AEF6A9A68387AD16AB454ADC3EB65F9ACE96BE5",
+ "hash" : "391B7E37EBBEA051E1D33B84569C959A4D73F5F4E61ABC9FB62C381B6D68E9B7",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rwchA2b36zu2r6CJfEMzPLQ1cmciKFcw9t",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9320758,
+ "Sequence" : 9320762,
+ "SigningPubKey" : "037E9B02A63FFC298C82B66D250932A5DCF89361122925CB42339E3C769245084C",
+ "TakerGets" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "21604.14928277434"
+ },
+ "TakerPays" : "18046769983",
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "304402207130109344A2002B02F9DC3454572F1DE48A76D489F3A2912F17AA54586975F3022035BEAB40662F077F7B119CB77ACFD480B720E614C0F5C7AC7224EAF611CB7BCA",
+ "hash" : "FA0FC48F5087AA77E630EFD9D6E8F7C1465086846696AF00EEF517377A2CB749",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rwchA2b36zu2r6CJfEMzPLQ1cmciKFcw9t",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9320757,
+ "Sequence" : 9320761,
+ "SigningPubKey" : "037E9B02A63FFC298C82B66D250932A5DCF89361122925CB42339E3C769245084C",
+ "TakerGets" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "21153.27740430806"
+ },
+ "TakerPays" : "17084997741",
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3044022070D1F61AB277243ED18C8104DC7251DE464C37DC3F8A92C48586DA02FE27944E02203E63E73E0ABE7EAE518BB7CFAE5FFAB20BE1DECC60D6B4B16B9B72DC920BB06A",
+ "hash" : "D01E289C628C441EAC2279929951ED0DA2816A6560C0985A093E85BB9E506937",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rwchA2b36zu2r6CJfEMzPLQ1cmciKFcw9t",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9320756,
+ "Sequence" : 9320760,
+ "SigningPubKey" : "037E9B02A63FFC298C82B66D250932A5DCF89361122925CB42339E3C769245084C",
+ "TakerGets" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "23222.92606822486"
+ },
+ "TakerPays" : "18155392823",
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3044022027BA44F8509ED750ACE3FF3808DEE7C5800CE2AF6DD578C7AFD212D45EB1505E0220448283547BC3C0A6D316A8ADF884FFD216DF1288C813ECBF95B6457A24273844",
+ "hash" : "BB65B88A976B04FF906C0962764BBED724B410514CAB614F1C4D1CD9F397C8D0",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rwchA2b36zu2r6CJfEMzPLQ1cmciKFcw9t",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9320755,
+ "Sequence" : 9320759,
+ "SigningPubKey" : "037E9B02A63FFC298C82B66D250932A5DCF89361122925CB42339E3C769245084C",
+ "TakerGets" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "28979.36444343412"
+ },
+ "TakerPays" : "21952068329",
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100D32888AE7BF2312A661FE5C61C9E402643BB524263CDE7A0172971056F1D7E650220296BD08642719E778D24585AB127BA851E61C450A50CDA0EDF7D1AD8EF933DFE",
+ "hash" : "026E1CAD09FD1B4508839377D2C27A34D99E61173ACEAC021171424938E2B662",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rUTEn2jLLv4ESmrUqQmhZfEfDN3LorhgvZ",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9280923,
+ "Sequence" : 9280927,
+ "SigningPubKey" : "021C987881039AD42AEC336FB8460F1B1F4DDF0839CAF3EAB1AF69DDF8012C30A3",
+ "TakerGets" : "18779187610",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "28975.72310791101"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100A9735BBF6E757AC5E07FCE16C55B8901634EAC43F16F21B1493B689B7F0234FD0220614053BEA47C68930BA3CF262E961CBFF4A71E4C16AB1EE30F345359F3C858E2",
+ "hash" : "BB4F12026FD5B635A9CE1C1A3DB2DC23F1011082CA431E911940B63A8F393607",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rUTEn2jLLv4ESmrUqQmhZfEfDN3LorhgvZ",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9280922,
+ "Sequence" : 9280926,
+ "SigningPubKey" : "021C987881039AD42AEC336FB8460F1B1F4DDF0839CAF3EAB1AF69DDF8012C30A3",
+ "TakerGets" : "8181267030",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "12288.01764167985"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "3045022100DC085D453E9F106E0C23F6EFBFB35AB7476847EF145113CC585EDFF7B622285102200FBDAF12422AA49C71BCA805A94207D2C6C85AAF0DF3ADA2131139273FEE0065",
+ "hash" : "2C7EB89FD617EC0ACC4608141F6C6588DD5C28CD8BD545F2758D778E445B9F39",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rUTEn2jLLv4ESmrUqQmhZfEfDN3LorhgvZ",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9280921,
+ "Sequence" : 9280925,
+ "SigningPubKey" : "021C987881039AD42AEC336FB8460F1B1F4DDF0839CAF3EAB1AF69DDF8012C30A3",
+ "TakerGets" : "5483852556",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "8011.744069983915"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "30440220235009358985925D4F5A29FBB650585A949C4299B597E59F944C2F9A7F465F04022067A9D52CE7668EDDFD23CD0A549C614BDBC7E3CBCE1DAFCDAA6617985F22AF5A",
+ "hash" : "3D549BE1E3F76B04F353A8D2984FA8E5285F845D62595A881956133578AAE7F6",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ },
+ {
+ "Account" : "rUTEn2jLLv4ESmrUqQmhZfEfDN3LorhgvZ",
+ "Fee" : "12",
+ "Flags" : 0,
+ "LastLedgerSequence" : 56845614,
+ "OfferSequence" : 9280920,
+ "Sequence" : 9280924,
+ "SigningPubKey" : "021C987881039AD42AEC336FB8460F1B1F4DDF0839CAF3EAB1AF69DDF8012C30A3",
+ "TakerGets" : "18161813563",
+ "TakerPays" : {
+ "currency" : "CNY",
+ "issuer" : "rJ1adrpGS3xsnQMb9Cw54tWJVFPuSdZHK",
+ "value" : "25789.23040606686"
+ },
+ "TransactionType" : "OfferCreate",
+ "TxnSignature" : "30440220556320ADCF85CCA130B3DCB4579ADEBE4C9792580574DD53FF51F5CFD805BACE0220448BE61C8521C42012B23C15394991C29AE9EA2E971FDD9EB197165291FB6F5A",
+ "hash" : "295833386FF9A419EE7CE81758CD16E9D6DE61E3A8618BD052FE1D548BA920E1",
+ "inLedger" : 56845612,
+ "ledger_index" : 56845612
+ }
+ ]
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following fields:
diff --git a/content/references/rippled-api/public-rippled-methods/utility-methods/random.md b/content/references/rippled-api/public-rippled-methods/utility-methods/random.md
index d960318806..5a863fc5af 100644
--- a/content/references/rippled-api/public-rippled-methods/utility-methods/random.md
+++ b/content/references/rippled-api/public-rippled-methods/utility-methods/random.md
@@ -70,6 +70,17 @@ An example of a successful response:
}
```
+*Commandline*
+
+```json
+{
+ "result" : {
+ "random" : "DB7C23C7F224CD410912E68A997BE0FD0FA7175A4C74B829BE5A80ED0DBAA0C5",
+ "status" : "success"
+ }
+}
+```
+
The response follows the [standard format][], with a successful result containing the following field:
diff --git a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md
index 34d8ea7a7b..7c1995c246 100644
--- a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md
+++ b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md
@@ -4,10 +4,10 @@ Tracks the progress of the [amendment process](amendments.html#amendment-process
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
-| Field | JSON Type | [Internal Type][] | Description |
-|:---------------|:----------|:------------------|:----------------------------|
-| Amendment | String | Hash256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](amendments.html) for a list of known amendments. |
-| LedgerSequence | Number | UInt32 | The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
+| Field | JSON Type | [Internal Type][] | Description |
+|:-----------------|:----------|:------------------|:--------------------------|
+| `Amendment` | String | Hash256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](amendments.html) for a list of known amendments. |
+| `LedgerSequence` | Number | UInt32 | The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
## EnableAmendment Flags
@@ -15,10 +15,10 @@ The `Flags` value of the EnableAmendment pseudo-transaction indicates the status
A `Flags` value of `0` (no flags) indicates that the amendment has been enabled, and applies to all ledgers afterward. Other `Flags` values are as follows:
-| Flag Name | Hex Value | Decimal Value | Description |
-|:---------------|:-----------|:--------------|:-------------------------------|
-| tfGotMajority | 0x00010000 | 65536 | Support for this amendment increased to at least 80% of trusted validators starting with this ledger version. |
-| tfLostMajority | 0x00020000 | 131072 | Support for this amendment decreased to less than 80% of trusted validators starting with this ledger version. |
+| Flag Name | Hex Value | Decimal Value | Description |
+|:-----------------|:-------------|:--------------|:---------------------------|
+| `tfGotMajority` | `0x00010000` | 65536 | Support for this amendment increased to at least 80% of trusted validators starting with this ledger version. |
+| `tfLostMajority` | `0x00020000` | 131072 | Support for this amendment decreased to less than 80% of trusted validators starting with this ledger version. |
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md
index b3d7927790..b27a847160 100644
--- a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md
+++ b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md
@@ -4,10 +4,10 @@ Pseudo-Transactions are never submitted by users, nor propagated through the net
Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:
-| Field | Default Value |
-|:--------------|:---------------------------------------------------------|
-| Account | [ACCOUNT_ZERO](accounts.html#special-addresses) |
-| Sequence | 0 |
-| Fee | 0 |
-| SigningPubKey | "" |
-| Signature | "" |
+| Field | Default Value |
+|:----------------|:--------------------------------------------------|
+| `Account` | [ACCOUNT_ZERO](accounts.html#special-addresses) |
+| `Sequence` | `0` |
+| `Fee` | `0` |
+| `SigningPubKey` | `""` |
+| `Signature` | `""` |
diff --git a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md
index 572cb8c4c7..6ba5c6d187 100644
--- a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md
+++ b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md
@@ -21,13 +21,13 @@ A change in [transaction cost](transaction-cost.html) or [account reserve](reser
}
```
-| Field | JSON Type | [Internal Type][] | Description |
-|:------------------|:-----------------|:------------------|:------------------|
-| BaseFee | String | UInt64 | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](transaction-cost.html) before scaling for load.) |
-| ReferenceFeeUnits | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction |
-| ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops |
-| ReserveIncrement | Unsigned Integer | UInt32 | The incremental reserve, in drops |
-| LedgerSequence | Number | UInt32 | _(Omitted for some historical `SetFee` pseudo-transactions)_ The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
+| Field | JSON Type | [Internal Type][] | Description |
+|:--------------------|:-----------------|:------------------|:----------------|
+| `BaseFee` | String | UInt64 | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](transaction-cost.html) before scaling for load.) |
+| `ReferenceFeeUnits` | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction |
+| `ReserveBase` | Unsigned Integer | UInt32 | The base reserve, in drops |
+| `ReserveIncrement` | Unsigned Integer | UInt32 | The incremental reserve, in drops |
+| `LedgerSequence` | Number | UInt32 | _(Omitted for some historical `SetFee` pseudo-transactions)_ The index of the ledger version where this pseudo-transaction appears. This distinguishes the pseudo-transaction from other occurrences of the same change. |
{% include '_snippets/setfee_uniqueness_note.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-common-fields.md b/content/references/rippled-api/transaction-formats/transaction-common-fields.md
index 3ce48661c7..cc22130212 100644
--- a/content/references/rippled-api/transaction-formats/transaction-common-fields.md
+++ b/content/references/rippled-api/transaction-formats/transaction-common-fields.md
@@ -2,35 +2,33 @@
Every transaction has the same set of common fields, plus additional fields based on the [transaction type](transaction-types.html). Field names are case-sensitive. The common fields for all transactions are:
-| Field | JSON Type | [Internal Type][] | Description |
-|:-------------------|:-----------------|:------------------|:-----------------|
-| Account | String | Account | _(Required)_ The unique address of the [account](accounts.html) that initiated the transaction. |
-| TransactionType | String | UInt16 | _(Required)_ The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `AccountDelete`, `SetRegularKey`, `SignerListSet`, `EscrowCreate`, `EscrowFinish`, `EscrowCancel`, `PaymentChannelCreate`, `PaymentChannelFund`, `PaymentChannelClaim`, and `DepositPreauth`. |
-| Fee | String | Amount | _(Required; [auto-fillable][])_ Integer amount of XRP, in drops, to be destroyed as a cost for distributing this transaction to the network. Some transaction types have different minimum requirements. See [Transaction Cost][] for details. |
-| Sequence | Unsigned Integer | UInt32 | _(Required; [auto-fillable][])_ The [sequence number](basic-data-types.html#account-sequence) of the account sending the transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the previous transaction from the same account. |
-| [AccountTxnID][] | String | Hash256 | _(Optional)_ Hash value identifying another transaction. If provided, this transaction is only valid if the sending account's previously-sent transaction matches the provided hash. |
-| [Flags][] | Unsigned Integer | UInt32 | _(Optional)_ Set of bit-flags for this transaction. |
-| LastLedgerSequence | Number | UInt32 | _(Optional; strongly recommended)_ Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected. See [Reliable Transaction Submission](reliable-transaction-submission.html) for more details. |
-| [Memos][] | Array of Objects | Array | _(Optional)_ Additional arbitrary information used to identify this transaction. |
-| [Signers][] | Array | Array | _(Optional)_ Array of objects that represent a [multi-signature](multi-signing.html) which authorizes this transaction. |
-| SourceTag | Unsigned Integer | UInt32 | _(Optional)_ Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
-| SigningPubKey | String | Blob | _(Automatically added when signing)_ Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
-| TxnSignature | String | Blob | _(Automatically added when signing)_ The signature that verifies this transaction as originating from the account it says it is from. |
+| Field | JSON Type | [Internal Type][] | Description |
+|:---------------------|:-----------------|:------------------|:-----------------|
+| `Account` | String | Account | _(Required)_ The unique address of the [account](accounts.html) that initiated the transaction. |
+| `TransactionType` | String | UInt16 | _(Required)_ The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, `AccountDelete`, `SetRegularKey`, `SignerListSet`, `EscrowCreate`, `EscrowFinish`, `EscrowCancel`, `PaymentChannelCreate`, `PaymentChannelFund`, `PaymentChannelClaim`, and `DepositPreauth`. |
+| `Fee` | String | Amount | _(Required; [auto-fillable][])_ Integer amount of XRP, in drops, to be destroyed as a cost for distributing this transaction to the network. Some transaction types have different minimum requirements. See [Transaction Cost][] for details. |
+| `Sequence` | Number | UInt32 | _(Required; [auto-fillable][])_ The [sequence number](basic-data-types.html#account-sequence) of the account sending the transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the previous transaction from the same account. |
+| [`AccountTxnID`](#accounttxnid) | String | Hash256 | _(Optional)_ Hash value identifying another transaction. If provided, this transaction is only valid if the sending account's previously-sent transaction matches the provided hash. |
+| [`Flags`](#flags-field) | Number | UInt32 | _(Optional)_ Set of bit-flags for this transaction. |
+| `LastLedgerSequence` | Number | UInt32 | _(Optional; strongly recommended)_ Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected. See [Reliable Transaction Submission](reliable-transaction-submission.html) for more details. |
+| [`Memos`](#memos-field) | Array of Objects | Array | _(Optional)_ Additional arbitrary information used to identify this transaction. |
+| [`Signers`](#signers-field) | Array | Array | _(Optional)_ Array of objects that represent a [multi-signature](multi-signing.html) which authorizes this transaction. |
+| `SourceTag` | Number | UInt32 | _(Optional)_ Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
+| `SigningPubKey` | String | Blob | _(Automatically added when signing)_ Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
+| `TxnSignature` | String | Blob | _(Automatically added when signing)_ The signature that verifies this transaction as originating from the account it says it is from. |
[auto-fillable]: #auto-fillable-fields
-[AccountTxnID]: #accounttxnid
-[Flags]: #flags-field
-[Memos]: #memos-field
-[Signers]: #signers-field
-[Removed in: rippled 0.28.0][]: The `PreviousTxnID` field of transactions was replaced by the [AccountTxnID][] field. This String / Hash256 field is present in some historical transactions. This is unrelated to the field also named `PreviousTxnID` in some [ledger objects](ledger-data-formats.html).
+[Removed in: rippled 0.28.0][]: The `PreviousTxnID` field of transactions was replaced by the [`AccountTxnID`](#accounttxnid) field. This String / Hash256 field is present in some historical transactions. This is unrelated to the field also named `PreviousTxnID` in some [ledger objects](ledger-data-formats.html).
## AccountTxnID
+
+
The `AccountTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one (by Sequence Number) is also valid and matches the transaction you expected.
-Unlike the `PreviousTxnID` field, which tracks the last transaction to _modify_ an account (regardless of sender), the `AccountTxnID` tracks the last transaction _sent by_ an account. To use AccountTxnID, you must first set the [asfAccountTxnID](accountset.html#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction. (`PreviousTxnID`, by comparison, is always tracked.)
+Unlike the `PreviousTxnID` field, which tracks the last transaction to _modify_ an account (regardless of sender), the `AccountTxnID` tracks the last transaction _sent by_ an account. To use `AccountTxnID`, you must first set the [`asfAccountTxnID`](accountset.html#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction. (`PreviousTxnID`, by comparison, is always tracked.)
One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially have serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `AccountTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.
@@ -66,13 +64,13 @@ Bits that are not defined as flags MUST be 0. (The [fix1543 amendment][] enforce
The only flag that applies globally to all transactions is as follows:
-| Flag Name | Hex Value | Decimal Value | Description |
-|:--------------------|:-----------|:--------------|:--------------------------|
-| tfFullyCanonicalSig | 0x80000000 | 2147483648 | _(Strongly recommended)_ Require a fully-canonical signature. |
+| Flag Name | Hex Value | Decimal Value | Description |
+|:----------------------|:-----------|:--------------|:--------------------------|
+| `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | _(Strongly recommended)_ Require a fully-canonical signature. |
When using the [sign method][] (or [submit method][] in "sign-and-submit" mode), `rippled` adds a `Flags` field with `tfFullyCanonicalSig` enabled unless the `Flags` field is already present. The `tfFullyCanonicalSig` flag ***is not*** automatically enabled if `Flags` is explicitly specified. The flag ***is not*** automatically enabled when using the [sign_for method][] to add a signature to a multi-signed transaction.
-**Warning:** If you do not enable `tfFullyCanonicalSig`, it is theoretically possible for a malicious actor to modify your transaction signature so that the transaction may succeed with a different hash than expected. In the worst case, this could [trick your integration into submitting the same payment multiple times](transaction-malleability.html#exploit-with-malleable-transactions). To avoid this problem, enable the `tfFullyCanonicalSig` flag on all transactions you sign. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all single-signed transactions are protected regardless of the tfFullyCanonicalSig flag.
+**Warning:** If you do not enable `tfFullyCanonicalSig`, it is theoretically possible for a malicious actor to modify your transaction signature so that the transaction may succeed with a different hash than expected. In the worst case, this could [trick your integration into submitting the same payment multiple times](transaction-malleability.html#exploit-with-malleable-transactions). To avoid this problem, enable the `tfFullyCanonicalSig` flag on all transactions you sign. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all single-signed transactions are protected regardless of the `tfFullyCanonicalSig` flag.
### Flag Ranges
@@ -91,19 +89,19 @@ A transaction's `Flags` field can contain flags that apply at different levels o
The `Memos` field includes arbitrary messaging data with the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields:
-| Field | Type | [Internal Type][] | Description |
-|:-----------|:-------|:------------------|:-----------------------------------|
-| MemoData | String | Blob | Arbitrary hex value, conventionally containing the content of the memo. |
-| MemoFormat | String | Blob | Hex value representing characters allowed in URLs. Conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml). |
-| MemoType | String | Blob | Hex value representing characters allowed in URLs. Conventionally, a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
+| Field | Type | [Internal Type][] | Description |
+|:-------------|:-------|:------------------|:---------------------------------|
+| `MemoData` | String | Blob | Arbitrary hex value, conventionally containing the content of the memo. |
+| `MemoFormat` | String | Blob | Hex value representing characters allowed in URLs. Conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml). |
+| `MemoType` | String | Blob | Hex value representing characters allowed in URLs. Conventionally, a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
-The MemoType and MemoFormat fields should only consist of the following characters: `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%`
+The `MemoType` and `MemoFormat` fields should only consist of the following characters: `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%`
-The `Memos` field is limited to no more than 1KB in size (when serialized in binary format).
+The `Memos` field is limited to no more than 1 KB in size (when serialized in binary format).
Example of a transaction with a Memos field:
-```
+```json
{
"TransactionType": "Payment",
"Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
@@ -125,13 +123,13 @@ Example of a transaction with a Memos field:
The `Signers` field contains a [multi-signature](multi-signing.html), which has signatures from up to 8 key pairs, that together should authorize the transaction. The `Signers` list is an array of objects, each with one field, `Signer`. The `Signer` field has the following nested fields:
-| Field | Type | [Internal Type][] | Description |
-|:--------------|:-------|:------------------|:--------------------------------|
-| Account | String | AccountID | The address associated with this signature, as it appears in the SignerList. |
-| TxnSignature | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. |
-| SigningPubKey | String | Blob | The public key used to create this signature. |
+| Field | Type | [Internal Type][] | Description |
+|:----------------|:-------|:------------------|:--------------------------------|
+| `Account` | String | AccountID | The address associated with this signature, as it appears in the signer list. |
+| `TxnSignature` | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. |
+| `SigningPubKey` | String | Blob | The public key used to create this signature. |
-The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the SigningPubKey can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [lsfDisableMaster](accountroot.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address.
+The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the `SigningPubKey` can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [`lsfDisableMaster`](accountroot.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address.
Because signature verification is a compute-intensive task, multi-signed transactions cost additional XRP to relay to the network. Each signature included in the multi-signature increases the [transaction cost][] required for the transaction. For example, if the current minimum transaction cost to relay a transaction to the network is `10000` drops, then a multi-signed transaction with 3 entries in the `Signers` array would need a `Fee` value of at least `40000` drops to relay.
diff --git a/content/references/rippled-api/transaction-formats/transaction-metadata.md b/content/references/rippled-api/transaction-formats/transaction-metadata.md
index f68e174aae..c73ec09994 100644
--- a/content/references/rippled-api/transaction-formats/transaction-metadata.md
+++ b/content/references/rippled-api/transaction-formats/transaction-metadata.md
@@ -44,7 +44,7 @@ A `DeletedNode` object contains the following fields:
|:------------------|:------------------|:-------------------------------------|
| `LedgerEntryType` | String | The [type of ledger object](ledger-object-types.html) that was deleted. |
| `LedgerIndex` | String - [Hash][] | The [ID of this ledger object](ledger-object-ids.html) in the ledger's [state tree](ledgers.html). **Note:** This is **not the same** as a [ledger index](basic-data-types.html#ledger-index), even though the field name is very similar. |
-| `FinalFields` | Object | The content fields of the ledger object just before it was deleted. Which fields are present depends on what type of ledger object was created. |
+| `FinalFields` | Object | The content fields of the ledger object immediately before it was deleted. Which fields are present depends on what type of ledger object was created. |
### ModifiedNode Fields
@@ -71,12 +71,15 @@ The `rippled` server provides a `delivered_amount` field in JSON transaction met
* Is a partial payment
* Included in a validated ledger before 2014-01-20
-If both conditions are true, then `delivered_amount` contains the string value `unavailable` instead of an actual amount. If this happens, you can only figure out the actual delivered amount by reading the AffectedNodes in the transaction's metadata.
+If both conditions are true, then `delivered_amount` contains the string value `unavailable` instead of an actual amount. If this happens, you can only figure out the actual delivered amount by reading the `AffectedNodes` in the transaction's metadata.
**Note:** The `delivered_amount` field is generated on-demand for the request, and is not included in the binary format for transaction metadata, nor is it used when calculating the [hash](basic-data-types.html#hashes) of the transaction metadata. In contrast, the `DeliveredAmount` field _is_ included in the binary format for partial payment transactions after 2014-01-20.
See also: [Partial Payments](partial-payments.html)
+
+
+
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
index f72b9ae9af..f10ea180cb 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
@@ -20,7 +20,7 @@ For the most part, transactions with `tec` codes take no action other than to de
| `tecINSUF_RESERVE_LINE` | 122 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See `tecNO_LINE_INSUF_RESERVE` for the other case.) |
| `tecINSUF_RESERVE_OFFER` | 123 | The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: [Reserves](reserves.html)) |
| `tecINSUFF_FEE` | 136 | The transaction failed because the sending account does not have enough XRP to pay the [transaction cost](transaction-cost.html) that it specified. (In this case, the transaction processing destroys all of the sender's XRP even though that amount is lower than the specified transaction cost.) This result only occurs if the account's balance decreases _after_ this transaction has been distributed to enough of the network to be included in a consensus set. Otherwise, the transaction fails with [`terINSUF_FEE_B`](ter-codes.html) before being distributed. |
-| `tecINSUFFICIENT_RESERVE` | 141 | The transaction would increase the [reserve requirement](reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See [SignerLists and Reserves](signerlist.html#signerlists-and-reserves) for more information. |
+| `tecINSUFFICIENT_RESERVE` | 141 | The transaction would increase the [reserve requirement](reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See [Signer Lists and Reserves](signerlist.html#signer-lists-and-reserves) for more information. |
| `tecINTERNAL` | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tecNEED_MASTER_KEY` | 142 | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). [New in: rippled 0.28.0][] |
@@ -30,7 +30,7 @@ For the most part, transactions with `tec` codes take no action other than to de
| `tecNO_DST_INSUF_XRP` | 125 | The account on the receiving end of the transaction does not exist, and the transaction is not sending enough XRP to create it. |
| `tecNO_ENTRY` | 140 | Reserved for future use. |
| `tecNO_ISSUER` | 133 | The account specified in the `issuer` field of a currency amount does not exist. |
-| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the tfFillOrKill flag and could not be filled, so it was killed. _(Added by the [fix1578 amendment][].)_ |
+| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the `tfFillOrKill` flag and could not be filled, so it was killed. _(Added by the [fix1578 amendment][].)_ |
| `tecNO_LINE` | 135 | The `TakerPays` field of the [OfferCreate transaction][] specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. |
| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) |
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
index 2880535ed7..4033791876 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
@@ -1,4 +1,5 @@
# tef Codes
+
These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range -199 to -100. The exact code for any given error is subject to change, so don't rely on it.
@@ -20,7 +21,7 @@ These codes indicate that the transaction failed and was not included in a ledge
| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](transaction-cost.html). Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tefMASTER_DISABLED` | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. |
| `tefMAX_LEDGER` | The transaction included a [`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. |
-| `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. |
+| `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trust line as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. |
| `tefNOT_MULTI_SIGNING` | The transaction was [multi-signed](multi-signing.html), but the sending account has no SignerList defined. |
| `tefPAST_SEQ` | The sequence number of the transaction is lower than the current sequence number of the account sending the transaction. |
| `tefTOO_BIG` | The transaction would affect too many objects in the ledger. For example, this was an [AccountDelete transaction][] but the account to be deleted owns over 1000 objects in the ledger. |
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md
index 1d158fcd39..a0d9e8c7ee 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md
@@ -11,14 +11,14 @@ These codes indicate an error in the local server processing the transaction; it
| `telBAD_PUBLIC_KEY` | The transaction specified a public key value (for example, as the `MessageKey` field of an [AccountSet transaction][]) that cannot be used, probably because it is too long. |
| `telCAN_NOT_QUEUE` | The transaction did not meet the [open ledger cost](transaction-cost.html), but this server did not queue this transaction because it did not meet the [queuing restrictions](transaction-queue.html#queuing-restrictions). For example, a transaction returns this code when the sender already has 10 other transactions in the queue. You can try again later or sign and submit a replacement transaction with a higher transaction cost in the `Fee` field. |
| `telCAN_NOT_QUEUE_BALANCE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because the sum of potential XRP costs of already-queued transactions is greater than the expected balance of the account. You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] |
-| `telCAN_NOT_QUEUE_BLOCKS` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] |
-| `telCAN_NOT_QUEUE_BLOCKED` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] |
+| `telCAN_NOT_QUEUE_BLOCKS` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the `RequireAuth`/`OptionalAuth`, `DisableMaster`, or `AccountTxnID` flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] |
+| `telCAN_NOT_QUEUE_BLOCKED` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the `RequireAuth`/`OptionalAuth`, `DisableMaster`, or `AccountTxnID` flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_FEE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This code occurs when a transaction with the same sender and sequence number already exists in the queue and the new one does not pay a large enough transaction cost to replace the existing transaction. To replace a transaction in the queue, the new transaction must have a `Fee` value that is at least 25% more, as measured in [fee levels](transaction-cost.html#fee-levels). You can increase the `Fee` and try again, send this with a higher `Sequence` number so it doesn't replace an existing transaction, or try sending to another server. [New in: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_FULL` | The transaction did not meet the [open ledger cost](transaction-cost.html) and the server did not queue this transaction because this server's transaction queue is full. You could increase the `Fee` and try again, try again later, or try submitting to a different server. The new transaction must have a higher transaction cost, as measured in [fee levels](transaction-cost.html#fee-levels), than the transaction in the queue with the smallest transaction cost. [New in: rippled 0.70.2][] |
| `telFAILED_PROCESSING` | An unspecified error occurred when processing the transaction. |
| `telINSUF_FEE_P` | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](transaction-cost.html) requirement, which is derived from its load level. |
| `telLOCAL_ERROR` | Unspecified local error. |
-| `telNO_DST`_`PARTIAL` | The transaction is an XRP payment that would fund a new account, but the [tfPartialPayment flag](partial-payments.html) was enabled. This is disallowed. |
+| `telNO_DST`_`PARTIAL` | The transaction is an XRP payment that would fund a new account, but the [`tfPartialPayment` flag](partial-payments.html) was enabled. This is disallowed. |
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md
index 41d97904c9..d60e29020e 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md
@@ -12,17 +12,17 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
| `temBAD_EXPIRATION` | The transaction improperly specified an expiration value, for example as part of an [OfferCreate transaction][]. Alternatively, the transaction did not specify a required expiration value, for example as part of an [EscrowCreate transaction][]. |
| `temBAD_FEE` | The transaction improperly specified its `Fee` value, for example by listing a non-XRP currency or some negative amount of XRP. |
| `temBAD_ISSUER` | The transaction improperly specified the `issuer` field of some currency included in the request. |
-| `temBAD_LIMIT` | The [TrustSet transaction][] improperly specified the `LimitAmount` value of a trustline. |
+| `temBAD_LIMIT` | The [TrustSet transaction][] improperly specified the `LimitAmount` value of a trust line. |
| `temBAD_OFFER` | The [OfferCreate transaction][] specifies an invalid offer, such as offering to trade XRP for itself, or offering a negative amount. |
| `temBAD_PATH` | The [Payment transaction][] specifies one or more [Paths](paths.html) improperly, for example including an issuer for XRP, or specifying an account differently. |
| `temBAD_PATH_LOOP` | One of the [Paths](paths.html) in the [Payment transaction][] was flagged as a loop, so it cannot be processed in a bounded amount of time. |
-| `temBAD_SEND_XRP_LIMIT` | The [Payment transaction][] used the [tfLimitQuality](payment.html#limit-quality) flag in a direct XRP-to-XRP payment, even though XRP-to-XRP payments do not involve any conversions. |
-| `temBAD_SEND_XRP_MAX` | The [Payment transaction][] included a `SendMax` field in a direct XRP-to-XRP payment, even though sending XRP should never require SendMax. (XRP is only valid in SendMax if the destination `Amount` is not XRP.) |
-| `temBAD_SEND_XRP_NO_DIRECT` | The [Payment transaction][] used the [tfNoDirectRipple](payment.html#payment-flags) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments are always direct. |
-| `temBAD_SEND_XRP_PARTIAL` | The [Payment transaction][] used the [tfPartialPayment](partial-payments.html) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments should always deliver the full amount. |
+| `temBAD_SEND_XRP_LIMIT` | The [Payment transaction][] used the [`tfLimitQuality` flag](payment.html#limit-quality) in a direct XRP-to-XRP payment, even though XRP-to-XRP payments do not involve any conversions. |
+| `temBAD_SEND_XRP_MAX` | The [Payment transaction][] included a `SendMax` field in a direct XRP-to-XRP payment, even though sending XRP should never require `SendMax`. (XRP is only valid in `SendMax` if the destination `Amount` is not XRP.) |
+| `temBAD_SEND_XRP_NO_DIRECT` | The [Payment transaction][] used the [`tfNoDirectRipple` flag](payment.html#payment-flags) for a direct XRP-to-XRP payment, even though XRP-to-XRP payments are always direct. |
+| `temBAD_SEND_XRP_PARTIAL` | The [Payment transaction][] used the [`tfPartialPayment` flag](partial-payments.html) for a direct XRP-to-XRP payment, even though XRP-to-XRP payments should always deliver the full amount. |
| `temBAD_SEND_XRP_PATHS` | The [Payment transaction][] included `Paths` while sending XRP, even though XRP-to-XRP payments should always be direct. |
| `temBAD_SEQUENCE` | The transaction is references a sequence number that is higher than its own `Sequence` number, for example trying to cancel an offer that would have to be placed after the transaction that cancels it. |
-| `temBAD_SIGNATURE` | The signature to authorize this transaction is either missing, or formed in a way that is not a properly-formed signature. (See [tecNO_PERMISSION](tec-codes.html) for the case where the signature is properly formed, but not authorized for this account.) |
+| `temBAD_SIGNATURE` | The signature to authorize this transaction is either missing, or formed in a way that is not a properly-formed signature. (See [`tecNO_PERMISSION`](tec-codes.html) for the case where the signature is properly formed, but not authorized for this account.) |
| `temBAD_SRC_ACCOUNT` | The `Account` on whose behalf this transaction is being sent (the "source account") is not a properly-formed [account](accounts.html) address. |
| `temBAD_TRANSFER_RATE` | The [`TransferRate` field of an AccountSet transaction](accountset.html#transferrate) is not properly formatted or out of the acceptable range. |
| `temCANNOT_PREAUTH_SELF` | The sender of the [DepositPreauth transaction][] was also specified as the account to preauthorize. You cannot preauthorize yourself. |
diff --git a/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md b/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md
index 335b74d7e2..0e93ee8b65 100644
--- a/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md
+++ b/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md
@@ -4,14 +4,14 @@
The `rippled` server summarizes transaction results with result codes, which appear in fields such as `engine_result` and `meta.TransactionResult`. These codes are grouped into several categories of with different prefixes:
-| Category | Prefix | Description |
-|:----------------------|:------------------------|:---------------------------|
-| Claimed cost only | [tec](tec-codes.html) | The transaction did not achieve its intended purpose, but the [transaction cost](transaction-cost.html) was destroyed. This result is only final in a validated ledger. |
-| Failure | [tef](tef-codes.html) | The transaction cannot be applied to the server's current (in-progress) ledger or any later one. It may have already been applied, or the condition of the ledger makes it impossible to apply in the future. |
-| Local error | [tel](tel-codes.html) | The `rippled` server had an error due to local conditions, such as high load. You may get a different response if you resubmit to a different server or at a different time. |
-| Malformed transaction | [tem](tem-codes.html) | The transaction was not valid, due to improper syntax, conflicting options, a bad signature, or something else. |
-| Retry | [ter](ter-codes.html) | The transaction could not be applied, but it could apply successfully in a future ledger. |
-| Success | [tes](tes-success.html) | (Not an error) The transaction succeeded. This result only final in a validated ledger. |
+| Category | Prefix | Description |
+|:----------------------|:--------------------------|:-------------------------|
+| Claimed cost only | [`tec`](tec-codes.html) | The transaction did not achieve its intended purpose, but the [transaction cost](transaction-cost.html) was destroyed. This result is only final in a validated ledger. |
+| Failure | [`tef`](tef-codes.html) | The transaction cannot be applied to the server's current (in-progress) ledger or any later one. It may have already been applied, or the condition of the ledger makes it impossible to apply in the future. |
+| Local error | [`tel`](tel-codes.html) | The `rippled` server had an error due to local conditions, such as high load. You may get a different response if you resubmit to a different server or at a different time. |
+| Malformed transaction | [`tem`](tem-codes.html) | The transaction was not valid, due to improper syntax, conflicting options, a bad signature, or something else. |
+| Retry | [`ter`](ter-codes.html) | The transaction could not be applied, but it could apply successfully in a future ledger. |
+| Success | [`tes`](tes-success.html) | (Not an error) The transaction succeeded. This result only final in a validated ledger. |
The `rippled` server automatically retries failed transactions. It is important not to assume that a transaction has completely failed based on a tentative failure result. A transaction may later succeed unless its success or failure is [final](finality-of-results.html).
@@ -30,8 +30,8 @@ The response from `submit` contains the following fields:
| Field | Value | Description |
|:------------------------|:---------------|:----------------------------------|
-| `engine_result` | String | A code that categorizes the result, such as `tecPATH_DRY` |
-| `engine_result_code` | Signed Integer | A number that corresponds to the `engine_result`, although exact values are subject to change. |
+| `engine_result` | String | A code indicating the outcome of the transaction, such as `tecPATH_DRY`. |
+| `engine_result_code` | Signed Integer | A number that corresponds to the `engine_result`. The exact values are subject to change without notice. |
| `engine_result_message` | String | A human-readable message explaining what happened. This message is intended for developers to diagnose problems, and is subject to change without notice. |
If nothing went wrong when submitting and applying the transaction locally, the response looks like this:
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md
index 99514d06da..3560aba540 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md
@@ -24,21 +24,15 @@ An AccountSet transaction modifies the properties of an [account in the XRP Ledg
| Field | JSON Type | [Internal Type][] | Description |
|:-----------------|:-----------------|:------------------|:-------------------|
-| [ClearFlag][] | Number | UInt32 | _(Optional)_ Unique identifier of a flag to disable for this account. |
-| [Domain][] | String | Blob | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
-| EmailHash | String | Hash128 | _(Optional)_ Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
-| MessageKey | String | Blob | _(Optional)_ Public key for sending encrypted messages to this account. |
-| [SetFlag][] | Number | UInt32 | _(Optional)_ Integer flag to enable for this account. |
-| [TransferRate][] | Unsigned Integer | UInt32 | _(Optional)_ The fee to charge when users transfer this account's issued currencies, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
-| [TickSize][] | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Added by the [TickSize amendment][].)_ |
-| WalletLocator | String | Hash256 | _(Optional)_ Not used. |
-| WalletSize | Number | UInt32 | _(Optional)_ Not used. |
-
-[ClearFlag]: #accountset-flags
-[Domain]: #domain
-[SetFlag]: #accountset-flags
-[TickSize]: ticksize.html
-[TransferRate]: accountset.html#transferrate
+| [`ClearFlag`](#accountset-flags) | Number | UInt32 | _(Optional)_ Unique identifier of a flag to disable for this account. |
+| [Domain](#domain) | String | Blob | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
+| `EmailHash` | String | Hash128 | _(Optional)_ Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
+| `MessageKey` | String | Blob | _(Optional)_ Public key for sending encrypted messages to this account. |
+| [`SetFlag`](#accountset-flags) | Number | UInt32 | _(Optional)_ Integer flag to enable for this account. |
+| [`TransferRate`](#transferrate) | Number | UInt32 | _(Optional)_ The fee to charge when users transfer this account's issued currencies, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
+| [`TickSize`](ticksize.html) | Number | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Added by the [TickSize amendment][].)_ |
+| `WalletLocator` | String | Hash256 | _(Optional)_ Not used. |
+| `WalletSize` | Number | UInt32 | _(Optional)_ Not used. |
If none of these options are provided, then the AccountSet transaction has no effect (beyond destroying the transaction cost). See [Cancel or Skip a Transaction](cancel-or-skip-a-transaction.html) for more details.
@@ -57,40 +51,40 @@ You can put any domain in your account's `Domain` field. To prove that an accoun
There are several options which can be either enabled or disabled for an account. Account options are represented by different types of flags depending on the situation:
-* The `AccountSet` transaction type has several "AccountSet Flags" (prefixed **asf**) that can enable an option when passed as the `SetFlag` parameter, or disable an option when passed as the `ClearFlag` parameter.
-* The `AccountSet` transaction type has several transaction flags (prefixed **tf**) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is discouraged. New account options do not have corresponding transaction (tf) flags.
-* The `AccountRoot` ledger object type has several ledger-specific-flags (prefixed **lsf**) which represent the state of particular account options within a particular ledger. These settings apply until a transaction changes them.
+* The `AccountSet` transaction type has several "AccountSet Flags" (prefixed **`asf`**) that can enable an option when passed as the `SetFlag` parameter, or disable an option when passed as the `ClearFlag` parameter.
+* The `AccountSet` transaction type has several transaction flags (prefixed **`tf`**) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is discouraged. New account options do not have corresponding transaction (`tf`) flags.
+* The `AccountRoot` ledger object type has several ledger-state-flags (prefixed **`lsf`**) which represent the state of particular account options within a particular ledger. These settings apply until a transaction changes them.
-The preferred way to enable and disable Account Flags is using the `SetFlag` and `ClearFlag` parameters of an AccountSet transaction. AccountSet flags have names that begin with **asf**.
+The preferred way to enable and disable Account Flags is using the `SetFlag` and `ClearFlag` parameters of an AccountSet transaction. AccountSet flags have names that begin with **`asf`**.
All flags are disabled by default.
The available AccountSet flags are:
-| Flag Name | Decimal Value | Corresponding Ledger Flag | Description |
-|:-----------------|:--------------|:--------------------------|:--------------|
-| asfAccountTxnID | 5 | (None) | Track the ID of this account's most recent transaction. Required for [AccountTxnID](transaction-common-fields.html#accounttxnid) |
-| asfDefaultRipple | 8 | lsfDefaultRipple | Enable [rippling](rippling.html) on this account's trust lines by default. [New in: rippled 0.27.3][] |
-| asfDepositAuth | 9 | lsfDepositAuth | Enable [Deposit Authorization](depositauth.html) on this account. _(Added by the [DepositAuth amendment][].)_ |
-| asfDisableMaster | 4 | lsfDisableMaster | Disallow use of the master key pair. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](cryptographic-keys.html) or a [Signer List](multi-signing.html). |
-| asfDisallowXRP | 3 | lsfDisallowXRP | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) |
-| asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](freezes.html) all assets issued by this account. |
-| asfNoFreeze | 6 | lsfNoFreeze | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](freezes.html). This flag can never be disabled after being enabled. |
-| asfRequireAuth | 2 | lsfRequireAuth | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. |
-| asfRequireDest | 1 | lsfRequireDestTag | Require a destination tag to send transactions to this account. |
+| Flag Name | Decimal Value | Corresponding Ledger Flag | Description |
+|:-------------------|:--------------|:--------------------------|:--------------|
+| `asfAccountTxnID` | 5 | (None) | Track the ID of this account's most recent transaction. Required for [`AccountTxnID`](transaction-common-fields.html#accounttxnid) |
+| `asfDefaultRipple` | 8 | `lsfDefaultRipple` | Enable [rippling](rippling.html) on this account's trust lines by default. [New in: rippled 0.27.3][] |
+| `asfDepositAuth` | 9 | `lsfDepositAuth` | Enable [Deposit Authorization](depositauth.html) on this account. _(Added by the [DepositAuth amendment][].)_ |
+| `asfDisableMaster` | 4 | `lsfDisableMaster` | Disallow use of the master key pair. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](cryptographic-keys.html) or a [Signer List](multi-signing.html). |
+| `asfDisallowXRP` | 3 | `lsfDisallowXRP` | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) |
+| `asfGlobalFreeze` | 7 | `lsfGlobalFreeze` | [Freeze](freezes.html) all assets issued by this account. |
+| `asfNoFreeze` | 6 | `lsfNoFreeze` | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](freezes.html). This flag can never be disabled after being enabled. |
+| `asfRequireAuth` | 2 | `lsfRequireAuth` | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. |
+| `asfRequireDest` | 1 | `lsfRequireDestTag` | Require a destination tag to send transactions to this account. |
To enable the `asfDisableMaster` or `asfNoFreeze` flags, you must [authorize the transaction](transaction-basics.html#authorizing-transactions) by signing it with the master key pair. You cannot use a regular key pair or a multi-signature. You can disable `asfDisableMaster` (that is, re-enable the master key pair) using a regular key pair or multi-signature. [New in: rippled 0.28.0][]
The following [Transaction flags](transaction-common-fields.html#flags-field), specific to the AccountSet transaction type, serve the same purpose, but are discouraged:
-| Flag Name | Hex Value | Decimal Value | Replaced by AccountSet Flag |
-|:------------------|:-----------|:--------------|:----------------------------|
-| tfRequireDestTag | 0x00010000 | 65536 | asfRequireDest (SetFlag) |
-| tfOptionalDestTag | 0x00020000 | 131072 | asfRequireDest (ClearFlag) |
-| tfRequireAuth | 0x00040000 | 262144 | asfRequireAuth (SetFlag) |
-| tfOptionalAuth | 0x00080000 | 524288 | asfRequireAuth (ClearFlag) |
-| tfDisallowXRP | 0x00100000 | 1048576 | asfDisallowXRP (SetFlag) |
-| tfAllowXRP | 0x00200000 | 2097152 | asfDisallowXRP (ClearFlag) |
+| Flag Name | Hex Value | Decimal Value | Replaced by AccountSet Flag |
+|:--------------------|:-------------|:--------------|:----------------------------|
+| `tfRequireDestTag` | `0x00010000` | 65536 | `asfRequireDest` (`SetFlag`) |
+| `tfOptionalDestTag` | `0x00020000` | 131072 | `asfRequireDest` (`ClearFlag`) |
+| `tfRequireAuth` | `0x00040000` | 262144 | `asfRequireAuth` (`SetFlag`) |
+| `tfOptionalAuth` | `0x00080000` | 524288 | `asfRequireAuth` (`ClearFlag`) |
+| `tfDisallowXRP` | `0x00100000` | 1048576 | `asfDisallowXRP` (`SetFlag`) |
+| `tfAllowXRP` | `0x00200000` | 2097152 | `asfDisallowXRP` (`ClearFlag`) |
**Caution:** The numeric values of `tf` and `asf` flags in transactions do not match up with the values they set in the accounts "at rest" in the ledger. To read the flags of an account in the ledger, see [`AccountRoot` flags](accountroot.html#accountroot-flags).
@@ -105,9 +99,11 @@ You can protect against unwanted incoming payments for non-XRP currencies by not
## TransferRate
-The TransferRate field specifies a fee to charge whenever counterparties transfer the currency you issue. See [Transfer Fees](transfer-fees.html) for more information.
+The `TransferRate` field specifies a fee to charge whenever counterparties transfer the currency you issue. See [Transfer Fees](transfer-fees.html) for more information.
-In `rippled`'s WebSocket and JSON-RPC APIs, the TransferRate is represented as an integer, the amount that must be sent for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value `1200000000`. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify 0 as a shortcut for 1000000000, meaning no fee.
+In `rippled`'s WebSocket and JSON-RPC APIs, the transfer fee is represented as an integer, the amount that must be sent for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value `1200000000`. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify 0 as a shortcut for 1000000000, meaning no fee.
+
+
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
index 88037af138..9da3042568 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
@@ -35,7 +35,7 @@ The transaction ***must*** include either `Amount` or `DeliverMin`, but not both
- If the sender of the CheckCash transaction is not the `Destination` of the check, the transaction fails with the result code `tecNO_PERMISSION`.
- If the Check identified by the `CheckID` field does not exist, the transaction fails with the result `tecNO_ENTRY`.
- If the Check identified by the `CheckID` field has already expired, the transaction fails with the result `tecEXPIRED`.
-- If the destination of the Check has the RequireDest flag enabled but the Check, as created, does not have a destination tag, the transaction fails with the result code `tecDST_TAG_NEEDED`.
+- If the destination of the Check has the `RequireDest` flag enabled but the Check, as created, does not have a destination tag, the transaction fails with the result code `tecDST_TAG_NEEDED`.
- If the transaction specifies both `Amount` and `DeliverMin`, or omits both, the transaction fails with the result `temMALFORMED`.
- If the `Amount` or `DeliverMin` does not match the currency (and issuer, if not XRP) of the Check, the transaction fails with the result `temBAD_CURRENCY`.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
index 1c0ba7e651..429ba9fa87 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
@@ -35,7 +35,7 @@ Create a Check object in the ledger, which is a deferred payment that can be cas
- If the `Destination` is the sender of the transaction, the transaction fails with the result code `temREDUNDANT`.
- If the `Destination` [account](accounts.html) does not exist in the ledger, the transaction fails with the result code `tecNO_DST`.
-- If the `Destination` account has the RequireDest flag enabled but the transaction does not include a `DestinationTag` field, the transaction fails with the result code `tecDST_TAG_NEEDED`.
+- If the `Destination` account has the `RequireDest` flag enabled but the transaction does not include a `DestinationTag` field, the transaction fails with the result code `tecDST_TAG_NEEDED`.
- If `SendMax` specifies an issued currency which is [frozen](freezes.html), the transaction fails with the result `tecFROZEN`.
- If the `Expiration` of the transaction is in the past, the transaction fails with the result `tecEXPIRED`.
- If the sender does not have enough XRP to meet the [owner reserve](reserves.html#owner-reserves) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`.
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/offercancel.md b/content/references/rippled-api/transaction-formats/transaction-types/offercancel.md
index 9fbac50a77..e201d6876a 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/offercancel.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/offercancel.md
@@ -22,13 +22,13 @@ An OfferCancel transaction removes an Offer object from the XRP Ledger.
-| Field | JSON Type | [Internal Type][] | Description |
-|:--------------|:----------|:------------------|:-----------------------------|
-| OfferSequence | Number | UInt32 | The sequence number of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
+| Field | JSON Type | [Internal Type][] | Description |
+|:----------------|:----------|:------------------|:-----------------------------|
+| `OfferSequence` | Number | UInt32 | The sequence number of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
*Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate transaction][] with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
-The OfferCancel method returns [tesSUCCESS](tes-success.html) even if it did not find an offer with the matching sequence number.
+The OfferCancel method returns [`tesSUCCESS`](tes-success.html) even if it did not find an offer with the matching sequence number.
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md b/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md
index 5a7a24c307..5e76c53aae 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md
@@ -31,27 +31,25 @@ For more information about how Offers work, see [Offers](offers.html).
| Field | JSON Type | [Internal Type][] | Description |
|:---------------|:--------------------|:------------------|:------------------|
-| [Expiration][] | Number | UInt32 | _(Optional)_ Time after which the offer is no longer active, in [seconds since the Ripple Epoch][]. |
-| OfferSequence | Number | UInt32 | _(Optional)_ An offer to delete first, specified in the same way as [OfferCancel][]. |
-| TakerGets | [Currency Amount][] | Amount | The amount and type of currency being provided by the offer creator. |
-| TakerPays | [Currency Amount][] | Amount | The amount and type of currency being requested by the offer creator. |
-
-[Expiration]: offers.html#offer-expiration
+| [`Expiration`](offers.html#offer-expiration) | Number | UInt32 | _(Optional)_ Time after which the offer is no longer active, in [seconds since the Ripple Epoch][]. |
+| `OfferSequence` | Number | UInt32 | _(Optional)_ An offer to delete first, specified in the same way as [OfferCancel][]. |
+| `TakerGets` | [Currency Amount][] | Amount | The amount and type of currency being provided by the offer creator. |
+| `TakerPays` | [Currency Amount][] | Amount | The amount and type of currency being requested by the offer creator. |
## OfferCreate Flags
Transactions of the OfferCreate type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows:
-| Flag Name | Hex Value | Decimal Value | Description |
-|:--------------------|:-----------|:--------------|:--------------------------|
-| tfPassive | 0x00010000 | 65536 | If enabled, the offer does not consume offers that exactly match it, and instead becomes an Offer object in the ledger. It still consumes offers that cross it. |
-| tfImmediateOrCancel | 0x00020000 | 131072 | Treat the offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). If enabled, the offer never becomes a ledger object: it only tries to match existing offers in the ledger. If the offer cannot match any offers immediately, it executes "successfully" without trading any currency. In this case, the transaction has the [result code](transaction-results.html) `tesSUCCESS`, but creates no [Offer objects](offer.html) in the ledger. |
-| tfFillOrKill | 0x00040000 | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). Only try to match existing offers in the ledger, and only do so if the entire `TakerPays` quantity can be obtained. If the [fix1578 amendment][] is enabled and the offer cannot be executed when placed, the transaction has the [result code](transaction-results.html) `tecKILLED`; otherwise, the transaction uses the result code `tesSUCCESS` even when it was killed without trading any currency. |
-| tfSell | 0x00080000 | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |
+| Flag Name | Hex Value | Decimal Value | Description |
+|:----------------------|:-------------|:--------------|:----------------------|
+| `tfPassive` | `0x00010000` | 65536 | If enabled, the offer does not consume offers that exactly match it, and instead becomes an Offer object in the ledger. It still consumes offers that cross it. |
+| `tfImmediateOrCancel` | `0x00020000` | 131072 | Treat the offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). If enabled, the offer never becomes a ledger object: it only tries to match existing offers in the ledger. If the offer cannot match any offers immediately, it executes "successfully" without trading any currency. In this case, the transaction has the [result code](transaction-results.html) `tesSUCCESS`, but creates no [Offer objects](offer.html) in the ledger. |
+| `tfFillOrKill` | `0x00040000` | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). Only try to match existing offers in the ledger, and only do so if the entire `TakerPays` quantity can be obtained. If the [fix1578 amendment][] is enabled and the offer cannot be executed when placed, the transaction has the [result code](transaction-results.html) `tecKILLED`; otherwise, the transaction uses the result code `tesSUCCESS` even when it was killed without trading any currency. |
+| `tfSell` | `0x00080000` | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |
The following invalid flag combination prompts a `temINVALID_FLAG` error:
-* tfImmediateOrCancel and tfFillOrKill
+* `tfImmediateOrCancel` and `tfFillOrKill`
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/payment.md b/content/references/rippled-api/transaction-formats/transaction-types/payment.md
index bc7f61d92f..3c279cdd21 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/payment.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/payment.md
@@ -27,27 +27,27 @@ Payments are also the only way to [create accounts](#creating-accounts).
-| Field | JSON Type | [Internal Type][] | Description |
-|:---------------|:---------------------|:------------------|:-----------------|
-| Amount | [Currency Amount][] | Amount | The amount of currency to deliver. For non-XRP amounts, the nested field names MUST be lower-case. If the [**tfPartialPayment** flag](#payment-flags) is set, deliver _up to_ this amount instead. |
-| Destination | String | Account | The unique address of the account receiving the payment. |
-| DestinationTag | Number | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the payment to the destination, or a hosted recipient to pay. |
-| InvoiceID | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
-| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](paths.html) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. |
-| SendMax | [Currency Amount][] | Amount | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](transaction-cost.html). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. |
-| DeliverMin | [Currency Amount][] | Amount | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](partial-payments.html). For non-XRP amounts, the nested field names are lower-case. |
+| Field | JSON Type | [Internal Type][] | Description |
+|:-----------------|:---------------------|:------------------|:---------------|
+| `Amount` | [Currency Amount][] | Amount | The amount of currency to deliver. For non-XRP amounts, the nested field names MUST be lower-case. If the [`tfPartialPayment` flag](#payment-flags) is set, deliver _up to_ this amount instead. |
+| `Destination` | String | Account | The unique address of the account receiving the payment. |
+| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the payment to the destination, or a hosted recipient to pay. |
+| `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
+| `Paths` | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](paths.html) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. |
+| `SendMax` | [Currency Amount][] | Amount | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](transaction-cost.html). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. |
+| `DeliverMin` | [Currency Amount][] | Amount | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](partial-payments.html). For non-XRP amounts, the nested field names are lower-case. |
## Types of Payments
The Payment transaction type is a general-purpose tool that can represent several different types of abstract actions. You can identify the transaction type based on the transaction's fields, as described in the table below:
-| Payment type | `Amount` | `SendMax` | `Paths` | `Address` = `Destination`? | Description |
-|:------------------------------------------|:--------------------------------|:--------------------------------|:-----------------|:---------------------------|:--|
-| [Direct XRP-to-XRP Payment][] | String (XRP) | Omitted | Omitted | No | Transfers XRP directly from one account to another. Always delivers the exact amount. No fee applies other than the basic [transaction cost](transaction-cost.html). |
-| [Creating or redeeming issued currency][] | Object | Object (optional) | Optional | No | Increases or decreases the amount of a non-XRP currency or asset tracked in the XRP Ledger. [Transfer fees](transfer-fees.html) and [freezes](freezes.html) do not apply when sending and redeeming directly. |
-| [Cross-currency Payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Send issued currency from one holder to another. The `Amount` and `SendMax` cannot _both_ be XRP. These payments [ripple through](rippling.html) the issuer and can take longer [paths](paths.html) through several intermediaries if the transaction specifies a path set. [Transfer fees](transfer-fees.html) set by the issuer(s) apply to this type of transaction. These transactions consume offers in the [decentralized exchange](decentralized-exchange.html) to connect between different currencies, or possibly even between currencies with the same currency code and different issuers. |
-| [Partial payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Sends _up to_ a specific amount of any currency. Uses the [tfPartialPayment flag](#payment-flags). May include a `DeliverMin` amount specifying the minimum that the transaction must deliver to be successful; if the transaction does not specify `DeliverMin`, it can succeed by delivering _any positive amount_. |
-| Currency conversion | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Required | Yes | Consumes offers in the [decentralized exchange](decentralized-exchange.html) to convert one currency to another, possibly taking [arbitrage](https://en.wikipedia.org/wiki/Arbitrage) opportunities. The `Amount` and `SendMax` cannot both be XRP. Also called a _circular payment_ because it delivers money to the sender. The [Data API](data-api.html) tracks this type of transaction as an "exchange" and not a "payment". |
+| Payment type | `Amount` | `SendMax` | `Paths` | `Address` = `Destination`? | Description |
+|:-------------|:----------|:-----------|:----------|:---------------------------|:--|
+| [Direct XRP-to-XRP Payment][] | String (XRP) | Omitted | Omitted | No | Transfers XRP directly from one account to another. Always delivers the exact amount. No fee applies other than the basic [transaction cost](transaction-cost.html). |
+| [Creating or redeeming issued currency][] | Object | Object (optional) | Optional | No | Increases or decreases the amount of a non-XRP currency or asset tracked in the XRP Ledger. [Transfer fees](transfer-fees.html) and [freezes](freezes.html) do not apply when sending and redeeming directly. |
+| [Cross-currency Payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Send issued currency from one holder to another. The `Amount` and `SendMax` cannot _both_ be XRP. These payments [ripple through](rippling.html) the issuer and can take longer [paths](paths.html) through several intermediaries if the transaction specifies a path set. [Transfer fees](transfer-fees.html) set by the issuer(s) apply to this type of transaction. These transactions consume offers in the [decentralized exchange](decentralized-exchange.html) to connect between different currencies, or possibly even between currencies with the same currency code and different issuers. |
+| [Partial payment][] | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Usually required | No | Sends _up to_ a specific amount of any currency. Uses the [`tfPartialPayment` flag](#payment-flags). May include a `DeliverMin` amount specifying the minimum that the transaction must deliver to be successful; if the transaction does not specify `DeliverMin`, it can succeed by delivering _any positive amount_. |
+| Currency conversion | Object (non-XRP) / String (XRP) | Object (non-XRP) / String (XRP) | Required | Yes | Consumes offers in the [decentralized exchange](decentralized-exchange.html) to convert one currency to another, possibly taking [arbitrage](https://en.wikipedia.org/wiki/Arbitrage) opportunities. The `Amount` and `SendMax` cannot both be XRP. Also called a _circular payment_ because it delivers money to the sender. The [Data API](data-api.html) tracks this type of transaction as an "exchange" and not a "payment". |
[Direct XRP-to-XRP Payment]: direct-xrp-payments.html
[Creating or redeeming issued currency]: issued-currencies-overview.html
@@ -57,11 +57,13 @@ The Payment transaction type is a general-purpose tool that can represent severa
## Special issuer Values for SendMax and Amount
+
+
Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates a financial institution's [issuing address](issuing-and-operational-addresses.html). However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment.
-* There is only ever one balance for the same currency between two addresses. This means that, sometimes, the `issuer` field of an amount actually refers to a counterparty that is redeeming issuances, instead of the address that created the issuances.
-* When the `issuer` field of the destination `Amount` field matches the `Destination` address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all addresses to which the destination has extended trust lines, as well as issuances created by the destination which are held on other trust lines.
-* When the `issuer` field of the `SendMax` field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new issuances on trust lines that other accounts have extended to the source account, and sending issuances the source account holds from other issuers.
+* There is only ever one balance for the same currency between two addresses. This means that, sometimes, the `issuer` field of an amount actually refers to a counterparty that is redeeming the issued currency, instead of the address that issued the currency.
+* When the `issuer` field of the destination `Amount` field matches the `Destination` address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all addresses to which the destination has extended trust lines, as well as currencies issued by the destination.
+* When the `issuer` field of the `SendMax` field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new issued currencies on trust lines that other accounts have extended to the source account, and sending issued currencies the source account holds from other issuers.
## Creating Accounts
@@ -88,17 +90,17 @@ For more information, see [Paths](paths.html).
Transactions of the Payment type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows:
-| Flag Name | Hex Value | Decimal Value | Description |
-|:-----------------|:-----------|:--------------|:-----------------------------|
-| tfNoDirectRipple | 0x00010000 | 65536 | Do not use the default path; only use paths included in the `Paths` field. This is intended to force the transaction to take arbitrage opportunities. Most clients do not need this. |
-| tfPartialPayment | 0x00020000 | 131072 | If the specified `Amount` cannot be sent without spending more than `SendMax`, reduce the received amount instead of failing outright. See [Partial Payments](partial-payments.html) for more details. |
-| tfLimitQuality | 0x00040000 | 262144 | Only take paths where all the conversions have an input:output ratio that is equal or better than the ratio of `Amount`:`SendMax`. See [Limit Quality](#limit-quality) for details. |
+| Flag Name | Hex Value | Decimal Value | Description |
+|:-------------------|:-------------|:--------------|:-----------------------------|
+| `tfNoDirectRipple` | `0x00010000` | 65536 | Do not use the default path; only use paths included in the `Paths` field. This is intended to force the transaction to take arbitrage opportunities. Most clients do not need this. |
+| `tfPartialPayment` | `0x00020000` | 131072 | If the specified `Amount` cannot be sent without spending more than `SendMax`, reduce the received amount instead of failing outright. See [Partial Payments](partial-payments.html) for more details. |
+| `tfLimitQuality` | `0x00040000` | 262144 | Only take paths where all the conversions have an input:output ratio that is equal or better than the ratio of `Amount`:`SendMax`. See [Limit Quality](#limit-quality) for details. |
## Partial Payments
A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for [returning payments](become-an-xrp-ledger-gateway.html#bouncing-payments) without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the `Amount` field of a successful transaction always describes the exact amount delivered.
-A partial payment is any [Payment transaction][] with the **tfPartialPayment** flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its `DeliverMin` field (or any positive amount at all if `DeliverMin` is not specified) without sending more than the `SendMax` value.
+A partial payment is any [Payment transaction][] with the `tfPartialPayment` flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its `DeliverMin` field (or any positive amount at all if `DeliverMin` is not specified) without sending more than the `SendMax` value.
The [`delivered_amount`](transaction-metadata.html#delivered_amount) field of a payment's metadata indicates the amount of currency actually received by the destination account.
@@ -109,17 +111,17 @@ For more information, see the full article on [Partial Payments](partial-payment
The XRP Ledger defines the "quality" of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the "quality" of that exchange is `0.5`.
-The [*tfLimitQuality* flag](#payment-flags) allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination `Amount` divided by the `SendMax` amount (the numeric amounts only, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.
+The [`tfLimitQuality` flag](#payment-flags) allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination `Amount` divided by the `SendMax` amount (the numeric amounts only, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.
-By itself, the tfLimitQuality flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall average *average* quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the [transaction result](transaction-results.html) is `tecPATH_DRY`.
+By itself, the `tfLimitQuality` flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall average *average* quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the [transaction result](transaction-results.html) is `tecPATH_DRY`.
Consider the following example. If I am trying to send you 100 Chinese Yuan (`Amount` = 100 CNY) for 20 United States dollars (`SendMax` = 20 USD) or less, then the limit quality is `5`. Imagine one trader is offering ¥95 for $15 (a ratio of about `6.3` CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of `2.5` CNY per USD). If I were to take both offers to send you 100 CNY, then it would cost me 17 USD, for an average quality of about `5.9`.
-Without the tfLimitQuality flag set, this transaction would succeed, because the $17 it costs me is within my specified `SendMax`. However, with the tfLimitQuality flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of `2.5`, which is worse than the limit quality of `5`.
+Without the `tfLimitQuality` flag set, this transaction would succeed, because the $17 it costs me is within my specified `SendMax`. However, with the `tfLimitQuality` flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of `2.5`, which is worse than the limit quality of `5`.
-The tfLimitQuality flag is most useful when combined with [partial payments](partial-payments.html). When both *tfPartialPayment* and *tfLimitQuality* are set on a transaction, then the transaction delivers as much of the destination `Amount` as it can, without using any conversions that are worse than the limit quality.
+The `tfLimitQuality` flag is most useful when combined with [partial payments](partial-payments.html). When both `tfPartialPayment` and `tfLimitQuality` are set on a transaction, then the transaction delivers as much of the destination `Amount` as it can, without using any conversions that are worse than the limit quality.
-In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both tfPartialPayment and tfLimitQuality enabled. If we keep my `SendMax` of 20 USD and a destination `Amount` of 100 CNY, then the limit quality is still `5`. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about `6.3`, but it rejects the ¥5/$2 offer because that offer's quality of `2.5` is worse than the quality limit of `5`. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.
+In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both `tfPartialPayment` and `tfLimitQuality` enabled. If we keep my `SendMax` of 20 USD and a destination `Amount` of 100 CNY, then the limit quality is still `5`. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about `6.3`, but it rejects the ¥5/$2 offer because that offer's quality of `2.5` is worse than the quality limit of `5`. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md
index 609fbd878c..6f79fb4979 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md
@@ -33,7 +33,7 @@ The **destination address** of a channel can:
}
```
-
+
{% include '_snippets/tx-fields-intro.md' %}
@@ -45,7 +45,7 @@ The **destination address** of a channel can:
| `Balance` | String | Amount | _(Optional)_ Total amount of [XRP, in drops][Currency Amount], delivered by this channel after processing this claim. Required to deliver XRP. Must be more than the total amount delivered by the channel so far, but not greater than the `Amount` of the signed claim. Must be provided except when closing the channel. |
| `Amount` | String | Amount | _(Optional)_ The amount of [XRP, in drops][Currency Amount], authorized by the `Signature`. This must match the amount in the signed message. This is the cumulative amount of XRP that can be dispensed by the channel, including XRP previously redeemed. |
| `Signature` | String | Blob | _(Optional)_ The signature of this claim, as hexadecimal. The signed message contains the channel ID and the amount of the claim. Required unless the sender of the transaction is the source address of the channel. |
-| `PublicKey` | String | Blob | _(Optional)_ The public key used for the signature, as hexadecimal. This must match the `PublicKey` stored in the ledger for the channel. Required unless the sender of the transaction is the source address of the channel and the `Signature` field is omitted. (The transaction includes the PubKey so that `rippled` can check the validity of the signature before trying to apply the transaction to the ledger.) |
+| `PublicKey` | String | Blob | _(Optional)_ The public key used for the signature, as hexadecimal. This must match the `PublicKey` stored in the ledger for the channel. Required unless the sender of the transaction is the source address of the channel and the `Signature` field is omitted. (The transaction includes the public key so that `rippled` can check the validity of the signature before trying to apply the transaction to the ledger.) |
If the payment channel was created before the [fixPayChanRecipientOwnerDir amendment](known-amendments.html#fixpaychanrecipientownerdir) became enabled (on 2020-05-01), it is possible that the destination of the payment channel has been [deleted](accounts.html#deletion-of-accounts) and does not currently exist in the ledger. If the destination has been deleted, the source account cannot send XRP from the channel to the destination; instead, the transaction fails with `tecNO_DST`. (And, of course, the deleted account cannot send any transactions at all.) Other uses of this transaction type are unaffected when the destination account has been deleted, including adjusting the channel expiration, closing a channel with no XRP, or removing a channel that has passed its expiration time.
@@ -54,10 +54,10 @@ If the payment channel was created before the [fixPayChanRecipientOwnerDir amend
Transactions of the PaymentChannelClaim type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows:
-| Flag Name | Hex Value | Decimal Value | Description |
-|:----------|:-----------|:--------------|:------------------------------------|
-| `tfRenew` | 0x00010000 | 65536 | Clear the channel's `Expiration` time. (`Expiration` is different from the channel's immutable `CancelAfter` time.) Only the source address of the payment channel can use this flag. |
-| `tfClose` | 0x00020000 | 131072 | Request to close the channel. Only the channel source and destination addresses can use this flag. This flag closes the channel immediately if it has no more XRP allocated to it after processing the current claim, or if the destination address uses it. If the source address uses this flag when the channel still holds XRP, this schedules the channel to close after `SettleDelay` seconds have passed. (Specifically, this sets the `Expiration` of the channel to the close time of the previous ledger plus the channel's `SettleDelay` time, unless the channel already has an earlier `Expiration` time.) If the destination address uses this flag when the channel still holds XRP, any XRP that remains after processing the claim is returned to the source address. |
+| Flag Name | Hex Value | Decimal Value | Description |
+|:----------|:-------------|:--------------|:----------------------------------|
+| `tfRenew` | `0x00010000` | 65536 | Clear the channel's `Expiration` time. (`Expiration` is different from the channel's immutable `CancelAfter` time.) Only the source address of the payment channel can use this flag. |
+| `tfClose` | `0x00020000` | 131072 | Request to close the channel. Only the channel source and destination addresses can use this flag. This flag closes the channel immediately if it has no more XRP allocated to it after processing the current claim, or if the destination address uses it. If the source address uses this flag when the channel still holds XRP, this schedules the channel to close after `SettleDelay` seconds have passed. (Specifically, this sets the `Expiration` of the channel to the close time of the previous ledger plus the channel's `SettleDelay` time, unless the channel already has an earlier `Expiration` time.) If the destination address uses this flag when the channel still holds XRP, any XRP that remains after processing the claim is returned to the source address. |
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md b/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md
index 1e41115cda..4a3ec15497 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md
@@ -40,18 +40,18 @@ The SignerListSet transaction creates, replaces, or removes a list of signers th
| Field | JSON Type | [Internal Type][] | Description |
|:--------------|:----------|:------------------|:-----------------------------|
-| SignerQuorum | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is greater than or equal to this value. To delete a SignerList, use the value `0`. |
-| SignerEntries | Array | Array | (Omitted when deleting) Array of [SignerEntry objects](signerlist.html#signerentry-object), indicating the addresses and weights of signers in this list. A SignerList must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. |
+| `SignerQuorum` | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is greater than or equal to this value. To delete a signer list, use the value `0`. |
+| `SignerEntries` | Array | Array | (Omitted when deleting) Array of [`SignerEntry` objects](signerlist.html#signer-entry-object), indicating the addresses and weights of signers in this list. This signer list must have at least 1 member and no more than 8 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. |
-An account may not have more than one SignerList. A successful SignerListSet transaction replaces the existing SignerList, if one exists. To delete a SignerList, you must set `SignerQuorum` to `0` _and_ omit the `SignerEntries` field. Otherwise, the transaction fails with the error [temMALFORMED](tem-codes.html). A transaction to delete a SignerList is considered successful even if there was no SignerList to delete.
+A successful SignerListSet transaction replaces the account's [`SignerList` object](signerlist.html) in the ledger, or adds one if it did not exist before. An account may not have more than one signer list. To delete a signer list, you must set `SignerQuorum` to `0` _and_ omit the `SignerEntries` field. Otherwise, the transaction fails with the error [`temMALFORMED`](tem-codes.html). A transaction to delete a signer list is considered successful even if there was no signer list to delete.
-You cannot create a SignerList such that the SignerQuorum could never be met. The SignerQuorum must be greater than 0 but less than or equal to the sum of the `SignerWeight` values in the list. Otherwise, the transaction fails with the error [temMALFORMED](tem-codes.html).
+You cannot create a signer list such that the `SignerQuorum` could never be met. The `SignerQuorum` must be greater than 0 but less than or equal to the sum of the `SignerWeight` values in the list. Otherwise, the transaction fails with the error [`temMALFORMED`](tem-codes.html).
-You can create, update, or remove a SignerList using the master key, regular key, or the current SignerList, if those methods of signing transactions are available.
+You can create, update, or remove a signer list using the master key, regular key, or the current signer list, if those methods of signing transactions are available.
-You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the [`lsfDisableMaster` flag](accountroot.html#accountroot-flags) enabled) and the account does not have a [Regular Key](cryptographic-keys.html) configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [`tecNO_ALTERNATIVE_KEY`](tec-codes.html).
+You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (the account has the [`lsfDisableMaster` flag](accountroot.html#accountroot-flags) enabled) and the account does not have a [Regular Key](cryptographic-keys.html) configured, then you cannot delete the signer list from the account. Instead, the transaction fails with the error [`tecNO_ALTERNATIVE_KEY`](tec-codes.html).
-With the [MultiSignReserve amendment][] enabled, creating or replacing a SignerList enables the lsfOneOwnerCount flag on the SignerList object. When this flag is enabled, the XRP Ledger is able to lower the [`OwnerCount`](accountroot.html#accountroot-fields) and [owner reserve](reserves.html#owner-reserves) for a SignerList as provided by the MultiSignReserve amendment. For more information, see [SignerList Flag](signerlist.html#signerlist-flags).
+With the [MultiSignReserve amendment][] enabled, creating or replacing a signer list enables the `lsfOneOwnerCount` flag on the [SignerList object](signerlist.html). When this flag is enabled, the XRP Ledger is able to lower the [`OwnerCount`](accountroot.html#accountroot-fields) and [owner reserve](reserves.html#owner-reserves) for the signer list. For more information, see [SignerList Flags](signerlist.html#signerlist-flags).
{% include '_snippets/rippled-api-links.md' %}
diff --git a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md
index 06ccb2c94d..385279b525 100644
--- a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md
+++ b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md
@@ -39,16 +39,20 @@ Create or modify a trust line linking two accounts.
Transactions of the TrustSet type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows:
-| Flag Name | Hex Value | Decimal Value | Description |
-|:----------------|:-----------|:--------------|:------------------------------|
-| tfSetfAuth | 0x00010000 | 65536 | Authorize the other party to hold issuances from this account. (No effect unless using the [*asfRequireAuth* AccountSet flag](accountset.html#accountset-flags).) Cannot be unset. |
-| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](rippling.html) for details.) If the [fix1578 amendment][] is enabled, a transaction that uses this flag and cannot enable NoRipple fails with the result code `tecNO_PERMISSION`. If the amendment is not enabled, the transaction can result in `tesSUCCESS` (making any other changes it can) even if it cannot enable NoRipple on the trust line. |
-| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [NoRipple](rippling.html) for details.) |
-| tfSetFreeze | 0x00100000 | 1048576 | [Freeze](freezes.html) the trustline. |
-| tfClearFreeze | 0x00200000 | 2097152 | [Unfreeze](freezes.html) the trustline. |
+| Flag Name | Hex Value | Decimal Value | Description |
+|:------------------|:-------------|:--------------|:--------------------------|
+| `tfSetfAuth` | `0x00010000` | 65536 | Authorize the other party to hold [currency issued by this account](issued-currencies.html). (No effect unless using the [`asfRequireAuth` AccountSet flag](accountset.html#accountset-flags).) Cannot be unset. |
+| `tfSetNoRipple` | `0x00020000` | 131072 | Enable the No Ripple flag, which blocks [rippling](rippling.html) between two trust lines of the same currency if this flag is enabled on both. |
+| `tfClearNoRipple` | `0x00040000` | 262144 | Disable the No Ripple flag, allowing [rippling](rippling.html) on this trust line.) |
+| `tfSetFreeze` | `0x00100000` | 1048576 | [Freeze](freezes.html) the trust line. |
+| `tfClearFreeze` | `0x00200000` | 2097152 | [Unfreeze](freezes.html) the trust line. |
+
+If a transaction tries to enable No Ripple but cannot, it fails with the result code `tecNO_PERMISSION`. Before the [fix1578 amendment][] became enabled, such a transaction would result in `tesSUCCESS` (making any other changes it could) instead.
The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. An issuer can pre-authorize a trust line with the `tfSetfAuth` flag only, even if the limit and balance of the trust line are 0.
+
+
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
diff --git a/content/references/xrp-ledger-toml.md b/content/references/xrp-ledger-toml.md
index c138d46a4b..ffa44978f5 100644
--- a/content/references/xrp-ledger-toml.md
+++ b/content/references/xrp-ledger-toml.md
@@ -41,9 +41,9 @@ It is RECOMMENDED that you serve a human-readable website from the same domain a
### Path
-In compliance with [RFC5785](https://tools.ietf.org/html/rfc5785), the path MUST start with `/.well-known/`. The file MUST be available at the path `/.well-known/xrp-ledger.toml` exactly (case-sensitive, all lower case).
+In compliance with [RFC5785](https://tools.ietf.org/html/rfc5785), the path MUST start with `/.well-known/`. The file MUST be available at the path `/.well-known/xrp-ledger.toml` exactly (case-sensitive, all lower case).
-You MAY, if desired, serve the same file from alternate capitalizations of the same file, such as `/.well-known/XRP-Ledger.TOML`. You MUST NOT serve different contents depending on how the path is capitalized.
+You MAY, if desired, serve the same file from paths with different capitalization, such as `/.well-known/XRP-Ledger.TOML`. You MUST NOT serve different contents depending on how the path is capitalized.
### Headers
@@ -103,7 +103,7 @@ owner_country = "us"
server_country = "us"
unl = "https://vl.testnet.rippletest.net"
-# Note: the attestions above are only examples and are not real.
+# Note: the attestions above are only examples and are not real.
[[ACCOUNTS]]
address = "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV"
@@ -160,9 +160,9 @@ The specification does not define a `domain` field; the field should be determin
### Validators
-The validators list provides information about validating servers you operate. If present, the validators list MUST BE presented as an array of tables, with each entry using the header `[[VALIDATORS]]`, including double square brackets. Each entry describes a separate validating server.
+The validators list provides information about validating servers you run. If present, the validators list MUST BE presented as an array of tables, with each entry using the header `[[VALIDATORS]]`, including double square brackets. Each entry describes a separate validating server.
-The _first_ `[[VALIDATORS]]` entry in the file is treated as your primary validator. If you operate one or more validators for the production XRP Ledger, you should put the one you want others to trust first.
+The _first_ `[[VALIDATORS]]` entry in the file is treated as your primary validator. If you run one or more validators for the production XRP Ledger, you should put the one you want others to trust first.
For _each_ `[[VALIDATORS]]` entry, you MAY provide any of the following fields:
@@ -275,7 +275,7 @@ For other web servers, see [I want to add CORS support to my server](https://ena
## Domain Verification
-One use for the `xrp-ledger.toml` file is verifying that the same entity that operates a particular domain also operates a particular validator, as identified by the validator's public key. Verifying that a domain and a validator are owned by the same entity provides greater assurances of the identity of the validator operator and is a recommended step for becoming a trusted validator. (For other recommendations, see [Properties of a Good Validator](run-rippled-as-a-validator.html#1-understand-the-traits-of-a-good-validator).)
+One use for the `xrp-ledger.toml` file is verifying that the same entity that runs a particular domain also runs a particular validator, as identified by the validator's public key. Verifying that a domain and a validator are owned by the same entity provides greater assurances of the identity of the validator operator and is a recommended step for becoming a trusted validator. (For other recommendations, see [Properties of a Good Validator](run-rippled-as-a-validator.html#1-understand-the-traits-of-a-good-validator).)
Domain verification requires establishing a two-way link between the domain operator and the validator:
@@ -285,22 +285,22 @@ Domain verification requires establishing a two-way link between the domain oper
- In that `xrp-ledger.toml` file, provide a `[[VALIDATORS]]` entry with the validator's master public key in the `public_key` field.
-2. The validator claims ownership of the domain:
+2. The validator claims ownership of the domain:
- - Ensure that you have access to the validator-keys.json file that you created when first setting up your validator. If you have lost your keys or the keys have been compromised, please [revoke your keys](run-rippled-as-a-validator.html#revoke-validator-keys) and generate new keys.
+ - Ensure that you have access to the validator-keys.json file that you created when first setting up your validator. If you have lost your keys or the keys have been compromised, please [revoke your keys](run-rippled-as-a-validator.html#revoke-validator-keys) and generate new keys.
- Note: Recall that your validator-keys.json file should be stored **in a location not on your validator**.
+ Note: Recall that your validator-keys.json file should be stored **in a location not on your validator**.
- **In a location not on your validator**, build the [validator-keys-tool](https://github.com/ripple/validator-keys-tool).
- Run the following command to generate a new validator token that incorporates your domain and update your `xrp-ledger.toml` and `rippled.cfg` files:
-
+
$./validator-keys set_domain example.com
**Warning:** This command updates your validator-keys.json file. Please be sure to store the `validator-keys.json` file in a secure location.
-Sample Output:
+Sample Output:
```
The domain name has been set to: example.com
@@ -336,11 +336,11 @@ Update [the contents of your `xrp-ledger.toml` file](#contents) with the `attest
-**Warning:** Your validator token is meant to be kept secret. Do not share it on your `xrp-ledger.toml` file or anywhere else.
+**Warning:** Your validator token is meant to be kept secret. Do not share it on your `xrp-ledger.toml` file or anywhere else.
## Account Verification
-Similar to [Domain Verification](#domain-verification), account verification is the idea of proving that the same entity operates a particular domain and a particular XRP Ledger address. Account verification is not necessary for using the XRP Ledger or providing an `xrp-ledger.toml` file, but you may desire to verify your accounts in the name of transparency.
+Similar to [Domain Verification](#domain-verification), account verification is the idea of proving that the same entity controls a particular domain and a particular XRP Ledger address. Account verification is not necessary for using the XRP Ledger or providing an `xrp-ledger.toml` file, but you may desire to verify your accounts in the name of transparency.
Account verification requires establishing a two-way link between the domain operator and the address:
@@ -352,13 +352,13 @@ Account verification requires establishing a two-way link between the domain ope
2. The address claims ownership by a domain.
- [Set the account's `Domain` field](accountset.html#domain) to match the domain that this `xrp-ledger.toml` file was served from. The domain value (when decoded from ASCII) MUST match _exactly_, including all subdomains such as `www.`. For internationalized domain names, set the `Domain` value to the Punycode of the domain, as described in [RFC3492](https://tools.ietf.org/html/rfc3492).
+ [Set the account's `Domain` field](accountset.html#domain) to match the domain that this `xrp-ledger.toml` file was served from. The domain value (when decoded from ASCII) MUST match _exactly_, including all subdomains such as `www.`. For internationalized domain names, set the `Domain` value to the Punycode of the domain, as described in [RFC3492](https://tools.ietf.org/html/rfc3492).
Since setting the `Domain` requires sending a transaction, whoever set the `Domain` value must have possessed the account's secret key when the transaction was sent.
-Either of these two links, on their own, SHOULD NOT be considered authoritative. Anyone could host an `xrp-ledger.toml` file claiming ownership of any account, and any account operator could set its `Domain` field to any string it wants. If the two match, it provides strong evidence that the same entity operates both.
+Either of these two links, on their own, SHOULD NOT be considered authoritative. Anyone could host an `xrp-ledger.toml` file claiming ownership of any account, and any account operator could set its `Domain` field to any string it wants. If the two match, it provides strong evidence that the same entity controls both.
## Acknowledgements
-This specification is derived from the [original ripple.txt spec](https://web.archive.org/web/20161007113240/https://wiki.ripple.com/Ripple.txt) and draws inspiration from the [stellar.toml file](https://www.stellar.org/developers/guides/walkthroughs/how-to-complete-stellar-toml.html). This specification also incorporates feedback from XRP community members and many past and current Ripple employees.
+This specification is derived from the [original ripple.txt spec](https://web.archive.org/web/20161007113240/https://wiki.ripple.com/Ripple.txt) and draws inspiration from the [stellar.toml file](https://www.stellar.org/developers/guides/walkthroughs/how-to-complete-stellar-toml.html). This specification also incorporates feedback from XRP community members and many past and current Ripple employees.
diff --git a/content/tutorials/get-started/get-started-with-rippleapi-for-javascript.md b/content/tutorials/get-started/get-started-with-rippleapi-for-javascript.md
index 835b0b233c..dc82e45f56 100644
--- a/content/tutorials/get-started/get-started-with-rippleapi-for-javascript.md
+++ b/content/tutorials/get-started/get-started-with-rippleapi-for-javascript.md
@@ -20,13 +20,13 @@ This step depends on your operating system. Ripple recommends using [the officia
After you have installed Node.js, you can check the version of the `node` binary from a command line:
-```
+```sh
node --version
```
On some platforms, the binary is named `nodejs` instead:
-```
+```sh
nodejs --version
```
@@ -40,7 +40,7 @@ This step depends on your operating system. Ripple recommends using [the officia
After you have installed Yarn, you can check the version of the `yarn` binary from a command line:
-```
+```sh
yarn --version
```
@@ -55,13 +55,13 @@ Complete these steps to use Yarn to install RippleAPI and dependencies.
Create a folder called (for example) `my_ripple_experiment`:
-```
+```sh
mkdir my_ripple_experiment && cd my_ripple_experiment
```
Optionally, start a [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) repository in that directory so you can track changes to your code.
-```
+```sh
git init
```
@@ -75,16 +75,17 @@ Use the following template, which includes:
- RippleAPI itself (`ripple-lib`)
- (Optional) [ESLint](http://eslint.org/) (`eslint`) for checking code quality.
-```
+```json
{% include '_code-samples/rippleapi_quickstart/package.json' %}
```
+
### 3. Use Yarn to install RippleAPI and dependencies
Use Yarn to install RippleAPI and the dependencies defined in the `package.json` file you created for your project.
-```
+```sh
yarn
```
@@ -92,7 +93,7 @@ This installs RippleAPI and the dependencies into the local folder `node_modules
The install process may end with a few warnings. You may safely ignore the following warnings:
-```
+```text
warning eslint > file-entry-cache > flat-cache > circular-json@0.3.3: CircularJSON is in maintenance only, flatted is its successor.
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
@@ -106,7 +107,7 @@ npm WARN notsup Not compatible with your operating system or architecture: fseve
This script, `get-account-info.js`, fetches information about a hard-coded account. Use it to test that RippleAPI works:
-```
+```js
{% include '_code-samples/rippleapi_quickstart/get-account-info.js' %}
```
@@ -116,13 +117,13 @@ This script, `get-account-info.js`, fetches information about a hard-coded accou
Run your first RippleAPI script using this command:
-```
+```sh
node get-account-info.js
```
Output:
-```
+```text
getting account info for rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn
{ sequence: 359,
xrpBalance: '75.181663',
@@ -143,7 +144,7 @@ In addition to RippleAPI-specific code, this script uses syntax and conventions
### Script opening
-```
+```js
'use strict';
const RippleAPI = require('ripple-lib').RippleAPI;
```
@@ -155,7 +156,7 @@ The second line imports RippleAPI into the current scope using Node.js's require
### Instantiating the API
-```
+```js
const api = new RippleAPI({
server: 'wss://s1.ripple.com' // Public rippled server
});
@@ -165,7 +166,7 @@ This section creates a new instance of the RippleAPI class, assigning it to the
The one argument to the constructor is an options object, which has [a variety of options](rippleapi-reference.html#parameters). The `server` parameter tells it where it should connect to a `rippled` server.
-- The example `server` setting uses a secure WebSocket connection to connect to one of the public servers that Ripple (the company) operates.
+- The example `server` setting uses a secure WebSocket connection to connect to one of the public servers that Ripple (the company) runs.
- If you don't include the `server` option, RippleAPI runs in [offline mode](rippleapi-reference.html#offline-functionality) instead, which only provides methods that don't need network connectivity.
- You can specify a [XRP Ledger Test Net](xrp-test-net-faucet.html) server instead to connect to the parallel-world Test Network instead of the production XRP Ledger.
- If you [run your own `rippled`](install-rippled.html), you can instruct it to connect to your local server. For example, you might say `server: 'ws://localhost:5005'` instead.
@@ -173,7 +174,7 @@ The one argument to the constructor is an options object, which has [a variety o
### Connecting and Promises
-```
+```js
api.connect().then(() => {
```
@@ -188,7 +189,7 @@ The example uses [arrow function](https://developer.mozilla.org/en-US/docs/Web/J
### Custom code
-```
+```js
/* begin custom code ------------------------------------ */
const myAddress = 'rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn';
@@ -215,7 +216,7 @@ The `getAccountInfo` API method returns another Promise, so the line `}).then( i
### Cleanup
-```
+```js
}).then(() => {
return api.disconnect();
}).then(() => {
@@ -223,7 +224,7 @@ The `getAccountInfo` API method returns another Promise, so the line `}).then( i
}).catch(console.error);
```
-The rest of the sample code is mostly more [boilerplate code](rippleapi-reference.html#boilerplate). The first line ends the previous callback function, then chains to another callback to run when it ends. That method disconnects cleanly from the XRP Ledger, and has yet another callback which writes to the console when it finishes. If your script waits on [RippleAPI events](rippleapi-reference.html#api-events), do not disconnect until you are done waiting for events.
+The rest of the sample code is more [standard setup code](rippleapi-reference.html#boilerplate). The first line ends the previous callback function, then chains to another callback to run when it ends. That method disconnects cleanly from the XRP Ledger, and has yet another callback which writes to the console when it finishes. If your script waits on [RippleAPI events](rippleapi-reference.html#api-events), do not disconnect until you are done waiting for events.
The `catch` method ends this Promise chain. The callback provided here runs if any of the Promises or their callback functions encounters an error. In this case, we pass the standard `console.error` function, which writes to the console, instead of defining a custom callback. You could define a smarter callback function here to intelligently catch certain error types.
@@ -237,7 +238,7 @@ One of the biggest challenges in using the XRP Ledger (or any decentralized syst
{% include '_code-samples/rippleapi_quickstart/submit-and-verify.js' %}
```
-This code creates and submits an order transaction, although the same principles apply to other types of transactions as well. After submitting the transaction, the code uses a new Promise, which queries the ledger again after using setTimeout to wait a fixed amount of time, to see if the transaction has been verified. If it hasn't been verified, the process repeats until either the transaction is found in a validated ledger or the returned ledger is higher than the LastLedgerSequence parameter.
+This code creates and submits an order transaction, although the same principles apply to other types of transactions as well. After submitting the transaction, the code uses a new Promise, which queries the ledger again after using `setTimeout` to wait a fixed amount of time, to see if the transaction has been verified. If it hasn't been verified, the process repeats until either the transaction is found in a validated ledger or the returned ledger is higher than the `LastLedgerSequence` parameter.
In rare cases (particularly with a large delay or a loss of power), the `rippled` server may be missing a ledger version between when you submitted the transaction and when you determined that the network has passed the `maxLedgerVersion`. In this case, you cannot be definitively sure whether the transaction has failed, or has been included in one of the missing ledger versions. RippleAPI returns `MissingLedgerHistoryError` in this case.
@@ -251,6 +252,7 @@ See [Reliable Transaction Submission](reliable-transaction-submission.html) for
RippleAPI can also be used in a web browser if you compile a browser-compatible version and include [lodash](https://www.npmjs.com/package/lodash) as a dependency before the RippleAPI script.
+
## Build a Browser-Compatible Version of RippleAPI
@@ -268,7 +270,7 @@ cd ripple-lib
git checkout master
```
-Alternatively, you can download an archive (.zip or .tar.gz) of a specific release from the [RippleAPI releases page](https://github.com/ripple/ripple-lib/releases) and extract it.
+Alternatively, you can download an archive (`.zip` or `.tar.gz`) of a specific release from the [RippleAPI releases page](https://github.com/ripple/ripple-lib/releases) and extract it.
### 2. Install Yarn
@@ -285,7 +287,7 @@ yarn
### 4. Use Gulp to build a single JavaScript output
-RippleAPI comes with code to use the [gulp](http://gulpjs.com/) package to compile all its source code into browser-compatible JavaScript files. Gulp is automatically installed as one of the dependencies, so all you have to do is run it. RippleAPI's configuration makes this easy:
+RippleAPI comes with code to use the [gulp](http://gulpjs.com/) package to compile all its source code into browser-compatible JavaScript files. Gulp is automatically installed as one of the dependencies, so all you have to do is run it, such as with following command:
```
yarn run build
@@ -310,7 +312,7 @@ Output:
This may take a while. At the end, the build process creates a new `build/` folder, which contains the files you want.
-The file `build/ripple-.js` is a straight export of RippleAPI (whatever version you built) ready to be used in browsers. The file ending in `-min.js` is the same thing, but with the content [minified](https://en.wikipedia.org/wiki/Minification_%28programming%29) for faster loading.
+The file `build/ripple-.js` is a straight export of RippleAPI (whatever version you built) ready to be used in browsers. The file ending in `-min.js` is the same thing, but with the content [minified](https://en.wikipedia.org/wiki/Minification_%28programming%29) for faster loading.
@@ -326,7 +328,7 @@ To use this example, you must first [build a browser-compatible version of Rippl
{% include '_code-samples/rippleapi_quickstart/browser-demo.html' %}
```
-This demo HTML loads Lodash v4.17.11 from CDNJS on Cloudflare and then loads ripple-lib v1.1.2, but you could also download and load a variant of Lodash locally.
+This demo HTML loads Lodash v4.17.11 from CDNJS on Cloudflare and then loads ripple-lib v1.1.2, but you could also download and load a variant of Lodash locally.
## See Also
diff --git a/content/tutorials/get-started/get-started-with-the-rippled-api.md b/content/tutorials/get-started/get-started-with-the-rippled-api.md
index 075b50c762..8124df2228 100644
--- a/content/tutorials/get-started/get-started-with-the-rippled-api.md
+++ b/content/tutorials/get-started/get-started-with-the-rippled-api.md
@@ -47,7 +47,7 @@ The response to [this command][server_info method] shows you the current status
## JSON-RPC
-You can use any HTTP client (like [RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/), [Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en) or [Online HTTP client ExtendsClass](https://extendsclass.com/rest-client-online.html)) to make JSON-RPC calls a `rippled` server. Most programming languages have a library for making HTTP requests built in.
+You can use any HTTP client (like [RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/), [Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en) or [Online HTTP client ExtendsClass](https://extendsclass.com/rest-client-online.html)) to make JSON-RPC calls a `rippled` server. Most programming languages have a library for making HTTP requests built in.
Example JSON-RPC request:
diff --git a/content/tutorials/get-started/look-up-transaction-results.md b/content/tutorials/get-started/look-up-transaction-results.md
index 607bd89197..85ee6b8f50 100644
--- a/content/tutorials/get-started/look-up-transaction-results.md
+++ b/content/tutorials/get-started/look-up-transaction-results.md
@@ -54,14 +54,14 @@ The following example shows a successful transaction, as returned by the [tx met
}
```
-This example shows an [AccountSet transaction][] sent by the [account](accounts.html) with address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn, using [Sequence number][] 376. The transaction's [identifying hash][] is `017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567` and its [result](transaction-results.html) is `tesSUCCESS`. The transaction was included in ledger version 46447423, which has been validated, so these results are final.
+This example shows an [AccountSet transaction][] sent by the [account](accounts.html) with address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`, using [Sequence number][] 376. The transaction's [identifying hash][] is `017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567` and its [result](transaction-results.html) is `tesSUCCESS`. The transaction was included in ledger version 46447423, which has been validated, so these results are final.
### Case: Not Included in a Validated Ledger
**If a transaction is not included in a validated ledger, it cannot possibly have had _any_ effect on the shared XRP Ledger state.** If the transaction's failure to be included in a ledger is [_final_](finality-of-results.html), then it cannot have any future effect, either.
-If the transaction's failure is not final, it may still become included in a _future_ validated ledger. You can use the provisional results of applying the transaction to the current open ledger as a preview of the likely effects the transaction may have in a final ledger, but those results can change due to [numerous factors](finality-of-results.html#how-can-non-final-results-change).
+If the transaction's failure is not final, it may still become included in a _future_ validated ledger. You can use the provisional results of applying the transaction to the current open ledger as a preview of the likely effects the transaction may have in a final ledger, but those results can change due to [many factors](finality-of-results.html#how-can-non-final-results-change).
### Case: Included in a Validated Ledger
@@ -148,7 +148,7 @@ The _only_ changes made by this [no-op transaction](cancel-or-skip-a-transaction
**Note:** Although the metadata does not explicitly show it, any time a transaction modifies a ledger object, it updates that object's `PreviousTxnID` and `PreviousTxnLgrSeq` fields with the current transaction's information. If the same sender has multiple transactions in a single ledger version, each one after the first provides a `PreviousTxnLgrSeq` whose value is the [ledger index](basic-data-types.html#ledger-index) of the ledger version that included all those transactions.
-Since the `ModifiedNode` entry for rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn's account is the only object in the `AffectedNodes` array, no other changes were made to the ledger as a result of this transaction.
+Since the `ModifiedNode` entry for `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`'s account is the only object in the `AffectedNodes` array, no other changes were made to the ledger as a result of this transaction.
**Tip:** If the transaction sends or receives XRP, the sender's balance changes are combined with the transaction cost, resulting in a single change to the `Balance` field in the net amount. For example, if you sent 1 XRP (1,000,000 drops) and destroyed 10 drops for the transaction cost, the metadata shows your `Balance` decreasing by 1,000,010 drops of XRP.
@@ -187,7 +187,7 @@ Example of increasing an Account's `OwnerCount`:
Many transaction types create or modify [DirectoryNode objects](directorynode.html). These objects are for bookkeeping: tracking all objects owned by an account, or all Offers to exchange currency at the same exchange rate. If the transaction created new objects in the ledger, it may need to add entries to an existing DirectoryNode object, or add another DirectoryNode object to represent another page of the directory. If the transaction removed objects from the ledger, it may delete one or more DirectoryNode objects that are no longer needed.
-Example of a CreatedNode representing a new Offer Directory:
+Example of a `CreatedNode` representing a new Offer Directory:
```json
{
@@ -212,9 +212,9 @@ A [Payment transaction][] can represent a direct XRP-to-XRP transaction, a [cros
XRP amounts are tracked in the `Balance` field of `AccountRoot` objects. (XRP can also exist in [Escrow objects](escrow-object.html) and [PayChannel objects](paychannel.html), but Payment transactions cannot affect those.)
-You should always use [the delivered_amount field](partial-payments.html#the-delivered_amount-field) to see how much a payment delivered.
+You should always use [the `delivered_amount` field](partial-payments.html#the-delivered_amount-field) to see how much a payment delivered.
-If the payment contains a `CreatedNode` of LedgerEntryType `AccountRoot`, that means the payment [funded a new account](accounts.html#creating-accounts) in the ledger.
+If the payment contains a `CreatedNode` with `"LedgerEntryType": "AccountRoot"`, that means the payment [funded a new account](accounts.html#creating-accounts) in the ledger.
#### Issued Currency Payments
@@ -232,11 +232,11 @@ The [`QualityIn` and `QualityOut` settings of trust lines](trustset.html) can af
If the amount to be sent or received is outside of the [issued currency precision](currency-formats.html#issued-currency-precision), it is possible that one side may be debited for an amount that is rounded to nothing on the other side of the transaction. Therefore, when two parties transact while their balances are different by a factor of 1016, it is possible that rounding may effectively "create" or "destroy" small amounts of the issued currency. (XRP is never rounded, so this is not possible with XRP.)
-Depending on the length of the [paths](paths.html), the metadata for cross-currency payments can be _long_. For example, [transaction 8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B) delivered 2.788 GCB issued by rHaaans..., spending XRP but passing through USD from 2 issuers, paying XRP to 2 accounts, removing an unfunded offer from r9ZoLsJ to trade EUR for ETH, plus bookkeeping for a total of 17 different ledger objects modified.
+Depending on the length of the [paths](paths.html), the metadata for cross-currency payments can be _long_. For example, [transaction 8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B) delivered 2.788 GCB issued by `rHaaans...`, spending XRP but passing through USD from 2 issuers, paying XRP to 2 accounts, removing an unfunded offer from `r9ZoLsJ...` to trade EUR for ETH, plus bookkeeping for a total of 17 different ledger objects modified.
### Offers
-An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with LedgerEntryType `Offer` to see if the transaction added a new Offer to the ledger's order books. For example:
+An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer to the ledger's order books. For example:
```json
{
@@ -261,7 +261,7 @@ An [OfferCreate transaction][] may or may not create an object in the ledger, de
A `ModifiedNode` of type `Offer` indicates an Offer that was matched and partially consumed. A single transaction can consume a large number of Offers. An Offer to trade two issued currencies might also consume Offers to trade XRP because of [auto-bridging](autobridging.html). All or part of an exchange can be auto-bridged.
-A `DeletedNode` of LedgerEntryType `Offer` can indicate a matching Offer that was fully consumed, an Offer that was found to be [expired or unfunded](offers.html#lifecycle-of-an-offer) at the time of processing, or an Offer that was canceled as part of placing a new Offer. You can recognize a canceled Offer because the `Account` that placed it is the sender of the transaction that deleted it.
+A `DeletedNode` of type `Offer` can indicate a matching Offer that was fully consumed, an Offer that was found to be [expired or unfunded](offers.html#lifecycle-of-an-offer) at the time of processing, or an Offer that was canceled as part of placing a new Offer. You can recognize a canceled Offer because the `Account` that placed it is the sender of the transaction that deleted it.
Example of a deleted Offer:
@@ -293,23 +293,23 @@ Example of a deleted Offer:
Offers can create, delete, and modify both types of [DirectoryNode objects](directorynode.html), to keep track of who placed which Offers and which Offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
-An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no Offer to delete. Look for a `DeletedNode` of LedgerEntryType `Offer` to confirm that the transaction actually deleted an Offer. If not, the Offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
+An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no Offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an Offer. If not, the Offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the Offer created a trust line](offers.html#offers-and-trust) to hold an issued currency received in the trade.
### Escrows
-A successful [EscrowCreate transaction][] creates an [Escrow object](escrow-object.html) in the ledger. Look for a `CreatedNode` entry of LedgerEntryType `Escrow`. The `NewFields` should show an `Amount` equal to the amount of XRP escrowed, and other properties as specified.
+A successful [EscrowCreate transaction][] creates an [Escrow object](escrow-object.html) in the ledger. Look for a `CreatedNode` entry of type `Escrow`. The `NewFields` should show an `Amount` equal to the amount of XRP escrowed, and other properties as specified.
-A successful EscrowCreate transaction also debits the same amount of XRP from the sender. Look for a `ModifiedNode` of LedgerEntryType `AccountRoot`, where the `Account` in the final fields matches the address from the `Account` in the transaction instructions. The `Balance` should show the decrease in XRP due to the escrowed XRP (in addition to the XRP destroyed to pay the transaction cost).
+A successful EscrowCreate transaction also debits the same amount of XRP from the sender. Look for a `ModifiedNode` of type `AccountRoot`, where the `Account` in the final fields matches the address from the `Account` in the transaction instructions. The `Balance` should show the decrease in XRP due to the escrowed XRP (in addition to the XRP destroyed to pay the transaction cost).
-A successful [EscrowFinish transaction][] modifies the `AccountRoot` of the recipient to increase their XRP balance (in the `Balance` field), deletes the `Escrow` object, and reduces the owner count of the escrow creator. Since the escrow's creator, recipient, and finisher may all be different accounts or the same, this can result in _one to three_ `ModifiedNode` objects of LedgerEntryType `AccountRoot`. A successful [EscrowCancel transaction][] is very similar, except it sends the XRP back to the original creator of the escrow.
+A successful [EscrowFinish transaction][] modifies the `AccountRoot` of the recipient to increase their XRP balance (in the `Balance` field), deletes the `Escrow` object, and reduces the owner count of the escrow creator. Since the escrow's creator, recipient, and finisher may all be different accounts or the same, this can result in _one to three_ `ModifiedNode` objects of type `AccountRoot`. A successful [EscrowCancel transaction][] is very similar, except it sends the XRP back to the original creator of the escrow.
Of course, an EscrowFinish can only be successful if it meets the conditions of the escrow, and an EscrowCancel can only be successful if the expiration of the Escrow object is before the close time of the previous ledger.
Escrow transactions also do normal [bookkeeping](#general-purpose-bookkeeping) for adjusting the sender's owner reserve and the directories of the accounts involved.
-In the following excerpt, we see that r9UUEX...'s balance increases by 1 billion XRP and its owner count decreases by 1 because an escrow from that account to itself finished successfully. The `Sequence` number does not change because [a third party completed the escrow](https://xrpcharts.ripple.com/#/transactions/C4FE7F5643E20E7C761D92A1B8C98320614DD8B8CD8A04CFD990EBC5A39DDEA2):
+In the following excerpt, we see that `r9UUEX...`'s balance increases by 1 billion XRP and its owner count decreases by 1 because an escrow from that account to itself finished successfully. The `Sequence` number does not change because [a third party completed the escrow](https://xrpcharts.ripple.com/#/transactions/C4FE7F5643E20E7C761D92A1B8C98320614DD8B8CD8A04CFD990EBC5A39DDEA2):
```json
{
@@ -351,11 +351,11 @@ In the following excerpt, we see that r9UUEX...'s balance increases by 1 billion
### Payment Channels
-Look for a `CreatedNode` of LedgerEntryType `PayChannel` when creating a payment channel. You should also find a `ModifiedNode` of LedgerEntryType `AccountRoot` showing the decrease in the sender's balance. Look for an `Account` field in the `FinalFields` to confirm that the address matches the sender, and look at the difference in the `Balance` fields to see the change in XRP balance.
+Look for a `CreatedNode` of type `PayChannel` when creating a payment channel. You should also find a `ModifiedNode` of type `AccountRoot` showing the decrease in the sender's balance. Look for an `Account` field in the `FinalFields` to confirm that the address matches the sender, and look at the difference in the `Balance` fields to see the change in XRP balance.
The metadata also lists the newly-created payment channel in the destination's [owner directory](directorynode.html). This prevents an account from [being deleted](accounts.html#deletion-of-accounts) if it is the destination of an open payment channel. (This behavior was added by the [fixPayChanRecipientOwnerDir amendment](known-amendments.html#fixpaychanrecipientownerdir).)
-There are several ways to request to close a payment channel, aside from the immutable `CancelAfter` time of the channel (which is only set on creation). If a transaction schedules a channel to close, there is a `ModifiedNode` entry of LedgerEntryType `PayChannel` for the channel, with the newly-added close time in the `Expiration` field of the `FinalFields`. The following example shows the changes to a `PayChannel` in a case where the sender requested to close the channel without redeeming a claim:
+There are several ways to request to close a payment channel, aside from the immutable `CancelAfter` time of the channel (which is only set on creation). If a transaction schedules a channel to close, there is a `ModifiedNode` entry of type `PayChannel` for the channel, with the newly-added close time in the `Expiration` field of the `FinalFields`. The following example shows the changes to a `PayChannel` in a case where the sender requested to close the channel without redeeming a claim:
```json
{
@@ -385,7 +385,7 @@ There are several ways to request to close a payment channel, aside from the imm
TrustSet transactions create, modify, or delete [trust lines](trust-lines-and-issuing.html), which are represented as [`RippleState` objects](ripplestate.html). A single `RippleState` object contains settings for both parties involved, including their limits, [rippling settings](rippling.html), and more. Creating and modifying trust lines can also [adjust the sender's owner reserve and owner directory](#general-purpose-bookkeeping).
-The following example shows a new trust line, where **rf1BiG...** is willing to hold up to 110 USD issued by **rsA2Lp...**:
+The following example shows a new trust line, where **`rf1BiG...`** is willing to hold up to 110 USD issued by **`rsA2Lp...`**:
```json
{
@@ -426,7 +426,7 @@ Most other transactions create a specific type of ledger entry and [adjust the s
### Pseudo-Transactions
-[Pseudo-transactions](pseudo-transaction-types.html) also have metadata, but they do not follow all the rules of normal transactions. They are not tied to a real account (the `Account` value is just the [base58-encoded form of the number 0](accounts.html#special-addresses)), so they do not modify an AccountRoot object in the ledger to increase the `Sequence` number or destroy XRP. Pseudo-transactions only make specific changes to special ledger objects:
+[Pseudo-transactions](pseudo-transaction-types.html) also have metadata, but they do not follow all the rules of normal transactions. They are not tied to a real account (the `Account` value is the [base58-encoded form of the number 0](accounts.html#special-addresses)), so they do not modify an AccountRoot object in the ledger to increase the `Sequence` number or destroy XRP. Pseudo-transactions only make specific changes to special ledger objects:
- [EnableAmendment pseudo-transactions][] modify the [Amendments ledger object](amendments-object.html) to track which amendments are enabled, and which ones are pending with majority support and for how long.
- [SetFee pseudo-transactions][] modify the [FeeSettings ledger object](feesettings.html) to change the base levels for the [transaction cost](transaction-cost.html) and [reserve requirements](reserves.html).
diff --git a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md b/content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
index 5b74b5588b..133bad492f 100644
--- a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
+++ b/content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
@@ -110,11 +110,11 @@ $("#connect-button").click((event) => {
WebSocket接続では、複数のメッセージをどちらの方向にも送信することが可能で、要求と応答の間に厳密な1:1の相互関係がないため、各着信メッセージに対応する処理を識別する必要があります。この処理をコーディングする際の優れたモデルとして、「ディスパッチャー」関数の設定が挙げられます。この関数は着信メッセージを読み取り、各メッセージを正しいコードのパスに中継して処理します。メッセージを適切にディスパッチできるように、`rippled`サーバーでは、すべてのWebSocketメッセージで`type`フィールドを使用できます。
- クライアント側からの要求への直接の応答となるメッセージの場合、`type`は文字列の`response`です。この場合、サーバーは以下も提供します。
-
+
- この応答に対する要求で指定された`id`に一致する`id`フィールド（応答が順序どおりに到着しない可能性があるため、これは重要です）。
-
+
- APIが要求の処理に成功したかどうかを示す`status`フィールド。文字列値`success`は、[成功した応答](response-formatting.html)を示します。文字列値`error`は、[エラー](error-formatting.html)を示します。
-
+
**警告:** トランザクションを送信する際、WebSocketメッセージの先頭にある`success`の`status`は、必ずしもトランザクション自体が成功したことを意味しません。これは、サーバーによって要求が理解されたということのみを示します。トランザクションの実際の結果を確認するには、[トランザクションの結果の確認](look-up-transaction-results.html)を参照してください。
- [サブスクリプション](subscribe.html)からのフォローアップメッセージの場合、`type`は、新しいトランザクション、レジャーまたは検証の通知など、フォローアップメッセージのタイプを示します。または継続している[pathfinding要求](path_find.html)のフォローアップを示します。クライアントがこれらのメッセージを受信するのは、それらをサブスクライブしている場合のみです。
@@ -335,19 +335,19 @@ WS_HANDLERS["transaction"] = log_tx
- **`transaction.Account`** フィールドはトランザクションの送信元です。他の人が送信したトランザクションのみを探している場合は、このフィールドがあなたのアドレスと一致するトランザクションを無視できます（自身に対する複数通貨間の支払いが _可能である_ 点に注意してください）。
- **`transaction.TransactionType`フィールド**はトランザクションのタイプです。アカウントに通貨を送金できる可能性があるトランザクションのタイプは以下のとおりです。
-
+
- **[Paymentトランザクション][]** はXRPまたは[発行済み通貨](issued-currencies.html)を送金できます。受取人のアドレスを含んでいる`transaction.Destination`フィールドによってこれらを絞り込み、必ず`meta.delivered_amount`を使用して実際に支払われた額を確認します。XRPの額は、[文字列のフォーマットで記述されます](basic-data-types.html#通貨額の指定)。
-
+
**警告:** 代わりに`transaction.Amount`フィールドを使用すると、[Partial Paymentの悪用](partial-payments.html#partial-paymentの悪用)に対して脆弱になる可能性があります。不正使用者はこの悪用を行ってあなたをだまし、あなたが支払ったよりも多くの金額を交換または引き出すことができます。
-
+
- **[CheckCashトランザクション][]** :not_enabled: では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
-
+
- **[EscrowFinishトランザクション][]** は、以前の[EscrowCreateトランザクション][]によって作成された[Escrow](escrow.html)を終了することでXRPを送金できます。**EscrowFinishトランザクション**のメタデータを確認すると、escrowからXRPを受け取ったアカウントと、その額を確認できます。
-
+
- **[OfferCreateトランザクション][]** はアカウントがXRP Ledgerの[分散型取引所](decentralized-exchange.html)で以前発行したオファーを消費することで、XRPまたは発行済み通貨を送金できます。オファーを発行しないと、この方法で金額を受け取ることはできません。メタデータを確認して、アカウントが受け取った通貨（この情報がある場合）と、金額を確認します。
-
+
- **[PaymentChannelClaimトランザクション][]** では、[Payment Channel](payment-channels.html)からXRPを送金できます。メタデータを確認して、トランザクションからXRPを受け取ったアカウント（この情報がある場合）を確認します。
-
+
- **[PaymentChannelFundトランザクション][]** は、閉鎖された（期限切れの）Payment Channelから送金元にXRPを返金することができます。
- **`meta`フィールド**には、1つまたは複数の通貨の種類とその正確な金額、その送金先などを示す[トランザクションメタデータ](transaction-metadata.html)が示されています。トランザクションメタデータを理解する方法の詳細は、[トランザクションの結果の確認](look-up-transaction-results.html)を参照してください。
@@ -397,7 +397,7 @@ function CountXRPDifference(affected_nodes, address) {
}
}
} else if ((affected_nodes[i].hasOwnProperty("CreatedNode"))) {
- // created a ledger entry. maybe the account just got funded?
+ // created a ledger entry. maybe the account got funded?
let ledger_entry = affected_nodes[i].CreatedNode
if (ledger_entry.LedgerEntryType === "AccountRoot" &&
ledger_entry.NewFields.Account === address) {
diff --git a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md b/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md
index 1cb2b6722b..66a43c8deb 100644
--- a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md
+++ b/content/tutorials/get-started/monitor-incoming-payments-with-websocket.md
@@ -394,7 +394,7 @@ function CountXRPDifference(affected_nodes, address) {
}
}
} else if ((affected_nodes[i].hasOwnProperty("CreatedNode"))) {
- // created a ledger entry. maybe the account just got funded?
+ // created a ledger entry. maybe the account got funded?
let ledger_entry = affected_nodes[i].CreatedNode
if (ledger_entry.LedgerEntryType === "AccountRoot" &&
ledger_entry.NewFields.Account === address) {
diff --git a/content/tutorials/get-started/set-up-secure-signing.md b/content/tutorials/get-started/set-up-secure-signing.md
index ddd316644c..ab2d221740 100644
--- a/content/tutorials/get-started/set-up-secure-signing.md
+++ b/content/tutorials/get-started/set-up-secure-signing.md
@@ -2,7 +2,7 @@
To submit [transactions](transaction-basics.html) to the XRP Ledger, you need a way to digitally sign them without compromising the security of your [secret keys](cryptographic-keys.html). (If others gain access to your secret keys, they have as much control over your accounts as you do, and can steal or destroy all your money.) This page summarizes how to set up such an environment so you can sign transactions securely.
-**Tip:** If you are not submitting transactions to the network, you can safely use a trustworthy public server, such as the ones run by Ripple, to monitor for incoming transactions or just to read other network activity. All transactions, balances, and data in the XRP Ledger are public.
+**Tip:** If you are not submitting transactions to the network, you can safely use a trustworthy public server, such as the ones run by Ripple, to monitor for incoming transactions or read other network activity. All transactions, balances, and data in the XRP Ledger are public.
There are several configurations with varying levels of security that may be acceptable for your situation. Choose one of the following that best fits your needs:
@@ -38,7 +38,7 @@ In this configuration, you run `rippled` on the machine that generates the trans
The [example config file](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073) listens for connections on the local loopback network (127.0.0.1), with JSON-RPC (HTTP) on port 5005 and WebSocket (WS) on port 6006, and treats all connected clients as admin.
- **Caution:** Using the [commandline API](request-formatting.html#commandline-format) for signatures is less secure than [using the Websocket or JSON-RPC APIs](get-started-with-the-rippled-api.html) through non-commandline clients. When using the commandline syntax, your secret key may be visible to other users in the system's process listing, and your shell history may save the key in plaintext.
+ **Caution:** Using the [commandline API](request-formatting.html#commandline-format) for signatures is less secure than [using the Websocket or JSON-RPC APIs](get-started-with-the-rippled-api.html) through non-commandline clients. When using the commandline syntax, your secret key may be visible to other users in the system's process listing, and your shell history may save the key in plain text.
3. Maintain the server to keep it running, updated, and in sync with the network while you're using it.
@@ -70,7 +70,7 @@ This configuration uses a client library in the programming language you are usi
- **Signing Library for C++** (included with `rippled`)
- [Documentation](https://github.com/ripple/rippled/tree/develop/Builds/linux#signing-library)
-If you use a client library not published by Ripple, make sure it uses proper, secure implementations of the signing algorithm(s) it implements. (For example, if it uses the default ECDSA algorithm, it should also use deterministic nonces as described in [RFC6979](https://tools.ietf.org/html/rfc6979).) All of Ripple's published libraries listed above follow industry best practices.
+If you use a client library not published by Ripple, make sure it uses proper, secure implementations of the signing algorithm(s) it implements. (For example, if it uses the default ECDSA algorithm, it should also use deterministic nonces as described in [RFC-6979](https://tools.ietf.org/html/rfc6979).) All of Ripple's published libraries listed above follow industry best practices.
For best security, be sure to keep your client library updated to the latest stable version.
diff --git a/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md b/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md
index d12ca425a1..242bdc9264 100644
--- a/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md
+++ b/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md
@@ -1,6 +1,6 @@
# Change or Remove a Regular Key Pair
-The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If your [account](accounts.html)'s regular key pair is compromised, or if you just want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account.
+The XRP Ledger allows an account to authorize a secondary key pair, called a _[regular key pair](cryptographic-keys.html)_, to sign future transactions. If your [account](accounts.html)'s regular key pair is compromised, or if you want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account.
For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html).
@@ -14,7 +14,7 @@ For more information about master and regular key pairs, see [Cryptographic Keys
## Removing a Regular Key Pair
-If you want to simply remove a compromised regular key pair from your account, you don't need to generate a key pair first. Use a [SetRegularKey transaction][], omitting the `RegularKey` field. Note that the transaction fails if you don't have another way of signing for your account currently enabled (either the master key pair or a [signer list](multi-signing.html)).
+If you want to remove a compromised regular key pair from your account, you don't need to generate a key pair first. Use a [SetRegularKey transaction][], omitting the `RegularKey` field. Note that the transaction fails if you don't have another way of signing for your account currently enabled (either the master key pair or a [signer list](multi-signing.html)).
When removing a regular key pair to your account, the `SetRegularKey` transaction requires signing by your account's master private key (secret) or existing regular key pair. Transmitting your master or regular private key is dangerous, so we'll complete this transaction in two steps to keep transaction signing separate from transaction submission to the network.
@@ -353,7 +353,7 @@ An example of a successful response:
-In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](transaction-cost.html#key-reset-transaction) without paying the [transaction cost](transaction-cost.html). With the enablement of the FeeEscalation amendment, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
+In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](transaction-cost.html#key-reset-transaction) without paying the [transaction cost](transaction-cost.html). The XRP Ledger's [transaction queue](transaction-queue.html) prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero.
- **Concepts:**
diff --git a/content/tutorials/manage-account-settings/disable-master-key-pair.md b/content/tutorials/manage-account-settings/disable-master-key-pair.md
index 400936a9cd..67dbe3961b 100644
--- a/content/tutorials/manage-account-settings/disable-master-key-pair.md
+++ b/content/tutorials/manage-account-settings/disable-master-key-pair.md
@@ -451,7 +451,7 @@ Loading: "/etc/opt/ripple/rippled.cfg"
-In the response's `account_data` object, compare the `Flags` field with the lsfDisableMaster flag value (`0x00100000` in hex, or `1048576` in decimal) using bitwise-AND (the `&` operator in most common programming languages).
+In the response's `account_data` object, compare the `Flags` field with the `lsfDisableMaster` flag value (`0x00100000` in hex, or `1048576` in decimal) using bitwise-AND (the `&` operator in most common programming languages).
Example code:
@@ -487,7 +487,7 @@ else:
This operation has only two possible outcomes:
-- A nonzero result, equal to the lsfDisableMaster value, indicates **the master key has been successfully disabled**.
+- A nonzero result, equal to the `lsfDisableMaster` value, indicates **the master key has been successfully disabled**.
- A zero result indicates the account's master key is not disabled.
If the result does not match your expectations, check whether the transaction you sent in the previous steps has executed successfully. It should be the most recent entry in the account's transaction history ([account_tx method][]) and it should have the result code `tesSUCCESS`. If you see any other [result code](transaction-results.html), the transaction was not executed successfully. Depending on the cause of the error, you may want to restart these steps from the beginning.
diff --git a/content/tutorials/manage-account-settings/offline-account-setup.ja.md b/content/tutorials/manage-account-settings/offline-account-setup.ja.md
index 8132ece33d..cc31ee6088 100644
--- a/content/tutorials/manage-account-settings/offline-account-setup.ja.md
+++ b/content/tutorials/manage-account-settings/offline-account-setup.ja.md
@@ -137,10 +137,10 @@ Loading: "/etc/opt/ripple/rippled.cfg"
- ユーザーが送金理由や送金相手をタグ付けせずに送金できないようにするために、[宛先タグを要求する](require-destination-tags.html)。
- アカウントセキュリティを強化するために、[マルチ署名を設定する](set-up-multi-signing.html)。
- 明示的に承認した送金、または事前に承認した相手からの送金のみを受け取れるようにするために、[DepositAuthを有効にする](depositauth.html)。
-- ユーザーがあなたの許可なくあなたへの[トラストライン](trust-lines-and-issuing.html)を開けないようにするために、[RequireAuthを有効にする](become-an-xrp-ledger-gateway.html#enabling-requireauth)。XRP Ledgerの分散型取引所や発行済み通貨機能を使用する予定がない場合は、これを対策として行うことをお勧めします。
+- ユーザーがあなたの許可なくあなたへの[トラストライン](trust-lines-and-issuing.html)を開けないようにするために、[RequireAuthを有効にする](become-an-xrp-ledger-gateway.html#enabling-require-auth)。XRP Ledgerの分散型取引所や発行済み通貨機能を使用する予定がない場合は、これを対策として行うことをお勧めします。
- 発行済み通貨[ゲートウェイ](become-an-xrp-ledger-gateway.html)には次のような追加の設定がある場合があります。
- - 発行済み通貨を送金するユーザーに対して[TransferRateを設定する](become-an-xrp-ledger-gateway.html#transferrate)。
- - このアドレスを発行済み通貨のみに使用する予定の場合は、[XRPペイメントを禁止する](become-an-xrp-ledger-gateway.html#disallowxrp)。
+ - 発行済み通貨を送金するユーザーに対して[TransferRateを設定する](become-an-xrp-ledger-gateway.html#transfer-fees)。
+ - このアドレスを発行済み通貨のみに使用する予定の場合は、[XRPペイメントを禁止する](become-an-xrp-ledger-gateway.html#disallow-xrp)。
この段階では、トランザクションに署名をするだけで、まだ送信しません。各トランザクションに対して、`Fee`（[トランザクションコスト](transaction-cost.html)）や`Sequence`（[シーケンス番号][]）など、通常は自動入力可能なフィールドを含めて、すべてのフィールドに入力する必要があります。一度に複数のトランザクションを準備する場合は、トランザクションの実行順にシーケンシャルに増やした`Sequence`番号を使用する必要があります。
diff --git a/content/tutorials/manage-account-settings/offline-account-setup.md b/content/tutorials/manage-account-settings/offline-account-setup.md
index 56462765f3..e47a3b7f86 100644
--- a/content/tutorials/manage-account-settings/offline-account-setup.md
+++ b/content/tutorials/manage-account-settings/offline-account-setup.md
@@ -30,7 +30,7 @@ Software options for signing on the XRP Ledger include:
- Install [ripple-lib](rippleapi-reference.html) and its dependencies offline. The Yarn package manager, for example, has [recommended instructions for offline usage](https://yarnpkg.com/blog/2016/11/24/offline-mirror/).
- See also: [Set Up Secure Signing](set-up-secure-signing.html)
-You may want to set up custom software to facilitate the process of constructing transaction instructions on the offline machine. For example, your software may track what [sequence number][] to use next, or contain preset templates for certain types of transactions you expect to send.
+You may want to set up custom software to help construct transaction instructions on the offline machine. For example, your software may track what [sequence number][] to use next, or contain preset templates for certain types of transactions you expect to send.
### {{n.next()}}. Generate cryptographic keys
@@ -65,11 +65,13 @@ Loading: "/etc/opt/ripple/rippled.cfg"
Take note of the following values:
- **`account_id`**. This is the address associated with the key pair, which will become your **[account](accounts.html) address** in the XRP Ledger after you fund it with XRP (later in this process). It is safe to share your `account_id` publicly.
-- **`master_seed`**. This is the secret seed value for the keypair, which you'll use to sign transactions from the account. For best security, encrypt this value before writing it to disk on the offline machine. As an encryption key, use a secure passphrase that human operators can memorize or write down somewhere physically secure, such as a [diceware passphrase](http://world.std.com/~reinhold/diceware.html) created with properly weighted dice. You may also want to use a physical security key as a second factor. The extent of the precautions to take at this stage is up to you.
+- **`master_seed`**. This is the secret seed value for the key pair, which you'll use to sign transactions from the account. For best security, encrypt this value before writing it to disk on the offline machine. As an encryption key, use a secure passphrase that human operators can memorize or write down somewhere physically secure, such as a [diceware passphrase](http://world.std.com/~reinhold/diceware.html) created with properly weighted dice. You may also want to use a physical security key as a second factor. The extent of the precautions to take at this stage is up to you.
- **`key_type`**. This is the cryptographic algorithm used for this key pair. You need to know what type of key pair you have in order to sign valid transactions. The default is `secp256k1`.
**Do not** share the `master_key`, `master_seed`, or `master_seed_hex` values anywhere. Any of these can be used to reconstruct the private key associated with this address.
+
+
### {{n.next()}}. Fund the new address
@@ -137,14 +139,14 @@ On the offline machine, prepare and sign transactions for configuring your accou
- [Require destination tags](require-destination-tags.html) so that users can't send you payments without tagging the reason they sent it or the customer it's intended for.
- [Set Up Multi-Signing](set-up-multi-signing.html) for a higher bar of account security.
- [Enable DepositAuth](depositauth.html) so you can only receive payments you've explicitly accepted or from parties you've pre-approved.
-- [Enable RequireAuth](become-an-xrp-ledger-gateway.html#enabling-requireauth) so that users can't open [trust lines](trust-lines-and-issuing.html) to you without your permission. If you don't plan to use the XRP Ledger's decentralized exchange or issued currency features, you may want to do this as a precaution.
+- [Require Auth](become-an-xrp-ledger-gateway.html#enabling-require-auth) so that users can't open [trust lines](trust-lines-and-issuing.html) to you without your permission. If you don't plan to use the XRP Ledger's decentralized exchange or issued currency features, you may want to do this as a precaution.
- Issued currency [Gateways](become-an-xrp-ledger-gateway.html) may have additional setup, such as:
- - [Set a TransferRate](become-an-xrp-ledger-gateway.html#transferrate) for users transferring your issued currencies.
- - [Disallow XRP payments](become-an-xrp-ledger-gateway.html#disallowxrp) if you plan to use this address for issued currencies only.
+ - [Set a Transfer Fee](become-an-xrp-ledger-gateway.html#transfer-fees) for users transferring your issued currencies.
+ - [Disallow XRP payments](become-an-xrp-ledger-gateway.html#disallow-xrp) if you plan to use this address for issued currencies only.
At this stage, you are only signing the transactions, not submitting them. For each transaction, you must provide all fields, including fields that are normally auto-fillable such as the `Fee` ([transaction cost](transaction-cost.html)) and `Sequence` ([sequence number][]). If you prepare multiple transactions at the same time, you must use sequentially increasing `Sequence` numbers in the order you want the transactions to execute.
-Example (enable RequireAuth):
+Example (enable Require Auth):
diff --git a/content/tutorials/manage-account-settings/set-up-multi-signing.md b/content/tutorials/manage-account-settings/set-up-multi-signing.md
index ee2704abf0..0ed61d9c01 100644
--- a/content/tutorials/manage-account-settings/set-up-multi-signing.md
+++ b/content/tutorials/manage-account-settings/set-up-multi-signing.md
@@ -51,9 +51,9 @@ Take note of the `account_id` (XRP Ledger Address) and `master_seed` (secret key
## 3. Send SignerListSet transaction
-[Sign and submit](transaction-basics.html#signing-and-submitting-transactions) a [SignerListSet transaction][] in the normal (single-signature) way. This associates a SignerList with your XRP Ledger address, so that a combination of signatures from the members of that SignerList can multi-sign later transactions on your behalf.
+[Sign and submit](transaction-basics.html#signing-and-submitting-transactions) a [SignerListSet transaction][] in the normal (single-signature) way. This associates a signer list with your XRP Ledger address, so that a combination of signatures from the members of that signer list can multi-sign later transactions on your behalf.
-In this example, the SignerList has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW plus at least one signature from the other two members of the list.
+In this example, the signer list has 3 members, with the weights and quorum set up such that multi-signed transactions need a signature from `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW` plus at least one signature from the other two members of the list.
{% include '_snippets/secret-key-warning.md' %}
@@ -128,9 +128,9 @@ In this example, the SignerList has 3 members, with the weights and quorum set u
}
}
-Make sure that the [Transaction Result](transaction-results.html) is [**tesSUCCESS**](tes-success.html). Otherwise, the transaction failed. If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](start-a-new-genesis-ledger-in-stand-alone-mode.html#settings-in-new-genesis-ledgers).
+Make sure that the [Transaction Result](transaction-results.html) is [**`tesSUCCESS`**](tes-success.html). Otherwise, the transaction failed. If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](start-a-new-genesis-ledger-in-stand-alone-mode.html#settings-in-new-genesis-ledgers).
-**Note:** Without the [MultiSignReserve amendment][], the more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](tec-codes.html). With the [MultiSignReserve amendment][] enabled, the XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves) is 5 XRP, regardless of the number of members in the SignerList. See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves).
+**Note:** Without the [MultiSignReserve amendment][], the more members in the signer list, the more XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [`tecINSUFFICIENT_RESERVE`](tec-codes.html). With the [MultiSignReserve amendment][] enabled, the XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves) is 5 XRP, regardless of the number of members in the signer list. See also: [Signer Lists and Reserves](signerlist.html#signer-lists-and-reserves).
## 4. Wait for validation
@@ -140,9 +140,9 @@ Make sure that the [Transaction Result](transaction-results.html) is [**tesSUCCE
## 5. Confirm the new signer list
-Use the [account_objects method][] to confirm that the SignerList is associated with the address in the latest validated ledger.
+Use the [account_objects method][] to confirm that the signer list is associated with the address in the latest validated ledger.
-Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response.
+Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the signer list is the only object in the response.
$ rippled account_objects rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC validated
Loading: "/etc/opt/ripple/rippled.cfg"
@@ -189,7 +189,7 @@ Normally, an account can own many objects of different types (such as trust line
}
}
-If the SignerList is present with the expected contents, then your address is ready to multi-sign.
+If the signer list is present with the expected contents, then your address is ready to multi-sign.
## 6. Further steps
diff --git a/content/tutorials/manage-the-rippled-server/configuration/configure-advisory-deletion.md b/content/tutorials/manage-the-rippled-server/configuration/configure-advisory-deletion.md
index 8cab617624..d1028dbde4 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/configure-advisory-deletion.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/configure-advisory-deletion.md
@@ -88,7 +88,7 @@ To configure advisory deletion with a daily schedule, perform the following step
If online deletion does not seem to be running after configuring it, try the following:
- Check that the user who configured the `cron` job has permissions to run the `rippled` server as a commandline client.
-- Check the syntax of your cron job and the time when it is supposed to run.
+- Check the syntax of your `cron` job and the time when it is supposed to run.
- Check that the `rippled` executable is available at the path specified in your `cron` configuration. If necessary, specify the absolute path to the executable, such as `/opt/ripple/bin/rippled`.
- Check your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.html#interrupting-online-deletion) because your server fell out of sync with the network.
diff --git a/content/tutorials/manage-the-rippled-server/configuration/configure-grpc.md b/content/tutorials/manage-the-rippled-server/configuration/configure-grpc.md
index 51661e8d88..a688ad7799 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/configure-grpc.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/configure-grpc.md
@@ -25,7 +25,7 @@ To enable gRPC on your server, complete the following steps:
The configurable fields are as follows:
- `port` field defines the port the server listens on for gRPC connections from client applications. The recommended port is `50051`.
- - `ip` defines which interfaces the server listens on. The value `0.0.0.0` listens on all available network interfaces. To limit connections to just the local loopback network (same machine), use `127.0.0.1` instead.
+ - `ip` defines which interfaces the server listens on. The value `0.0.0.0` listens on all available network interfaces. To limit connections to the local loopback network (same machine), use `127.0.0.1` instead.
{% include '_snippets/conf-file-location.md' %}
diff --git a/content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.md b/content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.md
index 144dc1b93c..e88072a952 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.md
@@ -20,6 +20,8 @@ Before you configure your `rippled` server to store history shards, you must dec
## 2. Edit rippled.cfg
+
+
Edit your `rippled.cfg` file to add a `[shard_db]` stanza.
{% include '_snippets/conf-file-location.md' %}
diff --git a/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md b/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
index 456e534c9f..ddc9f54b8e 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
@@ -7,87 +7,84 @@ Rippleは[代替となるテスト用および開発用ネットワーク](paral
`rippled`サーバーをXRP TestnetまたはDevnetに接続するには、以下の構成を設定します。
1. `rippled.cfg`ファイルで以下の手順に従います。
-
+
a. [Testnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
-
+
[ips]
s.altnet.rippletest.net 51235
-
+
b. [Devnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
-
+
[ips]
s.devnet.rippletest.net 51235
-
+
c. 以下のセクションを次のようにコメントアウトします。
-
+
# [ips]
# r.ripple.com 51235
2. `validators.txt`ファイルで以下の手順に従います。
-
+
2a. Altnetに接続するための変更
-
+
a. 以下のセクションのコメントを解除し、Altnetに接続するようにします。
-
+
[validator_list_sites]
https://vl.altnet.rippletest.net
-
+
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
-
+
b. 以下のセクションを次のようにコメントアウトします。
-
+
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
-
+
2b. Devnetに接続するための変更
-
+
a. 以下のセクションをコメントアウトします。
-
+
# [validator_list_sites]
# https://vl.altnet.rippletest.net
-
+
# [validator_list_keys]
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
-
+
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
-
+
b. 次の信頼できるバリデータをvalidator.txtファイルに追加します。
-
- # Hard-coded List of Devnet Validators
- [validators]
- n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
- n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
- n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
- n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
- n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
- n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
- n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
+
+ [validator_list_sites]
+ https://vl.devnet.rippletest.net/index.json
+
+ [validator_list_keys]
+ EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
+
3. `rippled`を再起動します。
4. `rippled`がXRP TestnetまたはDevnetに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTestnetまたはDevnetの公開サーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
-
+
以下のコマンドは、`s.altnet.rippletest.net`にあるTestnetサーバーの最新の検証済みレジャーをチェックします。
-
+
$ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq
-
+
以下のコマンドは、`s.devnet.rippletest.net`にあるDevnetサーバーの最新の検証済みレジャーをチェックします。
-
+
$ ./rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq
-
+
以下のコマンドは、ローカルの`rippled`の最新検証済みレジャーインデックスをチェックします。
-
+
$ ./rippled server_info | grep seq
diff --git a/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md b/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md
index 413de1ecee..0f6508dd5a 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md
@@ -1,43 +1,84 @@
-# Connect Your rippled to an XRPL Altnet
+# Connect Your rippled to a Parallel Network
-Ripple has created [alternative test and development networks](parallel-networks.html) for developers to test their apps on the latest non-production version of the XRP Ledger (Testnet) or to test and experiment with features on the latest beta version (Devnet). **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](the-rippled-server.html) to either the Testnet or Devnet.
+Ripple hosts [alternative test and development networks](parallel-networks.html) for developers to test their apps on the latest non-production version of the XRP Ledger (Testnet) or to test and experiment with features on the latest beta version (Devnet). **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](the-rippled-server.html) to either the Testnet or Devnet.
-**Note:** The XRP Testnet and Devnet ledger and balances are reset on a regular basis.
+**Caution:** The Devnet frequently has new and experimental [amendments](amendments.html) enabled, so the latest production release version is likely to be amendment blocked when connecting to Devnet. You should use a pre-release or nightly build when connecting to Devnet.
-To connect your `rippled` server to the XRP Testnet or Devnet, set the following configurations:
+## Steps
-1. In your `rippled.cfg` file:
+To connect your `rippled` server to the XRP Testnet or Devnet, complete these steps. You can also use these steps to switch back to the production Mainnet after being on the Testnet or Devnet.
- a. To connect to the [Testnet](xrp-testnet-faucet.html), uncomment the following section and add:
+## 1. Configure your server to connect to the right hub.
+
+Edit your `rippled.cfg` file.
+
+{% include '_snippets/conf-file-location.md' %}
+
+
+1. Set an `[ips]` stanza with the hub for the network you want to connect to:
+
+
+
+ *Testnet*
[ips]
s.altnet.rippletest.net 51235
- b. To connect to the [Devnet](xrp-testnet-faucet.html), uncomment the following section and add:
+ *Devnet*
[ips]
s.devnet.rippletest.net 51235
- c. Comment out the following section, as follows:
+ *Mainnet*
+
+ # No [ips] stanza. Use the default hubs to connect to Mainnet.
+
+
+3. Comment out the previous `[ips]` stanza, if there is one:
# [ips]
# r.ripple.com 51235
+ # zaphod.alloy.ee 51235
+ # sahyadri.isrdc.in 51235
+
+## 2. Set your trusted validator list.
+
+Edit your `validators.txt` file. This file is located in the same folder as your `rippled.cfg` file and defines which validators your server trusts not to collude.
+
+1. Uncomment or add the `[validator_list_sites]` and `[validator_list_keys]` stanzas for the network you want to connect to:
+
+
+
+ *Testnet*
+
+ [validator_list_sites]
+ https://vl.altnet.rippletest.net
+
+ [validator_list_keys]
+ ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
+
+ *Devnet*
+
+ [validator_list_sites]
+ https://vl.devnet.rippletest.net
+
+ [validator_list_keys]
+ EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
+ *Mainnet*
-2. In your `validators.txt` file:
+ [validator_list_sites]
+ https://vl.ripple.com
- 2a. Changes to connect to the Testnet
+ [validator_list_keys]
+ ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
- a. Uncomment the following sections, as follows to connect to the altnet:
+
- [validator_list_sites]
- https://vl.altnet.rippletest.net
+1. Comment out any previous `[validator_list_sites]`, `[validator_list_keys]`, or `[validators]` stanzas.
- [validator_list_keys]
- ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
-
- b. Comment out the following sections, as follows:
+ For example:
# [validator_list_sites]
# https://vl.ripple.com
@@ -45,57 +86,71 @@ To connect your `rippled` server to the XRP Testnet or Devnet, set the following
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
- 2b. Changes to connect to the Devnet
+ # Old hard-coded List of Devnet Validators
+ # [validators]
+ # n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
+ # n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
+ # n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
+ # n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
+ # n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
+ # n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
+ # n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
- a. Comment out the following sections as follows:
+## 3. Restart the server.
- # [validator_list_sites]
- # https://vl.altnet.rippletest.net
+```
+$ sudo systemctl restart rippled
+```
- # [validator_list_keys]
- # ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
+## 4. Verify that your server syncs.
- # [validator_list_sites]
- # https://vl.ripple.com
- #
- # [validator_list_keys]
- # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
+It takes about 5 to 15 minutes to sync to the network after a restart. After your server is synced, the [server_info method][] shows the a `validated_ledger` object based on the network you are connected to.
- b. Add the following trusted validators to the validator.txt file:
+To verify that your `rippled` is connected to the XRP Testnet or Devnet, compare the results from your server to [a public server](get-started-with-the-rippled-api.html#public-servers) on the Testnet or Devnet. The `seq` field of the `validated_ledger` object should be the same on both servers (possibly off by one or two, if it changed as you were checking).
- # Hard-coded List of Devnet Validators
- [validators]
- n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
- n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
- n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
- n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
- n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
- n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
- n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
+The following example shows how to check the latest validated ledger from the commandline:
+
+
+
+*Local Server*
+
+```sh
+$ rippled server_info | grep seq
+```
+
+*Testnet*
+
+```sh
+# s.altnet.rippletest.net
+$ rippled --rpc_ip 35.158.96.209:51234 server_info | grep seq
+```
+
+*Devnet*
+
+```sh
+# s.devnet.rippletest.net
+$ rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq
+```
-3. Restart `rippled`.
+*Mainnet*
-4. To verify that your `rippled` is connected to the XRP Testnet or Devnet, use the [server_info method][] on your server and compare it to the results from a public server on the Testnet or Devnet. The `seq` field of the `validated_ledger` object should be the same on both servers (possibly off by one or two, if it changed as you were checking).
+```sh
+# s1.ripple.com
+$ rippled --rpc_ip 34.201.59.230:51234 server_info | grep seq
+```
- The following command checks the latest validated ledger of a Testnet server at `s.altnet.rippletest.net`:
+
- $ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq
+**Note:** The IP addresses in these examples are for public servers, and may change periodically. If you get no response, look up the IP address of a [public server](get-started-with-the-rippled-api.html#public-servers), for example using the `dig` command.
- The following command checks the latest validated ledger of a Devnet server at `s.devnet.rippletest.net`:
-
- $ ./rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq
-
- The following command checks your local `rippled`'s latest validated ledger index:
-
- $ ./rippled server_info | grep seq
## See Also
- **Tools:**
- [XRP Faucets](xrp-testnet-faucet.html)
- - [WebSocket API Tool](websocket-api-tool.html) - Select 'Testnet Public Server' in the connection options.
+ - [WebSocket API Tool](websocket-api-tool.html) - Select 'Testnet Public Server' or 'Devnet Public Server' in the connection options.
- **Concepts:**
- [Parallel Networks](parallel-networks.html)
- [Introduction to Consensus](intro-to-consensus.html)
diff --git a/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md b/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md
index f2b3bfe378..e6041b9cd2 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md
@@ -34,7 +34,7 @@ Strive to have your validator always embody the following properties. Being a go
- **Identified**
- A good validator has a clearly identified owner. Providing [domain verification](#6-provide-domain-verification) is a good start. Ideally, XRP Ledger network UNLs include validators operated by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators.
+ A good validator has a clearly identified owner. Providing [domain verification](#6-provide-domain-verification) is a good start. Ideally, XRP Ledger network UNLs include validators run by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators.
Ripple (the company) publishes a [validator list](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt) with a set of recommended validators. Ripple strongly recommends using exactly this list for production servers.
@@ -48,7 +48,7 @@ For more information, see [Install `rippled`](install-rippled.html).
## 3. Enable validation on your `rippled` server
-Enabling validation on your `rippled` server means providing a validator token in your server's `rippled.cfg` file. Ripple recommends using the `validator-keys` tool (included in `rippled` RPMs) to securely generate and manage your validator keys and tokens.
+Enabling validation on your `rippled` server means providing a validator token in your server's `rippled.cfg` file. Ripple recommends using the `validator-keys` tool (included in `rippled` packages) to securely generate and manage your validator keys and tokens.
In a location **not** on your validator:
@@ -80,7 +80,7 @@ In a location **not** on your validator:
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
- Sample output:
+ Sample output:
Update rippled.cfg file with these values:
@@ -133,7 +133,7 @@ For a comparison of these approaches, see [Pros and Cons of Peering Configuratio
This configuration connects your validator to the XRP Ledger network using [discovered peers](peer-protocol.html#peer-discovery). This is the default behavior for `rippled` servers.
-_**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example rippled.cfg file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
+_**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example `rippled.cfg` file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
### Connect using proxies
@@ -225,13 +225,13 @@ Here are some methods you can use to verify that your validator has a healthy co
## 6. Provide domain verification
-To help validation list publishers and other participants in the XRP Ledger network understand who operates your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link:
+To help validation list publishers and other participants in the XRP Ledger network understand who runs your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link:
- Use your domain to claim ownership of a validator key.
- Use your validator key to claim ownership of a domain.
-Creating this link establishes strong evidence that you own both the validator key and the domain. Providing this evidence is just one aspect of [being a good validator](#1-understand-the-traits-of-a-good-validator).
+Creating this link establishes strong evidence that you own both the validator key and the domain. Providing this evidence is one aspect of [being a good validator](#1-understand-the-traits-of-a-good-validator).
To provide domain verification:
@@ -259,7 +259,7 @@ To provide domain verification:
Provide the value returned in the **SSL Signature** field of the Google Form.
- 3. Using the [`validator-keys` tool](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) (included in `rippled` RPMs), sign the domain name.
+ 3. Using the [`validator-keys` tool](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) (included in `rippled` packages), sign the domain name.
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
diff --git a/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-wallet-server.md b/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-wallet-server.md
index 1aa8dc5346..506215eabc 100644
--- a/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-wallet-server.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-wallet-server.md
@@ -18,14 +18,12 @@ A wallet server does all of the following:
For more information, see [Install `rippled`](install-rippled.html).
-
-
## 2. Enable validation on your wallet server
For more information, see [Enable validation on your `rippled` server](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).
-**Warning:** Validators should not be accessible to the public. Do not allow public websockets access to your wallet server or any other form of public access.
-
+**Warning:** Validators should not be accessible to the public. Do not allow public WebSocket access to your wallet server or any other form of public access.
+
## 3. Provide domain verification
For more information, see [Provide domain verification](run-rippled-as-a-validator.html#6-provide-domain-verification).
diff --git a/content/tutorials/manage-the-rippled-server/configure-peering/cluster-rippled-servers.md b/content/tutorials/manage-the-rippled-server/configure-peering/cluster-rippled-servers.md
index ef31cf2364..7283a27c6e 100644
--- a/content/tutorials/manage-the-rippled-server/configure-peering/cluster-rippled-servers.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/cluster-rippled-servers.md
@@ -33,6 +33,8 @@ If you run multiple [`rippled` servers](the-rippled-server.html) in the same dat
This defines specific peer servers to which this server should always attempt to maintain a direct peer-to-peer connection.
+ **Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the [XRP Ledger protocol](peer-protocol.html). [New in: rippled 1.6.0][]
+
2. In the `[node_seed]` section, set the server's node seed to one of the `validation_seed` values you generated using the [validation_create method][] in step 2. Each server must use a unique node seed. For example:
[node_seed]
diff --git a/content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md b/content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md
index 6b01847b3f..5a83208cd8 100644
--- a/content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md
@@ -40,9 +40,11 @@ To set up a specific server as a private peer, complete the following steps:
If your server connects using **proxies**, the IP addresses and ports should match the configurations of the `rippled` servers you are using as proxies. For each of those servers, the port number should match the `protocol = peer` port in that server's config file (usually 51235). For example, your configuration might look like this:
- [ips_fixed]
- 192.168.0.1 51235
- 192.168.0.2 51235
+ [ips_fixed]
+ 192.168.0.1 51235
+ 192.168.0.2 51235
+
+ **Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the [XRP Ledger protocol](peer-protocol.html). [New in: rippled 1.6.0][]
4. If using proxies, cluster them with your private peer and each other.
diff --git a/content/tutorials/manage-the-rippled-server/configure-peering/enable-link-compression.md b/content/tutorials/manage-the-rippled-server/configure-peering/enable-link-compression.md
new file mode 100644
index 0000000000..def56fb0c2
--- /dev/null
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/enable-link-compression.md
@@ -0,0 +1,52 @@
+---
+html: enable-link-compression.html
+funnel: Docs
+doc_type: Tutorials
+category: Manage the rippled Server
+subcategory: Configure Peering
+blurb: Save bandwidth by compressing peer-to-peer communications.
+---
+# Enable Link Compression
+
+The `rippled` server can save bandwidth by compressing its [peer-to-peer communications](peer-protocol.html), at a cost of greater CPU usage. If you enable link compression, the server automatically compresses communications with peer servers that also have link compression enabled. [New in: rippled 1.6.0][]
+
+## Steps
+
+To enable link compression on your server, complete the following steps:
+
+### 1. Edit your `rippled` server's config file.
+
+```sh
+$ vim /etc/opt/ripple/rippled.cfg
+```
+
+{% include '_snippets/conf-file-location.md' %}
+
+### 2. In the config file, add or uncomment the `[compression]` stanza.
+
+To enable compression:
+
+```text
+[compression]
+true
+```
+
+Use `false` to disable compression (the default).
+
+### 3. Restart the `rippled` server
+
+```sh
+$ sudo systemctl restart rippled.service
+```
+
+After the restart, your server automatically uses link compression with other peers that also have link compression enabled.
+
+## See Also
+
+- [Capacity Planning](capacity-planning.html)
+- [Peer Protocol](peer-protocol.html)
+
+
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.md b/content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.md
index eef5bb42cf..3b214f0afe 100644
--- a/content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.md
@@ -8,8 +8,8 @@ Use these steps to manually connect your server to a specific [peer](peer-protoc
## Prerequisites
- You must know the IP address of the peer you want to connect to.
-- You must know what port the peer you want to connect to uses for the XRP Ledger [peer protocol](peer-protocol.html). By default, this is port 51235.
-- You must have a network connection from your server to the peer. For example, the peer server must [forward the apppropriate port through its firewall](forward-ports-for-peering.html).
+- You must know what port the peer you want to connect to uses for the XRP Ledger [peer protocol](peer-protocol.html). The default config file uses port 51235.
+- You must have a network connection from your server to the peer. For example, the peer server must [forward the appropriate port through its firewall](forward-ports-for-peering.html).
- The peer server must have available peer slots. If the peer is already at its maximum number of peers, you can ask the peer server's operator to add a [peer reservation](use-a-peer-reservation.html) for your server.
## Steps
diff --git a/content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md b/content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md
index 95824875bd..d2f597fe10 100644
--- a/content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md
@@ -150,7 +150,7 @@ As a server administrator, you can manage the reservations your server has for o
- Remove one of your reservations using the [peer_reservations_del method][].
- Check which peers are currently connected and how much bandwidth they have used, using the [peers method][].
-**Tip:** Although there is no API method to immediately disconnect from an unwanted peer, you can use a software firewall such as `firewalld` to block an unwanted peer from connecting to your server. For examples, see the community-contributed [rbh script](https://github.com/gnanderson/rbh).
+**Tip:** Although there is no API method to immediately disconnect from an unwanted peer, you can use a software firewall such as `firewalld` to block an unwanted peer from connecting to your server. For examples, see the community-contributed [rbh script](https://github.com/gnanderson/rbh).
## See Also
diff --git a/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.md b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.md
index f2a315e2b6..931122c299 100644
--- a/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.md
+++ b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.md
@@ -6,7 +6,7 @@ That said, macOS is suitable for many development and testing tasks. `rippled` h
For development purposes, run `rippled` as a non-admin user, not using `sudo`.
-1. Install [Xcode](https://developer.apple.com/download/).
+1. Install [Xcode](https://developer.apple.com/download/).
0. Install Xcode command line tools.
@@ -42,7 +42,7 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
2. Edit below code with your Boost directory location and run to add Boost environment variable to your `.bash_profile` file so it's automatically set when you log in.
- $ echo $"export BOOST_ROOT=/Users/my_user/boost_1_71_0" >> ~/.bash_profile
+ $ echo "export BOOST_ROOT=/Users/my_user/boost_1_71_0" >> ~/.bash_profile
0. If you updated your `.bash_profile` file in the previous step, be sure to source it in a new Terminal window. For example:
@@ -53,19 +53,23 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
$ git clone git@github.com:ripple/rippled.git
$ cd rippled
-0. By default, cloning puts you on the `develop` branch. Use this branch if you are doing development work and want the latest set of untested features.
+0. Switch to the appropriate branch for the software version you want:
- If you want the latest stable release, checkout the `master` branch.
+ For the latest stable release, use the `master` branch.
$ git checkout master
- If you want to test out the latest release candidate, checkout the `release` branch:
+ For the latest release candidate, use the `release` branch:
$ git checkout release
- Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
+ For the latest in-progress version, use the `develop` branch:
-0. In the `rippled` directory you just cloned, create your build directory and access it. For example:
+ $ git checkout develop
+
+ Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
+
+0. In the `rippled` directory you cloned, create your build directory and access it. For example:
$ mkdir my_build
$ cd my_build
diff --git a/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.md b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.md
index e346a4fa28..38cebb7f67 100644
--- a/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.md
+++ b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.md
@@ -87,17 +87,17 @@ These instructions use Ubuntu's APT (Advanced Packaging Tool) to install the sof
7. Check the commit log to be sure you're compiling the version you intend to. The most recent commit should be signed by a well-known Ripple developer and should set the version number to the latest released version. For example:
$ git log -1
+ commit 01bd5a2646cda78ee09d2067c287c8f89872736d
+ Author: manojsdoshi
+ Date: Tue Aug 18 15:32:50 2020 -0700
- commit 06c371544acc3b488b9d9c057cee4e51f6bef7a2
- Author: Nik Bougalis
- Date: Mon Nov 25 22:58:03 2019 -0800
-
- Set version to 1.4.0
+ Set version to 1.6.0
-8. If you previously built, or (more importantly) tried and failed to build `rippled`, you should delete the `my_build/` directory (or whatever you named it) to start clean before moving on to the next step. Otherwise, you may get unexpected behavior, like a `rippled` executable that crashes due to a segmentation fault (segfault).
+
+8. If you previously built, or (more importantly) tried and failed to build `rippled`, you should delete the `my_build/` directory (or whatever you named it) to start clean before moving on to the next step. Otherwise, you may get unexpected behavior, like a `rippled` executable that crashes due to a segmentation fault (segfault).
If this is your first time building `rippled` 1.0.0 or higher, you won't have a `my_build/` directory and can move on to the next step.
diff --git a/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md
index a7684f7250..7986c3f103 100644
--- a/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md
+++ b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md
@@ -1,3 +1,11 @@
+---
+html: capacity-planning.html
+funnel: Docs
+doc_type: Tutorials
+category: Manage the rippled Server
+subcategory: Installation
+blurb: Plan system specs and tune configuration for rippled in production environments.
+---
# Capacity Planning
This section describes configuration, network, and hardware recommendations that you can use to tune and optimize the performance of your `rippled` server. Being aware of these considerations can help you ensure that your `rippled` server is ready to handle XRP Ledger network capacity today and in the near future.
@@ -19,16 +27,16 @@ Ripple recommends you always use the largest node size your available RAM can su
#### Recommendation
-Each `node_size` has a corresponding requirement for available RAM. For example, if you set `node_size` to `huge`, you should have at least 32GB of available RAM to help ensure that `rippled` can run smoothly.
+Each `node_size` has a corresponding requirement for available RAM. For example, if you set `node_size` to `huge`, you should have at least 32 GB of available RAM to help ensure that `rippled` can run smoothly.
To tune your server, it may be useful to start with `tiny` and increase the size to `small`, `medium`, and so on as you refine the requirements for your use case.
| RAM available for `rippled` | `node_size` value | Notes |
|:----------------------------|:------------------|:---------------------------|
-| < 8GB | `tiny` | Not recommended for testing or production servers. This is the default value if you don't specify a value in `rippled.cfg`. |
-| 8GB | `small` | Recommended for test servers. |
-| 16GB | `medium` | The `rippled-example.cfg` file uses this value. |
-| 32GB | `huge` | Recommended for production servers. |
+| < 8 GB | `tiny` | Not recommended for testing or production servers. This is the default value if you don't specify a value in `rippled.cfg`. |
+| 8 GB | `small` | Recommended for test servers. |
+| 16 GB | `medium` | The `rippled-example.cfg` file uses this value. |
+| 32 GB | `huge` | Recommended for production servers. |
Although `large` is also a legal value for `[node_size]`, in practice it performs worse than `huge` in most circumstances. Ripple recommends always using `huge` instead of `large`.
@@ -47,13 +55,13 @@ You can set the value to either `RocksDB` or `NuDB`.
- For most cases, use `NuDB` because its performance is constant even with large amounts of data on disk. A fast SSD is required. [Learn more](#more-about-using-nudb)
-- If you are using rotational disks (not recommended) or even just a slow SSD, use `RocksDB`. [Learn more](#more-about-using-rocksdb)
+- If you are using rotational disks (not recommended) or an unusually slow SSD, use `RocksDB`. [Learn more](#more-about-using-rocksdb)
The example `rippled-example.cfg` file has the `type` field in the `[node_db]` stanza set to `RocksDB`.
#### More About Using RocksDB
-[RocksDB](https://rocksdb.org/docs/getting-started.html) is an embeddable persistent key-value store.
+[RocksDB](https://rocksdb.org/docs/getting-started.html) is an persistent key-value store built into `rippled`.
RocksDB works well on solid-state disks. RocksDB performs better than NuDB when used with rotational disks, but you may still encounter performance problems unless you use solid-state disks.
@@ -121,7 +129,7 @@ For best performance in enterprise production environments, Ripple recommends ru
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
- Disk speed: SSD (7000+ writes/second, 10,000+ reads/second)
- Disk space: Varies. At least 50 GB recommended.
-- RAM: 32GB
+- RAM: 32 GB
- Network: Enterprise data center network with a gigabit network interface on the host
#### CPU Utilization and Virtualization
@@ -165,7 +173,7 @@ If you want to contribute to storing ledger history but you do not have enough d
##### Amazon Web Services
-Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run `rippled` in AWS, but Ripple does not recommend using Elastic Block Storage (EBS). Elastic Block Storage's maximum number of IOPS (5,000) is insufficient for `rippled`'s heaviest loads, despite being very expensive.
+Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run `rippled` in AWS, but Ripple does not recommend using Elastic Block Storage (EBS). Elastic Block Storage's maximum number of IOPS (5,000) is insufficient for `rippled`'s heaviest loads, despite being very expensive.
AWS instance stores (`ephemeral` storage) do not have these constraints. Therefore, Ripple recommends deploying `rippled` servers with host types such as `M3` that have instance storage. The `database_path` and `node_db` path should each reside on instance storage.
@@ -177,15 +185,20 @@ Memory requirements are mainly a function of the `node_size` configuration setti
#### Network
-Any enterprise or carrier-class data center should have substantial network bandwidth to support running `rippled` servers.
+Any enterprise or carrier-class data center should have substantial network bandwidth to support running `rippled` servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](ledger-history.html)) also affects network use.
-Here are examples of observed network bandwidth use for common `rippled` tasks:
+During exceptionally high periods of transaction volume, some operators have reported that their `rippled` servers have completely saturated a 100 MBit/s network link. Therefore, a gigabit network interface is required for reliable performance.
+
+Here are examples of observed uncompressed network bandwidth use for common `rippled` tasks:
| Task | Transmit/Receive |
|:------------------------------------------------|:---------------------------|
-| Process current transaction volumes | 2Mbps transmit, 2 Mbps receive |
-| Serve historical ledger and transaction reports | 100Mbps transmit |
-| Start up `rippled` | 20Mbps receive |
+| Process average transaction volumes | 2 Mbps transmit, 2 Mbps receive |
+| Process peak transaction volumes | >100 Mbps transmit |
+| Serve historical ledger and transaction reports | 100 Mbps transmit |
+| Start up `rippled` | 20 Mbps receive |
+
+You can save bandwidth by [enabling compression on peer-to-peer communications](enable-link-compression.html), at a cost of higher CPU. Many hardware configurations have spare CPU capacity during normal use, so this can be an economical option if your network bandwidth is limited.
## See Also
diff --git a/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.md b/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.md
index caa14c1101..dcc33aa187 100644
--- a/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.md
+++ b/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.md
@@ -14,6 +14,16 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
1. Install the Ripple RPM repository:
+ Choose the appropriate RPM repository for the stability of releases you want:
+
+ - `stable` for the latest production release (`master` branch)
+ - `unstable` for pre-release builds (`release` branch)
+ - `nightly` for experimental/development builds (`develop` branch)
+
+
+
+ *Stable*
+
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
@@ -24,6 +34,33 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
repo_gpgcheck=1
REPOFILE
+ *Pre-release*
+
+ $ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
+ [ripple-unstable]
+ name=XRP Ledger Packages
+ baseurl=https://repos.ripple.com/repos/rippled-rpm/unstable/
+ enabled=1
+ gpgcheck=0
+ gpgkey=https://repos.ripple.com/repos/rippled-rpm/unstable/repodata/repomd.xml.key
+ repo_gpgcheck=1
+ REPOFILE
+
+ *Development*
+
+ $ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
+ [ripple-nightly]
+ name=XRP Ledger Packages
+ baseurl=https://repos.ripple.com/repos/rippled-rpm/nightly/
+ enabled=1
+ gpgcheck=0
+ gpgkey=https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
+ repo_gpgcheck=1
+ REPOFILE
+
+
+
+
2. Fetch the latest repo updates:
$ sudo yum -y update
diff --git a/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.md b/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.md
index 2b02b37f18..f78c4e1019 100644
--- a/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.md
+++ b/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.md
@@ -1,6 +1,6 @@
# Install on Ubuntu or Debian Linux
-This page describes the recommended instructions for installing the latest stable version of `rippled` on **Ubuntu Linux 16.04 or higher** or **Debian 9 (Stretch)**, using the [`apt`](https://help.ubuntu.com/lts/serverguide/apt.html) utility.
+This page describes the recommended instructions for installing the latest stable version of `rippled` on **Ubuntu Linux 16.04 or higher** or **Debian 9 or higher**, using the [`apt`](https://help.ubuntu.com/lts/serverguide/apt.html) utility.
These instructions install a binary that has been compiled by Ripple.
@@ -40,13 +40,15 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
4. Add the appropriate Ripple repository for your operating system version:
- $ echo "deb https://repos.ripple.com/repos/rippled-deb bionic stable" | \
+ $ echo "deb https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
- The above example is appropriate for **Ubuntu 18.04 Bionic Beaver**. For other operating systems, replace the word `bionic` with one of the following:
+ The above example is appropriate for **Ubuntu 20.04 Focal Fossa**. For other operating systems, replace the word `focal` with one of the following:
- - `xenial` for **Ubuntu 16.04 Xenial Xerus**
+ - `bionic` for **Ubuntu 18.04 Bionic Beaver**
+ - `xenial` for **Ubuntu 16.04 Xenial Xerus**
- `stretch` for **Debian 9 Stretch**
+ - `buster` for **Debian 10 Buster**
If you want access to development or pre-release versions of `rippled`, use one of the following instead of `stable`:
diff --git a/content/tutorials/manage-the-rippled-server/installation/system-requirements.md b/content/tutorials/manage-the-rippled-server/installation/system-requirements.md
index 805bd98329..bc578d4b8c 100644
--- a/content/tutorials/manage-the-rippled-server/installation/system-requirements.md
+++ b/content/tutorials/manage-the-rippled-server/installation/system-requirements.md
@@ -8,8 +8,10 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex
- Production: CentOS or RedHat Enterprise Linux (latest release), Ubuntu (16.04+), or Debian (9.x) supported
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
- CPU: 64-bit x86_64, 2+ cores
-- Disk: Minimum 50GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
-- RAM: 8GB+
+- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
+- RAM: 8 GB+
+
+
Amazon EC2's `m3.large` VM size may be appropriate depending on your workload. A fast network connection is preferable. Any increase in a server's client-handling load increases resources needs.
@@ -22,8 +24,8 @@ For best performance in enterprise production environments, Ripple recommends ru
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
- Disk: SSD (7000+ writes/second, 10,000+ reads/second)
- RAM:
- - For testing: 8GB+
- - For production: 32GB
+ - For testing: 8 GB+
+ - For production: 32 GB
- Network: Enterprise data center network with a gigabit network interface on the host
## System Time
diff --git a/content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.md b/content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.md
index 856c207185..f9069d3258 100644
--- a/content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.md
+++ b/content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.md
@@ -12,7 +12,7 @@ To set up automatic updates, complete the following steps:
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
- This cron configuration runs a script to update the installed `rippled` package within an hour of each new release. To reduce the chance of outages from all servers updating simultaneously, the script delays the update for a random number of minutes, up to 59.
+ This configuration runs a script to update the installed `rippled` package within an hour of each new release. To reduce the chance of outages from all servers updating simultaneously, the script delays the update for a random number of minutes, up to 59.
**Caution:** In the future, it is possible that changes to Ripple's repositories may require manual intervention to update the URLs where your script searches for updates. Stay tuned to the [XRP Ledger Blog](/blog/) or the [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) for announcements on any required changes.
diff --git a/content/tutorials/manage-the-rippled-server/stand-alone-mode/start-a-new-genesis-ledger-in-stand-alone-mode.md b/content/tutorials/manage-the-rippled-server/stand-alone-mode/start-a-new-genesis-ledger-in-stand-alone-mode.md
index 317a99c800..93816e7f39 100644
--- a/content/tutorials/manage-the-rippled-server/stand-alone-mode/start-a-new-genesis-ledger-in-stand-alone-mode.md
+++ b/content/tutorials/manage-the-rippled-server/stand-alone-mode/start-a-new-genesis-ledger-in-stand-alone-mode.md
@@ -14,7 +14,7 @@ In a genesis ledger, the [genesis address](accounts.html#special-addresses) hold
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
-**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase")
+**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("`masterpassphrase`")
## Settings in New Genesis Ledgers
diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md b/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md
index 95a56a03b9..8040ad85cb 100644
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md
@@ -99,7 +99,7 @@ The `rippled` executable returns the following message if it wasn't able to conn
This generally indicates one of several problems:
-- The `rippled` server is just starting up, or is not running at all. Check the status of the service; if it is running, wait a few seconds and try again.
+- The `rippled` server is starting up, or is not running at all. Check the status of the service; if it is running, wait a few seconds and try again.
- You may need to pass different [parameters to the `rippled` commandline client](commandline-usage.html#client-mode-options) to connect to your server.
- The `rippled` server may be configured not to accept JSON-RPC connections.
@@ -138,7 +138,7 @@ To use the script:
should verify before posting.
####################################################
- The script collects the output of numerous commands and writes them to a temporary file. The filename is randomized with a string of letters and numbers (case-sensitive), for example: `/tmp/ripple_info.Xo8Xr/rippled_info.md`
+ The script collects the output of many commands and writes them to a temporary file. The filename is randomized with a string of letters and numbers (case-sensitive), for example: `/tmp/ripple_info.Xo8Xr/rippled_info.md`
2. Look over the output file for sensitive information.
@@ -149,7 +149,7 @@ To use the script:
3. Upload the output file where others can see it.
- You can upload the file directly to [GitHub Gist](https://gist.github.com/), [Pastebin](https://pastebin.com/), or a similar service. If you are running `rippled` on a remote server, you may find it easier to first transfer the file to a machine with a web browser, using `scp` or a similar tool.
+ You can upload the file directly to [GitHub Gist](https://gist.github.com/), [Pastebin](https://pastebin.com/), or a similar service. If you are running `rippled` on a remote server, you may find it easier to first transfer the file to a machine with a web browser, using `scp` or a similar tool.
## See Also
diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/fix-sqlite-tx-db-page-size-issue.md b/content/tutorials/manage-the-rippled-server/troubleshooting/fix-sqlite-tx-db-page-size-issue.md
index d13cf6a0f7..80f92971b5 100644
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/fix-sqlite-tx-db-page-size-issue.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/fix-sqlite-tx-db-page-size-issue.md
@@ -6,11 +6,11 @@ This document describes steps to detect and correct this problem if it occurs.
## Background
-`rippled` servers store a copy of their transaction history in a SQLite database. Before version 0.40.0, `rippled` configured this database to have a capacity of roughly 2TB. For most uses, this is plenty. However, full transaction history back to ledger 32570 (the oldest ledger version available in the production XRP Ledger history) is likely to exceed this exceed the SQLite database capacity. `rippled` servers version 0.40.0 and later create their SQLite database files with a larger capacity, so they are unlikely to encounter this problem.
+`rippled` servers store a copy of their transaction history in a SQLite database. Before version 0.40.0, `rippled` configured this database to have a capacity of roughly 2 TB. For most uses, this is plenty. However, full transaction history back to ledger 32570 (the oldest ledger version available in the production XRP Ledger history) is likely to exceed this exceed the SQLite database capacity. `rippled` servers version 0.40.0 and later create their SQLite database files with a larger capacity, so they are unlikely to encounter this problem.
The capacity of the SQLite database is a result of the database's _page size_ parameter, which cannot be easily changed after the database is created. (For more information on SQLite's internals, see [the official SQLite documentation](https://www.sqlite.org/fileformat.html).) The database can reach its capacity even if there is still free space on the disk and filesystem where it is stored. As described in the [Fix](#fix) below, reconfiguring the page size to avoid this problem requires a somewhat time-consuming migration process.
-**Tip:** Full history is not necessary to operate a `rippled` server for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](history-sharding.html).
+**Tip:** Full history is not necessary for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](history-sharding.html).
## Detection
@@ -36,7 +36,7 @@ Transaction DB pathname: /opt/rippled/transaction.db; SQLite page size: 1024
The value `SQLite page size: 1024 bytes` indicates that your transaction database is configured with a smaller page size and does not have capacity for full transaction history. If the value is already 4096 bytes or higher, then your SQLite database should already have adequate capacity to store full transaction history and you do not need to perform the migration described in this document.
-The `rippled` server halts if the `Free space` described in this log message becomes less than 524288000 bytes (500MB). If your free space is approaching that threshold, [fix the problem](#fix) to avoid an unexpected outage.
+The `rippled` server halts if the `Free space` described in this log message becomes less than 524288000 bytes (500 MB). If your free space is approaching that threshold, [fix the problem](#fix) to avoid an unexpected outage.
### Reactive Detection
diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md
new file mode 100644
index 0000000000..8043c808a4
--- /dev/null
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md
@@ -0,0 +1,110 @@
+# Health Check Interventions
+
+The [Health Check method](health-check.html) can be used by automated monitoring to recognize when a `rippled` server is not healthy and prompt interventions such as restarting the server or alerting a human administrator.
+
+Infrastructure monitoring, and reliability engineering more generally, is an advanced discipline that involves using multiple sources of data to make decisions in context. This document provides some suggestions for how to use the health check most effectively, but these recommendations are only meant as guidelines as part of a larger strategy.
+
+## Momentary Failures
+
+Some [metrics][] in the health check can rapidly fluctuate into unhealthy ranges and then recover automatically shortly afterward. It is unnecessary and undesirable to raise alerts every single time the health check reports an unhealthy status. An automated monitoring system should call the health check method frequently, but only escalate to a higher level of intervention based on the severity and frequency of the problem.
+
+For example, if you check the health of the server once per second, you might raise an alert if the server reports "warning" status three times in a row, or four times in a five-second span. You might also raise an alert if the server reports "critical" status twice in a five-second span.
+
+**Tip:** The server normally reports a "critical" status for the first few seconds after startup, switches to a "warning" status after it establishes a connection to the network, and finally reports a "healthy" status when it has fully synced to the network. After a restart, you should give a server 5–15 minutes to sync before taking additional interventions.
+
+## Special Cases
+
+Certain server configurations may always report a `warning` status even when operating normally. If your server qualifies as a special case, you must configure your automated monitoring to recognize the difference between the normal status and an actual problem. This probably involves parsing the JSON response body for the health check method and comparing the values there with expected normal ranges.
+
+Some examples of special cases that may occur include:
+
+- A [private peer](peer-protocol.html#private-peers) typically has a very small number of peer-to-peer connections to known servers only, but the health check reports a warning on the `peers` metric if the server is connected to 7 or fewer peers. You should know the exact number of peers your server is configured to have and check for that value.
+- On a [parallel or test network](parallel-networks.html) where new transactions are not being sent continuously, the network waits up to 20 seconds for new transactions before attempting to validate a new ledger version, but the health check reports a warning on the `validated_ledger` metric if the latest validated ledger is 7 or more seconds old. If you are running `rippled` on a non-production network, you may want to ignore `warning` messages for this metric unless you know that there should be transactions being regularly sent. You may still want to alert on the `critical` level of 20 seconds, because the XRP Ledger protocol is designed to validate new ledger versions at least once every 20 seconds even if there are no new transactions to process.
+
+## Suggested Interventions
+
+When a health check fails, and it's not just a [momentary failure](#momentary-failures), the action to take to recover from the outage varies based on the cause. You may be able to configure your infrastructure to fix some types of failures automatically. Other failures require the intervention of a human administrator who can investigate and take the necessary steps to resolve more complex or critical failures; depending on the structure of your organization, you may have different levels of human administrator so that less skilled, lower level administrators can fix certain issues independently, but need to escalate to higher level administrators to fix larger or more complex issues. How and when you respond is likely to depend on your unique situation, but the metrics reported in the health check result can be a factor in these decisions.
+
+The following sections suggest some common interventions you may want to attempt and the health check statuses most likely to prompt those interventions. Automated systems and human administrators may selectively escalate through these and other interventions:
+
+- [Redirect traffic](#redirect-traffic) away from the affected server
+- [Restart](#restart) the server software or hardware
+- [Upgrade](#upgrade) the `rippled` software
+- [Investigate network](#investigate-network) in case the problem originates elsewhere
+- [Replace hardware](#replace-hardware)
+
+
+### Redirect Traffic
+
+A common reliability technique is to run a pool of redundant servers through one or more load-balancing proxies. You can do this with `rippled` servers, but should not do this with [validators](rippled-server-modes.html). In some cases, the load balancers can monitor the health of servers in their pools and direct traffic only to the servers that are currently reporting themselves as healthy. This allows servers to recover from being temporarily overloaded and automatically rejoin the pool of active servers.
+
+Redirecting traffic away from a server that is unhealthy is an appropriate response, especially for servers that report a `health` status of `warning`. Servers in the `critical` range may need more significant interventions.
+
+
+### Restart
+
+The most straightforward intervention is to restart the server. This can resolve temporary issues with several types of failures, including any of the following [metrics][]:
+
+- `load_factor`
+- `peers`
+- `server_state`
+- `validated_ledger`
+
+To restart only the `rippled` service, use `systemctl`:
+
+```
+$ sudo systemctl restart rippled.service
+```
+
+A stronger intervention is to restart the entire machine.
+
+**Caution:** After a server starts, it typically needs up to 15 minutes to sync to the network. During this time, the health check is likely to report a critical or warning status. You should be sure your automated systems give servers enough time to sync before restarting them again.
+
+
+### Upgrade
+
+If the server reports `"amendment_blocked": true` in the health check, this indicates that the XRP Ledger has enabled a [protocol amendment](amendments.html) that your server does not understand. As a precaution against misinterpreting the revised rules of the network in a way that causes you to lose money, such servers become "amendment blocked" instead of operating normally.
+
+To resolve being amendment blocked, [update your server](install-rippled.html) to a newer software version that understands the amendment.
+
+Also, software bugs can cause a server to get [stuck not syncing](server-doesnt-sync.html). In this case, the `server_state` metric is likely to be in a warning or critical state. If you are not using the latest stable release, you should upgrade to get the latest fixes for any known issues that could cause this.
+
+
+### Investigate Network
+
+An unreliable or insufficient network connection can cause a server to report outages. Warning or critical values in the following [metrics][] can indicate network problems:
+
+- `peers`
+- `server_state`
+- `validated_ledger`
+
+In this case, the necessary interventions may involve changes to other systems, such as:
+
+- Adjusting firewall rules to allow necessary traffic to reach a server, or to block harmful traffic from outside
+- Restarting or replacing network interfaces, switches, routers, or cabling
+- Contacting other network service providers to resolve an issue on their end
+
+
+
+### Replace Hardware
+
+If the outage is caused by a hardware failure or by higher load than the hardware is capable of handling, you may need to replace some components or even the entire server.
+
+The amount of load on a server in the XRP Ledger depends in part on transaction volume in the network, which varies organically. Load also depends on your usage pattern. See [Capacity Planning](capacity-planning.html) for how to plan the appropriate hardware and settings for your situation.
+
+Warning or critical values for the following [metrics][] may indicate insufficient hardware:
+
+- `load_factor`
+- `server_state`
+- `validated_ledger`
+
+
+
+
+
+
+
+[metrics]: health-check.html#response-format
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md b/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md
index 66d7aad461..f9b7d724b8 100644
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md
@@ -32,7 +32,7 @@ If the problem persists, check the other possibilities listed on this page. If n
The most common cause of syncing issues is not meeting the [system requirements](system-requirements.html). The three most common shortfalls are:
- **Slow disks.** You need a consistently fast solid state disk (SSD). Cloud providers like AWS usually don't guarantee disk performance, which may be impacted by other users of shared hardware.
-- **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements just in case.
+- **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements.
- **Poor network connection.** Network requirements vary the most based on how people use the XRP Ledger, but a slow or unstable connection can make it impossible to keep up with new transactions and data added to the XRP Ledger.
If you are having trouble remaining synced, double-check that your server meets the system requirements. Depending on how you use your server, you may need to meet the higher "Recommended" requirements instead of just the "Minimum" requirements. If you meet the "Recommended" requirements and still cannot sync, try the other possibilities on this page.
@@ -106,6 +106,7 @@ As a test, you can temporarily change the paths to your server's databases as lo
- [server_info method][]
- [validator_list_sites method][]
+
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.md b/content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.md
index 33c1958eb9..cfab73c610 100644
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.md
@@ -209,6 +209,7 @@ To fix this problem, do one of the following, then restart the server:
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
+
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
diff --git a/content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.md b/content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.md
index 8f147af674..a5bd66ccc0 100644
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.md
@@ -4,6 +4,28 @@ The following sections describe some of the most common types of log messages th
This is an important step in [Diagnosing Problems](diagnosing-problems.html) with `rippled`.
+## Log Message Structure
+
+The following shows the format of the log file:
+
+```text
+2020-Jul-08 20:10:17.372178946 UTC Peer:WRN [236] onReadMessage from n9J2CP7hZypxDJ27ZSxoy4VjbaSgsCNaRRJtJkNJM5KMdGaLdRy7 at 197.27.127.136:53046: stream truncated
+2020-Jul-08 20:11:13.582438263 UTC PeerFinder:ERR Logic testing 52.196.126.86:13308 with error, Connection timed out
+2020-Jul-08 20:11:57.728448343 UTC Peer:WRN [242] onReadMessage from n9J2CP7hZypxDJ27ZSxoy4VjbaSgsCNaRRJtJkNJM5KMdGaLdRy7 at 197.27.127.136:53366: stream truncated
+2020-Jul-08 20:12:12.075081020 UTC LoadMonitor:WRN Job: sweep run: 1172ms wait: 0ms
+```
+
+Each line represents one log entry, with the following parts in order, separated by spaces:
+
+1. The date the log entry was written, such as `2020-Jul-08`.
+2. The time the log entry was written, such as `20:12:12.075081020`.
+3. The time zone indicator `UTC`. (Log dates are always in UTC.) [New in: rippled 1.5.0][]
+4. The log partition and severity, such as `LoadMonitor:WRN`.
+5. The log message, such as `Job: sweep run: 1172ms wait: 0ms`.
+
+For simplicity, the examples in this page omit the date, time, and time zone indicator.
+
+
## Crashes
Messages in the log that mention runtime errors can indicate that the server crashed. These messages usually start with a message such as one of the following examples:
@@ -32,10 +54,10 @@ If none of the above apply, please report the issue to Ripple as a security-sens
Log messages such as the following indicate that a server received validations for different ledger indexes out of order.
```text
-2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
+Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
```
-Occasional messages of this type do not usually indicate a problem. If this type of message occurs frequently with the same sending validator, it could indicate a problem, including any of the following (roughly in order of most to least likely):
+Occasional messages of this type do not usually indicate a problem. If this type of message occurs often with the same sending validator, it could indicate a problem, including any of the following (roughly in order of most to least likely):
- The server writing the message is having network issues.
- The validator described in the message is having network issues.
@@ -47,7 +69,7 @@ Occasional messages of this type do not usually indicate a problem. If this type
The following log message indicates that [StatsD export](configure-statsd.html) failed:
```text
-2020-Apr-07 16:59:36.299867439 UTC Collector:ERR async_send failed: Connection refused
+Collector:ERR async_send failed: Connection refused
```
This could mean:
@@ -57,7 +79,18 @@ This could mean:
Check the `[insight]` stanza in your `rippled`'s config file and confirm that you have network connectivity from your `rippled` server to your StatsD server.
-This error has no other impact on the `rippled` server, which should continue to operate as normal except for the sending of StatsD metrics.
+This error has no other impact on the `rippled` server, which should continue to work as normal except for the sending of StatsD metrics.
+
+
+## Check for upgrade
+
+The following message indicates that the server has detected that it is running an older software version than at least 60% of its trusted validators:
+
+```text
+LedgerMaster:ERR Check for upgrade: A majority of trusted validators are running a newer version.
+```
+
+This is not strictly a problem, but an old server version is likely to become [amendment blocked](amendments.html#amendment-blocked). You should [update `rippled`](install-rippled.html) to the latest stable version. (If you are connected to [devnet](parallel-networks.html), update to the latest nightly version instead.)
## Connection reset by peer
@@ -65,7 +98,7 @@ This error has no other impact on the `rippled` server, which should continue to
The following log message indicates that a peer `rippled` server closed a connection:
```text
-2018-Aug-28 22:55:41.738765510 Peer:WRN [012] onReadMessage: Connection reset by peer
+Peer:WRN [012] onReadMessage: Connection reset by peer
```
Losing connections from time to time is normal for any peer-to-peer network. **Occasional messages of this kind do not indicate a problem.**
@@ -81,7 +114,7 @@ A large number of these messages around the same time may indicate a problem, su
The following log message indicates that a client to the server's public API has been dropped as a result of [rate limiting](rate-limiting.html):
```text
-2020-Feb-24 23:05:35.566312806 Resource:WRN Consumer entry 169.55.164.21 dropped with balance 15970 at or above drop threshold 15000
+Resource:WRN Consumer entry 169.55.164.21 dropped with balance 15970 at or above drop threshold 15000
```
The entry contains the IP address of the client that exceeded its rate limit, and the client's "balance", which is a score estimating the rate at which the client has been using the API. The threshold for dropping a client is [hardcoded to a score of 15000](https://github.com/ripple/rippled/blob/06c371544acc3b488b9d9c057cee4e51f6bef7a2/src/ripple/resource/impl/Tuning.h#L34-L35).
@@ -128,17 +161,17 @@ Messages such as the following occur when a function takes a long time to run (o
The following similar message occurs when a job spends a long time waiting to run (again, over 11 seconds in this example):
```text
-2018-Aug-28 22:56:36.180970431 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
-2018-Aug-28 22:56:36.181053831 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
-2018-Aug-28 22:56:36.181110594 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
-2018-Aug-28 22:56:36.181169931 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
+LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
+LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
+LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
+LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
```
These two types of messages often occur together, when a long-running job causes other jobs to wait a long time for it to finish.
It is **normal** to display several messages of these types **during the first few minutes** after starting the server.
-If the messages continue for more than 5 minutes after starting the server, especially if the `run` times are well over 1000ms, that may indicate that **your server does not have sufficient resources, such as disk I/O, RAM, or CPU**. This may be caused by not having sufficiently-powerful hardware or because other processes running on the same hardware are competing with `rippled` for resources. (Examples of other processes that may compete with `rippled` for resources include scheduled backups, virus scanners, and periodic database cleaners.)
+If the messages continue for more than 5 minutes after starting the server, especially if the `run` times are well over 1000 ms, that may indicate that **your server does not have sufficient resources, such as disk I/O, RAM, or CPU**. This may be caused by not having sufficiently-powerful hardware or because other processes running on the same hardware are competing with `rippled` for resources. (Examples of other processes that may compete with `rippled` for resources include scheduled backups, virus scanners, and periodic database cleaners.)
Another possible cause is trying to use NuDB on rotational hard disks; NuDB should only be used with solid state drives (SSDs). Ripple recommends always using SSD storage for `rippled`'s databases, but you _may_ be able to run `rippled` successfully on rotational disks using RocksDB. If you are using rotational disks, make sure both the `[node_db]` and the `[shard_db]` (if you have one) are configured to use RocksDB. For example:
@@ -252,7 +285,7 @@ Aside from the bug, this error can also occur if `rippled` became unable to writ
Log messages such as the following occur when the server sees a validation message from a peer and it does not know the parent ledger version that server is building on. This can occur when the server is not in sync with the rest of the network:
```text
-2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
+Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
{% include '_snippets/unsynced_warning_logs.md' %}
@@ -264,9 +297,9 @@ Log messages such as the following occur when the server sees a validation messa
Log messages such as the following occur when a server is not in sync with the rest of the network:
```text
-2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
-2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
-2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
+LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
+LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
+LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
{% include '_snippets/unsynced_warning_logs.md' %}
@@ -296,6 +329,8 @@ NetworkOPs:WRN We are not running on the consensus ledger
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
+
+
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
diff --git a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md b/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md
index bcf883f6f4..9605407336 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md
+++ b/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md
@@ -4,7 +4,7 @@ _Added by the [Checks amendment][]._
As long as the Check is in the ledger and not expired, the specified recipient can cash it to receive a flexible amount by sending a [CheckCash transaction][] with a `DeliverMin` field. When cashing a Check in this way, the receiver gets as much as is possible to deliver, debiting the Check's sender for the Check's full `SendMax` amount or as much as is available. Cashing fails if it doesn't deliver at least the `DeliverMin` amount to the Check's recipient.
-You might cash a Check for a flexible amount if you just want to get as much as possible from the Check.
+You might cash a Check for a flexible amount if you want to get as much as possible from the Check.
The specified recipient can also [cash the check for an exact amount](cash-a-check-for-a-flexible-amount.html).
@@ -164,7 +164,7 @@ If the Check was cashed for a flexible `DeliverMin` amount and succeeded, you ca
- For XRP, the `AccountRoot` object of the Check's sender has its XRP `Balance` field debited. The `AccountRoot` object of the Check's recipient (the one who sent the CheckCash transaction) has its XRP `Balance` credited for at least the `DeliverMin` of the CheckCash transaction minus the [transaction cost](transaction-cost.html) of sending the transaction.
- For example, the following `ModifiedNode` shows that the account rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis, the Check's recipient and the sender of this CheckCash transaction, had its XRP balance change from `9999999970` drops to `10099999960` drops, meaning the recipient was credited a _net_ of 99.99999 XRP as a result of processing the transaction.
+ For example, the following `ModifiedNode` shows that the account `rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`, the Check's recipient and the sender of this CheckCash transaction, had its XRP balance change from `9999999970` drops to `10099999960` drops, meaning the recipient was credited a _net_ of 99.99999 XRP as a result of processing the transaction.
{
"ModifiedNode": {
@@ -186,7 +186,7 @@ If the Check was cashed for a flexible `DeliverMin` amount and succeeded, you ca
}
}
- The net amount of 99.99999 XRP includes deducting the transaction cost that is destroyed to pay for sending this CheckCash transaction. The following transaction instructions (excerpted) show that the transaction cost (the `Fee` field) was 10 drops of XRP. By adding this to the net balance change, we conclude that the recipient, rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis, was credited a _gross_ amount of exactly 100 XRP for cashing the Check.
+ The net amount of 99.99999 XRP includes deducting the transaction cost that is destroyed to pay for sending this CheckCash transaction. The following part of the transaction instructions shows that the transaction cost (the `Fee` field) was 10 drops of XRP. By adding this to the net balance change, we conclude that the recipient, `rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`, was credited a _gross_ amount of exactly 100 XRP for cashing the Check.
"Account" : "rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
"TransactionType" : "CheckCash",
diff --git a/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md b/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
index 6ebe7800af..d268278621 100644
--- a/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
+++ b/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
@@ -6,9 +6,9 @@ Sending a Check is like writing permission for an intended recipient to pull a p
In many cases, you want to send a [Payment][] instead of a Check, since that delivers the money directly to the recipient in one step. However, if your intended recipient uses [DepositAuth](depositauth.html), you cannot send them Payments directly, so a Check is a good alternative.
-This tutorial uses the example of a fictitious company, BoxSend SG (whose XRP Ledger address is rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za) paying a fictitious cryptocurrency consulting company named Grand Payments (with XRP Ledger address rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis) for some consulting work. Grand Payments prefers be paid in XRP, but to simplify their taxes and regulation, only accepts payments they've explicitly approved.
+This tutorial uses the example of a fictitious company, BoxSend SG (whose XRP Ledger address is `rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za`) paying a fictitious cryptocurrency consulting company named Grand Payments (with XRP Ledger address `rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`) for some consulting work. Grand Payments prefers be paid in XRP, but to simplify their taxes and regulation, only accepts payments they've explicitly approved.
-Outside of the XRP Ledger, Grand Payments sends an invoice to BoxSend SG with the ID `46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291`, and requests a Check for 100 XRP be sent to Grand Payments' XRP Ledger address of rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis.
+Outside of the XRP Ledger, Grand Payments sends an invoice to BoxSend SG with the ID `46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291`, and requests a Check for 100 XRP be sent to Grand Payments' XRP Ledger address of `rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`.
{% set send_n = cycler(* range(1,99)) %}
@@ -40,7 +40,7 @@ If you are using [RippleAPI](rippleapi-reference.html), you can use the `prepare
### Example CheckCreate Preparation
-The following example shows a prepared Check from BoxSend SG (rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za) to Grand Payments (rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis) for 100 XRP. As additional (optional) metadata, BoxSend SG adds the ID of the invoice from Grand Payments so Grand Payments knows which invoice this Check is intended to pay.
+The following example shows a prepared Check from BoxSend SG (`rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za`) to Grand Payments (`rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis`) for 100 XRP. As additional (optional) metadata, BoxSend SG adds the ID of the invoice from Grand Payments so Grand Payments knows which invoice this Check is intended to pay.
@@ -52,7 +52,7 @@ The following example shows a prepared Check from BoxSend SG (rBXsgNkPcDN2runsvW
*JSON-RPC, WebSocket, or Commandline*
-```
+```json
{
"TransactionType": "CheckCreate",
"Account": "rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za",
@@ -183,7 +183,7 @@ Use the [tx method][] with the CheckCreate transaction's identifying hash to che
Look for a `CreatedNode` object in the transaction metadata with a `LedgerEntryType` of `"Check"`. This indicates that the transaction created a [Check ledger object](check.html). The `LedgerIndex` of this object is the ID of the Check. In the following example, the Check's ID is `84C61BE9B39B2C4A2267F67504404F1EC76678806C1B901EA781D1E3B4CE0CD9`.
-**Note:** RippleAPI does not report the Check's ID when you look up a CheckCreate transaction. You can work around this by calculating the Check's ID from the [Check ID format](check.html#check-id-format), as in the example RippleAPI code below, or you can use the [getAccountObjects() method](rippleapi-reference.html#getaccountobjects) to look up the Check and find its ID.
+**Note:** RippleAPI does not report the Check's ID when you look up a CheckCreate transaction. You can work around this by calculating the Check's ID from the [Check ID format](check.html#check-id-format), as in the example RippleAPI code below, or you can use the [`getAccountObjects()` method](rippleapi-reference.html#getaccountobjects) to look up the Check and find its ID.
### Example Request
diff --git a/content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.md b/content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.md
index ec2b7a6671..a920dcba7e 100644
--- a/content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.md
+++ b/content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.md
@@ -2,10 +2,10 @@
## 1. Generate condition and fulfillment
-XRP Ledger escrows require PREIMAGE-SHA-256 [crypto-conditions][]. To calculate a condition and fulfillment in the proper format, you should use a crypto-conditions library such as [five-bells-condition](https://github.com/interledgerjs/five-bells-condition). For fulfillments, the following methods are recommended to generate the fulfillment:
+XRP Ledger escrows require PREIMAGE-SHA-256 [crypto-conditions][]. To calculate a condition and fulfillment in the proper format, you should use a crypto-conditions library such as [five-bells-condition](https://github.com/interledgerjs/five-bells-condition). To generate the fulfillment:
- Use a cryptographically secure source of randomness to generate at least 32 random bytes.
-- Follow Interledger Protocol's [PSK specification](https://github.com/interledger/rfcs/blob/master/deprecated/0016-pre-shared-key/0016-pre-shared-key.md) and use an HMAC-SHA-256 of the ILP packet as the fulfillment.
+- Follow Interledger Protocol's [PSK specification](https://github.com/interledger/rfcs/blob/master/deprecated/0016-pre-shared-key/0016-pre-shared-key.md) and use an HMAC-SHA-256 of the ILP packet as the fulfillment.
Example JavaScript code for a random fulfillment and condition:
@@ -62,7 +62,7 @@ print(cancel_after)
-**Warning:** In the XRP Ledger, you must specify time as **seconds since the Ripple Epoch** (2000-01-01T00:00:00Z). If you use a UNIX time in the `CancelAfter` or `FinishAfter` field without converting to the equivalent Ripple time first, that sets the unlock time to an extra **30 years** in the future!
+**Warning:** In the XRP Ledger, you must specify time as **[seconds since the Ripple Epoch][]**. If you use a UNIX time in the `CancelAfter` or `FinishAfter` field without converting it, that sets the unlock time to an extra **30 years** in the future!
## 3. Submit EscrowCreate transaction
diff --git a/content/tutorials/use-complex-payment-types/use-payment-channels.md b/content/tutorials/use-complex-payment-types/use-payment-channels.md
index 23c59e4b5c..50fc3746c6 100644
--- a/content/tutorials/use-complex-payment-types/use-payment-channels.md
+++ b/content/tutorials/use-complex-payment-types/use-payment-channels.md
@@ -10,10 +10,10 @@ The example addresses used in this tutorial are:
| | |
|--|--|
-| **Payer's address** | rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH |
-| **Public key used for channel (in the XRP Ledger's [base58][] encoded string format)** | aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3
-| **Public key used for channel (in hex)** | 023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6 |
-| **Payee's address** | rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn |
+| **Payer's address** | `rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH` |
+| **Public key used for channel (in the XRP Ledger's [base58][] encoded string format)** | `aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3`
+| **Public key used for channel (in hex)** | `023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6` |
+| **Payee's address** | `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` |
**Tip:** In this example, the channel's public key is the public key from the payer's master key pair. This is perfectly safe and valid. It is also perfectly safe and valid to use a different key pair, as long as only the payer knows the public and secret keys for that key pair.
@@ -49,7 +49,7 @@ This is a [PaymentChannelCreate transaction][]. As part of this process, the pay
**Tip:** The "settlement delay" does not delay the settlement, which can happen as fast as a ledger version closes (3-5 seconds). The "settlement delay" is a forced delay on closing the channel so that the payee has a chance to finish with settlement.
-The following example shows creation of a payment channel by [submitting](submit.html#sign-and-submit-mode) to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (rN7n7...) to the [example payee](#example-values) (rf1Bi...) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal.
+The following example shows creation of a payment channel by [submitting](submit.html#sign-and-submit-mode) to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (`rN7n7...`) to the [example payee](#example-values) (`rf1Bi...`) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal.
**Note:** A payment channel counts as one object toward the payer's [owner reserve](reserves.html#owner-reserves). The owner must keep at least enough XRP to satisfy the reserve after subtracting the XRP allocated to the payment channel.
@@ -154,7 +154,7 @@ In the response from the JSON-RPC, the payer should look for the following:
- In the transaction's `meta` field, confirm that the `TransactionResult` is `tesSUCCESS`.
- Confirm that the response has `"validated":true` to indicate the data comes from a validated ledger. (The result `tesSUCCESS` is only [final](finality-of-results.html) if it appears in a validated ledger version.)
-- In the `AffectedNodes` array of the transaction's `meta` field, look for a `CreatedNode` object with the `LedgerEntryType` of `PayChannel`. The `LedgerIndex` field of the `CreatedNode` object indicates the Channel ID. (In the above example, this is a hex string starting with "5DB0...") The Channel ID is necessary later to sign claims.
+- In the `AffectedNodes` array of the transaction's `meta` field, look for a `CreatedNode` object with the `LedgerEntryType` of `PayChannel`. The `LedgerIndex` field of the `CreatedNode` object indicates the Channel ID. (In the above example, this is a hex string starting with "`5DB0`...") The Channel ID is necessary later to sign claims.
For more information on the PayChannel ledger object type, see [PayChannel ledger object](paychannel.html).
@@ -430,6 +430,8 @@ If the channel _does_ have XRP remaining, the request to close a channel acts as
The payee can also close a payment channel immediately after processing a claim _(9b in the [flow diagram][])_.
+
+
Example of [submitting a transaction](submit.html#sign-and-submit-mode) requesting a channel to close:
{
@@ -471,7 +473,7 @@ Example `account_channels` response:
}
}
-In this example, the `expiration` value 547073182 in [seconds since the Ripple Epoch][] maps to 2017-05-02T20:46:22Z, so any claims not redeemed by that time are no longer valid.
+In this example, the `expiration` value 547073182 in [seconds since the Ripple Epoch][] maps to `2017-05-02T20:46:22Z`, so any claims not redeemed by that time are no longer valid.
## 10. Anyone can close the expired channel.
diff --git a/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md b/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
index b76d369da0..1dbf5745e4 100644
--- a/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
+++ b/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
@@ -1,6 +1,6 @@
# Reliable Transaction Submission
-Financial institutions and other services using the XRP Ledger should use the best practices described here to make sure that transactions are validated or rejected in a verifiable and prompt way. You should submit transactions to trusted (locally operated) `rippled` servers.
+Financial institutions and other services using the XRP Ledger should use the best practices described here to make sure that transactions are validated or rejected in a verifiable and prompt way. You should submit transactions to trusted `rippled` servers.
The best practices detailed in this document allow applications to submit transactions to the XRP Ledger while achieving:
@@ -54,6 +54,8 @@ Each validated ledger has a canonical order in which transactions apply. This or
### LastLedgerSequence
+
+
`LastLedgerSequence` is an optional [parameter of all transactions](transaction-common-fields.html). This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger version. The XRP Ledger never includes a transaction in a ledger version whose ledger index is higher than the transaction's `LastLedgerSequence` parameter.
Use the `LastLedgerSequence` parameter to prevent undesirable cases where a transaction is not confirmed promptly but could be included in a future ledger. You should specify the `LastLedgerSequence` parameter on every transaction. Automated processes should use a value of 4 greater than the last validated ledger index to make sure that a transaction is validated or rejected in a predictable and prompt way.
diff --git a/content/tutorials/use-simple-xrp-payments/send-a-multi-signed-transaction.md b/content/tutorials/use-simple-xrp-payments/send-a-multi-signed-transaction.md
index 30a71eb40f..01a9a82cfd 100644
--- a/content/tutorials/use-simple-xrp-payments/send-a-multi-signed-transaction.md
+++ b/content/tutorials/use-simple-xrp-payments/send-a-multi-signed-transaction.md
@@ -31,7 +31,7 @@ Here's an example transaction ready to be multi-signed:
"Fee": "30000"
}
-(This transaction creates an accounting relationship from rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC to rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh with a maximum balance of 100 USD.)
+(This transaction creates an accounting relationship from `rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC` to `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` with a maximum balance of 100 USD.)
## 2. Get one signature
diff --git a/content/tutorials/use-simple-xrp-payments/send-xrp.ja.md b/content/tutorials/use-simple-xrp-payments/send-xrp.ja.md
index 8763ffd81f..2cb3c59823 100644
--- a/content/tutorials/use-simple-xrp-payments/send-xrp.ja.md
+++ b/content/tutorials/use-simple-xrp-payments/send-xrp.ja.md
@@ -301,7 +301,7 @@ async function doSubmit(txBlob) {
const earliestLedgerVersion = doSubmit(txBlob)
```
-このメソッドは、ローカルでトランザクションを適用しようと試みたときの**一時的な**結果を返します。この結果は、トランザクションが検証済みレジャーに含まれた時点で変わる_可能性があります_。当初は成功していたトランザクションが最終的に失敗となったり、当初失敗していたトランザクションが最終的に成功する場合があります。しかしながら、一時的な結果はほとんどの場合は最終結果と一致するため、ここで`tesSUCCESS`が表示されたらひとまず安心しても問題ありません。😁
+このメソッドは、ローカルでトランザクションを適用しようと試みたときの**一時的な**結果を返します。この結果は、トランザクションが検証済みレジャーに含まれた時点で変わる_可能性があります_。当初は成功していたトランザクションが最終的に失敗となったり、当初失敗していたトランザクションが最終的に成功する場合があります。しかしながら、一時的な結果はほとんどの場合は最終結果と一致するため、ここで`tesSUCCESS`が表示されたらひとまず安心しても問題ありません。😁
他の結果が表示された場合は、以下の点を確認します。
@@ -357,7 +357,7 @@ RippleAPIの`ledger`イベントタイプを使用して、新しい検証済み
```js
api.on('ledger', ledger => {
- console.log("Ledger version", ledger.ledgerVersion, "was just validated.")
+ console.log("Ledger version", ledger.ledgerVersion, "was validated.")
if (ledger.ledgerVersion > maxLedgerVersion) {
console.log("If the transaction hasn't succeeded by now, it's expired")
}
diff --git a/content/tutorials/use-simple-xrp-payments/send-xrp.md b/content/tutorials/use-simple-xrp-payments/send-xrp.md
index d5b7c0a775..278375ae63 100644
--- a/content/tutorials/use-simple-xrp-payments/send-xrp.md
+++ b/content/tutorials/use-simple-xrp-payments/send-xrp.md
@@ -87,7 +87,7 @@ $(document).ready( () => {
})
-**Caution:** Ripple operates the XRP Test Net for testing purposes only, and regularly resets the state of the test net along with all balances. As a precaution, Ripple recommends **not** using the same addresses on the test net and production.
+**Caution:** Ripple provides the XRP Test Net for testing purposes only, and regularly resets the state of the test net along with all balances. As a precaution, Ripple recommends **not** using the same addresses on the test net and production.
## Send a Payment on the Test Net
@@ -283,7 +283,7 @@ The signing API also returns the transaction's ID, or identifying hash, which yo
### {{n.next()}}. Submit the Signed Blob
-Use the [submit() method](rippleapi-reference.html#submit) to submit a transaction to the network. It's also a good idea to use the [getLedgerVersion() method](rippleapi-reference.html#getledgerversion) to take note of the latest validated ledger index before you submit. The earliest ledger version that your transaction could get into as a result of this submission is one higher than the latest validated ledger when you submit it.
+Use the [submit() method](rippleapi-reference.html#submit) to submit a transaction to the network. It's also a good idea to use the [`getLedgerVersion()` method](rippleapi-reference.html#getledgerversion) to take note of the latest validated ledger index before you submit. The earliest ledger version that your transaction could get into as a result of this submission is one higher than the latest validated ledger when you submit it.
Of course, if the same transaction was previously submitted, it could already be in a previous ledger. (It can't succeed a second time, but you may not realize it succeeded if you aren't looking in the right ledger versions.)
@@ -363,7 +363,7 @@ You use the `ledger` event type in RippleAPI to trigger your code to run wheneve
```js
api.on('ledger', ledger => {
- console.log("Ledger version", ledger.ledgerVersion, "was just validated.")
+ console.log("Ledger version", ledger.ledgerVersion, "was validated.")
if (ledger.ledgerVersion > maxLedgerVersion) {
console.log("If the transaction hasn't succeeded by now, it's expired")
}
@@ -381,7 +381,7 @@ api.on('ledger', ledger => {
| (Not submitted) |
|
|---|