Positioning system design discussion #478
Labels
accounting
prolly positioning: the accounting of "what/when (is) owned"
clearing
auction and mm tech: EMS, OMS, algo-trading
config
ledger
trade, accounts and other user focal event history tracking, management and storage
After landing the (very exciting) pair of patch sets in #462 and soon #470
this is yet-another-follow-up issue, with todos surrounding our
pps.toml
format, file management, and general position tracking service architecture.We currently have a variety of follow up issues and bugs:prolly positioning: the accounting of "what/when (is) owned"
accounting
Some ideas that came out of the above mentioned patch sets include:
=> now all detailed in the newer #510
ledgerd
pps.toml
.clears
table-field format and name:with limit adjustments as discussed in order mode pane UI bugs.. #479
pps.toml
into multiple files, likely broken up by broker and possibly by
account
=> lands with Rekt pps? problem? =>
piker.accounting
#489brokerd
's trying to write to a common file by instead expectingeach actor-process to manage its own
<brokername>_pps.toml
file, allowing for distribution over multiple hosts as well as
isolation between position state tracking if we were to route
orders for a single pair through multiple brokers.
NEW
MktPair
struct formatAs per the draft type that will land in
https://github.com/pikers/piker/pull/470/files#diff-2ea622b63a72576d8a27f1a2ab910591a350d29e7b6e0b9a055e49ae66626f12R137,
we want a much simplified and better suited for our
fqsn
marketaddresing schema detailed in #467.
piker.accounting
#489 B)likely i will write up some further details on how to refine this
prototype and use throughout the rest of
piker
's subsystems..here 😂^Again see #489
The text was updated successfully, but these errors were encountered: