CoinTracking analyze all your trades and generates in real time tons of useful information such as the profit / loss of your trades,the value of your coins, balances, realized and unrealized gains, reports for tax declaration, and much more.With the current and historical prices for all 4542 existing currencies, you will get the complete overview.Sign up now and never lose track again!Click here for a Live Demo Login Username Password forgot password 30,766 Interactive charts for trades and coins Calculation of key indicators Profit / loss, coin value & balances Realized and unrealized gains List of all trades and fees Grouping by exchange Interactive search Comment function Capital Gains Report FIFO, LIFO, HIFO and LOFO calculation Prepared for accountants and tax office Variable parameters for all countries Easy CSV import from 26 exchanges Automatic import via APIs Export in Excel, PDF, CSV, XML & JSON Direct synchronization with the blockchain History charts to all 4542 coins Always the latest prices for all coins Top Coins by trades and by volume Experimental Bitcoin forecasts Complete documentation Email reports on request SSL certified & encrypted No access to your exchanges required Import your data from many exchanges and wallets References "CoinTracking is a comprehensive feature rich finance, tax, accounting and strategic planning crypto dashboard" Kirk Phillips, CPA, CMA, CFE, CBP, DCC,Author of "The Ultimate Bitcoin Business Guide" "No more Excel sheets, no more headache.

CoinTracking is the best analysis software and tax tool for Bitcoins.""We want only the best for our customers.offizielle bitcoin appBeing partners with cointracking.info helps us to provide better services and products for our users, and we think that Cointracking is a must for any Bitcoin trader!"armory bitcoin open sourceDavide Barbieri, Founder and CTO of The Rock Trading Ltd "I like CoinTracking very much, because I get a clear representation of my trades.bitcoin asic group buyWith the automatic import function I don't even have to lift a finger to do so."bitcoin private key brute"CoinTracking is an active participant in the Bitcoin community and quick to support its customers on online forums..."reddit bitcoin china ban

"If you don't want to keep your own log, use software like CoinTracking.Info."litecoin pln"CoinTracking is the epitome of convenience.No other Bitcoin service will save as much time and money.""The name CoinTracking does exactly what it says.With a wide range of supported cryptocurrencies – including bitcoin, Ethereum, Ripple, and thousands of others – filling in those tax forms becomes very straightforward."The Ripple Data API v2 provides access to information about changes in the Ripple Consensus Ledger, including transaction history and processed analytical data.This information is stored in a dedicated database, which frees rippled servers to keep fewer historical ledger versions.Ripple provides a live instance of the Data API with as complete a transaction record as possible at the following address: The Ripple Data API v2 replaces the Historical Database v1 and the Charts API.The Data API v2 provides a REST API with the following methods: Retrieve a specific Ledger by hash, index, date, or latest validated.

This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve a any validations recorded for a specific ledger hash.This dataset includes ledger versions that are outside the validated ledger chain.(New in v2.2.0) Note: The Data API does not have a comprehensive record of all validations.The response only includes data that the Data API has recorded.Some ledger versions, especially older ledgers, may have no validations even if they were validated by consensus.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve a validation vote recorded for a specific ledger hash by a specific validator.This method requires the following URL parameters: This request takes no query parameters.

A successful response uses the HTTP code 200 OK and has a JSON body containing a Validation Object with the following additional field: Retrieve a specific transaction by its identifying hash.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve Payments over time, where Payments are defined as Payment type transactions where the sender of the transaction is not also the destination.(New in v2.0.4) Results can be returned as individual payments, or aggregated to a specific list of intervals if currency and issuer are provided.REST - All CurrenciesREST - Specific Currency GET /v2/payments/ GET /v2/payments/{:currency} This method uses the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: If the request specifies a currency and an interval, the result includes objects summarizing activity over a specific time period instead of listing individual payments.

Each interval summary object has the following fields: Retrieve Exchanges for a given currency pair over time.Results can be returned as individual exchanges or aggregated to a specific list of intervals This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve an exchange rate for a given currency pair at a specific time.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: All exchange rates are calcuated 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.Convert an amount from one currency and issuer to another, using the network exchange rates.

You must provide at least some of the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: All exchange rates are calculating by converting both currencies to XRP.Retrieve per account per day aggregated payment summaries This method uses the following URL parameter: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Caution: This method may return a very large amount of data (more than 1 megabyte), which may cause poor performance in your client application.Retrieve statistics about transaction activity in the Ripple Consensus Ledger, divided into intervals of time.Optionally, you can provide the following query parameters: The family and metrics query parameters provide a way to filter results to a specific subset of all metrics available for transactions in any given interval.Each metric is tied to a specific family, as follows: The Data API derives the following values for every interval.

These metrics are part of the metric family.If any of the metrics have a value of 0, they are omitted from the results.A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get the total amount of a single currency issued by a single issuer, also known as the market capitalization.(New in v2.0.4) This method requires the following URL parameters: Optionally, you can provide the following query parameters: If the request omits both start and end, the API returns only the most recent sample.A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each issuer capitalization object has the following fields: Get information on which accounts are actively trading in a specific currency pair.(New in v2.0.4) This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each "Account Trading Object" describes the activity of a single account during this time period, and has the following fields: Get aggregated exchange volume for a given time period.

(New in v2.0.4) The API returns results in units of a single display currency rather than many different currencies.The conversion uses standard rates to and from XRP.Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each object in the components array of the Volume Objects represent the volume of exchanges in a market between two currencies, and has the following fields: Get aggregated payment volume for a given time period.Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each object in the components array of the Volume Objects represent the volume of payments for one currencies and issuer, and has the following fields: Get the total value of all currencies issued by major gateways over time.By default, returns only the most recent measurement.Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Issued Value Object represents the total value issued at one point in time, and has the following fields: Get information on the total amount of XRP in existence and in circulation, by weekly intervals.

(New in v2.2.0) Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Distribution Object has the following fields: Returns the top currencies on the Ripple Consensus Ledger, ordered from highest rank to lowest.The ranking is determined by the volume and count of transactions and the number of unique counterparties.By default, returns results for the 30-day rolling window ending on the current date.You can specify a date to get results for the 30-day window ending on that date.(New in v2.1.0) Most RecentBy Date GET /v2/network/top_currencies GET /v2/network/top_currencies/{:date} This method uses the following URL parameter: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Top Currency Object has the following fields: Returns the top exchange markets on the Ripple Consensus Ledger, ordered from highest rank to lowest.

The rank is determined by the number and volume of exchanges and the number of counterparties participating.By default, returns top markets for the 30-day rolling window ending on the current date.(New in v2.1.0) Most RecentBy Date GET /v2/network/top_markets GET /v2/network/top_markets/{:date} This method uses the following URL parameter: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Top Market object has the following fields: Returns transaction cost stats per ledger, hour, or day.The data shows the average, minimum, maximum, and total transaction costs paid for the given interval or ledger.(New in v2.2.0) Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Fee Summary object has the following fields: Get known rippled servers and peer-to-peer connections between them.

(New in v2.2.0) Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get known rippled nodes.(This is a subset of the data returned by the Get Topology method.)(New in v2.2.0) Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get information about a single rippled server by its node public key (not validator public key).(New in v2.2.0) This method requires the following URL parameters: This method takes no query parameters.A successful response uses the HTTP code 200 OK and has a JSON body with a Server Object in the response with the following additional field: Get information on peer-to-peer connections between rippled servers.(New in v2.2.0) Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get details of a single validator in the consensus network.

(New in v2.2.0) This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get a list of known validators.(New in v2.2.0) Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve validation votes signed by a specified validator, including votes for ledger versions that are outside the main ledger chain.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve validation votes, including votes for ledger versions that are outside the main ledger chain.Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get a single validator's validation vote stats for 24-hour intervals.

This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each member in the validators array is a Single Validator Report Object with data on that validator's performance on that day.Each has the following fields: Get a validation vote stats and validator information for all known validators in a 24-hour period.Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Daily Validator Report Object fields: Reports the latest versions of rippled available from the official Ripple Yum repositories.A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Version Object contains the following fields: Get information about known gateways.(New in v2.0.4) This method takes no query parameters.

A successful response uses the HTTP code 200 OK and has a JSON body.Each field in the top level JSON object is a Currency Code.The content of each field is an array of objects, representing gateways that issue that currency.Each object has the following fields: Get information about a specific gateway from the Data API's list of known gateways.(New in v2.0.4) This method requires the following URL parameters: This method takes no query parameters.A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each object in the accounts field array has the following fields: Retrieve vector icons for various currencies.(New in v2.0.4) This method requires the following URL parameter: A successful response uses the HTTP code 200 OK and has a Content-Type header of image/svg+xml to indicate that the contents are XML representing a file in SVG format.Retrieve information about the creation of new accounts in the Ripple Consensus Ledger.

Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: If the request uses the interval query parameter, the response has an array of interval objects, each of which represents the number of accounts created during a single interval.Interval objects have the following fields: Get creation info for a specific ripple account This method requires the following URL parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get all balances held or owed by a specific Ripple account.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Get orders in the order books, placed by a specific account.This does not return orders that have already been filled.This method requires the following URL parameters: Optionally, you can provide the following query parameters: If none of ledger_index, ledger_hash, or date are specified, the API uses the most current data available.

A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each order object has the following fields: 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.This method requires the following URL parameters: Optionally, you can provide the following query parameters: Note: This method cannot return CSV format; only JSON results are supported for raw RCL transactions.A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve a specifc transaction originating from a specified account This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve a payments for a specified account This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve Exchanges for a given account over time.

There are two variations on this method: REST - All ExchangesREST - Specific Currency Pair GET /v2/accounts/{:address}/exchanges/ GET /v2/accounts/{:address}/exchanges/{:base}/{:counter} This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve Balance changes for a given account over time.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve daily summaries of payment activity for an account.REST - Date OmittedREST - Date Specified GET /v2/accounts/{:address}/reports/ GET /v2/accounts/{:address}/reports/{:date} This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Retrieve daily summaries of transaction activity for an account.

This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Transaction Stats Object has the following fields: Retrieve daily summaries of transaction activity for an account.This method requires the following URL parameters: Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK and has a JSON body with the following: Each Value Stats Object has the following fields: Check the health of the API service.Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK.By default, the response body is an integer health value only.The health value 0 always indicates a healthy status.Other health values are defined as follows: If the request specifies verbose=true in the query parameters, the response body is a JSON object, with the following fields: Check the health of the Ledger Importer Service.

REST - Importer Health GET /v2/health/importer Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK.Other health values are defined as follows: If the request specifies verbose=true in the query parameters, the response body is a JSON object, with the following fields: Check the health of the Topology Nodes Extract, Transform, Load (ETL) Service.REST - Nodes ETL Health GET /v2/health/nodes_etl Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK.Other health values are defined as follows: If the request specifies verbose=true in the query parameters, the response body is a JSON object, with the following fields: Check the health of the Validations Extract, Transform, Load (ETL) Service.REST - Validations ETL Health GET /v2/health/validations_etl Optionally, you can provide the following query parameters: A successful response uses the HTTP code 200 OK.

Other health values are defined as follows: If the request specifies verbose=true in the query parameters, the response body is a JSON object, with the following fields: As a REST API, the Data API v2 uses JSON's native datatypes to represent API fields, with some special cases.Currency amounts in Ripple require more precision than most native number types, so the Data API v2 uses the String type to represent some values.Within the String value, the numbers are serialized in the same way as native JSON numbers: The precision for amounts of non-XRP currency in Ripple is as follows: XRP has a different internal representation, and its precision is different: In other words, XRP has the same precision as a 64-bit unsigned integer where each unit is equivalent to 0.000001 XRP.Accounts in the RCL are identified by a base58 Ripple Address.The address is derived from the account's master public key, which is in turn derived from a secret key.An address is represented as a string in JSON and has the following characteristics: For more information, see Accounts.

The Ripple Consensus Ledger (RCL) uses public keys to verify cryptographic signatures in several places: Validator public keys and node public keys use the exact same format.Public keys can be represented in hexadecimal or in base-58.In hexadecimal, all three types of public keys are 33 bytes (66 characters) long.In base-58 format, validator public keys and node public keys always start with the character n, commonly followed by the character 9.A validator public key in base-58 format can be up to 53 characters long.Example node public key: n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG.Ripple addresses are mathematically associated with a public key.This public key is rarely encoded in base-58, but when it is, it starts with the character a. Many objects in Ripple, particularly transactions and ledgers, are uniquely identified by a 256-bit hash value.This value is typically calculated as a "SHA-512Half", which calculates a SHA-512 hash from some contents, then takes the first 64 characters of the hexadecimal representation.

Since the hash of an object is derived from the contents in a way that is extremely unlikely to produce collisions, two objects with the same hash can be considered the same.A Ripple hash value has the following characteristics: Note: SHA-512Half has similar security to the officially-defined SHA-512/256 hash function.However, Ripple's usage predates SHA-512/256 and is also easier to implement on top of an existing SHA-512 function.(As of this writing, SHA-512 support in cryptographic libraries is much more common than for SHA-512/256.)All dates and times are written in ISO 8601 Timestamp Format, using UTC.This format is summarized as: (As of v2.0.4, the offset +00:00 is no longer used.)A ledger index is a 32-bit unsigned integer used to identify a ledger.The ledger index is also known as the ledger's sequence number.The very first ledger was ledger index 1, and each new ledger has a ledger index 1 higher than that of the ledger immediately before it.The ledger index indicates the order of the ledgers; the Hash value identifies the exact contents of the ledger.

Two ledgers with the same hash are always the same.For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1.However, this is not true for in-progress ledgers: A Sequence number is a 32-bit unsigned integer used to identify a transaction or Offer relative to a specific account.Every account object in the Ripple Consensus Ledger has a Sequence number, which starts at 1.For a transaction to be relayed to the network and possibly included in a validated ledger, it must have a Sequence field that matches the sending account's current Sequence number.An account's Sequence field is incremented whenever a transaction from that account is included in a validated ledger (regardless of whether the transaction succeeded or failed).This preserves the order of transactions submitted by an account, and differentiates transactions that would otherwise be the same.Every Offer node in the Ripple Consensus Ledger is marked with the sending Account Address and the Sequence value of the OfferCreate transaction that created it.

These two fields, together, uniquely identify the Offer.There are two kinds of currency code in the Ripple Consensus Ledger: Many queries may return more data than is reasonable to return in a single HTTP response.The Data API uses a "limit and marker" system to control how much is returned in a single response ("page") and to query for additional content.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 marker is or would be present, the response contains a Link header 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) Transactions have two formats - a compact "binary" format where the defining fields of the transaction are encoded as strings of hex, and an expanded format where the defining fields of the transaction are nested as complete JSON objects.A "ledger" is one version of the shared global ledger.Each ledger object has the following fields: Note: Ledger close times are approximate, typically rounded to about 10 seconds.Two ledgers could have the same close_time values, when their actual close times were several seconds apart.The sequence number (ledger_index) of the ledger makes it unambiguous which ledger closed first.

Due to a mishap early in Ripple's history, ledgers 1 through 32569 were lost.Thus, ledger #32570 is the earliest ledger available anywhere.For purposes of the Data API v2, ledger #32570 is considered the genesis ledger.An account creation object represents the action of creating an account in the Ripple Consensus Ledger.There are two variations, depending on whether the account was already present in ledger 32570, the earliest ledger available.Accounts that were already present in ledger 32570 are termed genesis accounts.An exchange object represents an actual exchange of currency, which can occur in the Ripple Consensus Ledger as the result of executing either an OfferCreate transaction or a Payment transaction.In order for currency to actually change hands, there must be a previously-unfilled Offer previously placed in the ledger with an OfferCreate transaction.A single transaction can cause several exchanges to occur.In this case, the sender of the transaction is the taker for all the exchanges, but each exchange has a different provider, currency pair, or both.

Reports objects show the activity of a given account over a specific interval of time, typically a day.Reports have the following fields: A Payment Summary Object contains a reduced amount of information about a single payment from the perspective of either the sender or receiver of that payment.In the Data API, a Payment Object represents an event where one account sent value to another account.This mostly lines up with Ripple transactions of the Payment transaction type, except that the Data API does not consider a transaction to be a payment if the sending Account and the Destination account are the same, or if the transaction failed.Payment objects have the following fields: Balance objects represent an Ripple account's balance in a specific currency with a specific counterparty at a single point in time.Balance change objects represent a change to such balances that occurs in transaction execution.A single Ripple transaction may cause changes to balances with several counterparties, as well as changes to XRP.

Balance objects and Balance Change objects have the same format, with the following fields: Balance Change Descriptors are objects that describe and analyze a single balance change that occurs in transaction execution.They represent the same events as balance change objects, but in greater detail.Balance Change Descriptors have the following fields: The following values are valid for the change_type field of a Balance Change Descriptor: Volume objects represent the total volumes of money moved, in either payments or exchanges, during a given period.A "Server Object" describes one rippled server in the Ripple peer-to-peer network.Server objects are returned by the Get Topology, Get Toplogy Nodes, and Get Topology Node methods.The Data API collects reported network topology approximately every 30 seconds using the peer crawler.Server objects have the following fields, with some only appearing if the request specified a verbose response: A Link Object represents a peer-to-peer network connection between two rippled servers.

It has the following fields: A Validation Object represents one vote from a validator to mark a ledger version as validated.(A ledger is only validated by the consensus process if a quorum of trusted validators votes for the same exact ledger version.)Note: The Data API retain only about 6 months of validation vote data.A Validation Object has the following fields: You can also serve the Data API v2 from 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 to run the historical database indefinitely, or you want access to historical transactions from within your own intranet.The Historical Database requires the following software installed first: Version 2 of the Historical Database requires HBase instead of PostgreSQL.Postgres support is deprecated.To install the Data API v2: Install HBase.For production use, configure it in distributed mode.Clone the Historical Database Git Repository: /ripple/rippled-historical-database.git (You can also download and extract a zipped release instead.)

Use npm to install additional modules: cd rippled-historical-database npm install The install script creates the required config files: config/api.config.json and config/import.config.json Change the config files as needed.Remove the postgres section from api.config.json.Reports, stats, and aggregated exchange data needs more processing before the API can make it available.This processing uses Apache Storm as well as some custom scripts.See Storm Setup for more information.At this point, the Data API is installed.See Services for the different components that you can run.The rippled Historical Database consists of several processes that can be run separately.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: 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.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, the Importer may still 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.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.Caution: The Backfiller is best for filling in relatively short histories of transactions.Importing a complete history of all Ripple transactions using the Backfiller could take weeks.If you want a full history, we recommend acquiring a database dump with early transctions, and importing it directly.For the public server, Ripple (the company) used the internal SQLite database from an offline rippled to populate its historical databases with the early transactions, then used the Backfiller to catch up to date after the import finished.