Currently we are completely deferring to binance's own internal
position / balance reporting and we haven't added any support
for transaction ledgers.
[ ] tracking via piker-native .accounting system using
ledgers and accounting positions B)
[ ] add ledger tracking of historical trades.
[ ] add ledger tracking of every live update transaction
[ ] add position accounting from the above as in other
backends.
Running futes and spot venue brokerd tasks in parallel?
Currently we have no way to indicate to the particular brokerd
instance whether the futes or spot venue should be attached for the
user stream wss. Ideally we actually connect to both (so that
inbound EMS requests are routed appropriately based on msg content)
but that requires concurrency (in terms of the current task tree
design from open_trade_dialog() downward) and is a design we
should discuss both in terms of performance and configuration
details.
[ ] easiest in-actor way would be to spawn separate task trees
depending on whether there are binance.futes and
binance.spot sections in the brokers.toml and then more or
less spawning a separate task that runs what right now is.brokers.binance.broker.open_trade_dialog()
[ ] we might want to actually spawn a sub-actor tree as well so
that both brokerd's have equal cpu bound priority?
say like under some kind of HFT(ish) market-making scenario
where a bot is trading both futes and spot market in tandem?
After #520 lands we still have some lingering questions and todos to get full
.accountingposition tracking support.Pulling in remaining bullets from that PR content:
Order control questions:
<listenkey>@orderREQUEST but no bueno..Position tracking via
.accountingsub-sys:Currently we are completely deferring to binance's own internal position / balance reporting and we haven't added any support for transaction ledgers.
piker-native.accountingsystem using ledgers and accounting positions B)Running futes and spot venue brokerd tasks in parallel?
Currently we have no way to indicate to the particular brokerd instance whether the futes or spot venue should be attached for the user stream wss. Ideally we actually connect to both (so that inbound EMS requests are routed appropriately based on msg content) but that requires concurrency (in terms of the current task tree design from
open_trade_dialog()downward) and is a design we should discuss both in terms of performance and configuration details.binance.futesandbinance.spotsections in thebrokers.tomland then more or less spawning a separate task that runs what right now is.brokers.binance.broker.open_trade_dialog()