From 5c588410b5b3a78af77b7af0813b720d6bb48de3 Mon Sep 17 00:00:00 2001 From: Rome Reginelli Date: Tue, 23 Jun 2020 10:29:05 -0700 Subject: [PATCH 01/65] Update install for latest distro releases Default to Focal Fossa, list our other supported releases --- .../installation/install-rippled-on-ubuntu.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) 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..63e1d66813 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,16 @@ 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: + - `disco` for **Ubuntu 19.04 Disco Dingo** + - `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`: From abc373409d8f1c32c700050182229db25615e2f9 Mon Sep 17 00:00:00 2001 From: Rome Reginelli Date: Tue, 23 Jun 2020 11:32:41 -0700 Subject: [PATCH 02/65] Ubuntu Install: Remove Disco Dingo (EOL) --- .../installation/install-rippled-on-ubuntu.md | 1 - 1 file changed, 1 deletion(-) 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 63e1d66813..47cfb29e14 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 @@ -45,7 +45,6 @@ Before you install `rippled`, you must meet the [System Requirements](system-req The above example is appropriate for **Ubuntu 20.04 Focal Fossa**. For other operating systems, replace the word `focal` with one of the following: - - `disco` for **Ubuntu 19.04 Disco Dingo** - `bionic` for **Ubuntu 18.04 Bionic Beaver** - `xenial` for **Ubuntu 16.04 Xenial Xerus** - `stretch` for **Debian 9 Stretch** From 7a45ac940e5d6c14f1c4fb05f1e6638c87f50b36 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 29 Jun 2020 16:39:35 -0700 Subject: [PATCH 03/65] Start v1.6.0 branch --- content/_snippets/rippled_versions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/_snippets/rippled_versions.md b/content/_snippets/rippled_versions.md index 85cbd82aac..c0982806ea 100644 --- a/content/_snippets/rippled_versions.md +++ b/content/_snippets/rippled_versions.md @@ -37,6 +37,7 @@ "1.3.1", "1.4.0", "1.5.0", + "1.6.0", ] %} {% for v in rippled_versions %} From 96185b584ea36e91edbfd7091bc148b46987151d Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 29 Jun 2020 17:09:25 -0700 Subject: [PATCH 04/65] Default port updates for v1.6.0 --- content/concepts/the-rippled-server/peer-protocol.md | 4 ++-- .../peer-management-methods/connect.ja.md | 2 +- .../peer-management-methods/connect.md | 2 +- .../configure-peering/cluster-rippled-servers.md | 2 ++ .../configure-peering/configure-a-private-server.md | 8 +++++--- .../manually-connect-to-a-specific-peer.md | 2 +- 6 files changed, 12 insertions(+), 8 deletions(-) diff --git a/content/concepts/the-rippled-server/peer-protocol.md b/content/concepts/the-rippled-server/peer-protocol.md index f61e95ce8c..de66bfab27 100644 --- a/content/concepts/the-rippled-server/peer-protocol.md +++ b/content/concepts/the-rippled-server/peer-protocol.md @@ -28,13 +28,13 @@ To participate in the XRP Ledger, `rippled` servers connect to arbitrary peers u Ideally, the server should be able to send _and_ receive connections on the peer port. You should [forward the port used for the peer protocol through your firewall](forward-ports-for-peering.html) to the `rippled` server. -The [default `rippled` config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file. +IANA [has assigned port **2459**](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2459) for the XRP Ledger peer protocol, but for compatibility with legacy systems, the [default `rippled` config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) listens for incoming peer protocol connections on **port 51235** on all network interfaces. If you run a server, you can configure which port(s) your server listens on using the `rippled.cfg` file. Example: ``` [port_peer] -port = 51235 +port = 2459 ip = 0.0.0.0 protocol = peer ``` 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/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..b40c9b561e 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. [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..c3956f2fe3 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. [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/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..b6bf00c59a 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,7 +8,7 @@ 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 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 apppropriate 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. From e441b45d717e26b6f447c55b33110c9e39e50371 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 29 Jun 2020 17:10:44 -0700 Subject: [PATCH 05/65] Health Check method: set up IA --- .../the-rippled-server/peer-protocol.md | 2 +- .../peer-port-methods/health-check.md | 5 +++ .../{ => peer-port-methods}/peer-crawler.md | 2 +- .../{ => peer-port-methods}/validator-list.md | 0 dactyl-config.yml | 37 ++++++++++++++++--- 5 files changed, 38 insertions(+), 8 deletions(-) create mode 100644 content/references/rippled-api/peer-port-methods/health-check.md rename content/references/rippled-api/{ => peer-port-methods}/peer-crawler.md (93%) rename content/references/rippled-api/{ => peer-port-methods}/validator-list.md (100%) diff --git a/content/concepts/the-rippled-server/peer-protocol.md b/content/concepts/the-rippled-server/peer-protocol.md index f61e95ce8c..6a89c2b734 100644 --- a/content/concepts/the-rippled-server/peer-protocol.md +++ b/content/concepts/the-rippled-server/peer-protocol.md @@ -39,7 +39,7 @@ ip = 0.0.0.0 protocol = peer ``` -The peer protocol port also serves the [special Peer Crawler API method](peer-crawler.html). +The peer protocol port also serves [special peer port methods](peer-port-methods.html). ## Node Key Pair 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..15bea70139 --- /dev/null +++ b/content/references/rippled-api/peer-port-methods/health-check.md @@ -0,0 +1,5 @@ +# Health Check + +The Health Check is a special [peer port method](peer-port-methods.html) for reporting on the health of an individual `rippled` server. + +***TODO: detailed description. PR: *** diff --git a/content/references/rippled-api/peer-crawler.md b/content/references/rippled-api/peer-port-methods/peer-crawler.md similarity index 93% rename from content/references/rippled-api/peer-crawler.md rename to content/references/rippled-api/peer-port-methods/peer-crawler.md index d81fb93ab6..36093f41dd 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. diff --git a/content/references/rippled-api/validator-list.md b/content/references/rippled-api/peer-port-methods/validator-list.md similarity index 100% rename from content/references/rippled-api/validator-list.md rename to content/references/rippled-api/peer-port-methods/validator-list.md diff --git a/dactyl-config.yml b/dactyl-config.yml index 69c62815d3..0011973f0e 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -5868,35 +5868,60 @@ pages: targets: - ja - - md: references/rippled-api/peer-crawler.md + # TODO: translate title & blurb + - name: Peer Port Methods + html: peer-port-methods.html + funnel: Docs + doc_type: References + supercategory: rippled API + category: Peer Port Methods + template: template-landing-children.html + blurb: Special API method for sharing network topology and status metrics. + targets: + - en + - ja + + # TODO: translate page & blurb + - md: references/rippled-api/peer-port-methods/health-check.md + html: health-check.html + funnel: Docs + doc_type: References + supercategory: rippled API + category: Peer Port Methods + blurb: Special API method for reporting server health. + targets: + - en + - ja + + - md: references/rippled-api/peer-port-methods/peer-crawler.md html: peer-crawler.html funnel: Docs doc_type: References supercategory: rippled API - category: Peer Crawler + category: Peer Port Methods blurb: Special API method for sharing network topology and status metrics. targets: - en # TODO: translate page - - md: references/rippled-api/peer-crawler.md + - md: references/rippled-api/peer-port-methods/peer-crawler.md html: peer-crawler.html funnel: Docs doc_type: References supercategory: rippled API - category: Peer Crawler + category: Peer Port Methods blurb: ネットワークトポロジーとステータスメトリックを共有するための特殊なAPIメソッドです。 untranslated_warning: true targets: - ja # TODO: translate page & blurb - - md: references/rippled-api/validator-list.md + - md: references/rippled-api/peer-port-methods/validator-list.md html: validator-list.html funnel: Docs doc_type: References supercategory: rippled API - category: Validator List + category: Peer Port Methods blurb: Special API method for sharing recommended validator lists. targets: - en From 0f807c6e09b51f56f553ef461249e698c9d04d15 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 1 Jul 2020 20:43:08 -0700 Subject: [PATCH 06/65] Health check details (+related edits) --- .../amendments/amendments.md | 2 + .../peer-port-methods/health-check.md | 65 ++++++++++- ...onnect-your-rippled-to-the-xrp-test-net.md | 4 +- .../installation/build-run-rippled-macos.md | 12 +- .../installation/capacity-planning.md | 8 +- ...install-rippled-on-centos-rhel-with-yum.md | 37 +++++++ .../health-check-interventions.md | 104 ++++++++++++++++++ dactyl-config.yml | 12 ++ 8 files changed, 233 insertions(+), 11 deletions(-) create mode 100644 content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md diff --git a/content/concepts/consensus-network/amendments/amendments.md b/content/concepts/consensus-network/amendments/amendments.md index de5008f0e0..528eb9dbb8 100644 --- a/content/concepts/consensus-network/amendments/amendments.md +++ b/content/concepts/consensus-network/amendments/amendments.md @@ -92,6 +92,8 @@ The amendments that a `rippled` server is configured to vote for or against have If your server is amendment blocked, you must [upgrade to a new version](install-rippled.html) to sync with the network. +It is also possible to be amendment blocked because you connected your server to a [parallel network](parallel-networks.html) that has different amendments enabled. For example, the XRP Ledger Devnet typically has upcoming and experimental amendments enabled. If you are using the latest production release, your server is likely to be amendment blocked when connecting to Devnet. You could resolve this issue by upgrading to an unstable pre-release or nightly build, or you could [connect to a different network such as Testnet](connect-your-rippled-to-the-xrp-test-net.html) instead. + #### How to Tell If Your `rippled` Server Is Amendment Blocked diff --git a/content/references/rippled-api/peer-port-methods/health-check.md b/content/references/rippled-api/peer-port-methods/health-check.md index 15bea70139..268834aacf 100644 --- a/content/references/rippled-api/peer-port-methods/health-check.md +++ b/content/references/rippled-api/peer-port-methods/health-check.md @@ -1,5 +1,66 @@ # 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. +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][] -***TODO: detailed description. PR: *** +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 were unhealthy. Since some metrics may rapidly fluctuate into and out of unhealthy ranges, it is recommended not to 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 Peer Crawler 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 + +```json +HTTP/1.1 503 Service Unavailable +Server: rippled-1.6.0 +Content-Type: application/json +Connection: close +Transfer-Encoding: chunked + +{ + "info": { + "load_factor": 256, + "server_state": "connected", + "validated_ledger": 2147483647 + } +} +``` + +## Response Format + +If the server is in a **critical** state, the response has the status code **503 Service Unavailable**. If the server is **healthy** or in a **warning** state, the response has the status code **200 OK**. + +In either case, 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 [amemdment 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. If there is no validated ledger available, this is a very large integer value such as `2147483647` (architecture-dependent). This is a warning if the last validated ledger was at least 7 seconds ago, and 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/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..fccad80b78 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,8 +1,8 @@ -# 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. -**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: 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..ea86e56aa8 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 @@ -53,17 +53,21 @@ 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: + + $ 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 just cloned, create your build directory and access it. For example: 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..5252c636ce 100644 --- a/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md +++ b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md @@ -177,17 +177,19 @@ 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. + +During exceptionally high periods of transaction volume, some operators have reported that their `rippled` servers have completely saturated a 100MBit/s network link. Therefore, a gigabit network interface is required for reliable performance. Here are examples of observed network bandwidth use for common `rippled` tasks: | Task | Transmit/Receive | |:------------------------------------------------|:---------------------------| -| Process current transaction volumes | 2Mbps transmit, 2 Mbps receive | +| Process average transaction volumes | 2Mbps transmit, 2 Mbps receive | +| Process peak transaction volumes | >100Mbps transmit | | Serve historical ledger and transaction reports | 100Mbps transmit | | Start up `rippled` | 20Mbps receive | - ## See Also - **Concepts:** 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/troubleshooting/health-check-interventions.md b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md new file mode 100644 index 0000000000..4eb0aba822 --- /dev/null +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md @@ -0,0 +1,104 @@ +# 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. + +## 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) that is not very busy, 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. Some failures can be fixed with steps that your infrastructure can take automatically based on specific criteria. Other failures may require the intervention of a human administrator who can investigate and take the necessary steps to resolve more complex or critical failures. How and when you respond is likely to depend on your unique situation and infrastructure, 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 +- [Investigate network](#investigate-network) in case the problem originates elsewhere +- [Replace hardware](#replace-hardware) +- [Upgrade](#upgrade) the `rippled` software + + +### 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. + + +### 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, it may be necessary 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` + + +### 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. + +The proper way to resolve being amendment blocked is to [update your server](install-rippled.html) to a newer software version that understands the amendment. + + + + + + +{% include '_snippets/rippled-api-links.md' %} +{% include '_snippets/tx-type-links.md' %} +{% include '_snippets/rippled_versions.md' %} diff --git a/dactyl-config.yml b/dactyl-config.yml index 0011973f0e..ac158de17d 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -2758,6 +2758,18 @@ pages: targets: - en + # TODO: translate page and blurb + - md: tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md + html: health-check-interventions.html + funnel: Docs + doc_type: Tutorials + category: Manage the rippled Server + subcategory: Troubleshooting rippled + blurb: Use the rippled server's health check as part of automated infrastructure monitoring. + targets: + - en + - ja + - md: tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.ja.md html: diagnosing-problems.html funnel: Docs From c82994068b01a57704b41d2d04abd8102e721dfa Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 6 Jul 2020 16:20:50 -0700 Subject: [PATCH 07/65] Health Check: edits/cleanup --- .../references/rippled-api/peer-port-methods/health-check.md | 2 +- .../troubleshooting/health-check-interventions.md | 4 ++-- dactyl-config.yml | 2 ++ 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/content/references/rippled-api/peer-port-methods/health-check.md b/content/references/rippled-api/peer-port-methods/health-check.md index 268834aacf..a7405f8df1 100644 --- a/content/references/rippled-api/peer-port-methods/health-check.md +++ b/content/references/rippled-api/peer-port-methods/health-check.md @@ -49,7 +49,7 @@ The `info` object may contain the following fields: | `Field` | Value | Description | |:--------------------|:--------|:---------------------------------------------| -| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, the server is [amemdment 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. | +| `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. | 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 index 4eb0aba822..2ea9680a4c 100644 --- a/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md @@ -17,11 +17,11 @@ Certain server configurations may always report a `warning` status even when ope 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) that is not very busy, 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. +- 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. Some failures can be fixed with steps that your infrastructure can take automatically based on specific criteria. Other failures may require the intervention of a human administrator who can investigate and take the necessary steps to resolve more complex or critical failures. How and when you respond is likely to depend on your unique situation and infrastructure, but the metrics reported in the health check result can be a factor in these decisions. +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: diff --git a/dactyl-config.yml b/dactyl-config.yml index ac158de17d..74424430a3 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -129,6 +129,8 @@ targets: "transaction-metadata.html#affectednodes": "transaction-metadata.html" # Fix link from untranslated peer-crawler.html: "peer-protocol.html#private-peers": "peer-protocol.html#プライベートピア" + # Fix link from untranslated health-check.html: + "rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode": "rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由" - name: xrp-api-only From 69bfd526273f62b3e07f24d2a90d058b8cfb9146 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 7 Jul 2020 15:53:16 -0700 Subject: [PATCH 08/65] Link peer protocol w/ default port notes --- .../configure-peering/cluster-rippled-servers.md | 2 +- .../configure-peering/configure-a-private-server.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) 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 b40c9b561e..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,7 +33,7 @@ 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. [New in: rippled 1.6.0][] + **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: 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 c3956f2fe3..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 @@ -44,7 +44,7 @@ To set up a specific server as a private peer, complete the following steps: 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. [New in: rippled 1.6.0][] + **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. From fa277b719772b76a8b62a70b2c43c7c2505ad647 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 8 Jul 2020 13:39:28 -0700 Subject: [PATCH 09/65] Health Check edits: - revised per reviews - updated for rippled#3491 --- .../peer-port-methods/health-check.md | 63 ++++++++++++++++--- .../health-check-interventions.md | 30 +++++---- 2 files changed, 71 insertions(+), 22 deletions(-) diff --git a/content/references/rippled-api/peer-port-methods/health-check.md b/content/references/rippled-api/peer-port-methods/health-check.md index a7405f8df1..879094e711 100644 --- a/content/references/rippled-api/peer-port-methods/health-check.md +++ b/content/references/rippled-api/peer-port-methods/health-check.md @@ -3,14 +3,14 @@ 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 were unhealthy. Since some metrics may rapidly fluctuate into and out of unhealthy ranges, it is recommended not to raise alerts unless the health check fails multiple times in a row. +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 Peer Crawler information, make the following HTTP request: +To request the Health Check information, make the following HTTP request: - **Protocol:** https - **HTTP Method:** GET @@ -23,6 +23,24 @@ To request the Peer Crawler information, make the following HTTP request: ## 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 @@ -31,19 +49,44 @@ Connection: close Transfer-Encoding: chunked { - "info": { - "load_factor": 256, - "server_state": "connected", - "validated_ledger": 2147483647 - } + "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 -If the server is in a **critical** state, the response has the status code **503 Service Unavailable**. If the server is **healthy** or in a **warning** state, the response has the status code **200 OK**. +The response's HTTP status code indicates the health of the server: -In either case, 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. +| 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: @@ -53,7 +96,7 @@ The `info` object may contain the following fields: | `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. If there is no validated ledger available, this is a very large integer value such as `2147483647` (architecture-dependent). This is a warning if the last validated ledger was at least 7 seconds ago, and critical if the last validated ledger was at least 20 seconds ago. | +| `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 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 index 2ea9680a4c..8043c808a4 100644 --- a/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md @@ -6,10 +6,12 @@ Infrastructure monitoring, and reliability engineering more generally, is an adv ## 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. +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. @@ -27,9 +29,9 @@ The following sections suggest some common interventions you may want to attempt - [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) -- [Upgrade](#upgrade) the `rippled` software ### Redirect Traffic @@ -41,7 +43,7 @@ Redirecting traffic away from a server that is unhealthy is an appropriate respo ### 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: +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` @@ -59,9 +61,18 @@ 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: +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` @@ -77,28 +88,23 @@ In this case, the necessary interventions may involve changes to other systems, ### Replace Hardware -If the outage is caused by a hardware failure or by higher load than the hardware is capable of handling, it may be necessary to replace some components or even the entire server. +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: +Warning or critical values for the following [metrics][] may indicate insufficient hardware: - `load_factor` - `server_state` - `validated_ledger` -### 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. - -The proper way to resolve being amendment blocked is to [update your server](install-rippled.html) to a newer software version that understands the amendment. - +[metrics]: health-check.html#response-format {% include '_snippets/rippled-api-links.md' %} {% include '_snippets/tx-type-links.md' %} {% include '_snippets/rippled_versions.md' %} From 082adf421345104321c0b4c27eaa8c29f617c2c9 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 8 Jul 2020 17:54:40 -0700 Subject: [PATCH 10/65] Log messages: cleanup & upgrade message --- .../understanding-log-messages.md | 57 +++++++++++++++---- 1 file changed, 45 insertions(+), 12 deletions(-) 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..6fcedcc69c 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,7 +54,7 @@ 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): @@ -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: @@ -60,12 +82,23 @@ Check the `[insight]` stanza in your `rippled`'s config file and confirm that yo This error has no other impact on the `rippled` server, which should continue to operate 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 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,10 +161,10 @@ 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. @@ -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' %} From b278c75cacb1db71d947ffe46e20583bae8a9d80 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 8 Jul 2020 18:24:23 -0700 Subject: [PATCH 11/65] download_shard: validate field deprecated --- .../download_shard.md | 27 ++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) 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" + } +} +``` From 08782a3da5085e77588b056f0b1f4997a8f76c36 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 9 Jul 2020 23:40:22 -0700 Subject: [PATCH 12/65] Health check: fix broken link from untranslated page --- dactyl-config.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dactyl-config.yml b/dactyl-config.yml index 74424430a3..72976a7918 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -129,8 +129,10 @@ targets: "transaction-metadata.html#affectednodes": "transaction-metadata.html" # Fix link from untranslated peer-crawler.html: "peer-protocol.html#private-peers": "peer-protocol.html#プライベートピア" - # Fix link from untranslated health-check.html: + # Fix links from untranslated health-check.html: "rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode": "rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由" + "server-doesnt-sync.html#normal-syncing-behavior": "server-doesnt-sync.html#通常の同期動作" + - name: xrp-api-only From 764ed24f13a1b78a482cde1d549bc026a8da0b28 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:25:37 -0700 Subject: [PATCH 13/65] Adds commandline response to account_currencies.md --- .../account-methods/account_currencies.md | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) 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..95e3a244e8 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 @@ -133,6 +133,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" : "A18990ECC3FC7C1DCFF4B3ED98B436EA87B63195FE08DA205650FD7DE8445303", + "ledger_index" : 56823150, + "status" : "success", + "validated" : true + } +} +``` + The response follows the [standard format][], with a successful result containing the following fields: From 7b3e5010eaa21084bc97ceeea06478004fad7e2f Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:32:42 -0700 Subject: [PATCH 14/65] Fixes commandline request and response for account_currencies.md --- .../account-methods/account_currencies.md | 20 +++++-------------- 1 file changed, 5 insertions(+), 15 deletions(-) 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 95e3a244e8..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 ``` @@ -138,20 +138,10 @@ An example of a successful response: ```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" : "A18990ECC3FC7C1DCFF4B3ED98B436EA87B63195FE08DA205650FD7DE8445303", - "ledger_index" : 56823150, + "ledger_hash" : "F43A801ED4562FA744A35755B86BE898D91C5643BF499924EA3C69491B8C28D1", + "ledger_index" : 56843649, + "receive_currencies" : [ "USD" ], + "send_currencies" : [ "NGN", "TRC" ], "status" : "success", "validated" : true } From bc1433e65d0c162930a5fdfe557103d21b55ac5f Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:36:43 -0700 Subject: [PATCH 15/65] Adds commandline response for account_info.md --- .../account-methods/account_info.md | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) 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: From cf6a6ff5eb5d7dd421ab700dc6bf030913a75d58 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:41:49 -0700 Subject: [PATCH 16/65] Adds commandline response for account_objects.md --- .../account-methods/account_objects.md | 592 ++++++++++++++++++ 1 file changed, 592 insertions(+) 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: From aece660c445a61f3f158603e9d59b0114ede5397 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:44:51 -0700 Subject: [PATCH 17/65] Adds commandline response for account_offers.md --- .../account-methods/account_offers.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) 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..d69fa7bede 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 @@ -152,6 +152,19 @@ An example of a successful response: } } ``` +*Commandline* + +```json +{ + "result" : { + "account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", + "ledger_current_index" : 56843824, + "offers" : [], + "status" : "success", + "validated" : false + } +} +``` From e5d41d9740a6b7b3b0db632a40800d876378febe Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:52:35 -0700 Subject: [PATCH 18/65] Adds commandline repsonse to account_tx.md --- .../account-methods/account_tx.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) 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..270633a98a 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 @@ -557,6 +557,22 @@ An example of a successful response: } ``` +*Commandline* + +```json +{ + "result" : { + "account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", + "ledger_index_max" : 56843937, + "ledger_index_min" : 56843321, + "limit" : 2, + "status" : "success", + "transactions" : [], + "validated" : true + } +} +``` + The response follows the [standard format][], with a successful result containing the following fields: From 3a051f5caf9a151773962b1bc9c581d674b6a687 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:55:18 -0700 Subject: [PATCH 19/65] Adds commandline output for ledger_closed.md --- .../ledger-methods/ledger_closed.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) 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: From e820dd4e598ba0f2046b8aa6ac237aa6496e1860 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 14:58:09 -0700 Subject: [PATCH 20/65] Adds commandline output for ledger_current.md --- .../ledger-methods/ledger_current.md | 11 +++++++++++ 1 file changed, 11 insertions(+) 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: From 59493996b888cde76456236b2f89f888a6c30d07 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Wed, 15 Jul 2020 16:39:47 -0700 Subject: [PATCH 21/65] Adds commandline response for tx_history.md --- .../transaction-methods/tx_history.md | 552 ++++++++++++++++++ 1 file changed, 552 insertions(+) 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: From f500926adb50bcb02c6faf3482e260abc2d666a1 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 14:16:08 -0700 Subject: [PATCH 22/65] Changes tx hash to a valid hash and adds commandline/JSON-RPC response for tx.md --- .../transaction-methods/tx.md | 436 ++++++++++++++---- 1 file changed, 338 insertions(+), 98 deletions(-) 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 + } } ``` From 7da0dd9778677b656721958f1967d60ba6c03210 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 14:34:44 -0700 Subject: [PATCH 23/65] Changes tx hash and ledger index to valid values; Adds JSON-RPC/Commandline response for transaction_entry.md --- .../transaction-methods/transaction_entry.md | 447 ++++++++++++++---- 1 file changed, 344 insertions(+), 103 deletions(-) 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 + } } ``` From cf22a02bb6cd67c888c355f2931ceda6a348c9cb Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 15:08:00 -0700 Subject: [PATCH 24/65] Adds commandline request and response for ledger_entry.md --- .../ledger-methods/ledger_entry.md | 37 +++++++++++++++++-- 1 file changed, 33 insertions(+), 4 deletions(-) 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..4734894f71 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,8 +3,6 @@ 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: @@ -38,6 +36,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 +98,8 @@ An example of a successful response: *WebSocket* -```{ +```json +{ "id": 3, "result": { "index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05", @@ -118,7 +123,7 @@ An example of a successful response: *JSON-RPC* -``` +```json 200 OK { "result": { @@ -141,6 +146,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: From 7b4a6378462ce1b95865205b717d3c0b8d964581 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 15:13:18 -0700 Subject: [PATCH 25/65] Adds note to noripple_check --- .../public-rippled-methods/account-methods/noripple_check.md | 2 ++ 1 file changed, 2 insertions(+) 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..d43cf65ba2 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 @@ -3,6 +3,8 @@ 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. +**Note:** There is no commandline version of this method. + ## Request Format An example of the request format: From 2cd7ca070794c435077832bf41795cd339c8474f Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 15:57:06 -0700 Subject: [PATCH 26/65] Adds commandline request and response to gatewar_balances.md --- .../account-methods/gateway_balances.md | 57 +++++++++++++++++++ 1 file changed, 57 insertions(+) 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..a5da28acfc 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 @@ -40,6 +40,11 @@ An example of the request format: } ``` +*Commandline* +``` +gateway_balances rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q +``` + The request includes the following parameters: @@ -193,6 +198,58 @@ 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" + } + ] + }, + "frozen_balances" : { + "r4keXr5myiU4iTLh68ZqZ2CgsJ8dM9FSW6" : [ + { + "currency" : "BTC", + "value" : "0.091207822800868" + } + ] + }, + "ledger_current_index" : 56866688, + "obligations" : { + "BTC" : "1762.700511879441", + "EUR" : "958608.6233004864", + "GBP" : "4974.337212333351", + "USD" : "6746387.604424974" + }, + "status" : "success", + "validated" : false + } +} +``` + **Note:** There is no command-line syntax for this method. Use the [json method][] to access this from the command line. From 753863b3d525c5e7ae06613ccae5ec85a8dbf8e9 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 16:02:16 -0700 Subject: [PATCH 27/65] Adds commandline response for ripple_path_find.md --- .../ripple_path_find.md | 102 ++++++++++++++++++ 1 file changed, 102 insertions(+) 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: From 15140181abf703d099b670be49146ef3329921dd Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 16:06:32 -0700 Subject: [PATCH 28/65] Adds commandline response for book_offers.md --- .../book_offers.md | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) 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..a252e9b64c 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 @@ -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: From 494a6b7f12a26f4dd36126703b4132a7323bcd8e Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 16:10:27 -0700 Subject: [PATCH 29/65] Fixes comandline request and adds commandline response for account_lines.md --- .../account-methods/account_lines.md | 248 +++++++++++++++++- 1 file changed, 247 insertions(+), 1 deletion(-) 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..7cf6b4b365 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 @@ -36,7 +36,7 @@ An example of the request format: ```sh #Syntax: -rippled account_lines [] [] +rippled account_lines r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 ``` @@ -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: From ce083c8aaa40b82d34b6379df545fae46218bc6c Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 16 Jul 2020 16:26:42 -0700 Subject: [PATCH 30/65] Adds commandline request and response to ledger_data.md --- .../ledger-methods/ledger_data.md | 3773 +++++++++++++++++ 1 file changed, 3773 insertions(+) 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..90d73ce862 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 @@ -35,6 +35,11 @@ An example of the request format: } ``` +*Commandline* +``` +rippled ledger_data +``` + **Note:** There is no commandline syntax for `ledger_data`. You can use the [json method][] to access this method from the commandline instead. @@ -230,6 +235,3774 @@ An example of a successful response: } ``` +*Commandline* +```json +{ + "result" : { + "ledger" : { + "closed" : false, + "ledger_index" : "56867513", + "parent_hash" : "1377C0CAD6B0D331CCD3815753469A84D08DDA230481EE5CEA807D30F0AF0E11", + "seqNum" : "56867513" + }, + "ledger_current_index" : 56867513, + "ledger_hash" : "1377C0CAD6B0D331CCD3815753469A84D08DDA230481EE5CEA807D30F0AF0E11", + "ledger_index" : 56867513, + "marker" : "0004FCA7BBB8123368374A908D4B9146B42780E3F91653BB1D144795A9E8676E", + "state" : [ + { + "Account" : "rMj5DFATVxw91PDy3AM2wu7Uu1kgrhWypE", + "Balance" : "107723001", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "F18F0DF4B4921A468A5F968CE6E04EA800799C67E0659B9C4588988BCE9972B4", + "PreviousTxnLgrSeq" : 53524108, + "Sequence" : 3, + "index" : "000003E6AFED1AADCC39AAE0727B354C2286F1503274F345FE661748F24366CF" + }, + { + "Balance" : { + "currency" : "GCB", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2162688, + "HighLimit" : { + "currency" : "GCB", + "issuer" : "rBfVgTnsdh8ckC19RM8aVGNuMZnpwrMP6n", + "value" : "0" + }, + "HighNode" : "0000000000000283", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "GCB", + "issuer" : "rhRFGCy2RJTA8oxkjjtYTvofPVGqcgvXWj", + "value" : "2000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "C0C37CE200B509E0A529880634F7841A9EF4CB65F03C12E6004CFAD9718D6694", + "PreviousTxnLgrSeq" : 24695242, + "index" : "0000041EFD027808D3F78C8352F97E324CB816318E00B977C74ECDDC7CD975B2" + }, + { + "Account" : "rHeyw38ezc3LSLzYAYwaBci2KssDkYGVr9", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "7540CE04B966D67DBD39F3AA832274902B79AF4782F5AC9D4DC7CD18B1D9AE0D", + "PreviousTxnLgrSeq" : 47846971, + "Sequence" : 2, + "index" : "000004D417A9CE049C9A71A62B004659B5F1AAAB1BEA1EFDE4E01EB3497FD999" + }, + { + "Account" : "rLeNL66BfgeszBsCBKJcLmYTRThiWrNTUL", + "Balance" : "19999988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "E4BE6307E377590FF56BBF2F26DCBC4BA9682A4C141269352E4E2D4E53C1116E", + "PreviousTxnLgrSeq" : 37851086, + "Sequence" : 2, + "index" : "00000FB78838CA2CFA82E7438B4F54794A6783327326D58C46B4EF137C059038" + }, + { + "Account" : "rUwXrQMa4HHBbfxQT71YJNbQXaxZPR8Uhp", + "Balance" : "4999941286", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "B24817E7D4B9EC5CB29D2D36215F7BD6C7526020A9C1DC6C892C788E195DFCC4", + "PreviousTxnLgrSeq" : 55172051, + "Sequence" : 1, + "index" : "000012F60C3F1E226D03F974AE8E77250B2BEA91C38AB4146B6055A048C7D540" + }, + { + "Flags" : 0, + "IndexNext" : "00000000000019A5", + "IndexPrevious" : "00000000000019A3", + "Indexes" : [ + "07B06AC59BE6D6B3A4EA9B813FE3A13CF7F6FA21BB92D5F691CFE09FAD733EEB", + "19D40E64B1AB5270A8470542459BC8171A2BC119AD308C46C383495C1595503D", + "2358E16921A1A577B380F3E000452795D54237ED52A3B21C19ED5C8E2CACCC7B", + "2817196B387099A9651055D277411847EC9E904FB71CB9CC5CF2931309AC7B6A", + "39EACF818BBC1581BCE5121A0046C6A8E07EB52C051F3961465D2D612A728684", + "5326601A89F1529F3675DC13BF0F430E005A55CD0347601532B61A6B43538839", + "5D2F1DBFE9475D69F365D37B545644CF18CEE20E4A8276030545F40A495F3F28", + "5E15CE61F291F1119338F4876C5A29EAE547F1AB2C8AAE6598DB2F3F6436067D", + "829D72DCB03F7E01ED508287E1862471DAE1F438C95814705388950D35935969", + "87C2963F5A673B1BC9FD3835F1B45A20C50E2654B81739ED33522E33D09323E4", + "8ECBBA2E63E79F4D9FE2053EC9E497614F5522F40C54D874A16BB31E46DB01D0", + "938224E0CB58A1DD8879C8167FA5D95D634AD6CF8223BA80923F8566D70A3382", + "A59CC6C97348E202CE28A47C3DD0422C3CD173F6BD6B8D0EBC78407DDC1A4D30", + "B34C5B770B6CE3507876B6F6C9C45D53B74EAC8A0705F6E252751A53F3CAF18E", + "B74A96E754DFD2BC20B913B1586410CBB69CF53B497DFD48330CD8D44FFBA652", + "BC704823EFD7641B44E7509F2C3EF29596A9C2D95AADA3C3759BE4F9962F3E4E", + "CBC998EFF58214B886935FEE119DA9CD363489DED76306BE21F4B24A1D9B406E", + "D754ED5085D5B6A6A9F7C96325DE848292DD4C79F7FFC273F6D76D7A87F7BE7E", + "E82FC929F4AF4B2ACA74185633FA0D65E86DD65E505EEC38D1140D489772461E", + "F167F314E3BBFBBDC480860C7266C7C3440764CDF0ACA66F4AFEBD7F92C53FB2" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "RootIndex" : "D7AC7D74720E29A563100F2B494BADB198F8A9E9FA46F57AE07123151E0DFA7A", + "index" : "0000139EDA03EF58CE7176F1402035B5EB6AEE49724555DDB0EBA01432B009A8" + }, + { + "Account" : "rKKzk9ghA2iuy3imqMXUHJqdRPMtNDGf4c", + "Balance" : "40000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 4, + "PreviousTxnID" : "CF650E9A4AAE1ADFDF2633AE71F1782ADA4D3B52C949FEEC2FF3DAAF8C301762", + "PreviousTxnLgrSeq" : 42071651, + "Sequence" : 38, + "index" : "00001A2969BE1FC85F1D7A55282FA2E6D95C71D2E4B9C0FDD3D9994F3C00FF8F" + }, + { + "Account" : "rsSbmeMPVnpwWbDyY6HD9v8TYSg7kFNJga", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "4A12CCD9C8C28088A13D86A44F1C80B81387BD34520A0556509FF5404D9FA05C", + "PreviousTxnLgrSeq" : 45123172, + "Sequence" : 2, + "index" : "00001CA2EE28952E26D329A26BCF7A0DFB655C571863CD7CCCB924101CA3832B" + }, + { + "Flags" : 0, + "Indexes" : [ "4186664D76AFFB709791E2C23CE2B7D1843831F1B9B2D23D29B81108E46D1DED" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rJYkq4c6QxzuNaM8ELZWH2fdzvFRnCmXg8", + "RootIndex" : "00001FB94BFF05D391C58C5F72DB5A537F5C4AF8C91786B4A6AE874179928E87", + "index" : "00001FB94BFF05D391C58C5F72DB5A537F5C4AF8C91786B4A6AE874179928E87" + }, + { + "Account" : "rfTzpaFG3VXJsz5DmDhgrWD7Z7bSFWT4UE", + "Balance" : "20150090", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "E55C1DDDFE20148D1BE0A201E663DFBB282374000C43AE9A1745277CED7450AE", + "PreviousTxnLgrSeq" : 53524253, + "Sequence" : 2, + "index" : "000023E2F2CF80DCDE1C03D848B78FAB5E2B73512ADBA3EC78C85AE291932FBC" + }, + { + "Account" : "rh6iGDTJpZCGf86b81wkZ3BotUaKfRxaaN", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "1E9E5BAFDD854F3713D6E06CADE2C84E6C6F7191B6B57A153A7D6CA79C4D110D", + "PreviousTxnLgrSeq" : 35033153, + "Sequence" : 2, + "index" : "00002499977F7BBE9850B47AC2B560B69A809F1CED66F9DAC7C12CA8CCB40F4E" + }, + { + "Flags" : 0, + "Indexes" : [ + "136C747528D439646FE88DC99D2C9E308A7C72F17D844EC38271110118215CE1", + "55C7A61CCF63A11E20E5276D2ABE35432A42ED03D6C492CC68C93E91ECBC3EFE", + "66FCEB2CDFF777F27E04CF86EADF4D5A665AA122F6A7EE6F0CF2718D4B7D6295", + "6A331A832765BA269E9F3D7F211380501E5C6AA59AA0955FB177A0EA0025E60F" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rGRaBuffuAaaeedpvkrRM3cmX3SCK7zpaV", + "RootIndex" : "000025097E81A5B6FF027221FBB3B3CAFFF6FA690B78DA6EA0DF6E880CBA0A20", + "index" : "000025097E81A5B6FF027221FBB3B3CAFFF6FA690B78DA6EA0DF6E880CBA0A20" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rwdf1Yb6BpTkZyH9LwP5KagqK5c1uMYFPd", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "LowNode" : "0000000000000CBC", + "PreviousTxnID" : "84AD7C491291135D4FAB7C9AA8D5760105D95A42BBDCF88DA3F66EDF750A929D", + "PreviousTxnLgrSeq" : 34789991, + "index" : "000027B473B2EAB084323383428D054E66249BEC4AB16515256FEF2D27CD8D23" + }, + { + "Account" : "rKUN4CjifHrBc7yLjgQCDRPxaKevj5VkhX", + "Balance" : "4796311032", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "4F95433B1598042BD89F81C2CA1861E2340E2772F6A591F4D91E87BA38484B72", + "PreviousTxnLgrSeq" : 55179796, + "Sequence" : 3, + "index" : "000030C724B3C25B89A73D776005E33ACA9F7A1AEFB7538584AA8E9B36C93B8E" + }, + { + "Account" : "rD5TQBCZoHHnQQMHzd3bfqb8BHsDw94Msu", + "Balance" : "19988000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "B87984992FBCD48CA49101E7DC767D9F90889B601F79264F85104BB56F110531", + "PreviousTxnLgrSeq" : 10696061, + "Sequence" : 2, + "index" : "000033E22A320E5D1EA62689C561CB324FFE1103180947065079EB73812717A9" + }, + { + "Balance" : { + "currency" : "BRL", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0.63235217563" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "BRL", + "issuer" : "rfNZPxoZ5Uaamdp339U9dCLWz2T73nZJZH", + "value" : "0" + }, + "HighNode" : "000000000000005C", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BRL", + "issuer" : "rauwJ9JC6M6JtMG5dRw9Csny7ZHVBF1tFv", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "26736CF97C8F707109717C1123BB33FBB7B6312332877469A0F82FF2E1F10805", + "PreviousTxnLgrSeq" : 36874911, + "index" : "000036A8D891AE85170EDA8658B52EA21C163185A008B14506F3D6EE8C90C5ED" + }, + { + "Account" : "rnKNNFcbsZSDDnYFSpHSkRBYvsrP29ocBJ", + "Balance" : "49988981", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 3, + "PreviousTxnID" : "D6018D595E70972CF01A1351554D9F51951502C625A0CE5FB7B55001A3809D7E", + "PreviousTxnLgrSeq" : 30498238, + "Sequence" : 46, + "index" : "000036B2E4602C42011987825C97BCB0BEA3396115C2418BE9D70BB2BCA32BBA" + }, + { + "Account" : "r4ysrf6g7T6QgLGe6FtGQudWhRnxmyQaGK", + "Balance" : "20010988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "8B707CB44D543F12EBB2E3A3C65596B63C6F7B9AE1E77A6073D0469927E39F9B", + "PreviousTxnLgrSeq" : 39876093, + "Sequence" : 2, + "index" : "00003B5A931AE159DCDDABBDBB32A8F26B07A74203817009097B3F8F4440FF29" + }, + { + "Account" : "raAUvyzqUKM3JWZgGuwGfEfxUJJbpVnrQA", + "Balance" : "48575070060", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "29F37B398FCA123B8B4FAD88510170F156ACEA8E65AA21E8536997A9B238667F", + "PreviousTxnLgrSeq" : 56468588, + "Sequence" : 2, + "index" : "000043EE9FCE52E7691EB21E714D3FE5AE641363317C7D856085B7A0C2BE66EA" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-2500201.004512104" + }, + "Flags" : 1179648, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rGo32zaBLSBwC1fTYHjBsZxQk3Mo9E8rDZ", + "value" : "20000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rbwE6wsxzYat1YyGGxzAwq6wBSF5MdoAg", + "value" : "0" + }, + "LowNode" : "000000000000004F", + "PreviousTxnID" : "6BD812D3AF63299DFD1C123C76D366752AA4F09D0076D868EFC950A967C1B1D7", + "PreviousTxnLgrSeq" : 27109989, + "index" : "0000457D66BD69769E4BB05DDAB4269F5EB1A095026FDB04816058385D09568B" + }, + { + "Account" : "rP6dAps4bwHTf8bNNkhA4YKx3DeMNdr8sA", + "Balance" : "1886187898", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "73C54DAC576C4DA8851B47F9D802123C942C21026AF13B849F22215ED8AFA0A4", + "PreviousTxnLgrSeq" : 56330724, + "Sequence" : 1, + "index" : "00004718F616B0CC7E12949C8AC399A9FB383311C5515C110194223F1A8FE627" + }, + { + "Balance" : { + "currency" : "JPY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "30" + }, + "Flags" : 3211264, + "HighLimit" : { + "currency" : "JPY", + "issuer" : "rDKcJtUW5b8URJB5AVb41jkTeETfXWwahe", + "value" : "0" + }, + "HighNode" : "0000000000000029", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "JPY", + "issuer" : "rpNSWfSE2TkmwH4VK26d6RGwC7rzQb7xKt", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "3B7C0DE2A9F5FD2CC1C058763690EECB3452C76C6595F97318C98BF8D105DD52", + "PreviousTxnLgrSeq" : 34623483, + "index" : "0000484CEEDC4DAE666B2C2DEFD726575DD1D5197CC32C38B63F1D265462BD48" + }, + { + "Account" : "rEngbD1J8rrrMkKz8fBtdLRgarmMZTiNRt", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "1D8544851DF1E3B73B4299707AE9FBA4D9A375D30EDE6A7F9F6D2F9905AAA1DC", + "PreviousTxnLgrSeq" : 35751340, + "Sequence" : 1, + "index" : "00004C6EC792D443262DB347376ADB5781FCD6EC84E233826C9172BC14316D1B" + }, + { + "Account" : "r4arcs5ngLPmDeYoDLzaG7q5eWKs2LeuFK", + "Balance" : "200824800", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "9E6D3DC20F4069FAF1F25E2C26BBD8BD8BBBCCB13F92EC4AD4A190D5753604A3", + "PreviousTxnLgrSeq" : 37180721, + "Sequence" : 1, + "index" : "00004CA3D9AA87A56017E8CD56893DAECA090EF8CC393EA38758E22B5BDC7159" + }, + { + "Account" : "rDtMRovj32kjpJpnBR2HUqHAZ5HYjauFrL", + "Balance" : "614201036", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "CBC27919116C08DC751C8E2ED1E9772519C610F93FE8CE9414ACEC6E1E245AAC", + "PreviousTxnLgrSeq" : 45157979, + "Sequence" : 55, + "index" : "00005E8982DE87680E6D3DC143FD0B73A30EF873D1C6EB9F371BBE140F6D49DF" + }, + { + "Balance" : { + "currency" : "CAD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "99.67048908512925" + }, + "Flags" : 196608, + "HighLimit" : { + "currency" : "CAD", + "issuer" : "rnziParaNb8nsU4aruQdwYE3j5jUcqjzFm", + "value" : "60" + }, + "HighNode" : "0000000000000011", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CAD", + "issuer" : "rsPwcozMqkCr76TvABBjyzaGqvUrpcxafd", + "value" : "100" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "5CB4D8512C74A21DB45DD67F409A7E784FA79E0E0ABCBD3208574A3D4E48AA44", + "PreviousTxnLgrSeq" : 39514920, + "index" : "0000655AD48998D4F3D931356363FFBFE89416DD21A9159F647AEE3652AA076D" + }, + { + "Account" : "r4rZuKQRF3DpuVoftMfz9q6cae9UXiiTEA", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "2F586F9E23348AF1A6E2E5C11908A269657CBD61A8CB4C4A1CE69FBB34979643", + "PreviousTxnLgrSeq" : 54003659, + "Sequence" : 2, + "index" : "000065C9F41ABE752CBBF18C15B35294045A686B7242B14D6FE5175C48459BFE" + }, + { + "Balance" : { + "currency" : "ALV", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.3" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "ALV", + "issuer" : "rPJM3GsQjpZLd3CQWSpqGs1qWEG1X4vpSm", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ALV", + "issuer" : "raEQc5krJ2rUXyi6fgmUAf63oAXmF7p6jp", + "value" : "0" + }, + "LowNode" : "000000000000005C", + "PreviousTxnID" : "4B905BDB67CDCE068FB216B7ED3833C0743944B8170B3FB4BBF2C124EA6C7BE7", + "PreviousTxnLgrSeq" : 37878390, + "index" : "00006CB62921C8A4D42D4375440A0636104A1F6F3E48ADBFF9D83A405D241223" + }, + { + "Account" : "rKQSz4tYnAi4au4v8eEa6hkUrDjukLTVi4", + "Balance" : "20420366", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "80755ECA9A09E3D9A05D012FEB2F0DE2D6CD93B36478087F4925722E4A8500EA", + "PreviousTxnLgrSeq" : 36172509, + "Sequence" : 6, + "index" : "00006D7682A29260C4079ABC2E810ECF68AE784D4E7E5E152F587C3A0816F254" + }, + { + "Account" : "rEhKQnKYjTBqmWyWGfYtJgx9CxCBauLu3S", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "F18D40F603177CE74689FFB5972EC4A167B639A2F2A11AB7671B32CB7A9F3118", + "PreviousTxnLgrSeq" : 35040704, + "Sequence" : 2, + "index" : "0000710FFC8D60A8BCA7BA5BFC00EE81FC7D3BB2AE5E8ECE92CC4E441B63CE80" + }, + { + "Account" : "rJLQ56pHabZ6o2mNSmprBxy6DdCwdxTAzd", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "E18725C56FB60084F05162BCE7946861A470AE620BDD5DE519D15D260594578D", + "PreviousTxnLgrSeq" : 42119175, + "Sequence" : 4, + "index" : "00007429BB237782C9406EF25B09463DD751712E4D21F49DC221CFE4CF262660" + }, + { + "Balance" : { + "currency" : "ADA", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "ADA", + "issuer" : "rJXGFDrN5h3ooiCSsupPXhg81QgGtUQmeJ", + "value" : "0" + }, + "HighNode" : "0000000000000001", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ADA", + "issuer" : "r9TPUpytcjmo9UaM9kwu6VmDSuVXqSxWUi", + "value" : "1000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "E64DE7F158AD81B20D8E10255CC9BE0ABB39347C80CB61205D538F905A1DCABE", + "PreviousTxnLgrSeq" : 28152986, + "index" : "0000812BF6B7152E240E8A41A224C876F4A006DCD570F2E9FC6BFB34A9A5F960" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rBadiLisPCyqeyRA1ufVLv5qgVRenP2Zyc", + "value" : "0" + }, + "HighNode" : "0000000000000002", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rfVBtKzz4kAuxcaESZv3tF3vcsHfeWBoho", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "12D2D09C90F49889718B60BF3A03493364EB665C0F558EA12CEE1B0C35D5C124", + "PreviousTxnLgrSeq" : 9301047, + "index" : "000082B286E3162EC4ADA91330AF0072D1B51748089906F635AB7B30966C56F4" + }, + { + "Account" : "rPR6WAoPKByT92Sjuji8Y8EABTGaLaACV3", + "Balance" : "209270000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EF6518AB9506BFC883182600E2FDDEC016BEA5412C7C8A3EDFDCEFC06D4CDC3C", + "PreviousTxnLgrSeq" : 35893835, + "Sequence" : 1, + "index" : "000084346288D9C0EC50D79D394230D7C5CB3190DCD9527B8F1FA18084A7DA5C" + }, + { + "Account" : "rJUkQCKwM9smokgL7iD6oyLTx813PaQUiY", + "Balance" : "35009535", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 3, + "PreviousTxnID" : "8227B98C50DD76CAE2D226066CA9C3AFFD3F3F7B97D0CA755BAA0C61465A3808", + "PreviousTxnLgrSeq" : 48263445, + "Sequence" : 36, + "index" : "000086CE48D95A92F078B5128845C3BCDF56E7DA88D7E35089DBE5AFF7D81C0C" + }, + { + "Balance" : { + "currency" : "ETC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "ETC", + "issuer" : "rDAN8tzydyNfnNf2bfUQY6iR96UbpvNsze", + "value" : "0" + }, + "HighNode" : "00000000000001E5", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ETC", + "issuer" : "r3X34kvPSV2jGU7fgUb3wh1XCwr6WCbm94", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "E763D1AF0BFEAA558D42B33361DEB3C7BEDC46AFF41D016EE726554C4C365294", + "PreviousTxnLgrSeq" : 34855014, + "index" : "00009472587A9D425875950F0FA34CDC7A69F384AC28A756C5A2322AE0F0A1C1" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "00000000000002D9", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rpHbU3xao4QxtqHSFS8ojDMxPFcbasrRmb", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "7B25FC571E190538386BEE9F2CEC94E01BC6455B3872151C693171101D5EEF9E", + "PreviousTxnLgrSeq" : 29254689, + "index" : "000099FD3C2741BAF3C66AC48F770DDE2B32C16AC81EAAD88262866B263F5523" + }, + { + "Account" : "rNB3TknEkY3kjpwNCGVxpvBwyowyGuwfVh", + "Balance" : "23169305", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "09574601F2AEDFFF4CF61CF377C298F07FC9A13B5127B4C53EED3B29A756F70C", + "PreviousTxnLgrSeq" : 35690032, + "Sequence" : 4, + "index" : "00009C1C21886B5C2BDE0B7751F96EBC3B7C8C57AA8D16E3A818591624A1A5A9" + }, + { + "Account" : "rKbyYMKzTgvhsUqgeEbpdq6WvQc8rupMGn", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "8D54FAD13DD5B90133B3FA1F2BDBFA15559DA35159B670AB8B5FF51F29EE39A0", + "PreviousTxnLgrSeq" : 33977868, + "Sequence" : 2, + "index" : "00009C2BEF50C671658F700078E740B87F650E081B55CC3FA32A00475F621D66" + }, + { + "Account" : "rLkrSbJgLHPdQFn1QcRTCDmRWvZpp27tah", + "Balance" : "50624403", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "412FAE0959898C325238876A0C039096C39B25A3810C708D56C9899FB2384903", + "PreviousTxnLgrSeq" : 35648800, + "Sequence" : 5, + "index" : "00009D28A1AE6FFC984B771DAE107699091DF44F6910FD05B12CC09E3F7DE801" + }, + { + "Balance" : { + "currency" : "XEC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2162688, + "HighLimit" : { + "currency" : "XEC", + "issuer" : "rMpiGaEM9Qp3icX7wPHTdxbkphHWLJcX34", + "value" : "0" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "XEC", + "issuer" : "rNx3ty1w48iAa4JDfqhZk6bphwXxvCEtZP", + "value" : "0" + }, + "LowNode" : "0000000000000007", + "PreviousTxnID" : "01AD5E21337686A2F709773A28501B2023D3A950550BEB03C43462B98731A9E9", + "PreviousTxnLgrSeq" : 35883799, + "index" : "00009E2036FD1B363A6E2B6752F7C672D652E3A559579BFF3C493587C8C231C3" + }, + { + "Account" : "rDR96JmJAsEgZThPnREZTSdjKPZDnH5k5f", + "Balance" : "153819291", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "EB5515580E16071F0EA96B3313D72C6545F23CDF0C32547A9ACCB2FCE404A4F0", + "PreviousTxnLgrSeq" : 35368386, + "Sequence" : 7, + "index" : "0000A80432DEC44EE6228DE4A0528EFF76E28288D5E2A0384DD3432D976984A3" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.000459110023164767" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rPireoEmXsz8hke3T7mrdDkqfzxj4uY4ae", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", + "value" : "0" + }, + "LowNode" : "0000000000001003", + "PreviousTxnID" : "1F9E636AC4FEE0C01EEE0E0559121689AABC70BE7ECF5B60E4ECB78627523583", + "PreviousTxnLgrSeq" : 41398225, + "index" : "0000A9D1FDBC542726D379D855E4CB3E2C05483B6F033F43408DAE9E1838B70B" + }, + { + "Account" : "rHKEQxk3G2EEZnsmiCd8RsBM5UigC5qiVe", + "Balance" : "350000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A6382E793984B79E2938C66CCA9F2D694F5CACBAE21B50A3FF9EC40930A12599", + "PreviousTxnLgrSeq" : 34504001, + "Sequence" : 1, + "index" : "0000AC1E487CC20D9FF8314022473B1D5F106D35BFC3BB33032FBF976230B0FF" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rHYSdyKPrtDegWkHibXK3YApwKfn5J1rEN", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", + "value" : "0" + }, + "LowNode" : "000000000000049B", + "PreviousTxnID" : "8424AF691677ACEA9B0113B2CBDC577AABE251E1EDDB018E0744FEE8C90C58DB", + "PreviousTxnLgrSeq" : 31621663, + "index" : "0000B24C620FBD0E8B1313022AA4857E5300FB70FCDE9F194F901D567C70EDFB" + }, + { + "Account" : "rEFh3ZGKaxMJwWPXxiYYa8kiXJyVMJNwoY", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "42F82FF6D1EB50C5DD13784F073F231BA887922AB9958BF2C4A168438711AF88", + "PreviousTxnLgrSeq" : 47429528, + "Sequence" : 2, + "index" : "0000B482CF9E7E9BB4350CF185A306BE9165218401EB559379A00AA0C7915312" + }, + { + "Account" : "rh3C81VfNDhhWPQWCU8ZGgknvdgNUvRtM9", + "Balance" : "13000000894", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "4FEE14F4552879897B61C77CA5E0A884652102EF62396C09835BE9477E2B8969", + "PreviousTxnLgrSeq" : 55182503, + "Sequence" : 1, + "index" : "0000B717320558E2DE1A3B9FDB24E9A695BF05D1A44E4A4683212BB1DD0FBA23" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0.032809672000001" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y", + "value" : "0" + }, + "HighNode" : "00000000000001C0", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rhNTmR8ej24mL1LXv3ZsCnrQop7c6bocQp", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "4710BF02E5791A7D69FC384C874A40E06F1E23E63FA7FD6355D1B439F436B2D5", + "PreviousTxnLgrSeq" : 21050911, + "index" : "0000B87C9CD0F3530C71A8921FBCF127EAECA5C9DA92717AFB1CE9F63C8BBD6E" + }, + { + "Account" : "rhVcmcoptD1Kgeeag9mhsTPWQSZk8eTz9A", + "Balance" : "182376831", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A6803D6CE4199E0F74C52788C7A148E4AF9E9A0CBFF072B469ECC5C0DCB448CB", + "PreviousTxnLgrSeq" : 36446538, + "Sequence" : 1, + "index" : "0000BF2224BB915521C921773AFE11E1CE59CF69F6AE3AB6827707102103C47B" + }, + { + "Balance" : { + "currency" : "ETH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.00002" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "ETH", + "issuer" : "rHzVgKskCRFpg1X3aBU5AtvQnDD5mqSX92", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ETH", + "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "value" : "0" + }, + "LowNode" : "00000000000009FD", + "PreviousTxnID" : "AE750643C6C355A176A65981CA9D1831A7C226F230420624CE8C8C32A4C22316", + "PreviousTxnLgrSeq" : 35743316, + "index" : "0000C2D68E9A1E1919E930D0D063A183DBA39798286DFEE32E1EF5379A8F6B79" + }, + { + "Balance" : { + "currency" : "RUB", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 65536, + "HighLimit" : { + "currency" : "RUB", + "issuer" : "r4wnCs62uGuGBuoSttaYsiFedZ3Wd6NPJJ", + "value" : "0" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "RUB", + "issuer" : "rU73c3tdNz6vpKjs5432YFxgepizkV1qyp", + "value" : "0" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "B7AC4670461DEA315826E37A90C63D2C66045F829FC6C603AD0C9FB25A2BA226", + "PreviousTxnLgrSeq" : 56277523, + "index" : "0000C3C0AE5883C4B4455845A39F97C48DC4D62101F38812213DBAE00A086060" + }, + { + "Balance" : { + "currency" : "JPY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0.54045001548441" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "JPY", + "issuer" : "r94s8px6kSw1uZ1MV98dhSRTvc6VMPoPcN", + "value" : "0" + }, + "HighNode" : "0000000000000147", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "JPY", + "issuer" : "raUX9XGwCx7sowwdk8FnvbyZ3LYrvRYsxF", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "0F31CA12B366AF3E658EBA68EEEB1AFCA7D28CFB74BF6CD22C02CFCA82BDC983", + "PreviousTxnLgrSeq" : 32752843, + "index" : "0000C864EB051CF0D4A1EBB5B92390769CD2E84FFCFDD00E8FEF6DD6CF545BCF" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "1.2339878" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rPT74sUcTBTQhkHVD54WGncoqXEAMYbmH7", + "value" : "0" + }, + "HighNode" : "000000000000008F", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rRFBj6g2mVXstHfzsQE6Y9WX1F6fhqcTK", + "value" : "100000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "265DBB6009C3CC5A89421DBE0293AFAAE2F9F9040C72CDCA406F0C1EC29314FB", + "PreviousTxnLgrSeq" : 35575141, + "index" : "0000C9ECB507AE2CBA320D2D85708AA5C064A291BED7D6988A3F0DAA028F06AC" + }, + { + "Flags" : 0, + "Indexes" : [ "454E2E047AF37AD08E2923C7550A3852EBD5653423BF5C53083BDEDBB1416F3D" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "r4TByrtckppjYXH1Ga6H67T4cVSo9NbJoa", + "RootIndex" : "0000D04DD09A3AFFD4F72DBC82676D87FA0E78100318030253F554B716DBAB61", + "index" : "0000D04DD09A3AFFD4F72DBC82676D87FA0E78100318030253F554B716DBAB61" + }, + { + "Flags" : 0, + "IndexNext" : "0000000000000042", + "IndexPrevious" : "0000000000000040", + "Indexes" : [ + "09FD4F9F11B873C9D9305FA3CF6A69DF7094EE62249302E42116FD6785DA01D3", + "0B7BFBA537D9D61801B71D148C0D009894ADD05421FF3BA3DE9B034735815E97", + "0DCD793E55A28C0D8FD0605A223A4999B4F0B330B0EBD4E680FE9D211F2A019B", + "11F82E1B83AED8D65106519CDBF03F4FD593BCED7DB250C11DCC0C4F1E62D722", + "286BB3EE7EA39BF84F09AD171F2B0A3E989E33430AAD4956060F65BB075D96FE", + "2FF3DFC02FFDEEF16504F982C45FDCBF64D33474B1BF70AE5D575F87286AB8FE", + "33B19788AF95B4974AF78334610D36EE12121705E63EA668BE0B5DEE61732157", + "498A5D8BBB03EE6D9A3895DFDEE92CF0C50F4E59CB6774C403BA8A2144D3B148", + "564C375F8963269E3025B547E57C6DA19C08F1DD57A9C84638E29CDE012576AC", + "598F891A026B8CE95A2925D608D22DB9FC421FC89CA94AA779EA423FF0A76ACA", + "5BB8D13A07B741D1DF1FCC66E97AE8D628FA77CB4DBCC31F8905CFCC1BC49BB7", + "5FFBF4BD8FAAD3F0BD450C27A14934C6BA0826DC5E0E8E48EFA6136DAC2810A4", + "62606281D0B3BEDDDC0BEE1D3D71E3786396522238822F38C5FE965FC9A31307", + "6D6E102E93C57FA1DE3B90C89958ED1A7985CADC790B0B40E44605E50D49B21A", + "79881E278AB359606FD58984CD0D18AF1364CC589A520DAE28EB60EE5369D0DC", + "7D9A657FCF24BFBE5DD09C05C44988439D26407937802A0FC6B1922307A886F9", + "82B1F7A3235BC90220751DB626090054A2C6084B9BAE0CF95B88A6D778964B34", + "8EB4CA0F9A5492F68F26B04C87B7641EB5FA060BAD3ED76C7EC2E6C76C15EBC2", + "900C7D947C9F3462F347884EA14A853EFC1417A2BE5B0513F0D422A3A085E1B4", + "9E853D5188667FA3DBF3E94DB8BCF75DD0AFCEAA84EC44E23E5ADA6CC3E17AC3", + "AD35E5B4821CDF4334B4A8221218CEF1DA96F24DFA59062C571FB8F4BE27A258", + "B4294BFC9B9622F15560D0403182D7D6ADD05A4A0CB75808395A8BE303FE97A3", + "BF44E394383AC131812E3CB525A75174FBDF43C6DEAFA6B5AF78897287B415B5", + "C08C5409998CED4B0F7B813C4448839ED53A4F290BBC0C71467B6DBA9B5F6B9F", + "C799828B25BB5C7896FB03A27F36C08CD6BBAFC8F7D7FCA68FF1C727369D647A", + "CF04F0477E7BF590302293097B5D441451BBC54ACAE0F396D846A5E2BB4ED809", + "D4172E534583CF88B32357F81402620B0BD7A85248F277CE35654D70792335F9", + "DFCCAE3AE0FB534E1DE93449F4ABB6670CC88B03B91158B7A52650D251905FF1", + "E0E55DF7339BF8EC3150A5D0C624ACDA9A2D9CF88781628189CCC0F2ED4E74AB", + "E329C7D93439B45442CA8B97B8BC2F093EEB1BA2E6C4139C510C3E4FB9F273B4", + "EAE50BF969F4A3CE8C6FCAE744DF3B797057B0B2CE6CAD38A54136AEE3614D01", + "FB594E5E88B25B7AF5863CEFC7A3FE0A55F8486C6D5A3DFD7626428F879F60D5" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rpJZ5WyotdphojwMLxCr2prhULvG3Voe3X", + "RootIndex" : "5655E14CF12014525D1BC1E68DB09518514FEDCD3EE26F4865109B56B9EE3650", + "index" : "0000DAE48F41B86821B14F1892D6AD3F6996B608338ACFC363823858CB251020" + }, + { + "Flags" : 65536, + "LedgerEntryType" : "SignerList", + "OwnerNode" : "0000000000000000", + "PreviousTxnID" : "B06C49812F7E3A84A75C78F38B920966A94ED5F85C4E6EFD34C523A6C797614A", + "PreviousTxnLgrSeq" : 47260685, + "SignerEntries" : [ + { + "SignerEntry" : { + "Account" : "raWr8dtNxddY2bqD51LZh9z77R23iyP3PZ", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rwJkTfV8XXThGBUoC7sACmyWepw4iurYHb", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rGtDNiHFHNTNSnoeLg5usoRnLx33ABTWhT", + "SignerWeight" : 1 + } + } + ], + "SignerListID" : 0, + "SignerQuorum" : 2, + "index" : "0000DFFDA866FD9215A794C2FC7FBF3302EF1335E3835D1B74E73780ABE32AB3" + }, + { + "Account" : "r4cPWQKVertBh6auBn6t2rXh9kht4LoabA", + "Balance" : "25032932", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "27653F0C331B2317D35D5677BBCD0DE639E65E365392EFC8D691A824085AC864", + "PreviousTxnLgrSeq" : 38365202, + "Sequence" : 61, + "index" : "0000E78D01EE4EDDE598B933D1092A1E00B922FDEDD58CFB25E3AF2CE099AF48" + }, + { + "Account" : "rKru2mJkxPrum8VAZHhdoSYEwMW7G7KFD9", + "Balance" : "38871400", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 3, + "PreviousTxnID" : "0A91F6560E32B6C13285E5F98DF81B04EBC919ABD60126F529ED3A82C93E5F68", + "PreviousTxnLgrSeq" : 35803787, + "Sequence" : 23, + "index" : "0000F5AB075F8C48286156A300F367F7E370434B0F08CA0475DDA47B1854CA62" + }, + { + "Account" : "raxoUPmpy1x7bfUX2giVfMWkPMa3vWW8f4", + "Balance" : "1121000177", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "AD4616FD44650D3E279D534BD1799AB825891449ED7E2413403666E9CF18935E", + "PreviousTxnLgrSeq" : 53532513, + "Sequence" : 1, + "index" : "0000F89B1E8F215DE7D737674050C33557974864924B2F692129560508BAAB0F" + }, + { + "Account" : "rQDZcUFcbRNXHppFUFFiTtii3hRoyjTxAV", + "Balance" : "11834990892", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "1772D4ECED1698225672ACDA3168ED886DD8F7669538BD2AC6F4B12CF9315500", + "PreviousTxnLgrSeq" : 55170656, + "Sequence" : 1, + "index" : "0000FFE18AF90D9780964C9E7A4C2F8D82C6E78C0267344B6B4232AFB9E56DA0" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 131072, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rKUK9omZqVEnraCipKNFb5q4tuNTeqEDZS", + "value" : "10" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B", + "value" : "0" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "87591A63051645F37B85D1FBA55EE69B1C96BFF16904F5C99F03FB93D42D0375", + "PreviousTxnLgrSeq" : 746872, + "index" : "000103996A3BAD918657F86E12A67D693E8FC8A814DA4B958A244B5F14D93E58" + }, + { + "Account" : "rBTpxtceMtXUKit2mQkVcWKuDHYCR7LKdD", + "Balance" : "999988000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D59694A9C6A9AAE645E51EF4FD7F9B20835A52381035B2FD99905AC6DB9850A2", + "PreviousTxnLgrSeq" : 11683667, + "Sequence" : 2, + "index" : "00010BC07B606D414CE5F140403152AC34B34EFC27E646E337D1F11593F559DE" + }, + { + "Account" : "rPDT5VZCLM2wv1qwmpbCjQfn1wXBANRhQ5", + "Balance" : "24977500", + "Flags" : 1179648, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "AD9F7BF745AC3567B30BAABFEFDA224042A184B3A094450DDFA7E13B1D6DCB3B", + "PreviousTxnLgrSeq" : 51348778, + "Sequence" : 4, + "index" : "00011327A3CA29B88F23A58B640CE23135C18E4E2A8C2333B09D7D3112459637" + }, + { + "Flags" : 0, + "Indexes" : [ + "0DB0815613B4FA7A2DE7E9551E6D2117ACD1036E1CCD14414C7905AEFC072549", + "405161AF4FBEA97F25331DEB3D2E56531245CA4F010639443AE3C8E9A5A0380C", + "4F8D5788C721E2B9F38E23DCF5396F2D6B1EF8E32BC8415495122B0F6437743F", + "C1B13E99BC56A1B4357DED440EBF0BADB1C402F582CF971401629D8FF82619B6" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rBk2i1frpX2jJC1eBm2HcWmnUdR9ZRbHwG", + "RootIndex" : "000117DF584A463510F7620C204E0FF6F64206ACD62CE887BF57EF93A4BC0DAE", + "index" : "000117DF584A463510F7620C204E0FF6F64206ACD62CE887BF57EF93A4BC0DAE" + }, + { + "Account" : "rGubvAoDEmWdiAd6ovfDVuvAViDFA6nrre", + "Balance" : "24828477", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "BD722F6D1595FDB183EA340EAF0A781A91CDD487B6EE0C65AF9F031C16957246", + "PreviousTxnLgrSeq" : 51275279, + "Sequence" : 5, + "index" : "00011C8B64D31D25AD6758E0AB72765EF24EB5535AE256A6AA696536A359010A" + }, + { + "Flags" : 0, + "Indexes" : [ + "22E578265CD7E5F46DD0695DD55428CF8F797CC1D6C4C1F5F829EC677253235B", + "2FB51B174723021E30D21A5CE4CF94CF1A99649EC33D8BE60CDEBE422E18D855", + "5177CC903382225113B6BDBB881A00EEF4EBB6BFA3947940673DE5FEDC8B751B", + "81F699D15B2BE1B9FE4486B95593B27067D8E5728AA21D69C86FF4F59BE7F608", + "A76CE2AC7714162E989F93717F58F7319A08DC2CD7F65411048B5E2DC5365DFF", + "AA1A0958D561E2A885345AFD76E676EDD29BE76FB2AE65B8739BD889EFD8092A", + "D00DD039D22BB25EC1DD8AE7BAA3BFECA41766974C094DBDF47A3718975D8749", + "D127376D2F4E392EBB296001ABFF8E03FC602924618D98EA7D6C748613DEC9CC", + "EF2F3AA2F93512F263BB79C838B6DDF53E0199C59B63CC7D12D905E7097652A3" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rDoWW6ERjamzXChsuE2YBZMDGUysDyfVpG", + "RootIndex" : "000124613EE5581AFFBA4C729A0AD1046CEEB9FDFAE4E2C8C0147212F274301E", + "index" : "000124613EE5581AFFBA4C729A0AD1046CEEB9FDFAE4E2C8C0147212F274301E" + }, + { + "Flags" : 0, + "Indexes" : [ + "49998B8AD85C57D571102032E7099F83E84AB04E9AF7A02A6470CD848B76163F", + "17712DAC19B5275AEA623477BFD517D5379EB3AE130C1279F3E57B8D1DB9AEFD", + "BBDF9868E3FCE9CB50AD16719D0009B044F838551392A6EF4029EB390F926A55", + "1D8485B2F450F6CA0130C53963D3C6F18E256A3795FF7369B9A06A2845CFC96D", + "BE1B22BC694F1BA8AF1C7E841877598789B5028F11296424A5E521D762636101", + "9B6EF09CA83A6186F4B1F677ABA02FA4CF0F99E319FDCD05F2BB7EB4668845C3", + "5A8038F189C15616633456580940927D0B42EBAEF49E97D662DD7336F0006E72" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rad7pqyVBYjom3dNuXbd2WjEga7un9GVtE", + "RootIndex" : "00012954F2A4838FA5DF0A00BCE54A9CC5C878D6B8E00C7CE9C3A346E44C18DB", + "index" : "00012954F2A4838FA5DF0A00BCE54A9CC5C878D6B8E00C7CE9C3A346E44C18DB" + }, + { + "Account" : "rGP5bTpj6pmvcGKkNqSTM4d7fEVyque8A8", + "Balance" : "20023735", + "Flags" : 65536, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D4D6B2CBF319B7291C68F5372478F2DB2CE6060400FD6675501A1657119DCF60", + "PreviousTxnLgrSeq" : 48386321, + "RegularKey" : "rP2gfYFYZRWPzLMPpzjq8ZLZcEDvC4t1n2", + "Sequence" : 3, + "index" : "000145F2834A83C6C4F1756528876A331021C36112E8A20F66AAD646CE06D77F" + }, + { + "Account" : "r7KCRNjcweTn64ty5eTZ6CCDRKuSPYurW", + "Balance" : "30099277", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "81C454E3A8CAC7E2AB6344190AC238402400BCC249AF5F0F4F20512844CB308C", + "PreviousTxnLgrSeq" : 34678008, + "Sequence" : 29, + "index" : "0001505A9C2BBA5C19B812889DE86E8DB411D5E34F8B6DBE78F73376D502E327" + }, + { + "Account" : "rwBBnexNbxPNTCh5BkSRubhVzw3asfqG6C", + "Balance" : "20006468", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0E1D9A165492CCBA23DEB69A4FD2440A2046A81670C074B381A008FDA08AC9AA", + "PreviousTxnLgrSeq" : 48236415, + "Sequence" : 2, + "index" : "000152F477C08442092FF51513637262A5814ACCEEB873DD4542046A85765E8B" + }, + { + "Flags" : 0, + "Indexes" : [ + "BDF1810D0F8272249D560AAF47168D1BCF664E53D27F3041403A42876475F04F", + "606519AFA9D8F25AA0C7FBC2BF167FD5F472F4941A222F70B818EFC8F273A1F7" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rLNeS5rVcEVgVnqyve2SSoNyxg5SgJskhN", + "RootIndex" : "000156EDDD33FD522EEDAC95BBF8C422159A2BC5E9EEDFEF0562F6943663DA05", + "index" : "000156EDDD33FD522EEDAC95BBF8C422159A2BC5E9EEDFEF0562F6943663DA05" + }, + { + "Account" : "rU1AMsDK5Fsyx7WUmhoQTdv7ZDQWtuL71S", + "Balance" : "24977500", + "Flags" : 1179648, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "08C040451C492C4EC0B24FE24E50268755ABE82449F032E481EBF7CEADA0E8A2", + "PreviousTxnLgrSeq" : 51378627, + "Sequence" : 4, + "index" : "00015F6E0B22029ED7A6E470EAC946FF56A65ADDD74E952A8C485FD8E86DC7EF" + }, + { + "Flags" : 0, + "Indexes" : [ "F8351954832393F659DADCDBA60AD9C780E6A1BCB1D862AE63BAAB75DEA9FAE4" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rheq5biynaKpGcqhRcqvmo1FNGFX98DT3q", + "RootIndex" : "0001616E695CF6732D8D3809A22498056806383D29116615AF99ADCB029D3171", + "index" : "0001616E695CF6732D8D3809A22498056806383D29116615AF99ADCB029D3171" + }, + { + "Account" : "raSieUta8fy4SfACciECTdn2HGzEu8f48Y", + "Balance" : "52744206", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "602045615A571475995DA7667E093B8ECB5BE5419CDE9F0ABE8670ED94A3FA48", + "PreviousTxnLgrSeq" : 41757973, + "Sequence" : 1, + "index" : "000162578D0B7D7C9147874B49C69F64E8B229CD599066BC44D64972F7397B59" + }, + { + "Account" : "rZWjtggT2aT9539aEb9HPZR2aqonE8UpG", + "Balance" : "20022340", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5E7B6DBD193D13F1BC93F776E708EF6D324142144F941C46A83068F7AE05C555", + "PreviousTxnLgrSeq" : 35875147, + "Sequence" : 5, + "index" : "00016BF3FE48CAEA4BC3D5A78A4DAACDCE013655F021FBA5E9F01065CFEC6A9F" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "12.725676646811" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rPT74sUcTBTQhkHVD54WGncoqXEAMYbmH7", + "value" : "0" + }, + "HighNode" : "00000000000001C0", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rExzFtNkWrHrXF9zK2eABuvrhD2ayFoopV", + "value" : "100000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "642A3E7DF7E5471BC671F5862AFF1D935061BB2032BD0DC3BFE9C093B593E992", + "PreviousTxnLgrSeq" : 40968267, + "index" : "00016EC4440590FE9DF14F280580B77116341F97D0179B04D7D0B88EE25420A3" + }, + { + "Account" : "rEXwDtcsjf6zUairDrJ64beeppn2vZ9u5k", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A482F307A6F637187BDCD98AC1489301FF7F8E59B5016F6F3042E6C436BAA44B", + "PreviousTxnLgrSeq" : 47812511, + "Sequence" : 2, + "index" : "000171430B5EFB5018FBE245D1119CA61CFB8CD27446D51C9C2CB4C20739AC57" + }, + { + "Balance" : { + "currency" : "EUR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "EUR", + "issuer" : "rfz5wUTPtwEnZMvLYR526jWWqygSoHQB72", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "EUR", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "LowNode" : "00000000000004A3", + "PreviousTxnID" : "28783500A8878DD51E100108F0A831BAC3F02089EF1279553B00D1A75A0738B2", + "PreviousTxnLgrSeq" : 29830948, + "index" : "000171D2817C44C4AAFB093F675C44CF76CC77EBB10D67340F04D5C216CC60D9" + }, + { + "Account" : "rpSRdnAoTro6CPxqWtSgDouN11eFWPUEtz", + "Balance" : "10000000970", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "2BA264781737AD0B17B36DEF048D3EAFBAAC24E57973E2A494E68A0A520D214D", + "PreviousTxnLgrSeq" : 55178856, + "Sequence" : 1, + "index" : "0001727436B58F41EA68ED8BD969677AC1763ED7BDC03A9D2AA81959E34909C5" + }, + { + "Balance" : { + "currency" : "BCH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "BCH", + "issuer" : "rpVvMLVxo7t1mZM4zJedf9Rw2zwvTFZC9Y", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BCH", + "issuer" : "rcyS4CeCZVYvTiKcxj6Sx32ibKwcDHLds", + "value" : "0" + }, + "LowNode" : "00000000000001B3", + "PreviousTxnID" : "BFF8F2D22ED74DE95FEBCDF4F37A94DE5862AC3E00F312D31F13F19D490591B2", + "PreviousTxnLgrSeq" : 35359788, + "index" : "00017430A028B2826B5FF7A13158961E288793079F237A88D1B9447AD40A0F2A" + }, + { + "Account" : "rJBHfdXheicLvFdiTchUZQFegJ3F6wtbSe", + "Balance" : "4909014532", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "B0A908380DF1317C3E0D6E9BDBC23CBF8A3A6CA33291EF7641108BA991D2A66E", + "PreviousTxnLgrSeq" : 55176290, + "Sequence" : 1, + "index" : "0001796FFCC5DE52D25C719765ABC335AC9DC1D87A409CB50EECEB3FF90DA6F9" + }, + { + "Account" : "rw6L4pcny4qxHRzcr8rq7Ywhvtj1Zo4gbk", + "Balance" : "20263325", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A43A24DCAD70BE5633CBF25A60F24A40926A244FBFD2A68B56E88AD14224774E", + "PreviousTxnLgrSeq" : 49139053, + "Sequence" : 18, + "index" : "00017A965A6B6028B863D5F06C034CCF092067DC7D83CF0DFA7E57E016BB3A8C" + }, + { + "Account" : "rrQS26TiFbxSJMeDR3GVkssvUWqNagRA6", + "Balance" : "5184960776", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A5A573EE1F1BB78E74C47E8EFF9966D2C034B64B2F96E516829C151D6B0BA271", + "PreviousTxnLgrSeq" : 55179562, + "Sequence" : 1, + "index" : "00017DBFBA3F871DED46B33A9F904E8347D9E12137AACEF3641D26D09481A3F4" + }, + { + "Balance" : { + "currency" : "EUR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "EUR", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "00000000000003C7", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "EUR", + "issuer" : "rhkYFLnfJjuhhJMSt98LEjHRb5EPPWMMLM", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "62C87C48AB958E6C0EEB5AC537CBA577DDF47005470D8076338BD15A23408AF0", + "PreviousTxnLgrSeq" : 29684491, + "index" : "0001967BAA589E2BD8DB305A679A274C091F0995A63A0500A1C4AC13D650EE37" + }, + { + "Account" : "ra11vg3cu7y1ekAP77217jAZ2AUxijC4xg", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "F1EB5B4857B3E5B02DEC9AA13CC249DD28B036878EAD605B630A2990F81EBCF1", + "PreviousTxnLgrSeq" : 43025296, + "Sequence" : 3, + "index" : "00019BD625FF83D962FE366F0BF69D7FA50BAD8692BDC4BDDCE8517653B8477B" + }, + { + "Flags" : 65536, + "LedgerEntryType" : "SignerList", + "OwnerNode" : "0000000000000000", + "PreviousTxnID" : "44A3BEBFDE97AF4A547CA81B652817FDB7951388AFCC1E151AEDECB035739A7B", + "PreviousTxnLgrSeq" : 51394555, + "SignerEntries" : [ + { + "SignerEntry" : { + "Account" : "rXKRWAQdSk68NakbeY3b4HtDqSaRFjgCR", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rav2svUdPWzwET55egx7AuqREtkYSFScY7", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rGtDNiHFHNTNSnoeLg5usoRnLx33ABTWhT", + "SignerWeight" : 1 + } + } + ], + "SignerListID" : 0, + "SignerQuorum" : 2, + "index" : "00019CF2142F600C978EFB986613BE3CCB85CE599405FF757BC34AEE1BF9C982" + }, + { + "Flags" : 0, + "Indexes" : [ "A0DD66478D7E2C9C77B4D0C046A036C828B9A0257702FD7B403B9D0E815CBAB7" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rNYWvRRd7PDsa69C3bqNq7MH8jBK8jUR2", + "RootIndex" : "0001A3C2AF2B8210E978BE486AA397DB35DB9D0E6AFAEC8035E536F3DF00401E", + "index" : "0001A3C2AF2B8210E978BE486AA397DB35DB9D0E6AFAEC8035E536F3DF00401E" + }, + { + "Account" : "rPySuBy3dCnDpp4eeD3YvirnLtF19DafYm", + "Balance" : "21079607", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D66F918C0DB4009A75FD3BC3D49087DDCEAB3FD676D9003AEB7E2A1A84264D1B", + "PreviousTxnLgrSeq" : 35083095, + "Sequence" : 5, + "index" : "0001B3E919D8905EC2080FB6F593451028233D50E3A82CD16351BD394B4055F4" + }, + { + "Account" : "rabbit1eyDGsiWzRH4wL4vnk7giSxWyMeb", + "Balance" : "100041360", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 4, + "PreviousTxnID" : "DD2BD18EE4400459E3BC6560E0D3786831EFEA3860B07FFB8AE445532F589927", + "PreviousTxnLgrSeq" : 41202517, + "Sequence" : 802375, + "index" : "0001B7264DF8F7730C3E1530A24A17FA99F062DC0A6E66615F3EA4EC3CED46D9" + }, + { + "Account" : "rf7nSY8GXRiiTukpnunSQi4otiH5ZoiEvy", + "Balance" : "33000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "CB7F74D3CB40602C52302AE42363885E5EFC7536827B14B3BEC3055D4573F356", + "PreviousTxnLgrSeq" : 40507156, + "Sequence" : 1, + "index" : "0001B75BF0B7EDEDD51057F7109144C8FACE381BA0C968596E85E7CA53C1AC9B" + }, + { + "Flags" : 0, + "IndexNext" : "000000000000010F", + "IndexPrevious" : "000000000000010D", + "Indexes" : [ + "47EF55938C4C0E228672D6199A2B4BE6E6E2BB863341128BF74193CE5DEB5912", + "ADDC5C415149EDE4D6F47C2AB0B9033E60156737136EFD850A409060824E4E02", + "54264648AEC6EB3D25695872798E669E745B05AC765E45E9B5F88053EE41231B", + "9370A905CA293F0774F454D64315CE52A63B9BDB2A50915EDF643C90CA6444F7", + "1323A324D39A5DBADBE2F7959C9F8505ED5F43D0C3C25E4892AB0B3632D76ED5", + "A33C29C307BDAC45F4F1277E60E82B5C26125401C20AB5CDB352DDDE38AAA863", + "6D712C8B5BDBE99D1C93C25FFF9707D6726C317059662BED12584A706D8AEB41", + "7CE75E387DF97ADE98718131EE2B19B034B6233D22CB67817440923BA0DC9071", + "213CB583C0A91E794D5587320801B5F763D9FDDF4DC6AC8A0DC1D0CA6834A4E7", + "5DCCA52BA4873F8CDDE86A08C415E8C29B4E0AB43ABE1F2B80AF667C1A831CE2", + "676C3AB3D4953B3D995698B47F8C8BAC715D7236C1513C03D36A90F0AF2CAFBA", + "FA7B6DBDE818BAA7BAA3FB43266C7DDEF0D6B1035A89E240185CB382FBB9CF1E", + "162801B3679E3623F5A1E1281D875806FDBF4194C2BE2F3A89E91700FF9A0E9B", + "C5E6524750B19B938F6A046E95AC6F57DF9C59C0D29B460DA6787840BAF8105D", + "964B15F052285525F66594C3080EB83FEE4C448F98990B77A12654EA2638A323", + "2F81C7C101E15DF959E43530B17C6DAEC1BD012BC7CFCC4AFF9AA905724F7D0C", + "C5A1E3C85B510E0A3FFFE6610355D02A063E160A7A99BA6A7CDAEFD34C45BE9F", + "F6C003A46C2905EB16A822436D0A0A6A726F7FFFD80ECFF1EEE0228FC3A2BCC8", + "AA4C93539FAC96D37E121130F1D9225C3758AB814D2A5B4042B29E1F559EA4BB", + "7EC3784C4CA5BDCB5C798E39B9F655860D5DF0013B39580C94B5D0BEF0A75C7D", + "F8FED9BE60375A25CEEADE3CAF51522CB5174367C16E8099BB20DD02CA2244AD", + "8711B16A37882C221E750F429053FBA94D74E3C2615870FFA0ACDA12694E6149", + "1720BEB74777C45007F46332933B909E629677CE4D00EB5AC71B36A7D04E8962", + "092E2D46FC1067FAA3A893715EC531E1E75D06BE14DFB66DFB1698EF6D5FC02F", + "DEA88D84936A98A7BA6A16331BCBA2D5A3EAF996AF9DB25141900A071B76B177" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rckzVpTnKpP4TJ1puQe827bV3X4oYtdTP", + "RootIndex" : "DC5101C0CC6A7FC8E21465501E0EAEEF475BE2D1FF2E7BF6691360DACA4F9C48", + "index" : "0001B882C3BDDF2524DA892639A16FAF4985CF19DDEC17EAAC38F6A98F1D3275" + }, + { + "Account" : "rEWmZFmKAPWjUoD9pPk9Y7Ut8eEpSZmnq1", + "Balance" : "126488970", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "1BADA79B7090A31C6EC6A70993FFEF9242B249B9CB42C9251F5FEA5906B8612A", + "PreviousTxnLgrSeq" : 35569892, + "Sequence" : 1, + "index" : "0001C56562C6B32EF503B9B44F65BFA0E4E990A42C8F19CBC8868071D74B4492" + }, + { + "Account" : "r4rL7NEbRwzNdKZApRcDP4rUV8JKrqN9tW", + "Balance" : "20781895", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "7BB899214EB0FFDD5A677D4F391EBA46D6287CBB33052AF0C1F1BBCAF92D541D", + "PreviousTxnLgrSeq" : 35347840, + "Sequence" : 3, + "index" : "0001C817A1A9EA16F3A307CECD2D274B0C402C4C96997E32C6AA047E4D3A9CCB" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rNcvK17hLGoHQuPbZf1R8mAh3M31GMtgnR", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "LowNode" : "000000000000123F", + "PreviousTxnID" : "72D56D94CC6CC2694E1E5EB9DA536F43E8A3FB3C1C0ED081527001D18D8D7A3C", + "PreviousTxnLgrSeq" : 35435065, + "index" : "0001D78EB50C60CB9708E8202C9897688363B78F8AB7AC63F66EEDA462EF453A" + }, + { + "Account" : "rfHzTZqckursDsc3BaVv84f9FfK81UPMVc", + "Balance" : "78999988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "61F7D324154F46A8846A1AE920858AC5893B81CC19C238EA038EC4A79E404B41", + "PreviousTxnLgrSeq" : 54682342, + "Sequence" : 2, + "index" : "0001DAC577DD41000B500FFFCA784A88C04B00788AA210EF5AB6AB54E59DDD49" + }, + { + "Account" : "rwao7UjmZbBed84yhGP39W2PLH66Q7aXjb", + "Balance" : "2481472609", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5060666111A067C2D877D5F4982F0050903AEE439E2FB082DBBCBD8ABCA0CDEF", + "PreviousTxnLgrSeq" : 53449904, + "Sequence" : 1, + "index" : "0001DD4EC36B9A34D8899ED31E4E388587154016B49FFD82128C68AE919B2BE7" + }, + { + "Balance" : { + "currency" : "DSH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "DSH", + "issuer" : "rwrudJs8u5KatPEuGuyDnQ8R5nEQUPB7v2", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "DSH", + "issuer" : "rcXY84C4g14iFp6taFXjjQGVeHqSCh9RX", + "value" : "0" + }, + "LowNode" : "000000000000016A", + "PreviousTxnID" : "3FF02890077B48632D1A19744DE05E182E68C9A1A4B0B31F6E41159F512BD41B", + "PreviousTxnLgrSeq" : 35699762, + "index" : "0001DF3CB8196255E69A14F92EBAB9877B1F350DF7E62D64AB6587EC3ED9CA4D" + }, + { + "Flags" : 0, + "Indexes" : [ + "278D58129796548AF58E23A40247F050CB3E46BAF058A44D96CBCF1F41A65357", + "448843AF12951D5119AF6A31F67C19AAF30F9CA4A87E1913F1CE77E8A489A608", + "4533FC4C079D626A72899A2DDF532829F8838D376C2840B642CF1C53403E8427", + "7F38E0C8E0214AEF922B617C19156009EF3292A40C6FF52C9CB03625AC09058E", + "8BD45AFCAFCE035932E6A176836A3E088F90B0854CCA37CAE8760DCB68A40E2A", + "A1505359F82BE39B0A23190A6F55AFD4ADCA4990337605C74BC2622399799186", + "B1A644AFAEACE38D9A31E212059BBDAE52184CD63938AA03A2C324201EB0B1BD", + "B49AC5079F5E2455F141E62F72AB80F7FF9D2E6C98EF894936C01C4E491E49E3", + "B8A780F02B1B50D9A5A43A08B000F23340F8D48966642FB1BAA2E17E28B83E58" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rEAKkNt5z2HTkqS9baCGaTStHXfptPtCuF", + "RootIndex" : "0001E959978564B75810992944B463A63B305AA6690410FA4ED790CA7AFCE45D", + "index" : "0001E959978564B75810992944B463A63B305AA6690410FA4ED790CA7AFCE45D" + }, + { + "Balance" : { + "currency" : "GCB", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "100000" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "GCB", + "issuer" : "rNdwi8ain5ibXNB9A7H3zzKtSxgVzAqqAe", + "value" : "0" + }, + "HighNode" : "00000000000001B0", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "GCB", + "issuer" : "rNNeAHyaSgDxG8ynpnxuzaVtqp49sctxb9", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "6C6ADA3ADF20D37577BEA94CBA1871B1A030B6D63E3F594D5A9959275E97A999", + "PreviousTxnLgrSeq" : 37721815, + "index" : "0001E9604C5FC991A30408A78A299A58AD7DBF5A9069445A3A75D487D04DD607" + }, + { + "Account" : "rKbUdv2SnNbgK7t69drPNKmAAeQfs5fNVZ", + "Balance" : "464278000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "B0DFF30B2BE30663A9BE7A8CA42FD85CF423B041CDA489FA7A18D714260D5C08", + "PreviousTxnLgrSeq" : 35570527, + "Sequence" : 1, + "index" : "0001FD3112599AF2C9991E5E7E56A24268F9DC3438D525C8DA8135E9BBFB7D6A" + }, + { + "Account" : "rMJuG542Akwt2idVxQemfPWSKtTeSyR4QL", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5C79FD3CA953C881C3D4BE48F2EFAC671177B8ACD37A72A38958A293B706B4C6", + "PreviousTxnLgrSeq" : 35696409, + "Sequence" : 3, + "index" : "000201714F588C6F1D440EA526ED868FC48FE4F3508840D58A36D79251D7D8D9" + }, + { + "Flags" : 0, + "Indexes" : [ "9D41377F1EB6E502A7107C2A35CE571506BA8DDC5E57F77AED0C4FD7C5BB6D2B" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rGUhYCjTac2tuuUPwAJ38iajg44s4H9b3E", + "RootIndex" : "0002043F91DC997AD832ADB3A90B2B2D762E575AFEBDE372FEE323617EB89255", + "index" : "0002043F91DC997AD832ADB3A90B2B2D762E575AFEBDE372FEE323617EB89255" + }, + { + "Flags" : 0, + "Indexes" : [ + "63309BC276156760C5BBB0E5F1238546824A861CE478C536DD8B36D6009502C6", + "34E8966296BF24299BC9D7DC14FEFE60DB5C23C3AC8325B883D6AAE5B4FFDA92", + "2333718F8324FAE85841B54F86B7486841335A69C4956207905CDF9A65C37D38" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "r49HKrCPQUvs4en9DEUBewA3DASoVNUE4B", + "RootIndex" : "000204CA2372F5DBB072D5CB38156EF7E67D3A584AA5B02657976DEC6D0C5B88", + "index" : "000204CA2372F5DBB072D5CB38156EF7E67D3A584AA5B02657976DEC6D0C5B88" + }, + { + "Balance" : { + "currency" : "STR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "STR", + "issuer" : "rUwyk5PmESWq1DCMTCTscsRb4kYVYrZw4f", + "value" : "10000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "STR", + "issuer" : "rB3gZey7VWHYRqJHLoHDEJXJ2pEPNieKiS", + "value" : "0" + }, + "LowNode" : "00000000000002F4", + "PreviousTxnID" : "9CE00B05DE793F99081996E2A322ACE374EBD6C7E6F1343AED0BADBD20DAED69", + "PreviousTxnLgrSeq" : 29743678, + "index" : "0002068C83B72D014453DC1415A6D30A430CA904FA78BAB33A36900F8AF645C9" + }, + { + "Account" : "rBuDDpdVBt57JbyfXbs8gjWvp4ScKssHzx", + "BookDirectory" : "37AAC93D336021AE94310D0430FFA090F7137C97D473488C4A0D635441A85A45", + "BookNode" : "0000000000000000", + "Flags" : 0, + "LedgerEntryType" : "Offer", + "OwnerNode" : "000000000000025E", + "PreviousTxnID" : "17DE3914111D63CBA7BB51B551BD4C14F9BED048B8EA142222B2C4B1CEBDA01A", + "PreviousTxnLgrSeq" : 52563046, + "Sequence" : 121220, + "TakerGets" : "33170680", + "TakerPays" : { + "currency" : "BTC", + "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B", + "value" : "0.00125" + }, + "index" : "0002133B26A1D5533CD791251844CE17650F2F478EE37F8564D024BA2E0A224C" + }, + { + "Account" : "rL45jjo6Ym2isLu5kPQrL8BctBjX2Ur4tq", + "Balance" : "30000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "243950CFC1A4FEDCA0A62041EE6FFD4EB116E20FC20DBE816624C24609085A75", + "PreviousTxnLgrSeq" : 38977070, + "Sequence" : 26, + "index" : "000215DE95AD3CE49624ABF5019E13A3D5691B5D21E3A13EDD44A8DFED3C9A85" + }, + { + "Account" : "rE8yruJtXACpDWyVyGSP1MLrGBzcnnfUhw", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "17E2EF85A7CAD6EE02610CDB51ADB284AB64B8C88D3B0759ABADE870597EF081", + "PreviousTxnLgrSeq" : 47828640, + "Sequence" : 2, + "index" : "000217A389C05CE05D96FA5A368621F21E0431C21748800240487F1C51321CB7" + }, + { + "Account" : "rnoHcWx5sskoiiNMt6CSSeTfjHw7JL3RfJ", + "Balance" : "122834669", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "2A4B34391F53C0DB49C0C2ABF39611C9EE797B2A71C128453A0A85AE629FB481", + "PreviousTxnLgrSeq" : 35665140, + "Sequence" : 1, + "index" : "000218E0DB87BA2E65CB5F59CCFBAA15DAC6A2D07EDECC72DB0457C50B0F3156" + }, + { + "Account" : "rGuvvY7BPCRYmw83EmzYFQZ76ybdZ28DKX", + "Balance" : "2242284331", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "F1603850E52D962CDA5A33646A13FDC44990436BC1967C1B45B5556E0CB94EE0", + "PreviousTxnLgrSeq" : 53527645, + "Sequence" : 7, + "index" : "00021CD2D04E777624DC7D15AD7EDC7400375029FC11B1EEAAB187FDA0A86E07" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1179648, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rPFd14EgMkmEnvtk2nzsrTfkoDmYzwpowJ", + "value" : "2000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rBfVgTnsdh8ckC19RM8aVGNuMZnpwrMP6n", + "value" : "0" + }, + "LowNode" : "00000000000002F9", + "PreviousTxnID" : "4352226FA79635CBA7D59E9705B1A751834EC5EC4025281DE7A6DFDC3B8CCB73", + "PreviousTxnLgrSeq" : 24725683, + "index" : "00021D4E6E9CE88B3DFCBC8917CDF28C7BC2792AD68FA6A269DB454CA8C0160A" + }, + { + "Account" : "rBFLqCBHFZCKrZVRZK1oyH5SibamM8uM49", + "Balance" : "87782000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EE6E0422AC888EE1C298D17EF069D6D0F937181D861BFA67D8CECB18E6A05CF6", + "PreviousTxnLgrSeq" : 35105975, + "Sequence" : 3, + "index" : "00021FDEE2F788C23C3E11EBCE3657FCF560A61C365A6EFA45726C54A570579D" + }, + { + "Flags" : 0, + "Indexes" : [ "6AB1BA256C26B11B0C2BC28B68CFFF9EBA1A0D7505F43F1D9D4D64A38F38A8F9" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rUAuRre3GfGDTxdbzo7s7GArR2zhPf61Rd", + "RootIndex" : "0002228CECB01B2B948DCF2EEE43DBF33637F27F0C6BFDAF238EF2F9E022F4E3", + "index" : "0002228CECB01B2B948DCF2EEE43DBF33637F27F0C6BFDAF238EF2F9E022F4E3" + }, + { + "Account" : "rGFEpTL3rXgsHkopDNbEB3NMfNDspZ23e3", + "Balance" : "1756380116", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "755AD6C3F0F8075B48409692AA2A336CF5B07DFE9B5B7517DBBD5D6AE79389FD", + "PreviousTxnLgrSeq" : 53543734, + "Sequence" : 1, + "index" : "00022463A30DA0BB03215AC3777746D7DF2794D13A056C08C7947C1D0298A8E2" + }, + { + "ExchangeRate" : "54038D7EA4C68000", + "Flags" : 0, + "Indexes" : [ "291430753F816826020D5F119325B30E68C9B69A204E97758A84A9E2BDC0AA4C" ], + "LedgerEntryType" : "DirectoryNode", + "RootIndex" : "000227CD42FA0FF90ED3DF1940FE988950EC26250C6CA27554038D7EA4C68000", + "TakerGetsCurrency" : "000000000000000000000000594B540000000000", + "TakerGetsIssuer" : "9DE47FDE20653B82F1A116B3A82658362CC482FB", + "TakerPaysCurrency" : "0000000000000000000000004D4C4B0000000000", + "TakerPaysIssuer" : "9DE47FDE20653B82F1A116B3A82658362CC482FB", + "index" : "000227CD42FA0FF90ED3DF1940FE988950EC26250C6CA27554038D7EA4C68000" + }, + { + "Account" : "rpd9hZKqeXJr7rNjvehBunEdQwLZRY61D5", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D4A0C37289C478B5B9BA2AC8F93701F5ED52FDEA6429750E9019D622F1B8C9E0", + "PreviousTxnLgrSeq" : 35222051, + "Sequence" : 1, + "index" : "000234B4BD11D93E4810C37F13C6A009498192E957D35FDE55E809E6FA40361F" + }, + { + "Balance" : { + "currency" : "ETH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.00000000069586" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "ETH", + "issuer" : "rs7WjWW76Dtq9bkHq98ZfvQzaANiVSW9s2", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ETH", + "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "value" : "0" + }, + "LowNode" : "0000000000000B36", + "PreviousTxnID" : "F2ED70C5BEB1B964C344614DEBB2854033B695DEDC444793D3870746FFC4164D", + "PreviousTxnLgrSeq" : 35823767, + "index" : "00023646D06EF5D6BA4FDF1F5D8F23FE28D486B54F227C97702AA7A83CBCD8F3" + }, + { + "Account" : "rPLXMQ6KhniRFGLxXLg4YbeHmRXSP9ncBv", + "Balance" : "2600007809796", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "AEA85201CE0D0D9062DB691AA3E05530C6B64FEC0F42D0D645622ADB9BDA558D", + "PreviousTxnLgrSeq" : 55163667, + "Sequence" : 15, + "index" : "000242578431923F7E961D6D69146C0D80B936E60E094450CB7497759BC1F0B6" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rMSY8DZpWH9sCvqq1Mg5wKGjqqicXtTNyc", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", + "value" : "0" + }, + "LowNode" : "00000000000007CF", + "PreviousTxnID" : "E2AB5AEE53AC746F1FDA16AE068E0C39752114E6676DF16E7C2B4A97AE2C9091", + "PreviousTxnLgrSeq" : 34906009, + "index" : "00024ECF15C95740AF5FA04C3DD341E8F05B7A069224407F9AF9C59FAEF723E3" + }, + { + "Balance" : { + "currency" : "JPY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "JPY", + "issuer" : "rB3gZey7VWHYRqJHLoHDEJXJ2pEPNieKiS", + "value" : "0" + }, + "HighNode" : "0000000000000367", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "JPY", + "issuer" : "rf8RiHHJvDosckVtsmZ3SGxYcuduUJ7gus", + "value" : "10000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "4236B9703C0FA5C1DE1FF8A0316E915477F4ED1300A39C96F5C1D383C5CDCED3", + "PreviousTxnLgrSeq" : 30038128, + "index" : "00024F52A82AAD1D2B49549BC2C737BE101F662E4F55F01868F56CE6076C0228" + }, + { + "Account" : "rpSHB1VsKFKBx4VjmHH8V4SVdbPYdowAkE", + "Balance" : "1136037689", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "08C5DADC959F085A22ABBE4CCB5CD8BC361C4854578F1CD9446502A433E563FA", + "PreviousTxnLgrSeq" : 55609692, + "Sequence" : 55609692, + "index" : "00025455DA641B87A2EBE0C1F02F4E17A07CF1D97B708A20DEE7C4EEC25EBBE3" + }, + { + "Account" : "rpaD3HhpVPSUj4k9xerLN3nj7CkZ6AwYv3", + "Balance" : "1685711002969", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "416A1EAFA3EFEF7F27FF4E5E374CA4D4786ACB507522137E5E560289D740F6A6", + "PreviousTxnLgrSeq" : 55164077, + "Sequence" : 1, + "index" : "00025908A8FD8967A049FACB5181AE8F14C1840215B6BDE5063342136597BFA0" + }, + { + "Account" : "rUw4QkuMot2GSTfGmu8uAt989f4KsAjcmK", + "Balance" : "1384845450", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "FD68277F820799FC5A8E58A5EECD4D5AD6BCB42688286E3D4AE6D136EE9C2272", + "PreviousTxnLgrSeq" : 53528319, + "Sequence" : 1, + "index" : "00025CFEF306B3FA99C5000F530F3D967F07B3414C313725F7D9E2DC6FB30412" + }, + { + "Account" : "rB4ZqDWBW1SjzbBenKSnsqC7YuPsMCJ1mB", + "Balance" : "113107120977", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 32, + "PreviousTxnID" : "F620D678A5578D144292CE94F3B841EB24DBAFFC68D19735272E102E775CC71F", + "PreviousTxnLgrSeq" : 56852695, + "Sequence" : 1623, + "index" : "00026278BB9B84D65F8872C506EBDD4BE182FD31B9930E5D6C327B554006C7CA" + }, + { + "Account" : "rB7FbVaugiT9x2tNdUTpMPLB6uEbrzzHDg", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "3473F370144C61BDAFC6340A7AEB41D23274D12542B2CFC82B77E3ABD0E549D9", + "PreviousTxnLgrSeq" : 56066464, + "Sequence" : 24, + "index" : "000263EEFD18A648F716C7201F7E8D9FD53E8157EED200F6B8AADADCA7644B48" + }, + { + "Account" : "rJnpxaXdu8WbeYwj1z4s6sYz7uGq5GC1NF", + "Balance" : "3281565997", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "449E8D4ED990941940FAB231FC916487A81E61491D55A1EC7AFF83D29398CF4D", + "PreviousTxnLgrSeq" : 55175689, + "Sequence" : 1, + "index" : "000264109B71F26AC0C274FD4D2BBDFCC6AA5E4817066C9264FEB606F9746EF8" + }, + { + "Account" : "rJkCKqwncDrbDNxgf3QFB6UWUCe5tD2vzs", + "Balance" : "47451988", + "Flags" : 65536, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "09B698D2A9369B708325CAC986B4F13BAFC6AEBCED89455A100FCB98E66D87CC", + "PreviousTxnLgrSeq" : 44981172, + "RegularKey" : "rncMr3zTqsfGuwiC4goKM6Br7YGmuUy358", + "Sequence" : 2, + "index" : "000267A0E4D9EB87145C89BC8352EA105BBFAD618F6AEF637A947E53129E6E83" + }, + { + "Balance" : { + "currency" : "JPY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "JPY", + "issuer" : "r4iPSVbRZosUDeuQg7obweH8DgCYvg947o", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "JPY", + "issuer" : "rEYD5k6kZPARQbKfB9GpiNPDY93kRQgPKj", + "value" : "0" + }, + "LowNode" : "0000000000000008", + "PreviousTxnID" : "7516F9BC3E8055CCE7F727A29F1FD48E9F9925BB91B62129D1D00B8502DDB4DB", + "PreviousTxnLgrSeq" : 11378470, + "index" : "00026AE25E921ACDE0861F983DAAD7852553F53454C69A6113DC8F6A994F19F6" + }, + { + "Account" : "raHV45pVDiRUdeGBJNhFSH5heTuebjtzoY", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EF368FA8D09BC9D278CA7A55F5E2BCCA674C00F7DCDA35CB0565618BB9ED3E6E", + "PreviousTxnLgrSeq" : 48264559, + "Sequence" : 2, + "index" : "00026D54B2F877AD05FB5639DBE2041007B4D6D8613B5301AAB291CED182494A" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.0097" + }, + "Flags" : 3276800, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rDvmLrFhAHRxaVmmeppZKzjfzM9RZ7W7m7", + "value" : "1000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rhKgFxe7Mp38yeJzvwoNLm46RxMdXotTn6", + "value" : "0" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "3E8D2DADF8C4FBA09D117F772F144D982F46D8FC6F050FDDA93DD0066F5ADB09", + "PreviousTxnLgrSeq" : 35240943, + "index" : "00026E9C64E0BEF3F562EFE4D13B62BA3284FD7FB09395A936591C0F23D607DA" + }, + { + "Account" : "rs7Ne13j2FCJtMS5UZmsYfHV9KBSTyan7w", + "Balance" : "20023065", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "3F9D327F292D8244735721EE8F9CCB5565306270DF8BF4F642BAFA0C06F12742", + "PreviousTxnLgrSeq" : 36968533, + "Sequence" : 11, + "index" : "0002701E7145F0FCADF2EBC24DFE242C5BB868A5CDCC50A7EDB21F7433E1C3C5" + }, + { + "Account" : "rHETEQaUhP6KBLDbQ7jdvytEfLDN5XzviD", + "Balance" : "44992103", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 4, + "PreviousTxnID" : "EE896EC16D9017697EDADC0E676F63D4E5855C682BE94A5C2E5A535DB96A2180", + "PreviousTxnLgrSeq" : 37313330, + "Sequence" : 33, + "index" : "00027632FBDE4927164EF1AAE745EDFFDD3B820809464BADEFC18E08FEF42055" + }, + { + "Account" : "rKk3VeQP8oUq1Y6J8WxARUFATRoFZn6gz1", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "35F4770B3559A62731ED680C0D8B53C8A58F8994D123AEF43DBE3D66075F22F6", + "PreviousTxnLgrSeq" : 28960817, + "Sequence" : 2, + "index" : "00027ED9E4526B75B2CE0CF80E41EE0011C39589401E717AA700CC692E21D543" + }, + { + "Account" : "rGyMFQRn5HtdC2eFoK4n98uc4QeMddiZoF", + "Balance" : "238529992773", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "FA7FE32E7D86A19D88F79F926AA5A44AEFFCC55C26B07D7BA631D9D9B7B56BE3", + "PreviousTxnLgrSeq" : 55174593, + "Sequence" : 2, + "index" : "000280047BACA5D00427677365D9559F3FAF9027E4FFE69452DD0DD577B44942" + }, + { + "Account" : "rnmYfkS85KmV9p4Le7cJC6JjJcysL8Y5bw", + "Balance" : "25020000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0F5503095AC7D78B6AD2E8B7C4A0A946C4DA0273C433E8AE8F3FD4D55F68DAC1", + "PreviousTxnLgrSeq" : 56406521, + "Sequence" : 7, + "index" : "000285A460C476F5AD35C6D837EAD4F2CC09D7E8A43F07D77AD8B72204372903" + }, + { + "Account" : "rfRnmsbfku4S2nCrPXKFtKsNVE2feYW9Kv", + "Balance" : "739809000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "8F9C0CBD3E6DCC535B67760BE2C4AB4E96CA855DA763A352E2A5882D5AFB7FC4", + "PreviousTxnLgrSeq" : 35491168, + "Sequence" : 1, + "index" : "0002886C2182362FA2ADBF0794354385F120D4F90316D408DDA1BE254C08F340" + }, + { + "ExchangeRate" : "55038D7EA4C68000", + "Flags" : 0, + "Indexes" : [ "14472F3D7E46A79BC424FE22782DA8152B3346F240D76B03F17C06C21C56005F" ], + "LedgerEntryType" : "DirectoryNode", + "RootIndex" : "00028C6812AF7B7043E8D146563C740614D1293A952026F555038D7EA4C68000", + "TakerGetsCurrency" : "0000000000000000000000005553440000000000", + "TakerGetsIssuer" : "A2F38D1722E33796F5880141A8F6318BC91F27C2", + "TakerPaysCurrency" : "0000000000000000000000005553440000000000", + "TakerPaysIssuer" : "0B233D3B2EBDC4F12A251C29AF26323EA0864CE9", + "index" : "00028C6812AF7B7043E8D146563C740614D1293A952026F555038D7EA4C68000" + }, + { + "Flags" : 0, + "Indexes" : [ + "1A319AE7B7FBA78BE7D021AC01C781A842BAAD4BF558A7F709C86A05F1607F8A", + "5FD00AB6D78C5F742B00E02A8B3A5D47A9642D0FF3143438BA4B9F7FB93898A7", + "915A2E1823AF08F32A7803BF7B7AF43D2C3EB77CA05F56951304C6D7E974A7FE" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rBcwbD6PTsoveJLT2RLwiKwNBvubWEqB23", + "RootIndex" : "00028D42EF0C344205C82444A6F67E9875E6CFAB5B9210B6D70ED6AEB16E6CE8", + "index" : "00028D42EF0C344205C82444A6F67E9875E6CFAB5B9210B6D70ED6AEB16E6CE8" + }, + { + "Account" : "rMCuL9Sce7QiJHosT3kkGaF6ySntfVp2Gj", + "Balance" : "19999990", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "02AF004961D61E2CD1F0BF84C5F31D47EC13086FFE5D51EE8C59842DC1C325A3", + "PreviousTxnLgrSeq" : 35880386, + "Sequence" : 5, + "index" : "00028F39C354A66DD4994A4CD7AB8A91E32452E5039898CCC134FFA61DD0025E" + }, + { + "Flags" : 0, + "Indexes" : [ + "0BA71FA44920D017FC27956BCADE84B103CA8BA11B835BB6ED911A3FABA549A4", + "80461BDED64B13994E9318F3143BF436C256E81A9B574FE0D511602CA3466E33" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rMqgMdQm1hDh7ZUAWz4AzASi1vg2GMRY4G", + "RootIndex" : "0002999EEC715951639874C60F2D4F6B28E29CF6432008EF86DEB988CA8AADF6", + "index" : "0002999EEC715951639874C60F2D4F6B28E29CF6432008EF86DEB988CA8AADF6" + }, + { + "Account" : "rPDu1wk2vmLHdCrztVrn4yNMTNeme75Mmk", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "CBDB3EE7253A4E47CAE1BA3FDBA062C364ED4E7FF9686F558E2598E9B19589F6", + "PreviousTxnLgrSeq" : 47865012, + "Sequence" : 2, + "index" : "00029D9DDBE35894846ADEF13949EE95AD3FBD4B749BB800B6508A82160706D2" + }, + { + "Account" : "rNFYBtTaywSA2PmjpZSXJ6by1Bh5MjAnj6", + "Balance" : "1258667366", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D5944A2C279AAF2749D4F7658ACEBAD24252393B1BD108D51A4572943D88B17E", + "PreviousTxnLgrSeq" : 53527042, + "Sequence" : 1, + "index" : "0002A3F34A62A3FCED5E3DE2AF5012A2B33AB8EC411028E4310947A4BADC6F9E" + }, + { + "Account" : "rU51UCvkbJDsjXsE9PmB59TCm5ZjSW6ZPy", + "Balance" : "10000000811", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "1C916B192126CB9D8524DBF7DD77325EFACE96BF282BF0877F0C22D4BB9BF4D9", + "PreviousTxnLgrSeq" : 55180029, + "Sequence" : 1, + "index" : "0002A590029B53BE7857EFF9985F770EC792CE483720EB5E963C4D6A607D43E0" + }, + { + "Account" : "rHW2anzZMwGF6jB3Qe2KJHVvdNp83u8zUB", + "Balance" : "19988000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D83E336EBA2F2768A8FCC7A7C9F93CD3145861C5FC89828122006DAFB0DDED38", + "PreviousTxnLgrSeq" : 18595284, + "Sequence" : 2, + "index" : "0002A98F9BA1CB7F71BBD170DE366EB64B818B05CE714C611DCB1B501C5834B9" + }, + { + "Account" : "raGNVgTN4vmi8FyNh75ydzJAbeuXjytDA2", + "Balance" : "476318366", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "FE70E402404608A3E77B23AC61A8652C448EF08AE2DD110C0FCEA8E7BAB8D1A6", + "PreviousTxnLgrSeq" : 35179921, + "Sequence" : 1, + "index" : "0002AD9E073BE86B8D78BE3D6B417F41CB37C5782D05E6859BB57E709543E283" + }, + { + "Account" : "r9scREW2BqzWc5EHDPURFXmc2nbE3zk27o", + "Balance" : "25981483", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "031F8EB959C780E160DE06921338275E85B3F6CF963DB9BDF6C0C30279CAECF4", + "PreviousTxnLgrSeq" : 45548830, + "Sequence" : 9, + "index" : "0002AE9D14EAF79B4C4928D622CEAF7C192B79682C091E373466E7B4948C3F82" + }, + { + "Account" : "rHgmYFSPe4PmHAAxLmXT8gHTHdAkyC8qux", + "Balance" : "37353357", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "4F91EB7706212FF41734E3DBB3AAD1107DFFDB1C168EF2C588D5762FCB28B6E4", + "PreviousTxnLgrSeq" : 36055617, + "Sequence" : 5, + "index" : "0002B0BB1E2050F8E9A46A9E8EA28D9602B1439219ABA1932ED251CDA00DCB4A" + }, + { + "Account" : "rEMZkiyzyK4ujMEqkcA6RQz8kjjt2Lo85s", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "87F590598CCC90C920C76AB3799867BE73551358852B955A54383EB899BF81E6", + "PreviousTxnLgrSeq" : 56862164, + "Sequence" : 56822595, + "index" : "0002B53E6EFB0DA9EAA4AED495AD95238848042571240D89255AECBD5FBA4451" + }, + { + "Account" : "rJ9ocS5wWL93D4nPDPypAmvpvDJaDmNKzy", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EB19B4DFBAE06FBB920BEADCCDCAE0DE655249A14698D9985F97D5AC2AD52C89", + "PreviousTxnLgrSeq" : 48079546, + "Sequence" : 3, + "index" : "0002BDBDBD34EFAF974F5439F222439CE9F23F80446E9B252C4424543CB42F67" + }, + { + "Account" : "rseH6yDsetznMcuUg4uVhTjQPJc9BE4bpQ", + "Balance" : "20042739", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "59F89927C1B8F3BB5880902EAC796CBE2FFF44C3CDC8E3CDD66A5E9F962966A3", + "PreviousTxnLgrSeq" : 56775842, + "Sequence" : 55769928, + "index" : "0002C6425429A29A0BA566F93145BFBEABFCDE6A7E2AA81E2D0823D8F6E12303" + }, + { + "Account" : "rwkEbDdopDS13yADjPNmAnsB4yJvdZyB6s", + "Balance" : "340570301", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "8401A5E0142CBE0F3EE3DFFD92C86065FF00EAF189AC7F0466384B64AA45BA2A", + "PreviousTxnLgrSeq" : 35533603, + "Sequence" : 7, + "index" : "0002CA03B25A44145348CDEE8FA9677C40AB515E9ADB9310562F742B0471453A" + }, + { + "Flags" : 0, + "Indexes" : [ + "3C7ECA3343757CF715F41334F4DB668B3FDCC40F4BC4254FBE0400555DCE72D4", + "537FB843F8AB0749B4D27028B76D2E80D02B5479102EC43F92486C5D7AE75907", + "6BFED756A60D16582D4132B29E07B087FBFCC2210295CAA6AA11238BC13EA785", + "F65B5293422BD30522CED800B6D14D9A79DE5698412134FCD5CB276512A1ADDE" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "r8RwFcEDnhCJATxjEjVAjQ1QszVsHD2Hn", + "RootIndex" : "0002CD31E83DF6281A9A8D7481D5FCFCA5003E57CDA551FF0B99ED6E34E71840", + "index" : "0002CD31E83DF6281A9A8D7481D5FCFCA5003E57CDA551FF0B99ED6E34E71840" + }, + { + "Balance" : { + "currency" : "EUR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "EUR", + "issuer" : "rJ6m73X94YvJxXJRMU2WXQx5s1G3woTAx7", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "EUR", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "LowNode" : "0000000000001B92", + "PreviousTxnID" : "00CFA69736975A56B4EA193D9207304E077C53F3EFA6C3AA024A8B2974225016", + "PreviousTxnLgrSeq" : 51640267, + "index" : "0002CD3BA78E323561C904095C2EDDD0EAE58682C251C3AB249EFB9750E92C8F" + }, + { + "Account" : "rKyK3pQtCTMz6nt6Yxtx8vgju6hLyLWpwh", + "Balance" : "1000000289", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "C0F561FB05A808EE51101B4D451F676224FCD18500049054BABB96DEB07D4C35", + "PreviousTxnLgrSeq" : 53531363, + "Sequence" : 1, + "index" : "0002D81201E576CF3E0120E2CC35C03E08E22452F498B8C874CD1DF9D3DC305B" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0.879917248308" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rPT74sUcTBTQhkHVD54WGncoqXEAMYbmH7", + "value" : "0" + }, + "HighNode" : "0000000000000178", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rGestQBBx9LzvB84EuT4fXLMGJwobM4hf8", + "value" : "100000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "FC708BDFC90FFF03350A3D8DA999382F7D26C23C9E506E21EE85988BAA713868", + "PreviousTxnLgrSeq" : 46748120, + "index" : "0002DBB4B998AC5B154C44CF6D09AFC56F1EF7AF932F3F8639148F603849E287" + }, + { + "Account" : "rKcA2BEGo1F9FgjxZCpYKXCPdoRgs6HfEx", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EED2AEB0E8CC724DB3993DC7A4AA39CE45D3EBAA14FF3191833522C3C51ECF0A", + "PreviousTxnLgrSeq" : 35775598, + "Sequence" : 3, + "index" : "0002DC77014AC99A1EE11FC396FE3EC53114075916DB1CA19B6D00FAB2054279" + }, + { + "Account" : "rnFzegAparFPG2iT3ZjNLyJCJgTaTGTAze", + "Balance" : "44977500", + "Flags" : 1179648, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 5, + "PreviousTxnID" : "87E952D70F677E01F7BDE997B56CBED3B03B089F983AA4E8B5510A9A4E993818", + "PreviousTxnLgrSeq" : 44630608, + "Sequence" : 4, + "index" : "0002E13AA676C29F39CA24FCE64D649E41EAD3878674E38F15AC2E8A2C62F7C6" + }, + { + "Balance" : { + "currency" : "EUR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "EUR", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "0000000000000B2B", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "EUR", + "issuer" : "rsrqGKug9zri8a6v1ntrxG1iY29jc17eaW", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "62A36774CBBB4C81A0DFDED7DE937B94C9FED2F1E851FDFE813CAEEB203A6745", + "PreviousTxnLgrSeq" : 33856831, + "index" : "0002E2F1FD488A0EE9D03253761F144EC0DA33AE3C4191D257B5B11DA3FD85C6" + }, + { + "Account" : "rEJPTXe1N961YD9cGmsmgwMpZmbz26Yave", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "84F8284D4F9C04C3B597C988A09D2EE3429C11432850FA2C6B5174606F47AD2A", + "PreviousTxnLgrSeq" : 45560553, + "Sequence" : 4, + "index" : "0002E40161CF611D05E5E3955ECF602A0CB24B15AC0D34452342564F1ACE8746" + }, + { + "Flags" : 0, + "IndexNext" : "00000000000004CB", + "IndexPrevious" : "00000000000004C9", + "Indexes" : [ + "E8C9A4D4FC68E8907135B58F79CB7C9A226354E8763E3366DED150ED31B00A3E", + "C76498C69D0DA394320DCD231221BFE68DAA799FC83C39BA077535B1C1C64357", + "A8CF9F1AD796E54FEE58B3325606D629123C27A47D7DC62D3FF9D7EC050FA379", + "8CCC845672D85DC8409187B6AF07178726852F123C9778B41BE1F725B7D52E85", + "67DEE30B11DF75D230355AF0F62232B2C3FC741446BD58EDAE8B8E948F10A98C", + "6CD1B5E38F1E830B178C8539632E1AB649A3AE96D308FD54670AABBC261C2D8D", + "90015E42BE4342D74C7263CE40B04B19477CA51241DCF5C7EB76C462C1A8A11C", + "DC23BEE432638C1B2F64DBAE2BAE0178FD16FEEF4B60FB4DC06D89FD9925F043", + "CAC174B9408518428BAE74A9845581F66CB3E7073C2C34033DFA075B0BADD594", + "7009D3F91AC4E64B37AFAA5B9FB76AB370E6F9758F99A4BB0167233403F06925", + "B78CB3A31755211BCC3325B6462A20AD4E6BECE76E788DE8487E6560C364FAFB", + "12D2F7522CA12F07533987A3C3F79FE62DF285C7D3AAC8886CD9EF05D2EA3310", + "9FDD34BCDB121570A911E6E318E869FDA3311226F19DC848E9B21926993B3B7A", + "EFD8D41B49D6503256FA072C3C2B6432C67BCEBF2A66E186EA5ADAB618E84F69", + "F26F2F1712EE21B75179B4BAB05ACDB28C0C60146ACA1832D738F9FFD8C21495", + "DB9683C7760AC03A768B3E3E123C315337D3E8C91247BB1AFA2E9BB395B73891", + "03D2F3700BE5F072967C1AB29ABA0F010E05B938BD08DA8985EAA707EB0ACE34", + "4431EB0B4C6E133656F48955FE5A0C6954477C665289B0BAED4AC8202781BA77", + "59956DA4F14C2F71C1ECF70923828616E9285F11CCAC5B7ABD45A3902167C18B", + "CA5C95DEFE1939A958A673F59844F013C7B46DE6CCE474E3F50FE4C2FCE480DB", + "E03D2B6D8F58E4B518264FC3E91C806599709F339D141ED3D03D765C7AEA6B0F" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", + "RootIndex" : "AC7D605DC4B0E09BB9BA05DF47C1D6CFC01688603B14D86BB0E3896B910EF4B4", + "index" : "0002EA7BA21C8D8226C854BDB74D687C237CEF8746F3DC932A559F9C2064F8D7" + }, + { + "Flags" : 0, + "LedgerEntryType" : "SignerList", + "OwnerNode" : "0000000000000000", + "PreviousTxnID" : "F1A41B304E232A9E3C9D598D07E6937B9EF6C1EE9578A7C083983D1A2B90FAB2", + "PreviousTxnLgrSeq" : 35126701, + "SignerEntries" : [ + { + "SignerEntry" : { + "Account" : "rfPN64wTKpvoEcGXbzaSFwTeJvGgkFwTuY", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rJ5LGeJ3AXgtyUaBj9Nv9LTfSLnD5S5M68", + "SignerWeight" : 1 + } + }, + { + "SignerEntry" : { + "Account" : "rKZJjkstK1pRQzk8s7UiaX7Ubo6Z3TVNVD", + "SignerWeight" : 1 + } + } + ], + "SignerListID" : 0, + "SignerQuorum" : 2, + "index" : "0002EB7A73AF53419F135C2E732BC70774B84D1235E96AE5F2D4481FD2EB079E" + }, + { + "Account" : "rM3swPFaTfwJJuUaGQ8hnA5koULsewx8u1", + "Balance" : "19978733", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "3F89A76079746F3EDC49577DE020781A65BC3289122B2F5358F22C8BA27A7D9E", + "PreviousTxnLgrSeq" : 35582012, + "Sequence" : 9, + "index" : "0002F175C2C7472A08F2B030E656B5C6F114A5CA3F00290802C2E16F7D60541B" + }, + { + "Flags" : 0, + "Indexes" : [ "A1DF1B804F052A8831B39E1F6B6B1DE5F4E78C0E33863570E3C665D35C4B9C0B" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rU5whLGPpEmntcqTwQaLS4nsnrHe85ozM1", + "RootIndex" : "0002FC2F23C62F316FE8823101479F16BA154E6F2FA798A31C3CFC17072E24B2", + "index" : "0002FC2F23C62F316FE8823101479F16BA154E6F2FA798A31C3CFC17072E24B2" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-2.939007646409247" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rn4P59E8AryXfuWyTcP5PkUC8fVDjvLN5f", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "LowNode" : "00000000000007A8", + "PreviousTxnID" : "6047EC41BA9E306F7AB111ED174FEDFAFE85B3E2C22409A0B934252C5C94DB28", + "PreviousTxnLgrSeq" : 32218908, + "index" : "0002FF5B1CA1E2C54BCF1E547A8EDAF9A21E4488D88338A7FCBA5D8B5AADAD7E" + }, + { + "Account" : "r99ooocgKebimq2QGsQ91zE1haNkMtDhSL", + "Balance" : "20944251", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "D93515E7915B3090014A11424F2B04F10DC8FFD3BC32D8E5732BBE7DD80DF51F", + "PreviousTxnLgrSeq" : 35406923, + "Sequence" : 5, + "index" : "000300F1A67DDDF180F2F5FBB4842DE5236307886D2C38188C1407EEA9AE4745" + }, + { + "Account" : "rskLVNC3mG17QRroaoppv6Edf8joEorHFT", + "Balance" : "19999988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "3DAF88BE77786AA0AB4D5B19844B88EB181CEDF58E1DA20A198740F7BC0FA024", + "PreviousTxnLgrSeq" : 40120274, + "Sequence" : 2, + "index" : "0003015678A1517A89526AA29CBB8A8BC257FF6622D88557DA658E3411F21B3B" + }, + { + "Balance" : { + "currency" : "XNF", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "5" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "XNF", + "issuer" : "rPKSvQ1qFAksr7hzk2wC2xtqSqFbxP3wvg", + "value" : "0" + }, + "HighNode" : "0000000000000006", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "XNF", + "issuer" : "rngKfjktN2ULxQrsdbsCvU8CKRA1cevHNP", + "value" : "500" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "05C99D17CE9575782E6B74151CEEF53A6D693A8AC5F27300B491916219FFAB61", + "PreviousTxnLgrSeq" : 4479312, + "index" : "0003072319EEE0498F96A9476F71B6471B1B7F950851E3DFCF9420C1F5298BD3" + }, + { + "Account" : "rGXfiCLX166omuSmZbms2ZoMYNBRzvHP8z", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "1A13C53D96A4D339F5BCCFC198D0C5D0C4886BF85D50CDAB3D63E0308CEA9D31", + "PreviousTxnLgrSeq" : 56480801, + "Sequence" : 55816494, + "index" : "0003079A869E1823BDE38CBB99D56BF929EAB01BA290B3E32473221EF02E1466" + }, + { + "Balance" : { + "currency" : "STR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 131072, + "HighLimit" : { + "currency" : "STR", + "issuer" : "rHCYrkbmxBwMKD6JjVAZBCcuDCPDMjxCB4", + "value" : "1000000001" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "STR", + "issuer" : "rsP3mgGb2tcYUrxiLFiHJiQXhsziegtwBc", + "value" : "0" + }, + "LowNode" : "000000000000007B", + "PreviousTxnID" : "7F0F38E7CC1A000F378E1EE9CD42D2C1B98702A269F93359A823FDCD801FD42D", + "PreviousTxnLgrSeq" : 10178957, + "index" : "00030A41AA99869C6DBD24DCF0C91A1FD6AD63EAE7820CE92165D025F1EC5B93" + }, + { + "Account" : "rN2TMeaxGAGHDsUD2Qaf2CtkPtraKmsvaC", + "Balance" : "19993287", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "2243B0A351E5778480EDFD2627135B2D33763EDF67D1037A8950A50076D59B2F", + "PreviousTxnLgrSeq" : 33384428, + "Sequence" : 6, + "index" : "00030A5B5C54753400E0FB69A7A376DA8EC245D6942069A3E56CEC3276B0D902" + }, + { + "Account" : "rLnnTEpzwrcBj2Zpd33Dsq77iutzSvjNzo", + "Balance" : "214124738", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "0EDB7A78F89202267DF062A0DEF0DC9B285774D65053D599DD2FFAF088BE4A83", + "PreviousTxnLgrSeq" : 28757580, + "Sequence" : 69, + "index" : "000311FDE6DA20683ECA81978A6E5C617C38E2836105405FF4129285D506B9C3" + }, + { + "Balance" : { + "currency" : "JPY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0.3369568318" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "JPY", + "issuer" : "r94s8px6kSw1uZ1MV98dhSRTvc6VMPoPcN", + "value" : "0" + }, + "HighNode" : "00000000000000A3", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "JPY", + "issuer" : "rfYQMgj3g3Qp8VLoZNvvU35mEuuJC8nCmY", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "06FC7DE374089D50F81AAE13E7BBF3D0E694769331E14F55351B38D0148018EA", + "PreviousTxnLgrSeq" : 32253063, + "index" : "000319BAE0A618A7D3BB492F17E98E5D92EA0C6458AFEBED44206B5B4798A840" + }, + { + "Flags" : 0, + "Indexes" : [ "0F6870E7A353A08AE5B4C3BD1CEE6970F453F8A4B3D18B91C4C95838A56EA75F" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rhkXLsw9GevBLKy6wHTjFYBb3Ym8y3gqGn", + "RootIndex" : "0003224EF471E4E409840399C5265A20B1A83F8882623974043284461455AA7F", + "index" : "0003224EF471E4E409840399C5265A20B1A83F8882623974043284461455AA7F" + }, + { + "Account" : "rshcmLugYnNfo4LZz11P6p1tHVvKm8exwt", + "Balance" : "19998149", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "032FF7D8A3E7B7981A380430C4130304155F8DC5B0D6D7AF2AE9BCEA96043C34", + "PreviousTxnLgrSeq" : 35909240, + "Sequence" : 21, + "index" : "00032BDB9B745EFCAF7E3DB11BA75D05A8286A2AC7EF4AC61F43A72AEB0D504C" + }, + { + "Account" : "rUTx5eW837RS2ev1uSzKbAMoiTyeUNJKjR", + "Balance" : "67766079", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "E3465D18EB0E072F92E918DC43EBDEE2DE991FE6C3C8D99DFD5BC3C34AC7D938", + "PreviousTxnLgrSeq" : 45158420, + "Sequence" : 6, + "index" : "00033122E0DDE1FC1F96F3749A4B05E1DE3743F38CDC6915D9A5524B28A2D423" + }, + { + "Account" : "rUXmrQadHNnW5TPKzZiZB2ufVZnLAYRXF1", + "Balance" : "325818483", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "AFD43F421282EC80911D6C7893425D6A4502BDD4D2C0682CFB28EE9AB45AFD8F", + "PreviousTxnLgrSeq" : 41689452, + "Sequence" : 53, + "index" : "000333CDAF9C498EF3E726F426B9D953488624B318AF755C6498735CD8855A62" + }, + { + "Account" : "rfFMmbCCRSWwArbhfeKGhufZuGRbW2BhW4", + "Balance" : "125998750000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "261AA7D6FCED1FADD956FC63C72DB2AAB5E8305EA9896D7160D55431DEF6CF61", + "PreviousTxnLgrSeq" : 56212007, + "Sequence" : 55935184, + "index" : "000336C16900E4633CDE390D57C285B5D831842F403900B2B4F65EC56FE17F2C" + }, + { + "Account" : "rPyKE3f9VmYFZt1kNWRYrU8NkGWPoJPSoy", + "Balance" : "20840074", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D502895B5F48CF00B6D4661F278CEE3B39BBFF1143D8DE6A060E9B8EC31C1F3F", + "PreviousTxnLgrSeq" : 51806631, + "Sequence" : 55, + "index" : "00034DBDAB31C00B376D6A4B33C5F61A50CBDC1446E64C5E125EFBFE1FBB191D" + }, + { + "Flags" : 0, + "Indexes" : [ "081342A0AB45459A54D8E4FA1842339A102680216CF9A152BCE4F4CE467D8246" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rh6kN9s7spSb3vdv6H8ZGYzsddSLeEUGmc", + "RootIndex" : "000360186E008422E06B72D5B275E29EE3BE9D87A370F424E0E7BF613C465909", + "index" : "000360186E008422E06B72D5B275E29EE3BE9D87A370F424E0E7BF613C465909" + }, + { + "Account" : "rL98jaU74YA8ApTTKbkMhtDSvcNfiwUcrp", + "Balance" : "20778948", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "57B6A618645E8B93BAA41AA74E56D7AE985428EE490EC9EAA6C4BAD9F39D4961", + "PreviousTxnLgrSeq" : 39541514, + "Sequence" : 2, + "index" : "0003670FB502C9F2C9CF7294F92B0538B4333E9DDF12D65E36D2F65279086066" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "USD", + "issuer" : "r3dSfgL1c19ckULHUfZpAxHWkwCjWfFhZW", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "LowNode" : "000000000000125F", + "PreviousTxnID" : "EFB3C219A768237D668A7B7B50EB21CDFA3034E70AFBCD4A9338E6CD8F3C4F9E", + "PreviousTxnLgrSeq" : 35441502, + "index" : "0003758269F37C061C180B0582EE30F961E3AB9D44E1BC0020B81091ADE999C8" + }, + { + "Account" : "rP3mqGi5PYN22WUf1Fo8K7ncUntWL5rtHS", + "Balance" : "87847269", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "DD15C6074AA46CD8EFAEB0BEF4FF9C8C4B3187E46E89B314EB880808EDD38746", + "PreviousTxnLgrSeq" : 35798376, + "Sequence" : 1, + "index" : "00037AC83282ACE26F066DE2D607300E47D4A62E157CD469E1FE748A4B009F31" + }, + { + "Account" : "rfUvH5v84ytdn23UwXWZvV7SNuH2dgv3v8", + "Balance" : "50019989222", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "82682C0E4EFB0FC31815C36250C6BC129693F8C0B168DB232335DF6D40BAD86D", + "PreviousTxnLgrSeq" : 53565632, + "Sequence" : 2, + "index" : "00038644504E6E379BD37046FDA37C417055D7A88D209F7AB9C3D41840836E7C" + }, + { + "Balance" : { + "currency" : "ETH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "ETH", + "issuer" : "rpbXVn3MEwwwXyAHZtKwEqyV1x24qEWdfR", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ETH", + "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "value" : "0" + }, + "LowNode" : "000000000000056C", + "PreviousTxnID" : "7E9ECD12BC8814A2F575C983308F6F8D2145802AA2BD9A79430529D805684CF9", + "PreviousTxnLgrSeq" : 34768922, + "index" : "00038CAB8AD69D82FAFA3E0B02BB1CA040959B933DF4122EFF009D76A00658FA" + }, + { + "Account" : "rpUbFUFNiVcJRgUJj8sutNmLN3LLexyGEt", + "Balance" : "29974636", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "E02A6BFB72177EF2BDB1696819233BBD86CFD94B376C1ADC2A6EA831D8F3C5FB", + "PreviousTxnLgrSeq" : 50996773, + "Sequence" : 77, + "index" : "00039B62AAB31EE54B8CF9346CBF12A8A9FB80EB0C2BBA04155B5B4F0FBA594D" + }, + { + "Account" : "rQrT1y5CkTKjY6zvci2TruPw2vEGraMvvt", + "Balance" : "3416025660", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "B9BF42229699062CCEC0EBC171CE1177CF99EF387E1C378047C8E3128021FDF2", + "PreviousTxnLgrSeq" : 56479420, + "Sequence" : 55482786, + "index" : "00039CCD5DFAB67E18E978BA2578600A56CD94B71E5EA2920CB825EAD0950888" + }, + { + "Flags" : 0, + "IndexNext" : "0000000000000784", + "IndexPrevious" : "0000000000000782", + "Indexes" : [ + "05F6DD98054AD536FB7D1EE64FF2E37BEA525987300C9051057A428D64CFC64B", + "0E23EA9F7D1466FD72C2D7330E4C0048B4E4B97351EAD7C7851D8C0BAEBF7E15", + "2E349E02287ACB74A420254B3E5535DE13327AAB81A524A877F778CE5CDC2149", + "2FDA646F4E34E04E142223EE957C265C521C28F93DF08998191281C1E5ECA498", + "37010083EE0EE6FD172F3A9FC8D8C4A61FE49BCD640FB7D14D26DCC0E40E61C8", + "5233260F503316CB6EA03FA4943D1E51078E98F7D58BB0544344D552884221D0", + "5775CB45790C38F6EFD6A8D389A683059F00D109E6F39A309BAA852EACA7DEE9", + "5F13E18B1CE5E53B79606BDCA2CF9F96BFBB82B31E7114A9A7E6730CF7788E23", + "66E278F46FBF660D6EDA7EEAFFF8D509A4FED347C297B8EB3E88E77B65EEF3A0", + "75B5F03D5096FBA46E298498583FEDA09C6619F6BD40D12DBB0A8956BA04EE9A", + "78B60DCC25CA34332C66903DCA62B2F1031F025105C03C2CF1BFC71079E606DA", + "886CDA9A8C949DE729D83B0087132AFD126B3D1A1155BAE5244F1F1DB957DF64", + "9085C41FE89F7A7729B5D2E851CA27EFC75C4A5FECC1CF45CF77D68683E7F8E7", + "95AB2A9A055A76C6FC99C2AB752F825BC4FF097017554C8980A045D9C2106F98", + "9D17132791D4A6E9A9FCD2335401290F0A24FF5A18D99F1041E36B98DE765C5F", + "A02CA67F804DFAD220BDFFC49572FE8F8545B6B17F716316A03783619EBBF2C7", + "A8F40848D68D4D138EDD5CF0F8534657D423C02E40581C5EB8DF4861BEC4BAEF", + "BC6B27DF63284E418A1C925D4E8B2E999C8672FBB08839B2AACAFC83789CD527", + "C3A98E846189D1B85DF395ED97F086C3F95B5855C93A07739E6E9AD4E368F679", + "C9BB90AEBAD895B6E7D7D37C6F2BDF53744F06ED8D720156A5DAB8AE904FD554", + "CB8A6826ED894DA07CCE3B47BBF51805308A17478580C1F9591A9085D712A6CB", + "F971A92DF948FF4F8A5A0EBE54C37AD1757C41A02AA1A219A3D0307FDA7E25B6" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "RootIndex" : "4EC2C3BBB5D149BD55EBFB6841BFC74978B240A5312EA96BF569367782997DBD", + "index" : "00039FE2851CAFFBF4AB8906A7CA4C6DA20A03AECD402A62E25B5503BA264C90" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rw8tGC1FHXeuQHo5ccGRAhwNd9MHFsUaXY", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", + "value" : "0" + }, + "LowNode" : "0000000000000461", + "PreviousTxnID" : "BFA706F20486360826B396D37B6687A017494B713A0DA607248BC7C1DDD688E9", + "PreviousTxnLgrSeq" : 31239501, + "index" : "0003A1E91894EAE15ABD2E8172734A7F56847D845570AA9071EBDC0A4F3994DE" + }, + { + "Flags" : 0, + "Indexes" : [ + "58BE13B0871BBE38CB03C9B3BDD3D449FCA43B992DEC896C99632809354A75BD", + "52A28BBAF0EC325F81CB248D8C2FDD27289523738DD0BDF861626ABCB1012D75" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rB9KYTdt1NPvt4rjv3HaGyghuV8ZbjxAiv", + "RootIndex" : "0003A8522014599601A808BF68B490BADE57DD328B07897F9CA18C7782C3C29D", + "index" : "0003A8522014599601A808BF68B490BADE57DD328B07897F9CA18C7782C3C29D" + }, + { + "Account" : "rfretfgjYcB6cVRSqUkGaUBRrPJg7oWXBk", + "Balance" : "20857762", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5398461E08D4B541D3A9B120E9B684CA563581732DBA3024EE2B4837C5636854", + "PreviousTxnLgrSeq" : 36532402, + "Sequence" : 3, + "index" : "0003AB72C4F8DC6C6F9FE1776429E758330E7061EC9EF28D4EF46A1C23E535C4" + }, + { + "Account" : "rHzcWrLab3MubitUfsNGsLNqKeA75VCzjA", + "Balance" : "19999990", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "958B8FFA11DBE960A1346D960217180F37600F8A9E7DAE9EB0C170B1F0B85064", + "PreviousTxnLgrSeq" : 35703532, + "Sequence" : 6, + "index" : "0003AC9192E3746F287527542C724A38FB1689F50AB89617930BCA53C051C8AE" + }, + { + "Account" : "rEjcYAi1kePMyrQTdxFkAdCg8DjUNG2nGk", + "Balance" : "19988000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5A7CE59A33514F05951427EAE6D5139721464730840EC890DC8520E5DA77C7BB", + "PreviousTxnLgrSeq" : 15913663, + "Sequence" : 2, + "index" : "0003B74499E08C266F506BF1F52B4E5212493D913493E4B037DBF867A5437530" + }, + { + "Flags" : 0, + "Indexes" : [ "05654771F9B57011239F2AFE5A92F08220318968F1438DFA64F2CDF0A414B5E6" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rGt8yFKTASyBxCXE9bzXpF1Ucsdx9wdNYD", + "RootIndex" : "0003B76E9B32E108BFBD663FDFB30BF1CDE19E411214C1D9E4A28417CFCAF6BD", + "index" : "0003B76E9B32E108BFBD663FDFB30BF1CDE19E411214C1D9E4A28417CFCAF6BD" + }, + { + "Account" : "rJdAZgrkgVAxsksMkZbn9zheeQFLzp6SGs", + "Balance" : "39999976", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "0A57BAB1C758ED1D3F808133343FDEE5972E9CD0B071A3A814D1BFC64DB039EE", + "PreviousTxnLgrSeq" : 37117674, + "Sequence" : 3, + "index" : "0003B8F63DC61D899B69A0F889DE22EF5CD4B0532DF2C6F4503E45A74F5C6257" + }, + { + "Flags" : 0, + "Indexes" : [ "792E7B025DA04B17EF4BF7C682EA21C900C189D12994B259DE2980F8C62051B3" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rDg11bHubiWpoki8rt9gxpTtLyJeZJ9Sp5", + "RootIndex" : "0003BA5377F7E730EC26B29C412B25707992213103754914DAB2105EA13CB604", + "index" : "0003BA5377F7E730EC26B29C412B25707992213103754914DAB2105EA13CB604" + }, + { + "Account" : "rwZF2RtFafhr3igLU5R32Sedk9gjHDYLDm", + "Balance" : "24977500", + "Flags" : 1179648, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "F15DC44FA931A53BC44940B42A0EFDE4C46BEDF23E1A8A7CFD5BE75224348139", + "PreviousTxnLgrSeq" : 51619073, + "Sequence" : 4, + "index" : "0003C51FEC6DF5EF908A32AD980883A8ED0B39A1855870922C935DB43194D173" + }, + { + "Flags" : 0, + "Indexes" : [ + "6057B8300EF716859B9BF62C8C8C98EA232F7A02E1EF7FED4A0C0F7382F68A51", + "6D3BBE35F7C18C8747310107B1A6B7295EE1FD6667A00015A9FB6681AB0BE10F" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rPbdWUNunUfAGaprmJo5hQyWUkzXrbANzB", + "RootIndex" : "0003C626CADF620F2E911CCFB70BBA29795339274DA9EAE7A2BEAA6C105D1AA5", + "index" : "0003C626CADF620F2E911CCFB70BBA29795339274DA9EAE7A2BEAA6C105D1AA5" + }, + { + "Flags" : 0, + "Indexes" : [ + "C35FF73535631AFA1BF6F15AD391FBE7FFBC5CA9B63411DDCC5E10EC07149AF0", + "AA32F82B41B573D12970D05D5720DEAEA60C3502A3054816ABDED76ACFEB2C3E", + "9A0135755653009912CEBE1869626D7DDBBAC4FA2B0302DE70D1AAEDCD29AC5E", + "1F00033E131AE60F9C3389E849DD4EDB3F00694CED969CC3E8558B5435948899", + "062DEEFC31527A88DE509CE9F09F1D8710E134AB606D05AEBB9B503303821C59" + ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rUyB89zuaijCypgLEXzQXUqthe5FPHUMc", + "RootIndex" : "0003C8E760C9CE377CA4486675760C984DD380E14088CF34E309F7D266956376", + "index" : "0003C8E760C9CE377CA4486675760C984DD380E14088CF34E309F7D266956376" + }, + { + "Account" : "rNxHAm6DrFCgLRV8iyNMzmsmDc3yT9fMew", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "7AF4C24E06DD0F8E2673556DA7E9B4C9F723172898BF29299F3DD5CD62032734", + "PreviousTxnLgrSeq" : 46462347, + "Sequence" : 2, + "index" : "0003CC742B46D74305CA8E046819E1AA97D1562C79220075C88F910DB3D6985F" + }, + { + "Account" : "r6NGJbC8Nh7qg7mNNkn2QpAzLWfh8hP58", + "Balance" : "93294121", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0A1527D62D932335CB5B3CB39073FDF70E005717A21B81FDB8454C56264CF965", + "PreviousTxnLgrSeq" : 31926264, + "Sequence" : 3, + "index" : "0003DC0717153A0FC5E2EA4BA5B591B212EA1EB5BE7B39855D894A058E202F8D" + }, + { + "Account" : "rHpBxwCmb1qDYfL47Yssog86oWYdrWZf5U", + "Balance" : "2000000002577", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0FD4DFDA203A9F9D7E47C7DA2412AA38ADBA2B200515A0AB5F077EED7DF53192", + "PreviousTxnLgrSeq" : 55163924, + "Sequence" : 1, + "index" : "0003DD9FD0C0CCCE359F26E8395BA4A60CB7074439188796C9BED785258375E8" + }, + { + "Account" : "rs2Pi9HrrmrHSva7Rp6m85WTMbijxU8ZRN", + "Balance" : "16294773045", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A887C95A0C6EB0E9052F4DA814D04A411126F255246DCADE73F23184164416DF", + "PreviousTxnLgrSeq" : 55182715, + "Sequence" : 1, + "index" : "0003E412CC0915B3AD068FEF0D8AF37E09DD2DBC802F8D3F5075E13D700955B5" + }, + { + "Balance" : { + "currency" : "ETH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.000375" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "ETH", + "issuer" : "rtR4429hdNSHotarYCqzeJAxqRw8cER1S", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ETH", + "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "value" : "0" + }, + "LowNode" : "0000000000000241", + "PreviousTxnID" : "A6626B1A8A4D66395DF9B4A29A20A31C0AC2E9151274EF4871F1ADCAA6F434C4", + "PreviousTxnLgrSeq" : 31100032, + "index" : "0003E975AB352553F6FC94C4643C2FC13B8CFD1C176DC61694BB5FDEE767EB3F" + }, + { + "Account" : "rfr1PerWfzGmbEn8ZKuz1hGsk4smDAZGST", + "Balance" : "19999980", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "2E9AAC3FA2ECF151EDD81C5E8F88BFA8AEDF755B244283682B086D12F857E0BE", + "PreviousTxnLgrSeq" : 48589693, + "Sequence" : 4, + "index" : "0003EC18AC4B2CF519F33BE734870151F8BED09AA250F1E95CBCD95E04908791" + }, + { + "Balance" : { + "currency" : "GCB", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-33333" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "GCB", + "issuer" : "rKVqAXyd2xdP9iPUJ24j7wjX9TW2oBb7iq", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "GCB", + "issuer" : "rNdwi8ain5ibXNB9A7H3zzKtSxgVzAqqAe", + "value" : "0" + }, + "LowNode" : "0000000000000169", + "PreviousTxnID" : "9B30B8940D0519DC4DBB904E9ED34A12FC42F366981C3BA73E1C43E3E5D27A06", + "PreviousTxnLgrSeq" : 38343800, + "index" : "0003F339D937025D9FAE8724E3949CE4A2D497EE72DCF17CAD03C07E69C312B6" + }, + { + "Account" : "rNPYdGhgeVHyD7Loj4vrEPMjSPGig2p2Fj", + "Balance" : "49999970", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 3, + "PreviousTxnID" : "BAFCA0A4AFBA0300B8800C16E3ABEB0B095BF3103EA985D064EF9C1AD061B9CF", + "PreviousTxnLgrSeq" : 44292686, + "Sequence" : 16, + "index" : "0003F463DC9910431C20BE61FBE203C1776A97847A6C03FE662D0CF571E812BE" + }, + { + "Account" : "rHP4k7K8hxLAJkJjDc6qn6VhkibPU6Vhee", + "Balance" : "10955579573", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "B00C84FD4723003C3EF88934D2182BFEA3A737BB11E81A52340517D9143DCFB3", + "PreviousTxnLgrSeq" : 56192692, + "Sequence" : 2, + "index" : "0003F8872371E899468914E24BC20DD218BE8A2647AF5348E1FFCA92EFE96717" + }, + { + "Account" : "rNozxmhZbAnfcoFrvENNo64HEW5ceNpPPQ", + "Balance" : "19999988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "44290B40914D1192777662E29FB32F43207FB52E7E2BBEFF5F01EBA0ADCF8B08", + "PreviousTxnLgrSeq" : 48580948, + "Sequence" : 3, + "index" : "0003F92B400F4AFA2CD3386459C99408786124EA11BF6D5CB211859142BCC8CF" + }, + { + "Account" : "rfNXU2szUFio4Hus3nikZCxRTM6SB1wGmG", + "Balance" : "2000000167", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "91F073C52B1046E4A4280BDC5299FA25766640DDF8D537CD189424B84C55B4B9", + "PreviousTxnLgrSeq" : 53535233, + "Sequence" : 1, + "index" : "0004006B968DCD105EB9235C8E7CF2A5DEEADC645073BA5D43642CE874CB448A" + }, + { + "Account" : "rUAcsDtb9haqV4Yu9TeSSjpzb8VScp9WKF", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "76916479558C2B1EFA75271AB49DFD491B1B38A9A024584CE6210F34370CF97F", + "PreviousTxnLgrSeq" : 43500691, + "Sequence" : 2, + "index" : "00040A6B5E10E3BC48E76A1FBD64F26C5DBA536C77EAEFD62DDAD03822E79F0D" + }, + { + "Account" : "rBrzrsaHN1NMJ8wNirWGi4xXRixVMa3K4j", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "3BB91826267F85C3A203A5E37FBE643E4AA1F16E2DF8ADB33A009FB93F492BE7", + "PreviousTxnLgrSeq" : 46452698, + "Sequence" : 3, + "index" : "00040B73AB116C267CE43B7A7A7BAC16FDFC0936DC9AB245D54BB4B672BC9A41" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "0000000000000680", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rhePjBM5Hdhqc2hiyAMMNArwJyHhmN1ys3", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "34B671C49C8226F2993601B9F68383C95FEA701A2055D2E64BAC5E2D0E78AD17", + "PreviousTxnLgrSeq" : 30260251, + "index" : "00041008DFADEF0C28810345202B75AB9AE17BA191F3F4821A46D7F476E69B88" + }, + { + "Account" : "rEYT8JgAafMNKDBqPePJCQzxgnH2KYiRSE", + "Balance" : "707739031", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "956669766DE55BEFA53C7C013D113F43A2590451A55452E0787C3FA0C0FEB854", + "PreviousTxnLgrSeq" : 55788741, + "Sequence" : 55786539, + "index" : "00041034B0D6E62B850BEFE74CE4565E47221D550CD274FE4A1EF6310DE39540" + }, + { + "Account" : "rfZHqsL53Kix5vGwTss9fzUe2mC7AZbziF", + "Balance" : "302424455", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "2DC609DA0D310409F4DB8C9C9DE2A539BD60EE0D94218795D552BFE04921A5A8", + "PreviousTxnLgrSeq" : 35144098, + "Sequence" : 2, + "index" : "00041094FF85918AE56E103122EA8C21B4ED567F17B9AA1764135BF4863BA91C" + }, + { + "Account" : "rJYacFmK5NW6q1en2X1WXsC63FeXbdZZcK", + "Balance" : "1993092237", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "E040A227580A5D98471EC9F08B2BD714D9D131B30C1D9B5DA537625D9D9023ED", + "PreviousTxnLgrSeq" : 53866398, + "Sequence" : 1, + "index" : "00041CFCBED5E832F9AF02921DBA390F2243809CAEE2F6B12FC7FE2257EB4C61" + }, + { + "Account" : "rNn9diyjJ8rypuTMT8eowyDdhWvfka7PyW", + "Balance" : "49995695", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "6DEF945C56DFF972AD5387BBF158343C18DA2AE38810BEACFCA79F0866F8C6AB", + "PreviousTxnLgrSeq" : 29843258, + "Sequence" : 4, + "index" : "000424554D47800D97BCA002008324F3505F3DFA0051369D2BB1EC9278EC1AFA" + }, + { + "Account" : "r4gdggbXw527EehtLpMzSq7HkV8X1ZJNfu", + "Balance" : "49988000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "2C5AA5DD28A86D1FD15C71D5EE10ACB379C26353068C677536CAAF5054EBB63B", + "PreviousTxnLgrSeq" : 10591517, + "Sequence" : 2, + "index" : "00042D99424950CEF1C109E1AD59A1BDB39798CE5DC33997118E5C81CA36D736" + }, + { + "Balance" : { + "currency" : "EUR", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "EUR", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "0000000000000EB4", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "EUR", + "issuer" : "rpqf8HjJVfNGzz2xgp6FHgGSDjFUJVF1Z7", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "58F0CE1FC3D3F698B54EEF63327F5312A4E1F6ADFF0D6C0E9E5ED70FAFCE7108", + "PreviousTxnLgrSeq" : 35077255, + "index" : "00043116DDC6156D7F1DEB82947E530C5D15BC1110EB4B6610C73026608058E8" + }, + { + "Account" : "rhsxXXvmCJSxXdPQh1BghKrwWmGCkidcWb", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "8AD609D944125F19256A8F43BBB306D815237EC2EDDAFDA3BFBBA05DA6207A8E", + "PreviousTxnLgrSeq" : 35163930, + "Sequence" : 2, + "index" : "00043AC62B3EC2680D729DFF135CB31AF9EB59D2866B588959D6F45ADF76949A" + }, + { + "Account" : "r3fDQrGYJsLfVnX2UpR3AvHLQMe9ttBhFM", + "Balance" : "194809789", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 8, + "PreviousTxnID" : "6BB24B338A3ACE4BADEE7B3F947636C7F657F459CADBE44F2C9B469C999FA3A2", + "PreviousTxnLgrSeq" : 34106543, + "Sequence" : 493, + "index" : "00043C397A43F4E6F99235F840C5783ACE2780A8AD5D5BC344BD7DCB6CD9D853" + }, + { + "Account" : "raoc4ckuPpfqGuuAm55HwUvUHcfuNmiAhj", + "Balance" : "37291669", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "CECA45286DB6F6E01EEE88D950556D6E40BFE67C66A3A765B09C2FD01273391E", + "PreviousTxnLgrSeq" : 36188661, + "Sequence" : 1, + "index" : "00044273E4FCD8932602CBB8545F54E862270F79F183B1C40AA11E98F297E951" + }, + { + "Account" : "rE4TJNbsG6CPM7X3Qhyw85QqGENEhgCKp4", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "9850E15578F6D3A6B8232FE9CA6DAF9B4D10B980C88344D96078CBDB81A9461A", + "PreviousTxnLgrSeq" : 35420496, + "Sequence" : 2, + "index" : "00044E668C2326839EC8E145A4E4C07A451FF3C5618E8892EBC0C21D6D852632" + }, + { + "Account" : "rDm4AioMMZgd7KedMRgv73yQ6zhMJMHHtH", + "Balance" : "19999988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 1, + "PreviousTxnID" : "1FEC8F660682CD2B450F8D4780E2535ACFE40FCDD9FE66AB97DC190DB9FA3D29", + "PreviousTxnLgrSeq" : 37735191, + "Sequence" : 2, + "index" : "00044E7954EBCFCDD3D21AD53777F89196B6F37CD43A40D0DD26A69C43E5DC04" + }, + { + "Account" : "rQBAbNc26Ys3Tbagkmb5jAAf2ZXsaqZyGF", + "Balance" : "20000076", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0D5DA3CC42ADBB68B3A08704255720F928D9984E97C3CB7BF70554F134EA3669", + "PreviousTxnLgrSeq" : 35290357, + "Sequence" : 4, + "index" : "000450DCF34F189E5CF2E97EA797000439AE4A9580FB45885BF979F37215DE83" + }, + { + "Account" : "rEsNWUZ9vr7GjU6pu5W6cEEg8tKwYJy59X", + "Balance" : "20226687", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5A1528246D603633F6E918AA0AB21836E09D7917E698101A702796DE921E6DA2", + "PreviousTxnLgrSeq" : 41695007, + "Sequence" : 3, + "index" : "00045125EE993EF598355CB47A24C482AE07D870F8F0806BA973FB299F4B29AB" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "0000000000000396", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rq4BtzpHxFRQn9qsk3pRhDWPU1CrmYeT6", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "38276C2BF8B8995573F0CD5B3600922B153393CF0F39F422681580A943DC85EE", + "PreviousTxnLgrSeq" : 35441092, + "index" : "00045B7D116EEF9A5441171F497C4ED66BA027A0DB513FA92E13806DB1A0486B" + }, + { + "Account" : "rDZCRYBAkW2JhLvoo879f7schNT5WE1hKs", + "Balance" : "100000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "448F7523B5A49F69B4093F2C310A3CE2DB5E0D1F77EF0A992C01F511239ED4B7", + "PreviousTxnLgrSeq" : 56260953, + "Sequence" : 56260953, + "index" : "0004605DC35B94E8E6481CC6BA45C72C02C05745A1F731A6955863C80845F057" + }, + { + "Account" : "rNPRPQPCCPKDu6XKqN6FxK1vhMup9h7xv1", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "5EE647BB6D9700357D5937A970452D9CD6A2E54BF1144F45F2AA7735BEDE8642", + "PreviousTxnLgrSeq" : 50147716, + "Sequence" : 2, + "index" : "0004622E90BF53DBDE39CB7CB902892F77E367C50059D4F82319A1B733ED3389" + }, + { + "Account" : "rws2ctKicUhnqq3HcnUq1Qbk39NxsGeu2q", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "49F95E1E9DF098C2CB695D2C0A4C12C0345A82A83AF0AC1D38770FB93BC00D88", + "PreviousTxnLgrSeq" : 48127460, + "Sequence" : 2, + "index" : "00046490305BFB74F60BE369CA1170FFD1C40491D3E4963F630130E42E1F14F0" + }, + { + "Account" : "rh5XXc8BFFRA7xeWojr2ZsYgqvgQdhvRAd", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "6DE20189EF8598769263232EABD70197242DBA3196A02E20C1CE30B1C55FB3D2", + "PreviousTxnLgrSeq" : 34283739, + "Sequence" : 2, + "index" : "000466F1C43F93B9A9FAB81F5909438355DECF70C67BAEE2F2B97F7FE80DB23F" + }, + { + "Account" : "rjryT2fZHQMUkQ57i7eqjjWMdSXbL1xWz", + "Balance" : "19988000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EC38AB0D48757E9E088788A3907BD68FC33FA930160902E1A76D72600081EEDC", + "PreviousTxnLgrSeq" : 10644634, + "Sequence" : 2, + "index" : "00046B3B5D5C5F45AE5393761A99A8DDB2CEC25526148FB529F1404EC0DB230A" + }, + { + "Account" : "rnHCMNLwZr6aPhUkHhX1Cog1zkwebJ8k86", + "Balance" : "25489074", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0BB27A488FD2D4579C480C1E89AB2EAF65104548FF5D96A6A91ED209F1870560", + "PreviousTxnLgrSeq" : 48905816, + "Sequence" : 4, + "index" : "0004704B77C1942A569589D35F70AFBC3F2040DB4806733CFC51CA942C1EC627" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1114112, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value" : "0" + }, + "HighNode" : "00000000000005C8", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rhBxjDrNybHTk5zM7yR7d54noXVjvLRtZY", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "EDEDFD10BE0D8B5705B3BC2D05E37E4AD041DDF72D4635E5B062656960325D7E", + "PreviousTxnLgrSeq" : 30031756, + "index" : "00047509E54628EDC5A904C00C08A1BAB60D24BD23CC34CBB38ABE9F45F955B0" + }, + { + "Account" : "r9DvWkeub9kNaESk33UEGFg3euf74sbFWf", + "Balance" : "19999988", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "A1E466CEB29E2EB339F1DE9D6D3F1D7CFF5D826D5D338C1B8124E6CBA6632393", + "PreviousTxnLgrSeq" : 34935031, + "Sequence" : 2, + "index" : "000477ECA17E9435728D0560E349888965579EE5C1281F24190F988716719FCD" + }, + { + "Flags" : 0, + "Indexes" : [ "4B86893AD9F493ACB05E269A62DEB07A25CF49255030CECC91D69767BBECF16E" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rJs1i518wUrJtN8n5ZGjnVU4teCS4bVkhw", + "RootIndex" : "000488530E79F3C7E0B17C0E9DF4C242952A8B85C33AA80F173C842128105EAD", + "index" : "000488530E79F3C7E0B17C0E9DF4C242952A8B85C33AA80F173C842128105EAD" + }, + { + "Account" : "rMgVhSaAnrXBVoqs6QKqaCzcPT28WVbyyz", + "Balance" : "20959223", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "EB3C10C8ECA22C0F53566396871481EB2176768209232266A5029799D8568544", + "PreviousTxnLgrSeq" : 38508528, + "Sequence" : 19, + "index" : "00048EDD8A181E63056A7B2718EF840FC508ED05354955ED0D80BC10609F6DEA" + }, + { + "Account" : "rGbWLvx92cmECTsn3TFJfPuAnbqpdeEgKz", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "585B9341FC91832349AC47ACD4374D6584A44FB16975D83CF0BD7230E3E64F82", + "PreviousTxnLgrSeq" : 48407938, + "Sequence" : 2, + "index" : "0004951F6647029298DF9BF8DB099E8A1A8B74F502BC5CEAD9030A9A9FB7792D" + }, + { + "Account" : "rPPnjVhweEsXfmPchVa6GqHEf2kpooP9iv", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "ABC32682023FA3C11A522B7C7F41524D3ACEA0F7FA11C4FA019BFCCC86DE3BF6", + "PreviousTxnLgrSeq" : 35905984, + "Sequence" : 1, + "index" : "0004980A17929CEB800E3E1CF2F6045B6EE0160F4F342B0ECB791F867D5C8AB9" + }, + { + "Balance" : { + "currency" : "CNY", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 131072, + "HighLimit" : { + "currency" : "CNY", + "issuer" : "rHw3NqphfdPiJbctTLmg9rP2yERoqfWeQ2", + "value" : "10000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CNY", + "issuer" : "rnuF96W4SZoCJmbHYBFoJZpR8eCaxNvekK", + "value" : "0" + }, + "LowNode" : "000000000000003B", + "PreviousTxnID" : "06C4D587DA85B52C504C44DB39272DDCAF216C8403C5D0A943AF0FB9479A665B", + "PreviousTxnLgrSeq" : 3242268, + "index" : "00049C6ACC7B48B847E0EFA9313C0B28E79F7AC9A246DE269D85CC3756D15D6A" + }, + { + "Balance" : { + "currency" : "ETH", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "ETH", + "issuer" : "rUf7tsQugDN8vpTvRdcZgcibmtxHMXATRW", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "ETH", + "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "value" : "0" + }, + "LowNode" : "0000000000000401", + "PreviousTxnID" : "BF1138E291AC65A99E3D19C0654E223674896ED9A2530A58D3505EF47934DA53", + "PreviousTxnLgrSeq" : 32435791, + "index" : "00049E88D4D3337584AE71762ECEC72CC045A1FB0ECE5FD0AD71371EC7C82484" + }, + { + "Account" : "rh41r1hMt16UFwaGXCNtC1mAUS5Nuu7omo", + "Balance" : "48999940", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "D4B29DF22B522758875EAC5364D66690C274D81225EF9A48CF40EE8600D3AC35", + "PreviousTxnLgrSeq" : 38585786, + "Sequence" : 6, + "index" : "0004A34C6D6C448499B8341264CE32AB4700695A99C5E7FD60E470D32C80756E" + }, + { + "Account" : "rUfgiY4cAPU8DasL8EYAicPjj4JqCUB4aY", + "Balance" : "523343166", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "570E22E8A811FA0CC3CAFC0F0235428BB8BAE1C4260A6A123FC1F103332B1608", + "PreviousTxnLgrSeq" : 49099007, + "Sequence" : 1, + "index" : "0004A6317EEF302AD8505B51242BE09AB6D117E05A0BE5E886558B15ADF55C9B" + }, + { + "Account" : "rhdHkJnWFvet4Wwhq13iYMHFjT28BGyXbG", + "Balance" : "20505258", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 2, + "PreviousTxnID" : "4E3FCD2B7E7B6AEDC6F0E6767CF9D118CD48348F7F58A2CD2F6D1C932AA5190B", + "PreviousTxnLgrSeq" : 52648559, + "Sequence" : 170, + "index" : "0004AAE0CCF1618C2A894B06A30D7E85CCD8BC944FA30486F990A16085EBADBE" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 1179648, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rNPRNzBB92BVpAhhZr4iXDTveCgV5Pofm9", + "value" : "0" + }, + "HighNode" : "0000000000000003", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rUqNn26jQG8zfNDy21NTCwgFXrFgLyRf3U", + "value" : "0" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "00960BD6EEEEFBAD01B8FBF80B8E8E6783BECF84BBC7C6776F745E3681B8EA52", + "PreviousTxnLgrSeq" : 14819481, + "index" : "0004AC676C97112A2A14494B56C1CD9435B8E319F5152DF1F6BD40EC1A2586C4" + }, + { + "Account" : "rHK7ga3v53tfTCdVPmpHNdvmUGLpG9gNGh", + "Balance" : "109685000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "8EE7DE8E9156503E1BAFA8CA00867946F43FCDC254FE650564D1CCF70F47106F", + "PreviousTxnLgrSeq" : 35185091, + "Sequence" : 1, + "index" : "0004AEC9772AB16AF1C9FD08850D918769F60C55C9FF1877FE8125D0F418117F" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rfSEud5jTYqQF3CnKBHgt3AxkWCnwUgJg9", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B", + "value" : "0" + }, + "LowNode" : "000000000000029E", + "PreviousTxnID" : "301DBB9F2A532F9AE4B565D74AE24862D715CBA450B99CB2F00B657EBDDE0F9A", + "PreviousTxnLgrSeq" : 10242481, + "index" : "0004AF8BD80F295A8E8DA1D6597DAB919037007C70657BAD81B56FCDB7B38E80" + }, + { + "Account" : "rJdq8QfaW7Uur9L63xbC17fx1hXvzXmFGn", + "Balance" : "20439844", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "6187CAA5525A3B413ECACE88C11DD4D1E438D112B04AA43F86DD81DAE2AE440D", + "PreviousTxnLgrSeq" : 49070852, + "Sequence" : 39, + "index" : "0004B458F8891430C7B7A237E66F02E693A78AF2D68822DA5F0DEECC3B171E3D" + }, + { + "Balance" : { + "currency" : "USD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "0" + }, + "Flags" : 2162688, + "HighLimit" : { + "currency" : "USD", + "issuer" : "rNPRNzBB92BVpAhhZr4iXDTveCgV5Pofm9", + "value" : "0" + }, + "HighNode" : "0000000000000081", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "USD", + "issuer" : "r9GhUNdVsPF8kvGdtZs2EH5KvfWefddyXP", + "value" : "1000000000" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "4E910D3230F90B2C5F1D0FA27A40196AC55A0B2625BBAEEC346B9A2D2C05B3ED", + "PreviousTxnLgrSeq" : 24792921, + "index" : "0004B7BE41198D0C0DFC7456B2941022CDEDF96D2B34BA2B4D0A3E14C67A3541" + }, + { + "Account" : "rae6oVSd1aNTJvAwyxE8wKVNVAHyWawN5S", + "Balance" : "20000000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "AB0FFB05D0DCD834B0EC7CBF61801755B595A48CDD7F6AFD5B6E0BF9C988FD09", + "PreviousTxnLgrSeq" : 45371385, + "Sequence" : 2, + "index" : "0004B861C4B94E840FF9401876572F8193C53761BCC8B6DBC99A5D9383D12402" + }, + { + "Flags" : 0, + "Indexes" : [ "8E6889A03B26C4C7D73D48E374471C8C7DFBE994382C229D7D56CF3AF6FB3F28" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "r9sUeAqPayRSsXamaqvWeZPDVENK1ScPed", + "RootIndex" : "0004C29FA06DE0D176D987DFD9712F310BDD6749D6A1F83556BBBF710B07EA46", + "index" : "0004C29FA06DE0D176D987DFD9712F310BDD6749D6A1F83556BBBF710B07EA46" + }, + { + "Balance" : { + "currency" : "CAD", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-23" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "CAD", + "issuer" : "rJhd44rcZNXJs3UKZGf28i1j5Dv1kMHMjr", + "value" : "0" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "CAD", + "issuer" : "r3ADD8kXSUKHd6zTCKfnKT3zV9EZHjzp1S", + "value" : "0" + }, + "LowNode" : "0000000000000009", + "PreviousTxnID" : "DDDCB07625649FBA5AEF4FEF52628E5B34D9A690DBC653D3E61BCFB332E11184", + "PreviousTxnLgrSeq" : 6599501, + "index" : "0004C9E1CF03D437B6D8CE8E3522844BA2DCA9818A83D3E20A1D8FCE374FA3A3" + }, + { + "Account" : "rMXy2mvgGfo6VPKZiE2p178MBk4fesnkss", + "Balance" : "42807000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "713598A0911DB371E6AE6B320D320EAD585E72195728723F4260F86FB41A862C", + "PreviousTxnLgrSeq" : 35438454, + "Sequence" : 1, + "index" : "0004D14B235DD9C0AB959C26C3D1199D3098D8B22DBB694753C398FE011DE000" + }, + { + "Balance" : { + "currency" : "BTC", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-0.000016588782871" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "BTC", + "issuer" : "rErS8387dwmS7E3fDnTFa8XAQRPr5uvFhd", + "value" : "1000000000" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "BTC", + "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", + "value" : "0" + }, + "LowNode" : "0000000000000BD2", + "PreviousTxnID" : "8A292FEDE82F23A60E1BC7188F1C88147DAD7303D297A39875DFC8A7DD74C772", + "PreviousTxnLgrSeq" : 35731651, + "index" : "0004D41DDBE051FD5302886A10C9990F4264DC657CE49F62F95DF3A86E255C2D" + }, + { + "Flags" : 0, + "Indexes" : [ "FD6EBE613BED36E97D7FCAEF9870FFDEC49FCC23FA76FA7443AB59F66C4DFBF8" ], + "LedgerEntryType" : "DirectoryNode", + "Owner" : "rJTjmpFeVYxKzDXcxPYyxqDFPsAjHU1szc", + "RootIndex" : "0004E7DEEA81686BE43530355C41B0931EB4DB21726E6FDF913CF1425AF30400", + "index" : "0004E7DEEA81686BE43530355C41B0931EB4DB21726E6FDF913CF1425AF30400" + }, + { + "Balance" : { + "currency" : "MTL", + "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value" : "-9999999999999999e-4" + }, + "Flags" : 2228224, + "HighLimit" : { + "currency" : "MTL", + "issuer" : "rUZt6cD3ZN6iWat1q3Z6B4YmkPBEa88vYE", + "value" : "1000000000000000e-3" + }, + "HighNode" : "0000000000000000", + "LedgerEntryType" : "RippleState", + "LowLimit" : { + "currency" : "MTL", + "issuer" : "rfe8yiZUymRPx35BEwGjhfkaLmgNsTytxT", + "value" : "0" + }, + "LowNode" : "0000000000000000", + "PreviousTxnID" : "102CCCA09AC9D0337F1E4E8EE66D7ADC6BCE3E54F1D3785A06C383555E81D08A", + "PreviousTxnLgrSeq" : 7117664, + "index" : "0004ED7218296FBABFC9790AFE8A193CB8B4E52CCF6D06D2F5CD81A9125BC7D1" + }, + { + "Account" : "rhafmcHgwPDhUtwHKJHeS1AowVQ6yrBzry", + "Balance" : "186663000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "0B3EF2DEF14E17DEF61DC6489800FCA372A7D2FBBF1344AF690A231EDD722390", + "PreviousTxnLgrSeq" : 35410824, + "Sequence" : 1, + "index" : "0004EFFADB2A92621B66644809830ADC7F5453D96F523D6885D5D4F5953A674C" + }, + { + "Account" : "rse7zNjdyUTcuRyAbnmY7GKV2cSSM9xYbx", + "Balance" : "20150000", + "Flags" : 0, + "LedgerEntryType" : "AccountRoot", + "OwnerCount" : 0, + "PreviousTxnID" : "FF39483D49A3132227A5F83316CCFD943248CA3D5D68161B4177791F9ED384F5", + "PreviousTxnLgrSeq" : 30401374, + "Sequence" : 4, + "index" : "0004F80C0082589154F40E9962406ADF2A6BC943BCD073863B8BB9B3EDB306EA" + } + ], + "status" : "success", + "validated" : false + } +} +``` + The response follows the [standard format][], with a successful result containing the following fields: From 769003a8c4f709dc5b601f31065482ea1b31a485 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 20 Jul 2020 17:17:31 -0700 Subject: [PATCH 31/65] Doc backfilling changes in v1.6.0 --- .../ledger-history/ledger-history.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/content/concepts/the-rippled-server/ledger-history/ledger-history.md b/content/concepts/the-rippled-server/ledger-history/ledger-history.md index 9503350842..1962bb983a 100644 --- a/content/concepts/the-rippled-server/ledger-history/ledger-history.md +++ b/content/concepts/the-rippled-server/ledger-history/ledger-history.md @@ -18,17 +18,21 @@ The [server_info method][] reports how many ledger versions your server has avai ## Fetching History -When it starts, a `rippled` server's first priority is to get a complete copy of the latest validated ledger. From there, it keeps up with advances in the ledger progress. If configured to do so, the server also backfills ledger history up to a configured amount, which must be equal to or less than the cutoff beyond which online deletion is configured to delete. +When it starts, a `rippled` server's first priority is to get a complete copy of the latest validated ledger. From there, it keeps up with advances in the ledger progress. The server can also backfill history from before it became synced, as well as filling in any gaps in the history it has collected after syncing. (Gaps in ledger history can occur if a server temporarily becomes too busy to keep up with the network, loses its network connection, or suffers other temporary issues.) To backfill history, the server requests data from its peer servers. -The server can backfill history from before it became synced, as well as filling in any gaps in the history it has collected after syncing. (Gaps in ledger history can occur if a server temporarily becomes too busy to keep up with the network, loses its network connection, or suffers other temporary issues.) To backfill history, the server requests data from its peer `rippled` servers. The amount the server tries to backfill is defined by the `[ledger_history]` setting. +Backfilling history is one of the server's lowest priorities, so it may take a long time to fill missing history, especially if the server is busy or has less than sufficient hardware and network specs. For recommendations on hardware specs, see [Capacity Planning](capacity-planning.html). Backfilling history also requires that at least one of the server's direct peers has the history in question. For more information on managing your server's peer-to-peer connections, see [Configure Peering](configure-peering.html). The XRP Ledger identifies data (on several different levels) by a unique hash of its contents. The XRP Ledger's state data contains a short summary of the ledger's history, in the form of the [LedgerHashes object type](ledgerhashes.html). Servers use the LedgerHashes objects to know which ledger versions to fetch, and to confirm that the ledger data they receive is correct and complete. -Backfilling history is one of the server's lowest priorities, so it may take a long time to fill missing history, especially if the server is busy or has less than sufficient hardware and network specs. For recommendations on hardware specs, see [Capacity Planning](capacity-planning.html). Backfilling history also requires that at least one of the server's direct peers has the history in question. -### With Advisory Deletion + +### Backfilling +[Updated in: rippled 1.6.0][] + +The amount of history a server attempts to download depends on its configuration. The server tries to fill gaps by downloading history up to **the oldest ledger it already has available**. You can use the `[ledger_history]` setting to make the server backfill history beyond that point. However, the server never downloads ledgers that would be scheduled for [deletion](online-deletion.html). + +The `[ledger_history]` setting defines a minimum number of ledgers to accumulate. Use the special value `full` to download the [full history](#full-history) of the network. If you specify a number of ledgers, it must be equal to or more than the `online_deletion` setting; you cannot use `[ledger_history]` to make the server download _less_ history. To reduce the amount of history a server stores, change the [online deletion](online-deletion.html) settings instead. -If [online deletion](online-deletion.html) and advisory deletion are both enabled, the server automatically backfills data up to the oldest ledger it has not been allowed to delete yet. This can fetch data beyond the number of ledger versions configured in the `[ledger_history]` and `online_delete` settings. The [can_delete method][] tells the server what ledger versions it is allowed to delete. ## Full History From 9d8604a02351b1d2990c5cc2eaf38d8c9fa700ab Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 22 Jul 2020 14:43:24 -0700 Subject: [PATCH 32/65] Backfilling: edits per review --- .../the-rippled-server/ledger-history/ledger-history.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/concepts/the-rippled-server/ledger-history/ledger-history.md b/content/concepts/the-rippled-server/ledger-history/ledger-history.md index 1962bb983a..5cd44731fb 100644 --- a/content/concepts/the-rippled-server/ledger-history/ledger-history.md +++ b/content/concepts/the-rippled-server/ledger-history/ledger-history.md @@ -18,7 +18,7 @@ The [server_info method][] reports how many ledger versions your server has avai ## Fetching History -When it starts, a `rippled` server's first priority is to get a complete copy of the latest validated ledger. From there, it keeps up with advances in the ledger progress. The server can also backfill history from before it became synced, as well as filling in any gaps in the history it has collected after syncing. (Gaps in ledger history can occur if a server temporarily becomes too busy to keep up with the network, loses its network connection, or suffers other temporary issues.) To backfill history, the server requests data from its peer servers. +When an XRP Ledger server starts, its first priority is to get a complete copy of the latest validated ledger. From there, it keeps up with advances in the ledger progress. The server fills in any gaps in its ledger history that occur after syncing, and can backfill history from before it became synced. (Gaps in ledger history can occur if a server temporarily becomes too busy to keep up with the network, loses its network connection, or suffers other temporary issues.) When downloading ledger history, the server requests the missing data from its [peer servers](peer-protocol.html), and verifies the data's integrity using cryptographic [hashes][Hash]. Backfilling history is one of the server's lowest priorities, so it may take a long time to fill missing history, especially if the server is busy or has less than sufficient hardware and network specs. For recommendations on hardware specs, see [Capacity Planning](capacity-planning.html). Backfilling history also requires that at least one of the server's direct peers has the history in question. For more information on managing your server's peer-to-peer connections, see [Configure Peering](configure-peering.html). @@ -29,7 +29,7 @@ The XRP Ledger identifies data (on several different levels) by a unique hash of ### Backfilling [Updated in: rippled 1.6.0][] -The amount of history a server attempts to download depends on its configuration. The server tries to fill gaps by downloading history up to **the oldest ledger it already has available**. You can use the `[ledger_history]` setting to make the server backfill history beyond that point. However, the server never downloads ledgers that would be scheduled for [deletion](online-deletion.html). +The amount of history a server attempts to download depends on its configuration. The server automatically tries to fill gaps by downloading history up to **the oldest ledger it already has available**. You can use the `[ledger_history]` setting to make the server backfill history beyond that point. However, the server never downloads ledgers that would be scheduled for [deletion](online-deletion.html). The `[ledger_history]` setting defines a minimum number of ledgers to accumulate. Use the special value `full` to download the [full history](#full-history) of the network. If you specify a number of ledgers, it must be equal to or more than the `online_deletion` setting; you cannot use `[ledger_history]` to make the server download _less_ history. To reduce the amount of history a server stores, change the [online deletion](online-deletion.html) settings instead. From 1101d65051190a78785ae24629571667b6e7f136 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 16 Jul 2020 23:00:33 -0700 Subject: [PATCH 33/65] Start applying spell-checking --- content/_snippets/data_types/address.md | 7 +- .../depositauth-semantics-table.html | 12 +- .../amendments/known-amendments.md | 2 +- .../concepts/consensus-network/consensus.md | 10 +- .../concepts/consensus-network/fee-voting.md | 4 +- .../transaction-malleability.md | 2 +- .../decentralized-exchange/autobridging.md | 2 +- .../concepts/decentralized-exchange/offers.md | 4 +- .../decentralized-exchange/ticksize.md | 2 +- .../introduction/intro-to-consensus.md | 2 +- .../introduction/software-ecosystem.md | 6 +- .../concepts/introduction/technical-faq.md | 18 +- .../introduction/xrp-ledger-overview.md | 4 +- content/concepts/introduction/xrp.md | 6 +- .../accounts/accounts.md | 16 +- .../accounts/cryptographic-keys.ja.md | 4 +- .../accounts/cryptographic-keys.md | 6 +- .../accounts/depositauth.md | 4 +- .../accounts/reserves.md | 2 +- .../payment-types/cross-currency-payments.md | 4 +- content/references/data-api.md | 56 +-- .../ledger_cleaner.md | 2 +- .../validator_list_sites.md | 2 +- .../api-conventions/basic-data-types.md | 4 +- .../api-conventions/error-formatting.md | 2 +- .../api-conventions/request-formatting.md | 4 +- .../api-conventions/serialization.md | 5 +- .../rippled-api/commandline-usage.md | 4 +- .../references/rippled-api/peer-crawler.md | 2 +- .../public-rippled-methods.md | 2 +- .../enableamendment.md | 16 +- .../pseudo-transaction-types.md | 14 +- .../pseudo-transaction-types/setfee.md | 14 +- .../transaction-metadata.md | 7 +- .../transaction-results/tec-codes.md | 4 +- .../transaction-results/tef-codes.md | 3 +- .../transaction-results/tel-codes.md | 4 +- .../transaction-results/tem-codes.md | 12 +- .../transaction-results.md | 4 +- .../transaction-types/offercreate.md | 24 +- .../transaction-types/paymentchannelclaim.md | 12 +- .../transaction-types/signerlistset.md | 14 +- .../transaction-types/trustset.md | 14 +- .../references/rippled-api/validator-list.md | 18 +- content/references/xrp-ledger-toml.md | 22 +- .../offline-account-setup.md | 2 +- .../manually-connect-to-a-specific-peer.md | 2 +- .../fix-sqlite-tx-db-page-size-issue.md | 4 +- .../troubleshooting/server-doesnt-sync.md | 1 + .../troubleshooting/server-wont-start.md | 1 + .../understanding-log-messages.md | 4 +- .../become-an-xrp-ledger-gateway.md | 2 +- .../list-xrp-as-an-exchange.md | 2 +- .../use-cases/list-xrp-in-your-exchange.md | 2 +- ...nel-to-enable-an-inter-exchange-network.md | 10 +- content/use-cases/use-cases.md | 2 +- dactyl-config.yml | 6 + tool/spelling.txt | 390 ++++++++++++++++++ 58 files changed, 607 insertions(+), 203 deletions(-) create mode 100644 tool/spelling.txt diff --git a/content/_snippets/data_types/address.md b/content/_snippets/data_types/address.md index 96cb460038..39e9cfc310 100644 --- a/content/_snippets/data_types/address.md +++ b/content/_snippets/data_types/address.md @@ -2,13 +2,14 @@ Accounts in the XRP Ledger are identified by an address in the XRP Ledger's [bas * Between 25 and 35 characters in length * Starts with the character `r` - - **Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) (and developed a [codec](https://github.com/xrp-community/xrpl-tagged-address-codec) to support) a new **X**-address format that exchanges and wallets could use instead of [destination tags](https://xrpl.org/source-and-destination-tags.html). These "packed" addresses start with an `X` instead of an `r`. For more information, see the [XRPL 𝗫-address format](https://xrpaddress.info/) site. - * Uses alphanumeric characters, excluding the number "`0`" capital letter "`O`", capital letter "`I`", and lowercase letter "`l`" * Case-sensitive * Includes a 4-byte checksum so that the probability of generating a valid address from random characters is approximately 1 in 2^32 +**Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) an **X**-address format that "packs" a [destination tag](source-and-destination-tags.html) into the address. These addresses start with an `X` (for the mainnet) or a `T` (for the [testnet](parallel-networks.html)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec). + +The XRP Ledger protocol only supports "classic" addresses natively, but [ripple-lib](rippleapi-reference.html), [Xpring SDK](https://xpring.io/docs), and many other tools support X-addresses tool. + {% if currentpage.md != "concept-accounts.md" %} For more information, see [Accounts](accounts.html) and [base58 Encodings](base58-encodings.html). {% endif %} diff --git a/content/_snippets/depositauth-semantics-table.html b/content/_snippets/depositauth-semantics-table.html index 4f78dfbd0c..d8b906f352 100644 --- a/content/_snippets/depositauth-semantics-table.html +++ b/content/_snippets/depositauth-semantics-table.html @@ -8,9 +8,9 @@ Transaction Type - Sent by DestinationSent by Others + Sent by Destination Sent by Others   - Sent by DestinationSent by OthersSent by Preauthorized Others + Sent by Destination Sent by Others Sent by Preauthorized Others @@ -70,7 +70,7 @@ Cross-currency only OK   - Cross-currency only1 + Cross-currency only 1 No Permission OK @@ -79,7 +79,7 @@ Cross-currency only OK   - Cross-currency only1 + Cross-currency only 1 XRP payments up to the minimum reserve OK @@ -88,7 +88,7 @@ Cross-currency only OK   - Cross-currency only1 + Cross-currency only 1 Balance changes from rippling OK @@ -97,7 +97,7 @@ Cross-currency only OK   - Cross-currency only1 + Cross-currency only 1 Balance changes from executing offers OK diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md index e1d4faa8e3..662db25f97 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.md +++ b/content/concepts/consensus-network/amendments/known-amendments.md @@ -551,7 +551,7 @@ This Amendment requires the [Flow Amendment](#flow) to be enabled. |:-----------------------------------------------------------------|:----------| | 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 | Enabled | -Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the [Interledger Protocol](https://interledger.org/). One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the batched content of many small Claims later, as long as it is within the expiration. +Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the [Interledger Protocol](https://interledger.org/). One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the combined content of many small Claims later, as long as it is within the expiration. Creates three new transaction types: [PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger object type, [PayChannel](paychannel.html). Defines an off-ledger data structure called a `Claim`, used in the ChannelClaim transaction. Creates new `rippled` API methods: [`channel_authorize`](channel_authorize.html) (creates a signed Claim), [`channel_verify`](channel_verify.html) (verifies a signed Claim), and [`account_channels`](account_channels.html) (lists Channels associated with an account). diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md index 5a1dfce24c..d2f5a25c76 100644 --- a/content/concepts/consensus-network/consensus.md +++ b/content/concepts/consensus-network/consensus.md @@ -41,13 +41,13 @@ Each ledger version also contains a set of transactions and metadata about those _Figure 3: Transactions Applied to Ledger Version_ -The set of transactions included in a ledger instance are recorded in that ledger and allow auditability of the XRP Ledger history. If an account balance is different in ledger N+1 than it was in ledger N, then ledger N+1 contains the transaction(s) responsible for the change. +The set of transactions included in a ledger instance are recorded in that ledger and allow audits of the XRP Ledger history. If an account balance is different in ledger N+1 than it was in ledger N, then ledger N+1 contains the transaction(s) responsible for the change. -Transactions that appear in a validated ledger may have succeeded in changing the ledger, or may have been processed without doing the requested action. Successful transactions have the **tesSUCCESS** [result code](transaction-results.html) which indicates the requested changes are applied to the ledger. Failed transactions in the ledger have **tec** class result codes.1 +Transactions that appear in a validated ledger may have succeeded in changing the ledger, or may have been processed without doing the requested action. Successful transactions have the **`tesSUCCESS`** [result code](transaction-results.html) which indicates the requested changes are applied to the ledger. Failed transactions in the ledger have **`tec`** class result codes.1 -All transactions included in a ledger destroy some XRP as a [transaction cost](transaction-cost.html), regardless of whether they had a **tes** or **tec** code. The exact amount of XRP to destroy is defined by the signed transaction instructions. +All transactions included in a ledger destroy some XRP as a [transaction cost](transaction-cost.html), regardless of whether they had a **`tes`** or **`tec`** code. The exact amount of XRP to destroy is defined by the signed transaction instructions. -In addition to the **tes** and **tec** class result codes, there are **ter**, **tef** and **tem** class codes. The latter three indicate provisional failures returned by API calls. Only **tes** and **tec** codes appear in ledgers. Transactions that are not included in ledgers cannot have any effect on the ledger state (including XRP balances), but transitions that provisionally failed may still end up succeeding. +In addition to the **`tes`** and **`tec`** class result codes, there are **`ter`**, **`tef`** and **`tem`** class codes. The latter three indicate provisional failures returned by API calls. Only **`tes`** and **`tec`** codes appear in ledgers. Transactions that are not included in ledgers cannot have any effect on the ledger state (including XRP balances), but transitions that provisionally failed may still end up succeeding. When working with [`rippled` APIs](rippled-api.html), applications must distinguish between candidate transactions proposed for inclusion in a ledger versus validated transactions which are included in a validated ledger. Only transaction results found in a validated ledger are immutable. A candidate transaction may or may not ever be included in a validated ledger. @@ -201,7 +201,7 @@ Best practices for applications submitting transactions include: 9 – In practice, the XRP Ledger runs more efficiently by starting a new round of consensus concurrently, before validation has completed. -10 – A `rippled` server can respond to API requests even without a complete ledger history. Interruptions in service or network connectivity can lead to missing ledgers, or gaps, in the server’s ledger history. Over time, if configured to, `rippled` fills in gaps in its history. When testing for missing transactions, it is important to verify against a server with continuous complete ledgers from the time the transaction was submitted until its LastLedgerSequence. Use the RPC server_state to determine which complete_ledgers are available to a particular server. +10 – A `rippled` server can respond to API requests even without a complete ledger history. Interruptions in service or network connectivity can lead to missing ledgers, or gaps, in the server’s ledger history. Over time, if configured to, `rippled` fills in gaps in its history. When testing for missing transactions, it is important to verify against a server with continuous complete ledgers from the time the transaction was submitted until its `LastLedgerSequence`. Use the [server_info method][] to determine which ledgers are available to a particular server. diff --git a/content/concepts/consensus-network/fee-voting.md b/content/concepts/consensus-network/fee-voting.md index 9e7c14c545..f1b48cb6b7 100644 --- a/content/concepts/consensus-network/fee-voting.md +++ b/content/concepts/consensus-network/fee-voting.md @@ -20,14 +20,14 @@ Every 256th ledger is called a "flag" ledger. (A flag ledger is defined such tha In the flag ledger itself, nothing happens, but validators receive and take note of the votes from other validators they trust. -After counting the votes of other validators, each validator attempts to compromise between its own preferences and the preferences of a majority of validators it trusts. (For example, if one validator wants to raise the minimum transaction cost from 10 to 100, but most validators only want to raise it from 10 to 20, the one validator settles on the change to raise the cost to 20. However, the one validator never settles on a value lower than 10 or higher than 100.) If a compromise is possible, the validator inserts a [SetFee pseudo-transaction](setfee.html) into its proposal for the ledger following the flag ledger. Other validators who want the same change insert the same SetFee pseudo-transaction into their proposals for the same ledger. (Validators whose preferences match the existing network settings do nothing.) If a SetFee psuedo-transaction survives the consensus process to be included in a validated ledger, then the new transaction cost and reserve settings denoted by the SetFee pseudo-transaction take effect starting with the following ledger. +After counting the votes of other validators, each validator attempts to compromise between its own preferences and the preferences of a majority of validators it trusts. (For example, if one validator wants to raise the minimum transaction cost from 10 to 100, but most validators only want to raise it from 10 to 20, the one validator settles on the change to raise the cost to 20. However, the one validator never settles on a value lower than 10 or higher than 100.) If a compromise is possible, the validator inserts a [SetFee pseudo-transaction](setfee.html) into its proposal for the ledger following the flag ledger. Other validators who want the same change insert the same SetFee pseudo-transaction into their proposals for the same ledger. (Validators whose preferences match the existing network settings do nothing.) If a SetFee pseudo-transaction survives the consensus process to be included in a validated ledger, then the new transaction cost and reserve settings denoted by the SetFee pseudo-transaction take effect starting with the following ledger. In short: * **Flag ledger -1**: Validators submit votes. * **Flag ledger**: Validators tally votes and decide what SetFee to include, if any. * **Flag ledger +1**: Validators insert SetFee pseudo-transaction into their proposed ledgers. -* **Flag ledger +2**: New settings take effect, if a SetFee psuedotransaction achieved consensus. +* **Flag ledger +2**: New settings take effect, if a SetFee pseudo-transaction achieved consensus. ## Maximum Fee Values diff --git a/content/concepts/consensus-network/transaction-malleability.md b/content/concepts/consensus-network/transaction-malleability.md index 5f5d80fcab..092d75e446 100644 --- a/content/concepts/consensus-network/transaction-malleability.md +++ b/content/concepts/consensus-network/transaction-malleability.md @@ -8,7 +8,7 @@ There are two circumstances that could lead to transaction malleability: 1. The transaction does not specify the tfFullyCanonicalSig flag on a transaction signed using the default signing algorithm (ECDSA with the secp256k1 curve). - **Use the [tfFullyCanonicalSig flag](transaction-common-fields.html#global-flags)** to guarantee that a transaction is not malleable in this way. Although transactions [signed with Ed25519 keys](cryptographic-keys.html#signing-algorithms) are not vulnerable to this problem, **there is no downside** to using this flag on _all_ transactions. + **Use the [`tfFullyCanonicalSig` flag](transaction-common-fields.html#global-flags)** to guarantee that a transaction is not malleable in this way. Although transactions [signed with Ed25519 keys](cryptographic-keys.html#signing-algorithms) are not vulnerable to this problem, **there is no downside** to using this flag on _all_ transactions. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions are protected against malleability regardless of the tfFullyCanonicalSig flag. diff --git a/content/concepts/decentralized-exchange/autobridging.md b/content/concepts/decentralized-exchange/autobridging.md index 3061f570ed..90673c8b73 100644 --- a/content/concepts/decentralized-exchange/autobridging.md +++ b/content/concepts/decentralized-exchange/autobridging.md @@ -8,7 +8,7 @@ Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment ## See Also -- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) +- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) - [Offer Preference](offers.html#offer-preference) diff --git a/content/concepts/decentralized-exchange/offers.md b/content/concepts/decentralized-exchange/offers.md index 1331af74dd..8ee582d4d6 100644 --- a/content/concepts/decentralized-exchange/offers.md +++ b/content/concepts/decentralized-exchange/offers.md @@ -32,14 +32,14 @@ An unfunded offer can stay on the ledger indefinitely, but it does not have any * It becomes fully claimed by a Payment or a matching OfferCreate transaction. * An OfferCancel or OfferCreate transaction explicitly cancels the offer. * An OfferCreate transaction from the same account crosses the earlier offer. (In this case, the older offer is automatically canceled.) -* An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook. +* An offer is found to be unfunded during transaction processing, typically because it was at the tip of the order book. * This includes cases where one side or the other of an offer is found to be closer to 0 than `rippled`'s precision supports. ### Tracking Unfunded Offers Tracking the funding status of all offers can be computationally taxing. In particular, addresses that are actively trading may have a large number of offers open. A single balance can affect the funding status of many offers to buy different currencies. Because of this, `rippled` does not proactively find and remove offers. -A client application can locally track the funding status of offers. To do this, first retreive an order book using the [book_offers method][] and check the `taker_gets_funded` field of offers. Then, [subscribe](subscribe.html) to the `transactions` stream and watch the transaction metadata to see which offers are modified. +A client application can locally track the funding status of offers. To do this, first retrieve an order book using the [book_offers method][] and check the `taker_gets_funded` field of offers. Then, [subscribe](subscribe.html) to the `transactions` stream and watch the transaction metadata to see which offers are modified. ## Offers and Trust diff --git a/content/concepts/decentralized-exchange/ticksize.md b/content/concepts/decentralized-exchange/ticksize.md index f4e417879b..e04fef6532 100644 --- a/content/concepts/decentralized-exchange/ticksize.md +++ b/content/concepts/decentralized-exchange/ticksize.md @@ -4,7 +4,7 @@ _(Added by the [TickSize amendment][].)_ When an Offer is placed into an order book, its exchange rate is truncated based on the `TickSize` values set by the issuers of the currencies involved in the Offer. When a trader offers to exchange XRP and an issued currency, the `TickSize` from the issuer of the currency applies. When a trader offers to exchange two issued currencies, the offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither currency has a `TickSize` set, the default behavior applies. -The `TickSize` value truncates the number of _significant digits_ in the exchange rate of an offer when it gets placed in an order book. Issuers can set `TickSize` to an integer from `3` to `15` using an [AccountSet transaction][]. The exchange rate is represented as significant digits and an exponent; the `TickSize` does not affect the exponent. This allows the XRP Ledger to represent exchange rates between assets that vary greatly in value (for example, a hyperinflated currency compared to a rare commodity). The lower the `TickSize` an issuer sets, the larger the increment traders must offer to be considered a higher exchange rate than the existing Offers. +The `TickSize` value truncates the number of _significant digits_ in the exchange rate of an offer when it gets placed in an order book. Issuers can set `TickSize` to an integer from `3` to `15` using an [AccountSet transaction][]. The exchange rate is represented as significant digits and an exponent; the `TickSize` does not affect the exponent. This allows the XRP Ledger to represent exchange rates between assets that vary greatly in value (for example, a highly inflated currency compared to a rare commodity). The lower the `TickSize` an issuer sets, the larger the increment traders must offer to be considered a higher exchange rate than the existing Offers. The `TickSize` does not affect the part of an Offer that can be executed immediately. (For that reason, OfferCreate transactions with `tfImmediateOrCancel` are unaffected by `TickSize` values.) If the Offer cannot be fully executed, the transaction processing engine calculates the exchange rate and truncates it based on `TickSize`. Then, the engine rounds the remaining amount of the Offer from the "less important" side to match the truncated exchange rate. For a default OfferCreate transaction (a "buy" Offer), the `TakerPays` amount (the amount being bought) gets rounded. If the `tfSell` flag is enabled (a "sell" Offer) the `TakerGets` amount (the amount being sold) gets rounded. diff --git a/content/concepts/introduction/intro-to-consensus.md b/content/concepts/introduction/intro-to-consensus.md index 98508152b2..9c1a1165cf 100644 --- a/content/concepts/introduction/intro-to-consensus.md +++ b/content/concepts/introduction/intro-to-consensus.md @@ -65,6 +65,6 @@ For a longer exploration of how the XRP Ledger Consensus Protocol responds to va 1. Due to a mishap early in the XRP Ledger's history, [ledgers 1 through 32569 were lost](http://web.archive.org/web/20171211225452/https://forum.ripple.com/viewtopic.php?f=2&t=3613). (This loss represents approximately the first week of ledger history.) Thus, ledger #32570 is the earliest ledger available anywhere. Because the XRP Ledger's state is recorded in every ledger version, the ledger can continue without the missing history. New test networks still start with ledger index 1. -2. In Bitcoin, the current state is sometimes called the set of "UTXOs" (unspent transaction outputs). Unlike the XRP Ledger, a Bitcoin server must download the entire transaction history to know the full set of UTXOs and process new transactions. As of 2018, there have been some proposals to modify Bitcoin's consensus mechanism to periodically summarize the latest UTXOs so new servers would not need to do this. Ethereum uses a similar approach to the XRP Ledger, with a summary of the current state (called a _state root_) in each block, but syncing takes longer because Ethereum stores a large amount of state data. +2. In Bitcoin, the current state is sometimes called the set of "UTXOs" (unspent transaction outputs). Unlike the XRP Ledger, a Bitcoin server must download the entire transaction history to know the full set of UTXOs and process new transactions. As of 2018, there have been some proposals to modify Bitcoin's consensus mechanism to periodically summarize the latest UTXOs so new servers would not need to do this. Ethereum uses a similar approach to the XRP Ledger, with a summary of the current state (called a _state root_) in each block, but syncing takes longer because Ethereum stores a large amount of state data. 3. A server does not need a direct connection to its trusted validators to hear from them. The XRP Ledger peer-to-peer network uses a _gossip protocol_ where servers identify each other by public keys and relay digitally-signed messages from others. diff --git a/content/concepts/introduction/software-ecosystem.md b/content/concepts/introduction/software-ecosystem.md index fa666865f8..c5a311537a 100644 --- a/content/concepts/introduction/software-ecosystem.md +++ b/content/concepts/introduction/software-ecosystem.md @@ -1,6 +1,6 @@ # Software Ecosystem -The XRP Ledger is home to a deep, layered ecosystem of software projects powering and enabling an Internet of Value. It's impossible to list every project, tool, and business that interacts with the XRP Ledger, so this page only lists a few categories and highlights some central projects that are documented here on [xrpl.org](https://xrpl.org). +The XRP Ledger is home to a deep, layered ecosystem of software projects powering and enabling an Internet of Value. It's impossible to list every project, tool, and business that interacts with the XRP Ledger, so this page only lists a few categories and highlights some central projects that are documented here on [xrpl.org](https://xrpl.org). ## Stack Levels @@ -8,7 +8,7 @@ The XRP Ledger is home to a deep, layered ecosystem of software projects powerin - The [basis of the XRP Ledger](#rippled-the-core-server) is a peer-to-peer network of always-on servers sharing transactions, engaging in the [consensus process](consensus.html) and processing [transactions](transaction-basics.html). Everything else in the XRP Ledger ecosystem is ultimately built on top of this peer-to-peer network, directly or indirectly. -- [_Programming Libraries_](#programming-libraries) exist in higher level software, where they are imported directly into program code, and contain premade implementations of routines to access the XRP Ledger. +- [_Programming Libraries_](#programming-libraries) exist in higher level software, where they are imported directly into program code, and contain methods to access the XRP Ledger. - [_Middleware_](#middleware) provides indirect access to XRP Ledger data. Applications in this layer frequently have their own data storage and processing. @@ -42,7 +42,7 @@ The [Data API](data-api.html) is an example of a middleware service on top of th ### Apps and Services -Atop the stack is where the truly exciting things happen. Apps and services provide a way for users and devices to connect to the XRP Ledger. At this level, [exchanges list XRP](list-xrp-in-your-exchange.html), [gateways issue other currencies](become-an-xrp-ledger-gateway.html) for use in the decentralized exchange, and wallets provide user interfaces for buying, selling, or just HODLing holding XRP. Many other possibilities exist, including additional services layered even higher. +Atop the stack is where the truly exciting things happen. Apps and services provide a way for users and devices to connect to the XRP Ledger. At this level, [exchanges list XRP](list-xrp-in-your-exchange.html), [gateways issue other currencies](become-an-xrp-ledger-gateway.html) for use in the decentralized exchange, and wallets provide user interfaces for buying, selling, or just HODLing holding XRP. Many other possibilities exist, including additional services layered even higher. A great way to build applications that are compatible with not only XRP but lots of other ways of denominating value is to use the [Interledger Protocol][] with settlement in XRP. diff --git a/content/concepts/introduction/technical-faq.md b/content/concepts/introduction/technical-faq.md index 3238eb44b3..e857e7b41c 100644 --- a/content/concepts/introduction/technical-faq.md +++ b/content/concepts/introduction/technical-faq.md @@ -25,7 +25,7 @@ They are the lists of transaction validators a given participant believes will n Since anybody can run a validator, the burden is on the network participants to choose a reliable set. Currently, Ripple provides a default and recommended list which we expand based on watching the history of validators operated by Ripple and third parties. Eventually, Ripple intends to remove itself from this process entirely by having network participants select their own lists based on publicly available data about validator quality. -#### If Ripple recommends adoption of its UNL, doesn’t that create a centralized system? +#### If Ripple recommends adoption of its UNL, doesn't that create a centralized system? No. The XRP Ledger network is opt-in. Each participant directly or indirectly chooses its UNL. Should Ripple stop operating or should Ripple act maliciously, participants could change their UNLs to continue using the XRP Ledger. @@ -51,9 +51,9 @@ In the process of determining the final, authoritative version of the ledger, th However, there will only be one authoritative ledger version at any given time; other versions are irrelevant and harmless. -#### Does the XRP Ledger utilize a formal validator onboarding process? +#### Does the XRP Ledger have a formal process for adding validators? -No, a formal validator onboarding process is not compatible with the XRP Ledger, as it is a system with no central authority. +No, a formal process for adding validators is not compatible with the XRP Ledger, because it is a system with no central authority. For recommendations and best practices, see [Run `rippled` as a Validator](run-rippled-as-a-validator.html). @@ -79,9 +79,9 @@ Ripple is committed to monitoring and reporting any AML flags across the XRP Led ## Security Concerns -#### What is Ripple’s process for reviewing third-party code contributions before they go live in the master codebase? +#### What is Ripple's process for reviewing third-party code contributions? -The code contribution process starts with a developer opening a pull request against Ripple's `rippled` repo. This pull request triggers automated unit and integration tests, as well as code reviews by several developers who, typically, have significant expertise in the area of code that the pull request is changing. +The code contribution process starts with a developer opening a [pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) to Ripple's `rippled` repo. This pull request triggers automated unit and integration tests, as well as code reviews by several developers who, typically, have significant expertise in the area of code that the pull request affects. Once the pull request passes automated tests and receives approvals from reviewers, a trusted [maintainer of the repo](https://opensource.guide/best-practices/) can stage it for inclusion in the next beta. @@ -89,13 +89,13 @@ Once the pull request passes automated tests and receives approvals from reviewe No, Ripple does not own or control the XRP Ledger or XRP Ledger network. -Ripple does publish a reference implementation of the core XRP Ledger server ([`rippled`](https://github.com/ripple/rippled)) and employs a team of engineers who contribute to the open-source codebase. Ripple also periodically publishes precompiled binary packages of the software as a convenience. Anyone is free to [download and compile the software from source](install-rippled.html), if they prefer. +Ripple does publish a reference implementation of the core XRP Ledger server ([`rippled`](https://github.com/ripple/rippled)) and employs a team of engineers who contribute to the open-source codebase. Ripple also periodically publishes pre-compiled binary packages of the software as a convenience. Anyone is free to [download and compile the software from source](install-rippled.html), if they prefer. You don't need to use Ripple’s version of the XRP Ledger software to interact with the XRP Ledger. `rippled` is open-source software and Ripple grants anyone the ability to use, extend, and modify it as long as they follow the terms of the [ISC license](https://github.com/ripple/rippled/blob/develop/LICENSE). The ISC License is very permissive compared to some other open-source licenses that strictly limit how you can extend and adapt the software. #### Does Ripple offer a secure method to download their software? -`rippled` source code is available at , where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers prebuilt binary packages for CentOS, RedHat Enterprise Linux, Fedora, Ubuntu, and Debian Linux. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the cryptographic hash values of the packages that are published. +`rippled` source code is available at , where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers pre-built binary packages for CentOS, RedHat Enterprise Linux, Fedora, Ubuntu, and Debian Linux. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the cryptographic hash values of the packages that are published. #### Does Ripple distinguish between the codebase for validation and the one for user software? @@ -107,6 +107,6 @@ Yes. Client software for the XRP Ledger, including ripple-lib, has a different c - [`rippled` codebase](https://github.com/ripple/rippled) - User software codebase: - - [ripple-lib](https://github.com/ripple/ripple-lib) - - [ripplecharts-frontend](https://github.com/ripple/ripplecharts-frontend) + - [`ripple-lib`](https://github.com/ripple/ripple-lib) + - [`ripplecharts-frontend`](https://github.com/ripple/ripplecharts-frontend) - [Ripple GitHub Organization](https://github.com/ripple/) diff --git a/content/concepts/introduction/xrp-ledger-overview.md b/content/concepts/introduction/xrp-ledger-overview.md index 7c93ec3a8a..39c92de0f8 100644 --- a/content/concepts/introduction/xrp-ledger-overview.md +++ b/content/concepts/introduction/xrp-ledger-overview.md @@ -8,7 +8,7 @@ XRP is a digital asset native to the XRP Ledger. Anyone with a cryptographic key - **[Censorship-Resistant Transaction Processing][]:** No single party decides which XRP transactions succeed or fail, and no one can "roll back" a transaction after it completes. As long as those who choose to participate in the network keep it healthy, they can send and receive XRP in seconds. - **[Fast, Efficient Consensus Algorithm][]:** The XRP Ledger's consensus algorithm settles transactions in 4 to 5 seconds, processing at a throughput of up to 1500 transactions per second. These properties put XRP at least an order of magnitude ahead of other top digital assets. -- **[Finite XRP Supply][]:** When the XRP Ledger began, 100 billion XRP were created, and no more XRP will ever be created. (Each XRP is subdivisible down to 6 decimal places, for a grand total of 100 quadrillion (10^17) _drops_ of XRP.) The available supply of XRP decreases slowly over time as small amounts are destroyed to pay transaction costs. +- **[Finite XRP Supply][]:** When the XRP Ledger began, 100 billion XRP were created, and no more XRP will ever be created. (Each XRP is divisible down to 6 decimal places, for a grand total of 100 quadrillion (10^17) _drops_ of XRP.) The available supply of XRP decreases slowly over time as small amounts are destroyed to pay transaction costs. - **[Responsible Software Governance][]:** A team of full-time, world-class developers at Ripple maintain and continually improve the XRP Ledger's underlying software. Ripple acts as a steward for the technology and an advocate for its interests, and builds constructive relationships with governments and financial institutions worldwide. - **[Secure, Adaptable Cryptography][]:** The XRP Ledger relies on industry standard digital signature systems like ECDSA (the same scheme used by Bitcoin) but also supports modern, efficient algorithms like Ed25519. The extensible nature of the XRP Ledger's software makes it possible to add and disable algorithms as the state of the art in cryptography advances. - **[Modern Features for Smart Contracts][]:** Features like Escrow, Checks, and Payment Channels support cutting-edge financial applications including the [Interledger Protocol](https://interledger.org/). This toolbox of advanced features comes with safety features like a process for amending the network and separate checks against invariant constraints. @@ -50,7 +50,7 @@ Alongside war and political turmoil, hyperinflation is one of the leading causes The supply of XRP available to the general public _does_ change due to a few factors: -- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with certain minimums based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](transaction-cost.html). +- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with the minimum based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](transaction-cost.html). - Each account in the XRP Ledger must hold a small amount of XRP in reserve. This is an anti-spam measure to disincentivize making the ledger data occupy too much space. XRP Ledger validators can vote to change the amount of XRP required as a reserve, to compensate for changes in XRP's real-world value. (The last time this happened was in December 2013, when [the reserve requirement decreased from 50 XRP to 20 XRP](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/).) If the reserve requirement decreases, XRP that was previously locked up by the reserve becomes available again. - Ripple (the company) holds a large reserve of XRP in escrow. At the start of each month, 1 billion XRP is released from escrow for Ripple to use. (Ripple uses XRP to incentivize growth in the XRP Ledger ecosystem and sells XRP to institutional investors. Ripple also sells XRP programmatically on exchanges, limited to a small percentage of overall exchange volume. Ripple publishes sales figures quarterly in the [XRP Markets Report](https://ripple.com/insights/q1-2018-xrp-markets-report/).) At the end of each month, any remaining XRP the company does not sell or give away is stored into escrow for a 54-month period. For more information on Ripple's escrow policy, see [Ripple Escrows 55 Billion XRP for Supply Predictability](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). For more information on the technical capabilities of the Escrow feature, see [Escrow](escrow.html). diff --git a/content/concepts/introduction/xrp.md b/content/concepts/introduction/xrp.md index 6c18bb7afa..29ee4def5b 100644 --- a/content/concepts/introduction/xrp.md +++ b/content/concepts/introduction/xrp.md @@ -2,7 +2,7 @@ **XRP** is the native cryptocurrency of the XRP Ledger. All [accounts](accounts.html) in the XRP Ledger can send XRP among one another and must hold a minimum amount of XRP as a [reserve](reserves.html). XRP can be sent directly from any XRP Ledger address to any other, without needing a gateway or liquidity provider. This helps make XRP a convenient bridge currency. -Some advanced features of the XRP Ledger, such as [Escrow](escrow.html) and [Payment Channels](use-payment-channels.html), only work with XRP. Order book [autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) uses XRP to deepen liquidity in the decentralized exchange by merging order books of two issued currencies with XRP order books to create synthetic combined order books. (For example, autobridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.) +Some advanced features of the XRP Ledger, such as [Escrow](escrow.html) and [Payment Channels](use-payment-channels.html), only work with XRP. Order book [auto-bridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) uses XRP to deepen liquidity in the decentralized exchange by merging order books of two issued currencies with XRP order books to create synthetic combined order books. (For example, auto-bridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.) XRP also serves as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to offset the costs of maintaining the XRP Ledger. The [transaction cost](transaction-cost.html) and [reserve](reserves.html) are neutral fees denominated in XRP and not paid to any party. In the ledger's data format, XRP is stored in [AccountRoot objects](accountroot.html). @@ -19,7 +19,7 @@ In technical contexts, XRP is measured precisely to the nearest 0.000001 XRP, ca ### XRP Sales -The XRP Ledger was built over 2011 – early 2012 by Jed McCaleb, Arthur Britto and David Schwartz. In September 2012, Jed and Arthur, along with Chris Larsen formed Ripple (the company, called OpenCoin Inc. at the time) and decided to gift 80 billion XRP to Ripple in exchange for Ripple developing on the XRP Ledger. Since then, the company has regularly sold XRP, used it to strengthen XRP markets and improve network liquidity, and incentivized development of the greater ecosystem. In 2017, the company [placed 55 billion XRP in escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/) to ensure that the amount entering the general supply [grows predictably](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/) for the foreseeable future. Ripple's [XRP Market Performance site](https://ripple.com/xrp/market-performance/) reports how much XRP the company has available and locked in escrow at present. +The XRP Ledger was built over 2011 – early 2012 by Jed McCaleb, Arthur Britto and David Schwartz. In September 2012, Jed and Arthur, along with Chris Larsen formed Ripple (the company, called OpenCoin Inc. at the time) and decided to gift 80 billion XRP to Ripple in exchange for Ripple developing on the XRP Ledger. Since then, the company has regularly sold XRP, used it to strengthen XRP markets and improve network liquidity, and incentivized development of the greater ecosystem. In 2017, the company [placed 55 billion XRP in escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/) to ensure that the amount entering the general supply [grows predictably](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/) for the foreseeable future. Ripple's [XRP Market Performance site](https://ripple.com/xrp/market-performance/) reports how much XRP the company has available and locked in escrow at present. ### Naming @@ -30,7 +30,7 @@ Originally, the XRP Ledger was called "Ripple" for the way the technology allowe | !["X" logo](assets/img/xrp-x-logo.png) | ![Triskelion](img/ripple-triskelion.png) | -The smallest, indivisible unit of XRP was named a "drop" at the suggestion of Ripple forum member ThePiachu. An early alternative term was a "jed", after Jed McCaleb. +The smallest, indivisible unit of XRP was named a "drop" at the suggestion of Ripple forum member ThePiachu. An early alternative term was a "jed", after Jed McCaleb. ## See Also diff --git a/content/concepts/payment-system-basics/accounts/accounts.md b/content/concepts/payment-system-basics/accounts/accounts.md index 4e95814431..cf4db6fc7d 100644 --- a/content/concepts/payment-system-basics/accounts/accounts.md +++ b/content/concepts/payment-system-basics/accounts/accounts.md @@ -4,7 +4,7 @@ An "Account" in the XRP Ledger represents a holder of XRP and a sender of [trans - An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` - **Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) (and developed a [codec](https://github.com/xrp-community/xrpl-tagged-address-codec) to support) a new **X**-address format that exchanges and wallets could use instead of [destination tags](source-and-destination-tags.html). These "packed" addresses start with an `X` instead of an `r`. For more information, see the [XRPL 𝗫-address format](https://xrpaddress.info/) site. + **Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) (and developed a [codec](https://github.com/xrp-community/xrpl-tagged-address-codec) to support) a new **X**-address format that exchanges and wallets could use instead of [destination tags](source-and-destination-tags.html). These "packed" addresses start with an `X` instead of an `r`. For more information, see the [XRPL X-address format](https://xrpaddress.info/) site. - An **XRP balance**. Some of this XRP is set aside for the [Reserve](reserves.html). - A **sequence number**, which helps make sure any transactions this account sends are applied in the correct order and only once each. To execute a transaction, the transaction's sequence number and its sender's sequence number must match. Then, as part of applying the transaction, the account's sequence number increases by 1. (See also: [Basic Data Types: Account Sequence](basic-data-types.html#account-sequence).) @@ -49,13 +49,13 @@ For more technical details of how to calculate an XRP Ledger address, see [Addre Some addresses have special meaning, or historical uses, in the XRP Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is effectively impossible to guess a secret key from only an address, any XRP possessed by black hole addresses is lost forever. -| Address | Name | Meaning | Black Hole? | -|-----------------------------|------|---------|-------------| -| rrrrrrrrrrrrrrrrrrrrrhoLvTp | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes | -| rrrrrrrrrrrrrrrrrrrrBZbvji | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](ripplestate.html) use this address as a placeholder for the issuer of a trust line balance. | Yes | -| rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value "masterpassphrase" which is [hard-coded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No | -| rrrrrrrrrrrrrrrrrNAMEtxvNvQ | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes | -| rrrrrrrrrrrrrrrrrrrn5RM1rHd | NaN Address | Previous versions of [ripple-lib](https://github.com/ripple/ripple-lib) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes | +| Address | Name | Meaning | Black Hole? | +|-------------------------------|------|---------|-------------| +| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes | +| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](ripplestate.html) use this address as a placeholder for the issuer of a trust line balance. | Yes | +| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No | +| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes | +| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Previous versions of [ripple-lib](https://github.com/ripple/ripple-lib) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes | ## Deletion of Accounts diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.ja.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.ja.md index 01129bbe83..2519ffed76 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.ja.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.ja.md @@ -180,7 +180,7 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ 2. 連結された（シード+ルートシーケンス）値の[SHA-512ハーフ][]を計算します。 - 3. 結果が有効なsecp265k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source") + 3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source") 有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。 @@ -205,7 +205,7 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ 2. 連結された値の[SHA-512ハーフ][]を計算します。 - 3. 結果が有効なsecp265k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。 + 3. 結果が有効なsecp256k1秘密鍵でない場合は、キーシーケンスを1増やし、アカウントの仲介銀行（機関）キーペアの導出をやり直します。 4. 有効なsecp256k1秘密鍵を使用して、secp256k1曲線で標準ECDSA公開鍵を導出し、仲介銀行（機関）公開鍵を導出します。（暗号化アルゴリズムの場合と同様に、可能な場合は必ず、公的に監査された既知の標準実装を使用します。例えば、[OpenSSL](https://www.openssl.org/)には、コア関数であるEd25519およびsecp256k1が実装されています。） diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md index 566c4ac07c..c6f53046a5 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md @@ -30,7 +30,7 @@ The response contains a key pair (a seed and a public key, in various formats) a **Seed** -A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual secret key (and public key) for an account. The `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](rippled-api.html) and some [other XRPL software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well. +A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual secret key (and public key) for an account. The `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](rippled-api.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well. Because the seed value is the basis for all the other information of an account, you must protect it very carefully. Anyone who has knows an address's seed value effectively has full control over that address. @@ -178,7 +178,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu 2. Calculate the [SHA-512Half][] of the concatenated (seed+root sequence) value. - 3. If the result is not a valid secp265k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source") + 3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source") A valid secp256k1 key must not be zero, and it must be numerically less than the _secp256k1 group order_. The secp256k1 group order is the constant value `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`. @@ -203,7 +203,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu 2. Calculate the [SHA-512Half][] of the concatenated value. - 3. If the result is not a valid secp265k1 secret key, increment the key sequence by 1 and restart deriving the account's intermediate key pair. + 3. If the result is not a valid secp256k1 secret key, increment the key sequence by 1 and restart deriving the account's intermediate key pair. 4. With a valid secp256k1 secret key, use the standard ECDSA public key derivation with the secp256k1 curve to derive the intermediate public key. (As always with cryptographic algorithms, use a standard, well-known, publicly-audited implementation whenever possible. For example, [OpenSSL](https://www.openssl.org/) has implementations of core Ed25519 and secp256k1 functions.) diff --git a/content/concepts/payment-system-basics/accounts/depositauth.md b/content/concepts/payment-system-basics/accounts/depositauth.md index fff25ea0a7..acb50d41a7 100644 --- a/content/concepts/payment-system-basics/accounts/depositauth.md +++ b/content/concepts/payment-system-basics/accounts/depositauth.md @@ -24,7 +24,7 @@ To receive money from [Payment transactions][] when you have Deposit Authorizati To get the full effect of Deposit Authorization, Ripple recommends also doing the following: - Always maintain an XRP balance higher than the minimum [reserve requirement](reserves.html). -- Keep the DefaultRipple flag in its default (disabled) state. Do not enable [rippling](rippling.html) on any trust lines. When sending TrustSet transactions, always use the [`tfSetNoRipple` flag](trustset.html). +- Keep the `DefaultRipple` flag in its default (disabled) state. Do not enable [rippling](rippling.html) on any trust lines. When sending [TrustSet transactions][], always use the [`tfSetNoRipple` flag](trustset.html). - Do not place [Offers](offercreate.html). It is impossible to know in advance which matching offers will be consumed to execute such a trade. ## Precise Semantics @@ -63,7 +63,7 @@ An account can enable deposit authorization by sending an [AccountSet transactio To see whether an account has Deposit Authorization enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](accountroot.html). -If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (0x01000000) is nonzero, then the account has DepositAuth enabled. If the result is zero, then the account has DepositAuth disabled. +If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (`0x01000000`) is nonzero, then the account has DepositAuth enabled. If the result is zero, then the account has DepositAuth disabled. ## Preauthorization diff --git a/content/concepts/payment-system-basics/accounts/reserves.md b/content/concepts/payment-system-basics/accounts/reserves.md index e7f6968841..1e628db903 100644 --- a/content/concepts/payment-system-basics/accounts/reserves.md +++ b/content/concepts/payment-system-basics/accounts/reserves.md @@ -21,7 +21,7 @@ Many objects in the ledger are owned by a particular address, and count toward t - [Offers](offer.html) are owned by the address that placed them. Transaction processing automatically removes Offers that are fully consumed or found to be unfunded. Alternatively, the owner can cancel an Offer by sending an [OfferCancel transaction][], or by sending an [OfferCreate transaction][] that contains an `OfferSequence` parameter. - [Trust lines](ripplestate.html) are shared between two addresses. The owner reserve can apply to one or both of the addresses, depending on whether the fields that address controls are in their default state. See [Contributing to the Owner Reserve](ripplestate.html#contributing-to-the-owner-reserve) for details. -- Without the [MultiSignReserve amendment][], a single [SignerList](signerlist.html) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. With the [MultiSignReserve amendment][] enabled, a single SignerList counts as 1 object for purposes of the owner reserve, regardless of the number of members it has. See also: [SignerLists and Reserves](signerlist.html#signerlists-and-reserves). +- Without the [MultiSignReserve amendment][], a single [SignerList](signerlist.html) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. With the [MultiSignReserve amendment][] enabled, a single SignerList counts as 1 object for purposes of the owner reserve, regardless of the number of members it has. See also: [Signer Lists and Reserves](signerlist.html#signerlists-and-reserves). - [Held Payments (Escrow)](escrow-object.html) are owned by the address that placed them. - [Payment Channels](use-payment-channels.html) are owned by the address that created them. - [Owner directories](directorynode.html) list all the ledger objects that contribute to an address's owner reserve. However, the owner directory itself does not count towards the reserve. diff --git a/content/concepts/payment-types/cross-currency-payments.md b/content/concepts/payment-types/cross-currency-payments.md index 93655fa1a8..fdec998f13 100644 --- a/content/concepts/payment-types/cross-currency-payments.md +++ b/content/concepts/payment-types/cross-currency-payments.md @@ -13,11 +13,11 @@ By default, cross-currency payments deliver a fixed amount to their destination - There must be at least one [Path](paths.html) between the sender and receiver, and the total liquidity across all paths must be enough to facilitate the payment. Cross-currency payments convert from one currency to another by consuming [Offers](offers.html) in the XRP Ledger's decentralized exchange. -## Autobridging +## Auto-Bridging Cross-currency payments that exchange two issued currencies automatically use XRP, when it decreases the cost of the payment, by connecting order books to deepen the pool of available liquidity. For example, a payment sending from USD to MXN automatically converts USD to XRP and then XRP to MXN if doing so is cheaper than converting USD to MXN directly. -For more information, see [Autobridging](autobridging.html). +For more information, see [Auto-Bridging](autobridging.html). ## See Also 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/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/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** | ![1 byte: high 4 bits define type; low 4 bits define field.](img/field-id-common-type-common-field.png) | ![2 bytes: low 4 bits of the first byte define field; next byte defines type.](img/field-id-uncommon-type-common-field.png) | -| **Field Code >= 16** | ![2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field](img/field-id-common-type-uncommon-field.png) | ![3 bytes: first byte is 0x00, second byte defines type; third byte defines field](img/field-id-uncommon-type-uncommon-field.png) | +| **Field Code >= 16** | ![2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field](img/field-id-common-type-uncommon-field.png) | ![3 bytes: first byte is `0x00`, second byte defines type; third byte defines field](img/field-id-uncommon-type-uncommon-field.png) | 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/peer-crawler.md b/content/references/rippled-api/peer-crawler.md index d81fb93ab6..b97157f778 100644 --- a/content/references/rippled-api/peer-crawler.md +++ b/content/references/rippled-api/peer-crawler.md @@ -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/public-rippled-methods/public-rippled-methods.md b/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md index e1372db33b..503044848a 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 @@ -20,7 +20,7 @@ An account in the XRP Ledger represents a holder of XRP and a sender of transact ## [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/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-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..83a1881854 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#signerlists-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..38b5007f4e 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_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..6ee826b9b3 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 @@ -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/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/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..90fb0127cf 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#signerentry-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..7b9349e0b2 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md @@ -39,13 +39,13 @@ 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 | Blocks rippling between two trust lines 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 No Ripple on the trust line. | +| `tfClearNoRipple` | `0x00040000` | 262144 | Clears the No-Rippling flag. (See [No Ripple](rippling.html) for details.) | +| `tfSetFreeze` | `0x00100000` | 1048576 | [Freeze](freezes.html) the trustline. | +| `tfClearFreeze` | `0x00200000` | 2097152 | [Unfreeze](freezes.html) the trustline. | 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. diff --git a/content/references/rippled-api/validator-list.md b/content/references/rippled-api/validator-list.md index f4575d9ee4..451298b1c0 100644 --- a/content/references/rippled-api/validator-list.md +++ b/content/references/rippled-api/validator-list.md @@ -47,15 +47,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. diff --git a/content/references/xrp-ledger-toml.md b/content/references/xrp-ledger-toml.md index c138d46a4b..f42fd413df 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" @@ -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,7 +336,7 @@ 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 @@ -352,7 +352,7 @@ 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. @@ -361,4 +361,4 @@ Either of these two links, on their own, SHOULD NOT be considered authoritative. ## 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/manage-account-settings/offline-account-setup.md b/content/tutorials/manage-account-settings/offline-account-setup.md index 56462765f3..335d3d829e 100644 --- a/content/tutorials/manage-account-settings/offline-account-setup.md +++ b/content/tutorials/manage-account-settings/offline-account-setup.md @@ -65,7 +65,7 @@ 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. 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..b627c98263 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 @@ -9,7 +9,7 @@ Use these steps to manually connect your server to a specific [peer](peer-protoc - 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 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/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..80805b70f8 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,7 +6,7 @@ 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. @@ -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/server-doesnt-sync.md b/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.md index 66d7aad461..dd28bfa4a4 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 @@ -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..15b2942551 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 @@ -138,7 +138,7 @@ These two types of messages often occur together, when a long-running job causes 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: @@ -296,6 +296,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/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md index 7193180a84..acba69d38b 100644 --- a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md +++ b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md @@ -341,7 +341,7 @@ For more information, see [Source and Destination Tags](source-and-destination-t Historically, Ripple (the company) issued gateway bulletins to introduce new features or discuss topics related to compliance and risk. Gateway Bulletins are listed here in reverse chronological order. -- May 13, 2015 - [GB-2015-06 Gateway Bulletin: Corrections to Autobridging (PDF)](assets/pdf/GB-2015-06.pdf) +- May 13, 2015 - [GB-2015-06 Gateway Bulletin: Corrections to Autobridging (PDF)](assets/pdf/GB-2015-06.pdf) - April 17, 2015 - [GB-2015-05 Historical Ledger Query Migration](assets/pdf/GB-2015-05.pdf) - March 13, 2015 - [GB-2015-04 Action Required: Default Ripple Flag (PDF)](https://ripple.com/files/GB-2015-04.pdf) - March 3, 2015 - [GB-2015-03 Gateway Advisory: FinCEN Ruling on MoneyGram Compliance Program (PDF)](https://ripple.com/files/GB-2015-03.pdf) diff --git a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md index 5b34e473f7..9b7f3ec052 100644 --- a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md +++ b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md @@ -74,7 +74,7 @@ To follow Ripple's recommended best practices, Alpha Exchange should create at l * The malicious actor could issue currency in the XRP Ledger by using the cold wallet, but that currency should not be valued by anyone (unless the exchange explicitly stated it was also a gateway). - * If a malicious actor sets the asfRequireAuth flag for the account, that cannot be unset, although this only relates to issuing currency and should not affect an exchange that is not also a gateway. Any other settings a malicious actor sets or unsets with a master key can be reverted. + * If a malicious actor sets the asfRequireAuth flag for the account, that cannot be unset, although this only relates to issuing currency and should not affect an exchange that is not also a gateway. Any other settings a malicious actor changes with a master key can be reverted. * One or more [_hot wallets_](issuing-and-operational-addresses.html#operational-addresses) to conduct the day-to-day business of managing customers' XRP withdrawals and deposits. For example, with a hot wallet, exchanges can securely support these types of automated XRP transfers. Hot wallets need to be online to service instant withdrawal requests. diff --git a/content/use-cases/list-xrp-in-your-exchange.md b/content/use-cases/list-xrp-in-your-exchange.md index 7f96f0836f..3951825bf2 100644 --- a/content/use-cases/list-xrp-in-your-exchange.md +++ b/content/use-cases/list-xrp-in-your-exchange.md @@ -59,4 +59,4 @@ To support listing XRP, code integrations with the XRP Ledger to deposit XRP int - [Capacity Planning](capacity-planning.html) - [Look Up an XRP Ledger Account’s Transaction History](tx_history.html) - \ No newline at end of file + diff --git a/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md b/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md index b5385ac846..89a64a99f4 100644 --- a/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md +++ b/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md @@ -118,11 +118,11 @@ Consider a series of claims prompted by payer exchange customers withdrawing XRP **Public key**: `023D9BFCC22FB9A997E45ACA0D2D679A6A1AE5589E51546F3EDC4E9B16713FC255` -| Sequence | Signature | Amount | Destination Tag | -|:---------|:------------------|:-------|:----------------| -| 1 | 3045022100CE6E... | 2000 | 12345678 | -| 2 | 304402200C304A... | 3000 | 23456781 | -| 3 | 30450221009849... | 4000 | 34567812 | +| Sequence | Signature | Amount | Destination Tag | +|:---------|:--------------------|:-------|:----------------| +| 1 | `3045022100CE6E...` | 2000 | 12345678 | +| 2 | `304402200C304A...` | 3000 | 23456781 | +| 3 | `30450221009849...` | 4000 | 34567812 | | Claim Information | Purpose | |:--------------------|:-------------------------------------------------------| diff --git a/content/use-cases/use-cases.md b/content/use-cases/use-cases.md index c8404449f6..33402f6a40 100644 --- a/content/use-cases/use-cases.md +++ b/content/use-cases/use-cases.md @@ -1,6 +1,6 @@ # Use Cases -Use these roadmaps to walk you, task-by-task, through implementing your use case. +Use these instructions to walk you, step-by-step, through implementing your use case. Here are some of our users' most popular use cases: diff --git a/dactyl-config.yml b/dactyl-config.yml index 69c62815d3..2f55dd6702 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -70,6 +70,8 @@ targets: github_branch: master link_subs: "./src/api-v3/paths/preparations/payments.ts": "https://github.com/xpring-eng/xrp-api/blob/master/src/api-v3/paths/preparations/payments.ts" + readability_goals: + flesch_reading_ease: 50 # or higher - name: ja lang: ja @@ -5910,6 +5912,7 @@ pages: funnel: Docs doc_type: References supercategory: XRP-API + skip_spell_checker: true filters: - xrpapi_readme targets: @@ -5924,6 +5927,7 @@ pages: funnel: Docs doc_type: References supercategory: XRP-API + skip_spell_checker: true targets: - en - ja @@ -5939,6 +5943,7 @@ pages: doc_type: References category: RippleAPI for JavaScript blurb: Official client library to the XRP Ledger. Available for JavaScript only. + skip_spell_checker: true # Japanese: XRP Ledgerに対する公式なクライアントライブラリです。JavaScriptのみで使用できます。 curated_anchors: - name: Transactions @@ -6312,3 +6317,4 @@ known_broken_links: word_substitutions_file: tool/word_substitutions.yaml phrase_substitutions_file: tool/phrase_substitutions.yaml +spelling_file: tool/spelling.txt diff --git a/tool/spelling.txt b/tool/spelling.txt new file mode 100644 index 0000000000..02ed2224bb --- /dev/null +++ b/tool/spelling.txt @@ -0,0 +1,390 @@ +1st +2nd +3rd +256th +absconds +aren't +asynchronously +atomically +avatar +backend +backfilling +backfills +billionths +bitcoin +bitwise +blockchain +blog +breakpoints +callback +callbacks +canceled +canceling +cannot +centos +codebase +colocation +commandline +concatenate +concatenated +cryptocurrencies +cryptocurrency +cryptographic +cryptographically +csv +datacenter +ddos +debian +debug +decrypt +denominate +denominating +deserializing +disincentivize +disincentivizes +doesn't +downloads +dvd +emailing +encrypt +endian +enum +enums +escrowed +escrows +ethereum +expirations +failover +faq +faucets +filesystem +fillable +firewall +firewalls +fulfills +gapped +geolocation +gigabit +github +google +haven't +hardcoded +hashed +hashes +hasn't +hbase +hostname +html +http +https +hyperthreading +i'll +incentivize +incentivized +idempotency +immutably +instantiates +instantiating +integration +integrations +internationalized +invalidly +ipv4 +ipv6 +isn't +iterating +firefox +javascript +json +linux +loopback +lowercase +maintainer +malware +metadata +mitigations +modulo +namespace +nonces +npm +onboarding +openssl +outages +overwriting +paginate +paginated +passphrase +placeholder +preauthorization +preauthorizations +preauthorize +preauthorized +preauthorizing +prefixing +preimage +prioritizes +programmatically +pseudocode +quadrillion +reactively +reattach +rebalance +rebalancing +recalculate +recomputes +reconfigure +reconfiguring +reconnecting +reconnects +redhat +refunding +renumbering +reorders +resubmitting +retriable +retries +retried +retrying +rhel +roadmaps +sandbox +serialize +serialized +serializing +sharding +smartphone +spamming +sqlite +subdomain +subfolder +subfolders +supermajority +svg +synced +synchronizing +syncing +syncs +systemd +tbd +terabyte +terabytes +that'll +they'll +they're +they've +timeline +timeout +timeouts +timestamp +timestamps +toml +tradeoff +tradeoffs +triskelion +troubleshoot +truncates +typos +ubuntu +unauthorize +uncomment +undesirably +unencrypted +unfavorable +unicode +uninstall +unintuitively +unmount +unscaled +unset +unsets +unsubscribe +untrusted +upload +uppercase +url +urls +utc +validator +versioning +wasn't +we'll +won't +website +websites +websocket +whitespace +workaround +writable +wss +xeon +xml +you'll +you're +you've +zeroes + +btc +cny +eur +mxn +usd +xrp + +hash128 +hash160 +hash256 +uint16 +uint256 +uint32 +uint64 +uint8 + +512half +account_channels +account_currencies +account_info +account_lines +account_objects +account_offers +account_one +account_tx +account_zero +accountdelete +accountid +accountroot +accountset +altnet +altnets +autobridging +base58 +base58check +base64 +book_offers +can_delete +channel_authorize +channel_verify +checkcancel +checkcash +checkcreate +consensus_info +cors +crawl_shards +crypto +cryptoconditionssuite +deletableaccounts +deposit_authorized +depositauth +depositpreauth +demurrage +demurraging +devnet +directorynode +download_shard +ecdsa +ecmascript +ed25519 +eddsa +enableamendment +enforceinvariants +escrowcancel +escrowcreate +escrowfinish +etl +feeescalation +feesettings +fetch_info +fincen +fix1201 +fix1368 +fix1373 +fix1512 +fix1513 +fix1515 +fix1523 +fix1528 +fix1543 +fix1571 +fix1578 +fix1623 +fix1781 +fixcheckthreading +fixmasterkeyasregularkey +fixpaychanrecipientownerdir +fixqualityupperbound +fixtakerdryofferremoval +flowcross +flowv2 +gateway_balances +get_counts +gravatar +grpc +hmac +interledger +kyc +ledger_accept +ledger_cleaner +ledger_closed +ledger_current +ledger_entry +ledger_request +ledgerhashes +log_level +logrotate +lz4 +mainnet +md5 +multisign +multisigning +multisignreserve +nginx +noripple +nudb +ownerpaysfee +path_find +pathfinding +paychan +paychannel +paymentchannelclaim +paymentchannelcreate +paymentchannelfund +peer_reservations_add +peer_reservations_del +peer_reservations_list +offercancel +offercreate +requirefullycanonicalsig +ripemd160 +ripple_path_find +rippleapi +ripplestate +rocksdb +rtxp +secp256k1 +semver +server_info +server_state +setfee +setregularkey +shamapv2 +shor +sign_for +signerlist +signerlistset +submit_multisigned +suspay +testnet +ticksize +transaction_entry +trustset +trustsetauth +tx_history +unl +unls +wallet_propose +v0 +validation_create +validation_seed +validator_info +validator_list_sites +xpring +xrpchat From 2652c8832ad0a451cfde84f52aea0644a2dc6c1e Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 23 Jul 2020 20:34:51 -0700 Subject: [PATCH 34/65] Spelling - more fixes, additions --- .../issued-currencies-overview.md | 4 +- .../trust-lines-and-issuing.md | 2 +- .../accounts/accounts.md | 5 +- .../accounts/cryptographic-keys.md | 6 +- .../accounts/depositauth.md | 2 +- .../concepts/payment-system-basics/ledgers.md | 2 +- .../source-and-destination-tags.md | 2 +- .../transaction-basics/transaction-cost.md | 4 +- content/concepts/payment-types/checks.md | 3 +- .../payment-types/direct-xrp-payments.md | 4 +- content/concepts/payment-types/escrow.md | 7 +- .../payment-types/partial-payments.md | 4 +- .../payment-types/payment-channels.md | 4 +- .../logrotate.md | 2 +- .../ledger-data-formats/ledger-header.md | 2 +- .../ledger-object-types/accountroot.md | 32 ++++---- .../ledger-object-types/amendments.md | 6 +- .../ledger-object-types/directorynode.md | 12 +-- .../ledger-object-types/escrow.md | 26 +++---- .../ledger-object-types/ledgerhashes.md | 4 +- .../ledger-object-types/offer.md | 10 +-- .../ledger-object-types/paychannel.md | 2 +- .../ledger-object-types/ripplestate.md | 36 ++++----- .../ledger-object-types/signerlist.md | 34 ++++----- .../account-methods/account_lines.md | 2 +- .../account-methods/noripple_check.md | 6 +- .../ledger-methods/ledger.md | 4 +- .../ledger-methods/ledger_data.md | 8 +- .../book_offers.md | 4 +- .../path-and-order-book-methods/path_find.md | 14 ++-- .../public-rippled-methods.md | 2 +- .../server-info-methods/server_info.md | 4 +- .../server-info-methods/server_state.md | 2 +- .../subscription-methods/subscribe.md | 14 ++-- .../transaction-common-fields.md | 60 +++++++-------- .../transaction-results/tel-codes.md | 2 +- .../transaction-results.md | 16 ++-- .../transaction-types/accountset.md | 76 +++++++++---------- .../transaction-types/checkcreate.md | 2 +- .../transaction-types/offercancel.md | 8 +- .../transaction-types/payment.md | 48 ++++++------ .../transaction-types/trustset.md | 12 ++- .../configure-history-sharding.md | 2 + .../run-rippled-as-a-validator.md | 4 +- .../use-a-peer-reservation.md | 2 +- .../installation/build-run-rippled-macos.md | 2 +- .../installation/build-run-rippled-ubuntu.md | 2 +- .../installation/capacity-planning.md | 20 ++--- .../installation/install-rippled-on-ubuntu.md | 2 +- .../installation/system-requirements.md | 8 +- .../update-rippled-automatically-on-linux.md | 2 +- ...-new-genesis-ledger-in-stand-alone-mode.md | 2 +- .../troubleshooting/diagnosing-problems.md | 4 +- .../cash-a-check-for-a-flexible-amount.md | 4 +- .../send-a-conditionally-held-escrow.md | 6 +- .../use-payment-channels.md | 16 ++-- .../list-xrp-as-an-exchange.md | 16 ++-- .../list-your-exchange-on-xrp-charts.md | 2 +- tool/spelling.txt | 44 +++++++---- 59 files changed, 329 insertions(+), 308 deletions(-) diff --git a/content/concepts/issued-currencies/issued-currencies-overview.md b/content/concepts/issued-currencies/issued-currencies-overview.md index d367263afe..6f02d738a7 100644 --- a/content/concepts/issued-currencies/issued-currencies-overview.md +++ b/content/concepts/issued-currencies/issued-currencies-overview.md @@ -1,6 +1,6 @@ # Issued Currencies Overview -All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "issuances" or "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. +All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [NoRipple flag](rippling.html) on trust lines to prevent those trust lines from rippling. @@ -10,7 +10,7 @@ In the typical model, an issued currency is tied to holdings of currency or othe There are other use cases for issued currencies in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer. -**Warning:** ICOs may be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. +**Warning:** ICOs may be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. Ripple strongly recommends researching the relevant regulations before engaging in any financial service business. diff --git a/content/concepts/issued-currencies/trust-lines-and-issuing.md b/content/concepts/issued-currencies/trust-lines-and-issuing.md index b94a684248..7a839bb786 100644 --- a/content/concepts/issued-currencies/trust-lines-and-issuing.md +++ b/content/concepts/issued-currencies/trust-lines-and-issuing.md @@ -16,7 +16,7 @@ Trust lines are represented in the ledger's state data as [RippleState objects]( A trust line with settings in the default state is equivalent to no trust line. -The default state of all trust line flags is off, except for the [NoRipple flag](rippling.html), whose default state depends on the DefaultRipple flag. +The default state of all trust line flags is off, except for the [No Ripple flag](rippling.html), whose default state depends on the `DefaultRipple` flag. ## See Also diff --git a/content/concepts/payment-system-basics/accounts/accounts.md b/content/concepts/payment-system-basics/accounts/accounts.md index cf4db6fc7d..dcafa72758 100644 --- a/content/concepts/payment-system-basics/accounts/accounts.md +++ b/content/concepts/payment-system-basics/accounts/accounts.md @@ -2,10 +2,7 @@ An "Account" in the XRP Ledger represents a holder of XRP and a sender of [transactions](transaction-formats.html). The core elements of an account are: -- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` - - **Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) (and developed a [codec](https://github.com/xrp-community/xrpl-tagged-address-codec) to support) a new **X**-address format that exchanges and wallets could use instead of [destination tags](source-and-destination-tags.html). These "packed" addresses start with an `X` instead of an `r`. For more information, see the [XRPL X-address format](https://xrpaddress.info/) site. - +- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`. (This is a "classic address", as opposed to the [X-Address format](#addresses).) - An **XRP balance**. Some of this XRP is set aside for the [Reserve](reserves.html). - A **sequence number**, which helps make sure any transactions this account sends are applied in the correct order and only once each. To execute a transaction, the transaction's sequence number and its sender's sequence number must match. Then, as part of applying the transaction, the account's sequence number increases by 1. (See also: [Basic Data Types: Account Sequence](basic-data-types.html#account-sequence).) - A **history of transactions** that affected this account and its balances. diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md index c6f53046a5..16a1a7fe64 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md @@ -42,9 +42,11 @@ The `wallet_propose` response does not explicitly list the secret key value, als The `public_key` and `public_key_hex` both represent the same public key value. The public key is derived from the secret key as part of key derivation. The public key makes it possible to verify the authenticity of a transaction signature, but not to create more signatures. -**account_id** +**Account ID** -The `account_id` is [derived from the public key](accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account. +The `account_id` is [derived from the public key](accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. Typically, an Account ID is encoded in [base58][] to make a "classic address", but other representations are possible, including hexadecimal. The [X-Address format](accounts.html#addresses) combines an Account ID and a [Destination Tag](source-and-destination-tags.html) into a single address. + +It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account. The `account_id` (without a funded account) can, however, be used as a [regular key](#regular-key-pair) or a [member of a signer list](multi-signing.html) to authorize transactions for another account that does exist. diff --git a/content/concepts/payment-system-basics/accounts/depositauth.md b/content/concepts/payment-system-basics/accounts/depositauth.md index acb50d41a7..2c34907cfb 100644 --- a/content/concepts/payment-system-basics/accounts/depositauth.md +++ b/content/concepts/payment-system-basics/accounts/depositauth.md @@ -43,7 +43,7 @@ An account with Deposit Authorization enabled: - **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Added by the [Checks amendment][].)_ - **Can** receive XRP or issued currencies by sending [OfferCreate transactions][]. - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions. -- If the account has created any trust lines without the [NoRipple flag](rippling.html) enabled, or has enabled the DefaultRipple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. +- If the account has created any trust lines without the [NoRipple flag](rippling.html) enabled, or has enabled the `DefaultRipple` flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. - In general, an account in the XRP Ledger **cannot** receive any non-XRP currencies in the XRP Ledger as long as all of the following are true. (This rule is not specific to the DepositAuth flag.) - The account has not created any trust lines with a nonzero limit. - The account has not issued currency on trust lines created by others diff --git a/content/concepts/payment-system-basics/ledgers.md b/content/concepts/payment-system-basics/ledgers.md index 93c0d7b298..1dc235ff3b 100644 --- a/content/concepts/payment-system-basics/ledgers.md +++ b/content/concepts/payment-system-basics/ledgers.md @@ -17,7 +17,7 @@ A single ledger version consists of several parts: ## Tree Format -As its name might suggest, a ledger's state tree is a tree data structure. Each object in the state tree is identified by a 256-bit object ID. In JSON, a ledger object's ID is the `index` field, which contains a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every object in the state tree has an ID that you can use to look up that object; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (ID) of a ledger object with the [`ledger_index` (sequence number) of a ledger][Ledger Index]. +As its name might suggest, a ledger's state tree is a tree data structure. Each object in the state tree is identified by a 256-bit object ID. In JSON, a ledger object's ID is the `index` field, which contains a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every object in the state tree has an ID that you can use to look up that object; every transaction has an identifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (ID) of a ledger object with the [`ledger_index` (sequence number) of a ledger][Ledger Index]. **Tip:** Sometimes, an object in the ledger's state tree is called a "ledger node". For example, transaction metadata returns a list of `AffectedNodes`. Do not confuse this with a "node" (server) in the peer-to-peer network. diff --git a/content/concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md b/content/concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md index 9e3dd0bf8d..634768d323 100644 --- a/content/concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md +++ b/content/concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md @@ -30,7 +30,7 @@ Assigning tags in numerical order provides less privacy to customers. Since all ## Requiring Tags -For an XRP Ledger address that may receive payments intended for several customer accounts, receiving a payment _without_ a destination tag can be a problem: it is not immediately obvious which customer to credit, which can require a manual intervention and a discussion with the sender to figure out who was the intended recipient. To reduce cases like this, you can [enable the RequireDest setting](require-destination-tags.html). That way, if a user forgets to include a destination tag in a payment, the XRP Ledger rejects their payment instead of giving you money you don't know what to do with. The user can then send the payment again, using the tag as they should have. +For an XRP Ledger address that may receive payments intended for several customer accounts, receiving a payment _without_ a destination tag can be a problem: it is not immediately obvious which customer to credit, which can require a manual intervention and a discussion with the sender to figure out who was the intended recipient. To reduce cases like this, you can [enable the `RequireDest` setting](require-destination-tags.html). That way, if a user forgets to include a destination tag in a payment, the XRP Ledger rejects their payment instead of giving you money you don't know what to do with. The user can then send the payment again, using the tag as they should have. ## See Also diff --git a/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md b/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md index b0a64b1910..be9c8baad4 100644 --- a/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md +++ b/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md @@ -139,11 +139,11 @@ When a transaction has already been distributed to the network, but the account ## Key Reset Transaction -As a special case, an account can send a [SetRegularKey](setregularkey.html) transaction with a transaction cost of `0`, as long as the account's [lsfPasswordSpent flag](accountroot.html) is disabled. This transaction must be signed by the account's _master key pair_. Sending this transaction enables the lsfPasswordSpent flag. +As a special case, an account can send a [SetRegularKey](setregularkey.html) transaction with a transaction cost of `0`, as long as the account's [`lsfPasswordSpent` flag](accountroot.html) is disabled. This transaction must be signed by the account's _master key pair_. Sending this transaction enables the `lsfPasswordSpent` flag. This feature is designed to allow you to recover an account if the regular key is compromised, without worrying about whether the compromised account has any XRP available. This way, you can regain control of the account before you send more XRP to it. -The [lsfPasswordSpent flag](accountroot.html) starts out disabled. It gets enabled when you send a SetRegularKey transaction signed by the master key pair. It gets disabled again when the account receives a [Payment](payment.html) of XRP. +The [`lsfPasswordSpent` flag](accountroot.html) starts out disabled. It gets enabled when you send a SetRegularKey transaction signed by the master key pair. It gets disabled again when the account receives a [Payment](payment.html) of XRP. When the [FeeEscalation amendment][] is enabled, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero. diff --git a/content/concepts/payment-types/checks.md b/content/concepts/payment-types/checks.md index e6f383b783..b548ea1f63 100644 --- a/content/concepts/payment-types/checks.md +++ b/content/concepts/payment-types/checks.md @@ -29,7 +29,7 @@ Checks potentially enable many other use cases. Ripple encourages the community ### Use Case: Payment Authorization -**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](become-an-xrp-ledger-gateway.html#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to disclose the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. +**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](become-an-xrp-ledger-gateway.html#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to disclose the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. **Solution:** Institutions can enable [Deposit Authorization](depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](accountset.html). This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled. @@ -72,6 +72,7 @@ All Checks start the same way, so **Steps 1 and 2** are the same. **Step 4a:** After a Check expires, anyone may cancel it by submitting a [CheckCancel][] transaction. That transaction removes the Check from the ledger. + ## Availability of Checks diff --git a/content/concepts/payment-types/direct-xrp-payments.md b/content/concepts/payment-types/direct-xrp-payments.md index 5b20c9e870..2beb7c6ce6 100644 --- a/content/concepts/payment-types/direct-xrp-payments.md +++ b/content/concepts/payment-types/direct-xrp-payments.md @@ -15,7 +15,7 @@ Generally, any address in the XRP Ledger can send XRP directly to any other addr } ``` -These transaction instructions mean: Send a payment from rf1Bi... to ra5nK... delivering exactly 13 XRP. If the transaction is successfully processed, it does exactly that. Since it usually takes about 4 seconds for each new ledger version to become [validated](consensus.html), a successful transaction can be created, submitted, executed, and have a final outcome in 8 seconds or less, even if gets queued for the ledger version after the current in-progress one. +These transaction instructions mean: Send a payment from `rf1Bi...` to `ra5nK...` delivering exactly 13 XRP. If the transaction is successfully processed, it does exactly that. Since it usually takes about 4 seconds for each new ledger version to become [validated](consensus.html), a successful transaction can be created, submitted, executed, and have a final outcome in 8 seconds or less, even if gets queued for the ledger version after the current in-progress one. **Caution:** The [Payment transaction type][Payment] can also be used for some more specialized kinds of payments, including [cross-currency payments](cross-currency-payments.html) and [partial payments](partial-payments.html). In the case of partial payments, it is possible that the `Amount` shows a large amount of XRP even if the transaction only delivered a very small amount. See [partial payments exploit](partial-payments.html#partial-payments-exploit) for how to avoid crediting a customer for the wrong amount. @@ -52,7 +52,7 @@ From a relatively high level, the XRP Ledger's transaction processing engine app 2. It checks whether the receiving address is a funded account. - - If the receiving address is funded, it checks whether the receiving address has any limitations on receiving payments, such as [DepositAuth](depositauth.html) or [RequireDest](source-and-destination-tags.html#requiring-tags). If the payment does not meet any such limitations, the payment fails. + - If the receiving address is funded, it checks whether the receiving address has any limitations on receiving payments, such as [Deposit Authorization](depositauth.html) or [`RequireDest`](source-and-destination-tags.html#requiring-tags). If the payment does not meet any such limitations, the payment fails. - If the receiving address is not funded, it checks whether the payment would deliver enough XRP to meet the minimum [account reserve](reserves.html). If not, the payment fails. 3. It debits the sending account by an amount of XRP specified by the `Amount` field plus the XRP to be destroyed for the [transaction cost](transaction-cost.html) and credits the receiving account for the same amount. diff --git a/content/concepts/payment-types/escrow.md b/content/concepts/payment-types/escrow.md index fdbf503e53..cba02e290e 100644 --- a/content/concepts/payment-types/escrow.md +++ b/content/concepts/payment-types/escrow.md @@ -26,6 +26,9 @@ All escrows start the same way, so **Steps 1 and 2** are the same as in the succ **Step 4a:** The sender, or any other XRP Ledger address, sends an [EscrowCancel transaction][] to cancel the expired escrow. This destroys the [Escrow object](escrow-object.html) in the ledger and returns the XRP to the sender. + + + ## Limitations Escrow is designed as a feature to enable the XRP Ledger to be used in the [Interledger Protocol][] and with other smart contracts. The current version has a modest scope to avoid complexity. @@ -95,7 +98,7 @@ The Escrow feature takes this idea further by replacing the third party with an Fully automated escrow, backed by the integrity of the XRP Ledger itself, solves important problems for Ripple, and we think there are many other use cases that escrow enables. Ripple encourages the industry to find new and unique ways to put escrow to use. -### Use Case: Time-based Lockup +### Use Case: Time-based Lock-Up **Background:** Ripple holds a large amount of the total XRP, which it sells methodically as a way to fund and incentivize the healthy development of the XRP Ledger and related technologies. At the same time, owning such a large chunk of XRP causes problems for the company, such as: @@ -133,7 +136,7 @@ For more information about Escrow in the XRP Ledger, see the following: For more information on Interledger and how conditional transfers enable secure payments across multiple ledgers, see [Interledger Architecture](https://interledger.org/rfcs/0001-interledger-architecture/). -For more information on Ripple's 55-Billion XRP Lockup, see [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). +For more information on Ripple's 55-billion XRP lock-up, see [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). {% include '_snippets/rippled-api-links.md' %} diff --git a/content/concepts/payment-types/partial-payments.md b/content/concepts/payment-types/partial-payments.md index 484e37750f..1c38def8d1 100644 --- a/content/concepts/payment-types/partial-payments.md +++ b/content/concepts/payment-types/partial-payments.md @@ -1,6 +1,6 @@ # Partial Payments -In the default case, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the exact amount to deliver, after charging for exchange rates and [transfer fees](transfer-fees.html). The "Partial Payment" flag ([**tfPartialPayment**](payment.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](become-an-xrp-ledger-gateway.html#bouncing-payments) without incurring additional costs to oneself. +In the default case, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the exact amount to deliver, after charging for exchange rates and [transfer fees](transfer-fees.html). The "Partial Payment" flag ([`tfPartialPayment`](payment.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](become-an-xrp-ledger-gateway.html#bouncing-payments) without incurring additional costs to oneself. The amount of XRP used for the [transaction cost](transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction. @@ -51,7 +51,7 @@ The delivered amount is **not available** for transactions that meet **both** of - Is a partial payment - Is 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 determine the actual delivered amount by reading the AffectedNodes in the transaction's metadata. If the transaction delivered an issued currency and the `issuer` of the `Amount` is the same account as the `Destination` address, the delivered amount may be divided among multiple `AffectedNodes` members representing trust lines to different counterparties. +If both conditions are true, then `delivered_amount` contains the string value `unavailable` instead of an actual amount. If this happens, you can only determine the actual delivered amount by reading the `AffectedNodes` in the transaction's metadata. If the transaction delivered an issued currency and the `issuer` of the `Amount` is the same account as the `Destination` address, the delivered amount may be divided among multiple `AffectedNodes` members representing trust lines to different counterparties. You can find the `delivered_amount` field in the following places: diff --git a/content/concepts/payment-types/payment-channels.md b/content/concepts/payment-types/payment-channels.md index f080764c30..cb96e37be1 100644 --- a/content/concepts/payment-types/payment-channels.md +++ b/content/concepts/payment-types/payment-channels.md @@ -2,9 +2,9 @@ Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later. -The XRP for a payment channel is set aside for a given time period. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](consensus.html). (This is an _asychronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims. +The XRP for a payment channel is set aside for a given time period. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by [consensus](consensus.html). (This is an _asynchronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims. -Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECSDA signatures. Research has [demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second](https://ed25519.cr.yp.to/ed25519-20110926.pdf) on commodity hardware in 2011. +Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECDSA signatures. Research has [demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second](https://ed25519.cr.yp.to/ed25519-20110926.pdf) on commodity hardware in 2011. ## Why Use Payment Channels 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/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..e166548742 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 issuances. | +| `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..24adb9b05c 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 @@ -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 @@ -93,11 +93,11 @@ The values that count towards a trust line's non-default state are as follows: The **lsfLowAuth** and **lsfHighAuth** flags do not count against the default state, because they cannot be disabled. -The default state of the two 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 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. -**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 `DefaultRipple` flags 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 `DefaultRipple` flag, that account's reserve stays the same initially. If an account modifies a trust line, `rippled` re-evaluates whether that individual trust line is in its default state and should contribute to the owner reserve. ## RippleState ID Format 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..4c3520e019 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,24 +48,24 @@ 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. @@ -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/public-rippled-methods/account-methods/account_lines.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md index 9085d6c273..db16206d93 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 @@ -43,7 +43,7 @@ rippled account_lines [] [] [Try it! >](websocket-api-tool.html#account_lines) -The request accepts the following paramters: +The request accepts the following parameters: | `Field` | Type | Description | |:---------------|:-------------------------------------------|:---------------| 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..1520407a6b 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,7 +1,7 @@ # 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 `DefaultRipple` 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: @@ -10,7 +10,7 @@ An example of the request format: *WebSocket* -``` +```json { "id": 0, "command": "noripple_check", @@ -24,7 +24,7 @@ An example of the request format: *JSON-RPC* -``` +```json { "method": "noripple_check", "params": [ 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_data.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md index 6003619eba..8fa6c6bdc1 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 @@ -97,7 +97,7 @@ An example of a successful response: *WebSocket (binary:false)* -``` +```json { "id": 2, "result": { @@ -245,9 +245,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/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..4b515fd74f 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", @@ -165,7 +165,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/public-rippled-methods.md b/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md index 503044848a..4bba5b92da 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,7 +15,7 @@ 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 `DefaultRipple` and No Ripple settings. ## [Ledger Methods](ledger-methods.html) 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..dae08ef865 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 @@ -492,7 +492,7 @@ The `info` object may have some arrangement of the following fields: | `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. | +| `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..4eddb47a83 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 @@ -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..b60b264d2b 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 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..ddf6a8fc27 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,9 +64,9 @@ 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. @@ -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 `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", @@ -131,7 +129,7 @@ The `Signers` field contains a [multi-signature](multi-signing.html), which has | 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-results/tel-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md index 38b5007f4e..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 @@ -12,7 +12,7 @@ These codes indicate an error in the local server processing the transaction; it | `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_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. | 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 6ee826b9b3..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). 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..18c656da76 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/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/payment.md b/content/references/rippled-api/transaction-formats/transaction-types/payment.md index bc7f61d92f..aaf058485d 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 @@ -59,9 +59,9 @@ The Payment transaction type is a general-purpose tool that can represent severa 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,11 +88,11 @@ 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 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 7b9349e0b2..385279b525 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md @@ -42,13 +42,17 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel | 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 | Blocks rippling between two trust lines 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 No Ripple on the trust line. | -| `tfClearNoRipple` | `0x00040000` | 262144 | Clears the No-Rippling flag. (See [No Ripple](rippling.html) for details.) | -| `tfSetFreeze` | `0x00100000` | 1048576 | [Freeze](freezes.html) the trustline. | -| `tfClearFreeze` | `0x00200000` | 2097152 | [Unfreeze](freezes.html) the trustline. | +| `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/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/run-rippled-as-a-validator.md b/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md index 73eb47f409..ec94f92886 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 @@ -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: @@ -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/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..75f08430d3 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 @@ -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: 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..aacd7f0d79 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 @@ -97,7 +97,7 @@ These instructions use Ubuntu's APT (Advanced Packaging Tool) to install the sof -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..9c8bfcd022 100644 --- a/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md +++ b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md @@ -19,16 +19,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`. @@ -53,7 +53,7 @@ The example `rippled-example.cfg` file has the `type` field in the `[node_db]` s #### 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. @@ -165,7 +165,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. @@ -183,9 +183,9 @@ Here are examples of observed 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 current transaction volumes | 2 Mbps transmit, 2 Mbps receive | +| Serve historical ledger and transaction reports | 100 Mbps transmit | +| Start up `rippled` | 20 Mbps receive | ## See Also 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..c71dc84e4f 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 @@ -45,7 +45,7 @@ Before you install `rippled`, you must meet the [System Requirements](system-req The above example is appropriate for **Ubuntu 18.04 Bionic Beaver**. For other operating systems, replace the word `bionic` with one of the following: - - `xenial` for **Ubuntu 16.04 Xenial Xerus** + - `xenial` for **Ubuntu 16.04 Xenial Xerus** - `stretch` for **Debian 9 Stretch** 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..3e0c14db79 100644 --- a/content/tutorials/manage-the-rippled-server/installation/system-requirements.md +++ b/content/tutorials/manage-the-rippled-server/installation/system-requirements.md @@ -9,7 +9,9 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex - 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+ +- 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..c6cff0df34 100644 --- a/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md @@ -80,7 +80,7 @@ For troubleshooting purposes, the most important fields are (from most commonly - **`peers`** - This field indicates how many other servers in the XRP Ledger peer-to-peer network your server is connected to. Healthy servers typically show between 5 and 50 peers, unless explicitly configured to connect only to certain peers. - - If you have 0 peers, your server may be unable to contact the network, or your system clock may be wrong. (Ripple recommends running an [NTP](http://www.ntp.org/) daemon on all servers to keep their clocks synced.) + - If you have 0 peers, your server may be unable to contact the network, or your system clock may be wrong. (Ripple recommends running an [NTP](http://www.ntp.org/) daemon on all servers to keep their clocks synced.) - If you have exactly 10 peers, that may indicate that your `rippled` is unable to receive incoming connections through a router using [NAT](https://en.wikipedia.org/wiki/Network_address_translation). You can improve connectivity by configuring your router's firewall to forward the port used for peer-to-peer connections (port 51235 [by default](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)). @@ -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/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..ee37ee87cf 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 @@ -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-escrows/send-a-conditionally-held-escrow.md b/content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.md index ec2b7a6671..cad7702c72 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..f275a8cde7 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/xrp-ledger-businesses/list-xrp-as-an-exchange.md b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md index 9b7f3ec052..7b94a90e8f 100644 --- a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md +++ b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md @@ -48,7 +48,7 @@ Before integrating, exchanges should be aware of the [partial payments](partial- #### Partial Payments Warning -When the [tfPartialPayment flag](payment.html#payment-flags) is enabled, the `Amount` field **_is not guaranteed to be the amount received_**. The `delivered_amount` field of a payment's metadata indicates the amount of currency actually received by the destination account. When receiving a payment, use `delivered_amount` instead of the Amount field to determine how much your account received instead. +When the [`tfPartialPayment` flag](payment.html#payment-flags) is enabled, the `Amount` field **_is not guaranteed to be the amount received_**. The `delivered_amount` field of a payment's metadata indicates the amount of currency actually received by the destination account. When receiving a payment, use `delivered_amount` instead of the Amount field to determine how much your account received instead. **Warning:** Be aware that malicious actors could exploit this. For more information, see [Partial Payments](partial-payments.html). @@ -74,7 +74,7 @@ To follow Ripple's recommended best practices, Alpha Exchange should create at l * The malicious actor could issue currency in the XRP Ledger by using the cold wallet, but that currency should not be valued by anyone (unless the exchange explicitly stated it was also a gateway). - * If a malicious actor sets the asfRequireAuth flag for the account, that cannot be unset, although this only relates to issuing currency and should not affect an exchange that is not also a gateway. Any other settings a malicious actor changes with a master key can be reverted. + * If a malicious actor sets the `asfRequireAuth` flag for the account, that cannot be unset, although this only relates to issuing currency and should not affect an exchange that is not also a gateway. Any other settings a malicious actor changes with a master key can be reverted. * One or more [_hot wallets_](issuing-and-operational-addresses.html#operational-addresses) to conduct the day-to-day business of managing customers' XRP withdrawals and deposits. For example, with a hot wallet, exchanges can securely support these types of automated XRP transfers. Hot wallets need to be online to service instant withdrawal requests. @@ -119,7 +119,7 @@ XRP Balances User Balance - Acct # + Account # User Balance @@ -235,7 +235,7 @@ XRP Balances User Balance - Acct # + Account # User Balance @@ -306,7 +306,7 @@ A user named Charlie wants to deposit 50,000 XRP to Alpha Exchange. Doing this i 1. Charlie submits a payment of 50,000 XRP (by using [RippleAPI](rippleapi-reference.html) or similar software) to Alpha Exchange's [cold wallet](#accounts). - a. Charlie adds an identifier (in this case, `789`) to the payment to associate it with his account at Alpha Exchange. This is called a [_destination tag_](become-an-xrp-ledger-gateway.html#source-and-destination-tags). (To use this, Alpha Exchange should have set the asfRequireDest flag on all of its accounts to require all incoming payments to have a destination tag like Charlie's. For more information, see [AccountSet Flags](accountset.html#accountset-flags)). + a. Charlie adds an identifier (in this case, `789`) to the payment to associate it with his account at Alpha Exchange. This is called a [_destination tag_](become-an-xrp-ledger-gateway.html#source-and-destination-tags). (To use this, Alpha Exchange should have set the `asfRequireDest` flag on all of its accounts to require all incoming payments to have a destination tag like Charlie's. For more information, see [AccountSet Flags](accountset.html#accountset-flags)). 2. The software at Alpha Exchange detects the incoming payment, and recognizes `789` as the destination tag for Charlie’s account. @@ -329,7 +329,7 @@ XRP Balances User Balance - Acct # + Account # User Balance @@ -428,7 +428,7 @@ Off-Ledger Balances - Acct # + Account # User Balance @@ -520,7 +520,7 @@ Off-Ledger Balances User Balance - Acct # + Account # User Balance diff --git a/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md b/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md index e96d42a5de..75c3fbe0e0 100644 --- a/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md +++ b/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md @@ -10,7 +10,7 @@ To enable XRP Charts to list your exchange, you'll need to make the following da Then, you'll need to [send an exchange listing request to XRP Charts](#send-an-exchange-listing-request-to-xrp-charts). -If you have any questions about endpoint specifications, contact . +If you have any questions about endpoint specifications, contact . ## Provide a Recently Executed Trades Endpoint diff --git a/tool/spelling.txt b/tool/spelling.txt index 02ed2224bb..b9c1cad1d2 100644 --- a/tool/spelling.txt +++ b/tool/spelling.txt @@ -11,7 +11,6 @@ backend backfilling backfills billionths -bitcoin bitwise blockchain blog @@ -21,7 +20,6 @@ callbacks canceled canceling cannot -centos codebase colocation commandline @@ -34,7 +32,6 @@ cryptographically csv datacenter ddos -debian debug decrypt denominate @@ -64,9 +61,8 @@ firewalls fulfills gapped geolocation +ghz gigabit -github -google haven't hardcoded hashed @@ -93,14 +89,14 @@ ipv4 ipv6 isn't iterating -firefox javascript json -linux loopback lowercase maintainer malware +mbps +md5 metadata mitigations modulo @@ -108,7 +104,6 @@ namespace nonces npm onboarding -openssl outages overwriting paginate @@ -136,7 +131,6 @@ reconfigure reconfiguring reconnecting reconnects -redhat refunding renumbering reorders @@ -145,9 +139,9 @@ retriable retries retried retrying -rhel roadmaps sandbox +scammers serialize serialized serializing @@ -160,6 +154,7 @@ subfolder subfolders supermajority svg +symlink synced synchronizing syncing @@ -184,7 +179,6 @@ triskelion troubleshoot truncates typos -ubuntu unauthorize uncomment undesirably @@ -206,6 +200,8 @@ urls utc validator versioning +virtualization +virtualized wasn't we'll won't @@ -216,13 +212,28 @@ whitespace workaround writable wss -xeon xml you'll you're you've zeroes +bitcoin +centos +debian +firefox +github +google +linux +nginx +openssl +redhat +rhel +ubuntu +xenial +xeon +xerus + btc cny eur @@ -266,6 +277,7 @@ channel_verify checkcancel checkcash checkcreate +cmake consensus_info cors crawl_shards @@ -325,6 +337,7 @@ ledger_accept ledger_cleaner ledger_closed ledger_current +ledger_data ledger_entry ledger_request ledgerhashes @@ -332,16 +345,17 @@ log_level logrotate lz4 mainnet -md5 +micropayments multisign multisigning multisignreserve -nginx noripple +noripple_check nudb ownerpaysfee path_find pathfinding +pathset paychan paychannel paymentchannelclaim @@ -370,6 +384,7 @@ shor sign_for signerlist signerlistset +statsd submit_multisigned suspay testnet @@ -386,5 +401,6 @@ validation_create validation_seed validator_info validator_list_sites +vector256 xpring xrpchat From c63d10d116806e4b7900b88b3d35db5765e49cfb Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 24 Jul 2020 03:25:39 -0700 Subject: [PATCH 35/65] Most spelling, more style cleanup --- assets/js/apitool-methods-ws.js | 2 +- assets/js/tx-sender.js | 4 +- content/_img-sources/noripple-05.uxf | 4 +- content/_img-sources/noripple-06.uxf | 12 +- .../depositauth-semantics-table.html | 4 +- content/_snippets/gateways-intro.md | 2 +- content/_snippets/tutorial-submit-step.md | 2 +- .../amendments/known-amendments.md | 18 +-- .../consensus-principles-and-rules.md | 2 +- .../consensus-protections.md | 4 +- .../consensus-network/consensus-research.md | 2 + .../concepts/consensus-network/consensus.md | 6 +- .../consensus-network/parallel-networks.md | 6 +- .../transaction-malleability.md | 30 ++--- .../decentralized-exchange/autobridging.md | 2 +- .../concepts/decentralized-exchange/offers.md | 2 +- .../introduction/intro-to-consensus.md | 2 +- .../introduction/software-ecosystem.md | 6 +- .../concepts/introduction/technical-faq.md | 10 +- .../introduction/xrp-ledger-overview.md | 6 +- .../authorized-trust-lines.md | 19 ++-- .../concepts/issued-currencies/demurrage.md | 2 +- content/concepts/issued-currencies/freezes.md | 18 +-- .../issued-currencies-overview.md | 2 +- .../issuing-and-operational-addresses.md | 10 +- content/concepts/issued-currencies/paths.md | 10 +- .../concepts/issued-currencies/rippling.md | 44 +++---- .../issued-currencies/transfer-fees.md | 16 +-- .../trust-lines-and-issuing.md | 4 +- .../accounts/accounts.md | 2 +- .../accounts/cryptographic-keys.md | 8 +- .../accounts/depositauth.md | 4 +- .../concepts/payment-system-basics/fees.md | 2 +- .../transaction-basics/transaction-basics.md | 2 +- content/concepts/payment-types/checks.md | 2 +- .../payment-types/cross-currency-payments.md | 2 +- .../payment-types/partial-payments.md | 6 +- .../ledger-history/history-sharding.md | 2 +- .../ledger-history/online-deletion.md | 6 +- .../the-rippled-server/peer-protocol.md | 8 +- .../rippled-server-modes.md | 2 +- .../can_delete.md | 2 +- .../ledger-object-types/accountroot.md | 2 +- .../ledger-object-types/ripplestate.md | 14 +-- .../ledger-object-types/signerlist.md | 2 +- .../references/rippled-api/peer-crawler.md | 2 +- .../account-methods/account_lines.md | 12 +- .../account-methods/noripple_check.md | 11 +- .../public-rippled-methods.md | 2 +- .../server-info-methods/server_info.md | 2 +- .../server-info-methods/server_state.md | 2 +- .../subscription-methods/subscribe.md | 2 +- .../transaction-common-fields.md | 16 +-- .../transaction-types/accountset.md | 2 +- .../transaction-types/checkcash.md | 2 +- .../transaction-types/payment.md | 16 +-- .../references/rippled-api/validator-list.md | 2 +- content/references/xrp-ledger-toml.md | 10 +- ...t-started-with-rippleapi-for-javascript.md | 48 ++++---- .../get-started-with-the-rippled-api.md | 2 +- .../look-up-transaction-results.md | 36 +++--- ...tor-incoming-payments-with-websocket.ja.md | 22 ++-- ...onitor-incoming-payments-with-websocket.md | 2 +- .../get-started/set-up-secure-signing.md | 6 +- .../change-or-remove-a-regular-key-pair.md | 6 +- .../disable-master-key-pair.md | 4 +- .../offline-account-setup.md | 10 +- .../set-up-multi-signing.md | 14 +-- .../configure-advisory-deletion.md | 2 +- .../configuration/configure-grpc.md | 2 +- ...onnect-your-rippled-to-the-xrp-test-net.md | 92 +++++++-------- .../run-rippled-as-a-validator.md | 10 +- .../run-rippled-as-a-wallet-server.md | 6 +- .../installation/build-run-rippled-macos.md | 4 +- .../installation/capacity-planning.md | 4 +- .../installation/system-requirements.md | 2 +- .../troubleshooting/diagnosing-problems.md | 6 +- .../fix-sqlite-tx-db-page-size-issue.md | 2 +- .../troubleshooting/server-doesnt-sync.md | 2 +- .../understanding-log-messages.md | 4 +- .../cash-a-check-for-a-flexible-amount.md | 2 +- .../use-checks/send-a-check.md | 10 +- .../send-a-conditionally-held-escrow.md | 2 +- .../use-payment-channels.md | 2 +- .../reliable-transaction-submission.md | 4 +- .../send-a-multi-signed-transaction.md | 2 +- .../use-simple-xrp-payments/send-xrp.ja.md | 4 +- .../use-simple-xrp-payments/send-xrp.md | 14 +-- .../become-an-xrp-ledger-gateway.md | 107 ++++++++++-------- .../list-xrp-as-an-exchange.md | 2 +- .../list-your-exchange-on-xrp-charts.md | 4 +- .../contribute-code-to-ripple-lib.md | 4 +- .../use-cases/contribute-code-to-rippled.md | 4 +- ...nel-to-enable-an-inter-exchange-network.md | 6 +- dactyl-config.yml | 2 +- .../template-openapi_data_type.md | 2 +- .../template-openapi_data_types_toc.md | 2 +- .../template-openapi_endpoint.md | 2 +- .../template-openapi_endpoint_tag_toc.md | 2 +- .../template-openapi_endpoint_toc.md | 2 +- tool/spelling.txt | 19 +++- tool/word_substitutions.yaml | 2 +- 102 files changed, 463 insertions(+), 421 deletions(-) diff --git a/assets/js/apitool-methods-ws.js b/assets/js/apitool-methods-ws.js index 42218b6104..1123700c9b 100644 --- a/assets/js/apitool-methods-ws.js +++ b/assets/js/apitool-methods-ws.js @@ -99,7 +99,7 @@ Request('gateway_balances', { }) Request('noripple_check', { - description: "Compares an account's DefaultRipple and NoRipple flags to the recommended settings.", + description: "Compares an account's Default Ripple and No Ripple flags to the recommended settings.", link: "noripple_check.html", body: { "id": 0, diff --git a/assets/js/tx-sender.js b/assets/js/tx-sender.js index 705e530c1c..7f181f5891 100644 --- a/assets/js/tx-sender.js +++ b/assets/js/tx-sender.js @@ -235,14 +235,14 @@ const set_up_tx_sender = async function() { } $("#pp_progress .progress-bar").width("20%") - // 2. Set DefaultRipple on issuer + // 2. Set Default Ripple on issuer let resp = await submit_and_verify({ TransactionType: "AccountSet", Account: pp_issuer_address, SetFlag: 8 }, pp_issuer_secret, true) if (resp === undefined) { - console.log("Couldn't set DefaultRipple for partial payment issuer") + console.log("Couldn't set Default Ripple for partial payment issuer") return } $("#pp_progress .progress-bar").width("40%") diff --git a/content/_img-sources/noripple-05.uxf b/content/_img-sources/noripple-05.uxf index 54c35a6601..a8f526488c 100644 --- a/content/_img-sources/noripple-05.uxf +++ b/content/_img-sources/noripple-05.uxf @@ -45,7 +45,7 @@ A lt=<- $1 -NoRipple +No Ripple 10.0;20.0;110.0;20.0 @@ -82,7 +82,7 @@ B lt=<- $100 -NoRipple +No Ripple 120.0;20.0;10.0;20.0 diff --git a/content/_img-sources/noripple-06.uxf b/content/_img-sources/noripple-06.uxf index 4dc50fc28f..4e952f1f90 100644 --- a/content/_img-sources/noripple-06.uxf +++ b/content/_img-sources/noripple-06.uxf @@ -45,7 +45,7 @@ A lt=<- $1 - NoRipple + No Ripple 10.0;20.0;110.0;20.0 @@ -82,7 +82,7 @@ B lt=<- $100 -NoRipple . +No Ripple . 120.0;20.0;10.0;20.0 @@ -167,7 +167,7 @@ A lt=<- $1 - NoRipple + No Ripple 10.0;20.0;110.0;20.0 @@ -392,7 +392,7 @@ A lt=<- $1 - NoRipple + No Ripple 10.0;20.0;110.0;20.0 @@ -416,7 +416,7 @@ $1 lt=<- $100 - NoRipple + No Ripple 10.0;20.0;120.0;20.0 @@ -467,7 +467,7 @@ bg=green 110 This path is valid -because Daniel, but not Emily, has set the NoRipple flag on the trust line between them +because Daniel, but not Emily, has set the No Ripple flag on the trust line between them bg=yellow diff --git a/content/_snippets/depositauth-semantics-table.html b/content/_snippets/depositauth-semantics-table.html index d8b906f352..60a2dccacb 100644 --- a/content/_snippets/depositauth-semantics-table.html +++ b/content/_snippets/depositauth-semantics-table.html @@ -66,7 +66,7 @@ Only if account previously created a matching offer - Payment
(If account has more than the minimum XRP reserve, enables NoRipple on all trust lines, and places no offers)
+ Payment
(If account has more than the minimum XRP reserve, enables No Ripple on all trust lines, and places no offers)
Cross-currency only OK   @@ -84,7 +84,7 @@ OK - Payment
(If account has any trust lines with NoRipple disabled)
+ Payment
(If account has any trust lines with No Ripple disabled)
Cross-currency only OK   diff --git a/content/_snippets/gateways-intro.md b/content/_snippets/gateways-intro.md index fd74e3a276..3ac1eecd4b 100644 --- a/content/_snippets/gateways-intro.md +++ b/content/_snippets/gateways-intro.md @@ -1,5 +1,5 @@ Gateways are businesses that provide a way for money and other forms of value to move in and out of the XRP Ledger. There are three major models that gateways can follow, with different purposes and modes of operation. -* An **Issuing Gateway** receives money (or other assets of value) outside of the XRP Ledger, and creates issuances in the XRP Ledger. This provides a direct way for customers to get money in and out of the XRP Ledger. All currencies in the XRP Ledger, except for XRP, take the form of issuances tied to a specific issuing gateway. +* An **Issuing Gateway** receives money (or other assets of value) outside of the XRP Ledger, and issues currency in the XRP Ledger. This provides a direct way for customers to get money in and out of the XRP Ledger. All currencies in the XRP Ledger, except for XRP, are tied to a specific issuing gateway. * A **Private Exchange** holds XRP and lets its customers buy and sell that XRP in its own system. Most cryptocurrencies rely on private exchanges to provide a market for the cryptocurrency, but the XRP Ledger has a currency exchange built into the protocol itself. * **Merchants** accept payment within the XRP Ledger in exchange for goods and services in the outside world. Currently, Ripple (the company) does not provide support for merchant operations using the XRP Ledger. diff --git a/content/_snippets/tutorial-submit-step.md b/content/_snippets/tutorial-submit-step.md index 08141888e0..307c4444e3 100644 --- a/content/_snippets/tutorial-submit-step.md +++ b/content/_snippets/tutorial-submit-step.md @@ -1,3 +1,3 @@ -Take the signed transaction blob from the previous step and submit it to a `rippled` server. You can do this safely even if you do not operate the `rippled` server. The response contains a provisional result, which should be `tesSUCCESS`, but this result is [usually not final](finality-of-results.html). A provisional response of `terQUEUED` is also OK, since [queued transactions](transaction-cost.html#queued-transactions) are generally included in the next open ledger version (usually about 10 seconds after submission). +Take the signed transaction blob from the previous step and submit it to a `rippled` server. You can do this safely even if you do not run the `rippled` server. The response contains a provisional result, which should be `tesSUCCESS`, but this result is [usually not final](finality-of-results.html). A provisional response of `terQUEUED` is also OK, since [queued transactions](transaction-cost.html#queued-transactions) are generally included in the next open ledger version (usually about 10 seconds after submission). **Tip:** If the preliminary result is `tefMAX_LEDGER`, the transaction has failed permanently because its `LastLedgerSequence` parameter is lower than the current ledger. This happens when you take longer than the expected number of ledger versions between preparing and submitting the transaction. If this occurs, [start over from step 1]({{step_1_link}}) with a higher `LastLedgerSequence` value. diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md index 662db25f97..01cc765679 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.md +++ b/content/concepts/consensus-network/amendments/known-amendments.md @@ -119,7 +119,7 @@ When an account enables this flag, Payment transactions fail if the account is t As an exception, accounts with `DepositAuth` enabled can receive Payment transactions for small amounts of XRP (equal or less than the minimum [account reserve](reserves.html)) if their current XRP balance is below the account reserve. -Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where they mistakenly enforced the DisallowXRP flag, which is meant to be a non-binding advisory flag. (By not enforcing DisallowXRP in the ledger itself an account can still receive the necessary XRP to meet its [account reserve](reserves.html) and pay [transaction costs](transaction-cost.html).) +Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where they mistakenly enforced the Disallow XRP flag, which is meant to be a non-binding advisory flag. (By not enforcing Disallow XRP in the ledger itself an account can still receive the necessary XRP to meet its [account reserve](reserves.html) and pay [transaction costs](transaction-cost.html).) ## DepositPreauth @@ -133,7 +133,7 @@ Provides users of [deposit authorization](depositauth.html) with a way to preaut Adds a new transaction type, DepositPreauth for adding or removing preauthorization, and a DepositPreauth ledger object type for tracking preauthorizations from one account to another. Adds a JSON-RPC command, `deposit_authorized`, to query whether an account is authorized to send payments directly to another. -Also changes the behavior of cross-currency Payments from an account to itself when that account requires deposit authorization. Without this amendment, those payments always fail with the code tecNO_PERMISSION. With this amendment, those payments succeed as they would with Deposit Authorization disabled. +Also changes the behavior of cross-currency Payments from an account to itself when that account requires deposit authorization. Without this amendment, those payments always fail with the code `tecNO_PERMISSION`. With this amendment, those payments succeed as they would with Deposit Authorization disabled. ## EnforceInvariants @@ -326,7 +326,7 @@ Changes Escrow to fix the following issues: Changes the result codes returned by two transaction types: - Changes the [OfferCreate transaction][] to return a new result code, `tecKILLED`, if the offer used the `tfFillOrKill` flag and was killed. Without this amendment, the offer is killed but the transaction result is `tesSUCCESS`. -- Changes the [TrustSet transaction][] to fail with `tecNO_PERMISSION` if it tries to enable the [NoRipple flag](rippling.html#the-noripple-flag) but cannot because the trust line has a negative balance. Without this amendment, the transaction does not enable the NoRipple flag, but the transaction result is `tesSUCCESS` nonetheless. +- Changes the [TrustSet transaction][] to fail with `tecNO_PERMISSION` if it tries to enable the [No Ripple flag](rippling.html#the-no-ripple-flag) but cannot because the trust line has a negative balance. Without this amendment, the transaction does not enable the No Ripple flag, but the transaction result is `tesSUCCESS` nonetheless. ## fix1623 @@ -537,7 +537,7 @@ Implements a "Negative UNL" system, where the network can track which validators |:-----------------------------------------------------------------|:----------| | 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 | In Development | -Fixes an inconsistency in the way [transfer fees](transfer-fees.html) are calculated between [OfferCreate](offercreate.html) and [Payment](payment.html) transaction types. Without this amendment, the holder of the issuances pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. +Fixes an inconsistency in the way [transfer fees](transfer-fees.html) are calculated between [OfferCreate](offercreate.html) and [Payment](payment.html) transaction types. Without this amendment, the holder of the issued currency pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issued currency always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. This Amendment requires the [Flow Amendment](#flow) to be enabled. @@ -553,7 +553,7 @@ This Amendment requires the [Flow Amendment](#flow) to be enabled. Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the [Interledger Protocol](https://interledger.org/). One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the combined content of many small Claims later, as long as it is within the expiration. -Creates three new transaction types: [PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger object type, [PayChannel](paychannel.html). Defines an off-ledger data structure called a `Claim`, used in the ChannelClaim transaction. Creates new `rippled` API methods: [`channel_authorize`](channel_authorize.html) (creates a signed Claim), [`channel_verify`](channel_verify.html) (verifies a signed Claim), and [`account_channels`](account_channels.html) (lists Channels associated with an account). +Creates three new transaction types: [PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger object type, [PayChannel](paychannel.html). Defines an off-ledger data structure called a `Claim`; the PaymentChannelClaim uses a signature for this data structure. Creates new `rippled` API methods: [`channel_authorize`](channel_authorize.html) (creates a signed Claim), [`channel_verify`](channel_verify.html) (verifies a signed Claim), and [`account_channels`](account_channels.html) (lists Channels associated with an account). For more information, see the [Payment Channels Tutorial](use-payment-channels.html). @@ -565,11 +565,11 @@ For more information, see the [Payment Channels Tutorial](use-payment-channels.h |:-----------------------------------------------------------------|:----------| | 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC | Enabled | -Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](transaction-common-fields.html#global-flags) enabled. +Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](transaction-malleability.html) on _all_ transactions, instead of only transactions with the [`tfFullyCanonicalSig` flag](transaction-common-fields.html#global-flags) enabled. -Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. +Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have `tfFullyCanonicalSig` enabled. Most signing utilities enable `tfFullyCanonicalSig` by default, but there are exceptions. -With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. +With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the `tfFullyCanonicalSig` flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. For more information, see [`rippled` issue #3042](https://github.com/ripple/rippled/issues/3042). @@ -641,7 +641,7 @@ Introduces a `TickSize` field to accounts, which can be set with the [AccountSet Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Trust Lines](authorized-trust-lines.html). -With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](trustset.html#trustset-flags) can create a new [`RippleState` ledger object](ripplestate.html) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](ripplestate.html#ripplestate-flags) enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](accountroot.html#accountroot-flags) by sending an [AccountSet transaction](accountset.html) with the [asfRequireAuth flag enabled](accountset.html#accountset-flags). +With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](trustset.html#trustset-flags) can create a new [`RippleState` ledger object](ripplestate.html) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](ripplestate.html#ripplestate-flags) enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](accountroot.html#accountroot-flags) by sending an [AccountSet transaction](accountset.html) with the [`asfRequireAuth` flag enabled](accountset.html#accountset-flags). diff --git a/content/concepts/consensus-network/consensus-principles-and-rules.md b/content/concepts/consensus-network/consensus-principles-and-rules.md index 14a5b26e8f..5433fc8f3d 100644 --- a/content/concepts/consensus-network/consensus-principles-and-rules.md +++ b/content/concepts/consensus-network/consensus-principles-and-rules.md @@ -51,7 +51,7 @@ The primary role of consensus is for participants in the process to agree on whi 3. It is extremely rare for a participant to particularly care how the transactions were grouped. Agreement is easiest when everyone’s priority is reaching agreement and only challenging when there are diverging interests. 4. Deterministic rules can be used even to form the groupings, leading to disagreement only in edge cases. For example, if there are two conflicting transactions in a round, deterministic rules can be used to determine which is included in the next round. -Every participant’s top priority is correctness. They must first enforce the rules to be sure nothing violates the integrity of the shared ledger. For example, a transaction that is not properly signed must never be processed (even if other participants want to be processed). However, every honest participant’s second priority is agreement. A network with possible double spends has no utility at all. Agreement is facilitated by the fact that every honest participant values it above everything but correctness. +Every participant’s top priority is correctness. They must first enforce the rules to be sure nothing violates the integrity of the shared ledger. For example, a transaction that is not properly signed must never be processed (even if other participants want it to be processed). However, every honest participant’s second priority is agreement. A network with possible double spends has no utility at all, so every honest participant values agreement above everything but correctness. ### Consensus Rounds diff --git a/content/concepts/consensus-network/consensus-protections.md b/content/concepts/consensus-network/consensus-protections.md index 98a715bdf6..1160247577 100644 --- a/content/concepts/consensus-network/consensus-protections.md +++ b/content/concepts/consensus-network/consensus-protections.md @@ -1,6 +1,6 @@ # Consensus Protections Against Attacks and Failure Modes -The XRP Ledger Consensus Protocol is a _byzantine fault tolerant_ consensus mechanism, which means it's designed to operate even if all kinds of things can go wrong: participants depend on an unreliable open network to communicate, and malicious actors may be attempting to control or interrupt the system at any given time. On top of that, the set of participants in the XRP Ledger Consensus Protocol isn't known in advance and can change over time. +The XRP Ledger Consensus Protocol is a _byzantine fault tolerant_ consensus mechanism, which means it's designed to work even if all kinds of things can go wrong: participants depend on an unreliable open network to communicate, and malicious actors may be attempting to control or interrupt the system at any given time. On top of that, the set of participants in the XRP Ledger Consensus Protocol isn't known in advance and can change over time. Confirming transactions in a timely manner while maintaining [the desired properties of the network](intro-to-consensus.html#consensus-protocol-properties) is a complex challenge, and it's impossible to build a perfect system. The XRP Ledger Consensus Protocol is designed to work as well as it can in most situations, and to fail as gracefully as possible in the situations where it can't. @@ -25,7 +25,7 @@ The only way to confirm an invalid transaction would be to get at least 80% of t ## Software Vulnerabilities -As with any software system, bugs (or intentionally malicious code) in the implementation of the XRP Ledger Consensus Protocol, commonly deployed software packages, or their dependencies, are a problem to be taken seriously. Even bugs that simply cause a server to crash when it sees carefully crafted inputs can be abused to disrupt the progress of the network. Ripple has a number of precautions in place to address this threat, including: +As with any software system, bugs (or intentionally malicious code) in the implementation of the XRP Ledger Consensus Protocol, commonly deployed software packages, or their dependencies, are a problem to be taken seriously. Even bugs that cause a server to crash when it sees carefully crafted inputs can be abused to disrupt the progress of the network. Ripple has a number of precautions in place to address this threat, including: - An [open-source code base](https://github.com/ripple/rippled/), so any member of the public can review, compile, and independently test the relevant software. - A thorough and robust code review process for all changes to the official XRP Ledger repositories. diff --git a/content/concepts/consensus-network/consensus-research.md b/content/concepts/consensus-network/consensus-research.md index 5510ca7827..b936e610e9 100644 --- a/content/concepts/consensus-network/consensus-research.md +++ b/content/concepts/consensus-network/consensus-research.md @@ -7,3 +7,5 @@ Ripple researches both the theoretical and the practical limits of the XRP Ledge | 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | Introduces a novel atomic broadcast algorithm called Cobalt that allows more flexibility in consensus UNLs. | | 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | A detailed and updated analysis of the XRP Ledger consensus algorithm and its safety and liveness properties. | | 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | Introduces the consensus algorithm behind the XRP Ledger. | + + diff --git a/content/concepts/consensus-network/consensus.md b/content/concepts/consensus-network/consensus.md index d2f5a25c76..a70b162346 100644 --- a/content/concepts/consensus-network/consensus.md +++ b/content/concepts/consensus-network/consensus.md @@ -51,7 +51,7 @@ In addition to the **`tes`** and **`tec`** class result codes, there are **`ter` When working with [`rippled` APIs](rippled-api.html), applications must distinguish between candidate transactions proposed for inclusion in a ledger versus validated transactions which are included in a validated ledger. Only transaction results found in a validated ledger are immutable. A candidate transaction may or may not ever be included in a validated ledger. -Important: Some [`rippled` APIs](rippled-api.html) provide provisional results, based on candidate transactions 2. Applications should never rely on provisional results to determine the final outcome of a transaction. The only way to know with certainty that a transaction finally succeeded is to check the status of the transaction until it is both in a validated ledger and has result code tesSUCCESS. If the transaction is in a validated ledger with any other result code, it has failed. If the ledger specified in a transaction’s [`LastLedgerSequence`](transaction-common-fields.html) has been validated, yet the transaction does not appear in that ledger or any before it, then that transaction has failed and can never appear in any ledger. An outcome is final only for transactions that appear in a validated ledger or can never appear because of `LastLedgerSequence` restrictions as explained later in this document. +Important: Some [`rippled` APIs](rippled-api.html) provide provisional results, based on candidate transactions 2. Applications should never rely on provisional results to determine the final outcome of a transaction. The only way to know with certainty that a transaction finally succeeded is to check the status of the transaction until it is both in a validated ledger and has result code `tesSUCCESS`. If the transaction is in a validated ledger with any other result code, it has failed. If the ledger specified in a transaction’s [`LastLedgerSequence`](transaction-common-fields.html) has been validated, yet the transaction does not appear in that ledger or any before it, then that transaction has failed and can never appear in any ledger. An outcome is final only for transactions that appear in a validated ledger or can never appear because of `LastLedgerSequence` restrictions as explained later in this document. ## The XRP Ledger Protocol – Consensus and Validation @@ -155,7 +155,7 @@ Best practices for applications submitting transactions include: - Use the `LastLedgerSequence` parameter to ensure that transactions validate or fail in a deterministic and prompt fashion. - Check the results of transactions in validated ledgers. - Until a ledger containing the transaction is validated, or `LastLedgerSequence` has passed, results are provisional. - - Transactions with result code **tesSUCCESS** and `"validated": true` have immutably succeeded. + - Transactions with result code **`tesSUCCESS`** and `"validated": true` have immutably succeeded. - Transactions with other result codes and `"validated": true` have immutably failed. - Transactions that fail to appear in any validated ledger up to and including the validated ledger identified by the transaction’s `LastLedgerSequence` have immutably failed. - Take care to use a server with a continuous ledger history to detect this case 10. @@ -185,7 +185,7 @@ Best practices for applications submitting transactions include: 1 – Transactions with [**tec** result codes](tec-codes.html) do not perform the requested action, but do have effects on the ledger. To prevent abuse of the network and to pay for the cost of distributing the transaction, they destroy the XRP [transaction cost](transaction-cost.html). To not block other transactions submitted by the same sender around the same time, they increment the sending account's [sequence number](basic-data-types.html#account-sequence). Transactions with `tec`-class results sometimes also perform maintenance such as deleting expired objects or unfunded trade offers. -2 – For example, consider a scenario where Alice has $100, and sends all of it to Bob. If an application first submits that payment transaction, then immediately after checks Alice’s balance, the API returns $0. This value is based on the provisional result of a candidate transaction. There are circumstances in which the payment fails and Alice’s balance remains $100 (or, due to other transactions, become some other amount). The only way to know with certainty that Alice’s payment to Bob succeeded is to check the status of the transaction until it is both in a validated ledger and has result code **tesSUCCESS**. If the transaction is in a validated ledger with any other result code, the payment has failed. +2 – For example, consider a scenario where Alice has $100, and sends all of it to Bob. If an application first submits that payment transaction, then immediately after checks Alice’s balance, the API returns $0. This value is based on the provisional result of a candidate transaction. There are circumstances in which the payment fails and Alice’s balance remains $100 (or, due to other transactions, become some other amount). The only way to know with certainty that Alice’s payment to Bob succeeded is to check the status of the transaction until it is both in a validated ledger and has result code **`tesSUCCESS`**. If the transaction is in a validated ledger with any other result code, the payment has failed. 3 – Strictly speaking, validators are a subset of tracking servers. They provide the same features and additionally send "validation" messages. Tracking servers may be further categorized by whether they keep full vs. partial ledger history. diff --git a/content/concepts/consensus-network/parallel-networks.md b/content/concepts/consensus-network/parallel-networks.md index 4075e0400c..96e7623ed5 100644 --- a/content/concepts/consensus-network/parallel-networks.md +++ b/content/concepts/consensus-network/parallel-networks.md @@ -2,13 +2,13 @@ There is one production XRP Ledger peer-to-peer network, and all business that takes place on the XRP Ledger occurs within the production network—the Mainnet. -To help members of the XRPL community interact with XRPL technology without affecting anything on the Mainnet, Ripple hosts two alternative networks, or altnets: the Testnet and the Devnet. Here's a breakdown of all three networks: +To help members of the XRP Ledger community interact with XRP Ledger technology without affecting anything on the Mainnet, Ripple hosts two alternative networks, or altnets: the Testnet and the Devnet. Here's a breakdown of all three networks: | Network | Upgrade Cadence | Description | |:--------|:----------------|:-------------------------------------------------| | Mainnet | Stable releases | _The_ [XRP Ledger](xrp-ledger-overview.html), a decentralized cryptographic ledger powered by a network of peer-to-peer servers and the home of [XRP](xrp.html). | | Testnet | Stable releases | An "alternate universe" network that acts as a testing ground for software built on the XRP Ledger, without impacting production XRP Ledger users and without risking real money. The [amendment status](known-amendments.html) of the Testnet is intended to closely mirror the Mainnet, although slight variations in timing may occur due to the unpredictable nature of decentralized systems. | -| Devnet | Beta releases | A preview of coming attractions, where unstable changes to the core XRP Ledger software may be tested out. Developers can use this altnet to interact with and learn about planned new XRPL features and amendments that are not yet enabled on the Mainnet. | +| Devnet | Beta releases | A preview of coming attractions, where unstable changes to the core XRP Ledger software may be tested out. Developers can use this altnet to interact with and learn about planned new XRP Ledger features and amendments that are not yet enabled on the Mainnet. | Testnet and Devnet each have their own separate supply of test XRP, which Ripple [gives away for free](xrp-testnet-faucet.html) to parties interested in experimenting with the XRP Ledger and developing applications and integrations. Test XRP does not have real-world value and is lost when the network is reset. @@ -19,7 +19,7 @@ Testnet and Devnet each have their own separate supply of test XRP, which Ripple There is no `rippled` setting that defines which network it uses. Instead, it uses the consensus of validators it trusts to know which ledger to accept as the truth. When different consensus groups of `rippled` instances only trust other members of the same group, each group continues as a parallel network. Even if malicious or misbehaving computers connect to both networks, the consensus process overrides the confusion as long as the members of each network are not configured to trust members of another network in excess of their quorum settings. -Ripple operates the main servers in the Testnet and Devnet; you can also [connect your own `rippled` server to the Testnet](connect-your-rippled-to-the-xrp-test-net.html). The Testnet and Devnet do not use diverse, censorship-resistant sets of validators. This makes it possible for Ripple to reset the Testnet or Devnet on a regular basis. +Ripple runs the main servers in the Testnet and Devnet; you can also [connect your own `rippled` server to the Testnet](connect-your-rippled-to-the-xrp-test-net.html). The Testnet and Devnet do not use diverse, censorship-resistant sets of validators. This makes it possible for Ripple to reset the Testnet or Devnet on a regular basis. ## See Also diff --git a/content/concepts/consensus-network/transaction-malleability.md b/content/concepts/consensus-network/transaction-malleability.md index 092d75e446..e6d53fe937 100644 --- a/content/concepts/consensus-network/transaction-malleability.md +++ b/content/concepts/consensus-network/transaction-malleability.md @@ -6,11 +6,11 @@ If vulnerable software submits malleable transactions and assumes they can only There are two circumstances that could lead to transaction malleability: -1. The transaction does not specify the tfFullyCanonicalSig flag on a transaction signed using the default signing algorithm (ECDSA with the secp256k1 curve). +1. The transaction does not specify the `tfFullyCanonicalSig` flag on a transaction signed using the default signing algorithm (ECDSA with the secp256k1 curve). **Use the [`tfFullyCanonicalSig` flag](transaction-common-fields.html#global-flags)** to guarantee that a transaction is not malleable in this way. Although transactions [signed with Ed25519 keys](cryptographic-keys.html#signing-algorithms) are not vulnerable to this problem, **there is no downside** to using this flag on _all_ transactions. - If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions are protected against malleability regardless of the tfFullyCanonicalSig flag. + If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions are protected against malleability regardless of the `tfFullyCanonicalSig` flag. 2. The transaction is [multi-signed](multi-signing.html) and has more signatures than necessary. Even if the transaction originally did not have more signatures than necessary, it could be malleable if an authorized signer provides an additional signature. @@ -43,16 +43,16 @@ An ECDSA signature consists of two integers, called R and S. The secp256k1 _grou Thus, to have _fully_ canonical signatures, one must choose which of the two possibilities is preferred and declare the other to be invalid. The creators of the XRP Ledger decided arbitrarily to prefer the _smaller_ of the two possible values, `S` or `N-S`. A transaction is considered _fully canonical_ if it uses the preferred (smaller) value of `S`, and follows all the normal rules for being canonical. -To maintain compatibility with older software that did not always generate fully canonical signatures, the XRP Ledger accepts transactions that are not fully canonical. To protect new users from exploits, the XRP Ledger has a flag on transactions called [**tfFullyCanonicalSig**](transaction-common-fields.html#global-flags), which requires that the transaction use a _fully-canonical_ signature to be valid. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions require fully-canonical signatures regardless of the tfFullyCanonicalSig flag, and legacy software that makes non-fully-canonical signatures is no longer compatible. +To maintain compatibility with older software that did not always generate fully canonical signatures, the XRP Ledger accepts transactions that are not fully canonical. To protect new users from exploits, the XRP Ledger has a flag on transactions called [**`tfFullyCanonicalSig`**](transaction-common-fields.html#global-flags), which requires that the transaction use a _fully-canonical_ signature to be valid. If the [RequireFullyCanonicalSig amendment][] :not_enabled: is enabled, all transactions require fully-canonical signatures regardless of the `tfFullyCanonicalSig` flag, and legacy software that makes non-fully-canonical signatures is no longer compatible. To calculate a fully-canonical ECDSA signature, one must compare S and N-S to determine which is smaller, then use that value in the `Signature` field of the transaction. -All XRP Ledger software that Ripple publishes (including `rippled`, and ripple-lib/RippleAPI) generates only fully-canonical signatures. To further protect users, Ripple has configured its code to enable the **tfFullyCanonicalSig** flag by default where possible. Ripple strongly encourages third-party implementations of XRP Ledger software to generate only fully-canonical signatures, and enable tfFullyCanonicalSig on transactions by default. +All XRP Ledger software that Ripple publishes (including `rippled`, and ripple-lib/RippleAPI) generates only fully-canonical signatures. To further protect users, Ripple has configured its code to enable the **`tfFullyCanonicalSig`** flag by default where possible. Ripple strongly encourages third-party implementations of XRP Ledger software to generate only fully-canonical signatures, and enable `tfFullyCanonicalSig` on transactions by default. -There are two cases where Ripple's signing implementations for the XRP Ledger do not automatically enable the tfFullyCanonicalSig flag. Users should take care to set the flag in these situations: +There are two cases where Ripple's signing implementations for the XRP Ledger do not automatically enable the `tfFullyCanonicalSig` flag. Users should take care to set the flag in these situations: -- When the user explicitly specifies the `Flags` field of the transaction. Use bitwise OR to apply tfFullyCanonicalSig _and_ any other desired flags. -- When the user provides a multi-signature for a transaction. Since different participants in a multi-signature must sign _exactly_ the same data, the signing code does not pre-process the transaction instructions to add the tfFullyCanonicalSig flag. For multi-signed transactions, always enable the tfFullyCanonicalSig flag explicitly. +- When the user explicitly specifies the `Flags` field of the transaction. Use bitwise OR to apply `tfFullyCanonicalSig` _and_ any other desired flags. +- When the user provides a multi-signature for a transaction. Since different participants in a multi-signature must sign _exactly_ the same data, the signing code does not pre-process the transaction instructions to add the `tfFullyCanonicalSig` flag. For multi-signed transactions, always enable the `tfFullyCanonicalSig` flag explicitly. ### Malleability with Multi-Signatures @@ -77,7 +77,7 @@ Even if your authorized signers are not intentionally malicious, confusion or po - Be prepared for the possibility that a transaction executes with a different hash and set of signatures than you expected. Carefully monitor your account's sent transactions (for example, using the [account_tx method][]). - Monitor the `Sequence` number of your account (for example, using the [account_info method][]). This number always increases by exactly one when your account sends a transaction successfully, and never any other way. If the number does not match what you expect, you should check your recent transactions to confirm why. (Aside from malleable transactions, there are other ways this could happen, too. Perhaps you configured another application to send transactions for you. Maybe a malicious user gained access to your secret key. Or perhaps your application lost data and forgot about a transaction you sent already.) - If you re-create transactions to be multi-signed, _do not_ change the `Sequence` number unless you have manually confirmed that the intended actions have not already executed. -- Confirm that the tfFullyCanonicalSig flag is enabled before signing. +- Confirm that the `tfFullyCanonicalSig` flag is enabled before signing. For greater security, these guidelines provide multiple layers of protection. @@ -86,19 +86,19 @@ For greater security, these guidelines provide multiple layers of protection. If the software you use to interface with the XRP Ledger sends malleable transactions, a malicious actor may be able to trick your software into losing track of a transaction's final outcome and potentially (in the worst case) sending equivalent payments multiple times. -If you use single-signatures and always enable the tfFullyCanonicalSig flag, you are not vulnerable to this exploit. If you use multi-signatures, you may be vulnerable if you or your signers provide more signatures than necessary. +If you use single-signatures and always enable the `tfFullyCanonicalSig` flag, you are not vulnerable to this exploit. If you use multi-signatures, you may be vulnerable if you or your signers provide more signatures than necessary. ### Exploit Scenario Steps The process to exploit a vulnerable system follows a series of steps similar to the following: -1. The vulnerable system constructs and signs a transaction without enabling tfFullyCanonicalSig. +1. The vulnerable system constructs and signs a transaction without enabling `tfFullyCanonicalSig`. - Three ways that a transaction may not enable the tfFullyCanonicalSig flag are: + Three ways that a transaction may not enable the `tfFullyCanonicalSig` flag are: - - The system explicitly specifies a `Flags` field that does not have the tfFullyCanonicalSig bit enabled. - - The transaction is multi-signed and does not explicitly enable the tfFullyCanonicalSig flag. - - The system omits the `Flags` field from the transaction fields, but uses a non-standard implementation that does not automatically enable tfFullyCanonicalSig when signing. + - The system explicitly specifies a `Flags` field that does not have the `tfFullyCanonicalSig` bit enabled. + - The transaction is multi-signed and does not explicitly enable the `tfFullyCanonicalSig` flag. + - The system omits the `Flags` field from the transaction fields, but uses a non-standard implementation that does not automatically enable `tfFullyCanonicalSig` when signing. To be vulnerable, the transaction must be signed with an ECDSA key pair. If multi-signed, the transaction must be signed by at least one ECDSA key pair. @@ -138,7 +138,7 @@ The process to exploit a vulnerable system follows a series of steps similar to 8. The vulnerable system takes action assuming that the transaction has failed. - For example, it may refund (or simply not debit) a customer's balance in its own system, to account for the funds that it thinks have not been sent in the XRP Ledger. + For example, it may refund (or not debit) a customer's balance in its own system, to account for the funds that it thinks have not been sent in the XRP Ledger. Worse, the vulnerable system might construct a new transaction to replace the transaction, picking new `Sequence`, `LastLedgerSequence`, and `Fee` parameters based on the current state of the network, but keeping the rest of the transaction the same as the original. If this new transaction is also malleable, the system could be exploited in the same way an indefinite number of times. diff --git a/content/concepts/decentralized-exchange/autobridging.md b/content/concepts/decentralized-exchange/autobridging.md index 90673c8b73..c62c1307ab 100644 --- a/content/concepts/decentralized-exchange/autobridging.md +++ b/content/concepts/decentralized-exchange/autobridging.md @@ -4,7 +4,7 @@ Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentrali Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. The XRP Ledger's auto-bridging system finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._ -Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment transactions](payment.html) _do not_ autobridge by default, but path-finding can find [paths](paths.html) that have the same effect. +Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment transactions](payment.html) _do not_ use auto-bridging by default, but path-finding can find [paths](paths.html) that have the same effect. ## See Also diff --git a/content/concepts/decentralized-exchange/offers.md b/content/concepts/decentralized-exchange/offers.md index 8ee582d4d6..51cb3d0d49 100644 --- a/content/concepts/decentralized-exchange/offers.md +++ b/content/concepts/decentralized-exchange/offers.md @@ -48,7 +48,7 @@ The limit values of trust lines (See [TrustSet](trustset.html)) do not affect of However, holding non-XRP balances still requires a trust line to the address issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](reserves.html), any offers that would require a new trust line also require the address to have enough XRP to meet the reserve for that trust line. -A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits. +A trust line indicates an issuer you trust enough to accept their issued currencies as payment, within limits. Offers are explicit instructions to acquire certain issued currencies, so they are allowed to go beyond those limits. ## Offer Preference diff --git a/content/concepts/introduction/intro-to-consensus.md b/content/concepts/introduction/intro-to-consensus.md index 9c1a1165cf..a600d2eccb 100644 --- a/content/concepts/introduction/intro-to-consensus.md +++ b/content/concepts/introduction/intro-to-consensus.md @@ -46,7 +46,7 @@ As the network progresses, each server listens to its trusted validators[³](#fo [![Figure 2: Consensus rounds. Validators revise their proposals to match other validators they trust](img/consensus-rounds.png)](img/consensus-rounds.png) -It's OK if a small proportion of validators don't operate properly all the time. As long as fewer than 20% of trusted validators are faulty, consensus can continue unimpeded; and confirming an invalid transaction would require over 80% of trusted validators to collude. If more than 20% but less than 80% of trusted validators are faulty, the network simply stops making progress. +It's OK if a small proportion of validators don't work properly all the time. As long as fewer than 20% of trusted validators are faulty, consensus can continue unimpeded; and confirming an invalid transaction would require over 80% of trusted validators to collude. If more than 20% but less than 80% of trusted validators are faulty, the network stops making progress. For a longer exploration of how the XRP Ledger Consensus Protocol responds to various challenges, attacks, and failure cases, see [Consensus Protections Against Attacks and Failure Modes](consensus-protections.html). diff --git a/content/concepts/introduction/software-ecosystem.md b/content/concepts/introduction/software-ecosystem.md index c5a311537a..0f9bf17936 100644 --- a/content/concepts/introduction/software-ecosystem.md +++ b/content/concepts/introduction/software-ecosystem.md @@ -10,7 +10,7 @@ The XRP Ledger is home to a deep, layered ecosystem of software projects powerin - [_Programming Libraries_](#programming-libraries) exist in higher level software, where they are imported directly into program code, and contain methods to access the XRP Ledger. -- [_Middleware_](#middleware) provides indirect access to XRP Ledger data. Applications in this layer frequently have their own data storage and processing. +- [_Middleware_](#middleware) provides indirect access to XRP Ledger data. Applications in this layer often have their own data storage and processing. - [_Apps and Services_](#apps-and-services) provide user-level interaction with the XRP Ledger, or provide a basis for even higher-level apps and services. @@ -42,11 +42,11 @@ The [Data API](data-api.html) is an example of a middleware service on top of th ### Apps and Services -Atop the stack is where the truly exciting things happen. Apps and services provide a way for users and devices to connect to the XRP Ledger. At this level, [exchanges list XRP](list-xrp-in-your-exchange.html), [gateways issue other currencies](become-an-xrp-ledger-gateway.html) for use in the decentralized exchange, and wallets provide user interfaces for buying, selling, or just HODLing holding XRP. Many other possibilities exist, including additional services layered even higher. +Atop the stack is where the truly exciting things happen. Apps and services provide a way for users and devices to connect to the XRP Ledger. At this level, [exchanges list XRP](list-xrp-in-your-exchange.html), [gateways issue other currencies](become-an-xrp-ledger-gateway.html) for use in the decentralized exchange, and wallets provide user interfaces for buying, selling, or HODLing holding XRP. Many other possibilities exist, including additional services layered even higher. A great way to build applications that are compatible with not only XRP but lots of other ways of denominating value is to use the [Interledger Protocol][] with settlement in XRP. -There are numerous other examples of projects using XRP and adjacent technologies to interact with users. Ripple's enterprise customers already have the option to use XRP through [on-demand liquidity services](https://www.ripple.com/ripplenet/on-demand-liquidity/). For more examples of businesses and software built on the XRP Ledger, see [Xpring Partners](https://xpring.io/#partners) or XRPChat's excellent [Links & Resources](https://www.xrpchat.com/links/) listing. +There are many other examples of projects using XRP and adjacent technologies to interact with users. Ripple's enterprise customers already have the option to use XRP through [on-demand liquidity services](https://www.ripple.com/ripplenet/on-demand-liquidity/). For more examples of businesses and software built on the XRP Ledger, see [Xpring Partners](https://xpring.io/#partners) or XRPChat's excellent [Links & Resources](https://www.xrpchat.com/links/) listing. ## See Also diff --git a/content/concepts/introduction/technical-faq.md b/content/concepts/introduction/technical-faq.md index e857e7b41c..bb5cc7fe1a 100644 --- a/content/concepts/introduction/technical-faq.md +++ b/content/concepts/introduction/technical-faq.md @@ -22,7 +22,7 @@ They are the lists of transaction validators a given participant believes will n #### Which UNL should I select? -Since anybody can run a validator, the burden is on the network participants to choose a reliable set. Currently, Ripple provides a default and recommended list which we expand based on watching the history of validators operated by Ripple and third parties. Eventually, Ripple intends to remove itself from this process entirely by having network participants select their own lists based on publicly available data about validator quality. +Since anybody can run a validator, the burden is on the network participants to choose a reliable set. Currently, Ripple provides a default and recommended list which we expand based on watching the history of validators run by Ripple and third parties. Eventually, Ripple intends to remove itself from this process entirely by having network participants select their own lists based on publicly available data about validator quality. #### If Ripple recommends adoption of its UNL, doesn't that create a centralized system? @@ -34,12 +34,12 @@ No. The XRP Ledger network is opt-in. Each participant directly or indirectly ch The primary incentive to run a validator is to preserve and protect the stable operation and sensible evolution of the network. It is the validators who decide the evolution of the XRP Ledger, so any business that uses or depends on the XRP Ledger has an inherent incentive to ensure the reliability and stability of the network. -If you run an XRP Ledger server to participate in the network, the additional cost and effort to operate a validator is minimal. This means that additional incentives, such as the mining rewards in Bitcoin, are not necessary. Ripple avoids paying XRP as a reward for operating a validator so that such incentives do not warp the behavior of validators. +If you run an XRP Ledger server to participate in the network, the additional cost and effort to run a validator is minimal. This means that additional incentives, such as the mining rewards in Bitcoin, are not necessary. Ripple avoids paying XRP as a reward for operating a validator so that such incentives do not warp the behavior of validators. #### Can financial institutions set up transaction validators that will help them meet specific institutional standards and requirements? -No, institutions cannot set up customized validator policies for transaction selection. Validators either follow the protocol, or they do not. If software does not follow protocol rules, it will not function. Thus, it is not recommended that institutions seek out custom implementations without in-house expertise. +No, institutions cannot set up customized validator policies for choosing to allow some transactions and reject others. Validators either follow the protocol, or they do not. If software does not follow protocol rules, it will not function. Thus, it is not recommended that institutions seek out custom implementations without in-house expertise. #### What will happen if more than 20% of nodes within the network do not agree with the majority? How is the final version of the ledger chosen? @@ -63,7 +63,7 @@ For recommendations and best practices, see [Run `rippled` as a Validator](run-r #### Why does Ripple use XRP holdings? -Ripple's XRP holdings incentivize the company to make the XRP Ledger as useful as possible. XRP exists as a native asset in the XRP Ledger for anti-spam transaction purposes, and for currency bridging only if beneficial to users. Otherwise, the use of XRP in transactions is completely optional. +Ripple's XRP holdings incentivize the company to make the XRP Ledger as useful as possible. XRP exists as a native asset in the XRP Ledger for anti-spam transaction purposes, and for currency bridging only if beneficial to users. Otherwise, XRP is completely optional. #### How does the XRP Ledger respond to transaction floods? @@ -95,7 +95,7 @@ You don't need to use Ripple’s version of the XRP Ledger software to interact #### Does Ripple offer a secure method to download their software? -`rippled` source code is available at , where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers pre-built binary packages for CentOS, RedHat Enterprise Linux, Fedora, Ubuntu, and Debian Linux. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the cryptographic hash values of the packages that are published. +`rippled` source code is available at , where the tip of the `master`, `release` and `develop` branches always contains a version-setting commit signed by a `rippled` developer. The XRP Ledger also offers pre-built binary packages for CentOS, RedHat Enterprise Linux, Fedora, Ubuntu, and Debian Linux. Those packages are digitally signed by Ripple so that they are tamper-evident and their authenticity can be verified. Lastly, release bulletins are made available over a secure website, and include the commit ID of the repository, as well as the cryptographic hash values of the packages that are published. #### Does Ripple distinguish between the codebase for validation and the one for user software? diff --git a/content/concepts/introduction/xrp-ledger-overview.md b/content/concepts/introduction/xrp-ledger-overview.md index 39c92de0f8..8c3e5acebc 100644 --- a/content/concepts/introduction/xrp-ledger-overview.md +++ b/content/concepts/introduction/xrp-ledger-overview.md @@ -4,7 +4,7 @@ The **XRP Ledger** is a decentralized cryptographic ledger powered by a network ## The Digital Asset for Payments -XRP is a digital asset native to the XRP Ledger. Anyone with a cryptographic key and an internet connection can receive, hold, and send XRP to anyone else. XRP's creators have developed it to be a desirable bridge currency that can facilitate trades in any other currency. XRP has many properties which make it an appealing asset for many other use cases, too: +XRP is a digital asset native to the XRP Ledger. Anyone with a cryptographic key and an internet connection can receive, hold, and send XRP to anyone else. XRP's creators have developed it to be a desirable bridge currency that can enable trades in any other currency. XRP has many properties which make it an appealing asset for many other use cases, too: - **[Censorship-Resistant Transaction Processing][]:** No single party decides which XRP transactions succeed or fail, and no one can "roll back" a transaction after it completes. As long as those who choose to participate in the network keep it healthy, they can send and receive XRP in seconds. - **[Fast, Efficient Consensus Algorithm][]:** The XRP Ledger's consensus algorithm settles transactions in 4 to 5 seconds, processing at a throughput of up to 1500 transactions per second. These properties put XRP at least an order of magnitude ahead of other top digital assets. @@ -28,7 +28,7 @@ This combines qualities of physical and centralized digital money. Prior to the **Note:** Users of the XRP Ledger _can_ freeze non-XRP currencies issued in the XRP Ledger. For more information, see the [Freeze documentation](freezes.html). -The XRP Ledger's system of trusted validators uses a small amount of human interaction to achieve better distribution of authority than other decentralized systems. Fully-automated systems for reaching consensus from an unknown set of participants are vulnerable to concentrations of voting power. For example, Bitcoin mining is disproportionately concentrated in places with cheap electricity. As Ripple curates a list of distinct validators operated by different entities in different jurisdictions, the XRP Ledger can become more resistant to censorship and outside pressures than proof-of-work mining. For more information on Ripple's plan to decentralize the recommended set of validators, see the [Decentralization Strategy Update](https://xrpl.org/blog/2017/decent-strategy-update.html). +The XRP Ledger's system of trusted validators uses a small amount of human interaction to achieve better distribution of authority than other decentralized systems. Fully-automated systems for reaching consensus from an unknown set of participants are vulnerable to concentrations of voting power. For example, Bitcoin mining is disproportionately concentrated in places with cheap electricity. As Ripple curates a list of distinct validators run by different entities in different jurisdictions, the XRP Ledger can become more resistant to censorship and outside pressures than proof-of-work mining. For more information on Ripple's plan to decentralize the recommended set of validators, see the [Decentralization Strategy Update](https://xrpl.org/blog/2017/decent-strategy-update.html). For more information about the XRP Ledger's ability to detect censorship, see [Transaction Censorship Detection](transaction-censorship-detection.html). @@ -79,7 +79,7 @@ For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Mul ## Modern Features for Smart Contracts [Modern Features for Smart Contracts]: #modern-features-for-smart-contracts -Besides simple value transfer with [XRP payments](direct-xrp-payments.html), the XRP Ledger has advanced features specialized for the Internet of Value. This allows applications built on XRP to provide services and functionality that would have been impractical or impossible in the past. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful. +Besides direct value transfer with [XRP payments](direct-xrp-payments.html), the XRP Ledger has advanced features specialized for the Internet of Value. This allows applications built on XRP to provide services and functionality that would have been impractical or impossible in the past. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful. A sample of advanced features in the XRP Ledger: diff --git a/content/concepts/issued-currencies/authorized-trust-lines.md b/content/concepts/issued-currencies/authorized-trust-lines.md index 4cc6de80eb..910f662e8c 100644 --- a/content/concepts/issued-currencies/authorized-trust-lines.md +++ b/content/concepts/issued-currencies/authorized-trust-lines.md @@ -2,9 +2,9 @@ The XRP Ledger's Authorized Trust Lines feature enables a currency issuer to limit who can hold its issued (non-XRP) currencies, so that unknown XRP Ledger addresses cannot hold those currencies. The Authorized Trust Lines feature only applies to issued currencies and has no effect on XRP. -To use the Authorized Trust Lines feature, enable the RequireAuth flag on your issuing address. After doing so, your issuing address can send [TrustSet transactions][] to authorize trust lines from other addresses. While RequireAuth is enabled, other addresses can only hold funds issued by your address if the trust line to your issuing address has been authorized. +To use the Authorized Trust Lines feature, enable the `RequireAuth` flag on your issuing address. After doing so, your issuing address can send [TrustSet transactions][] to authorize trust lines from other addresses. While RequireAuth is enabled, other addresses can only hold funds issued by your address if the trust line to your issuing address has been authorized. -The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address. The process for sending funds into the XRP Ledger with RequireAuth enabled looks like the following: +The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address. The process for sending funds into the XRP Ledger with `RequireAuth` enabled looks like the following: 1. An issuing gateway publishes its issuing address to customers. 2. A customer sends a [TrustSet transaction][] to create a trust line from her XRP Ledger address to the gateway's issuing address. This indicates that she is willing to hold a specific currency issued by the gateway, up to a specific numeric limit. @@ -14,6 +14,8 @@ The transaction to authorize a trust line must be signed by the issuing address, ## RequireAuth Setting + + The `RequireAuth` setting (`requireAuthorization` in [RippleAPI](rippleapi-reference.html)) prevents all counterparties from holding balances issued by an address unless the issuing address has specifically approved a trust line with that counterparty for the currency in question. As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](issuing-and-operational-addresses.html), and then never approve any trust lines to those addresses. This prevents operational addresses and standby addresses from issuing currency in the XRP Ledger even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issued currency balances created by the issuing address, as they are intended to do. @@ -24,7 +26,7 @@ To use the Authorized Trust Lines feature, an issuer must also enable `RequireAu ### Enabling RequireAuth -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.) +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the `RequireAuth` flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.) Request: @@ -52,22 +54,23 @@ POST http://localhost:5005/ ## Checking Whether an Account Has RequireAuth Enabled -To see whether an account has the RequireAuth setting enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](accountroot.html). +To see whether an account has the `RequireAuth` setting enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](accountroot.html). -If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (0x00040000) is nonzero, then the account has RequireAuth enabled. If the result is zero, then the account has RequireAuth disabled. +If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (`0x00040000`) is nonzero, then the account has `RequireAuth` enabled. If the result is zero, then the account has `RequireAuth` disabled. ## Authorizing Trust Lines If you are using the Authorized Trust Lines feature, others cannot hold balances you issue unless you first authorize their trust lines to you. If you issue more than one currency, you must separately authorize trust lines for each currency. -To authorize a trust line, submit a [TrustSet transaction][] from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](trustset.html#trustset-flags) flag for the transaction. +To authorize a trust line, submit a [TrustSet transaction][] from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [`tfSetfAuth`](trustset.html#trustset-flags) flag for the transaction. -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW: +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` to hold USD issued by the address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`: Request: -``` +```json POST http://localhost:8088/ + { "method": "submit", "params": [ diff --git a/content/concepts/issued-currencies/demurrage.md b/content/concepts/issued-currencies/demurrage.md index 12665fb337..edacd8288d 100644 --- a/content/concepts/issued-currencies/demurrage.md +++ b/content/concepts/issued-currencies/demurrage.md @@ -27,7 +27,7 @@ D = A × ( e ^ (t ÷ τ) ) - **A** is the pre-demurrage amount as recorded in the global ledger - **e** is Euler's number - **t** is the number of seconds since the Ripple Epoch (0:00 on January 1, 2000 UTC) -- **τ** is the e-folding time in seconds. This value is [calculated from the desired interest rate](#calculating-e-folding-time). +- **τ** is the e-folding time in seconds. This value is [calculated from the desired interest rate](#calculating-e-folding-time). To convert between display amounts and ledger amounts, you can use the following steps: diff --git a/content/concepts/issued-currencies/freezes.md b/content/concepts/issued-currencies/freezes.md index f6d21b0ff9..5581483029 100644 --- a/content/concepts/issued-currencies/freezes.md +++ b/content/concepts/issued-currencies/freezes.md @@ -2,7 +2,7 @@ XRP is not an issued currency. XRP is the only native asset on the XRP Ledger and is required in order to conduct transactions on the XRP Ledger. XRP is counterparty free, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**XRP CANNOT be frozen by any entity or individual**_. -All non-XRP currencies can be represented in the XRP Ledger as issued currencies. These issued currencies (sometimes called "issuances" or "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. +All non-XRP currencies can be represented in the XRP Ledger as issued currencies. These issued currencies (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway may want to quickly freeze non-XRP issued currency balances. @@ -24,15 +24,15 @@ All freeze settings can be enacted regardless of whether the balance(s) to be fr The **Individual Freeze** feature is a setting on a [trust line](trust-lines-and-issuing.html). When an issuing address enables the Individual Freeze setting, the following rules apply to the currency of that trust line: * Payments can still occur directly between the two parties of the frozen trust line. -* The counterparty of that trust line can no longer decrease its balance on the frozen trust line, except in direct payments to the issuer. The counterparty can only send the frozen issuances directly to the issuer. +* The counterparty of that trust line can no longer decrease its balance on the frozen trust line, except in direct payments to the issuer. The counterparty can only send the frozen currencies directly to the issuer. * The counterparty can still receive payments from others on the frozen trust line. * The counterparty's offers to sell the currency issued on the frozen trust line are [considered unfunded](offers.html#lifecycle-of-an-offer). Reminder: Trust lines do not hold XRP. XRP cannot be frozen. -A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution operates that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.) +A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution uses that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.) -An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's issuances to the individual address. This type of individual freeze has no effect on offers. +An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's issued currencies to the individual address. This type of individual freeze has no effect on offers. The Individual Freeze applies to a single currency only. To freeze multiple currencies with a particular counterparty, the address must enable Individual Freeze on the trust lines for each currency individually. @@ -336,12 +336,12 @@ To see if an address has enabled Global Freeze, No Freeze, or both, use the [acc Check the value of the `account_data.Flags` field of the response using the [bitwise-AND](https://en.wikipedia.org/wiki/Bitwise_operation#AND) operator: -* If `Flags` AND `0x00400000` ([lsfGlobalFreeze](accountroot.html#accountroot-flags)) is _nonzero_: Global Freeze is enabled. -* If `Flags` AND `0x00200000` ([lsfNoFreeze](accountroot.html#accountroot-flags)) is _nonzero_: No Freeze is enabled. +* If `Flags` AND `0x00400000` ([`lsfGlobalFreeze`](accountroot.html#accountroot-flags)) is _nonzero_: Global Freeze is enabled. +* If `Flags` AND `0x00200000` ([`lsfNoFreeze`](accountroot.html#accountroot-flags)) is _nonzero_: No Freeze is enabled. Example WebSocket request: -``` +```json { "id": 1, "command": "account_info", @@ -352,7 +352,7 @@ Example WebSocket request: WebSocket response: -``` +```json { "id": 4, "status": "success", @@ -382,7 +382,7 @@ WebSocket response: } ``` -In the above example, the `Flags` value is 12582912. This indicates that has the following flags enabled: lsfGlobalFreeze, lsfDefaultRipple, as demonstrated by the following JavaScript code: +In the above example, the `Flags` value is 12582912. This indicates that has the following flags enabled: `lsfGlobalFreeze`, `lsfDefaultRipple`, as demonstrated by the following JavaScript code: ```js var lsfGlobalFreeze = 0x00400000; diff --git a/content/concepts/issued-currencies/issued-currencies-overview.md b/content/concepts/issued-currencies/issued-currencies-overview.md index 6f02d738a7..6767bd39d1 100644 --- a/content/concepts/issued-currencies/issued-currencies-overview.md +++ b/content/concepts/issued-currencies/issued-currencies-overview.md @@ -2,7 +2,7 @@ All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. -Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [NoRipple flag](rippling.html) on trust lines to prevent those trust lines from rippling. +Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling. Issued currencies can be traded with XRP or each other in the XRP Ledger's decentralized exchange. diff --git a/content/concepts/issued-currencies/issuing-and-operational-addresses.md b/content/concepts/issued-currencies/issuing-and-operational-addresses.md index ed5ee0de10..1ece84b2c8 100644 --- a/content/concepts/issued-currencies/issuing-and-operational-addresses.md +++ b/content/concepts/issued-currencies/issuing-and-operational-addresses.md @@ -9,9 +9,9 @@ All non-XRP balances in the XRP Ledger are _issued currencies_ which are tied to [![Diagram: Funds flow from the issuing address to standby addresses, to operational addresses, to customer and partner addresses, and finally back to the issuing address.](img/funds_flow_diagram.png)](img/funds_flow_diagram.png) -When the issuing address sends payments, it creates balances in the accounting relationships in the XRP Ledger. Within the XRP Ledger, users can exchange balances across different accounting relationships, so we use the term _issuances_ to describe any non-XRP balance. Issuances have negative value from the perspective of the issuing address, since they represent obligations. The same issuances have positive value from the perspective of the issuing address's counterparties. When the issuing address receives a payment, this reduces its obligations, erasing the issuances that were sent. +When the issuing address sends payments, it creates balances in the accounting relationships in the XRP Ledger. Within the XRP Ledger, users can exchange balances across different accounting relationships, so we use the term _issued currency_ to describe any non-XRP balance. (These can represent any type of value, not only "currencies" in the traditional sense.) Issued currencies have negative value from the perspective of the issuing address, since they represent obligations. The same issued currencies have positive value from the perspective of the issuing address's counterparties. When the issuing address receives a payment, this reduces its obligations, erasing the issued currencies that were sent. -The issuing address sends issuances to a standby address, or directly to an operational address. The standby addresses send those issuances to operational addresses. Operational addresses send payments to other counterparties, such as liquidity providers, partners, and other customers. Because all issuances are tied to accounting relationships with the issuing address, payments and exchanges of issuances "ripple through" the issuing address. The payment debits the sender's balance in its accounting relationship with the issuing address and credits the recipient's balance in the recipient's accounting relationship with the issuing address. The XRP Ledger also supports more complicated [paths](paths.html) that connect multiple issuers through order books and [liquidity providers who allow their funds to ripple](rippling.html). +The issuing address sends issued currencies to a standby address, or directly to an operational address. The standby addresses send those issued currencies to operational addresses. Operational addresses send payments to other counterparties, such as liquidity providers, partners, and other customers. Because all issued currencies are tied to accounting relationships with the issuing address, payments and exchanges of issued currencies "ripple through" the issuing address. The payment debits the sender's balance in its accounting relationship with the issuing address and credits the recipient's balance in the recipient's accounting relationship with the issuing address. The XRP Ledger also supports more complicated [paths](paths.html) that connect multiple issuers through order books and [liquidity providers who allow their funds to ripple](rippling.html). ## Issuing Address @@ -21,7 +21,7 @@ Unlike a vault, the issuing address can receive payments directly from customers ### Issuing Address Compromise -If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new issuances without limit and trade them in the decentralized exchange. This would make it difficult for the financial institution to distinguish legitimately-obtained issuances and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have accounting relationships with the old issuing address must create new accounting relationships with the new address. +If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new issued currencies without limit and trade them in the decentralized exchange. This would make it difficult for the financial institution to distinguish legitimately-obtained issued currencies and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have accounting relationships with the old issuing address must create new accounting relationships with the new address. ### Multiple Issuing Addresses @@ -30,9 +30,9 @@ A financial institution can issue more than one currency in the XRP Ledger from ## Operational Addresses -An operational address is like a cash register. It makes payments on behalf of the institution by transferring issuances to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create accounting relationships with an operational address. +An operational address is like a cash register. It makes payments on behalf of the institution by transferring issued currencies to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create accounting relationships with an operational address. -Each operational address has a limited balance of issuances. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address. +Each operational address has a limited balance of issued currencies. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address. ### Operational Address Compromise diff --git a/content/concepts/issued-currencies/paths.md b/content/concepts/issued-currencies/paths.md index 04dda0ecaf..a832de6d14 100644 --- a/content/concepts/issued-currencies/paths.md +++ b/content/concepts/issued-currencies/paths.md @@ -13,7 +13,7 @@ A path is made of steps that connect the sender to the receiver of the payment. * Rippling through another address with the same currency * Exchanging currency at an order book -Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the NoRipple Flag](rippling.html) for more examples of rippling. +Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the No Ripple Flag](rippling.html) for more examples of rippling. In the case of a currency exchange step, the path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) @@ -42,7 +42,7 @@ By convention, several steps of a path are implied by the [fields of the Payment * The first step of a path is always implied to be the sender of the transaction, as defined by the transaction's `Account` field. * If the transaction includes a `SendMax` field with an `issuer` that is not the sender of the transaction, that issuer is implied to be the second step of the path. - * If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines in the given currency. See [special values for SendMax and Amount](payment.html#special-issuer-values-for-sendmax-and-amount) for details. + * If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines in the given currency. See [special values for `SendMax` and `Amount`](payment.html#special-issuer-values-for-sendmax-and-amount) for details. * If the `Amount` field of the transaction includes an `issuer` that is not the same as the `Destination` of the transaction, that issuer is implied to be the second-to-last step of the path. * Finally, last step of a path is always implied to be the receiver of a transaction, as defined by the transaction's `Destination` field. @@ -89,9 +89,9 @@ The `type` field, used for the binary serialization of a path set, is actually c | Value (Hex) | Value (Decimal) | Description | |-------------|-----------------|-------------| -| 0x01 | 1 | A change of address (rippling): the `account` field is present. | -| 0x10 | 16 | A change of currency: the `currency` field is present. | -| 0x20 | 32 | A change of issuer: the `issuer` field is present. | +| `0x01` | 1 | A change of address (rippling): the `account` field is present. | +| `0x10` | 16 | A change of currency: the `currency` field is present. | +| `0x20` | 32 | A change of issuer: the `issuer` field is present. | ## See Also diff --git a/content/concepts/issued-currencies/rippling.md b/content/concepts/issued-currencies/rippling.md index 2270375949..b3cf3bf61c 100644 --- a/content/concepts/issued-currencies/rippling.md +++ b/content/concepts/issued-currencies/rippling.md @@ -4,9 +4,9 @@ In the XRP Ledger, "rippling" describes a process of atomic net settlement betwe Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling. -For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [NoRipple Flag](#the-noripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag). +For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [No Ripple Flag](#the-noripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag). -**Caution:** If you create a trust line to another address, you must explicitly enable the tfSetNoRipple flag to block rippling on your side of that trust line. +**Caution:** If you create a trust line to another address, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line. ## Example of Rippling @@ -20,13 +20,13 @@ If Bob wants to pay $3 to Charlie, then he could say, "Alice, take $3 of the mon We call this process, where two addresses pay each other by adjusting the balances of trust lines in between them, "rippling". This is a useful and important feature of the XRP Ledger. Rippling occurs when addresses are linked by trust lines that use the same [currency code][]. The issuer does not need to be the same: in fact, larger chains always involve changing issuers. -## The NoRipple Flag +## The No Ripple Flag Non-issuing accounts, especially liquidity providers who may hold balances from different issuers with different fees and policies, usually do not want their balances to ripple. -The "NoRipple" flag is a setting on a trust line. When two trust lines both have NoRipple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers of the same currency. +The **No Ripple** flag is a setting on a trust line. When two trust lines both have No Ripple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers of the same currency. -An account can disable NoRipple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling by default by enabling the [DefaultRipple flag](#the-defaultripple-flag). +An account can disable No Ripple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag). For example, imagine Emily has money issued by two different financial institutions, like so @@ -36,49 +36,49 @@ Now Charlie can pay Daniel by rippling through Emily's address. For example, if ![Charlie --($0)-- Institution A --($11)-- Emily --($90)-- Institution B --($12)-- Daniel](img/noripple-04.png) -This may surprise Emily, who does not know Charlie or Daniel. Even worse, if Institution A charges her higher fees to withdraw her money than Institution B, this could cost Emily money. The NoRipple flag exists to avoid this scenario. If Emily sets it on both trust lines, then payments cannot ripple through her address using those two trust lines. +This may surprise Emily, who does not know Charlie or Daniel. Even worse, if Institution A charges her higher fees to withdraw her money than Institution B, this could cost Emily money. The No Ripple flag exists to avoid this scenario. If Emily sets it on both trust lines, then payments cannot ripple through her address using those two trust lines. For example: -![Charlie --($10)-- Institution A --($1, NoRipple)-- Emily --($100,NoRipple)-- Institution B --($2)-- Daniel](img/noripple-05.png) +![Charlie --($10)-- Institution A --($1, No Ripple)-- Emily --($100,No Ripple)-- Institution B --($2)-- Daniel](img/noripple-05.png) Now the above scenario, where Charlie pays Daniel while rippling through Emily's address, is no longer possible. ### Specifics -The NoRipple flag makes certain paths invalid, so that they cannot be used to make payments. A path is considered invalid if and only if it enters **and** exits an address node through trust lines where NoRipple has been enabled for that address. +The No Ripple flag makes certain paths invalid, so that they cannot be used to make payments. A path is considered invalid if and only if it enters **and** exits an address node through trust lines where No Ripple has been enabled for that address. -![Diagram demonstrating that NoRipple has to be set on both trust lines by the same address to do anything](img/noripple-06.png) +![Diagram demonstrating that No Ripple has to be set on both trust lines by the same address to do anything](img/noripple-06.png) -## The DefaultRipple Flag +## The Default Ripple Flag -The DefaultRipple flag is an account setting that enables rippling on all incoming trust lines by default. Gateways and other currency issuers MUST enable this flag for their customers to be able to send those currencies to each other. +The **Default Ripple** flag is an account setting that enables rippling on all incoming trust lines by default. Gateways and other currency issuers MUST enable this flag for their customers to be able to send those currencies to each other. -The DefaultRipple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the DefaultRipple setting of your account, trust lines that were created before the change keep their existing NoRipple settings. You can use a [TrustSet transaction][] to change the NoRipple setting of a trust line to match your address's new default. +The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a [TrustSet transaction][] to change the No Ripple setting of a trust line to match your address's new default. -For more information, see [DefaultRipple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#defaultripple). +For more information, see [Default Ripple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#defaultripple). -## Using NoRipple +## Using No Ripple -### Enabling / Disabling NoRipple +### Enabling / Disabling No Ripple -The NoRipple flag can only be enabled on a trust line if the address has a positive or zero balance on that trust line. This is so that the feature cannot be abused to default on the obligation the trust line balance represents. (Of course, you can still default by abandoning the address.) +The No Ripple flag can only be enabled on a trust line if the address has a positive or zero balance on that trust line. This is so that the feature cannot be abused to default on the obligation the trust line balance represents. (Of course, you can still default by abandoning the address.) -In the [`rippled` APIs](rippled-api.html), you can enable the NoRipple flag by sending a [TrustSet transaction][] with the `tfSetNoRipple` flag. You can disable NoRipple (enable rippling) with the `tfClearNoRipple` flag. +In the [`rippled` APIs](rippled-api.html), you can enable the No Ripple flag by sending a [TrustSet transaction][] with the `tfSetNoRipple` flag. You can disable No Ripple (enable rippling) with the `tfClearNoRipple` flag. -In [RippleAPI](rippleapi-reference.html), you can enable the NoRipple flag by sending a [Trustline transaction](rippleapi-reference.html#preparetrustline) transaction with the `ripplingDisabled` field of the trust line set to `true`. +In [RippleAPI](rippleapi-reference.html), you can enable the No Ripple flag by sending a [Trustline transaction](rippleapi-reference.html#preparetrustline) transaction with the `ripplingDisabled` field of the trust line set to `true`. -### Looking Up NoRipple Status +### Looking Up No Ripple Status -In the case of two accounts that mutually trust each other, the NoRipple flag is tracked separately for each account. +In the case of two accounts that mutually trust each other, the No Ripple flag is tracked separately for each account. -In the [`rippled` APIs](rippled-api.html), you can use the [account_lines method][] to look up the trust lines associated with an address. For each trust line, the `no_ripple` field shows whether the current address has enabled the NoRipple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the NoRipple flag. +In the [`rippled` APIs](rippled-api.html), you can use the [account_lines method][] to look up the trust lines associated with an address. For each trust line, the `no_ripple` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the No Ripple flag. -In [RippleAPI](rippleapi-reference.html), you can use the [getTrustlines](rippleapi-reference.html#gettrustlines) method to look up the trust lines associated with an address. For each trust line, the `ripplingDisabled` field shows whether the current address has enabled the NoRipple flag on that trust line, and the `counterparty.ripplingDisabled` field shows whether the counterparty has enabled the NoRipple flag. +In [RippleAPI](rippleapi-reference.html), you can use the [`getTrustlines` method](rippleapi-reference.html#gettrustlines) to look up the trust lines associated with an address. For each trust line, the `ripplingDisabled` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `counterparty.ripplingDisabled` field shows whether the counterparty has enabled the No Ripple flag. ## See Also diff --git a/content/concepts/issued-currencies/transfer-fees.md b/content/concepts/issued-currencies/transfer-fees.md index 1bad083325..7b7a41113d 100644 --- a/content/concepts/issued-currencies/transfer-fees.md +++ b/content/concepts/issued-currencies/transfer-fees.md @@ -7,7 +7,7 @@ The `TransferRate` setting in the XRP Ledger allows [financial institutions that XRP never has a transfer fee, because it never has an issuer. -For example, ACME Bank might set the transfer fee to 1% for ACME issuances. For the recipient of a payment to get 2 EUR.ACME, the sender must send 2.02 EUR.ACME. After the transaction, ACME's outstanding obligations in the XRP Ledger have decreased by 0.02€, which means that ACME no longer needs to hold that amount in the account backing its XRP Ledger issuances. +For example, ACME Bank might set the transfer fee to 1%. For the recipient of a payment to get 2 EUR.ACME, the sender must send 2.02 EUR.ACME. After the transaction, ACME's outstanding obligations in the XRP Ledger have decreased by 0.02€, which means that ACME no longer needs to hold that amount in the account backing its issued currencies. The following diagram shows an XRP Ledger payment of 2 EUR.ACME from Alice to Charlie with a transfer fee of 1%: @@ -17,7 +17,7 @@ The following diagram shows an XRP Ledger payment of 2 EUR.ACME from Alice to Ch -A transfer fee applies whenever an individual transfer would shift issuances from one party to another through the issuing account. In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example: +A transfer fee applies whenever an individual transfer would move issued currency from one party to another through the issuing account. In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example: ![Diagram of cross-currency payment with transfer fees](img/transfer_fees_example.png) @@ -27,25 +27,27 @@ In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to de * FXMaker's current ask is 90.18 EUR.ACME to send 100.20 USD.WayGate. * For FXMaker to receive 90.18 EUR.ACME, Salazar must send 91.0818 EUR.ACME. + + # Technical Details -The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The TransferRate setting applies to all currencies issued by the same account. If you want to have different transfer fee percentages for different currencies, use different [issuing addresses][issuing address] for each currency. +The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The transfer fee applies to all currencies issued by the same account. If you want to have different transfer fees for different currencies, use different [issuing addresses][issuing address] for each currency. -**Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to operate at their stated rate. +**Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to apply at their stated rate. ## RippleAPI In RippleAPI, the transfer fee is specified in the `transferRate` field, as a decimal which represents the amount you must send for the recipient to get 1 unit of the same currency. A `transferRate` of `1.005` is equivalent to a transfer fee of 0.5%. By default, the `transferRate` is set to no fee. The value of `transferRate` cannot be less than `1.0` or more than `2.0`. The transfer rate is rounded to 10 significant digits including the ones digit. The value `null` is a special case for no fee, equivalent to `1.0`. -A financial institution can send a [Settings transaction](rippleapi-reference.html#settings) from its [issuing address][] to change the `transferRate` for its issuances. +A financial institution can send a [Settings transaction](rippleapi-reference.html#settings) from its [issuing address][] to change the `transferRate` for all its issued currencies. -You can check an account's `transferRate` with the [getSettings method](rippleapi-reference.html#getsettings). +You can check an account's `transferRate` with the [`getSettings` method](rippleapi-reference.html#getsettings). ## rippled In `rippled`'s JSON-RPC and WebSocket APIs, the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same currency. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` ("0%" fee) or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`. -A financial institution can submit an [AccountSet transaction][] from its [issuing address][] to change the `TransferRate` for its issuances. +A financial institution can submit an [AccountSet transaction][] from its [issuing address][] to change the `TransferRate` for all its issued currencies. You can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee. diff --git a/content/concepts/issued-currencies/trust-lines-and-issuing.md b/content/concepts/issued-currencies/trust-lines-and-issuing.md index 7a839bb786..40d50503c7 100644 --- a/content/concepts/issued-currencies/trust-lines-and-issuing.md +++ b/content/concepts/issued-currencies/trust-lines-and-issuing.md @@ -1,6 +1,6 @@ # Trust Lines and Issuing -Frequently, [issued currencies](issued-currencies.html) in the XRP Ledger, represent value held by _gateways_ in the world outside the XRP Ledger. The address that issues those funds in the XRP Ledger is expected to pay the balance back, outside of the XRP Ledger, when users redeem their XRP Ledger balances by returning them to the issuer. +[Issued currencies](issued-currencies.html) in the XRP Ledger often represent value held by _gateways_ in the world outside the XRP Ledger. The address that issues those funds in the XRP Ledger is expected to pay the balance back, outside of the XRP Ledger, when users redeem their XRP Ledger balances by returning them to the issuer. Since a computer program cannot force a someone to keep a promise in the outside world, trust lines represent a way of configuring how much you trust an issuer to hold on your behalf. Since a large, reputable financial institution is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuer "owe" you in the XRP Ledger. If the issuer defaults or goes out of business, you can lose up to that much money because the balances you hold in the XRP Ledger can no longer be exchanged for equivalent balances elsewhere. (You can still keep or trade the issued currency in the XRP Ledger, but there is probably no longer any reason to consider that issued currency to be worth anything.) @@ -16,7 +16,7 @@ Trust lines are represented in the ledger's state data as [RippleState objects]( A trust line with settings in the default state is equivalent to no trust line. -The default state of all trust line flags is off, except for the [No Ripple flag](rippling.html), whose default state depends on the `DefaultRipple` flag. +The default state of all trust line flags is off, except for the [No Ripple flag](rippling.html), whose default state depends on the Default Ripple flag. ## See Also diff --git a/content/concepts/payment-system-basics/accounts/accounts.md b/content/concepts/payment-system-basics/accounts/accounts.md index dcafa72758..4f6dd61584 100644 --- a/content/concepts/payment-system-basics/accounts/accounts.md +++ b/content/concepts/payment-system-basics/accounts/accounts.md @@ -27,7 +27,7 @@ The typical way to get an account in the XRP Ledger is as follows: 2. Have someone who already has an account in the XRP Ledger send XRP to the address you generated. - - For example, you can purchase XRP in a private exchange, then withdraw XRP from the exchange to the address you specified. + - For example, you can buy XRP in a private exchange, then withdraw XRP from the exchange to the address you specified. **Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.html) (currently 20 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price. diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md index 16a1a7fe64..4c63e4185d 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md @@ -97,14 +97,14 @@ After you assign a regular key pair to an account, the account has two key pairs You can assign one regular key pair to an account and use it to sign all transactions, except for the ones reserved for the [master key pair](#master-key-pair). -You can remove or change a regular key pair at any time. This means that if a regular secret key is compromised (but the master secret key is not), you can regain control of your account by simply removing or changing the regular key pair. +You can remove or change a regular key pair at any time. This means that if a regular secret key is compromised (but the master secret key is not), you can regain control of your account by removing or changing the regular key pair. For a tutorial on changing or removing a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html). ## Signing Algorithms -Cryptographic key pairs are always tied to a specific signing algorithm, which defines the mathematical relationships between the secret key and the public key. Cryptographic signing algorithms have the property that, given the current state of cryptographic techniques, it is "easy" to use a secret key to calculate a matching public key, but it is effectively impossible to compute a matching secret key by starting from a public key. +Cryptographic key pairs are always tied to a specific signing algorithm, which defines the mathematical relationships between the secret key and the public key. Cryptographic signing algorithms have the property that, given the current state of cryptographic techniques, it is "easy" to use a secret key to calculate a matching public key, but it is effectively impossible to compute a matching secret key by starting from a public key. The XRP Ledger supports the following cryptographic signing algorithms: @@ -190,7 +190,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu 2. Convert the root public key to its 33-byte compressed form. - The uncompressed form of any ECDSA public key consists of a pair of 32-byte integers: an X coordinate, and a Y coordinate. The compressed form is just the X coordinate and a one-byte prefix: `0x02` if the Y coordinate is even, or `0x03` if the Y coordinate is odd. + The uncompressed form of any ECDSA public key consists of a pair of 32-byte integers: an X coordinate, and a Y coordinate. The compressed form is the X coordinate and a one-byte prefix: `0x02` if the Y coordinate is even, or `0x03` if the Y coordinate is odd. You can convert an uncompressed public key to the compressed form with the `openssl` commandline tool. For example, if the uncompressed public key is in the file `ec-pub.pem`, you can output the compressed form like this: @@ -211,7 +211,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu 4. Derive the master public key pair by adding the intermediate public key to the root public key. Similarly, derive the secret key by adding the intermediate secret key to the root secret key. - - An ECDSA secret key is just a very large integer, so you can calculate the sum of two secret keys by summing them modulo the secp256k1 group order. + - An ECDSA secret key is a very large integer, so you can calculate the sum of two secret keys by summing them modulo the secp256k1 group order. - An ECDSA public key is a point on the elliptic curve, so you should use elliptic curve math to sum the points. diff --git a/content/concepts/payment-system-basics/accounts/depositauth.md b/content/concepts/payment-system-basics/accounts/depositauth.md index 2c34907cfb..9ff4c6cd08 100644 --- a/content/concepts/payment-system-basics/accounts/depositauth.md +++ b/content/concepts/payment-system-basics/accounts/depositauth.md @@ -24,7 +24,7 @@ To receive money from [Payment transactions][] when you have Deposit Authorizati To get the full effect of Deposit Authorization, Ripple recommends also doing the following: - Always maintain an XRP balance higher than the minimum [reserve requirement](reserves.html). -- Keep the `DefaultRipple` flag in its default (disabled) state. Do not enable [rippling](rippling.html) on any trust lines. When sending [TrustSet transactions][], always use the [`tfSetNoRipple` flag](trustset.html). +- Keep the Default Ripple flag in its default (disabled) state. Do not enable [rippling](rippling.html) on any trust lines. When sending [TrustSet transactions][], always use the [`tfSetNoRipple` flag](trustset.html). - Do not place [Offers](offercreate.html). It is impossible to know in advance which matching offers will be consumed to execute such a trade. ## Precise Semantics @@ -43,7 +43,7 @@ An account with Deposit Authorization enabled: - **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Added by the [Checks amendment][].)_ - **Can** receive XRP or issued currencies by sending [OfferCreate transactions][]. - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions. -- If the account has created any trust lines without the [NoRipple flag](rippling.html) enabled, or has enabled the `DefaultRipple` flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. +- If the account has created any trust lines without the [No Ripple flag](rippling.html) enabled, or has enabled the Default Ripple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. - In general, an account in the XRP Ledger **cannot** receive any non-XRP currencies in the XRP Ledger as long as all of the following are true. (This rule is not specific to the DepositAuth flag.) - The account has not created any trust lines with a nonzero limit. - The account has not issued currency on trust lines created by others diff --git a/content/concepts/payment-system-basics/fees.md b/content/concepts/payment-system-basics/fees.md index 8c2aaf87a8..3136dda294 100644 --- a/content/concepts/payment-system-basics/fees.md +++ b/content/concepts/payment-system-basics/fees.md @@ -1,6 +1,6 @@ # Fees (Disambiguation) -The XRP Ledger is a decentralized ledger, secured by cryptography and operated by a distributed peer-to-peer network of servers. This means that no one party, not even Ripple, can require a fee for access to the network. +The XRP Ledger is a decentralized ledger, secured by cryptography and powered by a distributed peer-to-peer network of servers. This means that no one party, not even Ripple, can require a fee for access to the network. However, the rules of the XRP Ledger include several types of fees, including neutral fees which protect the ledger against abuse. These neutral fees are not paid to anyone. There are also several optional ways that users can collect fees from each other, both inside and outside the XRP Ledger. diff --git a/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md b/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md index e4d1b2d2f0..46f9a298d4 100644 --- a/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md +++ b/content/concepts/payment-system-basics/transaction-basics/transaction-basics.md @@ -2,7 +2,7 @@ A _Transaction_ is the only way to modify the XRP Ledger. Transactions are only final if signed, submitted, and accepted into a validated ledger version following the [consensus process](consensus.html). Some ledger rules also generate _[pseudo-transactions](pseudo-transaction-types.html)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][]. -Transactions can do more than just send money. In addition to supporting various [Payment Types](payment-types.html), transactions in the XRP Ledger are also used to rotate [cryptographic keys](cryptographic-keys.html), manage other settings, and trade in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). The [`rippled` API reference](rippled-api.html) has a complete [list of transaction types](transaction-types.html). +Transactions can do more than send money. In addition to supporting various [Payment Types](payment-types.html), transactions in the XRP Ledger are also used to rotate [cryptographic keys](cryptographic-keys.html), manage other settings, and trade in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). The [`rippled` API reference](rippled-api.html) has a complete [list of transaction types](transaction-types.html). ### Identifying Transactions diff --git a/content/concepts/payment-types/checks.md b/content/concepts/payment-types/checks.md index b548ea1f63..aba6d50dc4 100644 --- a/content/concepts/payment-types/checks.md +++ b/content/concepts/payment-types/checks.md @@ -2,7 +2,7 @@ _(Added by the [Checks amendment][].)_ -The Checks feature in the XRP Ledger allows users to create deferred payments that can be canceled or cashed by the intended recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it, just like traditional checks. If there's a failure cashing the check, the check's recipient can retry until the Check expires. +The Checks feature in the XRP Ledger allows users to create deferred payments that can be canceled or cashed by the intended recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it, like traditional checks. If there's a failure cashing the check, the check's recipient can retry until the Check expires. XRP Ledger Checks have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires or is cashed. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. diff --git a/content/concepts/payment-types/cross-currency-payments.md b/content/concepts/payment-types/cross-currency-payments.md index fdec998f13..a54c2ed65d 100644 --- a/content/concepts/payment-types/cross-currency-payments.md +++ b/content/concepts/payment-types/cross-currency-payments.md @@ -10,7 +10,7 @@ By default, cross-currency payments deliver a fixed amount to their destination - By definition, a cross-currency payment involves at least two currencies, which means that at least one currency involved must be a non-XRP issued currency. - Typically, this means using one or more currencies issued by an [XRP Ledger Gateway](become-an-xrp-ledger-gateway.html). Such currencies are backed by funds outside the XRP Ledger, and can be withdrawn through the gateway. - Issued currencies can also be digital tokens that are only issued within the XRP Ledger, with no outside backing. Of course, the parties involved must be willing to send or receive those tokens and treat them as something of value. -- There must be at least one [Path](paths.html) between the sender and receiver, and the total liquidity across all paths must be enough to facilitate the payment. Cross-currency payments convert from one currency to another by consuming [Offers](offers.html) in the XRP Ledger's decentralized exchange. +- There must be at least one [Path](paths.html) between the sender and receiver, and the total liquidity across all paths must be enough to execute the payment. Cross-currency payments convert from one currency to another by consuming [Offers](offers.html) in the XRP Ledger's decentralized exchange. ## Auto-Bridging diff --git a/content/concepts/payment-types/partial-payments.md b/content/concepts/payment-types/partial-payments.md index 1c38def8d1..c44b1f5e2b 100644 --- a/content/concepts/payment-types/partial-payments.md +++ b/content/concepts/payment-types/partial-payments.md @@ -36,7 +36,7 @@ Partial Payments have the following limitations: - A partial payment cannot provide the XRP to fund an address; this case returns the [result code][] `telNO_DST_PARTIAL`. - Direct XRP-to-XRP payments cannot be partial payments; this case returns the [result code][] `temBAD_SEND_XRP_PARTIAL`. - - However, issuance-to-XRP payments or XRP-to-issuance payments _can_ be partial payments. + - However, cross-currency payments that involve XRP as one of the currencies _can_ be partial payments. [result code]: transaction-results.html @@ -80,7 +80,7 @@ If a financial institution's integration with the XRP Ledger assumes that the `A To exploit a vulnerable financial institution, a malicious actor does something like this: -1. The malicious actor sends a Payment transaction to the institution. This transaction has a large `Amount` field and has the **tfPartialPayment** flag enabled. +1. The malicious actor sends a Payment transaction to the institution. This transaction has a large `Amount` field and has the **`tfPartialPayment`** flag enabled. 2. The partial payment succeeds (result code `tesSUCCESS`) but actually delivers a very small amount of the currency specified. 3. The vulnerable institution reads the transaction's `Amount` field without looking at the `Flags` field or `delivered_amount` metadata field. 4. The vulnerable institution credits the malicious actor in an external system, such as the institution's own ledger, for the full `Amount`, despite only receiving a much smaller `delivered_amount` in the XRP Ledger. @@ -92,7 +92,7 @@ In the case of a merchant, the order of operations is slightly different, but th 1. The malicious actor requests to buy a large amount of goods or services. 2. The vulnerable merchant invoices the malicious actor for the price of those goods and services. -3. The malicious actor sends a Payment transaction to the merchant. This transaction has a large `Amount` field and has the **tfPartialPayment** flag enabled. +3. The malicious actor sends a Payment transaction to the merchant. This transaction has a large `Amount` field and has the **`tfPartialPayment`** flag enabled. 4. The partial payment succeeds (result code `tesSUCCESS`) but delivers only a very small amount of the currency specified. 5. The vulnerable merchant reads the transaction's `Amount` field without looking at the `Flags` field or `delivered_amount` metadata field. 6. The vulnerable merchant treats the invoice as paid and provides the goods or services to the malicious actor, despite only receiving a much smaller `delivered_amount` in the XRP Ledger. diff --git a/content/concepts/the-rippled-server/ledger-history/history-sharding.md b/content/concepts/the-rippled-server/ledger-history/history-sharding.md index 2f81085576..d6f70641a1 100644 --- a/content/concepts/the-rippled-server/ledger-history/history-sharding.md +++ b/content/concepts/the-rippled-server/ledger-history/history-sharding.md @@ -2,7 +2,7 @@ [Introduced in: rippled 0.90.0][] -As servers operate, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each `rippled` server stores that ledger data in its ledger store, but the online delete logic rotates these databases when the number of stored ledgers exceeds configured space limitations. +As servers run, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each `rippled` server stores that ledger data in its ledger store, but the online delete logic rotates these databases when the number of stored ledgers exceeds configured space limitations. Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers. A `rippled` server stores ledgers in both the ledger store and the shard store in the same way. diff --git a/content/concepts/the-rippled-server/ledger-history/online-deletion.md b/content/concepts/the-rippled-server/ledger-history/online-deletion.md index 50c37d6ae6..43e94c40ee 100644 --- a/content/concepts/the-rippled-server/ledger-history/online-deletion.md +++ b/content/concepts/the-rippled-server/ledger-history/online-deletion.md @@ -22,7 +22,7 @@ Inside the ledger store, ledger data is "de-duplicated". In other words, data th The online deletion settings configure how many ledger versions the `rippled` server should keep available in the ledger store at a time. However, the specified number is a guideline, not a hard rule: - The server never deletes data more recent than the configured number of ledger versions, but it may have less than that amount available if it has not been running for long enough or if it lost sync with the network at any time. (The server attempts to backfill at least some history; see [fetching history](ledger-history.html#fetching-history) for details.) -- The server may store up to just over twice the configured number of ledger versions if online deletion is set to run automatically. (Each time it runs, it reduces the number of stored ledger versions to approximately the configured number.) +- The server may store up to slightly over twice the configured number of ledger versions if online deletion is set to run automatically. (Each time it runs, it reduces the number of stored ledger versions to approximately the configured number.) If online deletion is delayed because the server is busy, ledger versions can continue to accumulate. When functioning normally, online deletion begins when the server has twice the configured number of ledger versions, but it may not complete until after several more ledger versions have accumulated. @@ -82,9 +82,9 @@ The following settings relate to online deletion: The `fetch_depth` setting cannot be higher than `online_delete` if both are specified. If `fetch_depth` is set higher, the server treats it as equal to `online_delete` instead. - The following diagram shows how fetch_depth works: + The following diagram shows how `fetch_depth` works: - ![Ledger versions older than fetch_depth are not served to peers](img/fetch_depth.png) + ![Ledger versions older than `fetch_depth` are not served to peers](img/fetch_depth.png) For estimates of how much disk space is required to store different amounts of history, see [Capacity Planning](capacity-planning.html#disk-space). diff --git a/content/concepts/the-rippled-server/peer-protocol.md b/content/concepts/the-rippled-server/peer-protocol.md index f61e95ce8c..8426675bf2 100644 --- a/content/concepts/the-rippled-server/peer-protocol.md +++ b/content/concepts/the-rippled-server/peer-protocol.md @@ -55,7 +55,7 @@ The node key pair also identifies other servers for purposes of [clustering](clu Normally, a `rippled` server attempts to maintain a healthy number of peers, and automatically connects to untrusted peers up to a maximum number. You can configure a `rippled` server to remain connected to specific peer servers in several ways: - Use **Fixed Peers** to remain always connected to specific other peers based on their IP addresses. This only works if the peers have fixed IP addresses. Use the `[ips_fixed]` config stanza to configure fixed peers. This is a necessary part of [clustering](clustering.html) or [private peers](#private-peers). Fixed peers are defined in the config file, so changes only apply after restarting the server. Fixed peers are most useful for keeping servers connected if those servers are run by the same person or organization. -- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers operated by different people or organizations. [New in: rippled 1.4.0][] +- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers run by different people or organizations. [New in: rippled 1.4.0][] In the following cases, a `rippled` server does not connect to untrusted peers: @@ -98,12 +98,12 @@ The pros and cons of each configuration are as follows: Discovered Peers

  • Simplest configuration, with a low maintenance burden.

    • -

  • Creates the opportunity for a lot of direct peer connections. Having more direct peers comes with several benefits. Your server can fetch history from multiple peers in parallel, both when syncing and when backfilling history. Since not all peers maintain full history, having access to more peers can also provide access to a wider selection of historical data.

    • +

  • Creates the opportunity for a lot of direct peer connections. Having more direct peers comes with several benefits. Your server can fetch history from multiple peers in parallel, both when syncing and when backfilling history. Since not all peers maintain full history, having access to more peers can also provide access to a wider range of historical data.

  • Lowers the possibility of disconnecting from the network because your server can replace disconnected peers with new ones.

  • Doesn't allow you to select your server's peers, which means that you have no idea whether your peers may decide to act maliciously. Although `rippled` servers are designed to protect against malicious peers, there is always a risk that malicious peers could exploit software flaws to affect your server.

    • -

  • Your server's peers may disconnect or change frequently.

    • +

  • Your server's peers may disconnect or change often.

Private Server Using Proxies @@ -121,7 +121,7 @@ The pros and cons of each configuration are as follows: 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/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/ledger-data-formats/ledger-object-types/accountroot.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md index e166548742..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 @@ -63,7 +63,7 @@ AccountRoot objects can have the following flag values: | `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 issuances. | +| `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/ripplestate.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md index 24adb9b05c..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 @@ -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 No Ripple 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 4c3520e019..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 @@ -67,7 +67,7 @@ Each member of the `SignerEntries` field is an object that describes that signer | `Account` | String | AccountID | An XRP Ledger address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. | | `SignerWeight` | Number | UInt16 | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the signer list's `SignerQuorum` value. | -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 diff --git a/content/references/rippled-api/peer-crawler.md b/content/references/rippled-api/peer-crawler.md index b97157f778..9f63b667f4 100644 --- a/content/references/rippled-api/peer-crawler.md +++ b/content/references/rippled-api/peer-crawler.md @@ -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 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 db16206d93..b405a1b0a2 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 @@ -176,12 +176,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/noripple_check.md b/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md index 1520407a6b..74fe09e31f 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,7 +1,7 @@ # 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 No Ripple 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: @@ -48,7 +48,7 @@ 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 +62,7 @@ An example of a successful response: *WebSocket* -``` +```json { "id": 0, "status": "success", @@ -114,8 +114,9 @@ An example of a successful response: *JSON-RPC* -``` +```json 200 OK + { "result": { "ledger_current_index": 14380381, @@ -170,7 +171,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/public-rippled-methods.md b/content/references/rippled-api/public-rippled-methods/public-rippled-methods.md index 4bba5b92da..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,7 +15,7 @@ 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 No Ripple settings. +* **[`noripple_check`](noripple_check.html)** - Get recommended changes to an account's Default Ripple and No Ripple settings. ## [Ledger Methods](ledger-methods.html) 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 dae08ef865..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,7 +491,7 @@ 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`. | +| `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][] | 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 4eddb47a83..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][] | 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 b60b264d2b..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 @@ -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/transaction-formats/transaction-common-fields.md b/content/references/rippled-api/transaction-formats/transaction-common-fields.md index ddf6a8fc27..cc22130212 100644 --- a/content/references/rippled-api/transaction-formats/transaction-common-fields.md +++ b/content/references/rippled-api/transaction-formats/transaction-common-fields.md @@ -70,7 +70,7 @@ The only flag that applies globally to all transactions is as follows: 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 @@ -95,7 +95,7 @@ The `Memos` field includes arbitrary messaging data with the transaction. It is | `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 1 KB in size (when serialized in binary format). @@ -123,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-types/accountset.md b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md index 18c656da76..3560aba540 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md @@ -63,7 +63,7 @@ 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) | +| `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). | 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/payment.md b/content/references/rippled-api/transaction-formats/transaction-types/payment.md index aaf058485d..3c279cdd21 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/payment.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/payment.md @@ -29,7 +29,7 @@ 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. | +| `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. | @@ -57,6 +57,8 @@ 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 the issued currency, instead of the address that issued the currency. @@ -98,7 +100,7 @@ Transactions of the Payment type support additional values in the [`Flags` field 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/validator-list.md b/content/references/rippled-api/validator-list.md index 451298b1c0..72b3c40156 100644 --- a/content/references/rippled-api/validator-list.md +++ b/content/references/rippled-api/validator-list.md @@ -20,7 +20,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 diff --git a/content/references/xrp-ledger-toml.md b/content/references/xrp-ledger-toml.md index f42fd413df..ffa44978f5 100644 --- a/content/references/xrp-ledger-toml.md +++ b/content/references/xrp-ledger-toml.md @@ -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: @@ -340,7 +340,7 @@ Update [the contents of your `xrp-ledger.toml` file](#contents) with the `attest ## 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: @@ -356,7 +356,7 @@ Account verification requires establishing a two-way link between the domain ope 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 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.md b/content/tutorials/manage-account-settings/offline-account-setup.md index 335d3d829e..0cb3c033a3 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 @@ -70,6 +70,8 @@ Take note of the following values: **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-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. - 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. + - [Set a Transfer Fee](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. 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/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..df457c3712 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,77 +1,77 @@ -# Connect Your rippled to an XRPL Altnet +# Connect Your rippled to an XRP Ledger Altnet -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. To connect your `rippled` server to the XRP Testnet or Devnet, set the following configurations: -1. In your `rippled.cfg` file: +1. Edit your `rippled.cfg` file to connect to a hub server in the network you want to connect to. - a. To connect to the [Testnet](xrp-testnet-faucet.html), uncomment the following section and add: + 1. To connect to the [Testnet](xrp-testnet-faucet.html), uncomment or add the following section: - [ips] - s.altnet.rippletest.net 51235 + [ips] + s.altnet.rippletest.net 51235 - b. To connect to the [Devnet](xrp-testnet-faucet.html), uncomment the following section and add: + 2. To connect to the [Devnet](xrp-testnet-faucet.html), uncomment or add the following section: - [ips] - s.devnet.rippletest.net 51235 + [ips] + s.devnet.rippletest.net 51235 - c. Comment out the following section, as follows: + 3. Comment out the existing `[ips]` stanza: - # [ips] - # r.ripple.com 51235 + # [ips] + # r.ripple.com 51235 -2. In your `validators.txt` file: +2. Edit your `validators.txt` file. - 2a. Changes to connect to the Testnet + - To connect to the Testnet: - a. Uncomment the following sections, as follows to connect to the altnet: + 1. Uncomment the following sections: - [validator_list_sites] - https://vl.altnet.rippletest.net + [validator_list_sites] + https://vl.altnet.rippletest.net - [validator_list_keys] - ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 + [validator_list_keys] + ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 - b. Comment out the following sections, as follows: + 1. Comment out the following sections, as follows: - # [validator_list_sites] - # https://vl.ripple.com - # - # [validator_list_keys] - # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 + # [validator_list_sites] + # https://vl.ripple.com + # + # [validator_list_keys] + # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 - 2b. Changes to connect to the Devnet + - To connect to the Devnet: - a. Comment out the following sections as follows: + 1. Comment out the following sections: - # [validator_list_sites] - # https://vl.altnet.rippletest.net + # [validator_list_sites] + # https://vl.altnet.rippletest.net - # [validator_list_keys] - # ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 + # [validator_list_keys] + # ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 - # [validator_list_sites] - # https://vl.ripple.com - # - # [validator_list_keys] - # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 + # [validator_list_sites] + # https://vl.ripple.com + # + # [validator_list_keys] + # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 - b. Add the following trusted validators to the validator.txt file: + 2. Add the following trusted validators to the `validator.txt` file: - # Hard-coded List of Devnet Validators - [validators] - n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c - n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B - n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD - n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U - n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd - n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC - n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS + # Hard-coded List of Devnet Validators + [validators] + n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c + n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B + n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD + n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U + n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd + n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC + n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS 3. Restart `rippled`. 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 ec94f92886..a4cd22c370 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. @@ -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: 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/installation/build-run-rippled-macos.md b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.md index 75f08430d3..2f4a7f8a4c 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. @@ -65,7 +65,7 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`. Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases). -0. In the `rippled` directory you just cloned, create your build directory and access it. For example: +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/capacity-planning.md b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md index 9c8bfcd022..ffff1bbcca 100644 --- a/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md +++ b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md @@ -47,7 +47,7 @@ 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`. @@ -121,7 +121,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 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 3e0c14db79..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,7 +8,7 @@ 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) +- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better) - RAM: 8 GB+ 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 c6cff0df34..8040ad85cb 100644 --- a/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md +++ b/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.md @@ -80,7 +80,7 @@ For troubleshooting purposes, the most important fields are (from most commonly - **`peers`** - This field indicates how many other servers in the XRP Ledger peer-to-peer network your server is connected to. Healthy servers typically show between 5 and 50 peers, unless explicitly configured to connect only to certain peers. - - If you have 0 peers, your server may be unable to contact the network, or your system clock may be wrong. (Ripple recommends running an [NTP](http://www.ntp.org/) daemon on all servers to keep their clocks synced.) + - If you have 0 peers, your server may be unable to contact the network, or your system clock may be wrong. (Ripple recommends running an [NTP](http://www.ntp.org/) daemon on all servers to keep their clocks synced.) - If you have exactly 10 peers, that may indicate that your `rippled` is unable to receive incoming connections through a router using [NAT](https://en.wikipedia.org/wiki/Network_address_translation). You can improve connectivity by configuring your router's firewall to forward the port used for peer-to-peer connections (port 51235 [by default](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)). @@ -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. 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 80805b70f8..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 @@ -10,7 +10,7 @@ This document describes steps to detect and correct this problem if it occurs. 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 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 dd28bfa4a4..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. 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 15b2942551..0c77f429df 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 @@ -35,7 +35,7 @@ Log messages such as the following indicate that a server received validations f 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 ``` -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. @@ -57,7 +57,7 @@ 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. ## Connection reset by peer 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 ee37ee87cf..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). 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 cad7702c72..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 @@ -5,7 +5,7 @@ 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: 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 f275a8cde7..50fc3746c6 100644 --- a/content/tutorials/use-complex-payment-types/use-payment-channels.md +++ b/content/tutorials/use-complex-payment-types/use-payment-channels.md @@ -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. 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) - Transaction LastLedgerSequence: + Transaction LastLedgerSequence: @@ -402,7 +402,7 @@ api.on('ledger', ledger => { ### {{n.next()}}. Check Transaction Status -To know for sure what a transaction did, you must look up the outcome of the transaction when it appears in a validated ledger version. For example, you can use the [getTransaction() method](rippleapi-reference.html#gettransaction) to check the status of a transaction: +To know for sure what a transaction did, you must look up the outcome of the transaction when it appears in a validated ledger version. For example, you can use the [`getTransaction()` method](rippleapi-reference.html#gettransaction) to check the status of a transaction: ```js // Continues from previous examples. @@ -464,7 +464,7 @@ To send an XRP payment on the production XRP Ledger, the steps you take are larg ### Getting a Real XRP Account -This tutorial uses a button to get an address that's already funded with Test Net XRP, which only works because Test Net XRP is not worth anything. For actual XRP, you need to get XRP from someone who already has some. (For example, you might buy it on an exchange.) You can generate an address and secret that'll work on either production or the test net using RippleAPI's [generateAddress() method](rippleapi-reference.html#generateaddress): +This tutorial uses a button to get an address that's already funded with Test Net XRP, which only works because Test Net XRP is not worth anything. For actual XRP, you need to get XRP from someone who already has some. (For example, you might buy it on an exchange.) You can generate an address and secret that'll work on either production or the test net using RippleAPI's [`generateAddress()` method](rippleapi-reference.html#generateaddress): ```js const generated = api.generateAddress() @@ -474,7 +474,7 @@ console.log(generated.secret) // Example: sp6JS7f14BuwFY8Mw6bTtLKWauoUs **Warning:** You should only use an address and secret that you generated securely, on your local machine. If another computer generated the address and secret and sent it to you over a network, it's possible that someone else on the network may see that information. If they do, they'll have as much control over your XRP as you do. It's also recommended not to use the same address for the test net and for production, because transactions that you created for use on one network could potentially also be viable on the other network, depending on the parameters you provided. -Generating an address and secret doesn't get you XRP directly; it's just choosing a random number. You must also receive XRP at that address to [fund the account](accounts.html#creating-accounts). A common way to acquire XRP is to buy it from an exchange, then withdraw it to your own address. For more information, see Ripple's [XRP Buying Guide](https://ripple.com/xrp/buy-xrp/). +Generating an address and secret doesn't get you XRP directly; it's only choosing a random number. You must also receive XRP at that address to [fund the account](accounts.html#creating-accounts). A common way to acquire XRP is to buy it from an exchange, then withdraw it to your own address. For more information, see Ripple's [XRP Buying Guide](https://ripple.com/xrp/buy-xrp/). ### Connecting to the Production XRP Ledger diff --git a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md index acba69d38b..13657a9745 100644 --- a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md +++ b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md @@ -74,7 +74,7 @@ Main article: [Issuing and Operational Addresses](issuing-and-operational-addres There are several ways in which a gateway can seek to profit from XRP Ledger integration. These can include: * Withdrawal and Deposit fees. Gateways typically charge a small fee (such as 1%) for the service of adding or removing money from the XRP Ledger. You have the power to determine the rate you credit people when they move money onto and off of the XRP Ledger through your gateway. -* Transfer fees. You can set a percentage fee to charge automatically when customers send each other issued currencies created by your issuing address. This amount is debited from the XRP Ledger, decreasing your obligation each time your issued currencies change hands. See [TransferRate](#transferrate) for details. +* Transfer fees. You can set a percentage fee to charge automatically when customers send each other issued currencies created by your issuing address. This amount is debited from the XRP Ledger, decreasing your obligation each time your issued currencies change hands. See [Transfer Fees](#transfer-fees) for details. * Indirect revenue from value added. XRP Ledger integration can provide valuable functionality for your customers that distinguishes your business from your competitors. * Interest on XRP Ledger-backed funds. You can keep the collateral for the funds you issue in XRP Ledger in a bank account that earns interest. Make sure you can always access enough funds to service customer withdrawals. * [Financial Exchange](#liquidity-and-currency-exchange). A gateway can also make offers to buy and sell its issued currencies for other issued currencies in the XRP Ledger, providing liquidity to cross-currency payments and possibly making a profit. (As with all financial exchange, profits are not guaranteed.) @@ -109,6 +109,8 @@ See also: - [The Non-US Standard on KYC set by the Financial Action Task Force (FATF)](http://www.fatf-gafi.org/topics/fatfrecommendations/documents/fatf-recommendations.html) + + ### Anti-Money Laundering (AML) and Combating the Financing of Terrorism (CFT) Money laundering is the process of moving illegal funds by disguising the source, nature or ownership so that funds can be legally accessed or distributed via legitimate financial channels and credible institutions. In short, it is converting “dirty money” into “clean money.” Anti-Money Laundering (AML) refers to the laws and procedures designed to stop money laundering from occurring. @@ -121,6 +123,8 @@ See also: - [“Virtual Currencies: Key Definitions and Potential AML/CFT Risks.” FATF, 2014](http://www.fatf-gafi.org/topics/methodsandtrends/documents/virtual-currency-definitions-aml-cft-risk.html) + + ### Source of Funds To prevent illicit funds from passing through their systems, financial institutions must be able to determine within reason if the source of a customer’s funds is linked to criminal activity. @@ -151,9 +155,11 @@ The Travel Rule is a Bank Secrecy Act (BSA) rule requiring funds-transmitting fi - The execution date of the transmittal order, and - The identity of the recipient's financial institution. + + See also: -- [Additional information and background on the Travel Rule](http://www.fincen.gov/news_room/rp/advisory/html/advissu7.html) +- [Funds “Travel” Regulations: Questions & Answers ](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers) ### Fee Disclosure and Tracing Funds @@ -179,6 +185,8 @@ See also: - [A list of OFAC resources](https://www.treasury.gov/resource-center/faqs/Sanctions/Pages/ques_index.aspx) + + ### Guidance on Virtual Currency and Money Service Business - United States: @@ -242,11 +250,11 @@ There are several prerequisites that ACME must meet for this to happen: - ACME can store the funds allocated to the XRP Ledger in a separate bank account. - If ACME is a cryptocurrency exchange, ACME can create a separate wallet to hold the funds allocated to the XRP Ledger, as publicly-verifiable proof to customers that the gateway is solvent. - ACME must control an address in the XRP Ledger. Ripple's best practices recommend using a separate issuing address and operational address. See [Issuing and Operational Addresses](issuing-and-operational-addresses.html) for details. - - ACME must enable the [DefaultRipple Flag](#defaultripple) on its issuing address for customers to send and receive its issued currencies. + - ACME must enable the [`DefaultRipple` Flag](#default-ripple) on its issuing address for customers to send and receive its issued currencies. - Alice must create an accounting relationship (trust line) from her XRP Ledger address to ACME's issuing address. She can do this from any XRP Ledger client application as long as she knows ACME's issuing address. - ACME should publicize its issuing address on its website where customers can find it. It can also use an [`xrp-ledger.toml` file](xrp-ledger-toml.html) to publish the issuing address to automated systems. - ACME must create a user interface for Alice to send funds from ACME into the XRP Ledger. - - ACME needs to know Alice's XRP Ledger address. ACME can have Alice input her XRP Ledger addresss as part of the interface, or ACME can require Alice to input and verify her XRP Ledger address in advance. + - ACME needs to know Alice's XRP Ledger address. ACME can have Alice input her XRP Ledger address as part of the interface, or ACME can require Alice to input and verify her XRP Ledger address in advance. See [Sending Payments to Customers](#sending-payments-to-customers) for an example of how to send payments into the XRP Ledger. @@ -278,15 +286,15 @@ Processing payments to and from the XRP Ledger naturally comes with some risks, - Protect yourself against reversible deposits. XRP Ledger payments are irreversible, but many electronic money systems like credit cards or PayPal are not. Scammers can abuse this to take their fiat money back by canceling a deposit after receiving issued currencies in the XRP Ledger. - When sending into the XRP Ledger, specify the issuing address as the issuer of the currency. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses. -- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any [transfer fee](#transferrate) you have set. +- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any [transfer fee](#transfer-fees) you have set. - Before processing a payment out of Ripple, make sure you know the customer's identity. This makes it harder for anonymous attackers to scam you. Most anti-money-laundering regulations require this anyway. This is especially important because the users sending money from the XRP Ledger could be different than the ones that initially received the money in the XRP Ledger. - Follow the guidelines for [reliable transaction submission](#reliable-transaction-submission) when sending XRP Ledger transactions. - [Robustly monitor for incoming payments](#robustly-monitoring-for-payments), and read the correct amount. Don't mistakenly credit someone the full amount if they only sent a [partial payment](partial-payments.html). - Track your obligations and balances within the XRP Ledger, and compare with the assets in your collateral account. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy. - Avoid ambiguous situations. We recommend the following: - - Enable the [`DisallowXRP` flag](#disallowxrp) for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.) + - Enable the [Disallow XRP flag](#disallow-xrp) for the issuing address and all operational addresses, so customers do not accidentally send you XRP. (Private exchanges should *not* set this flag, since they trade XRP normally.) - Enable the [`RequireDest` flag](require-destination-tags.html) for the issuing address and all operational addresses, so customers do not accidentally send a payment without the destination tag to indicate who should be credited. - - Enable the [`RequireAuth` flag](#requireauth) on all operational addresses so they cannot issue currency by accident. + - Enable the [`RequireAuth` flag](#require-auth) on all operational addresses so they cannot issue currency by accident. - Monitor for suspicious or abusive behavior. For example, a user could repeatedly send funds into and out of the XRP Ledger, as a denial of service attack that effectively empties an operational address's balance. Suspend customers whose addresses are involved in suspicious behavior by not processing their XRP Ledger payments. ## Trading on Ripple @@ -300,7 +308,7 @@ After the issued currencies have been created in the XRP Ledger, they can be fre - XRP Ledger users trading and sending EUR.ACME to one another requires no intervention by ACME. - All exchanges and balances in the XRP Ledger are publicly viewable. -The following diagram depicts an XRP Ledger payment sending 2EUR.ACME from Alice to Charlie. ACME can query the XRP Ledger to see updates to its balances any time after the transaction has occurred: +The following diagram depicts an XRP Ledger payment sending 2 EUR.ACME from Alice to Charlie. ACME can query the XRP Ledger to see updates to its balances any time after the transaction has occurred: ![Diagram: Alice's sends 2 EUR.ACME from her trust line to Charlie's](img/e2g-03.png) @@ -332,7 +340,7 @@ Similarly, *Source Tags* indicate the originator or source of a payment. Most co Ripple recommends making a user interface to generate a destination tag on-demand when a customer intends to send money to the gateway. You should consider that destination tag valid only for a payment with the expected amount. Later, bounce any other transactions that reuse the same destination tag. -Enable the [RequireDest](require-destination-tags.html) flag on your issuing and operational addresses so that customers must use a destination tag to indicate where funds should go when they send XRP Ledger payments to your gateway. +[Enable the `RequireDest` flag](require-destination-tags.html) on your issuing and operational addresses so that customers must use a destination tag to indicate where funds should go when they send XRP Ledger payments to your gateway. For more information, see [Source and Destination Tags](source-and-destination-tags.html). @@ -344,14 +352,14 @@ Historically, Ripple (the company) issued gateway bulletins to introduce new fea - May 13, 2015 - [GB-2015-06 Gateway Bulletin: Corrections to Autobridging (PDF)](assets/pdf/GB-2015-06.pdf) - April 17, 2015 - [GB-2015-05 Historical Ledger Query Migration](assets/pdf/GB-2015-05.pdf) - March 13, 2015 - [GB-2015-04 Action Required: Default Ripple Flag (PDF)](https://ripple.com/files/GB-2015-04.pdf) -- March 3, 2015 - [GB-2015-03 Gateway Advisory: FinCEN Ruling on MoneyGram Compliance Program (PDF)](https://ripple.com/files/GB-2015-03.pdf) +- March 3, 2015 - [GB-2015-03 Gateway Advisory: FinCEN Ruling on MoneyGram Compliance Program (PDF)](https://ripple.com/files/GB-2015-03.pdf) - March 2, 2015 (Updated) - [GB-2015-02 New Standards: How to be Featured on Ripple Trade and Ripple Charts (PDF)](https://ripple.com/files/GB-2015-02.pdf) - January 5, 2015 - [GB-2015-01 Gateway Advisory: Reliable Transaction Submission (PDF)](https://ripple.com/files/GB-2015-01.pdf) - December 18, 2014 - [GB-2014-08 Gateway Advisory: Recent FinCEN Rulings (PDF)](https://ripple.com/files/GB-2014-08.pdf) - November 4, 2014 -[GB-2014-07 Gateway Advisory: FATF Standards (PDF)](https://ripple.com/files/GB-2014-07.pdf) - October 17, 2014 -[GB-2014-06 Gateway Advisory: Partial Payment Flag (PDF)](https://ripple.com/files/GB-2014-06.pdf) -- September 24, 2014 - [GB-2014-05 Gateway Advisory: EBA Opinion On Virtual Currency (PDF)](https://ripple.com/files/GB-2014-05.pdf) -- September 11, 2014 - [GB-2014-04 Gateway Advisory: CFPB Opinion on Virtual Currency (PDF)](https://ripple.com/files/GB-2014-04.pdf) +- September 24, 2014 - [GB-2014-05 Gateway Advisory: EBA Opinion On Virtual Currency (PDF)](https://ripple.com/files/GB-2014-05.pdf) +- September 11, 2014 - [GB-2014-04 Gateway Advisory: CFPB Opinion on Virtual Currency (PDF)](https://ripple.com/files/GB-2014-04.pdf) - August 19, 2014 - [GB-2014-03 Updated Feature: Trust Lines UI (PDF)](https://ripple.com/files/GB-2014-03.pdf) - August 1, 2014 - [GB-2014-02 New Feature: Balance Freeze (PDF)](https://ripple.com/files/GB-2014-02.pdf) - April 23, 2014, Updated August 14, 2014 -[GB-2014-01 New Feature: Ripple Names (PDF)](https://ripple.com/files/GB-2014-01.pdf) @@ -375,23 +383,24 @@ There are several interfaces you can use to connect to the XRP Ledger, depending ## Tool Security -Any time you submit an XRP Ledger transaction, it must be signed using your secret key. The secret key gives full control over your XRP Ledger address. **Never** send your secret key to a server operated by someone else. Either use your own `rippled` server, or sign the transactions locally before sending them to a `rippled` server. +Any time you submit an XRP Ledger transaction, it must be signed using your secret key. The secret key gives full control over your XRP Ledger address. **Never** send your secret key to a server run by someone else. Either use your own `rippled` server, or sign the transactions locally before sending them to a `rippled` server. -The examples in this document show API methods that include a secret key. This is only safe if you control `rippled` server yourself, *and* you connect to it over a connection that is secure from outside listeners. (For example, you could connect over a loopback (localhost) network, a private subnet, or an encrypted VPN.) Alternatively, you could use [RippleAPI](rippleapi-reference.html) to sign transactions locally before submitting them to a third-party server. +The examples in this document show API methods that include a secret key. This is only safe if you control `rippled` server yourself, *and* you connect to it over a connection that is secure from outside listeners. (For example, you could connect over a loopback (`localhost`) network, a private network, or an encrypted VPN.) Alternatively, you could use [RippleAPI](rippleapi-reference.html) to sign transactions locally before submitting them to a third-party server. -## DefaultRipple +## Default Ripple -The DefaultRipple flag controls whether the balances in an accounting relationship [allowed to ripple](rippling.html) by default. Rippling is what allows customers to trade issued currencies, so a gateway must allow rippling on all the accounting relationships to its issuing address. +The Default Ripple flag controls whether the balances in an accounting relationship [allowed to ripple](rippling.html) by default. Rippling is what allows customers to trade issued currencies, so a gateway must allow rippling on all the accounting relationships to its issuing address. -Before asking customers to create accounting relationships to its issuing address, a gateway should enable the DefaultRipple flag on that address. Otherwise, the gateway must individually disable the NoRipple flag for each accounting relationship that other addresses have created. +Before asking customers to create accounting relationships to its issuing address, a gateway should enable the Default Ripple flag on that address. Otherwise, the gateway must individually disable the No Ripple flag for each accounting relationship that other addresses have created. -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the DefaultRipple flag: +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the Default Ripple flag: Request: -``` +```json POST http://localhost:8088/ + { "method": "submit", "params": [ @@ -414,7 +423,7 @@ POST http://localhost:8088/ Response: -``` +```json { "result": { "engine_result": "tesSUCCESS", @@ -437,22 +446,23 @@ Response: } ``` -To confirm that an address has DefaultRipple enabled, look up the address using the [account_info method][], specifying a validated ledger version. Use [a bitwise-AND operator](https://en.wikipedia.org/wiki/Bitwise_operation#AND) to compare the `Flags` field with 0x00800000 (the [ledger flag lsfDefaultRipple](accountroot.html#accountroot-flags)). If the result of the bitwise-AND operation is nonzero, then the address has DefaultRipple enabled. +To confirm that an address has Default Ripple enabled, look up the address using the [account_info method][], specifying a validated ledger version. Use [a bitwise-AND operator](https://en.wikipedia.org/wiki/Bitwise_operation#AND) to compare the `Flags` field with `0x00800000` (the [ledger flag `lsfDefaultRipple`](accountroot.html#accountroot-flags)). If the result of the bitwise-AND operation is nonzero, then the address has Default Ripple enabled. -## DisallowXRP +## Disallow XRP -The DisallowXRP setting (`disallowIncomingXRP` in RippleAPI) is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments, if your gateway does not trade XRP. The DisallowXRP flag is not strictly enforced, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the DisallowXRP flag by default. +The Disallow XRP setting (`disallowIncomingXRP` in RippleAPI) is designed to discourage XRP Ledger users from sending XRP to an address by accident. This reduces the costs and effort of bouncing undesired payments, if your gateway does not trade XRP. The Disallow XRP flag is not strictly enforced, because doing so could allow addresses to become permanently unusable if they run out of XRP. Client applications should honor the Disallow XRP flag by default. -An issuing gateway that does not trade XRP should enable the DisallowXRP flag on the gateway's issuing and operational addresses. A private exchange that trades in XRP should only enable the DisallowXRP flag on addresses that are not expected to receive XRP. +An issuing gateway that does not trade XRP should enable the Disallow XRP flag on the gateway's issuing and operational addresses. A private exchange that trades in XRP should only enable the Disallow XRP flag on addresses that are not expected to receive XRP. -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the DisallowXRP flag: +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the Disallow XRP flag: Request: -``` +```json POST http://localhost:8088/ + { "method": "submit", "params": [ @@ -475,7 +485,7 @@ POST http://localhost:8088/ Response: -``` +```json { "result": { "engine_result": "tesSUCCESS", @@ -499,18 +509,19 @@ Response: ``` -## RequireAuth +## Require Auth -The `RequireAuth` setting prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty. For more information, see [Authorized Trust Lines](authorized-trust-lines.html). +The Require Auth setting prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty. For more information, see [Authorized Trust Lines](authorized-trust-lines.html). -### Enabling RequireAuth +### Enabling Require Auth -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.) +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the Require Auth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.) Request: -``` +```json POST http://localhost:5005/ + { "method": "submit", "params": [ @@ -535,14 +546,15 @@ POST http://localhost:5005/ If you are using the [Authorized Trust Lines](authorized-trust-lines.html) feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the XRP Ledger. -To authorize an accounting relationship, submit a TrustSet transaction from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](trustset.html#trustset-flags) flag for the transaction. +To authorize an accounting relationship, submit a TrustSet transaction from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [`tfSetfAuth` flag](trustset.html#trustset-flags) for the transaction. -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issued USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW: +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` to hold USD issued by the address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`: Request: -``` +```json POST http://localhost:8088/ + { "method": "submit", "params": [ @@ -577,26 +589,25 @@ To robustly check for incoming payments, gateways should do the following: * [Look out for Partial Payments](https://ripple.com/files/GB-2014-06.pdf "Partial Payment Flag Gateway Bulletin"). Payments with the partial-payment flag enabled can be considered "successful" if any non-zero amount is delivered, even miniscule amounts. * In `rippled`, check the transaction for a `meta.delivered_amount` field. If present, that field indicates how much money *actually* got delivered to the `Destination` address. * In RippleAPI, you can search the `outcome.BalanceChanges` field to see how much the destination address received. In some cases, this can be divided into multiple parts on different trust lines. -* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero [TransferRate](#transferrate), then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's issued currencies. See [TransferRate](#transferrate) for more information. +* Some transactions change your balances without being payments directly to or from one of your addresses. For example, if ACME sets a nonzero [transfer fee](#transfer-fees), then ACME's issuing address's outstanding obligations decrease each time Bob and Charlie exchange ACME's issued currencies. See [Transfer Fees](#transfer-fees) for more information. To make things simpler for your customers, we recommend accepting payments to either operational addresses and issuing addresses. As an added precaution, we recommend comparing the balances of your issuing address with the collateral funds in your internal accounting system as of each new XRP Ledger ledger version. The issuing address's negative balances should match the assets you have allocated to XRP Ledger outside the network. If the two do not match up, then you should suspend processing payments into and out of the XRP Ledger until you have resolved the discrepancy. * Use `rippled`'s [gateway_balances method][] or [RippleAPI's `getTrustlines` method](rippleapi-reference.html#gettrustlines) to check your balances. -* If you have a [TransferRate](#transferrate) set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your issued currencies among themselves. +* If you have a [Transfer Fee](#transfer-fees) set, then your obligations within the XRP Ledger decrease slightly whenever other XRP Ledger addresses transfer your issued currencies among themselves. -## TransferRate +## Transfer Fees -The *TransferRate* setting (`transferRate` in RippleAPI) defines a fee to charge for transferring issued currencies from one XRP Ledger address to another. See [Transfer Fees](transfer-fees.html) for more information. +The `TransferRate` setting (`transferRate` in RippleAPI) defines a fee to charge for transferring issued currencies from one XRP Ledger address to another. See [Transfer Fees](transfer-fees.html) for more information. -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction for the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW, setting the TransferRate to charge a fee of 0.5%. +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction for the issuing address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`, setting the `TransferRate` to charge a fee of 0.5%. Request: -``` - +```json { "method": "submit", "params": [ @@ -639,14 +650,14 @@ Response: } ``` -### TransferRate with Operational and Standby Addresses +### Transfer Fees with Operational and Standby Addresses -All XRP Ledger addresses, including operational and standby addresses, are subject to the transfer fee. If you set a nonzero transfer fee, then you must send extra (to pay the TransferRate) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment. +All XRP Ledger addresses, including operational and standby addresses, are subject to the issuer's transfer fees when sending issued currency. If you set a nonzero transfer fee, then you must send extra (to pay the transfer fee) when making payments from your operational address or standby address. In other words, your addresses must pay back a little of the balance your issuing address created, each time you make a payment. * In `rippled`'s APIs, you should set the [`SendMax` transaction parameter][Payment] higher than the destination `Amount` parameter. * In RippleAPI, you should set the `source.maxAmount` parameter higher than the `destination.amount` parameter; or, set the `source.amount` parameter higher than the `destination.minAmount` parameter. -**Note:** The TransferRate does not apply when sending issued currencies directly to the issuing address. The issuing address must always accept its issued currencies at face value in the XRP Ledger. This means that customers don't have to pay the TransferRate if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the TransferRate the customer pays. +**Note:** Transfer fees do not apply when sending issued currencies directly to the issuing address. The issuing address must always accept its issued currencies at face value in the XRP Ledger. This means that customers don't have to pay the transfer fee if they send payments to the issuing address directly, but they do when sending to an operational address. If you accept payments at both addresses, you may want to adjust the amount you credit customers in your system of record when customers send payments to the operational address, to compensate for the transfer fee the customer pays. For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver 5 EUR.ACME from a customer address to ACME's issuing address would cost exactly 5 EUR.ACME. However, the customer would need to send 5.05 EUR.ACME to deliver 5 EUR.ACME to ACME's operational address. (The issuing address's total obligations in the XRP Ledger decrease by 0.05 EUR.ACME.) When ACME credits customers for payments to ACME's operational address, ACME credits the customer for the amount delivered to the operational address _and_ the transfer fee, giving the customer €5,05 in ACME's systems. @@ -657,7 +668,7 @@ When you build an automated system to send payments into the XRP Ledger for your One common pitfall is performing pathfinding before sending sending a payment to customers in the XRP Ledger. If you specify the issuers correctly, the [default paths](paths.html#default-paths) can deliver the currency as intended. -The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a payment from the operational address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to the customer address raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n, sending and delivering funds issued by the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW. +The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a payment from the operational address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` to the customer address `raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n`, sending and delivering funds issued by the issuing address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`. Request: @@ -727,7 +738,7 @@ In particular, note the following features of the [Payment transaction][]: - No `Paths` field. The payment only succeeds if it can use a [default path](paths.html#default-paths), which is preferable. Using less direct paths can become much more expensive. - The `issuer` of both the `SendMax` and the `Amount` is the issuing address. This ensures that the transaction sends and delivers issued currencies from the issuing address, and not from some other gateway. -- The `value` of the `SendMax` amount is slightly higher than the destination `Amount`, to compensate for the [transfer fee](#transferrate). In this case, the transfer fee is 0.5%, so the `SendMax` amount is exactly 1.005 times the destination `Amount`. +- The `value` of the `SendMax` amount is slightly higher than the destination `Amount`, to compensate for the [transfer fee](#transfer-fees). In this case, the transfer fee is 0.5%, so the `SendMax` amount is exactly 1.005 times the destination `Amount`. ## Bouncing Payments @@ -738,7 +749,7 @@ The first requirement to bouncing payments is [robustly monitoring for incoming Second, you should send bounced payments as Partial Payments. Since third parties can manipulate the cost of pathways between addresses, Partial Payments allow you to divest yourself of the full amount without being concerned about exchange rates within the XRP Ledger. You should publicize your bounced payments policy as part of your terms of use. Send the bounced payment from either an operational address or a standby address. -* To send a Partial Payment using `rippled`, enable the [tfPartialPayment flag](payment.html#payment-flags) on the transaction. Set the `Amount` field to the amount you received and omit the `SendMax` field. +* To send a Partial Payment using `rippled`, enable the [`tfPartialPayment` flag](payment.html#payment-flags) on the transaction. Set the `Amount` field to the amount you received and omit the `SendMax` field. * To send a Partial Payment using RippleAPI, set the `allowPartialPayment` field of the [Payment object](rippleapi-reference.html#payment) to `true`. Set the `source.maxAmount` and `destination.amount` both equal to the amount you received. You should use the `SourceTag` value (`source.tag` in RippleAPI) from the incoming payment as the `DestinationTag` value (`destination.tag` in RippleAPI) for the return payment. diff --git a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md index 7b94a90e8f..9ce7ee7625 100644 --- a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md +++ b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md @@ -56,7 +56,7 @@ When the [`tfPartialPayment` flag](payment.html#payment-flags) is enabled, the ` XRP is held in _accounts_ (also referred to as _wallets_ or _addresses_ ) on the XRP Ledger. Accounts on the XRP Ledger are different than accounts on other blockchain ledgers, such as Bitcoin, where accounts incur little to no overhead. In the XRP Ledger, account state is stored per ledger and accounts are [not easy to delete](accounts.html#deletion-of-accounts). To offset the costs associated with storing accounts, each account must hold a separate [reserve of XRP](reserves.html) that cannot be sent to others. For these reasons, Ripple recommends that institutions not create excessive or needless accounts. - + To follow Ripple's recommended best practices, Alpha Exchange should create at least two new accounts on the XRP Ledger. To minimize the risks associated with a compromised secret key, Ripple recommends creating [_cold_, _hot_, and _warm_ accounts](issuing-and-operational-addresses.html) (these are sometimes referred to, respectively, as cold, hot, and warm wallets). The hot/warm/cold model is intended to balance security and convenience. Exchanges listing XRP should create the following accounts: diff --git a/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md b/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md index 75c3fbe0e0..74a5f62757 100644 --- a/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md +++ b/content/tutorials/xrp-ledger-businesses/list-your-exchange-on-xrp-charts.md @@ -17,7 +17,7 @@ If you have any questions about endpoint specifications, contact {{n.next()}} ## Access the `ripple-lib` repo -`ripple-lib` is an open-source project. You can take a look at `ripple-lib` code simply by accessing the `ripple-lib` GitHub repo. Before contributing or reporting bugs, we recommend that you get to know the code and developer experience by performing the following tasks. +`ripple-lib` is an open-source project. You can take a look at `ripple-lib` code by accessing the `ripple-lib` GitHub repo. Before contributing or reporting bugs, we recommend that you get to know the code and developer experience by performing the following tasks. [Access the `ripple-lib` repo](https://github.com/ripple/ripple-lib) @@ -61,4 +61,4 @@ As you explore `ripple-lib`, you may find code that you don’t think is working If the bug you wish to report is security-related, we urge you to disclose it responsibly through Ripple's [Bug Bounty program](https://ripple.com/bug-bounty/). -[Report bugs](https://github.com/ripple/ripple-lib/issues) \ No newline at end of file +[Report bugs](https://github.com/ripple/ripple-lib/issues) diff --git a/content/use-cases/contribute-code-to-rippled.md b/content/use-cases/contribute-code-to-rippled.md index ec2ce55287..d5ccf7084f 100644 --- a/content/use-cases/contribute-code-to-rippled.md +++ b/content/use-cases/contribute-code-to-rippled.md @@ -8,7 +8,7 @@ Want to contribute code or a bug report to help improve `rippled`, the core peer {{n.next()}} ## Access the `rippled` repo -`rippled` is an open-source project. You can take a look at `rippled` code simply by accessing the `rippled` GitHub repo. Before contributing or reporting bugs, we recommend that you get to know the code and developer experience by performing the following tasks. +`rippled` is an open-source project. You can take a look at `rippled` code by accessing the `rippled` GitHub repo. Before contributing or reporting bugs, we recommend that you get to know the code and developer experience by performing the following tasks. [Access the repo](https://github.com/ripple/rippled) @@ -60,4 +60,4 @@ As you explore `rippled`, you may find code that you don’t think is working as If the bug you wish to report is security-related, we urge you to disclose it responsibly through Ripple's [Bug Bounty program](https://ripple.com/bug-bounty/). -[Report bugs](https://github.com/ripple/rippled/issues) \ No newline at end of file +[Report bugs](https://github.com/ripple/rippled/issues) diff --git a/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md b/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md index 89a64a99f4..88f8425126 100644 --- a/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md +++ b/content/use-cases/open-a-payment-channel-to-enable-an-inter-exchange-network.md @@ -1,6 +1,6 @@ # Open a Payment Channel to Enable an Inter-Exchange Network -A payment channel enables you to send one-way, "asynchronous" XRP payments that can be divided into very small increments and settled later. As a digital asset exchange, if you frequently send XRP to another exchange, you can improve the efficiency of these payments by opening an XRP Ledger [payment channel](payment-channels.html) between your exchange (the _payer_ exchange) and the other exchange (the _payee_ exchange). In the case of a two-way flow with another exchange, you can simply open two payment channels (one for each direction). +A payment channel enables you to send one-way, "asynchronous" XRP payments that can be divided into very small increments and settled later. As a digital asset exchange, if you send many payments of XRP to another exchange, you can improve the efficiency of these payments by opening an XRP Ledger [payment channel](payment-channels.html) between your exchange (the _payer_ exchange) and the other exchange (the _payee_ exchange). In the case of a two-way flow with another exchange, you can open two payment channels (one for each direction). @@ -20,7 +20,7 @@ Here are some of the benefits of using a payment channel to send XRP instead of - **Connect to the Internet of Value:** One of the key requirements of the [Internet of Value](https://ripple.com/insights/the-internet-of-value-what-it-means-and-how-it-benefits-everyone/) is interoperability. The [Interledger Protocol](https://interledger.org/) (ILP), which plays a large role in driving this interoperability, works best when it [uses payment channels](https://interledger.org/rfcs/0027-interledger-protocol-4) as its method for rebalancing accounts. In effect, when you open a payment channel from your exchange to another, you are connecting to the Internet of Value and helping to create the inter-exchange network that is fundamental to the success of the Internet of Value and the apps that are built on it. - Connecting your exchange to other exchanges by way of payment channels is another differentiator. For customers who are moving XRP to purchase various currencies across exchanges, knowing that they can move XRP at a moment's notice from your exchange to any number of exchanges in the Internet of Value can make your exchange a preferred place to custody their assets. + Connecting your exchange to other exchanges by way of payment channels is another differentiator. For customers who are moving XRP to buy various currencies across exchanges, knowing that they can move XRP at a moment's notice from your exchange to any number of exchanges in the Internet of Value can make your exchange a preferred place to custody their assets. Here’s a roadmap to the high-level tasks you’ll need to perform to implement this payment channel use case. To go directly to a full payment channels tutorial, see [Use Payment Channels](use-payment-channels.html). @@ -51,7 +51,7 @@ If not, a great way for an exchange to get access to a `rippled` server is to se {{n.next()}} ## Payer and payee: Fund XRP Ledger accounts with enough XRP -If your exchange processes XRP deposits and withdrawals directly, you probably have existing funded XRP Ledger accounts that you can use for this purpose. Just ensure that they are funded with enough XRP as described here. +If your exchange processes XRP deposits and withdrawals directly, you probably have existing funded XRP Ledger accounts that you can use for this purpose. Ensure that they are funded with enough XRP as described here. Along these lines, there's a good chance that you are following industry best practices and have a cold account plus one or more hot accounts. Use the hot accounts for your payment channels. diff --git a/dactyl-config.yml b/dactyl-config.yml index 2f55dd6702..8e52a742a4 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -3359,7 +3359,7 @@ pages: supercategory: rippled API category: Public rippled Methods subcategory: Account Methods - blurb: Get recommended changes to an account's DefaultRipple and NoRipple settings. + blurb: Get recommended changes to an account's Default Ripple and No Ripple settings. targets: - en diff --git a/tool/openapi_templates_alpha/template-openapi_data_type.md b/tool/openapi_templates_alpha/template-openapi_data_type.md index b095cf1caa..887e4ff9ea 100644 --- a/tool/openapi_templates_alpha/template-openapi_data_type.md +++ b/tool/openapi_templates_alpha/template-openapi_data_type.md @@ -2,7 +2,7 @@ {{description}} -**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change frequently in ways that break backwards compatibility. +**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change often in ways that break backwards compatibility. {% if type is defined %}- **Type:** {{type|title}} {% elif oneOf is defined %}- **Possible Types:** diff --git a/tool/openapi_templates_alpha/template-openapi_data_types_toc.md b/tool/openapi_templates_alpha/template-openapi_data_types_toc.md index 2b396ac3dd..33ba5141b2 100644 --- a/tool/openapi_templates_alpha/template-openapi_data_types_toc.md +++ b/tool/openapi_templates_alpha/template-openapi_data_types_toc.md @@ -1,6 +1,6 @@ # {{api_title}} Data Types -**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change frequently in ways that break backwards compatibility. +**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change often, in ways that break backwards compatibility. The following data types are defined for this API: diff --git a/tool/openapi_templates_alpha/template-openapi_endpoint.md b/tool/openapi_templates_alpha/template-openapi_endpoint.md index d9a11c2d9d..fbc12d2699 100644 --- a/tool/openapi_templates_alpha/template-openapi_endpoint.md +++ b/tool/openapi_templates_alpha/template-openapi_endpoint.md @@ -2,7 +2,7 @@ {{description}} -**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change frequently in ways that break backwards compatibility. +**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change often in ways that break backwards compatibility. ## Request Format diff --git a/tool/openapi_templates_alpha/template-openapi_endpoint_tag_toc.md b/tool/openapi_templates_alpha/template-openapi_endpoint_tag_toc.md index 875b7f1b15..40edc915d0 100644 --- a/tool/openapi_templates_alpha/template-openapi_endpoint_tag_toc.md +++ b/tool/openapi_templates_alpha/template-openapi_endpoint_tag_toc.md @@ -2,7 +2,7 @@ {{tag.description}} -**Warning:** {{info.title}} is early alpha software. API methods and data formats are likely to change frequently in ways that break backwards compatibility. +**Warning:** {{info.title}} is early alpha software. API methods and data formats are likely to change often in ways that break backwards compatibility. | Summary | Path | |:--------|:-----| diff --git a/tool/openapi_templates_alpha/template-openapi_endpoint_toc.md b/tool/openapi_templates_alpha/template-openapi_endpoint_toc.md index 659f972357..0c5ac43204 100644 --- a/tool/openapi_templates_alpha/template-openapi_endpoint_toc.md +++ b/tool/openapi_templates_alpha/template-openapi_endpoint_toc.md @@ -2,7 +2,7 @@ {{info.description}} -**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change frequently in ways that break backwards compatibility. +**Warning:** {{spec.info.title}} is early alpha software. API methods and data formats are likely to change often in ways that break backwards compatibility. {% if tags %} View API methods by category: diff --git a/tool/spelling.txt b/tool/spelling.txt index b9c1cad1d2..b198728d68 100644 --- a/tool/spelling.txt +++ b/tool/spelling.txt @@ -99,6 +99,7 @@ mbps md5 metadata mitigations +modeled modulo namespace nonces @@ -149,6 +150,7 @@ sharding smartphone spamming sqlite +streamlines subdomain subfolder subfolders @@ -199,12 +201,15 @@ url urls utc validator +verifiability versioning virtualization virtualized wasn't we'll won't +webpage +webpages website websites websocket @@ -220,13 +225,16 @@ zeroes bitcoin centos +cloudflare debian firefox github google linux nginx +ntp openssl +paypal redhat rhel ubuntu @@ -239,16 +247,19 @@ cny eur mxn usd +xau xrp hash128 hash160 hash256 +starray uint16 uint256 uint32 uint64 uint8 +vector256 512half account_channels @@ -282,6 +293,7 @@ consensus_info cors crawl_shards crypto +cryptoconditions cryptoconditionssuite deletableaccounts deposit_authorized @@ -330,6 +342,7 @@ gateway_balances get_counts gravatar grpc +hardenedvalidations hmac interledger kyc @@ -364,6 +377,7 @@ paymentchannelfund peer_reservations_add peer_reservations_del peer_reservations_list +preemptively offercancel offercreate requirefullycanonicalsig @@ -381,6 +395,7 @@ setfee setregularkey shamapv2 shor +sorteddirectories sign_for signerlist signerlistset @@ -401,6 +416,8 @@ validation_create validation_seed validator_info validator_list_sites -vector256 xpring xrpchat + +britto +macbrough diff --git a/tool/word_substitutions.yaml b/tool/word_substitutions.yaml index 4bf9e17d55..36a08b4df5 100644 --- a/tool/word_substitutions.yaml +++ b/tool/word_substitutions.yaml @@ -71,7 +71,7 @@ exhibit: show expedite: hasten, speed up expeditious: fast, quick expend: spend -expertise: ability +# expertise: ability #expiration: end facilitate: ease, help feasible: can be done, workable From 5c20fabc1e3c64445543f1b681d360e07bd9e5a5 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 24 Jul 2020 03:36:47 -0700 Subject: [PATCH 36/65] Spell checker pass --- .../amendments/known-amendments.md | 2 +- content/concepts/issued-currencies/freezes.md | 90 +++++++++---------- tool/spelling.txt | 3 + 3 files changed, 49 insertions(+), 46 deletions(-) diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md index 01cc765679..1d97448689 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.md +++ b/content/concepts/consensus-network/amendments/known-amendments.md @@ -527,7 +527,7 @@ With this amendment enabled, the owner reserve for a new SignerList is 5 XRP, re |:-----------------------------------------------------------------|:----------| | B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 | In Development | -Implements a "Negative UNL" system, where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the liveness of the network during periods of network instability. +Implements a "Negative UNL" system, where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the ability of the network to make progress during periods of network instability. ## OwnerPaysFee diff --git a/content/concepts/issued-currencies/freezes.md b/content/concepts/issued-currencies/freezes.md index 5581483029..1af132809a 100644 --- a/content/concepts/issued-currencies/freezes.md +++ b/content/concepts/issued-currencies/freezes.md @@ -84,15 +84,15 @@ You can only enable the No Freeze setting with a transaction signed by your addr To enable or disable Individual Freeze on a specific trust line, send a `TrustSet` transaction. Use the [`tfSetFreeze` flag](trustset.html#trustset-flags) to enable a freeze, and the `tfClearFreeze` flag to disable it. The fields of the transaction should be as follows: -| Field | Value | Description | -|----------------------|--------|-------------| -| Account | String | The XRP Ledger address to enable or disable the freeze. | -| TransactionType | String | `TrustSet` | -| LimitAmount | Object | Object defining the trust line to freeze. | -| LimitAmount.currency | String | Currency of the trust line (cannot be XRP) | -| LimitAmount.issuer | String | The XRP Ledger address of the counterparty to freeze | -| LimitAmount.value | String | The amount of currency you trust this counterparty to issue to you, as a quoted number. From the perspective of a financial institution, this is typically `"0"`. | -| Flags | Number | To enable a freeze, use a value with the bit `0x00100000` (tfSetFreeze) enabled. To disable a freeze, use a value with the bit `0x00200000` (tfClearFreeze) enabled instead. | +| Field | Value | Description | +|--------------------------|--------|-------------| +| `Account` | String | The XRP Ledger address to enable or disable the freeze. | +| `TransactionType` | String | `TrustSet` | +| `LimitAmount` | Object | Object defining the trust line to freeze. | +| `LimitAmount`.`currency` | String | Currency of the trust line (cannot be XRP) | +| `LimitAmount`.`issuer` | String | The XRP Ledger address of the counterparty to freeze | +| `LimitAmount`.`value` | String | The amount of currency you trust this counterparty to issue to you, as a quoted number. From the perspective of a financial institution, this is typically `"0"`. | +| Flags | Number | To enable a freeze, use a value with the bit `0x00100000` (`tfSetFreeze`) enabled. To disable a freeze, use a value with the bit `0x00200000` (`tfClearFreeze`) enabled instead. | Set the `Fee`, `Sequence`, and `LastLedgerSequence` parameters [in the typical way](transaction-basics.html#signing-and-submitting-transactions). @@ -126,14 +126,14 @@ Example of submitting a TrustSet transaction to enable an individual freeze usin ### Using RippleAPI -To enable or disable Individual Freeze on a specific trust line, prepare a *Trustline* transaction using the [prepareTrustline](rippleapi-reference.html#preparetrustline) method. The fields of the `trustline` parameter should be set as follows: +To enable or disable Individual Freeze on a specific trust line, prepare a `Trustline` transaction using the [`prepareTrustline()` method](rippleapi-reference.html#preparetrustline). The fields of the `trustline` parameter should be set as follows: -| Field | Value | Description | -|--------------|--------|-------------| -| currency | String | The [currency](rippleapi-reference.html#currency) of the trust line to freeze (cannot be XRP) | -| counterparty | String | The [XRP Ledger address](rippleapi-reference.html#address) of the counterparty | -| limit | String | The amount of currency you trust this counterparty to issue to you, as a quoted number. From the perspective of a financial institution, this is typically `"0"`. | -| frozen | Boolean | `true` to enable Individual Freeze on this trust line. `false` to disable Individual Freeze. | +| Field | Value | Description | +|----------------|--------|-------------| +| `currency` | String | The [currency](rippleapi-reference.html#currency) of the trust line to freeze (cannot be XRP) | +| `counterparty` | String | The [XRP Ledger address](rippleapi-reference.html#address) of the counterparty | +| `limit` | String | The amount of currency you trust this counterparty to issue to you, as a quoted number. From the perspective of a financial institution, this is typically `"0"`. | +| `frozen` | Boolean | `true` to enable Individual Freeze on this trust line. `false` to disable Individual Freeze. | The rest of the [transaction flow](rippleapi-reference.html#transaction-flow) is the same as any other transaction. @@ -148,7 +148,7 @@ Example JavaScript (ECMAScript 6) code to enable Individual Freeze on a trust li ### Using `rippled` -To enable Global Freeze on an address, send an `AccountSet` transaction with the [asfGlobalFreeze flag value](accountset.html#accountset-flags) in the `SetFlag` field. To disable Global Freeze, put the asfGlobalFreeze flag value in the `ClearFlag` field instead. +To enable Global Freeze on an address, send an `AccountSet` transaction with the [`asfGlobalFreeze` flag value](accountset.html#accountset-flags) in the `SetFlag` field. To disable Global Freeze, put the `asfGlobalFreeze` flag value in the `ClearFlag` field instead. Example of submitting an AccountSet transaction to enable Global Freeze using the [WebSocket API](get-started-with-the-rippled-api.html#websocket-api): @@ -176,11 +176,11 @@ Example of submitting an AccountSet transaction to enable Global Freeze using th ### Using RippleAPI -To enable or disable Global Freeze on an address, prepare a **Settings** transaction using the [prepareSettings](rippleapi-reference.html#preparesettings) method. The `settings` parameter should be an object set as follows: +To enable or disable Global Freeze on an address, prepare a **Settings** transaction using the [`prepareSettings()` method](rippleapi-reference.html#preparesettings). The `settings` parameter should be an object set as follows: -| Field | Value | Description | -|--------------|--------|-------------| -| globalFreeze | Boolean | `true` to enable a Global Freeze on this address. `false` to disable Global Freeze. | +| Field | Value | Description | +|----------------|--------|-------------| +| `globalFreeze` | Boolean | `true` to enable a Global Freeze on this address. `false` to disable Global Freeze. | The rest of the [transaction flow](rippleapi-reference.html#transaction-flow) is the same as any other transaction. @@ -196,7 +196,7 @@ Example JavaScript (ECMAScript 6) code to enable Global Freeze on an address: ### Using `rippled` -To enable No Freeze on an address, send an `AccountSet` transaction with the [asfNoFreeze flag value](accountset.html#accountset-flags) in the `SetFlag` field. You must sign this transaction using the master key. Once enabled, you cannot disable No Freeze. +To enable No Freeze on an address, send an `AccountSet` transaction with the [`asfNoFreeze` flag value](accountset.html#accountset-flags) in the `SetFlag` field. You must sign this transaction using the master key. Once enabled, you cannot disable No Freeze. Example of submitting an AccountSet transaction to enable No Freeze using the [WebSocket API](get-started-with-the-rippled-api.html#websocket-api): @@ -225,11 +225,11 @@ WebSocket request: ### Using RippleAPI -To enable No Freeze on an address, prepare a **Settings** transaction using the [prepareSettings](rippleapi-reference.html#preparesettings) method. Once enabled, you cannot disable No Freeze. The `settings` parameter should be an object set as follows: +To enable No Freeze on an address, prepare a **Settings** transaction using the [`prepareSettings() method`](rippleapi-reference.html#preparesettings). Once enabled, you cannot disable No Freeze. The `settings` parameter should be an object set as follows: -| Field | Value | Description | -|----------|---------|-------------| -| noFreeze | Boolean | `true` | +| Field | Value | Description | +|------------|---------|-------------| +| `noFreeze` | Boolean | `true` | You must [sign](rippleapi-reference.html#sign) this transaction using the master key. The rest of the [transaction flow](rippleapi-reference.html#transaction-flow) is the same as any other transaction. @@ -246,22 +246,22 @@ Example JavaScript (ECMAScript 6) code to enable No Freeze on an address: To see if a trust line has an Individual Freeze enabled, use the [account_lines method][] with the following parameters: -| Field | Value | Description | -|----------|---------|-------------| -| account | String | The XRP Ledger address of the issuer | -| peer | String | The XRP Ledger address of the counterparty | -| ledger\_index | String | Use `validated` to get the most recently validated information. | +| Field | Value | Description | +|----------------|--------|-------------| +| `account` | String | The XRP Ledger address of the issuer | +| `peer` | String | The XRP Ledger address of the counterparty | +| `ledger_index` | String | Use `validated` to get the most recently validated information. | The response contains an array of trust lines, for each currency in which the issuing address and the counterparty are linked. Look for the following fields in each trust line object: -| Field | Value | Description | -|--------------|---------|-------------| -| freeze | Boolean | (May be omitted) `true` if the issuing address has frozen this trust line. If omitted, that is the same as `false`. | -| freeze\_peer | Boolean | (May be omitted) `true` if the counterparty has frozen this trust line. If omitted, that is the same as `false`. | +| Field | Value | Description | +|---------------|---------|-------------| +| `freeze` | Boolean | (May be omitted) `true` if the issuing address has frozen this trust line. If omitted, that is the same as `false`. | +| `freeze_peer` | Boolean | (May be omitted) `true` if the counterparty has frozen this trust line. If omitted, that is the same as `false`. | Example WebSocket request to check for individual freeze: -``` +```json { "id": 15, "command": "account_lines", @@ -297,7 +297,7 @@ Example WebSocket response: } ``` -The field `"freeze": true` indicates that rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn has enabled Individual Freeze on the USD trust line to rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW. The lack of a field `"freeze_peer": true` indicates that the counterparty has _not_ frozen the trust line. +The field `"freeze": true` indicates that `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` has enabled Individual Freeze on the USD trust line to `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`. The lack of a field `"freeze_peer": true` indicates that the counterparty has _not_ frozen the trust line. ### Using RippleAPI @@ -329,10 +329,10 @@ Example JavaScript (ECMAScript 6) code to check whether a trust line is frozen: To see if an address has enabled Global Freeze, No Freeze, or both, use the [account_info method][] with the following parameters: -| Field | Value | Description | -|----------|---------|-------------| -| account | String | The XRP Ledger address of the issuing address | -| ledger\_index | String | Use `validated` to get the most recently validated information. | +| Field | Value | Description | +|----------------|--------|-------------| +| `account` | String | The XRP Ledger address of the issuing address | +| `ledger_index` | String | Use `validated` to get the most recently validated information. | Check the value of the `account_data.Flags` field of the response using the [bitwise-AND](https://en.wikipedia.org/wiki/Bitwise_operation#AND) operator: @@ -407,10 +407,10 @@ To see if an address has enabled Global Freeze, No Freeze, or both, use the [`ge Look for the following values in the response object: -| Field | Value | Description | -|---------------|---------|-------------| -| noFreeze | Boolean | (May be omitted) `true` if No Freeze is enabled. | -| globalFreeze | Boolean | (May be omitted) `true` if Global Freeze is enabled. | +| Field | Value | Description | +|----------------|---------|-------------| +| `noFreeze` | Boolean | (May be omitted) `true` if No Freeze is enabled. | +| `globalFreeze` | Boolean | (May be omitted) `true` if Global Freeze is enabled. | Example JavaScript (ECMAScript 6) code to check whether an address has Global Freeze or No Freeze enabled: diff --git a/tool/spelling.txt b/tool/spelling.txt index b198728d68..8aa134a6ff 100644 --- a/tool/spelling.txt +++ b/tool/spelling.txt @@ -331,6 +331,7 @@ fix1571 fix1578 fix1623 fix1781 +fixamendmentmajoritycalc fixcheckthreading fixmasterkeyasregularkey fixpaychanrecipientownerdir @@ -362,6 +363,7 @@ micropayments multisign multisigning multisignreserve +negativeunl noripple noripple_check nudb @@ -421,3 +423,4 @@ xrpchat britto macbrough +xrpscan From f8a1cb51da842ae5037b6f8f1f220420b029f60c Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 27 Jul 2020 11:13:44 -0700 Subject: [PATCH 37/65] Clarify [ledger_history] --- .../the-rippled-server/ledger-history/ledger-history.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/concepts/the-rippled-server/ledger-history/ledger-history.md b/content/concepts/the-rippled-server/ledger-history/ledger-history.md index 5cd44731fb..c5e5f361e7 100644 --- a/content/concepts/the-rippled-server/ledger-history/ledger-history.md +++ b/content/concepts/the-rippled-server/ledger-history/ledger-history.md @@ -31,7 +31,7 @@ The XRP Ledger identifies data (on several different levels) by a unique hash of The amount of history a server attempts to download depends on its configuration. The server automatically tries to fill gaps by downloading history up to **the oldest ledger it already has available**. You can use the `[ledger_history]` setting to make the server backfill history beyond that point. However, the server never downloads ledgers that would be scheduled for [deletion](online-deletion.html). -The `[ledger_history]` setting defines a minimum number of ledgers to accumulate. Use the special value `full` to download the [full history](#full-history) of the network. If you specify a number of ledgers, it must be equal to or more than the `online_deletion` setting; you cannot use `[ledger_history]` to make the server download _less_ history. To reduce the amount of history a server stores, change the [online deletion](online-deletion.html) settings instead. +The `[ledger_history]` setting defines a minimum number of ledgers to accumulate from before the current validated ledger. Use the special value `full` to download the [full history](#full-history) of the network. If you specify a number of ledgers, it must be equal to or more than the `online_deletion` setting; you cannot use `[ledger_history]` to make the server download _less_ history. To reduce the amount of history a server stores, change the [online deletion](online-deletion.html) settings instead. From f10a29753026fee04e8e6db5c1550a50f9939c7f Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 13:06:16 -0700 Subject: [PATCH 38/65] Adds comment syntax to commandline input for account_lines.md --- .../public-rippled-methods/account-methods/account_lines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 7cf6b4b365..a747683945 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,7 +35,7 @@ An example of the request format: *Commandline* ```sh -#Syntax: +#Syntax: account_lines [] [|] rippled account_lines r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 ``` From 96e126e7e05f25c821153a0a9c0ef2ed6b763149 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 13:20:37 -0700 Subject: [PATCH 39/65] Changes account example to account that has a non-empty list of offers for account_offers.md --- .../account-methods/account_offers.md | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) 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 d69fa7bede..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 ``` @@ -157,9 +157,21 @@ An example of a successful response: ```json { "result" : { - "account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", - "ledger_current_index" : 56843824, - "offers" : [], + "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 } From 1802c4fc297db3c1b6d977a828a14ad802b49b16 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 13:46:33 -0700 Subject: [PATCH 40/65] Moves commandline note to correct location; adds json commandline input example --- .../account-methods/gateway_balances.md | 29 ++++++++++++++----- 1 file changed, 22 insertions(+), 7 deletions(-) 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 a5da28acfc..4d4bc3cc2d 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: +**Note:** There is no command-line syntax for this method. Use the [json method][] to access this from the command line. + *WebSocket* @@ -42,7 +44,7 @@ An example of the request format: *Commandline* ``` -gateway_balances rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q +rippled json gateway_balances ' {"account": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q", "hotwallet": ["rKm4uWpg9tfwbVSeATv4KxDe6mpE9yPkgJ", "ra7JkEzrgeKHdzKgo4EUUVBnxggY4z37kt"],"ledger_index": "validated","strict": true} ' ``` @@ -229,6 +231,20 @@ An example of a successful response: } ] }, + "balances" : { + "rKm4uWpg9tfwbVSeATv4KxDe6mpE9yPkgJ" : [ + { + "currency" : "EUR", + "value" : "144816.1965999999" + } + ], + "ra7JkEzrgeKHdzKgo4EUUVBnxggY4z37kt" : [ + { + "currency" : "USD", + "value" : "6677.38614" + } + ] + }, "frozen_balances" : { "r4keXr5myiU4iTLh68ZqZ2CgsJ8dM9FSW6" : [ { @@ -237,23 +253,22 @@ An example of a successful response: } ] }, - "ledger_current_index" : 56866688, + "ledger_hash" : "6C789EAF25A931565E5936042EED037F287F3348B61A70777649552E0385B0E4", + "ledger_index" : 57111383, "obligations" : { "BTC" : "1762.700511879441", - "EUR" : "958608.6233004864", + "EUR" : "813792.4267005104", "GBP" : "4974.337212333351", - "USD" : "6746387.604424974" + "USD" : "6739710.218284974" }, "status" : "success", - "validated" : false + "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: | `Field` | Type | Description | From 7be89d0f184bebaeede7b25cd71894e97b8db4b4 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 13:49:19 -0700 Subject: [PATCH 41/65] Moves commandline input note to correct location for noripple_check.md --- .../public-rippled-methods/account-methods/noripple_check.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 d43cf65ba2..6fb0670110 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 @@ -3,11 +3,12 @@ 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. -**Note:** There is no commandline version of this method. ## Request Format 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. + *WebSocket* @@ -43,7 +44,6 @@ 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: From 8ced2eb321cdb1e3072bb897b6fd36b7e071899c Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 14:02:59 -0700 Subject: [PATCH 42/65] Removes commandline example request and response as well as moves commandline note for ledger_data.md --- .../ledger-methods/ledger_data.md | 3776 +---------------- 1 file changed, 2 insertions(+), 3774 deletions(-) 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 90d73ce862..b304dc174c 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: +**Note:** There is no commandline syntax for `ledger_data`. You can use the [json method][] to access this method from the commandline instead. + *WebSocket* @@ -35,14 +37,8 @@ An example of the request format: } ``` -*Commandline* -``` -rippled ledger_data -``` - -**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: @@ -235,3774 +231,6 @@ An example of a successful response: } ``` -*Commandline* -```json -{ - "result" : { - "ledger" : { - "closed" : false, - "ledger_index" : "56867513", - "parent_hash" : "1377C0CAD6B0D331CCD3815753469A84D08DDA230481EE5CEA807D30F0AF0E11", - "seqNum" : "56867513" - }, - "ledger_current_index" : 56867513, - "ledger_hash" : "1377C0CAD6B0D331CCD3815753469A84D08DDA230481EE5CEA807D30F0AF0E11", - "ledger_index" : 56867513, - "marker" : "0004FCA7BBB8123368374A908D4B9146B42780E3F91653BB1D144795A9E8676E", - "state" : [ - { - "Account" : "rMj5DFATVxw91PDy3AM2wu7Uu1kgrhWypE", - "Balance" : "107723001", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "F18F0DF4B4921A468A5F968CE6E04EA800799C67E0659B9C4588988BCE9972B4", - "PreviousTxnLgrSeq" : 53524108, - "Sequence" : 3, - "index" : "000003E6AFED1AADCC39AAE0727B354C2286F1503274F345FE661748F24366CF" - }, - { - "Balance" : { - "currency" : "GCB", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2162688, - "HighLimit" : { - "currency" : "GCB", - "issuer" : "rBfVgTnsdh8ckC19RM8aVGNuMZnpwrMP6n", - "value" : "0" - }, - "HighNode" : "0000000000000283", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "GCB", - "issuer" : "rhRFGCy2RJTA8oxkjjtYTvofPVGqcgvXWj", - "value" : "2000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "C0C37CE200B509E0A529880634F7841A9EF4CB65F03C12E6004CFAD9718D6694", - "PreviousTxnLgrSeq" : 24695242, - "index" : "0000041EFD027808D3F78C8352F97E324CB816318E00B977C74ECDDC7CD975B2" - }, - { - "Account" : "rHeyw38ezc3LSLzYAYwaBci2KssDkYGVr9", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "7540CE04B966D67DBD39F3AA832274902B79AF4782F5AC9D4DC7CD18B1D9AE0D", - "PreviousTxnLgrSeq" : 47846971, - "Sequence" : 2, - "index" : "000004D417A9CE049C9A71A62B004659B5F1AAAB1BEA1EFDE4E01EB3497FD999" - }, - { - "Account" : "rLeNL66BfgeszBsCBKJcLmYTRThiWrNTUL", - "Balance" : "19999988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "E4BE6307E377590FF56BBF2F26DCBC4BA9682A4C141269352E4E2D4E53C1116E", - "PreviousTxnLgrSeq" : 37851086, - "Sequence" : 2, - "index" : "00000FB78838CA2CFA82E7438B4F54794A6783327326D58C46B4EF137C059038" - }, - { - "Account" : "rUwXrQMa4HHBbfxQT71YJNbQXaxZPR8Uhp", - "Balance" : "4999941286", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "B24817E7D4B9EC5CB29D2D36215F7BD6C7526020A9C1DC6C892C788E195DFCC4", - "PreviousTxnLgrSeq" : 55172051, - "Sequence" : 1, - "index" : "000012F60C3F1E226D03F974AE8E77250B2BEA91C38AB4146B6055A048C7D540" - }, - { - "Flags" : 0, - "IndexNext" : "00000000000019A5", - "IndexPrevious" : "00000000000019A3", - "Indexes" : [ - "07B06AC59BE6D6B3A4EA9B813FE3A13CF7F6FA21BB92D5F691CFE09FAD733EEB", - "19D40E64B1AB5270A8470542459BC8171A2BC119AD308C46C383495C1595503D", - "2358E16921A1A577B380F3E000452795D54237ED52A3B21C19ED5C8E2CACCC7B", - "2817196B387099A9651055D277411847EC9E904FB71CB9CC5CF2931309AC7B6A", - "39EACF818BBC1581BCE5121A0046C6A8E07EB52C051F3961465D2D612A728684", - "5326601A89F1529F3675DC13BF0F430E005A55CD0347601532B61A6B43538839", - "5D2F1DBFE9475D69F365D37B545644CF18CEE20E4A8276030545F40A495F3F28", - "5E15CE61F291F1119338F4876C5A29EAE547F1AB2C8AAE6598DB2F3F6436067D", - "829D72DCB03F7E01ED508287E1862471DAE1F438C95814705388950D35935969", - "87C2963F5A673B1BC9FD3835F1B45A20C50E2654B81739ED33522E33D09323E4", - "8ECBBA2E63E79F4D9FE2053EC9E497614F5522F40C54D874A16BB31E46DB01D0", - "938224E0CB58A1DD8879C8167FA5D95D634AD6CF8223BA80923F8566D70A3382", - "A59CC6C97348E202CE28A47C3DD0422C3CD173F6BD6B8D0EBC78407DDC1A4D30", - "B34C5B770B6CE3507876B6F6C9C45D53B74EAC8A0705F6E252751A53F3CAF18E", - "B74A96E754DFD2BC20B913B1586410CBB69CF53B497DFD48330CD8D44FFBA652", - "BC704823EFD7641B44E7509F2C3EF29596A9C2D95AADA3C3759BE4F9962F3E4E", - "CBC998EFF58214B886935FEE119DA9CD363489DED76306BE21F4B24A1D9B406E", - "D754ED5085D5B6A6A9F7C96325DE848292DD4C79F7FFC273F6D76D7A87F7BE7E", - "E82FC929F4AF4B2ACA74185633FA0D65E86DD65E505EEC38D1140D489772461E", - "F167F314E3BBFBBDC480860C7266C7C3440764CDF0ACA66F4AFEBD7F92C53FB2" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "RootIndex" : "D7AC7D74720E29A563100F2B494BADB198F8A9E9FA46F57AE07123151E0DFA7A", - "index" : "0000139EDA03EF58CE7176F1402035B5EB6AEE49724555DDB0EBA01432B009A8" - }, - { - "Account" : "rKKzk9ghA2iuy3imqMXUHJqdRPMtNDGf4c", - "Balance" : "40000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 4, - "PreviousTxnID" : "CF650E9A4AAE1ADFDF2633AE71F1782ADA4D3B52C949FEEC2FF3DAAF8C301762", - "PreviousTxnLgrSeq" : 42071651, - "Sequence" : 38, - "index" : "00001A2969BE1FC85F1D7A55282FA2E6D95C71D2E4B9C0FDD3D9994F3C00FF8F" - }, - { - "Account" : "rsSbmeMPVnpwWbDyY6HD9v8TYSg7kFNJga", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "4A12CCD9C8C28088A13D86A44F1C80B81387BD34520A0556509FF5404D9FA05C", - "PreviousTxnLgrSeq" : 45123172, - "Sequence" : 2, - "index" : "00001CA2EE28952E26D329A26BCF7A0DFB655C571863CD7CCCB924101CA3832B" - }, - { - "Flags" : 0, - "Indexes" : [ "4186664D76AFFB709791E2C23CE2B7D1843831F1B9B2D23D29B81108E46D1DED" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rJYkq4c6QxzuNaM8ELZWH2fdzvFRnCmXg8", - "RootIndex" : "00001FB94BFF05D391C58C5F72DB5A537F5C4AF8C91786B4A6AE874179928E87", - "index" : "00001FB94BFF05D391C58C5F72DB5A537F5C4AF8C91786B4A6AE874179928E87" - }, - { - "Account" : "rfTzpaFG3VXJsz5DmDhgrWD7Z7bSFWT4UE", - "Balance" : "20150090", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "E55C1DDDFE20148D1BE0A201E663DFBB282374000C43AE9A1745277CED7450AE", - "PreviousTxnLgrSeq" : 53524253, - "Sequence" : 2, - "index" : "000023E2F2CF80DCDE1C03D848B78FAB5E2B73512ADBA3EC78C85AE291932FBC" - }, - { - "Account" : "rh6iGDTJpZCGf86b81wkZ3BotUaKfRxaaN", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "1E9E5BAFDD854F3713D6E06CADE2C84E6C6F7191B6B57A153A7D6CA79C4D110D", - "PreviousTxnLgrSeq" : 35033153, - "Sequence" : 2, - "index" : "00002499977F7BBE9850B47AC2B560B69A809F1CED66F9DAC7C12CA8CCB40F4E" - }, - { - "Flags" : 0, - "Indexes" : [ - "136C747528D439646FE88DC99D2C9E308A7C72F17D844EC38271110118215CE1", - "55C7A61CCF63A11E20E5276D2ABE35432A42ED03D6C492CC68C93E91ECBC3EFE", - "66FCEB2CDFF777F27E04CF86EADF4D5A665AA122F6A7EE6F0CF2718D4B7D6295", - "6A331A832765BA269E9F3D7F211380501E5C6AA59AA0955FB177A0EA0025E60F" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rGRaBuffuAaaeedpvkrRM3cmX3SCK7zpaV", - "RootIndex" : "000025097E81A5B6FF027221FBB3B3CAFFF6FA690B78DA6EA0DF6E880CBA0A20", - "index" : "000025097E81A5B6FF027221FBB3B3CAFFF6FA690B78DA6EA0DF6E880CBA0A20" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rwdf1Yb6BpTkZyH9LwP5KagqK5c1uMYFPd", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "LowNode" : "0000000000000CBC", - "PreviousTxnID" : "84AD7C491291135D4FAB7C9AA8D5760105D95A42BBDCF88DA3F66EDF750A929D", - "PreviousTxnLgrSeq" : 34789991, - "index" : "000027B473B2EAB084323383428D054E66249BEC4AB16515256FEF2D27CD8D23" - }, - { - "Account" : "rKUN4CjifHrBc7yLjgQCDRPxaKevj5VkhX", - "Balance" : "4796311032", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "4F95433B1598042BD89F81C2CA1861E2340E2772F6A591F4D91E87BA38484B72", - "PreviousTxnLgrSeq" : 55179796, - "Sequence" : 3, - "index" : "000030C724B3C25B89A73D776005E33ACA9F7A1AEFB7538584AA8E9B36C93B8E" - }, - { - "Account" : "rD5TQBCZoHHnQQMHzd3bfqb8BHsDw94Msu", - "Balance" : "19988000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "B87984992FBCD48CA49101E7DC767D9F90889B601F79264F85104BB56F110531", - "PreviousTxnLgrSeq" : 10696061, - "Sequence" : 2, - "index" : "000033E22A320E5D1EA62689C561CB324FFE1103180947065079EB73812717A9" - }, - { - "Balance" : { - "currency" : "BRL", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0.63235217563" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "BRL", - "issuer" : "rfNZPxoZ5Uaamdp339U9dCLWz2T73nZJZH", - "value" : "0" - }, - "HighNode" : "000000000000005C", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BRL", - "issuer" : "rauwJ9JC6M6JtMG5dRw9Csny7ZHVBF1tFv", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "26736CF97C8F707109717C1123BB33FBB7B6312332877469A0F82FF2E1F10805", - "PreviousTxnLgrSeq" : 36874911, - "index" : "000036A8D891AE85170EDA8658B52EA21C163185A008B14506F3D6EE8C90C5ED" - }, - { - "Account" : "rnKNNFcbsZSDDnYFSpHSkRBYvsrP29ocBJ", - "Balance" : "49988981", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 3, - "PreviousTxnID" : "D6018D595E70972CF01A1351554D9F51951502C625A0CE5FB7B55001A3809D7E", - "PreviousTxnLgrSeq" : 30498238, - "Sequence" : 46, - "index" : "000036B2E4602C42011987825C97BCB0BEA3396115C2418BE9D70BB2BCA32BBA" - }, - { - "Account" : "r4ysrf6g7T6QgLGe6FtGQudWhRnxmyQaGK", - "Balance" : "20010988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "8B707CB44D543F12EBB2E3A3C65596B63C6F7B9AE1E77A6073D0469927E39F9B", - "PreviousTxnLgrSeq" : 39876093, - "Sequence" : 2, - "index" : "00003B5A931AE159DCDDABBDBB32A8F26B07A74203817009097B3F8F4440FF29" - }, - { - "Account" : "raAUvyzqUKM3JWZgGuwGfEfxUJJbpVnrQA", - "Balance" : "48575070060", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "29F37B398FCA123B8B4FAD88510170F156ACEA8E65AA21E8536997A9B238667F", - "PreviousTxnLgrSeq" : 56468588, - "Sequence" : 2, - "index" : "000043EE9FCE52E7691EB21E714D3FE5AE641363317C7D856085B7A0C2BE66EA" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-2500201.004512104" - }, - "Flags" : 1179648, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rGo32zaBLSBwC1fTYHjBsZxQk3Mo9E8rDZ", - "value" : "20000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rbwE6wsxzYat1YyGGxzAwq6wBSF5MdoAg", - "value" : "0" - }, - "LowNode" : "000000000000004F", - "PreviousTxnID" : "6BD812D3AF63299DFD1C123C76D366752AA4F09D0076D868EFC950A967C1B1D7", - "PreviousTxnLgrSeq" : 27109989, - "index" : "0000457D66BD69769E4BB05DDAB4269F5EB1A095026FDB04816058385D09568B" - }, - { - "Account" : "rP6dAps4bwHTf8bNNkhA4YKx3DeMNdr8sA", - "Balance" : "1886187898", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "73C54DAC576C4DA8851B47F9D802123C942C21026AF13B849F22215ED8AFA0A4", - "PreviousTxnLgrSeq" : 56330724, - "Sequence" : 1, - "index" : "00004718F616B0CC7E12949C8AC399A9FB383311C5515C110194223F1A8FE627" - }, - { - "Balance" : { - "currency" : "JPY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "30" - }, - "Flags" : 3211264, - "HighLimit" : { - "currency" : "JPY", - "issuer" : "rDKcJtUW5b8URJB5AVb41jkTeETfXWwahe", - "value" : "0" - }, - "HighNode" : "0000000000000029", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "JPY", - "issuer" : "rpNSWfSE2TkmwH4VK26d6RGwC7rzQb7xKt", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "3B7C0DE2A9F5FD2CC1C058763690EECB3452C76C6595F97318C98BF8D105DD52", - "PreviousTxnLgrSeq" : 34623483, - "index" : "0000484CEEDC4DAE666B2C2DEFD726575DD1D5197CC32C38B63F1D265462BD48" - }, - { - "Account" : "rEngbD1J8rrrMkKz8fBtdLRgarmMZTiNRt", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "1D8544851DF1E3B73B4299707AE9FBA4D9A375D30EDE6A7F9F6D2F9905AAA1DC", - "PreviousTxnLgrSeq" : 35751340, - "Sequence" : 1, - "index" : "00004C6EC792D443262DB347376ADB5781FCD6EC84E233826C9172BC14316D1B" - }, - { - "Account" : "r4arcs5ngLPmDeYoDLzaG7q5eWKs2LeuFK", - "Balance" : "200824800", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "9E6D3DC20F4069FAF1F25E2C26BBD8BD8BBBCCB13F92EC4AD4A190D5753604A3", - "PreviousTxnLgrSeq" : 37180721, - "Sequence" : 1, - "index" : "00004CA3D9AA87A56017E8CD56893DAECA090EF8CC393EA38758E22B5BDC7159" - }, - { - "Account" : "rDtMRovj32kjpJpnBR2HUqHAZ5HYjauFrL", - "Balance" : "614201036", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "CBC27919116C08DC751C8E2ED1E9772519C610F93FE8CE9414ACEC6E1E245AAC", - "PreviousTxnLgrSeq" : 45157979, - "Sequence" : 55, - "index" : "00005E8982DE87680E6D3DC143FD0B73A30EF873D1C6EB9F371BBE140F6D49DF" - }, - { - "Balance" : { - "currency" : "CAD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "99.67048908512925" - }, - "Flags" : 196608, - "HighLimit" : { - "currency" : "CAD", - "issuer" : "rnziParaNb8nsU4aruQdwYE3j5jUcqjzFm", - "value" : "60" - }, - "HighNode" : "0000000000000011", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CAD", - "issuer" : "rsPwcozMqkCr76TvABBjyzaGqvUrpcxafd", - "value" : "100" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "5CB4D8512C74A21DB45DD67F409A7E784FA79E0E0ABCBD3208574A3D4E48AA44", - "PreviousTxnLgrSeq" : 39514920, - "index" : "0000655AD48998D4F3D931356363FFBFE89416DD21A9159F647AEE3652AA076D" - }, - { - "Account" : "r4rZuKQRF3DpuVoftMfz9q6cae9UXiiTEA", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "2F586F9E23348AF1A6E2E5C11908A269657CBD61A8CB4C4A1CE69FBB34979643", - "PreviousTxnLgrSeq" : 54003659, - "Sequence" : 2, - "index" : "000065C9F41ABE752CBBF18C15B35294045A686B7242B14D6FE5175C48459BFE" - }, - { - "Balance" : { - "currency" : "ALV", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.3" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "ALV", - "issuer" : "rPJM3GsQjpZLd3CQWSpqGs1qWEG1X4vpSm", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ALV", - "issuer" : "raEQc5krJ2rUXyi6fgmUAf63oAXmF7p6jp", - "value" : "0" - }, - "LowNode" : "000000000000005C", - "PreviousTxnID" : "4B905BDB67CDCE068FB216B7ED3833C0743944B8170B3FB4BBF2C124EA6C7BE7", - "PreviousTxnLgrSeq" : 37878390, - "index" : "00006CB62921C8A4D42D4375440A0636104A1F6F3E48ADBFF9D83A405D241223" - }, - { - "Account" : "rKQSz4tYnAi4au4v8eEa6hkUrDjukLTVi4", - "Balance" : "20420366", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "80755ECA9A09E3D9A05D012FEB2F0DE2D6CD93B36478087F4925722E4A8500EA", - "PreviousTxnLgrSeq" : 36172509, - "Sequence" : 6, - "index" : "00006D7682A29260C4079ABC2E810ECF68AE784D4E7E5E152F587C3A0816F254" - }, - { - "Account" : "rEhKQnKYjTBqmWyWGfYtJgx9CxCBauLu3S", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "F18D40F603177CE74689FFB5972EC4A167B639A2F2A11AB7671B32CB7A9F3118", - "PreviousTxnLgrSeq" : 35040704, - "Sequence" : 2, - "index" : "0000710FFC8D60A8BCA7BA5BFC00EE81FC7D3BB2AE5E8ECE92CC4E441B63CE80" - }, - { - "Account" : "rJLQ56pHabZ6o2mNSmprBxy6DdCwdxTAzd", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "E18725C56FB60084F05162BCE7946861A470AE620BDD5DE519D15D260594578D", - "PreviousTxnLgrSeq" : 42119175, - "Sequence" : 4, - "index" : "00007429BB237782C9406EF25B09463DD751712E4D21F49DC221CFE4CF262660" - }, - { - "Balance" : { - "currency" : "ADA", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "ADA", - "issuer" : "rJXGFDrN5h3ooiCSsupPXhg81QgGtUQmeJ", - "value" : "0" - }, - "HighNode" : "0000000000000001", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ADA", - "issuer" : "r9TPUpytcjmo9UaM9kwu6VmDSuVXqSxWUi", - "value" : "1000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "E64DE7F158AD81B20D8E10255CC9BE0ABB39347C80CB61205D538F905A1DCABE", - "PreviousTxnLgrSeq" : 28152986, - "index" : "0000812BF6B7152E240E8A41A224C876F4A006DCD570F2E9FC6BFB34A9A5F960" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rBadiLisPCyqeyRA1ufVLv5qgVRenP2Zyc", - "value" : "0" - }, - "HighNode" : "0000000000000002", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rfVBtKzz4kAuxcaESZv3tF3vcsHfeWBoho", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "12D2D09C90F49889718B60BF3A03493364EB665C0F558EA12CEE1B0C35D5C124", - "PreviousTxnLgrSeq" : 9301047, - "index" : "000082B286E3162EC4ADA91330AF0072D1B51748089906F635AB7B30966C56F4" - }, - { - "Account" : "rPR6WAoPKByT92Sjuji8Y8EABTGaLaACV3", - "Balance" : "209270000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EF6518AB9506BFC883182600E2FDDEC016BEA5412C7C8A3EDFDCEFC06D4CDC3C", - "PreviousTxnLgrSeq" : 35893835, - "Sequence" : 1, - "index" : "000084346288D9C0EC50D79D394230D7C5CB3190DCD9527B8F1FA18084A7DA5C" - }, - { - "Account" : "rJUkQCKwM9smokgL7iD6oyLTx813PaQUiY", - "Balance" : "35009535", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 3, - "PreviousTxnID" : "8227B98C50DD76CAE2D226066CA9C3AFFD3F3F7B97D0CA755BAA0C61465A3808", - "PreviousTxnLgrSeq" : 48263445, - "Sequence" : 36, - "index" : "000086CE48D95A92F078B5128845C3BCDF56E7DA88D7E35089DBE5AFF7D81C0C" - }, - { - "Balance" : { - "currency" : "ETC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "ETC", - "issuer" : "rDAN8tzydyNfnNf2bfUQY6iR96UbpvNsze", - "value" : "0" - }, - "HighNode" : "00000000000001E5", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ETC", - "issuer" : "r3X34kvPSV2jGU7fgUb3wh1XCwr6WCbm94", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "E763D1AF0BFEAA558D42B33361DEB3C7BEDC46AFF41D016EE726554C4C365294", - "PreviousTxnLgrSeq" : 34855014, - "index" : "00009472587A9D425875950F0FA34CDC7A69F384AC28A756C5A2322AE0F0A1C1" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "00000000000002D9", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rpHbU3xao4QxtqHSFS8ojDMxPFcbasrRmb", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "7B25FC571E190538386BEE9F2CEC94E01BC6455B3872151C693171101D5EEF9E", - "PreviousTxnLgrSeq" : 29254689, - "index" : "000099FD3C2741BAF3C66AC48F770DDE2B32C16AC81EAAD88262866B263F5523" - }, - { - "Account" : "rNB3TknEkY3kjpwNCGVxpvBwyowyGuwfVh", - "Balance" : "23169305", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "09574601F2AEDFFF4CF61CF377C298F07FC9A13B5127B4C53EED3B29A756F70C", - "PreviousTxnLgrSeq" : 35690032, - "Sequence" : 4, - "index" : "00009C1C21886B5C2BDE0B7751F96EBC3B7C8C57AA8D16E3A818591624A1A5A9" - }, - { - "Account" : "rKbyYMKzTgvhsUqgeEbpdq6WvQc8rupMGn", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "8D54FAD13DD5B90133B3FA1F2BDBFA15559DA35159B670AB8B5FF51F29EE39A0", - "PreviousTxnLgrSeq" : 33977868, - "Sequence" : 2, - "index" : "00009C2BEF50C671658F700078E740B87F650E081B55CC3FA32A00475F621D66" - }, - { - "Account" : "rLkrSbJgLHPdQFn1QcRTCDmRWvZpp27tah", - "Balance" : "50624403", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "412FAE0959898C325238876A0C039096C39B25A3810C708D56C9899FB2384903", - "PreviousTxnLgrSeq" : 35648800, - "Sequence" : 5, - "index" : "00009D28A1AE6FFC984B771DAE107699091DF44F6910FD05B12CC09E3F7DE801" - }, - { - "Balance" : { - "currency" : "XEC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2162688, - "HighLimit" : { - "currency" : "XEC", - "issuer" : "rMpiGaEM9Qp3icX7wPHTdxbkphHWLJcX34", - "value" : "0" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "XEC", - "issuer" : "rNx3ty1w48iAa4JDfqhZk6bphwXxvCEtZP", - "value" : "0" - }, - "LowNode" : "0000000000000007", - "PreviousTxnID" : "01AD5E21337686A2F709773A28501B2023D3A950550BEB03C43462B98731A9E9", - "PreviousTxnLgrSeq" : 35883799, - "index" : "00009E2036FD1B363A6E2B6752F7C672D652E3A559579BFF3C493587C8C231C3" - }, - { - "Account" : "rDR96JmJAsEgZThPnREZTSdjKPZDnH5k5f", - "Balance" : "153819291", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "EB5515580E16071F0EA96B3313D72C6545F23CDF0C32547A9ACCB2FCE404A4F0", - "PreviousTxnLgrSeq" : 35368386, - "Sequence" : 7, - "index" : "0000A80432DEC44EE6228DE4A0528EFF76E28288D5E2A0384DD3432D976984A3" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.000459110023164767" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rPireoEmXsz8hke3T7mrdDkqfzxj4uY4ae", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", - "value" : "0" - }, - "LowNode" : "0000000000001003", - "PreviousTxnID" : "1F9E636AC4FEE0C01EEE0E0559121689AABC70BE7ECF5B60E4ECB78627523583", - "PreviousTxnLgrSeq" : 41398225, - "index" : "0000A9D1FDBC542726D379D855E4CB3E2C05483B6F033F43408DAE9E1838B70B" - }, - { - "Account" : "rHKEQxk3G2EEZnsmiCd8RsBM5UigC5qiVe", - "Balance" : "350000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A6382E793984B79E2938C66CCA9F2D694F5CACBAE21B50A3FF9EC40930A12599", - "PreviousTxnLgrSeq" : 34504001, - "Sequence" : 1, - "index" : "0000AC1E487CC20D9FF8314022473B1D5F106D35BFC3BB33032FBF976230B0FF" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rHYSdyKPrtDegWkHibXK3YApwKfn5J1rEN", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", - "value" : "0" - }, - "LowNode" : "000000000000049B", - "PreviousTxnID" : "8424AF691677ACEA9B0113B2CBDC577AABE251E1EDDB018E0744FEE8C90C58DB", - "PreviousTxnLgrSeq" : 31621663, - "index" : "0000B24C620FBD0E8B1313022AA4857E5300FB70FCDE9F194F901D567C70EDFB" - }, - { - "Account" : "rEFh3ZGKaxMJwWPXxiYYa8kiXJyVMJNwoY", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "42F82FF6D1EB50C5DD13784F073F231BA887922AB9958BF2C4A168438711AF88", - "PreviousTxnLgrSeq" : 47429528, - "Sequence" : 2, - "index" : "0000B482CF9E7E9BB4350CF185A306BE9165218401EB559379A00AA0C7915312" - }, - { - "Account" : "rh3C81VfNDhhWPQWCU8ZGgknvdgNUvRtM9", - "Balance" : "13000000894", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "4FEE14F4552879897B61C77CA5E0A884652102EF62396C09835BE9477E2B8969", - "PreviousTxnLgrSeq" : 55182503, - "Sequence" : 1, - "index" : "0000B717320558E2DE1A3B9FDB24E9A695BF05D1A44E4A4683212BB1DD0FBA23" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0.032809672000001" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rKiCet8SdvWxPXnAgYarFUXMh1zCPz432Y", - "value" : "0" - }, - "HighNode" : "00000000000001C0", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rhNTmR8ej24mL1LXv3ZsCnrQop7c6bocQp", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "4710BF02E5791A7D69FC384C874A40E06F1E23E63FA7FD6355D1B439F436B2D5", - "PreviousTxnLgrSeq" : 21050911, - "index" : "0000B87C9CD0F3530C71A8921FBCF127EAECA5C9DA92717AFB1CE9F63C8BBD6E" - }, - { - "Account" : "rhVcmcoptD1Kgeeag9mhsTPWQSZk8eTz9A", - "Balance" : "182376831", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A6803D6CE4199E0F74C52788C7A148E4AF9E9A0CBFF072B469ECC5C0DCB448CB", - "PreviousTxnLgrSeq" : 36446538, - "Sequence" : 1, - "index" : "0000BF2224BB915521C921773AFE11E1CE59CF69F6AE3AB6827707102103C47B" - }, - { - "Balance" : { - "currency" : "ETH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.00002" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "ETH", - "issuer" : "rHzVgKskCRFpg1X3aBU5AtvQnDD5mqSX92", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ETH", - "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", - "value" : "0" - }, - "LowNode" : "00000000000009FD", - "PreviousTxnID" : "AE750643C6C355A176A65981CA9D1831A7C226F230420624CE8C8C32A4C22316", - "PreviousTxnLgrSeq" : 35743316, - "index" : "0000C2D68E9A1E1919E930D0D063A183DBA39798286DFEE32E1EF5379A8F6B79" - }, - { - "Balance" : { - "currency" : "RUB", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 65536, - "HighLimit" : { - "currency" : "RUB", - "issuer" : "r4wnCs62uGuGBuoSttaYsiFedZ3Wd6NPJJ", - "value" : "0" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "RUB", - "issuer" : "rU73c3tdNz6vpKjs5432YFxgepizkV1qyp", - "value" : "0" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "B7AC4670461DEA315826E37A90C63D2C66045F829FC6C603AD0C9FB25A2BA226", - "PreviousTxnLgrSeq" : 56277523, - "index" : "0000C3C0AE5883C4B4455845A39F97C48DC4D62101F38812213DBAE00A086060" - }, - { - "Balance" : { - "currency" : "JPY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0.54045001548441" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "JPY", - "issuer" : "r94s8px6kSw1uZ1MV98dhSRTvc6VMPoPcN", - "value" : "0" - }, - "HighNode" : "0000000000000147", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "JPY", - "issuer" : "raUX9XGwCx7sowwdk8FnvbyZ3LYrvRYsxF", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "0F31CA12B366AF3E658EBA68EEEB1AFCA7D28CFB74BF6CD22C02CFCA82BDC983", - "PreviousTxnLgrSeq" : 32752843, - "index" : "0000C864EB051CF0D4A1EBB5B92390769CD2E84FFCFDD00E8FEF6DD6CF545BCF" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "1.2339878" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rPT74sUcTBTQhkHVD54WGncoqXEAMYbmH7", - "value" : "0" - }, - "HighNode" : "000000000000008F", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rRFBj6g2mVXstHfzsQE6Y9WX1F6fhqcTK", - "value" : "100000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "265DBB6009C3CC5A89421DBE0293AFAAE2F9F9040C72CDCA406F0C1EC29314FB", - "PreviousTxnLgrSeq" : 35575141, - "index" : "0000C9ECB507AE2CBA320D2D85708AA5C064A291BED7D6988A3F0DAA028F06AC" - }, - { - "Flags" : 0, - "Indexes" : [ "454E2E047AF37AD08E2923C7550A3852EBD5653423BF5C53083BDEDBB1416F3D" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "r4TByrtckppjYXH1Ga6H67T4cVSo9NbJoa", - "RootIndex" : "0000D04DD09A3AFFD4F72DBC82676D87FA0E78100318030253F554B716DBAB61", - "index" : "0000D04DD09A3AFFD4F72DBC82676D87FA0E78100318030253F554B716DBAB61" - }, - { - "Flags" : 0, - "IndexNext" : "0000000000000042", - "IndexPrevious" : "0000000000000040", - "Indexes" : [ - "09FD4F9F11B873C9D9305FA3CF6A69DF7094EE62249302E42116FD6785DA01D3", - "0B7BFBA537D9D61801B71D148C0D009894ADD05421FF3BA3DE9B034735815E97", - "0DCD793E55A28C0D8FD0605A223A4999B4F0B330B0EBD4E680FE9D211F2A019B", - "11F82E1B83AED8D65106519CDBF03F4FD593BCED7DB250C11DCC0C4F1E62D722", - "286BB3EE7EA39BF84F09AD171F2B0A3E989E33430AAD4956060F65BB075D96FE", - "2FF3DFC02FFDEEF16504F982C45FDCBF64D33474B1BF70AE5D575F87286AB8FE", - "33B19788AF95B4974AF78334610D36EE12121705E63EA668BE0B5DEE61732157", - "498A5D8BBB03EE6D9A3895DFDEE92CF0C50F4E59CB6774C403BA8A2144D3B148", - "564C375F8963269E3025B547E57C6DA19C08F1DD57A9C84638E29CDE012576AC", - "598F891A026B8CE95A2925D608D22DB9FC421FC89CA94AA779EA423FF0A76ACA", - "5BB8D13A07B741D1DF1FCC66E97AE8D628FA77CB4DBCC31F8905CFCC1BC49BB7", - "5FFBF4BD8FAAD3F0BD450C27A14934C6BA0826DC5E0E8E48EFA6136DAC2810A4", - "62606281D0B3BEDDDC0BEE1D3D71E3786396522238822F38C5FE965FC9A31307", - "6D6E102E93C57FA1DE3B90C89958ED1A7985CADC790B0B40E44605E50D49B21A", - "79881E278AB359606FD58984CD0D18AF1364CC589A520DAE28EB60EE5369D0DC", - "7D9A657FCF24BFBE5DD09C05C44988439D26407937802A0FC6B1922307A886F9", - "82B1F7A3235BC90220751DB626090054A2C6084B9BAE0CF95B88A6D778964B34", - "8EB4CA0F9A5492F68F26B04C87B7641EB5FA060BAD3ED76C7EC2E6C76C15EBC2", - "900C7D947C9F3462F347884EA14A853EFC1417A2BE5B0513F0D422A3A085E1B4", - "9E853D5188667FA3DBF3E94DB8BCF75DD0AFCEAA84EC44E23E5ADA6CC3E17AC3", - "AD35E5B4821CDF4334B4A8221218CEF1DA96F24DFA59062C571FB8F4BE27A258", - "B4294BFC9B9622F15560D0403182D7D6ADD05A4A0CB75808395A8BE303FE97A3", - "BF44E394383AC131812E3CB525A75174FBDF43C6DEAFA6B5AF78897287B415B5", - "C08C5409998CED4B0F7B813C4448839ED53A4F290BBC0C71467B6DBA9B5F6B9F", - "C799828B25BB5C7896FB03A27F36C08CD6BBAFC8F7D7FCA68FF1C727369D647A", - "CF04F0477E7BF590302293097B5D441451BBC54ACAE0F396D846A5E2BB4ED809", - "D4172E534583CF88B32357F81402620B0BD7A85248F277CE35654D70792335F9", - "DFCCAE3AE0FB534E1DE93449F4ABB6670CC88B03B91158B7A52650D251905FF1", - "E0E55DF7339BF8EC3150A5D0C624ACDA9A2D9CF88781628189CCC0F2ED4E74AB", - "E329C7D93439B45442CA8B97B8BC2F093EEB1BA2E6C4139C510C3E4FB9F273B4", - "EAE50BF969F4A3CE8C6FCAE744DF3B797057B0B2CE6CAD38A54136AEE3614D01", - "FB594E5E88B25B7AF5863CEFC7A3FE0A55F8486C6D5A3DFD7626428F879F60D5" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rpJZ5WyotdphojwMLxCr2prhULvG3Voe3X", - "RootIndex" : "5655E14CF12014525D1BC1E68DB09518514FEDCD3EE26F4865109B56B9EE3650", - "index" : "0000DAE48F41B86821B14F1892D6AD3F6996B608338ACFC363823858CB251020" - }, - { - "Flags" : 65536, - "LedgerEntryType" : "SignerList", - "OwnerNode" : "0000000000000000", - "PreviousTxnID" : "B06C49812F7E3A84A75C78F38B920966A94ED5F85C4E6EFD34C523A6C797614A", - "PreviousTxnLgrSeq" : 47260685, - "SignerEntries" : [ - { - "SignerEntry" : { - "Account" : "raWr8dtNxddY2bqD51LZh9z77R23iyP3PZ", - "SignerWeight" : 1 - } - }, - { - "SignerEntry" : { - "Account" : "rwJkTfV8XXThGBUoC7sACmyWepw4iurYHb", - "SignerWeight" : 1 - } - }, - { - "SignerEntry" : { - "Account" : "rGtDNiHFHNTNSnoeLg5usoRnLx33ABTWhT", - "SignerWeight" : 1 - } - } - ], - "SignerListID" : 0, - "SignerQuorum" : 2, - "index" : "0000DFFDA866FD9215A794C2FC7FBF3302EF1335E3835D1B74E73780ABE32AB3" - }, - { - "Account" : "r4cPWQKVertBh6auBn6t2rXh9kht4LoabA", - "Balance" : "25032932", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "27653F0C331B2317D35D5677BBCD0DE639E65E365392EFC8D691A824085AC864", - "PreviousTxnLgrSeq" : 38365202, - "Sequence" : 61, - "index" : "0000E78D01EE4EDDE598B933D1092A1E00B922FDEDD58CFB25E3AF2CE099AF48" - }, - { - "Account" : "rKru2mJkxPrum8VAZHhdoSYEwMW7G7KFD9", - "Balance" : "38871400", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 3, - "PreviousTxnID" : "0A91F6560E32B6C13285E5F98DF81B04EBC919ABD60126F529ED3A82C93E5F68", - "PreviousTxnLgrSeq" : 35803787, - "Sequence" : 23, - "index" : "0000F5AB075F8C48286156A300F367F7E370434B0F08CA0475DDA47B1854CA62" - }, - { - "Account" : "raxoUPmpy1x7bfUX2giVfMWkPMa3vWW8f4", - "Balance" : "1121000177", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "AD4616FD44650D3E279D534BD1799AB825891449ED7E2413403666E9CF18935E", - "PreviousTxnLgrSeq" : 53532513, - "Sequence" : 1, - "index" : "0000F89B1E8F215DE7D737674050C33557974864924B2F692129560508BAAB0F" - }, - { - "Account" : "rQDZcUFcbRNXHppFUFFiTtii3hRoyjTxAV", - "Balance" : "11834990892", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "1772D4ECED1698225672ACDA3168ED886DD8F7669538BD2AC6F4B12CF9315500", - "PreviousTxnLgrSeq" : 55170656, - "Sequence" : 1, - "index" : "0000FFE18AF90D9780964C9E7A4C2F8D82C6E78C0267344B6B4232AFB9E56DA0" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 131072, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rKUK9omZqVEnraCipKNFb5q4tuNTeqEDZS", - "value" : "10" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B", - "value" : "0" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "87591A63051645F37B85D1FBA55EE69B1C96BFF16904F5C99F03FB93D42D0375", - "PreviousTxnLgrSeq" : 746872, - "index" : "000103996A3BAD918657F86E12A67D693E8FC8A814DA4B958A244B5F14D93E58" - }, - { - "Account" : "rBTpxtceMtXUKit2mQkVcWKuDHYCR7LKdD", - "Balance" : "999988000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D59694A9C6A9AAE645E51EF4FD7F9B20835A52381035B2FD99905AC6DB9850A2", - "PreviousTxnLgrSeq" : 11683667, - "Sequence" : 2, - "index" : "00010BC07B606D414CE5F140403152AC34B34EFC27E646E337D1F11593F559DE" - }, - { - "Account" : "rPDT5VZCLM2wv1qwmpbCjQfn1wXBANRhQ5", - "Balance" : "24977500", - "Flags" : 1179648, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "AD9F7BF745AC3567B30BAABFEFDA224042A184B3A094450DDFA7E13B1D6DCB3B", - "PreviousTxnLgrSeq" : 51348778, - "Sequence" : 4, - "index" : "00011327A3CA29B88F23A58B640CE23135C18E4E2A8C2333B09D7D3112459637" - }, - { - "Flags" : 0, - "Indexes" : [ - "0DB0815613B4FA7A2DE7E9551E6D2117ACD1036E1CCD14414C7905AEFC072549", - "405161AF4FBEA97F25331DEB3D2E56531245CA4F010639443AE3C8E9A5A0380C", - "4F8D5788C721E2B9F38E23DCF5396F2D6B1EF8E32BC8415495122B0F6437743F", - "C1B13E99BC56A1B4357DED440EBF0BADB1C402F582CF971401629D8FF82619B6" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rBk2i1frpX2jJC1eBm2HcWmnUdR9ZRbHwG", - "RootIndex" : "000117DF584A463510F7620C204E0FF6F64206ACD62CE887BF57EF93A4BC0DAE", - "index" : "000117DF584A463510F7620C204E0FF6F64206ACD62CE887BF57EF93A4BC0DAE" - }, - { - "Account" : "rGubvAoDEmWdiAd6ovfDVuvAViDFA6nrre", - "Balance" : "24828477", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "BD722F6D1595FDB183EA340EAF0A781A91CDD487B6EE0C65AF9F031C16957246", - "PreviousTxnLgrSeq" : 51275279, - "Sequence" : 5, - "index" : "00011C8B64D31D25AD6758E0AB72765EF24EB5535AE256A6AA696536A359010A" - }, - { - "Flags" : 0, - "Indexes" : [ - "22E578265CD7E5F46DD0695DD55428CF8F797CC1D6C4C1F5F829EC677253235B", - "2FB51B174723021E30D21A5CE4CF94CF1A99649EC33D8BE60CDEBE422E18D855", - "5177CC903382225113B6BDBB881A00EEF4EBB6BFA3947940673DE5FEDC8B751B", - "81F699D15B2BE1B9FE4486B95593B27067D8E5728AA21D69C86FF4F59BE7F608", - "A76CE2AC7714162E989F93717F58F7319A08DC2CD7F65411048B5E2DC5365DFF", - "AA1A0958D561E2A885345AFD76E676EDD29BE76FB2AE65B8739BD889EFD8092A", - "D00DD039D22BB25EC1DD8AE7BAA3BFECA41766974C094DBDF47A3718975D8749", - "D127376D2F4E392EBB296001ABFF8E03FC602924618D98EA7D6C748613DEC9CC", - "EF2F3AA2F93512F263BB79C838B6DDF53E0199C59B63CC7D12D905E7097652A3" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rDoWW6ERjamzXChsuE2YBZMDGUysDyfVpG", - "RootIndex" : "000124613EE5581AFFBA4C729A0AD1046CEEB9FDFAE4E2C8C0147212F274301E", - "index" : "000124613EE5581AFFBA4C729A0AD1046CEEB9FDFAE4E2C8C0147212F274301E" - }, - { - "Flags" : 0, - "Indexes" : [ - "49998B8AD85C57D571102032E7099F83E84AB04E9AF7A02A6470CD848B76163F", - "17712DAC19B5275AEA623477BFD517D5379EB3AE130C1279F3E57B8D1DB9AEFD", - "BBDF9868E3FCE9CB50AD16719D0009B044F838551392A6EF4029EB390F926A55", - "1D8485B2F450F6CA0130C53963D3C6F18E256A3795FF7369B9A06A2845CFC96D", - "BE1B22BC694F1BA8AF1C7E841877598789B5028F11296424A5E521D762636101", - "9B6EF09CA83A6186F4B1F677ABA02FA4CF0F99E319FDCD05F2BB7EB4668845C3", - "5A8038F189C15616633456580940927D0B42EBAEF49E97D662DD7336F0006E72" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rad7pqyVBYjom3dNuXbd2WjEga7un9GVtE", - "RootIndex" : "00012954F2A4838FA5DF0A00BCE54A9CC5C878D6B8E00C7CE9C3A346E44C18DB", - "index" : "00012954F2A4838FA5DF0A00BCE54A9CC5C878D6B8E00C7CE9C3A346E44C18DB" - }, - { - "Account" : "rGP5bTpj6pmvcGKkNqSTM4d7fEVyque8A8", - "Balance" : "20023735", - "Flags" : 65536, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D4D6B2CBF319B7291C68F5372478F2DB2CE6060400FD6675501A1657119DCF60", - "PreviousTxnLgrSeq" : 48386321, - "RegularKey" : "rP2gfYFYZRWPzLMPpzjq8ZLZcEDvC4t1n2", - "Sequence" : 3, - "index" : "000145F2834A83C6C4F1756528876A331021C36112E8A20F66AAD646CE06D77F" - }, - { - "Account" : "r7KCRNjcweTn64ty5eTZ6CCDRKuSPYurW", - "Balance" : "30099277", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "81C454E3A8CAC7E2AB6344190AC238402400BCC249AF5F0F4F20512844CB308C", - "PreviousTxnLgrSeq" : 34678008, - "Sequence" : 29, - "index" : "0001505A9C2BBA5C19B812889DE86E8DB411D5E34F8B6DBE78F73376D502E327" - }, - { - "Account" : "rwBBnexNbxPNTCh5BkSRubhVzw3asfqG6C", - "Balance" : "20006468", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0E1D9A165492CCBA23DEB69A4FD2440A2046A81670C074B381A008FDA08AC9AA", - "PreviousTxnLgrSeq" : 48236415, - "Sequence" : 2, - "index" : "000152F477C08442092FF51513637262A5814ACCEEB873DD4542046A85765E8B" - }, - { - "Flags" : 0, - "Indexes" : [ - "BDF1810D0F8272249D560AAF47168D1BCF664E53D27F3041403A42876475F04F", - "606519AFA9D8F25AA0C7FBC2BF167FD5F472F4941A222F70B818EFC8F273A1F7" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rLNeS5rVcEVgVnqyve2SSoNyxg5SgJskhN", - "RootIndex" : "000156EDDD33FD522EEDAC95BBF8C422159A2BC5E9EEDFEF0562F6943663DA05", - "index" : "000156EDDD33FD522EEDAC95BBF8C422159A2BC5E9EEDFEF0562F6943663DA05" - }, - { - "Account" : "rU1AMsDK5Fsyx7WUmhoQTdv7ZDQWtuL71S", - "Balance" : "24977500", - "Flags" : 1179648, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "08C040451C492C4EC0B24FE24E50268755ABE82449F032E481EBF7CEADA0E8A2", - "PreviousTxnLgrSeq" : 51378627, - "Sequence" : 4, - "index" : "00015F6E0B22029ED7A6E470EAC946FF56A65ADDD74E952A8C485FD8E86DC7EF" - }, - { - "Flags" : 0, - "Indexes" : [ "F8351954832393F659DADCDBA60AD9C780E6A1BCB1D862AE63BAAB75DEA9FAE4" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rheq5biynaKpGcqhRcqvmo1FNGFX98DT3q", - "RootIndex" : "0001616E695CF6732D8D3809A22498056806383D29116615AF99ADCB029D3171", - "index" : "0001616E695CF6732D8D3809A22498056806383D29116615AF99ADCB029D3171" - }, - { - "Account" : "raSieUta8fy4SfACciECTdn2HGzEu8f48Y", - "Balance" : "52744206", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "602045615A571475995DA7667E093B8ECB5BE5419CDE9F0ABE8670ED94A3FA48", - "PreviousTxnLgrSeq" : 41757973, - "Sequence" : 1, - "index" : "000162578D0B7D7C9147874B49C69F64E8B229CD599066BC44D64972F7397B59" - }, - { - "Account" : "rZWjtggT2aT9539aEb9HPZR2aqonE8UpG", - "Balance" : "20022340", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5E7B6DBD193D13F1BC93F776E708EF6D324142144F941C46A83068F7AE05C555", - "PreviousTxnLgrSeq" : 35875147, - "Sequence" : 5, - "index" : "00016BF3FE48CAEA4BC3D5A78A4DAACDCE013655F021FBA5E9F01065CFEC6A9F" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "12.725676646811" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rPT74sUcTBTQhkHVD54WGncoqXEAMYbmH7", - "value" : "0" - }, - "HighNode" : "00000000000001C0", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rExzFtNkWrHrXF9zK2eABuvrhD2ayFoopV", - "value" : "100000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "642A3E7DF7E5471BC671F5862AFF1D935061BB2032BD0DC3BFE9C093B593E992", - "PreviousTxnLgrSeq" : 40968267, - "index" : "00016EC4440590FE9DF14F280580B77116341F97D0179B04D7D0B88EE25420A3" - }, - { - "Account" : "rEXwDtcsjf6zUairDrJ64beeppn2vZ9u5k", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A482F307A6F637187BDCD98AC1489301FF7F8E59B5016F6F3042E6C436BAA44B", - "PreviousTxnLgrSeq" : 47812511, - "Sequence" : 2, - "index" : "000171430B5EFB5018FBE245D1119CA61CFB8CD27446D51C9C2CB4C20739AC57" - }, - { - "Balance" : { - "currency" : "EUR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "EUR", - "issuer" : "rfz5wUTPtwEnZMvLYR526jWWqygSoHQB72", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "EUR", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "LowNode" : "00000000000004A3", - "PreviousTxnID" : "28783500A8878DD51E100108F0A831BAC3F02089EF1279553B00D1A75A0738B2", - "PreviousTxnLgrSeq" : 29830948, - "index" : "000171D2817C44C4AAFB093F675C44CF76CC77EBB10D67340F04D5C216CC60D9" - }, - { - "Account" : "rpSRdnAoTro6CPxqWtSgDouN11eFWPUEtz", - "Balance" : "10000000970", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "2BA264781737AD0B17B36DEF048D3EAFBAAC24E57973E2A494E68A0A520D214D", - "PreviousTxnLgrSeq" : 55178856, - "Sequence" : 1, - "index" : "0001727436B58F41EA68ED8BD969677AC1763ED7BDC03A9D2AA81959E34909C5" - }, - { - "Balance" : { - "currency" : "BCH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "BCH", - "issuer" : "rpVvMLVxo7t1mZM4zJedf9Rw2zwvTFZC9Y", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BCH", - "issuer" : "rcyS4CeCZVYvTiKcxj6Sx32ibKwcDHLds", - "value" : "0" - }, - "LowNode" : "00000000000001B3", - "PreviousTxnID" : "BFF8F2D22ED74DE95FEBCDF4F37A94DE5862AC3E00F312D31F13F19D490591B2", - "PreviousTxnLgrSeq" : 35359788, - "index" : "00017430A028B2826B5FF7A13158961E288793079F237A88D1B9447AD40A0F2A" - }, - { - "Account" : "rJBHfdXheicLvFdiTchUZQFegJ3F6wtbSe", - "Balance" : "4909014532", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "B0A908380DF1317C3E0D6E9BDBC23CBF8A3A6CA33291EF7641108BA991D2A66E", - "PreviousTxnLgrSeq" : 55176290, - "Sequence" : 1, - "index" : "0001796FFCC5DE52D25C719765ABC335AC9DC1D87A409CB50EECEB3FF90DA6F9" - }, - { - "Account" : "rw6L4pcny4qxHRzcr8rq7Ywhvtj1Zo4gbk", - "Balance" : "20263325", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A43A24DCAD70BE5633CBF25A60F24A40926A244FBFD2A68B56E88AD14224774E", - "PreviousTxnLgrSeq" : 49139053, - "Sequence" : 18, - "index" : "00017A965A6B6028B863D5F06C034CCF092067DC7D83CF0DFA7E57E016BB3A8C" - }, - { - "Account" : "rrQS26TiFbxSJMeDR3GVkssvUWqNagRA6", - "Balance" : "5184960776", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A5A573EE1F1BB78E74C47E8EFF9966D2C034B64B2F96E516829C151D6B0BA271", - "PreviousTxnLgrSeq" : 55179562, - "Sequence" : 1, - "index" : "00017DBFBA3F871DED46B33A9F904E8347D9E12137AACEF3641D26D09481A3F4" - }, - { - "Balance" : { - "currency" : "EUR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "EUR", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "00000000000003C7", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "EUR", - "issuer" : "rhkYFLnfJjuhhJMSt98LEjHRb5EPPWMMLM", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "62C87C48AB958E6C0EEB5AC537CBA577DDF47005470D8076338BD15A23408AF0", - "PreviousTxnLgrSeq" : 29684491, - "index" : "0001967BAA589E2BD8DB305A679A274C091F0995A63A0500A1C4AC13D650EE37" - }, - { - "Account" : "ra11vg3cu7y1ekAP77217jAZ2AUxijC4xg", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "F1EB5B4857B3E5B02DEC9AA13CC249DD28B036878EAD605B630A2990F81EBCF1", - "PreviousTxnLgrSeq" : 43025296, - "Sequence" : 3, - "index" : "00019BD625FF83D962FE366F0BF69D7FA50BAD8692BDC4BDDCE8517653B8477B" - }, - { - "Flags" : 65536, - "LedgerEntryType" : "SignerList", - "OwnerNode" : "0000000000000000", - "PreviousTxnID" : "44A3BEBFDE97AF4A547CA81B652817FDB7951388AFCC1E151AEDECB035739A7B", - "PreviousTxnLgrSeq" : 51394555, - "SignerEntries" : [ - { - "SignerEntry" : { - "Account" : "rXKRWAQdSk68NakbeY3b4HtDqSaRFjgCR", - "SignerWeight" : 1 - } - }, - { - "SignerEntry" : { - "Account" : "rav2svUdPWzwET55egx7AuqREtkYSFScY7", - "SignerWeight" : 1 - } - }, - { - "SignerEntry" : { - "Account" : "rGtDNiHFHNTNSnoeLg5usoRnLx33ABTWhT", - "SignerWeight" : 1 - } - } - ], - "SignerListID" : 0, - "SignerQuorum" : 2, - "index" : "00019CF2142F600C978EFB986613BE3CCB85CE599405FF757BC34AEE1BF9C982" - }, - { - "Flags" : 0, - "Indexes" : [ "A0DD66478D7E2C9C77B4D0C046A036C828B9A0257702FD7B403B9D0E815CBAB7" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rNYWvRRd7PDsa69C3bqNq7MH8jBK8jUR2", - "RootIndex" : "0001A3C2AF2B8210E978BE486AA397DB35DB9D0E6AFAEC8035E536F3DF00401E", - "index" : "0001A3C2AF2B8210E978BE486AA397DB35DB9D0E6AFAEC8035E536F3DF00401E" - }, - { - "Account" : "rPySuBy3dCnDpp4eeD3YvirnLtF19DafYm", - "Balance" : "21079607", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D66F918C0DB4009A75FD3BC3D49087DDCEAB3FD676D9003AEB7E2A1A84264D1B", - "PreviousTxnLgrSeq" : 35083095, - "Sequence" : 5, - "index" : "0001B3E919D8905EC2080FB6F593451028233D50E3A82CD16351BD394B4055F4" - }, - { - "Account" : "rabbit1eyDGsiWzRH4wL4vnk7giSxWyMeb", - "Balance" : "100041360", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 4, - "PreviousTxnID" : "DD2BD18EE4400459E3BC6560E0D3786831EFEA3860B07FFB8AE445532F589927", - "PreviousTxnLgrSeq" : 41202517, - "Sequence" : 802375, - "index" : "0001B7264DF8F7730C3E1530A24A17FA99F062DC0A6E66615F3EA4EC3CED46D9" - }, - { - "Account" : "rf7nSY8GXRiiTukpnunSQi4otiH5ZoiEvy", - "Balance" : "33000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "CB7F74D3CB40602C52302AE42363885E5EFC7536827B14B3BEC3055D4573F356", - "PreviousTxnLgrSeq" : 40507156, - "Sequence" : 1, - "index" : "0001B75BF0B7EDEDD51057F7109144C8FACE381BA0C968596E85E7CA53C1AC9B" - }, - { - "Flags" : 0, - "IndexNext" : "000000000000010F", - "IndexPrevious" : "000000000000010D", - "Indexes" : [ - "47EF55938C4C0E228672D6199A2B4BE6E6E2BB863341128BF74193CE5DEB5912", - "ADDC5C415149EDE4D6F47C2AB0B9033E60156737136EFD850A409060824E4E02", - "54264648AEC6EB3D25695872798E669E745B05AC765E45E9B5F88053EE41231B", - "9370A905CA293F0774F454D64315CE52A63B9BDB2A50915EDF643C90CA6444F7", - "1323A324D39A5DBADBE2F7959C9F8505ED5F43D0C3C25E4892AB0B3632D76ED5", - "A33C29C307BDAC45F4F1277E60E82B5C26125401C20AB5CDB352DDDE38AAA863", - "6D712C8B5BDBE99D1C93C25FFF9707D6726C317059662BED12584A706D8AEB41", - "7CE75E387DF97ADE98718131EE2B19B034B6233D22CB67817440923BA0DC9071", - "213CB583C0A91E794D5587320801B5F763D9FDDF4DC6AC8A0DC1D0CA6834A4E7", - "5DCCA52BA4873F8CDDE86A08C415E8C29B4E0AB43ABE1F2B80AF667C1A831CE2", - "676C3AB3D4953B3D995698B47F8C8BAC715D7236C1513C03D36A90F0AF2CAFBA", - "FA7B6DBDE818BAA7BAA3FB43266C7DDEF0D6B1035A89E240185CB382FBB9CF1E", - "162801B3679E3623F5A1E1281D875806FDBF4194C2BE2F3A89E91700FF9A0E9B", - "C5E6524750B19B938F6A046E95AC6F57DF9C59C0D29B460DA6787840BAF8105D", - "964B15F052285525F66594C3080EB83FEE4C448F98990B77A12654EA2638A323", - "2F81C7C101E15DF959E43530B17C6DAEC1BD012BC7CFCC4AFF9AA905724F7D0C", - "C5A1E3C85B510E0A3FFFE6610355D02A063E160A7A99BA6A7CDAEFD34C45BE9F", - "F6C003A46C2905EB16A822436D0A0A6A726F7FFFD80ECFF1EEE0228FC3A2BCC8", - "AA4C93539FAC96D37E121130F1D9225C3758AB814D2A5B4042B29E1F559EA4BB", - "7EC3784C4CA5BDCB5C798E39B9F655860D5DF0013B39580C94B5D0BEF0A75C7D", - "F8FED9BE60375A25CEEADE3CAF51522CB5174367C16E8099BB20DD02CA2244AD", - "8711B16A37882C221E750F429053FBA94D74E3C2615870FFA0ACDA12694E6149", - "1720BEB74777C45007F46332933B909E629677CE4D00EB5AC71B36A7D04E8962", - "092E2D46FC1067FAA3A893715EC531E1E75D06BE14DFB66DFB1698EF6D5FC02F", - "DEA88D84936A98A7BA6A16331BCBA2D5A3EAF996AF9DB25141900A071B76B177" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rckzVpTnKpP4TJ1puQe827bV3X4oYtdTP", - "RootIndex" : "DC5101C0CC6A7FC8E21465501E0EAEEF475BE2D1FF2E7BF6691360DACA4F9C48", - "index" : "0001B882C3BDDF2524DA892639A16FAF4985CF19DDEC17EAAC38F6A98F1D3275" - }, - { - "Account" : "rEWmZFmKAPWjUoD9pPk9Y7Ut8eEpSZmnq1", - "Balance" : "126488970", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "1BADA79B7090A31C6EC6A70993FFEF9242B249B9CB42C9251F5FEA5906B8612A", - "PreviousTxnLgrSeq" : 35569892, - "Sequence" : 1, - "index" : "0001C56562C6B32EF503B9B44F65BFA0E4E990A42C8F19CBC8868071D74B4492" - }, - { - "Account" : "r4rL7NEbRwzNdKZApRcDP4rUV8JKrqN9tW", - "Balance" : "20781895", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "7BB899214EB0FFDD5A677D4F391EBA46D6287CBB33052AF0C1F1BBCAF92D541D", - "PreviousTxnLgrSeq" : 35347840, - "Sequence" : 3, - "index" : "0001C817A1A9EA16F3A307CECD2D274B0C402C4C96997E32C6AA047E4D3A9CCB" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rNcvK17hLGoHQuPbZf1R8mAh3M31GMtgnR", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "LowNode" : "000000000000123F", - "PreviousTxnID" : "72D56D94CC6CC2694E1E5EB9DA536F43E8A3FB3C1C0ED081527001D18D8D7A3C", - "PreviousTxnLgrSeq" : 35435065, - "index" : "0001D78EB50C60CB9708E8202C9897688363B78F8AB7AC63F66EEDA462EF453A" - }, - { - "Account" : "rfHzTZqckursDsc3BaVv84f9FfK81UPMVc", - "Balance" : "78999988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "61F7D324154F46A8846A1AE920858AC5893B81CC19C238EA038EC4A79E404B41", - "PreviousTxnLgrSeq" : 54682342, - "Sequence" : 2, - "index" : "0001DAC577DD41000B500FFFCA784A88C04B00788AA210EF5AB6AB54E59DDD49" - }, - { - "Account" : "rwao7UjmZbBed84yhGP39W2PLH66Q7aXjb", - "Balance" : "2481472609", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5060666111A067C2D877D5F4982F0050903AEE439E2FB082DBBCBD8ABCA0CDEF", - "PreviousTxnLgrSeq" : 53449904, - "Sequence" : 1, - "index" : "0001DD4EC36B9A34D8899ED31E4E388587154016B49FFD82128C68AE919B2BE7" - }, - { - "Balance" : { - "currency" : "DSH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "DSH", - "issuer" : "rwrudJs8u5KatPEuGuyDnQ8R5nEQUPB7v2", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "DSH", - "issuer" : "rcXY84C4g14iFp6taFXjjQGVeHqSCh9RX", - "value" : "0" - }, - "LowNode" : "000000000000016A", - "PreviousTxnID" : "3FF02890077B48632D1A19744DE05E182E68C9A1A4B0B31F6E41159F512BD41B", - "PreviousTxnLgrSeq" : 35699762, - "index" : "0001DF3CB8196255E69A14F92EBAB9877B1F350DF7E62D64AB6587EC3ED9CA4D" - }, - { - "Flags" : 0, - "Indexes" : [ - "278D58129796548AF58E23A40247F050CB3E46BAF058A44D96CBCF1F41A65357", - "448843AF12951D5119AF6A31F67C19AAF30F9CA4A87E1913F1CE77E8A489A608", - "4533FC4C079D626A72899A2DDF532829F8838D376C2840B642CF1C53403E8427", - "7F38E0C8E0214AEF922B617C19156009EF3292A40C6FF52C9CB03625AC09058E", - "8BD45AFCAFCE035932E6A176836A3E088F90B0854CCA37CAE8760DCB68A40E2A", - "A1505359F82BE39B0A23190A6F55AFD4ADCA4990337605C74BC2622399799186", - "B1A644AFAEACE38D9A31E212059BBDAE52184CD63938AA03A2C324201EB0B1BD", - "B49AC5079F5E2455F141E62F72AB80F7FF9D2E6C98EF894936C01C4E491E49E3", - "B8A780F02B1B50D9A5A43A08B000F23340F8D48966642FB1BAA2E17E28B83E58" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rEAKkNt5z2HTkqS9baCGaTStHXfptPtCuF", - "RootIndex" : "0001E959978564B75810992944B463A63B305AA6690410FA4ED790CA7AFCE45D", - "index" : "0001E959978564B75810992944B463A63B305AA6690410FA4ED790CA7AFCE45D" - }, - { - "Balance" : { - "currency" : "GCB", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "100000" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "GCB", - "issuer" : "rNdwi8ain5ibXNB9A7H3zzKtSxgVzAqqAe", - "value" : "0" - }, - "HighNode" : "00000000000001B0", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "GCB", - "issuer" : "rNNeAHyaSgDxG8ynpnxuzaVtqp49sctxb9", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "6C6ADA3ADF20D37577BEA94CBA1871B1A030B6D63E3F594D5A9959275E97A999", - "PreviousTxnLgrSeq" : 37721815, - "index" : "0001E9604C5FC991A30408A78A299A58AD7DBF5A9069445A3A75D487D04DD607" - }, - { - "Account" : "rKbUdv2SnNbgK7t69drPNKmAAeQfs5fNVZ", - "Balance" : "464278000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "B0DFF30B2BE30663A9BE7A8CA42FD85CF423B041CDA489FA7A18D714260D5C08", - "PreviousTxnLgrSeq" : 35570527, - "Sequence" : 1, - "index" : "0001FD3112599AF2C9991E5E7E56A24268F9DC3438D525C8DA8135E9BBFB7D6A" - }, - { - "Account" : "rMJuG542Akwt2idVxQemfPWSKtTeSyR4QL", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5C79FD3CA953C881C3D4BE48F2EFAC671177B8ACD37A72A38958A293B706B4C6", - "PreviousTxnLgrSeq" : 35696409, - "Sequence" : 3, - "index" : "000201714F588C6F1D440EA526ED868FC48FE4F3508840D58A36D79251D7D8D9" - }, - { - "Flags" : 0, - "Indexes" : [ "9D41377F1EB6E502A7107C2A35CE571506BA8DDC5E57F77AED0C4FD7C5BB6D2B" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rGUhYCjTac2tuuUPwAJ38iajg44s4H9b3E", - "RootIndex" : "0002043F91DC997AD832ADB3A90B2B2D762E575AFEBDE372FEE323617EB89255", - "index" : "0002043F91DC997AD832ADB3A90B2B2D762E575AFEBDE372FEE323617EB89255" - }, - { - "Flags" : 0, - "Indexes" : [ - "63309BC276156760C5BBB0E5F1238546824A861CE478C536DD8B36D6009502C6", - "34E8966296BF24299BC9D7DC14FEFE60DB5C23C3AC8325B883D6AAE5B4FFDA92", - "2333718F8324FAE85841B54F86B7486841335A69C4956207905CDF9A65C37D38" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "r49HKrCPQUvs4en9DEUBewA3DASoVNUE4B", - "RootIndex" : "000204CA2372F5DBB072D5CB38156EF7E67D3A584AA5B02657976DEC6D0C5B88", - "index" : "000204CA2372F5DBB072D5CB38156EF7E67D3A584AA5B02657976DEC6D0C5B88" - }, - { - "Balance" : { - "currency" : "STR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "STR", - "issuer" : "rUwyk5PmESWq1DCMTCTscsRb4kYVYrZw4f", - "value" : "10000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "STR", - "issuer" : "rB3gZey7VWHYRqJHLoHDEJXJ2pEPNieKiS", - "value" : "0" - }, - "LowNode" : "00000000000002F4", - "PreviousTxnID" : "9CE00B05DE793F99081996E2A322ACE374EBD6C7E6F1343AED0BADBD20DAED69", - "PreviousTxnLgrSeq" : 29743678, - "index" : "0002068C83B72D014453DC1415A6D30A430CA904FA78BAB33A36900F8AF645C9" - }, - { - "Account" : "rBuDDpdVBt57JbyfXbs8gjWvp4ScKssHzx", - "BookDirectory" : "37AAC93D336021AE94310D0430FFA090F7137C97D473488C4A0D635441A85A45", - "BookNode" : "0000000000000000", - "Flags" : 0, - "LedgerEntryType" : "Offer", - "OwnerNode" : "000000000000025E", - "PreviousTxnID" : "17DE3914111D63CBA7BB51B551BD4C14F9BED048B8EA142222B2C4B1CEBDA01A", - "PreviousTxnLgrSeq" : 52563046, - "Sequence" : 121220, - "TakerGets" : "33170680", - "TakerPays" : { - "currency" : "BTC", - "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B", - "value" : "0.00125" - }, - "index" : "0002133B26A1D5533CD791251844CE17650F2F478EE37F8564D024BA2E0A224C" - }, - { - "Account" : "rL45jjo6Ym2isLu5kPQrL8BctBjX2Ur4tq", - "Balance" : "30000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "243950CFC1A4FEDCA0A62041EE6FFD4EB116E20FC20DBE816624C24609085A75", - "PreviousTxnLgrSeq" : 38977070, - "Sequence" : 26, - "index" : "000215DE95AD3CE49624ABF5019E13A3D5691B5D21E3A13EDD44A8DFED3C9A85" - }, - { - "Account" : "rE8yruJtXACpDWyVyGSP1MLrGBzcnnfUhw", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "17E2EF85A7CAD6EE02610CDB51ADB284AB64B8C88D3B0759ABADE870597EF081", - "PreviousTxnLgrSeq" : 47828640, - "Sequence" : 2, - "index" : "000217A389C05CE05D96FA5A368621F21E0431C21748800240487F1C51321CB7" - }, - { - "Account" : "rnoHcWx5sskoiiNMt6CSSeTfjHw7JL3RfJ", - "Balance" : "122834669", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "2A4B34391F53C0DB49C0C2ABF39611C9EE797B2A71C128453A0A85AE629FB481", - "PreviousTxnLgrSeq" : 35665140, - "Sequence" : 1, - "index" : "000218E0DB87BA2E65CB5F59CCFBAA15DAC6A2D07EDECC72DB0457C50B0F3156" - }, - { - "Account" : "rGuvvY7BPCRYmw83EmzYFQZ76ybdZ28DKX", - "Balance" : "2242284331", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "F1603850E52D962CDA5A33646A13FDC44990436BC1967C1B45B5556E0CB94EE0", - "PreviousTxnLgrSeq" : 53527645, - "Sequence" : 7, - "index" : "00021CD2D04E777624DC7D15AD7EDC7400375029FC11B1EEAAB187FDA0A86E07" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1179648, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rPFd14EgMkmEnvtk2nzsrTfkoDmYzwpowJ", - "value" : "2000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rBfVgTnsdh8ckC19RM8aVGNuMZnpwrMP6n", - "value" : "0" - }, - "LowNode" : "00000000000002F9", - "PreviousTxnID" : "4352226FA79635CBA7D59E9705B1A751834EC5EC4025281DE7A6DFDC3B8CCB73", - "PreviousTxnLgrSeq" : 24725683, - "index" : "00021D4E6E9CE88B3DFCBC8917CDF28C7BC2792AD68FA6A269DB454CA8C0160A" - }, - { - "Account" : "rBFLqCBHFZCKrZVRZK1oyH5SibamM8uM49", - "Balance" : "87782000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EE6E0422AC888EE1C298D17EF069D6D0F937181D861BFA67D8CECB18E6A05CF6", - "PreviousTxnLgrSeq" : 35105975, - "Sequence" : 3, - "index" : "00021FDEE2F788C23C3E11EBCE3657FCF560A61C365A6EFA45726C54A570579D" - }, - { - "Flags" : 0, - "Indexes" : [ "6AB1BA256C26B11B0C2BC28B68CFFF9EBA1A0D7505F43F1D9D4D64A38F38A8F9" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rUAuRre3GfGDTxdbzo7s7GArR2zhPf61Rd", - "RootIndex" : "0002228CECB01B2B948DCF2EEE43DBF33637F27F0C6BFDAF238EF2F9E022F4E3", - "index" : "0002228CECB01B2B948DCF2EEE43DBF33637F27F0C6BFDAF238EF2F9E022F4E3" - }, - { - "Account" : "rGFEpTL3rXgsHkopDNbEB3NMfNDspZ23e3", - "Balance" : "1756380116", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "755AD6C3F0F8075B48409692AA2A336CF5B07DFE9B5B7517DBBD5D6AE79389FD", - "PreviousTxnLgrSeq" : 53543734, - "Sequence" : 1, - "index" : "00022463A30DA0BB03215AC3777746D7DF2794D13A056C08C7947C1D0298A8E2" - }, - { - "ExchangeRate" : "54038D7EA4C68000", - "Flags" : 0, - "Indexes" : [ "291430753F816826020D5F119325B30E68C9B69A204E97758A84A9E2BDC0AA4C" ], - "LedgerEntryType" : "DirectoryNode", - "RootIndex" : "000227CD42FA0FF90ED3DF1940FE988950EC26250C6CA27554038D7EA4C68000", - "TakerGetsCurrency" : "000000000000000000000000594B540000000000", - "TakerGetsIssuer" : "9DE47FDE20653B82F1A116B3A82658362CC482FB", - "TakerPaysCurrency" : "0000000000000000000000004D4C4B0000000000", - "TakerPaysIssuer" : "9DE47FDE20653B82F1A116B3A82658362CC482FB", - "index" : "000227CD42FA0FF90ED3DF1940FE988950EC26250C6CA27554038D7EA4C68000" - }, - { - "Account" : "rpd9hZKqeXJr7rNjvehBunEdQwLZRY61D5", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D4A0C37289C478B5B9BA2AC8F93701F5ED52FDEA6429750E9019D622F1B8C9E0", - "PreviousTxnLgrSeq" : 35222051, - "Sequence" : 1, - "index" : "000234B4BD11D93E4810C37F13C6A009498192E957D35FDE55E809E6FA40361F" - }, - { - "Balance" : { - "currency" : "ETH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.00000000069586" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "ETH", - "issuer" : "rs7WjWW76Dtq9bkHq98ZfvQzaANiVSW9s2", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ETH", - "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", - "value" : "0" - }, - "LowNode" : "0000000000000B36", - "PreviousTxnID" : "F2ED70C5BEB1B964C344614DEBB2854033B695DEDC444793D3870746FFC4164D", - "PreviousTxnLgrSeq" : 35823767, - "index" : "00023646D06EF5D6BA4FDF1F5D8F23FE28D486B54F227C97702AA7A83CBCD8F3" - }, - { - "Account" : "rPLXMQ6KhniRFGLxXLg4YbeHmRXSP9ncBv", - "Balance" : "2600007809796", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "AEA85201CE0D0D9062DB691AA3E05530C6B64FEC0F42D0D645622ADB9BDA558D", - "PreviousTxnLgrSeq" : 55163667, - "Sequence" : 15, - "index" : "000242578431923F7E961D6D69146C0D80B936E60E094450CB7497759BC1F0B6" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rMSY8DZpWH9sCvqq1Mg5wKGjqqicXtTNyc", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", - "value" : "0" - }, - "LowNode" : "00000000000007CF", - "PreviousTxnID" : "E2AB5AEE53AC746F1FDA16AE068E0C39752114E6676DF16E7C2B4A97AE2C9091", - "PreviousTxnLgrSeq" : 34906009, - "index" : "00024ECF15C95740AF5FA04C3DD341E8F05B7A069224407F9AF9C59FAEF723E3" - }, - { - "Balance" : { - "currency" : "JPY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "JPY", - "issuer" : "rB3gZey7VWHYRqJHLoHDEJXJ2pEPNieKiS", - "value" : "0" - }, - "HighNode" : "0000000000000367", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "JPY", - "issuer" : "rf8RiHHJvDosckVtsmZ3SGxYcuduUJ7gus", - "value" : "10000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "4236B9703C0FA5C1DE1FF8A0316E915477F4ED1300A39C96F5C1D383C5CDCED3", - "PreviousTxnLgrSeq" : 30038128, - "index" : "00024F52A82AAD1D2B49549BC2C737BE101F662E4F55F01868F56CE6076C0228" - }, - { - "Account" : "rpSHB1VsKFKBx4VjmHH8V4SVdbPYdowAkE", - "Balance" : "1136037689", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "08C5DADC959F085A22ABBE4CCB5CD8BC361C4854578F1CD9446502A433E563FA", - "PreviousTxnLgrSeq" : 55609692, - "Sequence" : 55609692, - "index" : "00025455DA641B87A2EBE0C1F02F4E17A07CF1D97B708A20DEE7C4EEC25EBBE3" - }, - { - "Account" : "rpaD3HhpVPSUj4k9xerLN3nj7CkZ6AwYv3", - "Balance" : "1685711002969", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "416A1EAFA3EFEF7F27FF4E5E374CA4D4786ACB507522137E5E560289D740F6A6", - "PreviousTxnLgrSeq" : 55164077, - "Sequence" : 1, - "index" : "00025908A8FD8967A049FACB5181AE8F14C1840215B6BDE5063342136597BFA0" - }, - { - "Account" : "rUw4QkuMot2GSTfGmu8uAt989f4KsAjcmK", - "Balance" : "1384845450", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "FD68277F820799FC5A8E58A5EECD4D5AD6BCB42688286E3D4AE6D136EE9C2272", - "PreviousTxnLgrSeq" : 53528319, - "Sequence" : 1, - "index" : "00025CFEF306B3FA99C5000F530F3D967F07B3414C313725F7D9E2DC6FB30412" - }, - { - "Account" : "rB4ZqDWBW1SjzbBenKSnsqC7YuPsMCJ1mB", - "Balance" : "113107120977", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 32, - "PreviousTxnID" : "F620D678A5578D144292CE94F3B841EB24DBAFFC68D19735272E102E775CC71F", - "PreviousTxnLgrSeq" : 56852695, - "Sequence" : 1623, - "index" : "00026278BB9B84D65F8872C506EBDD4BE182FD31B9930E5D6C327B554006C7CA" - }, - { - "Account" : "rB7FbVaugiT9x2tNdUTpMPLB6uEbrzzHDg", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "3473F370144C61BDAFC6340A7AEB41D23274D12542B2CFC82B77E3ABD0E549D9", - "PreviousTxnLgrSeq" : 56066464, - "Sequence" : 24, - "index" : "000263EEFD18A648F716C7201F7E8D9FD53E8157EED200F6B8AADADCA7644B48" - }, - { - "Account" : "rJnpxaXdu8WbeYwj1z4s6sYz7uGq5GC1NF", - "Balance" : "3281565997", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "449E8D4ED990941940FAB231FC916487A81E61491D55A1EC7AFF83D29398CF4D", - "PreviousTxnLgrSeq" : 55175689, - "Sequence" : 1, - "index" : "000264109B71F26AC0C274FD4D2BBDFCC6AA5E4817066C9264FEB606F9746EF8" - }, - { - "Account" : "rJkCKqwncDrbDNxgf3QFB6UWUCe5tD2vzs", - "Balance" : "47451988", - "Flags" : 65536, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "09B698D2A9369B708325CAC986B4F13BAFC6AEBCED89455A100FCB98E66D87CC", - "PreviousTxnLgrSeq" : 44981172, - "RegularKey" : "rncMr3zTqsfGuwiC4goKM6Br7YGmuUy358", - "Sequence" : 2, - "index" : "000267A0E4D9EB87145C89BC8352EA105BBFAD618F6AEF637A947E53129E6E83" - }, - { - "Balance" : { - "currency" : "JPY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "JPY", - "issuer" : "r4iPSVbRZosUDeuQg7obweH8DgCYvg947o", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "JPY", - "issuer" : "rEYD5k6kZPARQbKfB9GpiNPDY93kRQgPKj", - "value" : "0" - }, - "LowNode" : "0000000000000008", - "PreviousTxnID" : "7516F9BC3E8055CCE7F727A29F1FD48E9F9925BB91B62129D1D00B8502DDB4DB", - "PreviousTxnLgrSeq" : 11378470, - "index" : "00026AE25E921ACDE0861F983DAAD7852553F53454C69A6113DC8F6A994F19F6" - }, - { - "Account" : "raHV45pVDiRUdeGBJNhFSH5heTuebjtzoY", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EF368FA8D09BC9D278CA7A55F5E2BCCA674C00F7DCDA35CB0565618BB9ED3E6E", - "PreviousTxnLgrSeq" : 48264559, - "Sequence" : 2, - "index" : "00026D54B2F877AD05FB5639DBE2041007B4D6D8613B5301AAB291CED182494A" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.0097" - }, - "Flags" : 3276800, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rDvmLrFhAHRxaVmmeppZKzjfzM9RZ7W7m7", - "value" : "1000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rhKgFxe7Mp38yeJzvwoNLm46RxMdXotTn6", - "value" : "0" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "3E8D2DADF8C4FBA09D117F772F144D982F46D8FC6F050FDDA93DD0066F5ADB09", - "PreviousTxnLgrSeq" : 35240943, - "index" : "00026E9C64E0BEF3F562EFE4D13B62BA3284FD7FB09395A936591C0F23D607DA" - }, - { - "Account" : "rs7Ne13j2FCJtMS5UZmsYfHV9KBSTyan7w", - "Balance" : "20023065", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "3F9D327F292D8244735721EE8F9CCB5565306270DF8BF4F642BAFA0C06F12742", - "PreviousTxnLgrSeq" : 36968533, - "Sequence" : 11, - "index" : "0002701E7145F0FCADF2EBC24DFE242C5BB868A5CDCC50A7EDB21F7433E1C3C5" - }, - { - "Account" : "rHETEQaUhP6KBLDbQ7jdvytEfLDN5XzviD", - "Balance" : "44992103", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 4, - "PreviousTxnID" : "EE896EC16D9017697EDADC0E676F63D4E5855C682BE94A5C2E5A535DB96A2180", - "PreviousTxnLgrSeq" : 37313330, - "Sequence" : 33, - "index" : "00027632FBDE4927164EF1AAE745EDFFDD3B820809464BADEFC18E08FEF42055" - }, - { - "Account" : "rKk3VeQP8oUq1Y6J8WxARUFATRoFZn6gz1", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "35F4770B3559A62731ED680C0D8B53C8A58F8994D123AEF43DBE3D66075F22F6", - "PreviousTxnLgrSeq" : 28960817, - "Sequence" : 2, - "index" : "00027ED9E4526B75B2CE0CF80E41EE0011C39589401E717AA700CC692E21D543" - }, - { - "Account" : "rGyMFQRn5HtdC2eFoK4n98uc4QeMddiZoF", - "Balance" : "238529992773", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "FA7FE32E7D86A19D88F79F926AA5A44AEFFCC55C26B07D7BA631D9D9B7B56BE3", - "PreviousTxnLgrSeq" : 55174593, - "Sequence" : 2, - "index" : "000280047BACA5D00427677365D9559F3FAF9027E4FFE69452DD0DD577B44942" - }, - { - "Account" : "rnmYfkS85KmV9p4Le7cJC6JjJcysL8Y5bw", - "Balance" : "25020000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0F5503095AC7D78B6AD2E8B7C4A0A946C4DA0273C433E8AE8F3FD4D55F68DAC1", - "PreviousTxnLgrSeq" : 56406521, - "Sequence" : 7, - "index" : "000285A460C476F5AD35C6D837EAD4F2CC09D7E8A43F07D77AD8B72204372903" - }, - { - "Account" : "rfRnmsbfku4S2nCrPXKFtKsNVE2feYW9Kv", - "Balance" : "739809000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "8F9C0CBD3E6DCC535B67760BE2C4AB4E96CA855DA763A352E2A5882D5AFB7FC4", - "PreviousTxnLgrSeq" : 35491168, - "Sequence" : 1, - "index" : "0002886C2182362FA2ADBF0794354385F120D4F90316D408DDA1BE254C08F340" - }, - { - "ExchangeRate" : "55038D7EA4C68000", - "Flags" : 0, - "Indexes" : [ "14472F3D7E46A79BC424FE22782DA8152B3346F240D76B03F17C06C21C56005F" ], - "LedgerEntryType" : "DirectoryNode", - "RootIndex" : "00028C6812AF7B7043E8D146563C740614D1293A952026F555038D7EA4C68000", - "TakerGetsCurrency" : "0000000000000000000000005553440000000000", - "TakerGetsIssuer" : "A2F38D1722E33796F5880141A8F6318BC91F27C2", - "TakerPaysCurrency" : "0000000000000000000000005553440000000000", - "TakerPaysIssuer" : "0B233D3B2EBDC4F12A251C29AF26323EA0864CE9", - "index" : "00028C6812AF7B7043E8D146563C740614D1293A952026F555038D7EA4C68000" - }, - { - "Flags" : 0, - "Indexes" : [ - "1A319AE7B7FBA78BE7D021AC01C781A842BAAD4BF558A7F709C86A05F1607F8A", - "5FD00AB6D78C5F742B00E02A8B3A5D47A9642D0FF3143438BA4B9F7FB93898A7", - "915A2E1823AF08F32A7803BF7B7AF43D2C3EB77CA05F56951304C6D7E974A7FE" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rBcwbD6PTsoveJLT2RLwiKwNBvubWEqB23", - "RootIndex" : "00028D42EF0C344205C82444A6F67E9875E6CFAB5B9210B6D70ED6AEB16E6CE8", - "index" : "00028D42EF0C344205C82444A6F67E9875E6CFAB5B9210B6D70ED6AEB16E6CE8" - }, - { - "Account" : "rMCuL9Sce7QiJHosT3kkGaF6ySntfVp2Gj", - "Balance" : "19999990", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "02AF004961D61E2CD1F0BF84C5F31D47EC13086FFE5D51EE8C59842DC1C325A3", - "PreviousTxnLgrSeq" : 35880386, - "Sequence" : 5, - "index" : "00028F39C354A66DD4994A4CD7AB8A91E32452E5039898CCC134FFA61DD0025E" - }, - { - "Flags" : 0, - "Indexes" : [ - "0BA71FA44920D017FC27956BCADE84B103CA8BA11B835BB6ED911A3FABA549A4", - "80461BDED64B13994E9318F3143BF436C256E81A9B574FE0D511602CA3466E33" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rMqgMdQm1hDh7ZUAWz4AzASi1vg2GMRY4G", - "RootIndex" : "0002999EEC715951639874C60F2D4F6B28E29CF6432008EF86DEB988CA8AADF6", - "index" : "0002999EEC715951639874C60F2D4F6B28E29CF6432008EF86DEB988CA8AADF6" - }, - { - "Account" : "rPDu1wk2vmLHdCrztVrn4yNMTNeme75Mmk", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "CBDB3EE7253A4E47CAE1BA3FDBA062C364ED4E7FF9686F558E2598E9B19589F6", - "PreviousTxnLgrSeq" : 47865012, - "Sequence" : 2, - "index" : "00029D9DDBE35894846ADEF13949EE95AD3FBD4B749BB800B6508A82160706D2" - }, - { - "Account" : "rNFYBtTaywSA2PmjpZSXJ6by1Bh5MjAnj6", - "Balance" : "1258667366", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D5944A2C279AAF2749D4F7658ACEBAD24252393B1BD108D51A4572943D88B17E", - "PreviousTxnLgrSeq" : 53527042, - "Sequence" : 1, - "index" : "0002A3F34A62A3FCED5E3DE2AF5012A2B33AB8EC411028E4310947A4BADC6F9E" - }, - { - "Account" : "rU51UCvkbJDsjXsE9PmB59TCm5ZjSW6ZPy", - "Balance" : "10000000811", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "1C916B192126CB9D8524DBF7DD77325EFACE96BF282BF0877F0C22D4BB9BF4D9", - "PreviousTxnLgrSeq" : 55180029, - "Sequence" : 1, - "index" : "0002A590029B53BE7857EFF9985F770EC792CE483720EB5E963C4D6A607D43E0" - }, - { - "Account" : "rHW2anzZMwGF6jB3Qe2KJHVvdNp83u8zUB", - "Balance" : "19988000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D83E336EBA2F2768A8FCC7A7C9F93CD3145861C5FC89828122006DAFB0DDED38", - "PreviousTxnLgrSeq" : 18595284, - "Sequence" : 2, - "index" : "0002A98F9BA1CB7F71BBD170DE366EB64B818B05CE714C611DCB1B501C5834B9" - }, - { - "Account" : "raGNVgTN4vmi8FyNh75ydzJAbeuXjytDA2", - "Balance" : "476318366", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "FE70E402404608A3E77B23AC61A8652C448EF08AE2DD110C0FCEA8E7BAB8D1A6", - "PreviousTxnLgrSeq" : 35179921, - "Sequence" : 1, - "index" : "0002AD9E073BE86B8D78BE3D6B417F41CB37C5782D05E6859BB57E709543E283" - }, - { - "Account" : "r9scREW2BqzWc5EHDPURFXmc2nbE3zk27o", - "Balance" : "25981483", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "031F8EB959C780E160DE06921338275E85B3F6CF963DB9BDF6C0C30279CAECF4", - "PreviousTxnLgrSeq" : 45548830, - "Sequence" : 9, - "index" : "0002AE9D14EAF79B4C4928D622CEAF7C192B79682C091E373466E7B4948C3F82" - }, - { - "Account" : "rHgmYFSPe4PmHAAxLmXT8gHTHdAkyC8qux", - "Balance" : "37353357", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "4F91EB7706212FF41734E3DBB3AAD1107DFFDB1C168EF2C588D5762FCB28B6E4", - "PreviousTxnLgrSeq" : 36055617, - "Sequence" : 5, - "index" : "0002B0BB1E2050F8E9A46A9E8EA28D9602B1439219ABA1932ED251CDA00DCB4A" - }, - { - "Account" : "rEMZkiyzyK4ujMEqkcA6RQz8kjjt2Lo85s", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "87F590598CCC90C920C76AB3799867BE73551358852B955A54383EB899BF81E6", - "PreviousTxnLgrSeq" : 56862164, - "Sequence" : 56822595, - "index" : "0002B53E6EFB0DA9EAA4AED495AD95238848042571240D89255AECBD5FBA4451" - }, - { - "Account" : "rJ9ocS5wWL93D4nPDPypAmvpvDJaDmNKzy", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EB19B4DFBAE06FBB920BEADCCDCAE0DE655249A14698D9985F97D5AC2AD52C89", - "PreviousTxnLgrSeq" : 48079546, - "Sequence" : 3, - "index" : "0002BDBDBD34EFAF974F5439F222439CE9F23F80446E9B252C4424543CB42F67" - }, - { - "Account" : "rseH6yDsetznMcuUg4uVhTjQPJc9BE4bpQ", - "Balance" : "20042739", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "59F89927C1B8F3BB5880902EAC796CBE2FFF44C3CDC8E3CDD66A5E9F962966A3", - "PreviousTxnLgrSeq" : 56775842, - "Sequence" : 55769928, - "index" : "0002C6425429A29A0BA566F93145BFBEABFCDE6A7E2AA81E2D0823D8F6E12303" - }, - { - "Account" : "rwkEbDdopDS13yADjPNmAnsB4yJvdZyB6s", - "Balance" : "340570301", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "8401A5E0142CBE0F3EE3DFFD92C86065FF00EAF189AC7F0466384B64AA45BA2A", - "PreviousTxnLgrSeq" : 35533603, - "Sequence" : 7, - "index" : "0002CA03B25A44145348CDEE8FA9677C40AB515E9ADB9310562F742B0471453A" - }, - { - "Flags" : 0, - "Indexes" : [ - "3C7ECA3343757CF715F41334F4DB668B3FDCC40F4BC4254FBE0400555DCE72D4", - "537FB843F8AB0749B4D27028B76D2E80D02B5479102EC43F92486C5D7AE75907", - "6BFED756A60D16582D4132B29E07B087FBFCC2210295CAA6AA11238BC13EA785", - "F65B5293422BD30522CED800B6D14D9A79DE5698412134FCD5CB276512A1ADDE" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "r8RwFcEDnhCJATxjEjVAjQ1QszVsHD2Hn", - "RootIndex" : "0002CD31E83DF6281A9A8D7481D5FCFCA5003E57CDA551FF0B99ED6E34E71840", - "index" : "0002CD31E83DF6281A9A8D7481D5FCFCA5003E57CDA551FF0B99ED6E34E71840" - }, - { - "Balance" : { - "currency" : "EUR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "EUR", - "issuer" : "rJ6m73X94YvJxXJRMU2WXQx5s1G3woTAx7", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "EUR", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "LowNode" : "0000000000001B92", - "PreviousTxnID" : "00CFA69736975A56B4EA193D9207304E077C53F3EFA6C3AA024A8B2974225016", - "PreviousTxnLgrSeq" : 51640267, - "index" : "0002CD3BA78E323561C904095C2EDDD0EAE58682C251C3AB249EFB9750E92C8F" - }, - { - "Account" : "rKyK3pQtCTMz6nt6Yxtx8vgju6hLyLWpwh", - "Balance" : "1000000289", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "C0F561FB05A808EE51101B4D451F676224FCD18500049054BABB96DEB07D4C35", - "PreviousTxnLgrSeq" : 53531363, - "Sequence" : 1, - "index" : "0002D81201E576CF3E0120E2CC35C03E08E22452F498B8C874CD1DF9D3DC305B" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0.879917248308" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rPT74sUcTBTQhkHVD54WGncoqXEAMYbmH7", - "value" : "0" - }, - "HighNode" : "0000000000000178", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rGestQBBx9LzvB84EuT4fXLMGJwobM4hf8", - "value" : "100000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "FC708BDFC90FFF03350A3D8DA999382F7D26C23C9E506E21EE85988BAA713868", - "PreviousTxnLgrSeq" : 46748120, - "index" : "0002DBB4B998AC5B154C44CF6D09AFC56F1EF7AF932F3F8639148F603849E287" - }, - { - "Account" : "rKcA2BEGo1F9FgjxZCpYKXCPdoRgs6HfEx", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EED2AEB0E8CC724DB3993DC7A4AA39CE45D3EBAA14FF3191833522C3C51ECF0A", - "PreviousTxnLgrSeq" : 35775598, - "Sequence" : 3, - "index" : "0002DC77014AC99A1EE11FC396FE3EC53114075916DB1CA19B6D00FAB2054279" - }, - { - "Account" : "rnFzegAparFPG2iT3ZjNLyJCJgTaTGTAze", - "Balance" : "44977500", - "Flags" : 1179648, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 5, - "PreviousTxnID" : "87E952D70F677E01F7BDE997B56CBED3B03B089F983AA4E8B5510A9A4E993818", - "PreviousTxnLgrSeq" : 44630608, - "Sequence" : 4, - "index" : "0002E13AA676C29F39CA24FCE64D649E41EAD3878674E38F15AC2E8A2C62F7C6" - }, - { - "Balance" : { - "currency" : "EUR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "EUR", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "0000000000000B2B", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "EUR", - "issuer" : "rsrqGKug9zri8a6v1ntrxG1iY29jc17eaW", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "62A36774CBBB4C81A0DFDED7DE937B94C9FED2F1E851FDFE813CAEEB203A6745", - "PreviousTxnLgrSeq" : 33856831, - "index" : "0002E2F1FD488A0EE9D03253761F144EC0DA33AE3C4191D257B5B11DA3FD85C6" - }, - { - "Account" : "rEJPTXe1N961YD9cGmsmgwMpZmbz26Yave", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "84F8284D4F9C04C3B597C988A09D2EE3429C11432850FA2C6B5174606F47AD2A", - "PreviousTxnLgrSeq" : 45560553, - "Sequence" : 4, - "index" : "0002E40161CF611D05E5E3955ECF602A0CB24B15AC0D34452342564F1ACE8746" - }, - { - "Flags" : 0, - "IndexNext" : "00000000000004CB", - "IndexPrevious" : "00000000000004C9", - "Indexes" : [ - "E8C9A4D4FC68E8907135B58F79CB7C9A226354E8763E3366DED150ED31B00A3E", - "C76498C69D0DA394320DCD231221BFE68DAA799FC83C39BA077535B1C1C64357", - "A8CF9F1AD796E54FEE58B3325606D629123C27A47D7DC62D3FF9D7EC050FA379", - "8CCC845672D85DC8409187B6AF07178726852F123C9778B41BE1F725B7D52E85", - "67DEE30B11DF75D230355AF0F62232B2C3FC741446BD58EDAE8B8E948F10A98C", - "6CD1B5E38F1E830B178C8539632E1AB649A3AE96D308FD54670AABBC261C2D8D", - "90015E42BE4342D74C7263CE40B04B19477CA51241DCF5C7EB76C462C1A8A11C", - "DC23BEE432638C1B2F64DBAE2BAE0178FD16FEEF4B60FB4DC06D89FD9925F043", - "CAC174B9408518428BAE74A9845581F66CB3E7073C2C34033DFA075B0BADD594", - "7009D3F91AC4E64B37AFAA5B9FB76AB370E6F9758F99A4BB0167233403F06925", - "B78CB3A31755211BCC3325B6462A20AD4E6BECE76E788DE8487E6560C364FAFB", - "12D2F7522CA12F07533987A3C3F79FE62DF285C7D3AAC8886CD9EF05D2EA3310", - "9FDD34BCDB121570A911E6E318E869FDA3311226F19DC848E9B21926993B3B7A", - "EFD8D41B49D6503256FA072C3C2B6432C67BCEBF2A66E186EA5ADAB618E84F69", - "F26F2F1712EE21B75179B4BAB05ACDB28C0C60146ACA1832D738F9FFD8C21495", - "DB9683C7760AC03A768B3E3E123C315337D3E8C91247BB1AFA2E9BB395B73891", - "03D2F3700BE5F072967C1AB29ABA0F010E05B938BD08DA8985EAA707EB0ACE34", - "4431EB0B4C6E133656F48955FE5A0C6954477C665289B0BAED4AC8202781BA77", - "59956DA4F14C2F71C1ECF70923828616E9285F11CCAC5B7ABD45A3902167C18B", - "CA5C95DEFE1939A958A673F59844F013C7B46DE6CCE474E3F50FE4C2FCE480DB", - "E03D2B6D8F58E4B518264FC3E91C806599709F339D141ED3D03D765C7AEA6B0F" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", - "RootIndex" : "AC7D605DC4B0E09BB9BA05DF47C1D6CFC01688603B14D86BB0E3896B910EF4B4", - "index" : "0002EA7BA21C8D8226C854BDB74D687C237CEF8746F3DC932A559F9C2064F8D7" - }, - { - "Flags" : 0, - "LedgerEntryType" : "SignerList", - "OwnerNode" : "0000000000000000", - "PreviousTxnID" : "F1A41B304E232A9E3C9D598D07E6937B9EF6C1EE9578A7C083983D1A2B90FAB2", - "PreviousTxnLgrSeq" : 35126701, - "SignerEntries" : [ - { - "SignerEntry" : { - "Account" : "rfPN64wTKpvoEcGXbzaSFwTeJvGgkFwTuY", - "SignerWeight" : 1 - } - }, - { - "SignerEntry" : { - "Account" : "rJ5LGeJ3AXgtyUaBj9Nv9LTfSLnD5S5M68", - "SignerWeight" : 1 - } - }, - { - "SignerEntry" : { - "Account" : "rKZJjkstK1pRQzk8s7UiaX7Ubo6Z3TVNVD", - "SignerWeight" : 1 - } - } - ], - "SignerListID" : 0, - "SignerQuorum" : 2, - "index" : "0002EB7A73AF53419F135C2E732BC70774B84D1235E96AE5F2D4481FD2EB079E" - }, - { - "Account" : "rM3swPFaTfwJJuUaGQ8hnA5koULsewx8u1", - "Balance" : "19978733", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "3F89A76079746F3EDC49577DE020781A65BC3289122B2F5358F22C8BA27A7D9E", - "PreviousTxnLgrSeq" : 35582012, - "Sequence" : 9, - "index" : "0002F175C2C7472A08F2B030E656B5C6F114A5CA3F00290802C2E16F7D60541B" - }, - { - "Flags" : 0, - "Indexes" : [ "A1DF1B804F052A8831B39E1F6B6B1DE5F4E78C0E33863570E3C665D35C4B9C0B" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rU5whLGPpEmntcqTwQaLS4nsnrHe85ozM1", - "RootIndex" : "0002FC2F23C62F316FE8823101479F16BA154E6F2FA798A31C3CFC17072E24B2", - "index" : "0002FC2F23C62F316FE8823101479F16BA154E6F2FA798A31C3CFC17072E24B2" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-2.939007646409247" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rn4P59E8AryXfuWyTcP5PkUC8fVDjvLN5f", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "LowNode" : "00000000000007A8", - "PreviousTxnID" : "6047EC41BA9E306F7AB111ED174FEDFAFE85B3E2C22409A0B934252C5C94DB28", - "PreviousTxnLgrSeq" : 32218908, - "index" : "0002FF5B1CA1E2C54BCF1E547A8EDAF9A21E4488D88338A7FCBA5D8B5AADAD7E" - }, - { - "Account" : "r99ooocgKebimq2QGsQ91zE1haNkMtDhSL", - "Balance" : "20944251", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "D93515E7915B3090014A11424F2B04F10DC8FFD3BC32D8E5732BBE7DD80DF51F", - "PreviousTxnLgrSeq" : 35406923, - "Sequence" : 5, - "index" : "000300F1A67DDDF180F2F5FBB4842DE5236307886D2C38188C1407EEA9AE4745" - }, - { - "Account" : "rskLVNC3mG17QRroaoppv6Edf8joEorHFT", - "Balance" : "19999988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "3DAF88BE77786AA0AB4D5B19844B88EB181CEDF58E1DA20A198740F7BC0FA024", - "PreviousTxnLgrSeq" : 40120274, - "Sequence" : 2, - "index" : "0003015678A1517A89526AA29CBB8A8BC257FF6622D88557DA658E3411F21B3B" - }, - { - "Balance" : { - "currency" : "XNF", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "5" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "XNF", - "issuer" : "rPKSvQ1qFAksr7hzk2wC2xtqSqFbxP3wvg", - "value" : "0" - }, - "HighNode" : "0000000000000006", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "XNF", - "issuer" : "rngKfjktN2ULxQrsdbsCvU8CKRA1cevHNP", - "value" : "500" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "05C99D17CE9575782E6B74151CEEF53A6D693A8AC5F27300B491916219FFAB61", - "PreviousTxnLgrSeq" : 4479312, - "index" : "0003072319EEE0498F96A9476F71B6471B1B7F950851E3DFCF9420C1F5298BD3" - }, - { - "Account" : "rGXfiCLX166omuSmZbms2ZoMYNBRzvHP8z", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "1A13C53D96A4D339F5BCCFC198D0C5D0C4886BF85D50CDAB3D63E0308CEA9D31", - "PreviousTxnLgrSeq" : 56480801, - "Sequence" : 55816494, - "index" : "0003079A869E1823BDE38CBB99D56BF929EAB01BA290B3E32473221EF02E1466" - }, - { - "Balance" : { - "currency" : "STR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 131072, - "HighLimit" : { - "currency" : "STR", - "issuer" : "rHCYrkbmxBwMKD6JjVAZBCcuDCPDMjxCB4", - "value" : "1000000001" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "STR", - "issuer" : "rsP3mgGb2tcYUrxiLFiHJiQXhsziegtwBc", - "value" : "0" - }, - "LowNode" : "000000000000007B", - "PreviousTxnID" : "7F0F38E7CC1A000F378E1EE9CD42D2C1B98702A269F93359A823FDCD801FD42D", - "PreviousTxnLgrSeq" : 10178957, - "index" : "00030A41AA99869C6DBD24DCF0C91A1FD6AD63EAE7820CE92165D025F1EC5B93" - }, - { - "Account" : "rN2TMeaxGAGHDsUD2Qaf2CtkPtraKmsvaC", - "Balance" : "19993287", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "2243B0A351E5778480EDFD2627135B2D33763EDF67D1037A8950A50076D59B2F", - "PreviousTxnLgrSeq" : 33384428, - "Sequence" : 6, - "index" : "00030A5B5C54753400E0FB69A7A376DA8EC245D6942069A3E56CEC3276B0D902" - }, - { - "Account" : "rLnnTEpzwrcBj2Zpd33Dsq77iutzSvjNzo", - "Balance" : "214124738", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "0EDB7A78F89202267DF062A0DEF0DC9B285774D65053D599DD2FFAF088BE4A83", - "PreviousTxnLgrSeq" : 28757580, - "Sequence" : 69, - "index" : "000311FDE6DA20683ECA81978A6E5C617C38E2836105405FF4129285D506B9C3" - }, - { - "Balance" : { - "currency" : "JPY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0.3369568318" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "JPY", - "issuer" : "r94s8px6kSw1uZ1MV98dhSRTvc6VMPoPcN", - "value" : "0" - }, - "HighNode" : "00000000000000A3", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "JPY", - "issuer" : "rfYQMgj3g3Qp8VLoZNvvU35mEuuJC8nCmY", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "06FC7DE374089D50F81AAE13E7BBF3D0E694769331E14F55351B38D0148018EA", - "PreviousTxnLgrSeq" : 32253063, - "index" : "000319BAE0A618A7D3BB492F17E98E5D92EA0C6458AFEBED44206B5B4798A840" - }, - { - "Flags" : 0, - "Indexes" : [ "0F6870E7A353A08AE5B4C3BD1CEE6970F453F8A4B3D18B91C4C95838A56EA75F" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rhkXLsw9GevBLKy6wHTjFYBb3Ym8y3gqGn", - "RootIndex" : "0003224EF471E4E409840399C5265A20B1A83F8882623974043284461455AA7F", - "index" : "0003224EF471E4E409840399C5265A20B1A83F8882623974043284461455AA7F" - }, - { - "Account" : "rshcmLugYnNfo4LZz11P6p1tHVvKm8exwt", - "Balance" : "19998149", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "032FF7D8A3E7B7981A380430C4130304155F8DC5B0D6D7AF2AE9BCEA96043C34", - "PreviousTxnLgrSeq" : 35909240, - "Sequence" : 21, - "index" : "00032BDB9B745EFCAF7E3DB11BA75D05A8286A2AC7EF4AC61F43A72AEB0D504C" - }, - { - "Account" : "rUTx5eW837RS2ev1uSzKbAMoiTyeUNJKjR", - "Balance" : "67766079", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "E3465D18EB0E072F92E918DC43EBDEE2DE991FE6C3C8D99DFD5BC3C34AC7D938", - "PreviousTxnLgrSeq" : 45158420, - "Sequence" : 6, - "index" : "00033122E0DDE1FC1F96F3749A4B05E1DE3743F38CDC6915D9A5524B28A2D423" - }, - { - "Account" : "rUXmrQadHNnW5TPKzZiZB2ufVZnLAYRXF1", - "Balance" : "325818483", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "AFD43F421282EC80911D6C7893425D6A4502BDD4D2C0682CFB28EE9AB45AFD8F", - "PreviousTxnLgrSeq" : 41689452, - "Sequence" : 53, - "index" : "000333CDAF9C498EF3E726F426B9D953488624B318AF755C6498735CD8855A62" - }, - { - "Account" : "rfFMmbCCRSWwArbhfeKGhufZuGRbW2BhW4", - "Balance" : "125998750000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "261AA7D6FCED1FADD956FC63C72DB2AAB5E8305EA9896D7160D55431DEF6CF61", - "PreviousTxnLgrSeq" : 56212007, - "Sequence" : 55935184, - "index" : "000336C16900E4633CDE390D57C285B5D831842F403900B2B4F65EC56FE17F2C" - }, - { - "Account" : "rPyKE3f9VmYFZt1kNWRYrU8NkGWPoJPSoy", - "Balance" : "20840074", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D502895B5F48CF00B6D4661F278CEE3B39BBFF1143D8DE6A060E9B8EC31C1F3F", - "PreviousTxnLgrSeq" : 51806631, - "Sequence" : 55, - "index" : "00034DBDAB31C00B376D6A4B33C5F61A50CBDC1446E64C5E125EFBFE1FBB191D" - }, - { - "Flags" : 0, - "Indexes" : [ "081342A0AB45459A54D8E4FA1842339A102680216CF9A152BCE4F4CE467D8246" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rh6kN9s7spSb3vdv6H8ZGYzsddSLeEUGmc", - "RootIndex" : "000360186E008422E06B72D5B275E29EE3BE9D87A370F424E0E7BF613C465909", - "index" : "000360186E008422E06B72D5B275E29EE3BE9D87A370F424E0E7BF613C465909" - }, - { - "Account" : "rL98jaU74YA8ApTTKbkMhtDSvcNfiwUcrp", - "Balance" : "20778948", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "57B6A618645E8B93BAA41AA74E56D7AE985428EE490EC9EAA6C4BAD9F39D4961", - "PreviousTxnLgrSeq" : 39541514, - "Sequence" : 2, - "index" : "0003670FB502C9F2C9CF7294F92B0538B4333E9DDF12D65E36D2F65279086066" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "USD", - "issuer" : "r3dSfgL1c19ckULHUfZpAxHWkwCjWfFhZW", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "LowNode" : "000000000000125F", - "PreviousTxnID" : "EFB3C219A768237D668A7B7B50EB21CDFA3034E70AFBCD4A9338E6CD8F3C4F9E", - "PreviousTxnLgrSeq" : 35441502, - "index" : "0003758269F37C061C180B0582EE30F961E3AB9D44E1BC0020B81091ADE999C8" - }, - { - "Account" : "rP3mqGi5PYN22WUf1Fo8K7ncUntWL5rtHS", - "Balance" : "87847269", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "DD15C6074AA46CD8EFAEB0BEF4FF9C8C4B3187E46E89B314EB880808EDD38746", - "PreviousTxnLgrSeq" : 35798376, - "Sequence" : 1, - "index" : "00037AC83282ACE26F066DE2D607300E47D4A62E157CD469E1FE748A4B009F31" - }, - { - "Account" : "rfUvH5v84ytdn23UwXWZvV7SNuH2dgv3v8", - "Balance" : "50019989222", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "82682C0E4EFB0FC31815C36250C6BC129693F8C0B168DB232335DF6D40BAD86D", - "PreviousTxnLgrSeq" : 53565632, - "Sequence" : 2, - "index" : "00038644504E6E379BD37046FDA37C417055D7A88D209F7AB9C3D41840836E7C" - }, - { - "Balance" : { - "currency" : "ETH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "ETH", - "issuer" : "rpbXVn3MEwwwXyAHZtKwEqyV1x24qEWdfR", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ETH", - "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", - "value" : "0" - }, - "LowNode" : "000000000000056C", - "PreviousTxnID" : "7E9ECD12BC8814A2F575C983308F6F8D2145802AA2BD9A79430529D805684CF9", - "PreviousTxnLgrSeq" : 34768922, - "index" : "00038CAB8AD69D82FAFA3E0B02BB1CA040959B933DF4122EFF009D76A00658FA" - }, - { - "Account" : "rpUbFUFNiVcJRgUJj8sutNmLN3LLexyGEt", - "Balance" : "29974636", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "E02A6BFB72177EF2BDB1696819233BBD86CFD94B376C1ADC2A6EA831D8F3C5FB", - "PreviousTxnLgrSeq" : 50996773, - "Sequence" : 77, - "index" : "00039B62AAB31EE54B8CF9346CBF12A8A9FB80EB0C2BBA04155B5B4F0FBA594D" - }, - { - "Account" : "rQrT1y5CkTKjY6zvci2TruPw2vEGraMvvt", - "Balance" : "3416025660", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "B9BF42229699062CCEC0EBC171CE1177CF99EF387E1C378047C8E3128021FDF2", - "PreviousTxnLgrSeq" : 56479420, - "Sequence" : 55482786, - "index" : "00039CCD5DFAB67E18E978BA2578600A56CD94B71E5EA2920CB825EAD0950888" - }, - { - "Flags" : 0, - "IndexNext" : "0000000000000784", - "IndexPrevious" : "0000000000000782", - "Indexes" : [ - "05F6DD98054AD536FB7D1EE64FF2E37BEA525987300C9051057A428D64CFC64B", - "0E23EA9F7D1466FD72C2D7330E4C0048B4E4B97351EAD7C7851D8C0BAEBF7E15", - "2E349E02287ACB74A420254B3E5535DE13327AAB81A524A877F778CE5CDC2149", - "2FDA646F4E34E04E142223EE957C265C521C28F93DF08998191281C1E5ECA498", - "37010083EE0EE6FD172F3A9FC8D8C4A61FE49BCD640FB7D14D26DCC0E40E61C8", - "5233260F503316CB6EA03FA4943D1E51078E98F7D58BB0544344D552884221D0", - "5775CB45790C38F6EFD6A8D389A683059F00D109E6F39A309BAA852EACA7DEE9", - "5F13E18B1CE5E53B79606BDCA2CF9F96BFBB82B31E7114A9A7E6730CF7788E23", - "66E278F46FBF660D6EDA7EEAFFF8D509A4FED347C297B8EB3E88E77B65EEF3A0", - "75B5F03D5096FBA46E298498583FEDA09C6619F6BD40D12DBB0A8956BA04EE9A", - "78B60DCC25CA34332C66903DCA62B2F1031F025105C03C2CF1BFC71079E606DA", - "886CDA9A8C949DE729D83B0087132AFD126B3D1A1155BAE5244F1F1DB957DF64", - "9085C41FE89F7A7729B5D2E851CA27EFC75C4A5FECC1CF45CF77D68683E7F8E7", - "95AB2A9A055A76C6FC99C2AB752F825BC4FF097017554C8980A045D9C2106F98", - "9D17132791D4A6E9A9FCD2335401290F0A24FF5A18D99F1041E36B98DE765C5F", - "A02CA67F804DFAD220BDFFC49572FE8F8545B6B17F716316A03783619EBBF2C7", - "A8F40848D68D4D138EDD5CF0F8534657D423C02E40581C5EB8DF4861BEC4BAEF", - "BC6B27DF63284E418A1C925D4E8B2E999C8672FBB08839B2AACAFC83789CD527", - "C3A98E846189D1B85DF395ED97F086C3F95B5855C93A07739E6E9AD4E368F679", - "C9BB90AEBAD895B6E7D7D37C6F2BDF53744F06ED8D720156A5DAB8AE904FD554", - "CB8A6826ED894DA07CCE3B47BBF51805308A17478580C1F9591A9085D712A6CB", - "F971A92DF948FF4F8A5A0EBE54C37AD1757C41A02AA1A219A3D0307FDA7E25B6" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", - "RootIndex" : "4EC2C3BBB5D149BD55EBFB6841BFC74978B240A5312EA96BF569367782997DBD", - "index" : "00039FE2851CAFFBF4AB8906A7CA4C6DA20A03AECD402A62E25B5503BA264C90" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rw8tGC1FHXeuQHo5ccGRAhwNd9MHFsUaXY", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", - "value" : "0" - }, - "LowNode" : "0000000000000461", - "PreviousTxnID" : "BFA706F20486360826B396D37B6687A017494B713A0DA607248BC7C1DDD688E9", - "PreviousTxnLgrSeq" : 31239501, - "index" : "0003A1E91894EAE15ABD2E8172734A7F56847D845570AA9071EBDC0A4F3994DE" - }, - { - "Flags" : 0, - "Indexes" : [ - "58BE13B0871BBE38CB03C9B3BDD3D449FCA43B992DEC896C99632809354A75BD", - "52A28BBAF0EC325F81CB248D8C2FDD27289523738DD0BDF861626ABCB1012D75" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rB9KYTdt1NPvt4rjv3HaGyghuV8ZbjxAiv", - "RootIndex" : "0003A8522014599601A808BF68B490BADE57DD328B07897F9CA18C7782C3C29D", - "index" : "0003A8522014599601A808BF68B490BADE57DD328B07897F9CA18C7782C3C29D" - }, - { - "Account" : "rfretfgjYcB6cVRSqUkGaUBRrPJg7oWXBk", - "Balance" : "20857762", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5398461E08D4B541D3A9B120E9B684CA563581732DBA3024EE2B4837C5636854", - "PreviousTxnLgrSeq" : 36532402, - "Sequence" : 3, - "index" : "0003AB72C4F8DC6C6F9FE1776429E758330E7061EC9EF28D4EF46A1C23E535C4" - }, - { - "Account" : "rHzcWrLab3MubitUfsNGsLNqKeA75VCzjA", - "Balance" : "19999990", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "958B8FFA11DBE960A1346D960217180F37600F8A9E7DAE9EB0C170B1F0B85064", - "PreviousTxnLgrSeq" : 35703532, - "Sequence" : 6, - "index" : "0003AC9192E3746F287527542C724A38FB1689F50AB89617930BCA53C051C8AE" - }, - { - "Account" : "rEjcYAi1kePMyrQTdxFkAdCg8DjUNG2nGk", - "Balance" : "19988000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5A7CE59A33514F05951427EAE6D5139721464730840EC890DC8520E5DA77C7BB", - "PreviousTxnLgrSeq" : 15913663, - "Sequence" : 2, - "index" : "0003B74499E08C266F506BF1F52B4E5212493D913493E4B037DBF867A5437530" - }, - { - "Flags" : 0, - "Indexes" : [ "05654771F9B57011239F2AFE5A92F08220318968F1438DFA64F2CDF0A414B5E6" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rGt8yFKTASyBxCXE9bzXpF1Ucsdx9wdNYD", - "RootIndex" : "0003B76E9B32E108BFBD663FDFB30BF1CDE19E411214C1D9E4A28417CFCAF6BD", - "index" : "0003B76E9B32E108BFBD663FDFB30BF1CDE19E411214C1D9E4A28417CFCAF6BD" - }, - { - "Account" : "rJdAZgrkgVAxsksMkZbn9zheeQFLzp6SGs", - "Balance" : "39999976", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "0A57BAB1C758ED1D3F808133343FDEE5972E9CD0B071A3A814D1BFC64DB039EE", - "PreviousTxnLgrSeq" : 37117674, - "Sequence" : 3, - "index" : "0003B8F63DC61D899B69A0F889DE22EF5CD4B0532DF2C6F4503E45A74F5C6257" - }, - { - "Flags" : 0, - "Indexes" : [ "792E7B025DA04B17EF4BF7C682EA21C900C189D12994B259DE2980F8C62051B3" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rDg11bHubiWpoki8rt9gxpTtLyJeZJ9Sp5", - "RootIndex" : "0003BA5377F7E730EC26B29C412B25707992213103754914DAB2105EA13CB604", - "index" : "0003BA5377F7E730EC26B29C412B25707992213103754914DAB2105EA13CB604" - }, - { - "Account" : "rwZF2RtFafhr3igLU5R32Sedk9gjHDYLDm", - "Balance" : "24977500", - "Flags" : 1179648, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "F15DC44FA931A53BC44940B42A0EFDE4C46BEDF23E1A8A7CFD5BE75224348139", - "PreviousTxnLgrSeq" : 51619073, - "Sequence" : 4, - "index" : "0003C51FEC6DF5EF908A32AD980883A8ED0B39A1855870922C935DB43194D173" - }, - { - "Flags" : 0, - "Indexes" : [ - "6057B8300EF716859B9BF62C8C8C98EA232F7A02E1EF7FED4A0C0F7382F68A51", - "6D3BBE35F7C18C8747310107B1A6B7295EE1FD6667A00015A9FB6681AB0BE10F" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rPbdWUNunUfAGaprmJo5hQyWUkzXrbANzB", - "RootIndex" : "0003C626CADF620F2E911CCFB70BBA29795339274DA9EAE7A2BEAA6C105D1AA5", - "index" : "0003C626CADF620F2E911CCFB70BBA29795339274DA9EAE7A2BEAA6C105D1AA5" - }, - { - "Flags" : 0, - "Indexes" : [ - "C35FF73535631AFA1BF6F15AD391FBE7FFBC5CA9B63411DDCC5E10EC07149AF0", - "AA32F82B41B573D12970D05D5720DEAEA60C3502A3054816ABDED76ACFEB2C3E", - "9A0135755653009912CEBE1869626D7DDBBAC4FA2B0302DE70D1AAEDCD29AC5E", - "1F00033E131AE60F9C3389E849DD4EDB3F00694CED969CC3E8558B5435948899", - "062DEEFC31527A88DE509CE9F09F1D8710E134AB606D05AEBB9B503303821C59" - ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rUyB89zuaijCypgLEXzQXUqthe5FPHUMc", - "RootIndex" : "0003C8E760C9CE377CA4486675760C984DD380E14088CF34E309F7D266956376", - "index" : "0003C8E760C9CE377CA4486675760C984DD380E14088CF34E309F7D266956376" - }, - { - "Account" : "rNxHAm6DrFCgLRV8iyNMzmsmDc3yT9fMew", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "7AF4C24E06DD0F8E2673556DA7E9B4C9F723172898BF29299F3DD5CD62032734", - "PreviousTxnLgrSeq" : 46462347, - "Sequence" : 2, - "index" : "0003CC742B46D74305CA8E046819E1AA97D1562C79220075C88F910DB3D6985F" - }, - { - "Account" : "r6NGJbC8Nh7qg7mNNkn2QpAzLWfh8hP58", - "Balance" : "93294121", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0A1527D62D932335CB5B3CB39073FDF70E005717A21B81FDB8454C56264CF965", - "PreviousTxnLgrSeq" : 31926264, - "Sequence" : 3, - "index" : "0003DC0717153A0FC5E2EA4BA5B591B212EA1EB5BE7B39855D894A058E202F8D" - }, - { - "Account" : "rHpBxwCmb1qDYfL47Yssog86oWYdrWZf5U", - "Balance" : "2000000002577", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0FD4DFDA203A9F9D7E47C7DA2412AA38ADBA2B200515A0AB5F077EED7DF53192", - "PreviousTxnLgrSeq" : 55163924, - "Sequence" : 1, - "index" : "0003DD9FD0C0CCCE359F26E8395BA4A60CB7074439188796C9BED785258375E8" - }, - { - "Account" : "rs2Pi9HrrmrHSva7Rp6m85WTMbijxU8ZRN", - "Balance" : "16294773045", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A887C95A0C6EB0E9052F4DA814D04A411126F255246DCADE73F23184164416DF", - "PreviousTxnLgrSeq" : 55182715, - "Sequence" : 1, - "index" : "0003E412CC0915B3AD068FEF0D8AF37E09DD2DBC802F8D3F5075E13D700955B5" - }, - { - "Balance" : { - "currency" : "ETH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.000375" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "ETH", - "issuer" : "rtR4429hdNSHotarYCqzeJAxqRw8cER1S", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ETH", - "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", - "value" : "0" - }, - "LowNode" : "0000000000000241", - "PreviousTxnID" : "A6626B1A8A4D66395DF9B4A29A20A31C0AC2E9151274EF4871F1ADCAA6F434C4", - "PreviousTxnLgrSeq" : 31100032, - "index" : "0003E975AB352553F6FC94C4643C2FC13B8CFD1C176DC61694BB5FDEE767EB3F" - }, - { - "Account" : "rfr1PerWfzGmbEn8ZKuz1hGsk4smDAZGST", - "Balance" : "19999980", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "2E9AAC3FA2ECF151EDD81C5E8F88BFA8AEDF755B244283682B086D12F857E0BE", - "PreviousTxnLgrSeq" : 48589693, - "Sequence" : 4, - "index" : "0003EC18AC4B2CF519F33BE734870151F8BED09AA250F1E95CBCD95E04908791" - }, - { - "Balance" : { - "currency" : "GCB", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-33333" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "GCB", - "issuer" : "rKVqAXyd2xdP9iPUJ24j7wjX9TW2oBb7iq", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "GCB", - "issuer" : "rNdwi8ain5ibXNB9A7H3zzKtSxgVzAqqAe", - "value" : "0" - }, - "LowNode" : "0000000000000169", - "PreviousTxnID" : "9B30B8940D0519DC4DBB904E9ED34A12FC42F366981C3BA73E1C43E3E5D27A06", - "PreviousTxnLgrSeq" : 38343800, - "index" : "0003F339D937025D9FAE8724E3949CE4A2D497EE72DCF17CAD03C07E69C312B6" - }, - { - "Account" : "rNPYdGhgeVHyD7Loj4vrEPMjSPGig2p2Fj", - "Balance" : "49999970", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 3, - "PreviousTxnID" : "BAFCA0A4AFBA0300B8800C16E3ABEB0B095BF3103EA985D064EF9C1AD061B9CF", - "PreviousTxnLgrSeq" : 44292686, - "Sequence" : 16, - "index" : "0003F463DC9910431C20BE61FBE203C1776A97847A6C03FE662D0CF571E812BE" - }, - { - "Account" : "rHP4k7K8hxLAJkJjDc6qn6VhkibPU6Vhee", - "Balance" : "10955579573", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "B00C84FD4723003C3EF88934D2182BFEA3A737BB11E81A52340517D9143DCFB3", - "PreviousTxnLgrSeq" : 56192692, - "Sequence" : 2, - "index" : "0003F8872371E899468914E24BC20DD218BE8A2647AF5348E1FFCA92EFE96717" - }, - { - "Account" : "rNozxmhZbAnfcoFrvENNo64HEW5ceNpPPQ", - "Balance" : "19999988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "44290B40914D1192777662E29FB32F43207FB52E7E2BBEFF5F01EBA0ADCF8B08", - "PreviousTxnLgrSeq" : 48580948, - "Sequence" : 3, - "index" : "0003F92B400F4AFA2CD3386459C99408786124EA11BF6D5CB211859142BCC8CF" - }, - { - "Account" : "rfNXU2szUFio4Hus3nikZCxRTM6SB1wGmG", - "Balance" : "2000000167", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "91F073C52B1046E4A4280BDC5299FA25766640DDF8D537CD189424B84C55B4B9", - "PreviousTxnLgrSeq" : 53535233, - "Sequence" : 1, - "index" : "0004006B968DCD105EB9235C8E7CF2A5DEEADC645073BA5D43642CE874CB448A" - }, - { - "Account" : "rUAcsDtb9haqV4Yu9TeSSjpzb8VScp9WKF", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "76916479558C2B1EFA75271AB49DFD491B1B38A9A024584CE6210F34370CF97F", - "PreviousTxnLgrSeq" : 43500691, - "Sequence" : 2, - "index" : "00040A6B5E10E3BC48E76A1FBD64F26C5DBA536C77EAEFD62DDAD03822E79F0D" - }, - { - "Account" : "rBrzrsaHN1NMJ8wNirWGi4xXRixVMa3K4j", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "3BB91826267F85C3A203A5E37FBE643E4AA1F16E2DF8ADB33A009FB93F492BE7", - "PreviousTxnLgrSeq" : 46452698, - "Sequence" : 3, - "index" : "00040B73AB116C267CE43B7A7A7BAC16FDFC0936DC9AB245D54BB4B672BC9A41" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "0000000000000680", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rhePjBM5Hdhqc2hiyAMMNArwJyHhmN1ys3", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "34B671C49C8226F2993601B9F68383C95FEA701A2055D2E64BAC5E2D0E78AD17", - "PreviousTxnLgrSeq" : 30260251, - "index" : "00041008DFADEF0C28810345202B75AB9AE17BA191F3F4821A46D7F476E69B88" - }, - { - "Account" : "rEYT8JgAafMNKDBqPePJCQzxgnH2KYiRSE", - "Balance" : "707739031", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "956669766DE55BEFA53C7C013D113F43A2590451A55452E0787C3FA0C0FEB854", - "PreviousTxnLgrSeq" : 55788741, - "Sequence" : 55786539, - "index" : "00041034B0D6E62B850BEFE74CE4565E47221D550CD274FE4A1EF6310DE39540" - }, - { - "Account" : "rfZHqsL53Kix5vGwTss9fzUe2mC7AZbziF", - "Balance" : "302424455", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "2DC609DA0D310409F4DB8C9C9DE2A539BD60EE0D94218795D552BFE04921A5A8", - "PreviousTxnLgrSeq" : 35144098, - "Sequence" : 2, - "index" : "00041094FF85918AE56E103122EA8C21B4ED567F17B9AA1764135BF4863BA91C" - }, - { - "Account" : "rJYacFmK5NW6q1en2X1WXsC63FeXbdZZcK", - "Balance" : "1993092237", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "E040A227580A5D98471EC9F08B2BD714D9D131B30C1D9B5DA537625D9D9023ED", - "PreviousTxnLgrSeq" : 53866398, - "Sequence" : 1, - "index" : "00041CFCBED5E832F9AF02921DBA390F2243809CAEE2F6B12FC7FE2257EB4C61" - }, - { - "Account" : "rNn9diyjJ8rypuTMT8eowyDdhWvfka7PyW", - "Balance" : "49995695", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "6DEF945C56DFF972AD5387BBF158343C18DA2AE38810BEACFCA79F0866F8C6AB", - "PreviousTxnLgrSeq" : 29843258, - "Sequence" : 4, - "index" : "000424554D47800D97BCA002008324F3505F3DFA0051369D2BB1EC9278EC1AFA" - }, - { - "Account" : "r4gdggbXw527EehtLpMzSq7HkV8X1ZJNfu", - "Balance" : "49988000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "2C5AA5DD28A86D1FD15C71D5EE10ACB379C26353068C677536CAAF5054EBB63B", - "PreviousTxnLgrSeq" : 10591517, - "Sequence" : 2, - "index" : "00042D99424950CEF1C109E1AD59A1BDB39798CE5DC33997118E5C81CA36D736" - }, - { - "Balance" : { - "currency" : "EUR", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "EUR", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "0000000000000EB4", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "EUR", - "issuer" : "rpqf8HjJVfNGzz2xgp6FHgGSDjFUJVF1Z7", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "58F0CE1FC3D3F698B54EEF63327F5312A4E1F6ADFF0D6C0E9E5ED70FAFCE7108", - "PreviousTxnLgrSeq" : 35077255, - "index" : "00043116DDC6156D7F1DEB82947E530C5D15BC1110EB4B6610C73026608058E8" - }, - { - "Account" : "rhsxXXvmCJSxXdPQh1BghKrwWmGCkidcWb", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "8AD609D944125F19256A8F43BBB306D815237EC2EDDAFDA3BFBBA05DA6207A8E", - "PreviousTxnLgrSeq" : 35163930, - "Sequence" : 2, - "index" : "00043AC62B3EC2680D729DFF135CB31AF9EB59D2866B588959D6F45ADF76949A" - }, - { - "Account" : "r3fDQrGYJsLfVnX2UpR3AvHLQMe9ttBhFM", - "Balance" : "194809789", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 8, - "PreviousTxnID" : "6BB24B338A3ACE4BADEE7B3F947636C7F657F459CADBE44F2C9B469C999FA3A2", - "PreviousTxnLgrSeq" : 34106543, - "Sequence" : 493, - "index" : "00043C397A43F4E6F99235F840C5783ACE2780A8AD5D5BC344BD7DCB6CD9D853" - }, - { - "Account" : "raoc4ckuPpfqGuuAm55HwUvUHcfuNmiAhj", - "Balance" : "37291669", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "CECA45286DB6F6E01EEE88D950556D6E40BFE67C66A3A765B09C2FD01273391E", - "PreviousTxnLgrSeq" : 36188661, - "Sequence" : 1, - "index" : "00044273E4FCD8932602CBB8545F54E862270F79F183B1C40AA11E98F297E951" - }, - { - "Account" : "rE4TJNbsG6CPM7X3Qhyw85QqGENEhgCKp4", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "9850E15578F6D3A6B8232FE9CA6DAF9B4D10B980C88344D96078CBDB81A9461A", - "PreviousTxnLgrSeq" : 35420496, - "Sequence" : 2, - "index" : "00044E668C2326839EC8E145A4E4C07A451FF3C5618E8892EBC0C21D6D852632" - }, - { - "Account" : "rDm4AioMMZgd7KedMRgv73yQ6zhMJMHHtH", - "Balance" : "19999988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 1, - "PreviousTxnID" : "1FEC8F660682CD2B450F8D4780E2535ACFE40FCDD9FE66AB97DC190DB9FA3D29", - "PreviousTxnLgrSeq" : 37735191, - "Sequence" : 2, - "index" : "00044E7954EBCFCDD3D21AD53777F89196B6F37CD43A40D0DD26A69C43E5DC04" - }, - { - "Account" : "rQBAbNc26Ys3Tbagkmb5jAAf2ZXsaqZyGF", - "Balance" : "20000076", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0D5DA3CC42ADBB68B3A08704255720F928D9984E97C3CB7BF70554F134EA3669", - "PreviousTxnLgrSeq" : 35290357, - "Sequence" : 4, - "index" : "000450DCF34F189E5CF2E97EA797000439AE4A9580FB45885BF979F37215DE83" - }, - { - "Account" : "rEsNWUZ9vr7GjU6pu5W6cEEg8tKwYJy59X", - "Balance" : "20226687", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5A1528246D603633F6E918AA0AB21836E09D7917E698101A702796DE921E6DA2", - "PreviousTxnLgrSeq" : 41695007, - "Sequence" : 3, - "index" : "00045125EE993EF598355CB47A24C482AE07D870F8F0806BA973FB299F4B29AB" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "0000000000000396", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rq4BtzpHxFRQn9qsk3pRhDWPU1CrmYeT6", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "38276C2BF8B8995573F0CD5B3600922B153393CF0F39F422681580A943DC85EE", - "PreviousTxnLgrSeq" : 35441092, - "index" : "00045B7D116EEF9A5441171F497C4ED66BA027A0DB513FA92E13806DB1A0486B" - }, - { - "Account" : "rDZCRYBAkW2JhLvoo879f7schNT5WE1hKs", - "Balance" : "100000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "448F7523B5A49F69B4093F2C310A3CE2DB5E0D1F77EF0A992C01F511239ED4B7", - "PreviousTxnLgrSeq" : 56260953, - "Sequence" : 56260953, - "index" : "0004605DC35B94E8E6481CC6BA45C72C02C05745A1F731A6955863C80845F057" - }, - { - "Account" : "rNPRPQPCCPKDu6XKqN6FxK1vhMup9h7xv1", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "5EE647BB6D9700357D5937A970452D9CD6A2E54BF1144F45F2AA7735BEDE8642", - "PreviousTxnLgrSeq" : 50147716, - "Sequence" : 2, - "index" : "0004622E90BF53DBDE39CB7CB902892F77E367C50059D4F82319A1B733ED3389" - }, - { - "Account" : "rws2ctKicUhnqq3HcnUq1Qbk39NxsGeu2q", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "49F95E1E9DF098C2CB695D2C0A4C12C0345A82A83AF0AC1D38770FB93BC00D88", - "PreviousTxnLgrSeq" : 48127460, - "Sequence" : 2, - "index" : "00046490305BFB74F60BE369CA1170FFD1C40491D3E4963F630130E42E1F14F0" - }, - { - "Account" : "rh5XXc8BFFRA7xeWojr2ZsYgqvgQdhvRAd", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "6DE20189EF8598769263232EABD70197242DBA3196A02E20C1CE30B1C55FB3D2", - "PreviousTxnLgrSeq" : 34283739, - "Sequence" : 2, - "index" : "000466F1C43F93B9A9FAB81F5909438355DECF70C67BAEE2F2B97F7FE80DB23F" - }, - { - "Account" : "rjryT2fZHQMUkQ57i7eqjjWMdSXbL1xWz", - "Balance" : "19988000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EC38AB0D48757E9E088788A3907BD68FC33FA930160902E1A76D72600081EEDC", - "PreviousTxnLgrSeq" : 10644634, - "Sequence" : 2, - "index" : "00046B3B5D5C5F45AE5393761A99A8DDB2CEC25526148FB529F1404EC0DB230A" - }, - { - "Account" : "rnHCMNLwZr6aPhUkHhX1Cog1zkwebJ8k86", - "Balance" : "25489074", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0BB27A488FD2D4579C480C1E89AB2EAF65104548FF5D96A6A91ED209F1870560", - "PreviousTxnLgrSeq" : 48905816, - "Sequence" : 4, - "index" : "0004704B77C1942A569589D35F70AFBC3F2040DB4806733CFC51CA942C1EC627" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1114112, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", - "value" : "0" - }, - "HighNode" : "00000000000005C8", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rhBxjDrNybHTk5zM7yR7d54noXVjvLRtZY", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "EDEDFD10BE0D8B5705B3BC2D05E37E4AD041DDF72D4635E5B062656960325D7E", - "PreviousTxnLgrSeq" : 30031756, - "index" : "00047509E54628EDC5A904C00C08A1BAB60D24BD23CC34CBB38ABE9F45F955B0" - }, - { - "Account" : "r9DvWkeub9kNaESk33UEGFg3euf74sbFWf", - "Balance" : "19999988", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "A1E466CEB29E2EB339F1DE9D6D3F1D7CFF5D826D5D338C1B8124E6CBA6632393", - "PreviousTxnLgrSeq" : 34935031, - "Sequence" : 2, - "index" : "000477ECA17E9435728D0560E349888965579EE5C1281F24190F988716719FCD" - }, - { - "Flags" : 0, - "Indexes" : [ "4B86893AD9F493ACB05E269A62DEB07A25CF49255030CECC91D69767BBECF16E" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rJs1i518wUrJtN8n5ZGjnVU4teCS4bVkhw", - "RootIndex" : "000488530E79F3C7E0B17C0E9DF4C242952A8B85C33AA80F173C842128105EAD", - "index" : "000488530E79F3C7E0B17C0E9DF4C242952A8B85C33AA80F173C842128105EAD" - }, - { - "Account" : "rMgVhSaAnrXBVoqs6QKqaCzcPT28WVbyyz", - "Balance" : "20959223", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "EB3C10C8ECA22C0F53566396871481EB2176768209232266A5029799D8568544", - "PreviousTxnLgrSeq" : 38508528, - "Sequence" : 19, - "index" : "00048EDD8A181E63056A7B2718EF840FC508ED05354955ED0D80BC10609F6DEA" - }, - { - "Account" : "rGbWLvx92cmECTsn3TFJfPuAnbqpdeEgKz", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "585B9341FC91832349AC47ACD4374D6584A44FB16975D83CF0BD7230E3E64F82", - "PreviousTxnLgrSeq" : 48407938, - "Sequence" : 2, - "index" : "0004951F6647029298DF9BF8DB099E8A1A8B74F502BC5CEAD9030A9A9FB7792D" - }, - { - "Account" : "rPPnjVhweEsXfmPchVa6GqHEf2kpooP9iv", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "ABC32682023FA3C11A522B7C7F41524D3ACEA0F7FA11C4FA019BFCCC86DE3BF6", - "PreviousTxnLgrSeq" : 35905984, - "Sequence" : 1, - "index" : "0004980A17929CEB800E3E1CF2F6045B6EE0160F4F342B0ECB791F867D5C8AB9" - }, - { - "Balance" : { - "currency" : "CNY", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 131072, - "HighLimit" : { - "currency" : "CNY", - "issuer" : "rHw3NqphfdPiJbctTLmg9rP2yERoqfWeQ2", - "value" : "10000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CNY", - "issuer" : "rnuF96W4SZoCJmbHYBFoJZpR8eCaxNvekK", - "value" : "0" - }, - "LowNode" : "000000000000003B", - "PreviousTxnID" : "06C4D587DA85B52C504C44DB39272DDCAF216C8403C5D0A943AF0FB9479A665B", - "PreviousTxnLgrSeq" : 3242268, - "index" : "00049C6ACC7B48B847E0EFA9313C0B28E79F7AC9A246DE269D85CC3756D15D6A" - }, - { - "Balance" : { - "currency" : "ETH", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "ETH", - "issuer" : "rUf7tsQugDN8vpTvRdcZgcibmtxHMXATRW", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "ETH", - "issuer" : "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", - "value" : "0" - }, - "LowNode" : "0000000000000401", - "PreviousTxnID" : "BF1138E291AC65A99E3D19C0654E223674896ED9A2530A58D3505EF47934DA53", - "PreviousTxnLgrSeq" : 32435791, - "index" : "00049E88D4D3337584AE71762ECEC72CC045A1FB0ECE5FD0AD71371EC7C82484" - }, - { - "Account" : "rh41r1hMt16UFwaGXCNtC1mAUS5Nuu7omo", - "Balance" : "48999940", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "D4B29DF22B522758875EAC5364D66690C274D81225EF9A48CF40EE8600D3AC35", - "PreviousTxnLgrSeq" : 38585786, - "Sequence" : 6, - "index" : "0004A34C6D6C448499B8341264CE32AB4700695A99C5E7FD60E470D32C80756E" - }, - { - "Account" : "rUfgiY4cAPU8DasL8EYAicPjj4JqCUB4aY", - "Balance" : "523343166", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "570E22E8A811FA0CC3CAFC0F0235428BB8BAE1C4260A6A123FC1F103332B1608", - "PreviousTxnLgrSeq" : 49099007, - "Sequence" : 1, - "index" : "0004A6317EEF302AD8505B51242BE09AB6D117E05A0BE5E886558B15ADF55C9B" - }, - { - "Account" : "rhdHkJnWFvet4Wwhq13iYMHFjT28BGyXbG", - "Balance" : "20505258", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 2, - "PreviousTxnID" : "4E3FCD2B7E7B6AEDC6F0E6767CF9D118CD48348F7F58A2CD2F6D1C932AA5190B", - "PreviousTxnLgrSeq" : 52648559, - "Sequence" : 170, - "index" : "0004AAE0CCF1618C2A894B06A30D7E85CCD8BC944FA30486F990A16085EBADBE" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 1179648, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rNPRNzBB92BVpAhhZr4iXDTveCgV5Pofm9", - "value" : "0" - }, - "HighNode" : "0000000000000003", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rUqNn26jQG8zfNDy21NTCwgFXrFgLyRf3U", - "value" : "0" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "00960BD6EEEEFBAD01B8FBF80B8E8E6783BECF84BBC7C6776F745E3681B8EA52", - "PreviousTxnLgrSeq" : 14819481, - "index" : "0004AC676C97112A2A14494B56C1CD9435B8E319F5152DF1F6BD40EC1A2586C4" - }, - { - "Account" : "rHK7ga3v53tfTCdVPmpHNdvmUGLpG9gNGh", - "Balance" : "109685000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "8EE7DE8E9156503E1BAFA8CA00867946F43FCDC254FE650564D1CCF70F47106F", - "PreviousTxnLgrSeq" : 35185091, - "Sequence" : 1, - "index" : "0004AEC9772AB16AF1C9FD08850D918769F60C55C9FF1877FE8125D0F418117F" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rfSEud5jTYqQF3CnKBHgt3AxkWCnwUgJg9", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B", - "value" : "0" - }, - "LowNode" : "000000000000029E", - "PreviousTxnID" : "301DBB9F2A532F9AE4B565D74AE24862D715CBA450B99CB2F00B657EBDDE0F9A", - "PreviousTxnLgrSeq" : 10242481, - "index" : "0004AF8BD80F295A8E8DA1D6597DAB919037007C70657BAD81B56FCDB7B38E80" - }, - { - "Account" : "rJdq8QfaW7Uur9L63xbC17fx1hXvzXmFGn", - "Balance" : "20439844", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "6187CAA5525A3B413ECACE88C11DD4D1E438D112B04AA43F86DD81DAE2AE440D", - "PreviousTxnLgrSeq" : 49070852, - "Sequence" : 39, - "index" : "0004B458F8891430C7B7A237E66F02E693A78AF2D68822DA5F0DEECC3B171E3D" - }, - { - "Balance" : { - "currency" : "USD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "0" - }, - "Flags" : 2162688, - "HighLimit" : { - "currency" : "USD", - "issuer" : "rNPRNzBB92BVpAhhZr4iXDTveCgV5Pofm9", - "value" : "0" - }, - "HighNode" : "0000000000000081", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "USD", - "issuer" : "r9GhUNdVsPF8kvGdtZs2EH5KvfWefddyXP", - "value" : "1000000000" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "4E910D3230F90B2C5F1D0FA27A40196AC55A0B2625BBAEEC346B9A2D2C05B3ED", - "PreviousTxnLgrSeq" : 24792921, - "index" : "0004B7BE41198D0C0DFC7456B2941022CDEDF96D2B34BA2B4D0A3E14C67A3541" - }, - { - "Account" : "rae6oVSd1aNTJvAwyxE8wKVNVAHyWawN5S", - "Balance" : "20000000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "AB0FFB05D0DCD834B0EC7CBF61801755B595A48CDD7F6AFD5B6E0BF9C988FD09", - "PreviousTxnLgrSeq" : 45371385, - "Sequence" : 2, - "index" : "0004B861C4B94E840FF9401876572F8193C53761BCC8B6DBC99A5D9383D12402" - }, - { - "Flags" : 0, - "Indexes" : [ "8E6889A03B26C4C7D73D48E374471C8C7DFBE994382C229D7D56CF3AF6FB3F28" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "r9sUeAqPayRSsXamaqvWeZPDVENK1ScPed", - "RootIndex" : "0004C29FA06DE0D176D987DFD9712F310BDD6749D6A1F83556BBBF710B07EA46", - "index" : "0004C29FA06DE0D176D987DFD9712F310BDD6749D6A1F83556BBBF710B07EA46" - }, - { - "Balance" : { - "currency" : "CAD", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-23" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "CAD", - "issuer" : "rJhd44rcZNXJs3UKZGf28i1j5Dv1kMHMjr", - "value" : "0" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "CAD", - "issuer" : "r3ADD8kXSUKHd6zTCKfnKT3zV9EZHjzp1S", - "value" : "0" - }, - "LowNode" : "0000000000000009", - "PreviousTxnID" : "DDDCB07625649FBA5AEF4FEF52628E5B34D9A690DBC653D3E61BCFB332E11184", - "PreviousTxnLgrSeq" : 6599501, - "index" : "0004C9E1CF03D437B6D8CE8E3522844BA2DCA9818A83D3E20A1D8FCE374FA3A3" - }, - { - "Account" : "rMXy2mvgGfo6VPKZiE2p178MBk4fesnkss", - "Balance" : "42807000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "713598A0911DB371E6AE6B320D320EAD585E72195728723F4260F86FB41A862C", - "PreviousTxnLgrSeq" : 35438454, - "Sequence" : 1, - "index" : "0004D14B235DD9C0AB959C26C3D1199D3098D8B22DBB694753C398FE011DE000" - }, - { - "Balance" : { - "currency" : "BTC", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-0.000016588782871" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "BTC", - "issuer" : "rErS8387dwmS7E3fDnTFa8XAQRPr5uvFhd", - "value" : "1000000000" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "BTC", - "issuer" : "rchGBxcD1A1C2tdxF6papQYZ8kjRKMYcL", - "value" : "0" - }, - "LowNode" : "0000000000000BD2", - "PreviousTxnID" : "8A292FEDE82F23A60E1BC7188F1C88147DAD7303D297A39875DFC8A7DD74C772", - "PreviousTxnLgrSeq" : 35731651, - "index" : "0004D41DDBE051FD5302886A10C9990F4264DC657CE49F62F95DF3A86E255C2D" - }, - { - "Flags" : 0, - "Indexes" : [ "FD6EBE613BED36E97D7FCAEF9870FFDEC49FCC23FA76FA7443AB59F66C4DFBF8" ], - "LedgerEntryType" : "DirectoryNode", - "Owner" : "rJTjmpFeVYxKzDXcxPYyxqDFPsAjHU1szc", - "RootIndex" : "0004E7DEEA81686BE43530355C41B0931EB4DB21726E6FDF913CF1425AF30400", - "index" : "0004E7DEEA81686BE43530355C41B0931EB4DB21726E6FDF913CF1425AF30400" - }, - { - "Balance" : { - "currency" : "MTL", - "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", - "value" : "-9999999999999999e-4" - }, - "Flags" : 2228224, - "HighLimit" : { - "currency" : "MTL", - "issuer" : "rUZt6cD3ZN6iWat1q3Z6B4YmkPBEa88vYE", - "value" : "1000000000000000e-3" - }, - "HighNode" : "0000000000000000", - "LedgerEntryType" : "RippleState", - "LowLimit" : { - "currency" : "MTL", - "issuer" : "rfe8yiZUymRPx35BEwGjhfkaLmgNsTytxT", - "value" : "0" - }, - "LowNode" : "0000000000000000", - "PreviousTxnID" : "102CCCA09AC9D0337F1E4E8EE66D7ADC6BCE3E54F1D3785A06C383555E81D08A", - "PreviousTxnLgrSeq" : 7117664, - "index" : "0004ED7218296FBABFC9790AFE8A193CB8B4E52CCF6D06D2F5CD81A9125BC7D1" - }, - { - "Account" : "rhafmcHgwPDhUtwHKJHeS1AowVQ6yrBzry", - "Balance" : "186663000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "0B3EF2DEF14E17DEF61DC6489800FCA372A7D2FBBF1344AF690A231EDD722390", - "PreviousTxnLgrSeq" : 35410824, - "Sequence" : 1, - "index" : "0004EFFADB2A92621B66644809830ADC7F5453D96F523D6885D5D4F5953A674C" - }, - { - "Account" : "rse7zNjdyUTcuRyAbnmY7GKV2cSSM9xYbx", - "Balance" : "20150000", - "Flags" : 0, - "LedgerEntryType" : "AccountRoot", - "OwnerCount" : 0, - "PreviousTxnID" : "FF39483D49A3132227A5F83316CCFD943248CA3D5D68161B4177791F9ED384F5", - "PreviousTxnLgrSeq" : 30401374, - "Sequence" : 4, - "index" : "0004F80C0082589154F40E9962406ADF2A6BC943BCD073863B8BB9B3EDB306EA" - } - ], - "status" : "success", - "validated" : false - } -} -``` - The response follows the [standard format][], with a successful result containing the following fields: From 3be54baf6d3e7fb9d179ff0291f1a7c21222d9bb Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 14:07:28 -0700 Subject: [PATCH 43/65] Adds commandline note for ledger_entry.md --- .../public-rippled-methods/ledger-methods/ledger_entry.md | 2 ++ 1 file changed, 2 insertions(+) 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 4734894f71..1d31d48aff 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 @@ -7,6 +7,8 @@ The `ledger_entry` method returns a single ledger object from the XRP Ledger in 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. + *WebSocket* From d83477b9d5ffcf107ff150461d814694ad91ea36 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 14:56:40 -0700 Subject: [PATCH 44/65] Adds proper account id to requests and changes example responses for account_tx.md --- .../account-methods/account_tx.md | 654 +++++++----------- 1 file changed, 250 insertions(+), 404 deletions(-) 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 270633a98a..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,250 +88,168 @@ An example of a successful response: *WebSocket* -``` +```json { - "id": 2, - "status": "success", - "type": "response", - "result": { - "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", - "ledger_index_max": 6542489, - "ledger_index_min": 32570, - "limit": 2, - "transactions": [ + "id": 2, + "result": { + "account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w", + "ledger_index_max": 57111999, + "ledger_index_min": 55886305, + "limit": 2, + "marker": { + "ledger": 57111981, + "seq": 16 + }, + "transactions": [ + { + "meta": { + "AffectedNodes": [ { - "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" + "ModifiedNode": { + "FinalFields": { + "Account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w", + "Balance": "3732969177079", + "Flags": 131072, + "OwnerCount": 0, + "Sequence": 702817 }, - "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 + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574", + "PreviousFields": { + "Balance": "3713891690008" }, - "validated": true + "PreviousTxnID": "D58864C16344ADCC15995C7986CFC607CB693E88F84D2E019F0A35FB29749202", + "PreviousTxnLgrSeq": 57111994 + } }, { - "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" + "ModifiedNode": { + "FinalFields": { + "Account": "rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg", + "Balance": "40010160", + "Flags": 131072, + "OwnerCount": 0, + "Sequence": 466334 }, - "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 + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9", + "PreviousFields": { + "Balance": "19117497271", + "Sequence": 466333 }, - "validated": true + "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 { "result": { - "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", - "ledger_index_max": 8696227, - "ledger_index_min": 32570, + "account": "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w", + "ledger_index_max": 57112019, + "ledger_index_min": 56248229, "limit": 2, + "marker": { + "ledger": 57112007, + "seq": 13 + }, "status": "success", "transactions": [ { @@ -340,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 }, @@ -452,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 } @@ -562,12 +391,29 @@ An example of a successful response: ```json { "result" : { - "account" : "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", - "ledger_index_max" : 56843937, - "ledger_index_min" : 56843321, + "account" : "rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w", + "ledger_index_max" : 57112094, + "ledger_index_min" : 57105464, "limit" : 2, + "marker" : { + "ledger" : 57112074, + "seq" : 9 + }, "status" : "success", - "transactions" : [], + "transactions" : [ + { + "ledger_index" : 57112090, + "meta" : "201C0000002EF8E51100612503677617551E0297F38EF4FED7004E074D246B4EA3E550D9AE0F61BE40E08D3432091D52CE56140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574E624000AB96E624000037771BFD270E1E7220002000024000AB96F2D0000000062400003776C784A418114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911E1E1E311006156F7D315E0E992B1F1AC66B309C9D68961AA327FE770101B74D4C975F8C5DEC96AE8240367761A624000000005478807811403C95DC0C7CE402E8044A5F13304108013CE9963E1E1F1031000", + "tx_blob" : "120000228000000024000AB96E201B036776306140000000054788076840000000000000287321020A46D8D02AC780C59853ACA309EAA92E7D8E02DD72A0B6AC315A7D18A6C3276A74463044022054811EEF61ACCFA1B5FC6BB05D2FA49CF5174062740370328382E6EA557C0E6A0220480584D487638C333A87CA37100354BD36209E355E8DB9FE79791A56E24C1F268114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911831403C95DC0C7CE402E8044A5F13304108013CE9963", + "validated" : true + }, + { + "ledger_index" : 57112087, + "meta" : "201C00000026F8E5110061250367760A556B80EE9A9AD3FC40F471F29DCB80C678375137CE36220718902EF1EDCD375E7156140FA03FE8C39540CA8189BC7A7956795C712BC0A542C6409C041150703C8574E66240000376DEB77118E1E7220002000024000AB96E2D00000000624000037771BFD2708114D2E44C9FAF7BE9C536219800A6E698E4C7D2C911E1E1E511006125036776155591DA498D40AFD90670555F3D719883B48D224B4E4E906C634DEFA21163E8197756CC20FEBEA6D2AF969EC46F2BD92684D9FBABC3F238E841B5E056FE4EBF4379A9E62400071DA26240000001C0D849F8E1E722000200002400071DA32D0000000062400000012DCFE87881146914CB622B8E41E150DE431F48DA244A69809366E1E1F1031000", + "tx_blob" : "12000022800000002400071DA22E00000001201B0367762D61400000009308615868400000000000002873210381575032E254BF4D699C3D8D6EFDB63B3A71F97475C6F6885BC7DAEEE55D9A0174473045022100E592BCCFD85CCE0B39075EFC66D6BCA594EBB451F12AD5AD9EE533A267F1381B02203635AB46AC110848FC44E797BD19D77A19E10A0F463AA5540B1C62E5D48C81F081146914CB622B8E41E150DE431F48DA244A698093668314D2E44C9FAF7BE9C536219800A6E698E4C7D2C911", + "validated" : true + } + ], "validated" : true } } From 30584b5eba95e0778d72db3212f0f01bd0378c40 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 15:14:30 -0700 Subject: [PATCH 45/65] Adds snippet for missing commandline syntax and replaces commandline note with snippet in ledger_data.md --- content/_snippets/no-cli-syntax.md | 1 + .../public-rippled-methods/ledger-methods/ledger_data.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 content/_snippets/no-cli-syntax.md diff --git a/content/_snippets/no-cli-syntax.md b/content/_snippets/no-cli-syntax.md new file mode 100644 index 0000000000..ffc65eb98a --- /dev/null +++ b/content/_snippets/no-cli-syntax.md @@ -0,0 +1 @@ +**Note:** There is no commandline syntax for `ledger_data`. You can use the [json method][] to access this method from the commandline instead. \ No newline at end of file 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 b304dc174c..118265241d 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,7 +6,7 @@ The `ledger_data` method retrieves contents of the specified ledger. You can ite ## Request Format 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. +{% include '_snippets/no-cli-syntax.md' %} From c2a9698138bd7574209190c4c7ee60340344c502 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 15:17:45 -0700 Subject: [PATCH 46/65] Replaces commandline note with new snippet (gateway_balances.md) --- .../public-rippled-methods/account-methods/gateway_balances.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 4d4bc3cc2d..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,7 +6,7 @@ The `gateway_balances` command calculates the total balances issued by a given a ## Request Format 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. +{% include '_snippets/no-cli-syntax.md' %} From aa429a1849e631ae3cdbedd4567980a748108b4b Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 15:19:57 -0700 Subject: [PATCH 47/65] Replaces commandline note with new snippet (noripple_check.md) --- .../public-rippled-methods/account-methods/noripple_check.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 6fb0670110..663637facb 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 @@ -7,7 +7,7 @@ The `noripple_check` command provides a quick way to check the status of [the De ## Request Format 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. +{% include '_snippets/no-cli-syntax.md' %} From 45c48ab48df0dfd2e88f88d901a02b3336557aea Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 15:22:31 -0700 Subject: [PATCH 48/65] Replaces commandline note with new snippet (ledger_entry.md) --- .../public-rippled-methods/ledger-methods/ledger_entry.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 1d31d48aff..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 @@ -7,7 +7,7 @@ The `ledger_entry` method returns a single ledger object from the XRP Ledger in 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. +{% include '_snippets/no-cli-syntax.md' %} From e0805ec06cd7a9044e4b9e05a1e9a915ce147a71 Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Mon, 27 Jul 2020 15:28:59 -0700 Subject: [PATCH 49/65] Adds commandline example response for random.md --- .../public-rippled-methods/utility-methods/random.md | 11 +++++++++++ 1 file changed, 11 insertions(+) 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: From 0ceb1c52541fb2b7f7e36fd92b55ccecc73bdf21 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 28 Jul 2020 16:55:46 -0700 Subject: [PATCH 50/65] Update spell-checker to remove words added to Dactyl built-in dict --- tool/spelling.txt | 254 +--------------------------------------------- 1 file changed, 1 insertion(+), 253 deletions(-) diff --git a/tool/spelling.txt b/tool/spelling.txt index 8aa134a6ff..9e767bcdfd 100644 --- a/tool/spelling.txt +++ b/tool/spelling.txt @@ -1,255 +1,3 @@ -1st -2nd -3rd -256th -absconds -aren't -asynchronously -atomically -avatar -backend -backfilling -backfills -billionths -bitwise -blockchain -blog -breakpoints -callback -callbacks -canceled -canceling -cannot -codebase -colocation -commandline -concatenate -concatenated -cryptocurrencies -cryptocurrency -cryptographic -cryptographically -csv -datacenter -ddos -debug -decrypt -denominate -denominating -deserializing -disincentivize -disincentivizes -doesn't -downloads -dvd -emailing -encrypt -endian -enum -enums -escrowed -escrows -ethereum -expirations -failover -faq -faucets -filesystem -fillable -firewall -firewalls -fulfills -gapped -geolocation -ghz -gigabit -haven't -hardcoded -hashed -hashes -hasn't -hbase -hostname -html -http -https -hyperthreading -i'll -incentivize -incentivized -idempotency -immutably -instantiates -instantiating -integration -integrations -internationalized -invalidly -ipv4 -ipv6 -isn't -iterating -javascript -json -loopback -lowercase -maintainer -malware -mbps -md5 -metadata -mitigations -modeled -modulo -namespace -nonces -npm -onboarding -outages -overwriting -paginate -paginated -passphrase -placeholder -preauthorization -preauthorizations -preauthorize -preauthorized -preauthorizing -prefixing -preimage -prioritizes -programmatically -pseudocode -quadrillion -reactively -reattach -rebalance -rebalancing -recalculate -recomputes -reconfigure -reconfiguring -reconnecting -reconnects -refunding -renumbering -reorders -resubmitting -retriable -retries -retried -retrying -roadmaps -sandbox -scammers -serialize -serialized -serializing -sharding -smartphone -spamming -sqlite -streamlines -subdomain -subfolder -subfolders -supermajority -svg -symlink -synced -synchronizing -syncing -syncs -systemd -tbd -terabyte -terabytes -that'll -they'll -they're -they've -timeline -timeout -timeouts -timestamp -timestamps -toml -tradeoff -tradeoffs -triskelion -troubleshoot -truncates -typos -unauthorize -uncomment -undesirably -unencrypted -unfavorable -unicode -uninstall -unintuitively -unmount -unscaled -unset -unsets -unsubscribe -untrusted -upload -uppercase -url -urls -utc -validator -verifiability -versioning -virtualization -virtualized -wasn't -we'll -won't -webpage -webpages -website -websites -websocket -whitespace -workaround -writable -wss -xml -you'll -you're -you've -zeroes - -bitcoin -centos -cloudflare -debian -firefox -github -google -linux -nginx -ntp -openssl -paypal -redhat -rhel -ubuntu -xenial -xeon -xerus - -btc -cny -eur -mxn -usd -xau -xrp - hash128 hash160 hash256 @@ -379,7 +127,7 @@ paymentchannelfund peer_reservations_add peer_reservations_del peer_reservations_list -preemptively +preauthorizations offercancel offercreate requirefullycanonicalsig From 4c0bf49e30d5b4de2bd73ff456d2a15ad22b7b36 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 28 Jul 2020 17:53:18 -0700 Subject: [PATCH 51/65] Addresses: touch up X-addresses callout --- content/_snippets/data_types/address.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/_snippets/data_types/address.md b/content/_snippets/data_types/address.md index 39e9cfc310..4be3df0fb8 100644 --- a/content/_snippets/data_types/address.md +++ b/content/_snippets/data_types/address.md @@ -6,9 +6,9 @@ Accounts in the XRP Ledger are identified by an address in the XRP Ledger's [bas * Case-sensitive * Includes a 4-byte checksum so that the probability of generating a valid address from random characters is approximately 1 in 2^32 -**Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) an **X**-address format that "packs" a [destination tag](source-and-destination-tags.html) into the address. These addresses start with an `X` (for the mainnet) or a `T` (for the [testnet](parallel-networks.html)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec). - -The XRP Ledger protocol only supports "classic" addresses natively, but [ripple-lib](rippleapi-reference.html), [Xpring SDK](https://xpring.io/docs), and many other tools support X-addresses tool. +> **Note:** The XRP community has [proposed](https://github.com/xrp-community/standards-drafts/issues/6) an **X**-address format that "packs" a [destination tag](source-and-destination-tags.html) into the address. These addresses start with an `X` (for the mainnet) or a `T` (for the [testnet](parallel-networks.html)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec). +> +> The XRP Ledger protocol only supports "classic" addresses natively, but [ripple-lib](rippleapi-reference.html), [Xpring SDK](https://xpring.io/docs), and many other tools support X-addresses too. {% if currentpage.md != "concept-accounts.md" %} For more information, see [Accounts](accounts.html) and [base58 Encodings](base58-encodings.html). From 4aa13ff82d5273b3c2dc9c05d9e34a3b587a5e40 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Thu, 30 Jul 2020 18:16:01 -0700 Subject: [PATCH 52/65] Spelling: fix broken links --- content/concepts/issued-currencies/rippling.ja.md | 6 +++--- content/concepts/issued-currencies/rippling.md | 4 ++-- .../payment-system-basics/accounts/multi-signing.md | 2 +- content/concepts/payment-system-basics/accounts/reserves.md | 2 +- .../transaction-formats/transaction-results/tec-codes.md | 2 +- .../transaction-formats/transaction-types/signerlistset.md | 4 ++-- .../manage-account-settings/offline-account-setup.ja.md | 6 +++--- .../manage-account-settings/offline-account-setup.md | 6 +++--- .../xrp-ledger-businesses/become-an-xrp-ledger-gateway.md | 2 +- 9 files changed, 17 insertions(+), 17 deletions(-) diff --git a/content/concepts/issued-currencies/rippling.ja.md b/content/concepts/issued-currencies/rippling.ja.md index 6d2781f3bd..bb596008ce 100644 --- a/content/concepts/issued-currencies/rippling.ja.md +++ b/content/concepts/issued-currencies/rippling.ja.md @@ -57,7 +57,7 @@ DefaultRippleフラグは、デフォルトで着信トラストラインでのR アカウントのDefaultRipple設定は、他者があなたに対してオープンしたトラストラインにのみ影響し、あなたが作成するトラストラインには影響しません。アカウントのDefaultRipple設定を変更する場合、変更前に作成したトラストラインでは既存のNoRipple設定が維持されます。アドレスの新しいデフォルトに合わせてトラストラインのNoRipple設定を変更するには、[TrustSetトランザクション][]を使用します。 -詳細は、[「XRP Ledgerゲートウェイの開設」のDefaultRipple](become-an-xrp-ledger-gateway.html#defaultripple)を参照してください。 +詳細は、[「XRP Ledgerゲートウェイの開設」のDefaultRipple](become-an-xrp-ledger-gateway.html#default-ripple)を参照してください。 ## NoRippleを使用する @@ -96,6 +96,6 @@ DefaultRippleフラグは、デフォルトで着信トラストラインでのR - [RippleState（トラストライン）のフラグ](ripplestate.html#ripplestateのフラグ) -{% include '_snippets/rippled-api-links.md' %} -{% include '_snippets/tx-type-links.md' %} +{% include '_snippets/rippled-api-links.md' %} +{% include '_snippets/tx-type-links.md' %} {% include '_snippets/rippled_versions.md' %} diff --git a/content/concepts/issued-currencies/rippling.md b/content/concepts/issued-currencies/rippling.md index b3cf3bf61c..47392d936d 100644 --- a/content/concepts/issued-currencies/rippling.md +++ b/content/concepts/issued-currencies/rippling.md @@ -4,7 +4,7 @@ In the XRP Ledger, "rippling" describes a process of atomic net settlement betwe Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling. -For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [No Ripple Flag](#the-noripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag). +For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [No Ripple Flag](#the-no-ripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag). **Caution:** If you create a trust line to another address, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line. @@ -57,7 +57,7 @@ The **Default Ripple** flag is an account setting that enables rippling on all i The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a [TrustSet transaction][] to change the No Ripple setting of a trust line to match your address's new default. -For more information, see [Default Ripple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#defaultripple). +For more information, see [Default Ripple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#default-ripple). ## Using No Ripple diff --git a/content/concepts/payment-system-basics/accounts/multi-signing.md b/content/concepts/payment-system-basics/accounts/multi-signing.md index 659936179b..dd464b0e1f 100644 --- a/content/concepts/payment-system-basics/accounts/multi-signing.md +++ b/content/concepts/payment-system-basics/accounts/multi-signing.md @@ -19,7 +19,7 @@ The [SignerListSet transaction][] defines which addresses can authorize transact To successfully submit a multi-signed transaction, you must do all of the following: -* The address sending the transaction (specified in the `Account` field) must own a [`SignerList` in the ledger](signerlist.html). +* The address sending the transaction (specified in the `Account` field) must have a [signer list in the ledger](signerlist.html). For instructions on how to do this, see [Set Up Multi-Signing](set-up-multi-signing.html). * The transaction must include the `SigningPubKey` field as an empty string. * The transaction must include a [`Signers` field](transaction-common-fields.html#signers-field) containing an array of signatures. * The signatures present in the `Signers` array must match signers defined in the SignerList. diff --git a/content/concepts/payment-system-basics/accounts/reserves.md b/content/concepts/payment-system-basics/accounts/reserves.md index 1e628db903..8ef5d9d033 100644 --- a/content/concepts/payment-system-basics/accounts/reserves.md +++ b/content/concepts/payment-system-basics/accounts/reserves.md @@ -21,7 +21,7 @@ Many objects in the ledger are owned by a particular address, and count toward t - [Offers](offer.html) are owned by the address that placed them. Transaction processing automatically removes Offers that are fully consumed or found to be unfunded. Alternatively, the owner can cancel an Offer by sending an [OfferCancel transaction][], or by sending an [OfferCreate transaction][] that contains an `OfferSequence` parameter. - [Trust lines](ripplestate.html) are shared between two addresses. The owner reserve can apply to one or both of the addresses, depending on whether the fields that address controls are in their default state. See [Contributing to the Owner Reserve](ripplestate.html#contributing-to-the-owner-reserve) for details. -- Without the [MultiSignReserve amendment][], a single [SignerList](signerlist.html) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. With the [MultiSignReserve amendment][] enabled, a single SignerList counts as 1 object for purposes of the owner reserve, regardless of the number of members it has. See also: [Signer Lists and Reserves](signerlist.html#signerlists-and-reserves). +- Without the [MultiSignReserve amendment][], a single [SignerList](signerlist.html) counts as 3 to 10 objects for purposes of the owner reserve, depending on how many members it has. With the [MultiSignReserve amendment][] enabled, a single SignerList counts as 1 object for purposes of the owner reserve, regardless of the number of members it has. See also: [Signer Lists and Reserves](signerlist.html#signer-lists-and-reserves). - [Held Payments (Escrow)](escrow-object.html) are owned by the address that placed them. - [Payment Channels](use-payment-channels.html) are owned by the address that created them. - [Owner directories](directorynode.html) list all the ledger objects that contribute to an address's owner reserve. However, the owner directory itself does not count towards the reserve. 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 83a1881854..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 [Signer Lists 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][] | 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 90fb0127cf..4a3ec15497 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md @@ -41,9 +41,9 @@ 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 signer list, 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. 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. | +| `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. | -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. +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 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). 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 0cb3c033a3..e47a3b7f86 100644 --- a/content/tutorials/manage-account-settings/offline-account-setup.md +++ b/content/tutorials/manage-account-settings/offline-account-setup.md @@ -139,10 +139,10 @@ 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. -- [Require Auth](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 Transfer Fee](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. diff --git a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md index 13657a9745..a3b383bf64 100644 --- a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md +++ b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md @@ -250,7 +250,7 @@ There are several prerequisites that ACME must meet for this to happen: - ACME can store the funds allocated to the XRP Ledger in a separate bank account. - If ACME is a cryptocurrency exchange, ACME can create a separate wallet to hold the funds allocated to the XRP Ledger, as publicly-verifiable proof to customers that the gateway is solvent. - ACME must control an address in the XRP Ledger. Ripple's best practices recommend using a separate issuing address and operational address. See [Issuing and Operational Addresses](issuing-and-operational-addresses.html) for details. - - ACME must enable the [`DefaultRipple` Flag](#default-ripple) on its issuing address for customers to send and receive its issued currencies. + - ACME must enable the [Default Ripple Flag](#default-ripple) on its issuing address for customers to send and receive its issued currencies. - Alice must create an accounting relationship (trust line) from her XRP Ledger address to ACME's issuing address. She can do this from any XRP Ledger client application as long as she knows ACME's issuing address. - ACME should publicize its issuing address on its website where customers can find it. It can also use an [`xrp-ledger.toml` file](xrp-ledger-toml.html) to publish the issuing address to automated systems. - ACME must create a user interface for Alice to send funds from ACME into the XRP Ledger. From d26223141bcc489e749726a75ac466788c097ec7 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 31 Jul 2020 16:52:35 -0700 Subject: [PATCH 53/65] Rewrite cryptographic keys page significantly for clarity --- content/_img-sources/cryptographic-keys.uxf | 168 ++++++++++++++++++ .../accounts/cryptographic-keys.md | 136 +++++++------- img/cryptographic-keys.svg | 144 +++++++++++++++ 3 files changed, 387 insertions(+), 61 deletions(-) create mode 100644 content/_img-sources/cryptographic-keys.uxf create mode 100644 img/cryptographic-keys.svg diff --git a/content/_img-sources/cryptographic-keys.uxf b/content/_img-sources/cryptographic-keys.uxf new file mode 100644 index 0000000000..42e8c6ca47 --- /dev/null +++ b/content/_img-sources/cryptographic-keys.uxf @@ -0,0 +1,168 @@ + + + 10 + + UMLClass + + 260 + 100 + 120 + 70 + + Seed +-- +(Optional) +16 bytes +lt=. + + + + UMLObject + + 80 + 100 + 140 + 70 + + Passphrase +or source of +randomness +-- +(Optional) +lt=. + + + + Relation + + 210 + 130 + 70 + 30 + + lt=-> + 10.0;10.0;50.0;10.0 + + + UMLClass + + 420 + 100 + 120 + 70 + + Private Key +-- +32 bytes + + + + Relation + + 370 + 130 + 70 + 30 + + lt=-> + 10.0;10.0;50.0;10.0 + + + Relation + + 530 + 130 + 70 + 30 + + lt=-> + 10.0;10.0;50.0;10.0 + + + UMLClass + + 580 + 100 + 120 + 70 + + Public Key +-- +33 bytes + + + + UMLClass + + 740 + 100 + 120 + 70 + + Account ID +-- +20 bytes + + + + Relation + + 690 + 130 + 70 + 30 + + lt=-> + 10.0;10.0;50.0;10.0 + + + UMLNote + + 60 + 60 + 500 + 130 + + Secrets +fg=red + + + + Text + + 580 + 60 + 440 + 30 + + Public information +style=wordwrap +halign=center + + + + UMLClass + + 900 + 100 + 160 + 70 + + Address +-- +24 bytes (classic) +32 bytes (X-address) + + + + Relation + + 850 + 130 + 70 + 30 + + lt=<-> + 10.0;10.0;50.0;10.0 + + diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md index 4c63e4185d..9070d26b74 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md @@ -1,105 +1,120 @@ # Cryptographic Keys -In the XRP Ledger, a digital signature proves that a [transaction](transaction-basics.html) is authorized to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. +In the XRP Ledger, a digital signature _authorizes_ a [transaction](transaction-basics.html) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger. -Every digital signature is based on a cryptographic key pair associated with the transaction's sending account. A key pair may be generated using any of the XRP Ledger's supported [cryptographic signing algorithms](#signing-algorithms). A key pair can be used as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair) or a member of a [signer list](multi-signing.html), regardless of what algorithm was used to generate it. +To make a digital signature, you use a cryptographic key pair associated with the transaction's sending account. A key pair may be generated using any of the XRP Ledger's supported [cryptographic signing algorithms](#signing-algorithms). A key pair can be used as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair) or a member of a [signer list](multi-signing.html), regardless of what algorithm was used to generate it. -**Warning:** It is important to maintain proper security over your secret keys. Digital signatures are the only way of verifying to the XRP Ledger that you are authorized to send a transaction, and there is no privileged administrator who can undo or reverse any transaction that has been applied to the ledger. If someone else knows the secret key of your XRP Ledger account, that person can create digital signatures to authorize any transaction the same as you could. +**Warning:** It is important to maintain proper security over your cryptographic keys. Digital signatures are the only way of authorizing transactions in the XRP Ledger, and there is no privileged administrator who can undo or reverse any transactions after they have applied. If someone else knows the seed or private key of your XRP Ledger account, that person can create digital signatures to authorize any transaction the same as you could. ## Generating Keys -You generate a key pair using the [`wallet_propose`](wallet_propose.html) method. Here's a sample `wallet_propose` response: +There are several ways to create a key pair: -``` -{ - "result": { - "account_id": "rDGnaDqJczDAjrKHKdhGRJh2G7zJfZhj5q", - "key_type": "secp256k1", - "master_key": "COON WARN AWE LUCK TILE WIRE ELI SNUG TO COVE SHAM NAT", - "master_seed": "sstV9YX8k7yTRzxkRFAHmX7EVqMfX", - "master_seed_hex": "559EDD35041D3C11F9BBCED912F4DE6A", - "public_key": "aBQXEw1vZD3guCX3rHL8qy8ooDomdFuxZcWrbRZKZjdDkUoUjGVS", - "public_key_hex": "0351BDFB30E7924993C625687AE6127034C4A5EBA78A01E9C58B0C46E04E3A4948" - }, - "status": "success", - "type": "response" -} -``` +- The [wallet_propose method][] in [the `rippled` server](the-rippled-server.html). +- The [`generateAddress()` method of ripple-lib](rippleapi-reference.html#generateaddress). +- Other [tools or wallet applications](software-ecosystem.html). -The response contains a key pair (a seed and a public key, in various formats) as well as an `account_id`. -**Seed** +## Key Components -A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual secret key (and public key) for an account. The `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](rippled-api.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well. +A cryptographic key pair is a **private key** and a **public key** that are connected mathematically through a key derivation process. Each key is a number; the private key should be chosen using a strong source of randomness. The [cryptographic signing algorithm](#signing-algorithms) defines the key derivation process and sets constraints on the numbers that can be cryptographic keys. -Because the seed value is the basis for all the other information of an account, you must protect it very carefully. Anyone who has knows an address's seed value effectively has full control over that address. +When dealing with the XRP Ledger, you may also use some related values such as a passphrase, seed, account ID, or address. -**Secret Key** +[![Passphrase → Seed → Private Key → Public Key → Account ID ←→ Address](img/cryptographic-keys.svg)](img/cryptographic-keys.svg) +_Figure: A simplified view of the relationship between cryptographic key values._ -The `wallet_propose` response does not explicitly list the secret key value, also called a _private key_. Software that can sign transactions is expected to [derive the secret key](#key-derivation) from the seed value. +The passphrase, seed, and private key are **secrets**: if you know any of these values for an account, you can make valid signatures and you have full control over that account. If you own an account, be **very careful** with your account's secret information. If you don't have it, you can't use your account. If someone else can access it, they can take control of your account. -**Public Key** +The public key, account ID, and address are public information. There are some situations where you might temporarily keep a public key to yourself, but eventually you need to publish it as part of a transaction so that the XRP Ledger can verify the signature and process the transaction. -The `public_key` and `public_key_hex` both represent the same public key value. The public key is derived from the secret key as part of key derivation. The public key makes it possible to verify the authenticity of a transaction signature, but not to create more signatures. +For more technical details of how key derivation works, see [Key Derivation](#key-derivation). -**Account ID** +### Passphrase -The `account_id` is [derived from the public key](accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. Typically, an Account ID is encoded in [base58][] to make a "classic address", but other representations are possible, including hexadecimal. The [X-Address format](accounts.html#addresses) combines an Account ID and a [Destination Tag](source-and-destination-tags.html) into a single address. +You can, optionally, use a passphrase or some other input as a way of choosing a seed or private key. This is less secure than choosing the seed or private key completely at random, but there are some rare cases where you want to do this. (For example, in 2018 "XRPuzzler" gave away XRP to the first person [to solve a puzzle](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/); he used the puzzle's solution as the passphrase to an account holding the prize XRP.) -It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account. +The passphrase is secret information, so you must protect it very carefully. Anyone who knows an address's passphrase has effectively full control over the address. -The `account_id` (without a funded account) can, however, be used as a [regular key](#regular-key-pair) or a [member of a signer list](multi-signing.html) to authorize transactions for another account that does exist. +### Seed -To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](payment.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](reserves.html). +A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual private and public keys for an account. In a [wallet_propose method][] response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](rippled-api.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well. -For more information about the `wallet_propose` response, see [`wallet_propose`](wallet_propose.html). +The seed value is secret information, so you must protect it very carefully. Anyone who has knows an address's seed value has effectively full control over that address. -You can use this generated key pair in one of three ways: as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair), or [signer list member](multi-signing.html). +### Private Key -**Key Type** +The _private key_ is the value that is used to create a digital signature. Most XRP Ledger software does not explicitly show the private key, and [derives the private key](#key-derivation) from the seed value when necessary. It is technically possible to save the private key instead of the seed and use that to sign transactions directly, but this usage is rare. -The field `key_type` indicates what [cryptographic signing algorithm](#signing-algorithms) was used to generate this key pair. You can specify the `key_type` when you make the request to generate a key pair using the [wallet_propose method][]. +Just like the seed, the private key is secret information, so you must protect it very carefully. Anyone who has knows an address's private key has effectively full control over that address. + +### Public Key + +The _public key_ is the value used to verify the authenticity of a digital signature. The public key is derived from the private key as part of key derivation. In a [wallet_propose method][] response, the `public_key` and `public_key_hex` both represent the same public key value. + +Transactions in the XRP Ledger must include the public keys so that the network can verify the transactions' signatures. The public key cannot be used to create valid signatures, so it is safe to share publicly. + + +### Account ID and Address + +The **Account ID** is the core identifier for an [account](accounts.html) or a key pair. It is derived from the public key. In the XRP Ledger protocol, the Account ID is 20 bytes of binary data. Most XRP Ledger APIs represent the Account ID as an address, in one of two formats: + +- A "classic address" writes an Account ID in [base58][] with a checksum. In a [wallet_propose method][] response, this is the `account_id` value. +- An "X-Address" combines an Account ID _and_ a [Destination Tag](source-and-destination-tags.html) and writes the combined value in [base58][] with a checksum. + +The checksum in both formats is there so that small changes result in an invalid address, instead of changing it to refer to a different, but still potentially valid, account. This way, if you make a typo or a transmission error occurs, you don't send money to the wrong place. + +It is important to know that not all Account IDs (or addresses) refer to accounts in the ledger. Deriving keys and addresses is purely a mathematical operation. For an account to have a record in the XRP Ledger, it must [receive a payment of XRP](accounts.html#creating-accounts) that funds its [reserve requirement](reserves.html). An account cannot send any transactions until after it has been funded. + +Even if an Account ID or address does not refer to a funded account, you _can_ use that Account ID or address to represent a [regular key pair](#regular-key-pair) or a [member of a signer list](multi-signing.html). + +### Key Type + +The XRP Ledger supports more than one [cryptographic signing algorithm](#signing-algorithms). Any given key pair is only valid for a specific cryptographic signing algorithm. Some private keys may technically qualify as valid keys for more than one algorithm, but those private keys would have different public keys for each algorithm, and you should not reuse private keys anyway. + +The `key_type` field in the [wallet_propose method][] refers to the cryptographic signing algorithm to use. ## Master Key Pair -The master key pair is composed of a secret key and a public key. In addition to being able to sign all transactions that a regular key pair can, the master key pair's secret key is the only key that can be used to perform the following actions: +The master key pair consists of a private key and a public key. The address of an account is derived from the account's master key pair, so they are [intrinsically related](accounts.html#address-encoding). You cannot change or remove the master key pair, but you can disable it. -* [Disable the master public key](accountset.html). +The [wallet_propose method][] is one way of generating a master key pair. The response from this method shows the account's seed, address, and master public key together. For some other ways of setting up master key pairs, see [Set Up Secure Signing](set-up-secure-signing.html). -* Permanently give up the ability to [freeze](freezes.html#no-freeze). +**Warning:** If a malicious actor learns your master private key (or seed), they have full control over your account, unless your master key pair is disabled. They can take all the money your account holds and do other irreparable harm. Treat your secret values with care! -* Send a cost-0 [key reset transaction](transaction-cost.html#key-reset-transaction). +Because changing a master key pair is impossible, you should treat it with care proportionate to the value it holds. A good practice is to [keep your master key pair offline](offline-account-setup.html) and set up a regular key pair to sign transactions from your account instead. By keeping the master key pair enabled but offline, you can be reasonably certain that no one can get access to it using the internet, but you can still go find it to use in an emergency. -The master key pair for an account is generated in the same [`wallet_propose`](wallet_propose.html) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](accounts.html#address-encoding) to the address, which is derived from the public key. +Keeping your master key pair offline means not putting the secret information (passphrase, seed, or private key) anywhere that malicious actors can get access to it. In general, this means it is not within reach of a computer program that interacts with the internet at large. For example, you could keep it on an air-gapped machine that never connects to the internet, on a piece of paper stored in a safe, or have it completely memorized. (Memorization has some drawbacks, though, including making it impossible to pass they key on after you are dead.) -This is as opposed to a regular key pair, which is also generated using the `wallet_propose` method, but which must be explicitly assigned as a regular key pair to an account. Because a regular key pair is explicitly assigned, it is not intrinsically related to the address of the account it is authorized to sign transactions for. For more information, see [Regular Key Pair](#regular-key-pair). -**Caution:** A master key pair cannot be changed, but it can be disabled. This means that if your master seed or secret key is compromised, rather than change it, you must [disable it](accountset.html). -Because a master key pair cannot be changed and can only be disabled in the event of a compromise, this is a compelling reason to [keep your master key pair offline](offline-account-setup.html) and set up a regular key pair to sign transactions from your account instead. +### Special Permissions -Keeping your master key pair offline means not putting your master secret key anywhere that malicious actors can get access to it. For example, this can mean keeping it on an air-gapped machine that never connects to the internet, on a piece of paper stored in a safe, or in general, not within reach of a computer program that interacts with the internet at large. Ideally, a master key pair is used only on the most trusted of devices and for emergencies only, such as to change a regular key pair in the event of a possible or actual compromise. +**Only** the master key pair can authorize transactions to do certain things: + +- Send an account's very first transaction, because accounts cannot be initialized with + +- Disable the master key pair. (You must set up at least one other method of [authorizing transactions](transaction-basics.html#authorizing-transactions) first.) + +- Permanently give up the ability to [freeze](freezes.html#no-freeze). + +- Send a special [key reset transaction](transaction-cost.html#key-reset-transaction) with a transaction cost of 0 XRP. + +A regular key or [multi-signature](multi-signing.html) can do anything else the same as the master key pair. Notably, after you have disabled the master key pair, you can re-enable it using a regular key pair or multi-signature. You can also [delete an account](accounts.html#deletion-of-accounts) if it meets the requirements for deletion. ## Regular Key Pair -The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions, while keeping your master key pair offline. If the seed or secret key of a regular key pair is compromised, you can remove or replace the key pair without changing the rest of your account. This saves the trouble of re-establishing the account's settings and relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.) +An XRP Ledger account can authorize a secondary key pair, called a _regular key pair_. After doing so, you can use either the [master key pair](#master-key-pair) or the regular key to authorize transactions. You can remove or replace your regular key pair at any time without changing the rest of your account. -You generate a key pair to use as a regular key pair using the [`wallet_propose`](wallet_propose.html) method. However, unlike with a [master key pair](#master-key-pair), which is generated alongside and intrinsically related to the `account_id` of an account it supports, you must explicitly create the relationship between a regular key pair and the account you want it to sign transactions for. You use the [`SetRegularKey`](setregularkey.html) method to assign a regular key pair to an account. +A regular key pair can authorize most of the same types of transactions as the master key pair, with [certain exceptions](#special-permissions). For example, a regular key pair _can_ authorize a transaction to change the regular key pair. -For a tutorial on assigning a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html). +A good security practice is to save your master private key somewhere offline, and use a regular key pair most of the time. As a precaution, you can change the regular key pair regularly. If a malicious user learns your regular private key, you can get the master key pair out of offline storage and use it to change or remove the regular key pair. This way, you can regain control of your account. Even if you are not fast enough to stop the malicious user from stealing your money, at least you don't need to move to a new account and re-create all your settings and relationships from scratch. -After you assign a regular key pair to an account, the account has two key pairs associated with it: +Regular key pairs have the same format as master key pairs. You generate them the same way (for example, using the [wallet_propose method][]). The only difference is that a regular key pair is not intrinsically tied to the account it signs transactions for. It is possible (but not a good idea) to use the master key pair from one account as the regular key pair for another account. -* A master key pair that is intrinsically related to the account's `account_id` and which you should keep offline. -* A regular key pair that you've explicitly assigned to the account and which you use to sign transactions for the account. - -You can assign one regular key pair to an account and use it to sign all transactions, except for the ones reserved for the [master key pair](#master-key-pair). - -You can remove or change a regular key pair at any time. This means that if a regular secret key is compromised (but the master secret key is not), you can regain control of your account by removing or changing the regular key pair. - -For a tutorial on changing or removing a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html). +The [SetRegularKey transaction][] assigns or changes the regular key pair for an account. For a tutorial on assigning or changing a regular key pair, see [Assign a Regular Key Pair](assign-a-regular-key-pair.html). ## Signing Algorithms @@ -110,18 +125,17 @@ The XRP Ledger supports the following cryptographic signing algorithms: | Key Type | Algorithm | Description | |-------------|-----------|---| -| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) using the elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | This is the scheme used in Bitcoin. The XRP Ledger uses these key types by default. | -| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) using the elliptic curve [Ed25519](https://ed25519.cr.yp.to/) | This is a newer algorithm which has better performance and other convenient properties. Since Ed25519 public keys are one byte shorter than secp256k1 keys, `rippled` prefixes Ed25519 public keys with the byte `0xED` so both types of public key are 33 bytes. | +| `secp256k1` | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) using the elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | This is the same scheme Bitcoin uses. The XRP Ledger uses these key types by default. | +| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) using the elliptic curve [Ed25519](https://ed25519.cr.yp.to/) | This is a newer algorithm which has better performance and other convenient properties. Since Ed25519 public keys are one byte shorter than secp256k1 keys, `rippled` prefixes Ed25519 public keys with the byte `0xED` so both types of public key are 33 bytes. | When you generate a key pair with the [wallet_propose method][], you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions. The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs. -**Note:** Currently, you cannot sign [payment channel claims](use-payment-channels.html) with Ed25519 keys. This is a bug. ### Future Algorithms -In the future, it is likely that the XRP Ledger will need new cryptographic signing algorithms to keep up with developments in cryptography. For example, if quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, XRP Ledger developers can add a cryptographic signing algorithm that isn't easily broken. As of early 2020, there's no clear first choice "quantum-resistant" signing algorithm and quantum computers are not yet practical enough to be a threat, so there are no immediate plans to add any specific algorithms. +In the future, it is likely that the XRP Ledger will need new cryptographic signing algorithms to keep up with developments in cryptography. For example, if quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, XRP Ledger developers can add a cryptographic signing algorithm that isn't easily broken. As of mid 2020, there's no clear first choice "quantum-resistant" signing algorithm and quantum computers are not yet practical enough to be a threat, so there are no immediate plans to add any specific algorithms. ## Key Derivation diff --git a/img/cryptographic-keys.svg b/img/cryptographic-keys.svg new file mode 100644 index 0000000000..73b9b73edc --- /dev/null +++ b/img/cryptographic-keys.svg @@ -0,0 +1,144 @@ + + +Address24 bytes (classic)32 bytes (X-address)Public informationSecretsAccount ID20 bytesPublic Key33 bytesPrivate Key32 bytesPassphraseor source ofrandomness(Optional)Seed(Optional)16 bytes From d22c0432df7dd6809d1fd6a98e04724f1872bed2 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 31 Jul 2020 16:53:14 -0700 Subject: [PATCH 54/65] Style edits to FAQ and overview --- content/concepts/introduction/technical-faq.md | 16 +++++++++------- .../concepts/introduction/xrp-ledger-overview.md | 6 +++--- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/content/concepts/introduction/technical-faq.md b/content/concepts/introduction/technical-faq.md index bb5cc7fe1a..d29cabc70c 100644 --- a/content/concepts/introduction/technical-faq.md +++ b/content/concepts/introduction/technical-faq.md @@ -5,7 +5,7 @@ #### What service do transaction validators provide? -Validators determine if transactions meet protocol requirements, and are therefore “valid.” The service validators uniquely provide is grouping transactions into ordered units, agreeing on one such ordering specifically to prevent double spending. +Validators determine if transactions meet protocol requirements, and are therefore “valid.” The service validators uniquely provide is grouping transactions into ordered units, agreeing on one such ordering specifically to prevent double spending. See [Consensus](consensus.html) and the [Ripple Labs Tech Talk: Understanding Consensus](https://ripple.com/insights/ripple-labs-tech-talk-consensus-within-the-ripple-protocol/) for more information about the consensus process. @@ -17,7 +17,7 @@ Running a validator does not require any fees or XRP. It is comparable in cost t #### What are Unique Node Lists (UNLs)? -They are the lists of transaction validators a given participant believes will not conspire to defraud them. +They are the lists of transaction validators a given participant believes will not conspire to defraud them. #### Which UNL should I select? @@ -37,18 +37,18 @@ The primary incentive to run a validator is to preserve and protect the stable o If you run an XRP Ledger server to participate in the network, the additional cost and effort to run a validator is minimal. This means that additional incentives, such as the mining rewards in Bitcoin, are not necessary. Ripple avoids paying XRP as a reward for operating a validator so that such incentives do not warp the behavior of validators. -#### Can financial institutions set up transaction validators that will help them meet specific institutional standards and requirements? +#### Can financial institutions set up transaction validators to help them meet specific institutional standards and requirements? -No, institutions cannot set up customized validator policies for choosing to allow some transactions and reject others. Validators either follow the protocol, or they do not. If software does not follow protocol rules, it will not function. Thus, it is not recommended that institutions seek out custom implementations without in-house expertise. +No, institutions cannot set up customized validator policies for choosing to allow some transactions and reject others. Validators either follow the protocol, or they do not. If software does not follow protocol rules, it does not function. Thus, it is not recommended that institutions seek out custom implementations without in-house expertise. -#### What will happen if more than 20% of nodes within the network do not agree with the majority? How is the final version of the ledger chosen? +#### What happens if more than 20% of nodes within the network do not agree with the majority? How is the final version of the ledger chosen? The network may temporarily halt to reconfigure itself to continue with the new UNL list based on those that want to reach consensus. This temporary processing delay is desired rather than double spending. -In the process of determining the final, authoritative version of the ledger, there may be multiple temporary internal versions. Such internal versions will happen in distributed systems because not all nodes will receive transactions in the same order. The analogous behavior in Bitcoin is where two servers each see a different longest chain because two blocks were mined at about the same time. +In the process of determining the final, authoritative version of the ledger, there may be multiple temporary internal versions. Such internal versions naturally happen in distributed systems because not all nodes receive transactions in the same order. The analogous behavior in Bitcoin is where two servers each see a different longest chain because two blocks were mined at about the same time. -However, there will only be one authoritative ledger version at any given time; other versions are irrelevant and harmless. +However, there can be only one latest _validated_ ledger version at any given time; other versions are irrelevant and harmless. #### Does the XRP Ledger have a formal process for adding validators? @@ -73,6 +73,8 @@ The XRP Ledger is designed to set the transaction cost dynamically based on dema #### What is Ripple standard operating procedure regarding money laundering and suspicious economic activity? + + Ripple is committed to monitoring and reporting any AML flags across the XRP Ledger network, as well as reporting suspicious activity to FinCEN as applicable. diff --git a/content/concepts/introduction/xrp-ledger-overview.md b/content/concepts/introduction/xrp-ledger-overview.md index 8c3e5acebc..b694f73665 100644 --- a/content/concepts/introduction/xrp-ledger-overview.md +++ b/content/concepts/introduction/xrp-ledger-overview.md @@ -1,14 +1,14 @@ # XRP Ledger Overview -The **XRP Ledger** is a decentralized cryptographic ledger powered by a network of peer-to-peer servers. The XRP Ledger is the home of **XRP**, a digital asset designed to bridge the many different currencies in use worldwide. Ripple stewards the development of the XRP Ledger, and advances XRP as a key contribution to the _Internet of Value_: a world in which money moves the way information does today. +The **XRP Ledger** is an online system for payments, powered by a community without a central leader. Anyone can connect their computer to the peer-to-peer network that manages the ledger. The XRP Ledger is the home of **XRP**, a digital asset designed to bridge the world's many currencies. The XRP Ledger is one part of the developing _Internet of Value_: a world in which money moves the way information does today. ## The Digital Asset for Payments XRP is a digital asset native to the XRP Ledger. Anyone with a cryptographic key and an internet connection can receive, hold, and send XRP to anyone else. XRP's creators have developed it to be a desirable bridge currency that can enable trades in any other currency. XRP has many properties which make it an appealing asset for many other use cases, too: - **[Censorship-Resistant Transaction Processing][]:** No single party decides which XRP transactions succeed or fail, and no one can "roll back" a transaction after it completes. As long as those who choose to participate in the network keep it healthy, they can send and receive XRP in seconds. -- **[Fast, Efficient Consensus Algorithm][]:** The XRP Ledger's consensus algorithm settles transactions in 4 to 5 seconds, processing at a throughput of up to 1500 transactions per second. These properties put XRP at least an order of magnitude ahead of other top digital assets. -- **[Finite XRP Supply][]:** When the XRP Ledger began, 100 billion XRP were created, and no more XRP will ever be created. (Each XRP is divisible down to 6 decimal places, for a grand total of 100 quadrillion (10^17) _drops_ of XRP.) The available supply of XRP decreases slowly over time as small amounts are destroyed to pay transaction costs. +- **[Fast, Efficient Consensus Algorithm][]:** The XRP Ledger's consensus algorithm settles transactions in 4 to 5 seconds, and can process up to 1500 transactions per second. These properties put XRP far ahead of other top digital assets. +- **[Finite XRP Supply][]:** When the XRP Ledger began, 100 billion XRP were created, and no more XRP will ever be created. (Each XRP is divisible down to 6 decimal places, for a grand total of 100 quadrillion (10^17) _drops_ of XRP.) The available supply of XRP decreases slowly over time as small amounts are destroyed to pay transaction costs. - **[Responsible Software Governance][]:** A team of full-time, world-class developers at Ripple maintain and continually improve the XRP Ledger's underlying software. Ripple acts as a steward for the technology and an advocate for its interests, and builds constructive relationships with governments and financial institutions worldwide. - **[Secure, Adaptable Cryptography][]:** The XRP Ledger relies on industry standard digital signature systems like ECDSA (the same scheme used by Bitcoin) but also supports modern, efficient algorithms like Ed25519. The extensible nature of the XRP Ledger's software makes it possible to add and disable algorithms as the state of the art in cryptography advances. - **[Modern Features for Smart Contracts][]:** Features like Escrow, Checks, and Payment Channels support cutting-edge financial applications including the [Interledger Protocol](https://interledger.org/). This toolbox of advanced features comes with safety features like a process for amending the network and separate checks against invariant constraints. From 5a3fe46002f6095d216cb8232e387fabcb9c3128 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 3 Aug 2020 10:21:27 -0700 Subject: [PATCH 55/65] Exempt new link from checker --- dactyl-config.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dactyl-config.yml b/dactyl-config.yml index 8e52a742a4..6f583a60ef 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -6312,6 +6312,8 @@ known_broken_links: # even though they still work in browser: - https://web.archive.org/web/20161007113240/https://wiki.ripple.com/Ripple.txt - http://web.archive.org/web/20171211225452/https://forum.ripple.com/viewtopic.php?f=2&t=3613 + # Another failure that works fine in a browser: + - https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/ # Style Checker Config ------------------------------------------------------ # From b70d24dfa1a8762b0d128658643b84b6d18c6986 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 3 Aug 2020 15:13:26 -0700 Subject: [PATCH 56/65] Add link compression tutorial --- .../enable-link-compression.md | 52 +++++++++++++++++++ .../installation/capacity-planning.md | 13 ++++- dactyl-config.yml | 12 ++--- 3 files changed, 70 insertions(+), 7 deletions(-) create mode 100644 content/tutorials/manage-the-rippled-server/configure-peering/enable-link-compression.md 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..a55dac8444 --- /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. The server uses uncompressed communications with peers who do not have have link compression enabled or do not support link compression. [New in: rippled 1.6.0][] + +## Steps + +To enable link compression on your server, complete the following steps: + +### 1. Edit your `rippled`'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/installation/capacity-planning.md b/content/tutorials/manage-the-rippled-server/installation/capacity-planning.md index 5252c636ce..1907a441ef 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. @@ -181,7 +189,7 @@ Any enterprise or carrier-class data center should have substantial network band During exceptionally high periods of transaction volume, some operators have reported that their `rippled` servers have completely saturated a 100MBit/s network link. Therefore, a gigabit network interface is required for reliable performance. -Here are examples of observed network bandwidth use for common `rippled` tasks: +Here are examples of observed uncompressed network bandwidth use for common `rippled` tasks: | Task | Transmit/Receive | |:------------------------------------------------|:---------------------------| @@ -190,6 +198,9 @@ Here are examples of observed network bandwidth use for common `rippled` tasks: | Serve historical ledger and transaction reports | 100Mbps transmit | | Start up `rippled` | 20Mbps 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 - **Concepts:** diff --git a/dactyl-config.yml b/dactyl-config.yml index 72976a7918..9aa8b79ea9 100644 --- a/dactyl-config.yml +++ b/dactyl-config.yml @@ -2248,12 +2248,6 @@ pages: - ja - md: tutorials/manage-the-rippled-server/installation/capacity-planning.md - 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. targets: - en @@ -2568,6 +2562,12 @@ pages: targets: - ja + # TODO: translate this page including the blurb in its frontmatter. + - md: tutorials/manage-the-rippled-server/configure-peering/enable-link-compression.md + targets: + - en + - ja + - md: tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.md html: forward-ports-for-peering.html funnel: Docs From 3f68eed017235475c93e486f2db520ed4888beca Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Tue, 4 Aug 2020 18:39:16 -0700 Subject: [PATCH 57/65] FlowCross enabled --- .../concepts/consensus-network/amendments/known-amendments.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md index e1d4faa8e3..0107078d3f 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.md +++ b/content/concepts/consensus-network/amendments/known-amendments.md @@ -14,7 +14,7 @@ The following is a comprehensive list of all known amendments and their status o | [fixAmendmentMajorityCalc][] | v1.6.0-b8 | [In Development: TBD]( "BADGE_LIGHTGREY") | | [HardenedValidations][] | v1.6.0-b5 | [In Development: TBD]( "BADGE_LIGHTGREY") | | [fix1781][] | v1.6.0-b1 | [In Development: TBD]( "BADGE_LIGHTGREY") | -| [FlowCross][] | v0.70.0 | [Open for Voting: TBD](https://xrpl.org/blog/2017/rippled-0.70.0.html "BADGE_80d0e0") | +| [FlowCross][] | v0.70.0 | [Enabled: 2020-08-04](https://xrpcharts.ripple.com/#/transactions/44C4B040448D89B6C5A5DEC97C17FEDC2E590BA094BC7DB63B7FDC888B9ED78F "BADGE_GREEN") | | [fixQualityUpperBound][] | v1.5.0 | [Enabled: 2020-07-09](https://xrpcharts.ripple.com/#/transactions/5F8E9E9B175BB7B95F529BEFE3C84253E78DAF6076078EC450A480C861F6889E "BADGE_GREEN") | | [RequireFullyCanonicalSig][] | v1.5.0 | [Enabled: 2020-07-03](https://xrpcharts.ripple.com/#/transactions/94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3 "BADGE_GREEN") | | [Checks][] | v0.90.0 | [Enabled: 2020-06-18](https://xrpcharts.ripple.com/#/transactions/D88F2DCDFB10023F9F6CBA8DF34C18E321D655CAC8FDB962387A5DB1540242A6 "BADGE_GREEN") | @@ -452,7 +452,7 @@ The Flow Engine also makes it easier to improve and expand the payment engine wi | Amendment ID | Status | |:-----------------------------------------------------------------|:----------| -| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | Open for Voting | +| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | Enabled | Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. Uses the updated code from the [Flow](#flow) amendment to power offer crossing, so [OfferCreate transactions][] and [Payment transactions][] share more code. This has subtle differences in how offers are processed: From 5b0125b1f3fb715ac63d44531200e44fbc475d9e Mon Sep 17 00:00:00 2001 From: Edward Hennis Date: Wed, 5 Aug 2020 13:04:44 -0400 Subject: [PATCH 58/65] Fix some typos in the Validator List Method page --- content/references/rippled-api/validator-list.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/content/references/rippled-api/validator-list.md b/content/references/rippled-api/validator-list.md index f4575d9ee4..25adcebc5a 100644 --- a/content/references/rippled-api/validator-list.md +++ b/content/references/rippled-api/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 @@ -67,8 +68,9 @@ If you decode the `blob` from base64, the result is a JSON object with the follo | `Field` | Value | Description | |:-------------|:-------|:-----------------------------------------------------| | `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. | +| `expiration` | Number | The time this list expires, in [seconds since +the Ripple Epoch][]. | +| `validators` | Array | A list of recommended validators. | Each member of the `validators` array has the following fields: @@ -99,7 +101,7 @@ GET https://localhost:51235/vl *cURL* ``` -curl --insecure https://localhost:51235/vl +curl --insecure https://localhost:51235/vl/ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 ``` From 920e39a8a4dfdaed1ba65cadd769938b1cca1135 Mon Sep 17 00:00:00 2001 From: Edward Hennis Date: Wed, 5 Aug 2020 18:16:11 -0400 Subject: [PATCH 59/65] [FOLD] Fix hard-wrap --- content/references/rippled-api/validator-list.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/references/rippled-api/validator-list.md b/content/references/rippled-api/validator-list.md index 25adcebc5a..b01ee83a28 100644 --- a/content/references/rippled-api/validator-list.md +++ b/content/references/rippled-api/validator-list.md @@ -68,9 +68,8 @@ If you decode the `blob` from base64, the result is a JSON object with the follo | `Field` | Value | Description | |:-------------|:-------|:-----------------------------------------------------| | `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. | +| `expiration` | Number | The time this list expires, in [seconds since the Ripple Epoch][]. | +| `validators` | Array | A list of recommended validators. | Each member of the `validators` array has the following fields: From 53f949db97f880158bb09d673ea6042e7bbcc80c Mon Sep 17 00:00:00 2001 From: rmurphy23 Date: Thu, 6 Aug 2020 11:37:48 -0700 Subject: [PATCH 60/65] Changes snippet from ledger_data specific to general format --- content/_snippets/no-cli-syntax.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/_snippets/no-cli-syntax.md b/content/_snippets/no-cli-syntax.md index ffc65eb98a..a776a6cf79 100644 --- a/content/_snippets/no-cli-syntax.md +++ b/content/_snippets/no-cli-syntax.md @@ -1 +1 @@ -**Note:** There is no commandline syntax for `ledger_data`. You can use the [json method][] to access this method from the commandline instead. \ No newline at end of file +**Note:** There is no commandline syntax for this method. You can use the [json method][] to access this method from the commandline instead. \ No newline at end of file From 8eb2b2f5f1d4971722c90e4bab36b23f265db0e4 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 10 Aug 2020 15:55:55 -0700 Subject: [PATCH 61/65] Update Devnet connection instructions to use UNL --- ...ect-your-rippled-to-the-xrp-test-net.ja.md | 65 ++++--- ...onnect-your-rippled-to-the-xrp-test-net.md | 169 ++++++++++++------ 2 files changed, 143 insertions(+), 91 deletions(-) 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..ffc96e52a7 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] + 021B0DE76CED20C8B341086D8F4C8AB3D62657C6EDE19395461B197223D6271CA5 + 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 df457c3712..43d79900b6 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 @@ -4,98 +4,153 @@ Ripple hosts [alternative test and development networks](parallel-networks.html) **Note:** The XRP Testnet and Devnet ledger and balances are reset on a regular basis. -To connect your `rippled` server to the XRP Testnet or Devnet, set the following configurations: +## Steps -1. Edit your `rippled.cfg` file to connect to a hub server in the network you want to connect to. +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. - 1. To connect to the [Testnet](xrp-testnet-faucet.html), uncomment or add the following section: +## 1. Configure your server to connect to the right hub. - [ips] - s.altnet.rippletest.net 51235 +Edit your `rippled.cfg` file. - 2. To connect to the [Devnet](xrp-testnet-faucet.html), uncomment or add the following section: +{% include '_snippets/conf-file-location.md' %} + - [ips] - s.devnet.rippletest.net 51235 +1. Set an `[ips]` stanza with the hub for the network you want to connect to: - 3. Comment out the existing `[ips]` stanza: + - # [ips] - # r.ripple.com 51235 + *Testnet* + + [ips] + s.altnet.rippletest.net 51235 + + *Devnet* + + [ips] + s.devnet.rippletest.net 51235 + + *Mainnet* + + # No [ips] stanza. Use the default hubs to connect to Mainnet. +3. Comment out the previous `[ips]` stanza, if there is one: -2. Edit your `validators.txt` file. + # [ips] + # r.ripple.com 51235 + # zaphod.alloy.ee 51235 + # sahyadri.isrdc.in 51235 - - To connect to the Testnet: +## 2. Set your trusted validator list. - 1. Uncomment the following sections: +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. - [validator_list_sites] - https://vl.altnet.rippletest.net +1. Uncomment or add the `[validator_list_sites]` and `[validator_list_keys]` stanzas for the network you want to connect to: - [validator_list_keys] - ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 + - 1. Comment out the following sections, as follows: + *Testnet* - # [validator_list_sites] - # https://vl.ripple.com - # - # [validator_list_keys] - # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 + [validator_list_sites] + https://vl.altnet.rippletest.net - - To connect to the Devnet: + [validator_list_keys] + ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 - 1. Comment out the following sections: + *Devnet* - # [validator_list_sites] - # https://vl.altnet.rippletest.net + [validator_list_sites] + https://vl.devnet.rippletest.net/index.json - # [validator_list_keys] - # ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 - - # [validator_list_sites] - # https://vl.ripple.com - # - # [validator_list_keys] - # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 - - 2. Add the following trusted validators to the `validator.txt` file: - - # Hard-coded List of Devnet Validators - [validators] - n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c - n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B - n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD - n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U - n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd - n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC - n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS + [validator_list_keys] + 021B0DE76CED20C8B341086D8F4C8AB3D62657C6EDE19395461B197223D6271CA5 -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). + [validator_list_sites] + https://vl.ripple.com - The following command checks the latest validated ledger of a Testnet server at `s.altnet.rippletest.net`: + [validator_list_keys] + ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 - $ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq + - The following command checks the latest validated ledger of a Devnet server at `s.devnet.rippletest.net`: +1. Comment out any previous `[validator_list_sites]`, `[validator_list_keys]`, or `[validators]` stanzas. - $ ./rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq + For example: - The following command checks your local `rippled`'s latest validated ledger index: + # [validator_list_sites] + # https://vl.ripple.com + # + # [validator_list_keys] + # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 + + # Old hard-coded List of Devnet Validators + # [validators] + # n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c + # n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B + # n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD + # n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U + # n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd + # n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC + # n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS + +## 3. Restart the server. + +``` +$ sudo systemctl restart rippled +``` + +## 4. Verify that your server syncs. + +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. + +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). + +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 +``` + + +*Mainnet* + +```sh +# s1.ripple.com +$ rippled --rpc_ip 34.201.59.230: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. - $ ./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) From d7f3e9cd9ebeea2de2c7075630b2170e77c5ba93 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 10 Aug 2020 16:42:59 -0700 Subject: [PATCH 62/65] Use Devnet master public key, remove tabs chars --- .../connect-your-rippled-to-the-xrp-test-net.ja.md | 2 +- .../connect-your-rippled-to-the-xrp-test-net.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) 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 ffc96e52a7..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 @@ -67,7 +67,7 @@ Rippleは[代替となるテスト用および開発用ネットワーク](paral https://vl.devnet.rippletest.net/index.json [validator_list_keys] - 021B0DE76CED20C8B341086D8F4C8AB3D62657C6EDE19395461B197223D6271CA5 + EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12 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 43d79900b6..5a19950693 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 @@ -68,11 +68,11 @@ Edit your `validators.txt` file. This file is located in the same folder as your *Mainnet* - [validator_list_sites] - https://vl.ripple.com + [validator_list_sites] + https://vl.ripple.com - [validator_list_keys] - ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 + [validator_list_keys] + EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12 From cecbfe8d3ff812168b214359862a691827a1bacb Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Mon, 10 Aug 2020 17:39:53 -0700 Subject: [PATCH 63/65] Devnet instructions: fix key mixup --- .../connect-your-rippled-to-the-xrp-test-net.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 5a19950693..59c9db80fb 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 @@ -60,10 +60,10 @@ Edit your `validators.txt` file. This file is located in the same folder as your *Devnet* [validator_list_sites] - https://vl.devnet.rippletest.net/index.json + https://vl.devnet.rippletest.net [validator_list_keys] - 021B0DE76CED20C8B341086D8F4C8AB3D62657C6EDE19395461B197223D6271CA5 + EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12 *Mainnet* @@ -72,7 +72,7 @@ Edit your `validators.txt` file. This file is located in the same folder as your https://vl.ripple.com [validator_list_keys] - EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12 + ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734 From 61e252aa019788ef454bd7b48d909315df964b64 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 12 Aug 2020 00:28:21 -0700 Subject: [PATCH 64/65] Link compression: edit per review --- .../configure-peering/enable-link-compression.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 index a55dac8444..def56fb0c2 100644 --- 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 @@ -8,13 +8,13 @@ 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. The server uses uncompressed communications with peers who do not have have link compression enabled or do not support link compression. [New in: rippled 1.6.0][] +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`'s config file. +### 1. Edit your `rippled` server's config file. ```sh $ vim /etc/opt/ripple/rippled.cfg From b3cdb02909bb96f91bccc6f4875e2db4902a24cf Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Wed, 19 Aug 2020 09:21:59 -0700 Subject: [PATCH 65/65] Update version-setting commit example --- .../installation/build-run-rippled-ubuntu.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) 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 aacd7f0d79..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,12 +87,12 @@ 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.6.0 - Set version to 1.4.0