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

[Merge] branch 'gh-pages' of https://github.com/ripple/ripple-dev-portal into gh-pages

Browse Source
This commit is contained in:
mDuo13
2015-02-02 10:48:42 -08:00
parent baf7a0b9a3 0c0c220056
commit d604e0911f
7 changed files with 800 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
content/exchange_to_gateway.md
View File

@@ -121,7 +121,7 @@ There are several prerequisites that ACME must meet in order for this to happen:
- ACME modifies its core accounting system to track money that is backing funds issued on the Ripple Network. This could be as simple as adding a record for Ripple.
- Optionally, a gateway can take additional steps to separate normal user funds from funds backing the gateway's Ripple issuances. For example, a cryptocurrency exchange can create a separate wallet to hold the funds allocated to Ripple. This provides publicly-verifiable proof to customers that the gateway is solvent.
- ACME must have a Ripple account. Our best practices recommend actually having at least two accounts: a "cold wallet" account to issue currency, and one or more "hot wallet" accounts that perform day-to-day transactions. See [Hot and Cold Wallets](#hot-and-cold-wallets) for more information.
- Alice must create a trustline from her Ripple address to ACME's issuing (cold wallet) account. She can do this from any Ripple client (such as [Ripple Trade](https://www.rippletrade.com/) as long as she knows ACME's account address or Ripple Name.
- Alice must create a trustline from her Ripple account to ACME's issuing (cold wallet) account. She can do this from any Ripple client (such as [Ripple Trade](https://www.rippletrade.com/) as long as she knows the address or Ripple Name of ACME's cold wallet.
- ACME must create a user interface for Alice to send funds from ACME into Ripple.
- In order to do this, ACME needs to know Alice's Ripple address. ACME can have Alice input her Ripple addresss as part of the interface, or ACME can require Alice to input and verify her Ripple address in advance.
@@ -140,12 +140,12 @@ An example of a withdrawal flow:
In addition to the [requirements for making deposits possible](#deposit-requirements), there are several prerequisites that ACME must meet in order to process payments coming from Ripple:
- ACME must monitor its Ripple accounts for incoming payments.
- ACME must recognize the identities of users from the incoming payments.
- ACME must know which user to credit internally for the incoming payments.
- We recommend that ACME should [bounce any unrecognized incoming payments](#bouncing-payments) back to their sender.
- Typically, the preferred method of recognizing incoming payments is through [destination tags](#destination-tags).
### Precautions ###
## Precautions ##
Processing payments to and from Ripple naturally comes with some risks, so a gateway should be sure to take care in implementing these processes. We recommend the following precautions:
@@ -153,7 +153,7 @@ Processing payments to and from Ripple naturally comes with some risks, so a gat
- Before processing a payment out of Ripple, make sure you know the customer's identity. This is especially important because the users sending money from Ripple could be different than the ones that initially received the money in Ripple.
- Follow the guidelines for [reliable transaction submission](#reliable-transaction-submission) when sending Ripple transactions.
- [Robustly monitor for incoming payments](#robustly-monitor-for-payments), and read the correct amount. Don't be deceived by Partial Payments.
- Track your obligations and balances within the Ripple network, and compare with your assets off the network. If they do not match up, pause processing withdrawals and deposits until you resolve the discrepancy. (<span class='draft-comment'>TODO: Link to tallying bulletin when it comes out</span>)
- Track your obligations and balances within the Ripple network, and compare with your assets off the network. If they do not match up, stop processing withdrawals and deposits until you resolve the discrepancy. (<span class='draft-comment'>TODO: Link to tallying bulletin when it comes out</span>)
- Proactively avoid ambiguous situations. We recommend the following:
- Enable the [`DisallowXRP` flag](#disallowxrp) for the cold wallet account and all hot wallet accounts, so users do not accidentally send you XRP.
- Enable the [`RequireDest` flag](#requiredest) for the cold wallet account and all hot wallet accounts, so users do not accidentally forget the destination tag on payments to make withdrawals.
@@ -163,15 +163,17 @@ Processing payments to and from Ripple naturally comes with some risks, so a gat
After the issuances have been created in Ripple, they can be freely transferred and traded by Ripple users. There are several consequences of this situation:
- Anyone can buy/sell EUR@ACME on Ripple, if they create a trust line to ACME's issuing account first. If ACME issues multiple currencies on Ripple, a separate trust line is necessary for each.
- Anyone can buy/sell EUR@ACME on Ripple. If ACME issues multiple currencies on Ripple, a separate trust line is necessary for each.
- This includes users who do not have an account with ACME Exchange. In order to withdraw the funds successfully from ACME, users still have to create ACME accounts.
- Optionally, use the [Authorized Accounts](#authorized-accounts) feature to limit who can hold EUR@ACME on Ripple.
- Ripple users trading and sending EUR@ACME to one another requires no intervention by ACME.
- All exchanges and balances on Ripple are publicly viewable in the shared, global ledger.
## Market Makers ##
Exchanging EUR@ACME for other currencies within Ripple requires market makers who are willing to exchange other Ripple issuances for EUR@ACME. Market makers are just Ripple accounts with trust lines for EUR@ACME as well as other currencies or issuers, who create orders (called "offers" in the Ripple ledger) to exchange currency. The cost of exchanging EUR@ACME for another currency depends on the quantity and quality of orders.
To facilitate exchanging currency, ACME may decide to become its own market maker. For various reasons, we recommend using a separate Ripple account for trading.
To facilitate exchanging currency, ACME may decide to become its own market maker. For various reasons, we recommend using a separate Ripple account for trading. Because market making can result in financial losses, gateways that choose to act as market makers should not use customer funds for market making.
The following diagram depicts a simple Ripple payment sending 2EUR@ACME from Alice to Charlie. Note that ACME's balance sheet and holdings do not change:
@@ -195,7 +197,7 @@ To use the Authorized Accounts feature, a gateway first enables the `RequireAuth
You must authorize trust lines using the same cold wallet account that issues the currency, which unfortunately means an increased risk exposure for that account. The process for sending funds into Ripple with RequireAuth enabled looks like the following:
1. ACME publishes its cold wallet address to users.
1. ACME publishes the address of its cold wallet to users.
2. Alice extends a trust line from her Ripple account to ACME's cold wallet, indicating that she is willing to hold ACME's issuances.
3. ACME's cold wallet sends a transaction authorizing Alice's trust line.

603
content/historical_data.md Normal file
View File

@@ -0,0 +1,603 @@
rippled Historical Database
==========================
The `rippled` Historical Database provides access to raw Ripple transactions that are stored in a database. This provides an alternative to querying `rippled` itself for transactions that occurred in older ledgers, so that the `rippled` server can maintain fewer historical ledger versions and use fewer server resources.
Ripple Labs provides a live instance of the `rippled` Historical Database API with as complete a transaction record as possible at the following address:
`history.ripple.com`
You can also [install and run your own instance of the Historical Database](#running-the-historical-database).
# Usage #
The `rippled` Historical Database provides a REST API, currently with only one API method:
## Get Account Transaction History ##
[[Source]<br>](https://github.com/ripple/rippled-historical-database/blob/8dc88fc5a9de5f6bd12dd3589b586872fe283ad3/api/routes/accountTx.js "Source")
Retrieve a history of transactions that affected a specific account. This includes all transactions the account sent, payments the account received, and payments that rippled through the account.
<div class='multicode'>
*REST*
```
GET /v1/accounts/{:address}/transactions
```
</div>
The following URL parameters are required by this API endpoint:
| Field | Value | Description |
|-------|-------|-------------|
| account | String | The Ripple account address of the account |
Optionally, you can also include the following query parameters:
| Field | Value | Description |
|-------|-------|-------------|
| type | Single transaction type or comma-separated list of types | Filter results to include only transactions with the specified transaction type or types. Valid types include `OfferCreate`, `OfferCancel`, `Payment`, `TrustSet`, `AccountSet`, and `TicketCreate`. |
| result | Transaction result code | Filter results to only transactions with the specified transaction result code. Valid result codes include `tesSUCCESS` and all [tec codes](transactions.html#tec-codes). |
| start | ISO 8601-format date (YYYY-MM-DDThh:mmZ) | Only retrieve transactions occurring on or after the specified date and time. |
| end | ISO 8601-format date (YYYY-MM-DDThh:mmZ) | Only retrieve transactions occurring on or before the specified date and time. |
| ledger_min | Integer | Sequence number of the earliest ledger to search. |
| ledger_max | Integer | Sequence number of the most recent ledger to search. |
| limit | Integer | Number of transactions to return. Defaults to 20. |
| offset | Integer | Start getting results after skipping this many. Used for paginating results. |
| descending | Boolean | Whether to order transactions with the most recent first. Defaults to true. |
| binary | Boolean | If true, retrieve transactions as hex-formatted binary blobs instead of parsed JSON objects. Defaults to false. |
#### Example ####
Request:
```
GET http://history.ripple.com/v1/accounts/r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59/transactions?limit=2&type=OfferCreate
```
Response:
```js
200 OK
{
"result": "success",
"count": 2,
"transactions": [
{
"tx": {
"TransactionType": "OfferCreate",
"Flags": 131072,
"Sequence": 159244,
"TakerPays": {
"value": "0.001567373",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"TakerGets": "146348921",
"Fee": "64",
"SigningPubKey": "02279DDA900BC53575FC5DFA217113A5B21C1ACB2BB2AEFDD60EA478A074E9E264",
"TxnSignature": "3045022100D81FFECC36A3DEF0922EB5D16F1AA5AA0804C30A18ED3B512093A75E87C81AD602206B221E22A4E3158785C109E7508624AD3DE5C0E06108D34FA709FCC9575C9441",
"Account": "r2d2iZiCcJmNL6vhUGFjs8U8BuUq6BnmT",
"hash": "03EDF724397D2DEE70E49D512AECD619E9EA536BE6CFD48ED167AE2596055C9A",
"ledger_index": 8317037,
"executed_time": 1408047740,
"date": 461362940
},
"meta": {
"TransactionIndex": 0,
"AffectedNodes": [
{
"ModifiedNode": {
"LedgerEntryType": "AccountRoot",
"PreviousTxnLgrSeq": 8317036,
"PreviousTxnID": "A56793D47925BED682BFF754806121E3C0281E63C24B62ADF7078EF86CC2AA53",
"LedgerIndex": "2880A9B4FB90A306B576C2D532BFE390AB3904642647DCF739492AA244EF46D1",
"PreviousFields": {
"Balance": "275716601760"
},
"FinalFields": {
"Flags": 0,
"Sequence": 326323,
"OwnerCount": 27,
"Balance": "275862935331",
"Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw",
"RegularKey": "rfYqosNivHQFJ6KpArouxoci3QE3huKNYe"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "AccountRoot",
"PreviousTxnLgrSeq": 8317030,
"PreviousTxnID": "F8E33A40A481F037BA788231421737AF2AD13161928B15A14F6ABC5007D6A2B7",
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
"PreviousFields": {
"OwnerCount": 18,
"Balance": "213169802117"
},
"FinalFields": {
"Flags": 0,
"Sequence": 1405,
"OwnerCount": 17,
"Balance": "213169802799",
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "Offer",
"PreviousTxnLgrSeq": 8317036,
"PreviousTxnID": "B7256723E74A38A17C9F4F5CB938BD45581C57767E44BF26DAC8BA9FF2D58021",
"LedgerIndex": "55D0954D7C190006BF905D3B3D269A07016CB9F97B1E37ABE7CC8275DBBDE3DA",
"PreviousFields": {
"TakerPays": "8016312417",
"TakerGets": {
"value": "0.085862",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
}
},
"FinalFields": {
"Flags": 0,
"Sequence": 326320,
"Expiration": 461364125,
"BookNode": "0",
"OwnerNode": "3",
"BookDirectory": "7B73A610A009249B0CC0D4311E8BA7927B5A34D86634581C5F212B4AE944DDE4",
"TakerPays": "7869978846",
"TakerGets": {
"value": "0.084294634308",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"Account": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "RippleState",
"PreviousTxnLgrSeq": 8317014,
"PreviousTxnID": "AB356934159ECD02D27089C0AA97EF2B3DA4B3A5A3A9EC522474CADDF276B307",
"LedgerIndex": "5DC222A1BAF75AE489F9C78F772AEF6AF00C66660B4C28D93DC05FF4A4124D27",
"PreviousFields": {
"Balance": {
"value": "-2.254933867206176",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
}
},
"FinalFields": {
"Flags": 2228224,
"LowNode": "221",
"HighNode": "0",
"Balance": {
"value": "-2.253363366782792",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
},
"LowLimit": {
"value": "0",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"HighLimit": {
"value": "1000",
"currency": "BTC",
"issuer": "rfCFLzNJYvvnoGHWQYACmJpTgkLUaugLEw"
}
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "RippleState",
"PreviousTxnLgrSeq": 8317030,
"PreviousTxnID": "F8E33A40A481F037BA788231421737AF2AD13161928B15A14F6ABC5007D6A2B7",
"LedgerIndex": "767C12AF647CDF5FEB9019B37018748A79C50EDAF87E8D4C7F39F78AA7CA9765",
"PreviousFields": {
"Balance": {
"value": "-0.000000007322616",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
}
},
"FinalFields": {
"Flags": 131072,
"LowNode": "43",
"HighNode": "0",
"Balance": {
"value": "0",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
},
"LowLimit": {
"value": "0",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"HighLimit": {
"value": "3",
"currency": "BTC",
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
}
},
{
"DeletedNode": {
"LedgerEntryType": "DirectoryNode",
"LedgerIndex": "7B73A610A009249B0CC0D4311E8BA7927B5A34D86634581C5F211CEE1E0697A0",
"FinalFields": {
"Flags": 0,
"ExchangeRate": "5F211CEE1E0697A0",
"RootIndex": "7B73A610A009249B0CC0D4311E8BA7927B5A34D86634581C5F211CEE1E0697A0",
"TakerPaysCurrency": "0000000000000000000000000000000000000000",
"TakerPaysIssuer": "0000000000000000000000000000000000000000",
"TakerGetsCurrency": "0000000000000000000000004254430000000000",
"TakerGetsIssuer": "0A20B3C85F482532A9578DBB3950B85CA06594D1"
}
}
},
{
"DeletedNode": {
"LedgerEntryType": "Offer",
"LedgerIndex": "AF3C702057C9C47DB9E809FD8C76CD22521012C5CC7AE95D914EC9E226F1D7E5",
"PreviousFields": {
"TakerPays": "182677152",
"TakerGets": {
"value": "0.001959953669835",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
}
},
"FinalFields": {
"Flags": 131072,
"Sequence": 1404,
"PreviousTxnLgrSeq": 8317030,
"BookNode": "0",
"OwnerNode": "0",
"PreviousTxnID": "F8E33A40A481F037BA788231421737AF2AD13161928B15A14F6ABC5007D6A2B7",
"BookDirectory": "7B73A610A009249B0CC0D4311E8BA7927B5A34D86634581C5F211CEE1E0697A0",
"TakerPays": "182676470",
"TakerGets": {
"value": "0.001959946361835",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "AccountRoot",
"PreviousTxnLgrSeq": 8317036,
"PreviousTxnID": "049D5872010AE9144F8FE6A8A92937B6A21C065C2FA9A0233C9CAB7F5485ADC5",
"LedgerIndex": "B4C12A5134DCFE012CCC035F62D5903179DE5CABE74B228D84C7E4905BECC032",
"PreviousFields": {
"Sequence": 159244,
"Balance": "201007563226"
},
"FinalFields": {
"Flags": 0,
"Sequence": 159245,
"OwnerCount": 19,
"Balance": "200861228909",
"Account": "r2d2iZiCcJmNL6vhUGFjs8U8BuUq6BnmT"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "RippleState",
"PreviousTxnLgrSeq": 8317036,
"PreviousTxnID": "03229A664FF41A8767818DC8B236E59279078BB33C440996CB0A0093F213C173",
"LedgerIndex": "F16445094C00CD3A38CE7851BD6ECA77CA2F281019BE800AB984CDF57D2F2631",
"PreviousFields": {
"Balance": {
"value": "0",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
}
},
"FinalFields": {
"Flags": 1114112,
"LowNode": "0",
"HighNode": "233",
"Balance": {
"value": "0.001567373",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
},
"LowLimit": {
"value": "0",
"currency": "BTC",
"issuer": "r2d2iZiCcJmNL6vhUGFjs8U8BuUq6BnmT"
},
"HighLimit": {
"value": "0",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
}
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "DirectoryNode",
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
"FinalFields": {
"Flags": 0,
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
"Owner": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
}
],
"TransactionResult": "tesSUCCESS"
}
},
{
"tx": {
"TransactionType": "OfferCreate",
"Flags": 0,
"Sequence": 236535,
"LastLedgerSequence": 8317038,
"TakerPays": {
"value": "0.39545282",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"TakerGets": "36865488056",
"Fee": "20",
"SigningPubKey": "0382A086DB113581E08E439546156D7F34B68F11D70914B65F63A98A36AF9845DC",
"TxnSignature": "3045022100AB584255CDA4500BD82B5EA7CBB5ABB706DF657976F79187985209DDEB05C6290220365B67073797D3D4265B6E28ACC7DB7CE4EF3DF9DDB9B62ABE8078F0BF039414",
"Account": "rJnZ4YHCUsHvQu7R6mZohevKJDHFzVD6Zr",
"hash": "F8E33A40A481F037BA788231421737AF2AD13161928B15A14F6ABC5007D6A2B7",
"ledger_index": 8317030,
"executed_time": 1408047700,
"date": 461362900
},
"meta": {
"TransactionIndex": 7,
"AffectedNodes": [
{
"ModifiedNode": {
"LedgerEntryType": "AccountRoot",
"PreviousTxnLgrSeq": 8317030,
"PreviousTxnID": "F49ED1ACC968759EF5DA9745B08A4E47D5EA44E614AE61EE1B3CED50E1218C17",
"LedgerIndex": "2B9A35D51B6BABE4F386AA3C36866BDE72E14BFC917A95C6B81F5B079F1656A3",
"PreviousFields": {
"Sequence": 236535,
"Balance": "1035793050836"
},
"FinalFields": {
"Flags": 0,
"Sequence": 236536,
"OwnerCount": 30,
"Balance": "998934936914",
"Account": "rJnZ4YHCUsHvQu7R6mZohevKJDHFzVD6Zr"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "AccountRoot",
"PreviousTxnLgrSeq": 8317027,
"PreviousTxnID": "D92EBF936C4DEB2B99B7194C98F78A42B998E0B2C357400F139A3DA717AF8737",
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
"PreviousFields": {
"Balance": "176311688215"
},
"FinalFields": {
"Flags": 0,
"Sequence": 1405,
"OwnerCount": 18,
"Balance": "213169802117",
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "RippleState",
"PreviousTxnLgrSeq": 8317027,
"PreviousTxnID": "D92EBF936C4DEB2B99B7194C98F78A42B998E0B2C357400F139A3DA717AF8737",
"LedgerIndex": "767C12AF647CDF5FEB9019B37018748A79C50EDAF87E8D4C7F39F78AA7CA9765",
"PreviousFields": {
"Balance": {
"value": "-0.396243732962616",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
}
},
"FinalFields": {
"Flags": 131072,
"LowNode": "43",
"HighNode": "0",
"Balance": {
"value": "-0.000000007322616",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
},
"LowLimit": {
"value": "0",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"HighLimit": {
"value": "3",
"currency": "BTC",
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "Offer",
"PreviousTxnLgrSeq": 8317027,
"PreviousTxnID": "D92EBF936C4DEB2B99B7194C98F78A42B998E0B2C357400F139A3DA717AF8737",
"LedgerIndex": "AF3C702057C9C47DB9E809FD8C76CD22521012C5CC7AE95D914EC9E226F1D7E5",
"PreviousFields": {
"TakerPays": "37040791054",
"TakerGets": {
"value": "0.397412773669835",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
}
},
"FinalFields": {
"Flags": 131072,
"Sequence": 1404,
"BookNode": "0",
"OwnerNode": "0",
"BookDirectory": "7B73A610A009249B0CC0D4311E8BA7927B5A34D86634581C5F211CEE1E0697A0",
"TakerPays": "182677152",
"TakerGets": {
"value": "0.001959953669835",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
}
},
{
"ModifiedNode": {
"LedgerEntryType": "RippleState",
"PreviousTxnLgrSeq": 8317027,
"PreviousTxnID": "D92EBF936C4DEB2B99B7194C98F78A42B998E0B2C357400F139A3DA717AF8737",
"LedgerIndex": "CA152527E0627E8BB24C80D0D7D9CC515376D4D5416437F7C3687CA506901D83",
"PreviousFields": {
"Balance": {
"value": "-8.454143459263425",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
}
},
"FinalFields": {
"Flags": 2228224,
"LowNode": "230",
"HighNode": "0",
"Balance": {
"value": "-8.849596279263425",
"currency": "BTC",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji"
},
"LowLimit": {
"value": "0",
"currency": "BTC",
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"
},
"HighLimit": {
"value": "0",
"currency": "BTC",
"issuer": "rJnZ4YHCUsHvQu7R6mZohevKJDHFzVD6Zr"
}
}
}
}
],
"TransactionResult": "tesSUCCESS"
}
}
]
}
```
# Running the Historical Database #
You can also run your own instance of the Historical Database software, and populate it with transactions from your own `rippled` instance. This is useful if you do not want to depend on Ripple Labs to operate the historical database indefinitely, or you want access to historical transactions from within your own intranet.
## Installation ##
### Dependencies ###
The Historical Database requires the following software installed first:
* [PostgreSQL](http://www.postgresql.org/) (recommended), [HBase](http://hbase.apache.org/), or [CouchDB](http://couchdb.apache.org/).
* [Node.js](http://nodejs.org/)
* [npm](https://www.npmjs.org/)
* [git](http://git-scm.com/)
### Installation Process ###
1. Clone the rippled Historical Database Git Repository:
`git clone https://github.com/ripple/rippled-historical-database.git`
2. Use npm to install additional modules:
`cd rippled-historical-database`
`npm install`
3. Create a new postgres database:
`createdb ripple_historical` in PostgreSQL
4. Load the latest database schema for the rippled Historical Database:
`node_modules/knex/lib/bin/cli.js migrate:latest`
5. Create configuration files (and modify as necessary):
`cp config/api.config.json.example config/api.config.json`
At this point, the rippled Historical Database is installed. See [Services](#services) for the different components that you can run.
### Services ###
The `rippled` Historical Database consists of several processes that can be run separately.
* [Live Ledger Importer](#live-ledger-importer) - Monitors `rippled` for newly-validated ledgers.
`node import/live`
* [Backfiller](#backfiller) - Populates the database with older ledgers from a `rippled` instance.
`node import/postgres/backfill`
* API Server - Provides [REST API access](#usage) to the data.
`npm start` (restarts the server automatically when source files change),
or `node api/server.js` (simple start)
# Importing Data #
In order to retrieve data from the `rippled` Historical Database, you must first populate it with data. Broadly speaking, there are two ways this can happen:
* Connect to a `rippled` server that has the historical ledgers, and retrieve them. (Later, you can reconfigure the `rippled` server not to maintain history older than what you have in your Historical Database.)
* You can choose to retrieve only new ledgers as they are validated, or you can retrieve old ledgers, too.
* Or, you can load a dump from a database that already has the historical ledger data. (At this time, there are no publicly-available database dumps of historical data.) Use the standard process for your database.
In all cases, keep in mind that the integrity of the data is only as good as the original source. If you retrieve data from a public server, you are assuming that the operator of that server is trustworthy. If you load from a database dump, you are assuming that the provider of the dump has not corrupted or tampered with the data.
## Live Ledger Importer ##
The Live Ledger Importer is a service that connects to a `rippled` server using the WebSocket API, and listens for ledger close events. Each time a new ledger is closed, the Importer requests the latest validated ledger. Although this process has some fault tolerance built in to prevent ledgers from being skipped, it is still possible that the Importer may miss ledgers.
The Live Ledger Importer includes a secondary process that runs periodically to validate the data already imported and check for gaps in the ledger history.
The Live Ledger Importer can import to one or more different data stores concurrently. If you have configured the historical database to use another storage scheme, you can use the `--type` parameter to specify the database type or types to use. If not specified, the `rippled` Historical Database defaults to PostgreSQL.
Here are some examples:
```
// defaults to PostgreSQL:
$ node import/live
// Use HBase instead:
$ node import/live --type hbase
// Use PostgreSQL and CouchDB simultaneously:
$ node import/live --type postgres,couchdb
```
## Backfiller ##
The Backfiller retrieves old ledgers from a `rippled` instance by moving backwards in time. You can optionally provide start and stop indexes to retrieve a specific range of ledgers, by their sequence number.
The `--startIndex` parameter defines the most-recent ledger to retrieve. The Backfiller retrieves this ledger first and then continues retrieving progressively older ledgers. If this parameter is omitted, the Backfiller begins with the newest validated ledger.
The `--stopIndex` parameter defines the oldest ledger to retrieve. The Backfiller stops after it retrieves this ledger. If omitted, the Backfiller continues as far back as possible. Because backfilling goes from most recent to least recent, the stop index should be a smaller than the start index.
Here are some examples:
```
// retrieve everything to PostgreSQL
node import/postgres/backfill
// get ledgers #1,000,000 to #2,000,000 (inclusive) and store in CouchDB
node import/couchdb/backfill --startIndex 2000000 --stopIndex 1000000
```

171
content/rippled.md
View File

@@ -141,6 +141,7 @@ rippled -- account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
#### Example Successful Response ####
<div class='multicode'>
*WebSocket*
```
{
@@ -205,6 +206,7 @@ HTTP Status: 200 OK
}
}
```
</div>
The fields of a successful response include:
@@ -224,6 +226,7 @@ It is impossible to enumerate all the possible ways an error can occur. Some may
Some example errors:
<div class='multicode'>
*WebSocket*
```
{
@@ -273,6 +276,7 @@ HTTP Status: 200 OK
}
}
```
</div>
#### WebSocket API Error Response Format ####
@@ -465,6 +469,7 @@ The `wallet_accounts` command is deprecated and may be removed without further n
Additionally, this page contains an explanation of the following important admin-only command:
* [`can_delete` - Allow online deletion of ledgers up to a specific ledger.](#can-delete)
* [`wallet_propose` - Generate keys for a new account](#wallet-propose)
For information about other Admin Commands, consult [the old wiki documentation](https://ripple.com/wiki/JSON_Messages).
@@ -489,6 +494,7 @@ The `account_info` command retrieves information about an account, its activity,
An example of an account_info request:
<div class='multicode'>
*WebSocket*
```
{
@@ -519,6 +525,7 @@ An example of an account_info request:
#Syntax: account_info account [ledger_index|ledger_hash] [strict]
rippled -- account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 true
```
</div>
[Try it! >](ripple-api-tool.html#account_info)
@@ -539,6 +546,7 @@ The following fields are deprecated and should not be provided: `ident`, `accoun
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -561,6 +569,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with the result containing the requested account, its data, and a ledger to which it applies, as the following fields:
@@ -599,6 +608,7 @@ The `account_lines` method returns information about the account's lines of trus
An example of the request format:
<div class='multicode'>
*WebSocket*
```
@@ -646,6 +656,7 @@ The following parameters are deprecated and may be removed without further notic
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -982,6 +993,7 @@ The `account_offers` method retrieves a list of offers made by a given account t
An example of the request format:
<div class='multicode'>
*WebSocket*
```
@@ -1013,6 +1025,7 @@ An example of the request format:
#Syntax: account_offers account [ledger_index]
rippled -- account_offers r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 current
```
</div>
[Try it! >](ripple-api-tool.html#account_offers)
@@ -1035,6 +1048,7 @@ The following parameter is deprecated and may be removed without further notice:
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
@@ -1115,6 +1129,7 @@ The `account_tx` method retrieves a list of transactions that involved the speci
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -1155,6 +1170,7 @@ An example of the request format:
#Syntax account_tx account [ledger_index_min [ledger_index_max [limit]]] [binary] [count] [forward]
rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1 2 false false false
```
</div>
[Try it! >](ripple-api-tool.html#account_tx)
@@ -1187,6 +1203,7 @@ However, in the time between requests, things may change so that `"ledger_index_
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -1698,6 +1715,72 @@ this is the part where we plug our ears and don't acknowledge that you can provi
* `noGenDecrypt`
-->
## can_delete ##
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/CanDelete.cpp "Source")
With `online_delete` and `advisory_delete` configuration options enabled,
the `can_delete` method informs the rippled server of the latest ledger
which may be deleted.
#### Request Format ####
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
"id": 2,
"command": "can_delete",
"can_delete": 11320417
}
```
*JSON-RPC*
```
{
"method": "can_delete",
"params": [
{
"can_delete": 11320417
}
]
}
```
*Commandline*
```
#Syntax can_delete [<ledger_index>|<ledger_hash>|now|always|never]
rippled -- can_delete 11320417
```
</div>
The request includes the following optional parameter:
| Field | Type | Description |
|-------|------|-------------|
| can_delete | String or Integer | The maximum ledger to allow to be deleted. For `ledger_index` or `ledger_hash`, see [Specifying a Ledger](#specifying-a-ledger-instance). `never` sets the value to 0, and effectively disables online deletion until another `can_delete` is appropriately called. `always` sets the value to the maximum possible ledger (4294967295), and online deletion will occur as of each configured `online_delete` interval. `now` triggers online deletion at the next validated ledger that meets or exceeds the configured `online_delete` interval, but no further. |
If no parameter is specified, no change is made.
The response follows the [standard format](#response-formatting), with
a successful result containing the following fields:
| Field | Type | Description |
|-------|------|-------------|
| can_delete | Integer | The maximum ledger index that may be removed by the online deletion routine. |
Use this command with no parameter to query the existing `can_delete` setting.
#### Possible Errors ####
* Any of the [universal error types](#universal-errors).
* `notEnabled` - Not enabled in configuration.
* `notReady` - Not ready to handle this request.
* `lgrNotFound` - Ledger not found.
* `invalidParams` - Invalid parameters.
## wallet_propose ##
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/WalletPropose.cpp "Source")
@@ -1711,6 +1794,7 @@ Use the `wallet_propose` method to generate the keys needed for a new account. T
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -1749,6 +1833,7 @@ The request can contain the following parameter:
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -1763,6 +1848,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing various important information about the new account, including the following fields:
@@ -1798,6 +1884,7 @@ Retrieve information about the public ledger.
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -1831,6 +1918,7 @@ An example of the request format:
#Syntax: ledger ledger_index|ledger_hash [full]
rippled -- ledger current false
```
</div>
[Try it! >](ripple-api-tool.html#ledger)
@@ -1853,6 +1941,7 @@ The `ledger` field is deprecated and may be removed without further notice.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -1895,6 +1984,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing information about the ledger, including the following fields:
@@ -1933,6 +2023,7 @@ The `ledger_closed` method returns the unique identifiers of the most recently c
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -1956,6 +2047,7 @@ An example of the request format:
#Syntax: ledger_closed
rippled -- ledger_closed
```
</div>
[Try it! >](ripple-api-tool.html#ledger_closed)
@@ -1966,6 +2058,7 @@ This method accepts no parameters.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -1990,6 +2083,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -2014,6 +2108,7 @@ The `ledger_current` method returns the unique identifiers of the current in-pro
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -2037,6 +2132,7 @@ An example of the request format:
#Syntax: ledger_current
rippled -- ledger_current
```
</div>
[Try it! >](ripple-api-tool.html#ledger_current)
@@ -2048,6 +2144,7 @@ The request contains no parameters.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -2070,6 +2167,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following field:
@@ -2094,6 +2192,7 @@ The `ledger_data` method retrieves contents of the specified ledger. You can ite
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -2118,6 +2217,7 @@ An example of the request format:
]
}
```
</div>
__*Note:*__ There is no commandline syntax for `ledger_data`. You can use the [`json` command](#json) to access this method from the commandline instead.
@@ -2139,6 +2239,7 @@ The `ledger` field is deprecated and may be removed without further notice.
An example of a successful response:
<div class='multicode'>
*WebSocket (binary:true)*
```
{
@@ -2307,6 +2408,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -2344,6 +2446,7 @@ The `ledger_entry` method returns a single entry from the specified ledger. See
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -2368,6 +2471,7 @@ An example of the request format:
]
}
```
</div>
[Try it! >](ripple-api-tool.html#ledger_entry)
@@ -2408,6 +2512,7 @@ The `generator` and `ledger` parameters are deprecated and may be removed withou
An example of a successful response:
<div class='multicode'>
*WebSocket*
```{
"id": 3,
@@ -2454,6 +2559,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -2490,6 +2596,7 @@ The `tx` method retrieves information on a single transaction.
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -2516,6 +2623,7 @@ An example of the request format:
#Syntax: tx transaction [binary]
tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 false
```
</div>
[Try it! >](ripple-api-tool.html#tx)
@@ -2531,6 +2639,7 @@ The request includes the following parameters:
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -2657,6 +2766,7 @@ An example of a successful response:
"type": "response"
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the fields of the [Transaction object](transactions.html) as well as the following additional fields:
@@ -2688,6 +2798,7 @@ The `transaction_entry` method retrieves information on a single transaction fro
An example of the request format:
<div class='multicode'>
*WebSocket*
```
@@ -2719,6 +2830,7 @@ An example of the request format:
#Syntax: transaction_entry transaction_hash ledger_index|ledger_hash
rippled -- transaction_entry E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 348734
```
</div>
[Try it! >](ripple-api-tool.html#transaction_entry)
@@ -2737,6 +2849,7 @@ __*Note:*__ This method does not support retrieving information from the current
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -2865,6 +2978,7 @@ An example of a successful response:
"type": "response"
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -2904,6 +3018,7 @@ __*Caution:*__ This method is deprecated, and may be removed without further not
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -2930,6 +3045,7 @@ An example of the request format:
#Syntax: tx_history [start]
rippled -- tx_history 0
```
</div>
[Try it! >](ripple-api-tool.html#tx_history)
@@ -2945,6 +3061,7 @@ The request includes the following parameters:
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -3762,6 +3879,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -3804,6 +3922,7 @@ A client can only have one pathfinding request open at a time. If another pathfi
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -3819,6 +3938,7 @@ An example of the request format:
}
}
```
</div>
[Try it! >](ripple-api-tool.html#path_find)
@@ -3839,6 +3959,7 @@ The server also recognizes the following fields, but the results of using them a
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -4204,6 +4325,7 @@ An example of a successful response:
}
}
```
</div>
The initial response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -4236,6 +4358,7 @@ In addition to the initial response, the server sends more messages in a similar
Here is an example of an asychronous follow-up from a path_find create request:
<div class='multicode'>
*WebSocket*
```
{
@@ -5076,6 +5199,7 @@ Here is an example of an asychronous follow-up from a path_find create request:
"source_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
```
</div>
### path_find close ###
@@ -5087,6 +5211,7 @@ The `close` subcommand of `path_find` instructs the server to stop sending infor
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -5095,6 +5220,7 @@ An example of the request format:
"subcommand": "close"
}
```
</div>
The request includes the following parameters:
@@ -5123,6 +5249,7 @@ The `status` subcommand of `path_find` requests an immediate update about the cl
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -5131,6 +5258,7 @@ An example of the request format:
"subcommand": "status"
}
```
</div>
The request includes the following parameters:
@@ -5162,6 +5290,7 @@ Although the `rippled` server attempts to find the cheapest path or combination
An example of the request format:
<div class='multicode'>
*WebSocket*
```
@@ -5219,6 +5348,7 @@ An example of the request format:
#Syntax ripple_path_find json ledger_index|ledger_hash
rippled -- ripple_path_find '{"source_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", "source_currencies": [ { "currency": "XRP" }, { "currency": "USD" } ], "destination_account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", "destination_amount": { "value": "0.001", "currency": "USD", "issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B" } }'
```
</div>
[Try it! >](ripple-api-tool.html#ripple_path_find)
@@ -5239,6 +5369,7 @@ The request includes the following parameters:
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
@@ -5455,6 +5586,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -5500,6 +5632,7 @@ __*Note:*__ It is possible and preferable to sign a transaction without connecti
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -5548,6 +5681,7 @@ An example of the request format:
#Syntax: sign secret tx_json [offline]
rippled -- sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", "Amount": { "currency": "USD", "value": "1", "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" }}' false
```
</div>
[Try it! >](ripple-api-tool.html#sign)
@@ -5573,6 +5707,7 @@ The server automatically attempts to fill in certain fields from the `tx_json` o
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -5627,6 +5762,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -5676,6 +5812,7 @@ A submit-only request includes the following parameters:
<div class='multicode'>
*WebSocket*
```
{
@@ -5702,6 +5839,7 @@ A submit-only request includes the following parameters:
#Syntax: submit tx_blob
submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754
```
</div>
[Try it! >](ripple-api-tool.html#submit)
@@ -5726,6 +5864,7 @@ See the [sign command](#sign) for detailed information on how the server automat
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -5772,6 +5911,7 @@ An example of the request format:
#Syntax: submit secret json [offline]
submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"rJYMACXJd1eejwzZA53VncYmiK2kZSBxyD", "Amount":"200000000","Destination":"r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV" }'
```
</div>
[Try it! >](ripple-api-tool.html#submit)
@@ -5781,6 +5921,7 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -5840,6 +5981,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -5883,6 +6025,7 @@ The `book_offers` method retrieves a list of offers, also known as the [order bo
An example of the request format:
<div class='multicode'>
*WebSocket*
```
@@ -5928,6 +6071,7 @@ An example of the request format:
#Syntax: book_offers taker_pays taker_gets [taker [ledger [limit] ] ]
rippled -- book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'
```
</div>
[Try it! >](ripple-api-tool.html#book_offers)
@@ -5951,6 +6095,7 @@ Normally, offers that are not funded are omitted; however, offers made by the sp
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -6023,6 +6168,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following fields:
@@ -6071,6 +6217,7 @@ The `subscribe` method requests periodic notifications from the server when cert
An example of the request format:
<div class='multicode'>
*WebSocket - accounts*
```
{
@@ -6097,6 +6244,7 @@ An example of the request format:
]
}
```
</div>
[Try it! >](ripple-api-tool.html#subscribe)
@@ -6138,6 +6286,7 @@ The field `proof` is reserved for future use.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -6147,6 +6296,7 @@ An example of a successful response:
"result": {}
}
```
</div>
The response follows the [standard format](#response-formatting). The fields contained in the response vary depending on what subscriptions were included in the request.
@@ -6345,6 +6495,7 @@ The `unsubscribe` command tells the server to stop sending messages for a partic
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -6367,6 +6518,7 @@ An example of the request format:
]
}
```
</div>
[Try it! >](ripple-api-tool.html#unsubscribe)
@@ -6394,6 +6546,7 @@ The objects in the `books` array are defined almost like the ones from subscribe
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -6403,6 +6556,7 @@ An example of a successful response:
"type": "response"
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing no fields.
@@ -6438,6 +6592,7 @@ The `server_info` command asks the server for a human-readable version of variou
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -6455,6 +6610,7 @@ An example of the request format:
]
}
```
</div>
[Try it! >](ripple-api-tool.html#server_info)
@@ -6465,6 +6621,7 @@ The request does not takes any parameters.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -6531,6 +6688,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing an `info` object as its only field.
@@ -6578,6 +6736,7 @@ The `server_state` command asks the server for various machine-readable informat
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -6595,6 +6754,7 @@ An example of the request format:
]
}
```
</div>
[Try it! >](ripple-api-tool.html#server_state)
@@ -6605,6 +6765,7 @@ The request does not takes any parameters.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
@@ -6722,6 +6883,7 @@ The `ping` command returns an acknowledgement, so that clients can test the conn
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -6745,6 +6907,7 @@ An example of the request format:
#Syntax: ping
rippled -- ping
```
</div>
[Try it! >](ripple-api-tool.html#ping)
@@ -6756,6 +6919,7 @@ The request includes no parameters.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -6775,6 +6939,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.
@@ -6793,6 +6958,7 @@ The `random` command provides a random number to be used as a source of entropy
An example of the request format:
<div class='multicode'>
*WebSocket*
```
{
@@ -6816,6 +6982,7 @@ An example of the request format:
#Syntax: random
rippled -- random
```
</div>
The request includes no parameters.
@@ -6824,6 +6991,7 @@ The request includes no parameters.
An example of a successful response:
<div class='multicode'>
*WebSocket*
```
{
@@ -6846,6 +7014,7 @@ An example of a successful response:
}
}
```
</div>
The response follows the [standard format](#response-formatting), with a successful result containing the following field:
@@ -6868,11 +7037,13 @@ The `json` method is a proxy to running other commands, and accepts the paramete
An example of the request format:
<div class='multicode'>
*Commandline*
```
# Syntax: json method json_stanza
rippled -q -- json ledger_closed '{}'
```
</div>
#### Response Format ####

6
js/api-ripple.min.js vendored
View File

File diff suppressed because one or more lines are too long

7
js/apitool-websocket.js
View File

@@ -253,13 +253,13 @@
});
Request('submit', {
secret: 'sssssssssssssssssssssssssssss',
secret: 'sn3nxiW7v8KXzPzAqzyHXbSSKNuN9',
tx_json: {
Flags: 0,
TransactionType: 'AccountSet',
Account: 'rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn',
Sequence: void(0),
Fee: '15',
Fee: '10000',
Flags: 0
},
_description: 'Submits a transaction to the network.',
@@ -278,8 +278,9 @@
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
}
},
secret : "sssssssssssssssssssssssssssss",
secret : "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
offline: false,
fee_mult_max: 1000,
_description: 'Sends a transaction to be signed by the server.',
_link: 'rippled-apis.html#sign',
_takes_secret: true

12
js/ripple-0.11.0-min.js vendored Normal file
View File

File diff suppressed because one or more lines are too long

2
ripple-api-tool.html
View File

@@ -195,7 +195,7 @@
<script type='text/javascript' src='js/es5-shim.js'></script>
<script src='vendor/codemirror.min.js'></script>
<script type='text/javascript' src='js/cm-javascript.min.js'></script>
<script type='text/javascript' src='js/api-ripple.min.js'></script>
<script type='text/javascript' src='js/ripple-0.11.0-min.js'></script>
<script type='text/javascript' src='js/apitool-websocket.js'></script>