Market Lifecycle

The lifecycle a market on Aver goes through

A market on Aver will go through a number of phases, some of which may be optional, and depend on specifics of how the market was specified.

Some of these phases may be shorter or longer, depending on different factors and circumstances that apply.

Initialization

The subject matter of the market is determined and a resolution source (ideally sources) are identified.

An oracle resolution account is initialized, and the 'job(s)' which specify how the result will be obtained are deployed on the Switchboard oracle program.

Information which contains the specification of the market is passed in a set of instructions to the Aver Market program, which creates the first (partially initialized) instance of the Market on-chain. This contains values like:

• A description of the market itself

• The list of possible outcomes

• The number of winners to resolve from the market

• Whether or not the market is permissioned, and it's permissioning reuqirements and caps (if applicable)

• Trading limits

• An indication as to whether or not the market will go in-play

• Times when the market is currently anticipated to cease trading (and go in-play, if applicable)

• Specification of the fees applicable on this market

An associated token account, which will act as a collateral 'vault', is initialized and control of this account is assigned to the program (i.e. to be governed by smart contract logic only).

Accounts are incrementally initialized to support the orderbooks for each outcome in the market, and the index of these accounts updated within Market Store state.

Once all of necessary accounts have been initialized and the necessary state validated and complete, the market may sit in initialized status (i.e. ready, but not active) or be moved to a trading status.

Trading (Pre-Event)

Once a market has been moved from initialized status to activePreEvent status, other wallet may interact with the market.

User-Market accounts can be initialized against this market and orders can be placed and cancelled. Users are free to trade in and out of positions as they please within this period.

Halting Trading (Pre-Event)

A market's authority can temporarily suspend trading on a market - moving the market into a haltedPreEvent status. haltedPreEvent is not an absorbing state, and the market can return to activePreEvent from here.

If this occurs, new orders cannot be placed on the market until the market returns to an activePreEvent (or activeInPlay) status. It is possible however, for a user to cancel open/unmatched orders while the market is in haltedPreEvent status.

Going In-Play

In-Play is not supported on Aver just yet, but it will be very soon.

This is an optional phase which not all markets will go through. A flag is specified at market initialization which sets out whether or not a market can go in-play.

In-play trading means that trading is facilitated during the live unfolding of the underlying event.

This can be a particularly volatile period of time, where information asymmetry can lead to those with limit orders being exposed to those with an information advantage.

For example, where an individual is at the event and knows something immediately, where another participant has a 5-10 second lag before the information is reported on TV or online.

When a market turns in-play, all unmatched orders on the orderbooks are cancelled, and the orderbooks reset.

To facilitate this, the market is temporarily placed into a transitioningInPlay status, where new orders and order cancellations (not required in any case, as all unmatched pre-event orders will cancelled anyway) are not accepted.

Once the process has completed, the market authority can move the market in-play to activeInPlay status.

In this status, new orders have to 'wait' a minimum number of seconds (specified at market level) before they can be matched with existing unmatched orders, or before being posted onto the book. This is intended to act as a measure to level the playing field and remove the potential for information asymmetry leading to exploitation of other participants.

Unmatched orders (either in 'waiting' or already posted to the book) can be cancelled without any delay.

Halting Trading (In-Play)

As in the pre-event stage of trading, it is possible for the market's authority to temporarily suspend trading by moving the market into haltedInPlay status.

haltedInPlay is not an absorbing state, and the market can return to activeInPlay from here.

If this occurs, new orders cannot be placed on the market until the market returns to an activeInPlay status. It is possible however, for a participant to cancel open/unmatched orders while the market is in haltedInPlay status.

Updates to Market Timings

The market's authority has the ability to update market timings if new information comes to light. For example, it might be common for the underlying event to be rescheduled, and so the time when the market is expected to go in-play (if applicable) or to cease trading may change.

Ceasing Trading

The market will move to tradingCeased status through one of two mechanisms:

• The ceaseTradingTime specified within the market has now passed; or

• The market's authority has sent an instruction to cease the market trading.

At this point, the accounts required only during the trading phase of the market can be closed as they are no longer required. Once the orderbooks are cleared and these accounts are closed, the market moves into crankedCeasedClosed status.

From here, it is a matter of waiting until a result of the underlying market is known.

The time between the market ceasing trading and a result being available may vary by a number of circumstances - for example, where a market trades through the underlying event, or the natural time-lag between the event and the result (for example, the result of an election may not be official for a number of days or even weeks after the election itself)

Resolution & Settlement

Once a result is known, the market can be triggered to attempt resolution, and if successful moves to resolved status. This status is absorbing and the market will not move to any further states from here.

In this state, the winning outcome (or outcomes, for multi-winner markets) will be known.

From here, the proceeds from the market can be settled automatically to all participants, their User-Market accounts closed, and the SOL 'rent' returned to their wallets.

Any fees applicable are levied at this point, and any revenue share applicable (to Hosts or Referrers) is swept to a vault account.

Voiding & Settlement

In some cases, a market may need to be voided - for example, where a valid result cannot be obtained by the oracle, or there has been an issue with mis-specification of the market. In other cases, voiding may be an expected scenario (for example, where a market is init'd that voids in the case of a draw rather than specifying Draw as a possibly outcome)

In this case, the market's authority moves the market to voided status. This status is absorbing and the market will not move to any further states from here.

From here all participants are simply returned the funds which they have previously brought into this market, and all bets/trades up to this point are considered void. In the process, User-Market accounts can be closed, and the SOL 'rent' automatically returned to participant's wallets.

No fees or revenue share are taken when a market is voided.