Binance orders

[goodboy]

Now that #190 is ready to land (once y'all glance at it) we've got a much more explicit api for supporting order management and thus live trading.

The big crypto boi in town is of course the new binance backend and, from a glance at their api it should be mostly a cinch to implement.

This needs a readme / write up (coming soon) but the basic gist is this:

• each backend module needs to define @tractor.context (yes the new bidir streaming api) endpoint named trades_dialogue() which sets up a 2 way stream for both accepting order requests from the EMS (execution management system, or "clearing system" which runs in the emsd sub-daemon) and delivering user account trade events back from binance to the ems. Examples of this endpoint include:
  • the .clearing._paper_engine.trades_dialogue() which shows how to start the context and spawn a secondary task, at handle_order_requests() which handles the inbound order requests from the emsd
  • the brokers.ib.trades_dialogue() endpoint which basically shows the same design (also has a inbound handling task) but also has the support for *relaying ib trade events back to the emsd as is shown in this loop.
  • the allowed set of messages is defined in the new .clear._messages module; the sequencing and flow of which is currently only documented in the comments above each message set -> this all needs to be further documented in a readme (like i said, coming soon 😂).
• binance has 2 main sets of endpoints that are likely to be needed to get support going:
  • the first is the order request: NEW ORDER and Cancel Order calls which should basically map from the .submit_limit() and submit_cancel() methods seen in the other mentioned backends
  • the second is the trade events stream which can either be manually requested through queries (which are single request only) or, and which is the approach we probably want, by streaming the user's Order Update subscription.
    • Note that user data streams require some extra management with a listenKey which you actually use to gen a dynamic endpoint from the looks of it

The crash course on the 2 sets of message types:

• piker client dialogue msgs are in the set of Cancel, Order, and Status these are purely piker related client <-> emsd messages that provide a uniform/simpler layer for abstracting across ems services
• emsd <-> brokerd dialogues (which take place with the trades_dialogue() mentioned above) are the messages in this set which include a few extra messages for order request acks, positions, individual fills, and errors. For now as long as we stick to the pydantic fields everything should just work; if we need to modify / extend the messages that's also just fine 😎.

Hopefully this is enough to get going 😂