You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 orderbook account are common for all slabs - i.e. callback_id_len, callback_info_len, fee_budget, initial_lamports, min_base_order_size, tick_size, cranker_reward could 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 which slab they stemmed from) to the same event_queue, and instead identify the outcome with a u8 value which could be stored in callback_info.
To facilitate this, we would need to make the following checks within check_accounts optional 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)?;
The text was updated successfully, but these errors were encountered:
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
orderbook
account are common for all slabs - i.e.callback_id_len
,callback_info_len
,fee_budget
,initial_lamports
,min_base_order_size
,tick_size
,cranker_reward
could will all be consistent for all orderbook instances in the same market.Similarly, the only distinction implied by having N
event_queue
s 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 whichslab
they 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_accounts
optional 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)?;
The text was updated successfully, but these errors were encountered: