Henry-E
commented
2 years ago Making accounts check optional seems dangerous. You should look into writing your own new order function maybe?
Cool idea to have a single event queue for multiple order books though. The event queue is pretty generic so this should work no problem?
tomland123
Our use case (for multi-outcome prediction markets) involves multiple homogenous orderbooks 'stacked', where a market instance consist of N prediction contracts (the base assets) traded against a quote asset. The most common case stems from sports where you have 3 outcomes (and orderbooks) for Home/Away/Draw - however, you can imagine more extreme scenarios like F1 or horse racing, where 30+ outcomes in the same market is not unusual.
Other than differentiating that each orderbook is in respect of a different 'outcome' in the market, the orderbooks are the same, and properties stored within the
orderbookaccount are common for all slabs - i.e.callback_id_len,callback_info_len,fee_budget,initial_lamports,min_base_order_size,tick_size,cranker_rewardcould will all be consistent for all orderbook instances in the same market.Similarly, the only distinction implied by having N
event_queues is which outcome a given event relates to, which must be known in order to appropriately settle the correct user balances. It would streamline our calling program and cranking process massively if instead we could write all events (regardless of whichslabthey stemmed from) to the sameevent_queue, and instead identify the outcome with a u8 value which could be stored incallback_info.To facilitate this, we would need to make the following checks within
check_accountsoptional and ensure consistency between slab accounts and their intended use within the calling program.check_account_key(accounts.bids, &market_state.bids, AoError::WrongBidsAccount)?;check_account_key(accounts.asks, &market_state.asks, AoError::WrongAsksAccount)?;