In other words how do we store dark order and alerts in a data-state
that can be easily understood (via manual read by human) and tracked via
puter such that any time the emsd is brought alive, all such
prior executables are reinstated in the clearing engine and if
triggering conditions already took place we do some thing as
configured by the user?
Ideas:
to start, just use TOML and an array of inline-tables per market?
an example might be:
[ib.algopaper."mnq.globex.20220916"]
last_dt = "2023-05-19T22:00:26.976416+00:00" # last time that emsd was "up"
darks = [
{ price = 13250, size = 1, on_triggered = 'ignore' }, # don't submit if triggerable on boot
{ price = 15000, size = -1, on_triggered = 'submit_live' },
]
[btcusdt.binance]
alerts = [
{ price = 20e3, msg = 'yoyoyo BTC BE CHEEEEAP!' }, # alerts only have a msg field
]
what kind of sytax for a persistent alert: one that triggers at the
level (line value) no matter the crosses / trigger-side ?
a way to pass order between execution engines using a declarative
msg-compatible format?
would be super handy for mirroring and collab trades
In other words how do we store dark order and alerts in a data-state that can be easily understood (via manual read by human) and tracked via puter such that any time the
emsdis brought alive, all such prior executables are reinstated in the clearing engine and if triggering conditions already took place we do some thing as configured by the user?Ideas:
to start, just use
TOMLand an array of inline-tables per market?[btcusdt.binance] alerts = [ { price = 20e3, msg = 'yoyoyo BTC BE CHEEEEAP!' }, # alerts only have a msg field ]
what kind of sytax for a persistent alert: one that triggers at the level (line value) no matter the crosses / trigger-side ?
a way to pass order between execution engines using a declarative msg-compatible format?