-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cranking (consume events) FAQ #101
Comments
Hi @mihneacalugaru, thanks for your questions. |
Hi @ellttBen, thanks for your answer, as always! Understood everything you said and also implemented it. Works well! More as a FAQ-sided note, I wanted to talk a bit about the But I think I understand now:
Correct me If I'm wrong with any of my above findings and understanding. Thank you very much for your time and for working with me on building this early version of FAQ! |
Hello,
I want to ask some questions and touch base a bit about what the cranking process is and what are the best practices by which it should be done.
What I know from examining the code:
consume_events
instructionconsume_events
instruction needs to know how many items in the queue it should read and process (through themax_iterations
parameters)consume_events
instruction needs to provide the DEX program with theopen_orders_accounts
of all the users that are referenced by the events which are about to be processed. This can be done by loading theevent_queue
and extracting theiropen_orders_account
from theEvent
by the following rule: in case it's anEventFill
then it's taken from theevent_fill.makerCallbackInfo.slice(0, 32)
; in case it's anEventOut
then it's taken from theevent_out.callbackInfo.slice(0, 32)
taker
doesn't need to have his events consumed because thenew_order
instruction already takes care of updating theopen_orders_account
in case there was at least a partial fill for his ordermaker
has to have his events consumed by a crank in order to get hisopen_orders_account
updated after orders of his have been matchedaccumulated_royalties
andaccumulated_fees
belonging to the market are updated byconsuming events
What I am not sure about and would like to figure out:
consume_events
instruction in different transactions. For example:new_order
,consume_events
) so that after a taker will get his order matched, he will also consume the events that would update theopen_orders_account
of the maker, making the latter able to settle his funds.consume_events
,settle
) so that before a maker tries to settle his funds, he makes sure he consumed the events that will update hisopen_orders_account
in order to actually have something to settleHowever, I don't think these solutions are good. For example:
consume_events
instruction that belongs to the same transaction. But if I create a second transaction with just theconsume_events
instruction and execute it after thenew_order
this will workopen_orders_account
updated. Given the fact that he needs to specify amax_iterations
, he could consume the next X events that belong to other users and were not consumed yet, so he would end up cranking the market for others and not consume enough events to reach his own events.All in all, I think trying to embed the
consume_events
instruction in users' trading transaction is a dead-end. This leads to the point 2) below.cranker
folder in the repo. The code looks like something that needs to be run in a background job by the market admin at a particular frequency. The frequency can be set according to the liquidity in the market I guess.Here are the questions:
cranking/consuming events
of a market?The text was updated successfully, but these errors were encountered: