聊天记录
共 66 条，显示第 51-66 条
Your API, your design but for clarity's sake, I would recommend not including two different options for saying the same thing in the API. The use of outcome_side and book_side simulataneously just serves to confuse and make the API marginally less efficient. I quite like that the create order endpoint is slimmed to the essentials and users can always translate between book/outcome side conceptions on their own end
Your API, your design but for clarity's sake, I would recommend not including two different options for saying the same thing in the API. The use of outcome_side and book_side simulataneously just serves to confuse and make the API marginally less efficient. I quite like that the create order endpoint is slimmed to the essentials and users can always translate between book/outcome side conceptions on their own end
👋
👋
It's incredibly different and I can't imagine how you think it's similar at all. Also to be an "I don't like your attitude guy" when you respond to people like this constantly is deeply reflecting of a lack of self awareness.
It's incredibly different and I can't imagine how you think it's similar at all. Also to be an "I don't like your attitude guy" when you respond to people like this constantly is deeply reflecting of a lack of self awareness.
In parallel or together with the fills? ie do you track your positions via fills as position representation A and then also track it from the position stream as representation B and then do something like rely on A => fallback to B if fills dies?
In parallel or together with the fills? ie do you track your positions via fills as position representation A and then also track it from the position stream as representation B and then do something like rely on A => fallback to B if fills dies?
yup, makes sense. I currently place a ghost order in my ledger at create time anyway since an order frame may arrive before response
yup, makes sense. I currently place a ghost order in my ledger at create time anyway since an order frame may arrive before response
Is fills + doing your own order accounting what you do, broadstrokes? Do you ever have fills arrive before an order response is returned from the create order endpoint?
Is fills + doing your own order accounting what you do, broadstrokes? Do you ever have fills arrive before an order response is returned from the create order endpoint?
I figured it was clear what I was doing based on saying "I currently rely on the User Orders WS stream for orders and then, independently, use the Market Positions stream for actual holdings." but for extreme clarity I define real-time position tracking to mean that at any given time I have an internal representation of my position which is as close to the true state on the exchange. A position here is defined as, for every market, the complete set of orders and current holdings marked to market values. For each order, I have the full Order information about state that is available (ie order size, filled, remaining, price, etc) and for each position, I have a marked to market value, contract size, fees paid, cost of position, etc.
I figured it was clear what I was doing based on saying "I currently rely on the User Orders WS stream for orders and then, independently, use the Market Positions stream for actual holdings." but for extreme clarity I define real-time position tracking to mean that at any given time I have an internal representation of my position which is as close to the true state on the exchange. A position here is defined as, for every market, the complete set of orders and current holdings marked to market values. For each order, I have the full Order information about state that is available (ie order size, filled, remaining, price, etc) and for each position, I have a marked to market value, contract size, fees paid, cost of position, etc.
I mean thanks for going to the trouble of repeating yourself but that's not really useful advice. "My architecture is I cache data then figure out what I need to track" is something out a nightmare architecture discussion. I'm clearly aware of the data available but merging it into real time positions which enable proper risk management and sizing isn't completely trivial and, as you said, you have to deal with the race conditions. If you have an actual answer for how you do that in a consistent way that isn't "I figure out what my strats need, bro" then that could be helpful
I mean thanks for going to the trouble of repeating yourself but that's not really useful advice. "My architecture is I cache data then figure out what I need to track" is something out a nightmare architecture discussion. I'm clearly aware of the data available but merging it into real time positions which enable proper risk management and sizing isn't completely trivial and, as you said, you have to deal with the race conditions. If you have an actual answer for how you do that in a consistent way that isn't "I figure out what my strats need, bro" then that could be helpful
100. Just wanted to see if anyone had a consolidated architecture which they thought was good. Probably will track the relative latency of the 3 and see if that makes a decision easy
100. Just wanted to see if anyone had a consolidated architecture which they thought was good. Probably will track the relative latency of the 3 and see if that makes a decision easy
or rather it's a straightforward need for risk management, order sizing, etc.
or rather it's a straightforward need for risk management, order sizing, etc.
real-time position tracking? Feels straightforward as a use case?
real-time position tracking? Feels straightforward as a use case?
Under which arch? In the second, if a Fill arrives before an order, you could make a ghost order from the Fill and then add the missing details back with the REST response, yes, but it still leads to gaps
Under which arch? In the second, if a Fill arrives before an order, you could make a ghost order from the Fill and then add the missing details back with the REST response, yes, but it still leads to gaps
Does anyone have an architecture for real-time position tracking that they are happy with?
I currently rely on the User Orders WS stream for orders and then, independently, use the Market Positions stream for actual holdings.
This leads to a challenge where an Order may update from a Fill, the User Order frame comes first and then a delayed Market Position frame comes, representing the same Fill. In the gap between those frames, my position is incorrect. For Risk decisions this is fine, because it will give a conservative view of my exposure given how I calculate it but it breaks some order decisions (I may think my position is smaller than it is and that my open orders are smaller, eg).
An alternative I can see would be to go to a system where I rely on the Fill stream + internal tracking of orders. This would work as well but one challenge I see is the race between fills + order replies which would be an issue as well. eg, you would need to handle a fill arriving before the order REST response.
Is anyone doing anything else?
Does anyone have an architecture for real-time position tracking that they are happy with?
I currently rely on the User Orders WS stream for orders and then, independently, use the Market Positions stream for actual holdings.
This leads to a challenge where an Order may update from a Fill, the User Order frame comes first and then a delayed Market Position frame comes, representing the same Fill. In the gap between those frames, my position is incorrect. For Risk decisions this is fine, because it will give a conservative view of my exposure given how I calculate it but it breaks some order decisions (I may think my position is smaller than it is and that my open orders are smaller, eg).
An alternative I can see would be to go to a system where I rely on the Fill stream + internal tracking of orders. This would work as well but one challenge I see is the race between fills + order replies which would be an issue as well. eg, you would need to handle a fill arriving before the order REST response.
Is anyone doing anything else?
probably with worse latency though
probably with worse latency though
Although I guess you could just do them sequentially as well
Although I guess you could just do them sequentially as well
this is interesting. Seems like a valid use case if this is a guarantee of the endpoint
this is interesting. Seems like a valid use case if this is a guarantee of the endpoint
Kalshi