Fork GetLastTrades.jar to use as a wrapper for returning any account balances that are not part of orders

Issue #148 new
Ben Rossi created an issue

Functional Description

A simple way to query an exchange to determine the balance of funds not currently in orders from the command line would be useful.

Data returned in this response will need to be compared against the "expected" balance to make sure that values provided do not take into consideration funds that (technically) appeared in the user's balance at the time of the query, but in reality were only there temporarily during the shifting of a wall. This functionality does not need to be built into the requested fork of GetLastTrades.jar unless is it something that would actually be more work not to include because it already behaved this way.

It is not expected that exchanges will allow the passing of a timestamp into the request, but if it is an option offered by the exchange, it would be worth discussing the value to the custodian for reporting purposes depending on how it works.

Requested Output Structure

The output of this tool is a .json file, account-balance.json. The structure of the file should follow this model:

{
    "exchange": "ccedk",
    "id": "6DR7WK63ZV",
    "funds": [
        {
            "timestamp": 1420566717000,
            "currency": "btc",
            "balance": {
                 "onOrder": 12.48978328,
                 "available": 24.55313456,
                 "total": 37.043096736
            },
            "address": "1GzUJoStC9CHpzFPBGtZF7D7or9c3PdsG7"
        },
        {
            "timestamp": 1420566735000,
            "currency": "usd",
            "balance": {
                 "onOrder": 0,
                 "available": 294.8978,
                 "total": 294.8978
            },
            "address": "null"
        }
    ]
}

In the above example, the custodian's CCEDK account had two balances (BTC and USD) not used in active orders.

The top-level of the report contains:

  • exchange is the name of the exchange used to identify which exchange these results came from and should match the same naming convention used by the general NuBot wrapper results for that exchange (i.e., "ccedk" or "bter")

  • To identify which exchange account these values came from the id will be provided. This value is constructed by taking the last ten (10) characters from the public API token string passed to the exchange as part of the request. For example, if the account token passed to the exchange is "c703057be878458588961ce9a0ce686b", the value of id would be "e9a0ce686b". This allows the account holder to uniquely identify this account from any others on the same exchange that they have run balance queries against.

For each balance returned, the results will contain a unique object:

  • The timestamp value should provide the time of the query in unix millisecond time (or microsecond, whichever matches the rest of the timestamp .json outputs that NuBot builds).

  • The currency key corresponds with the type of unit that the balance is for. The response should be the three character currency code string (e.g. "btc", "usd", "nbt").

  • The amount key value will be the balance amount as an decimal to whatever level of precision it is provided by the exchange. It is assumed that rounding will be handled by whatever tool utilizes the data once it has been retrieved.

  • Finally, fo balances held in digital currencies, if the exchange is able to return a response with the exchange wallet address that the funds reside in, please include (CCEDK allows this). Otherwise, a "null" string or false boolean can be passed as the value.

Comments (11)

  1. Log in to comment