Aver Account Model
The Solana account model revolves around data (or 'state') being stored on accounts on the blockchain. These accounts are 'owned' by a program (in this case, the Aver Market program).
This section is intended to set out how these accounts are related, and how they can be used to represent information at global, market and participant/user specific level.
Overview
User Specific Accounts
User's Wallet
This is the main 'wallet' account for a given user, to which they have access to the keypair and are able to sign and authorize transactions.
All other 'user specific' account types will be specific to a given wallet - the wallet from which authorization will be required in order to take action related to these accounts.
User-Host-Lifetime Account ('UHLA')
This account type is unique by user/participant wallet and the host through which they operate.
This account is required to be created on the first occasion a wallet interacts with the Aver protocol via a particular 'host' - i.e. a client. This might be a webapp, or some other sort of tooling to facilitate interaction with the protocol.
For example, it will be required to be created the first time a user interacts with the web application hosted at app.aver.exchange or via the Python or Typescript SDK while passing default host account.
This account is used to store on-going information about the specific wallet's interaction with the protocol (via a given host) through time. For example, capturing volumes traded or entitlements to benefits and fee discounts.
The SDKs come with a default host pubkey included (the same host used on app.aver.exchange) which has no additional revenue share or fees implicit.
User-Market Account ('UMA')
User-Market accounts are unique to a given user* and market. They track key values required to represent a specific users positions, orders and balances within a given market.
When a user first interacts with a market (i.e. places their first order) one of these accounts are created, so that their order (and subsequently the resulting positions) can be represented and stored on-chain.
*Strictly speaking, a UMA is unique by User-Host and Market, since a user is not able to have more than one UMA for a given market. They will instead store positions for a given market on a UMA at attributed to the Host they first interacted with the Market through.
Markets Specific Accounts
Market instances facilitate trading and settlement of predictions for a given result of a certain event. Markets are represented by a number of accounts on-chain, but can be considered to represent any information necessary which is not specific to any given participant.
Market (Primary) Account
The Primary Market account describes the event, the type of result being speculated upon, the possible outcomes which can be traded, the timing of events and the terms of the market. Metrics which are required to be tracked are also stored within this account state - for example, open interest, active users interacting with the market.
Market Store Account
The Market Store account acts as a reference index for the other accounts belonging to this market which are required to enable its functioning. This includes reference to the four orderbook accounts required for each outcome in the market. It also contains a number of market parameters which are required while trading remains active on the market - for example, trading limits.
Orderbook Accounts
Orderbook Primary
A required account which ties the other orderbook accounts together. One of these exists per outcome traded on the market.
Orderbook Bids & Asks Slabs
Two accounts are required per outcome within the market to store the open orders on the bids (backs) and asks (lays) sides of the orderbook.
Orderbook Events Queue
This account stores the matched trades which are required to be processed by the program to update participant's accounts to represent the results of the match.
Vault Account
The vault account is a token account which is controlled by a program derived account. This means that funds can be removed from this account only by programmatically driven logic (i.e. it's not possible for a user or authority to access funds from the vault, other than via the logic encoded in the Aver Market program).
This account stores the tokens which are brought into the market to back trades made on outcomes in the market. When users are entitled with withdraw funds from the market, or when the market resolves and funds are to be paid out to winners, the program releases these funds from the vault.
Other Accounts
Host Account
As a decentralized protocol, it's possible to interact with Aver through different front-ends or developer tools. A 'host' is responsible for maintaining these gateways to the protocol and in return receive a share of revenue generated through interaction with the protocol via their gateway.
For example, a host may offer a bespoke front-end or application which caters for a particular niche or markets or users.
Host accounts are used to store and represent the conditions under which a host operates - for example, specifying the marginal fees charged by the host (if applicable) and the terms offered to referrers.
The web application hosted on app.aver.exchange is a 'host', and is recommended as the default host for interacting with Aver programmatically (as it does not carry any additional host mark-up), which may be the case when interacting via other gateways. For this reason you will find the host account defaulted to the aver.exchange host account in the Typescript and Python SDKs.
Referrer Account
A referrer account is used to represent information about the relationship between the wallet that referred other participants and the one-or-more participants that were referred by this wallet.
Versioning
Aver is built to be as backwards compatible as possible, recognising that updates may occur in the future to add additional functionality.
As a result, sometimes accounts may have different versions (e.g. - MarketV0 or MarketV1). Both the Aver Smart Contract as the SDK are written to handle all of this for you. The correct version is automatically loaded based on the public key of the account and parsed correctly.
Sometimes, you will receive a warning if the SDK detects any changes to the smart contract - it will prompt you to upgrade to the latest version of the SDK.
Additionally, if placing an order on an older version of a UMA, you will need to 'upgrade' your account to the latest version. As expected, all of this is automatically done for you as soon as you try to place an order.
Last updated
