Add FillEvent with common market order ID #315
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Bump devnet listing for FillEvent paradigm (#315)
| Once a market is registered, signing users and delegated custodians | ||
| can place limit orders on the book as makers, takers can place | ||
| market orders or swaps against the order book, and makers can cancel | ||
| or change the size of any outstanding orders they have on the book. | ||
| can place limit orders on the book as makers and/or as takers, | ||
| takers can place market orders or swaps against the order book, and | ||
| makers can cancel or change the size of any outstanding orders they | ||
| have on the book. |
There was a problem hiding this comment.
This wording seems strange to me. There is no sense in which any given user is a maker or a taker—any given order can be a maker order or a taker order, and the user will be a maker or a taker with regard to that specific order, but that doesn't describe their relationship to the market itself.
There was a problem hiding this comment.
Tagging #321 to incorporate refactors on that iteration
| event::emit_event(taker_handle, TakerEvent{ | ||
| market_id, side, market_order_id, maker, custodian_id: | ||
| maker_custodian_id, size: fill_size, price}); |
There was a problem hiding this comment.
Backwards compatibility means that anyone who had built anything on top of a previous version of this code would not have to make any changes for their code to keep on running as expected.
As we are no longer emitting taker events, and any system that relied on taker events would have to make the switch over to fills events, this change is not backwards compatible.
There was a problem hiding this comment.
Yes, so it's not really backward-compatible. Aptos simply performs a minimal check where the struct declarations and function signatures are compared to catch any changes that are obviously not backwards compatible, as far as I'm aware. This is in no way a guarantee of backwards compatibility, and since we know that this in fact isn't a backwards compatible change, we should stop describing it as such.
| // Increment order counter. | ||
| order_book_ref_mut.counter = order_book_ref_mut.counter + 1; |
There was a problem hiding this comment.
Comment simply repeats code
There was a problem hiding this comment.
Tagging #321 to incorporate refactors on that iteration
|
Closing in lieu of more comprehensive #321 |
Summary of changes
TakerEventandOrderBook.taker_eventsin lieu ofFillEventandFillEventHandles.match()and inplace_limit_order()).match()function to deferFillEventemission in the case of a limit order.did_order_post()) for determining if a market order ID corresponds to an order that posted to the book.FillEvent(s) when an order results in multiple fills, which is common to theMakerEventmarket order ID in the case of a limit order that crosses the spread and fills as a taker before posting as a maker.