piker/piker/brokers/kraken
Tyler Goodlet 4c5507301e kraken: be symcache compatible!
This was more involved then expected but on the bright side, is going to
help drive a more general `Account` update/processing/loading API
providing for all the high-level txn update methods needed for any
backend to generically update the participant's account *state* via
an input ledger/txn set B)

Key changes to enable `SymbologyCache` compat:
- adjust `Client` pairs / assets lookup tables to include a duplicate
  keying of all assets and "asset pairs" using the (chitty) default key
  set that kraken ships which is NOT the `.altname` no `.wsname` keys;
  the "default ReST response keys" i guess?
  - `._AssetPairs` and `._Assets` are *these ^* rest-key sets delivered
    verbatim from the endpoint responses,
  - `._pairs` and `._assets` the equivalent value-sets keyed by piker
    style FQME-looking keys (now provided via the new
    `.kraken.symbols.Pair.bs_fqme: str` and the delivered `'altname'`
    field (for assets) respectively.
- re-implement `.get_assets()` and `.get_mkt_pairs()` to appropriately
  delegate to internal methods and these new (multi-keyed) tables to
  deliver the cacheable set of symbology info.
- adjust `.feed.get_mkt_info()` to handle parsing of both fqme-style and
  wtv(-the-shit-stupid) kraken key set a caller passes via
  a key-matches-first-table-style-scan after pre-processing the
  input `fqme: str`; also do the `Asset` lookups from the new
  `Pair.bs_dst/src_asset: str` fields which should always map correctly
  to an internal asset entry delivered by `Client.get_assets()`.

Dirty impl deatz:
- add new `.kraken.symbols` and move the newly refined `Pair` there.
- add `.kraken.ledger` and move in the factored out ledger processing
  routines.
- also move out what was the `has_pp()` and large chung of nested-ish
  looking acnt-position verification logic blocks into a new
  `verify_balances()` B)
2023-07-16 21:21:53 -04:00
..
README.rst Flip to `.bs_mktid` in `ib` and `kraken` 2023-05-09 14:49:25 -04:00
__init__.py kraken: be symcache compatible! 2023-07-16 21:21:53 -04:00
api.py kraken: be symcache compatible! 2023-07-16 21:21:53 -04:00
broker.py kraken: be symcache compatible! 2023-07-16 21:21:53 -04:00
feed.py kraken: be symcache compatible! 2023-07-16 21:21:53 -04:00
ledger.py kraken: be symcache compatible! 2023-07-16 21:21:53 -04:00
symbols.py kraken: be symcache compatible! 2023-07-16 21:21:53 -04:00

README.rst

kraken backend

though they don't have the most liquidity of all the cexes they sure are accommodating to those of us who appreciate a little xmr.

status

current support is production grade and both real-time data and order management should be correct and fast. this backend is used by core devs for live trading.

config

In order to get order mode support your brokers.toml needs to have something like the following:

[kraken]
accounts.spot = 'spot'
key_descr = "spot"
api_key = "69696969696969696696969696969696969696969696969696969696"
secret = "BOOBSBOOBSBOOBSBOOBSBOOBSSMBZ69696969696969669969696969696"

If everything works correctly you should see any current positions loaded in the pps pane on chart load and you should also be able to check your trade records in the file:

<pikerk_conf_dir>/ledgers/trades_kraken_spot.toml

An example ledger file will have entries written verbatim from the trade events schema:

[TFJBKK-SMBZS-VJ4UWS]
ordertxid = "SMBZSA-7CNQU-3HWLNJ"
postxid = "SMBZSE-M7IF5-CFI7LT"
pair = "XXMRZEUR"
time = 1655691993.4133966
type = "buy"
ordertype = "limit"
price = "103.97000000"
cost = "499.99999977"
fee = "0.80000000"
vol = "4.80907954"
margin = "0.00000000"
misc = ""

your pps.toml file will have position entries like,

[kraken.spot."xmreur.kraken"]
size = 4.80907954
ppu = 103.97000000
bs_mktid = "XXMRZEUR"
clears = [
 { tid = "TFJBKK-SMBZS-VJ4UWS", cost = 0.8, price = 103.97, size = 4.80907954, dt = "2022-05-20T02:26:33.413397+00:00" },
]