Market and Trading Info

What price determination methods are used in the protocol?

When a market is proposed on testnet, a default trading mode is specified (currently only a limit order book with continuous trading is available). In the future, other trading modes will be available, such as discrete trading via frequent batch auctions, request for quote (RFQ) and AMM hybrid order books.

During continuous trading, if the market is triggered into a suspended state due to price monitoring or liquidity monitoring, the trading mode will change and the market enter a protective auction. Opening auctions are also used as a price determination method before the market is launched.

Can you earn interest on money held in Vega?

We don’t currently offer interest on either deployed or undeployed funds in the Vega smart contract. However, this is on the roadmap, with ongoing discussions on how to integrate lending protocols to provide this service.


Fees: What are the fees for trading on Vega Fairground, and who gets the fees?

Vega does not charge gas fees, but rather uses a different fee structure that rewards participants that make Vega possible. Fees are incurred on every trade on a market in continuous trading, but it is the price taker who pays the fee. During a market’s opening auction, no fees are collected.

The price taker is the party that traded using a market order, or placed a limit order that traded immediately. The price maker (the party whose passive order was on the book prior to the trade) obtains part of the fee as a reward for providing liquidity, see below for more details.

An order may cross with more than one other order, creating multiple trades, which incur fees for each. Because of how the trade value for fee purposes is calculated (see below), the amount you’ll pay for each order is the same, regardless of how many trades it takes to fill the order.

Fees are calculated and collected in the settlement currency of the market, and collected from your collateral. The fee is divided between the maker, the infrastructure provider, and the liquidity provider(s) for each market. In this version of the testnet, Vega fills the role of infrastructure provider, but that will not be true in future versions. On Vega Console, you can find the fees per market in each market’s Info view.

  • Infrastructure portion of the fee, which is paid to validators as a reward for running the infrastructure of the network, is transferred to the infrastructure fee pool for that asset. It is then periodically distributed to the validators.
  • Maker portion of the fee is transferred to the non-aggressive, or passive party in the trade (the maker, as opposed to the taker).
  • Liquidity portion of the fee is paid to market makers for providing liquidity, and is transferred to the market-maker fee pool for the market.

The fees come out of your testnet collateral, meaning there is no real-money fee. However, this should help you understand how fees can impact your collateral.

Fees: How are trading fees calculated?

The trading fee is calculated using the following formulas:

  • Total fee = (infrastructure fee factor + maker fee factor + liquidity fee factor) x Trade value for fee purposes
  • Trade value for fee purposes = notional value of the trade = size of trade x price of trade (This is true for futures, but may be calculated differently for other products.)


If you were to place an order for 100 futures at USDC50, the trade value for fee purposes is 100 x USDC50 = USDC5000.

In this example, each fee is 0.001, meaning total fee factor is 0.003.

USDC5000 x 0.003 = USDC15

The fee is the same irrespective of the number of transactions the order gets filled in, as long as they trade at the same price.

On Vega Console, you can find the fees per market in each market’s Info view. To estimate the trading fees for a potential order using the APIs, please see the how-to section under Fees and margins

The liquidity fee factor is submitted by liquidity providers when they place liquidity commitments. Read more about liquidity fees.

The other fee factors are set through the following network parameters: market.fee.factors.infrastructureFee, market.fee.factors.makerFee.

Market information view

Trading rewards

In addition to fees incentivising liquidity provision, passive orders, and infrastructure maintenance, participants can also fund rewards to incentivise certain trading activities on a market (or markets).

Participants can choose to incentivise activity by choosing what type(s) of activity they want to reward, how much to reward those who take part, and for how long.

Trading rewards framework

The reward framework provides a mechanism for defining, measuring and rewarding certain trading activities on the Vega network. Any Vega network participant with assets can use the rewards functionality to incentivise behaviours they would like to see in a market.

Rewards are independent from fees, which are paid to validators, liquidity providers, and price makers on each trade.

Trading rewards metrics

As rewards are distributed based on certain criteria, those criteria need to be defined and measured. Each of the reward metrics is calculated per party, and once at the end of each epoch.

Rewards can be defined to pay out to those who receive fees (functioning like a ‘bonus’), or those who create markets.

Fee-based reward metrics

Fee-based rewards metrics are designed to incentivise trading volume on a given market, and are dependent on how much a participant pays in fees.

Targets for rewards can be set based on one of three categories:

  • Sum of the maker fees a party paid
  • Sum of the maker fees a party received
  • Sum of liquidity fees a party received

Each is calculated per market, and assessed per party, relative to the total sum of fees across all parties for the given market.

When incentivising based on fees paid/received, any participant who, for example, places a market order that is filled, will receive a proportion of the reward amount available.

Example: Traders on Market X are eligible for rewards based on maker fees paid.

Party A, trading on Market X, has paid $100 in maker fees in one epoch.

The total maker fees paid by all parties in that market is $10,000.

Party A would receive $100 / $10,000 = 1% of the rewards for that epoch.

Market creation reward metric

The market creation reward metric is designed to incentivise successful market creation.

Rewards are awarded to the proposers of any markets that meet a certain total trade value in a given epoch. The threshold required is set by the network parameter market.liquidityProvision.minLpStakeQuantumMultiple, and can be changed via governance vote.


In a given epoch, 4 markets all reach $10,000 total trade value, which is the threshold value set in the network parameter.

The proposers of each of those markets qualify for 25% of the market creation reward for that epoch.

Reward pools

Reward pools hold the funds that are used to pay out trading rewards, and are funded by participants through transfers.

At the end of each epoch, all reward pools will be emptied and their funds allocated to users proportionally based on the reward metric defined for each pool.

It is up to individual users to transfer funds to the reward pools in order to finance the rewards they want to pay. If there is no balance in the reward pool at the end of the epoch, then no rewards will be paid.

When transferring funds, providing the following information determines that your funds go into the correct reward pool:

  • Reward asset: The asset in which the rewards will be paid
  • Market in scope: The Market ID of the market for which rewards will be calculated
  • Reward metric type: The metric type to be used to calculate the reward


An early liquidity provider who supports the ETH / USDT 1Y Future market wants to encourage people to trade on the market, and as an early adopter of Vega wants to incentivise people to hold VEGA too. That provider would transfer their chosen amount of funds to the relevant reward pool.

Reward Pool 1:

  • Reward asset = VEGA
  • Market in scope = ETH / USDT 1Y Future (defined by Market ID)
  • Reward metric type = Maker fees paid

This reward pool will transfer VEGA to anyone acting as a price taker and therefore paying maker fees on the market.

They may later decide that they have successfully driven so much volume that they would like to encourage more liquidity in the market to help supplement their own. In this case they could fund another reward pool.

Reward Pool 2: Reward asset = VEGA Market in scope = ETH / USDT 1Y Future Reward metric type = Liquidity fees

This will provide an additional incentive for LPs to commit liquidity, since in addition to the liquidity fees they would already receive (in USDT, the settlement asset of the market), they would also receive VEGA proportional to the share of liquidity fees they received for the market.

Finally, they may decide that they also want to provide a reward in the market’s settlement asset rather than solely reward in VEGA. Therefore they transfer funds to an additional reward pool.

Reward pool 3: Reward asset = USDT Market in scope = ETH / USDT 1Y Future Reward metric type = Maker fees paid

Now, any user that has been a price taker in this market will receive two reward payments at the end of the epoch, once in VEGA and one in USDT, with both proportional to their overall share of maker fees paid in the market.

Funding reward pools

Transfers are used to send assets to reward pools, and those transfers can be set up to transfer an asset just once, or for each epoch.

If a user wishes to provide a one-off reward in a single epoch only, they can do this by making a single transfer into the relevant reward pool.

If a user wishes to fund a single reward pool over multiple epochs, they can do this by setting up a recurring transfer to a single reward pool to keep topping up the reward pool for each epoch.

Another option is to regularly top up multiple reward pools across multiple markets, for a single metric and reward asset, by setting up a recurring transfer to multiple reward pools.

Each epoch, the funds will be paid into each reward pool proportionally based on the contribution of each market to the metric in scope.

Note: a multiple market recurring transfer can only be used for markets that settle in the same asset, since otherwise they cannot be compared.


A participant wants to incentivise trading on three new markets, all of which have the same settlement asset. They can create a transfer that will top up the reward pools for those markets that accept VEGA as a reward and that calculate based on the ‘maker fees paid’ metric.

  • Reward Pool 1: Reward Asset = VEGA | Market ID = A | Metric Type = Maker fees paid
  • Reward Pool 2: Reward Asset = VEGA | Market ID = B | Metric Type = Maker fees paid
  • Reward Pool 3: Reward Asset = VEGA | Market ID = C | Metric Type = Maker fees paid

All 3 markets settle in USDT. The rewards will be split to each market proportionally based on how much was paid out in maker fees for each market, and then each market’s pool will be split proportionally between users who paid maker fees in each defined market.

In the current epoch:

  • Market A has 200 USDT in maker fees paid
  • Market B has 100 USDT in maker fees paid
  • Market C has 700 USDT in maker fees paid

The user sets up a recurring transfer for 10,000 VEGA into the three reward pools above.

  • Reward Pool 1 share: 200 / (200 + 100 + 700) = 0.2 x 10,000 = 2,000 VEGA
  • Reward Pool 2 share: 100 / (200 + 100 + 700) = 0.1 x 10,000 = 1,000 VEGA
  • Reward Pool 3 share: 700 / (200 + 100 + 700) = 0.7 x 10,000 = 7,000 VEGA

Each reward pool is then distributed to individual parties as per the logic described in the Reward pools section.

Order types

What order types and time in force values are available to trade on Vega?

There are currently three order types available to traders: limit orders, market orders, and pegged orders. There is one order type that is automatically triggered to close out positions for distressed traders - called a network order.

A limit order is an instruction that allows you to specify the minimum price at which you will sell, or the maximum at which you will buy.

Times in force available for limit orders:

  • GTC - A Good til Cancelled order trades at a specific price until it is filled or cancelled.
  • GTT - A Good til Time order is a GTC order with an additional predefined cancellation time.
  • GFN - A Good for Normal order is an order that will only trade in a continuous market. The order can act like either a GTC or GTT order depending on whether the expiry field is set.
  • GFA - A Good for Auction order will only be accepted during an auction period, otherwise it will be rejected. The order can act like either a GTC or GTT order depending on whether an expiry is set.
  • IOC - An Immediate or Cancel order executes all or part of a trade immediately and cancels any unfilled portion of the order.
  • FOK - A Fill or Kill order either trades completely until the remaining size is 0, or not at all, and does not remain on the book if it doesn’t trade.

A market order is an instruction to buy or sell at the best available price in the market.

Market orders can use either IOC or FOK.

A network order is triggered by the Vega network to close out a distressed trader, as part of position resolution. Note that network orders cannot be submitted by a party.

Network orders use FOK market orders.

Pegged orders are orders that are a defined distance from a reference price (i.e. best bid, mid and best offer/ask), rather than at a specific price, and generate limit orders based on the set parameters. Currently, pegged orders can only use GTC and GTT times in force, but IOC and FOK will be available in a future release. Read more about pegged orders below.

Pegged orders

Rather than being set for a specific limit price, a pegged order is a defined distance from a reference price (such as the best bid, mid, or best offer/ask), and that’s the price against which the final order price is calculated. The reference price is based on the live market, and the final price is calculated and used to insert the new order. The distance is also known as the offset value, which is an absolute value that must be cleanly divisible by the tick size, and must be expressed as a positive integer.

A pegged order is not placed on the order book itself, but instead generates a limit order with the price generated based on the reference and offset value. As the price levels in the order book move around, the order’s price on the order book also moves.

Pegged orders can be amended like standard limit orders - their reference, offset and time in force values can all be amended. If amending an order cannot be performed in-place, the order will lose time priority in the order book (but will keep its priority in the list of pegged orders). Amends must be done to the pegged order itself, not any limit orders derived from pegged orders.

There are some situations in which pegged orders are parked, or moved off the order book, until the market returns to a state that allows pegs, or the orders are cancelled or expire. When orders return to the book, they are re-priced based on current market prices, sorted by their original entry time. If the primary trading mode of a market doesn’t allow pegged orders (such as an auctions-only market), then the pegged orders are rejected.

Those situations include:

  • Auctions - pegged orders are only valid during continuous trading
  • When the reference price does not exist (e.g. no best bid)
  • The price moves to a value that means it would create an invalid order if the offset was applied

Pegged orders are restricted in what values can be used when they are created, these can be defined by a list of rules each order must abide with. Note: IOC and FOK are not currently available for pegged orders, but will be in a future release.

Type (Time in Force) Side Bid Peg Mid Peg Offer Peg
Persistent (GTC, GTT) Buy <= 0 < 0 Not allowed
Persistent (GTC, GTT) Sell Not allowed > 0 >= 0
Non persistent (IOC, FOK) Buy > 0 > 0 >= 0
Non persistent (IOC, FOK) Sell <= 0 < 0 < 0

Order status

If you don’t have enough collateral to fill the margin requirements on an order, it will show up as ‘Rejected’. If you cancel an order, the status will be listed as ‘Cancelled’, and if the the network cannot fill an order, based on the parameters you set, for example, then the order will show up as ‘Stopped’. The following charts explain the order types and the statuses that they’ll show, based on what happens in the network.

Fill or Kill

Time In Force Filled Resulting status
FOK No Stopped
FOK Yes Filled

Immediate or Cancel

Time In Force Filled Resulting status
IOC No Stopped
IOC Partial Partially Filled
IOC Yes Filled

Good til Cancelled

Time In Force Filled Cancelled by user Stopped by network Resulting status
GTC No No No Active
GTC No No Yes Stopped
GTC No Yes No Cancelled
GTC Partial No No Active
GTC Partial Yes No Cancelled
GTC Partial No Yes Stopped
GTC Yes No No Filled

Good til Time

Time In Force Filled Expired Cancelled by user Stopped by network Resulting status
GTT No No No No Active
GTT No Yes No No Expired
GTT No No Yes No Cancelled
GTT No No No Yes Stopped
GTT Partial No No No Active
GTT Partial Yes No No Expired
GTT Partial No Yes No Cancelled
GTT Partial No No Yes Stopped
GTT Yes No No No Filled


Can you use any type of collateral on Vega? Is there a way to convert currencies on Vega?

On mainnet, you will have to use the settlement currency of the market you want to trade on. You’ll need to deposit, or lock, the settlement asset funds into the bridge for the assets. See a step-by-step guide for depositing on Vega Console.

For example, if you only have Bitcoin, but the market you want to trade on uses Ethereum as the settlement asset, you can use a service outside Vega to convert Bitcoin to Ethereum to use as collateral. We may eventually include support for converting between all the currencies supported by Vega, within the protocol itself.

How do deposits and withdrawals work?

Currently, you can deposit ERC20 testnet assets that will be used in Vega into an Ethereum contract. The funds in that ethereum contract will then be made available to the parties you registered with the network.


To start, all testnet markets are “cash” settled futures. This means that settlement occurs in the (testnet) settlement asset of the market, which is defined in the market framework. The settlement asset does not need to be the same asset as the ‘quote unit’ (i.e. ETH on a BTC/ETH December 2020 market). The settlement asset is defined by the market creator.

You can see the settlement asset in Vega Console in the market details view. (Search for ‘info’). When trading through APIs, you can call up the market data.

Mark to market settlement Settlement instructions are generated based on the change in market value of the open positions of a party.

When the mark price changes, the network calculates settlement cash flows for each party.

Each time the mark price for a given market changes, all the open positions and orders are marked to market, resulting in interim partial payments that are calculated by the network.

Settlement at a market’s expiry When a market reaches its maturity date and time, a final settlement is carried out based on a pre-defined oracle publishing data that triggers the market’s expiry.

The oracle trigger will cause the market to enter into a “trading terminated” state. Markets in this state no longer accept trading, but retain the positions and margin balances that were in place after processing the market’s maturity trigger. In the case of futures markets, termination occurs just prior to, or at, the settlement of the product.

Once a market settles, all open positions in that market are closed based on final oracle price, open orders are cancelled, and all collateral held in the market is released back to the participants. Corresponding cash flows happen as defined by the product type.

For example: A cash-settled futures market reaches its expiry date and time. If the last mark price before settlement is 100, but the oracle price feed emits data that the price is 115, then a trader with a position of 1 long is paid 15. Another trader that has a position of 1 short, pays 15.

After all positions are closed at market expiry, they are ‘forgotten’ by the network.

Settlement parameters defined through governance

  • When a market is proposed, the proposal must specify data sources for any settlement events that the product requires - for the currently available cash-settled futures, this is the final price/value at the expiry of the instrument, and the expiry date/time. If the market passes governance and is thus created, the market will go live.
  • Eventually the market will near its specified expiry, and trading terminates. The data sources provide the final ‘settlement value’. (In future, Vega will allow optional mechanisms for querying, verification, or dispute resolution that are independent of the source.)
  • Vega settles all open positions on the market using the price provided by the data source. Fairground’s cash settled futures are regularly mark to market settled, so the final settlement is simply a case of the protocol doing a final mark to market settlement using the data source price.

Data sources (oracles) for settlement

The Vega network runs on data. Market settlement, risk models, and other features require a supplied price (or other data), which must come from somewhere, usually completely external to Vega. Specifically for settlement values, Vega requires external data.

Vega APIs and protocol capabilities support a wide range of data sourcing styles and standards, and Vega will not integrate directly with specific oracle / data providers at the protocol level. This framework is flexible to make it easy to create and combine oracles, and therefore to design markets on almost anything.

The current implementation requires that a market proposal defines two data sources, and the price based on those sources is final.

Data source requirements

Multiple instruments can rely on the same data source, and can settle based on the same SubmitData message.

Data sources must provide:

  • Type of data source (signed message, internal Vega market data, date/time, Ethereum, etc.)
  • Data type (e.g. float for a price) - this must be compatible with the usage of the data source (if it is a settlement price, a numeric value would be required; for a trading termination trigger which consumes no data then any data type, etc.). Note that it is possible to have more than one “compatible” type, for instance it might be that a number could be a string or a raw numeric value in a JSON data source.
  • Data source specific details (for signed message, public key of sender; for Ethereum, contract address, method name; etc.)

Data sources must be able to emit the following data types:

  • Number (for prices or in filter comparisons)
  • String (to be used to compare against in filters)
  • Date/Time (to compare against in filters)
  • Structured data records, such as a set of key value pairs (inputs to filters)

Data sources nominated for use by Vega may refer to other data sources. For instance, one that takes a source of structured data records as input and emits only the value of a named field (e.g. to return BTCUSD_PRICE from a record containing many prices) or one that takes another data source as input and emits only data that matches a set of defined filters (e.g. to return only records with specific values in the timestamp and ticket symbol fields).

Data sourcing framework

Vega supports three data source types, though not all three can be used to settle markets. Internal data sources cannot be nominated for settling a market, but are used to emit an event or value at/after a given Vega time to trigger “trading terminated”, for example.

Data sources must be able to emit the following data types:

  • Number
  • String (for MVP these would only be used to compare against in filters)
  • Date/Time (for MVP these would only be used to compare against in filters)
  • Structured data records i.e. a set of key value pairs (for MVP these would be inputs to filters)

Signed message data sources are the first external data source to be supported on Vega, and can be nominated for settling a market. Signed message data sources introduce a Vega transaction that represents a data result. The result is validated by ensuring the signed message is signed by one of a set of public keys provided in a market’s proposal.

Currently on Fairground, signed message data sources require only one of the specified keys to sign and submit the data transaction. It will only be possible to construct external oracles in which one or more third party entities/systems must be trusted, but this will change with future work.

A signed message data source must include:

  • Public keys (and key algorithm to be used if required) that can sign and submit values for this oracle
  • Type of data to be supplied in the transaction. Supported types are a simple native Vega transaction (i.e. protobuf message) containing one or more key/value pairs of data fields with values that are expressed in the data types listed above
  • ABI encoded data

As a public key may provide many messages, a filter is likely to be needed to extract the required message, and a field select would be used to extract the required field (‘price’ or ‘temperature’, etc.).

Note: There are no rewards associated with being a signed message data source, nor are there fees associated with being or using a signed message data source.

A filtered data source includes another data source definition within its own definition, and outputs a modified stream of data. It contains one or more conditions that are applied to data to determine whether that data is emitted.

Multiple products can filter the same data source differently and settle based on different SubmitData messages. Multiple products can filter the same data source differently and settle based on different fields from the same SubmitData message.

A filtered data source must specify:

  • Data: Another data source that defines the input data
  • Filters: A list of at least one filter to apply to the data

A filter specifies a condition to apply to the data. If all filters match, the data is emitted. The filter types are defined in the Operator field of a market proposal.

Filter condition types:

  • Equals: Data must exactly match the filter, i.e. Equals key = ticker, value = TSLA
  • Greater / greater or equal: Data can be greater than or equal to the filter, i.e. GreaterOrEqual key = timestamp, value = 2021-12-31T23:59:59
  • Less / less or equal: Data can be less than or equal to the filter, i.e. LessOrEqual key = timestamp, value = 2021-12-31T23:59:59

Margin and leverage

What leverage can I achieve on Vega Fairground?

The available leverage depends on the market, the risk model in use, and the state of the order book. You can find details in the market info view, by searching (Shift + s) for ‘info’ in the Vega Console (example screenshot below) and also in the margin calculation diagram seen in What happens to margin when a trader puts a trade on?.

What happens to margin when a trader puts a trade on?

Vega’s margining system implements automated cross margining. Cross margining, which means gains on one market can be released and used as margin on another, is supported between all markets. More detailed explanation is available in Section 6 of the protocol whitepaper. However the basic calculation is relatively straightforward.

Vega works with four margin levels:

  • Search level: When the margin balance drops below the search level (but is still above the maintenance level) the network will try to allocate an additional amount (up to the current initial margin level) from your collateral, if possible, to be used for margin:
    • msearch := αsearch * mmaintenance, where αsearch is a constant and αsearch > 1.
  • Initial level: The amount that will be transferred from your collateral to be used as margin when an order is placed or trade executed. To avoid a margin search as soon as position is open, the initial margin level is set above the search level:
    • minitial := αinitial * mmaintenance, where αinitial is a constant and αinitial > αsearch.
  • Release level: Once a trader’s margin balance exceeds the margin release level, the position is considered overcollateralised and funds are released back to collateral so that the margin balance is equal to the current initial margin level:
    • mrelease := αrelease * mmaintenance, where αrelease is a constant and αrelease > αinitial.
  • Maintenance margin: This is implied by the risk model and corresponds to the minimum amount required to cover adverse market moves with a given probability level. As soon as the margin balance drops below the maintenance margin level, the position close-out process gets initiated.

Margins on open orders Vega will charge margin on open orders, because if your order gets hit you will need the margin to keep it open. The protocol shouldn’t allow you to enter a trade that will immediately need to be closed out. The liquidity you see on the order book should also be real, in that sense that it’s supported by collateral and thus available to trade.

Calculating the margin on open orders Vega calculates the largest long / short position. If the long is the riskiest, the margin algorithm multiplies by a ‘risk factor long’ and by the ‘mark price’ (for futures). If it is the short, then the algorithm multiplies the position by the ‘risk factor short’ and by the ‘mark price’. These capture the outcome of probabilistic distribution of future market moves, and are market specific.

Example: (see explanation below screenshot)

Calculating margin on open orders

There is an open sell order of size 1 on the book. The risk factor for short positions is 0.074347011. The current mark price is 0.02690. So minimum margin = 0.2690 x 0.074347011 = 0.00200 (rounded to 5 decimal places).

Margin on open positions Here the calculation is a little more complicated as it takes into account “slippage” as seen currently on the order book.

Example: (see explanation below screenshot)

Calculating margin on an open positions

The trader has an open short position of size 1 and no open orders. The risk factor for short positions is 0.074347011. The current mark price is 0.02672. The best offer price is 0.02676 and it has enough volume so that theoretically the position could be closed-out at that price. So maintenance margin = 0.02672 x 0.074347011 + max (0, 0.02676 - 0.02672) = 0.00203 (rounded to 5 decimal places), where the second term in the sum is the “slippage” component. Other margin levels are derived from the maintenance margin using the scaling factors that form part of the market configuration.

To estimate the margin levels for a potential order using the APIs, please see the how-to section under Fees and margins.

What happens if there’s a big swing against a trader?

In most cases, the allocated margin should cover market swings. If the swing is bigger than the margin is collateralised for, then money is pulled from the collateral to cover the requirement. If a trader has no more collateral, and their allocated margin is below the maintenance margin, the trader gets closed out and any margin balance remaining after the close-out is transferred to the market’s insurance pool. In the unlikely event that the insurance pool balance is insufficient to cover the entire balance, loss socialisation will get applied.

Note that price monitoring should assure that large swings occur only due to genuine changes in market participants' view of the true average price of the traded instrument and not as a result of short-lived artefacts of market microstructure.

What is the insurance pool?

Each market has its own insurance pool set aside. However, there’s also a general insurance pool per asset. It sits there until there are markets that use that asset. When a market expires, the insurance pool funds from that market go into the bigger insurance pool, which other markets that use the same collateral currency can pull from. Insurance pools grow in two scenarios: if a trader gets closed out, and if a liquidity provider pays a fine for failing to provide their committed liquidity. Read more about liquidity provision.

If a trader’s deployed margin on the market is insufficient to cover a mark to market (MTM) settlement liability, Vega will search the trader’s available balance of the settlement asset. If this search is unable to cover the full liability, the trader will be considered distressed and undergo position resolution, and the market’s insurance pool (for that settlement asset) will be utilised to make up the difference required to cover the MTM loss amount. Should the funds in the insurance pool be insufficient for that, loss socialisation will be applied.

The current insurance pool balance and a graph of the 24-hour history of the balance can be seen on Vega Console by searching for “info” for a market, or by clicking on Details in the Futures view for the market you want to see.

What is loss socialisation?

It is theoretically possible for there to not be enough funds in the insurance pool to fully cover the mark to market (MTM) losses. In that case, MTM gains get proportionally scaled down so that all of those for whom the most recent market move was favourable make a slightly smaller profit than they otherwise would have. This process is called loss socialisation and serves to spread the counterparty default risk across open positions. The first implementation on Vega simply prorates according to open position size.

Auction trading mode

Auctions: How does a new market obtain a fair price at the start of trading?

All markets created through governance will enter an opening auction at their enactment time, to determine a fair price for the start of continuous trading.

Auctions: How do I know if a market is in an auction?

On Vega Console, there will be indications that a market is in auction across the different views. Those include the futures markets, open orders, open positions, deal tickets, depth charts, market details, and order book views. You’ll see a gavel icon, and/or information about the auction, such as when it ends, and the uncrossing price and uncrossing volume once they’re known.

On Vega Console you can switch back to the normal deal ticket, but not all the Time in Force options will be relevant for trading in an auction, and your order will be rejected if the TIF you choose does not work in an auction.

When programmatically querying for market information, the market data will make it clear if the market is in auction, what type of auction it is, and if applicable, when the auction is scheduled to end.

It’s also worth noting that during an auction, while there will be a best bid / offer price along with volume and a mid price, the prices may be crossed (meaning the bid can be higher than the ask).

Auctions: What happens in an opening auction?

When a market on Vega first goes live, an opening auction determines a fair mid-price to start off continuous trading. Auctions aggregate participation over time, up to a pre-set time when the market is uncrossed. The auction uncrossing generates trades at the conclusion of the auction, using an algorithm that processes, in price-time priority, the set of crossed orders that maximises traded volume. Initially, the market will use the mid-price within the range of auction bids that would result in the highest trade volume.

For example, if the volume maximising range is 98-102, the market would price all trades in the uncrossing at 100. The order book would then be uncrossed at that price and the trades follow the normal flow, except no fees will be taken.

In implementations to come, other options will be available via a network parameter specified at market creation, and then changeable through a governance action. See a full list of the current network parameters.

In continuous trading, the order book is always crossed, and you won’t see bids and asks at the same level and at the same time, but when a market is in auction, the order book will show you where there’s an overlap, indicating which bids and asks cross.

On Vega Console, you’ll receive notifications when a market you’re trading in changes state, and if your order was filled, or unfilled, at an auction’s uncrossing.

Auctions: How long is an opening auction?

A new market’s opening auction begins at: the proposal’s closing date / time, and ends at: the market’s enactment date / time, both as specified in the market proposal.

You can also find out the duration of the market’s opening auction by querying the market data, using the APIs.

On Console, you’ll be able to see how long is left in an opening auction in the market’s deal ticket and Info view.

Auctions: What kinds of orders can I place in an opening auction? What happens to orders that aren’t filled at the end of an auction?

You can opt to have an order that’s only valid for the auction, or you can opt to have the orders stay on the order book after the auction, if they’re not filled when the auction ends. There is one auction-only time in force, Good for Auction (GFA). If orders using GFA are not filled during the auction, they are cancelled.

Good til Cancelled (GTC) and Good til Time (GTT) orders are valid in both auction and continuous trading modes, and will stay on the order book after an auction. Just like in continuous trading, you can amend or cancel orders during an opening auction. Your order will be rejected if you try to place a market order, or a limit order with a time in force of Good for Normal (GFN).

Auctions: What is a price monitoring auction?

A market will go into a price monitoring auction if generating a trade would result in a price that is larger than the theoretical bounds implied by the risk model and the market’s price monitoring settings. In that case, the trade doesn’t get generated, the orders that instigated that trade remain on the order book, and the market goes into an auction of the length implied by the price monitoring settings. For details please see the price monitoring section.

Auctions: What is a liquidity monitoring auction?

A market will go into a liquidity monitoring auction if the total commitment from liquidity providers (total stake) drops too low relative to the estimate of the market’s liquidity demand (target stake). More specifically, the market will go into a liquidity auction if:

total_stake < market.liquidity.targetstake.triggering.ratio x target_stake,

where market.liquidity.targetstake.triggering.ratio is a network parameter.

The market will also go into a liquidity monitoring auction if the best bid and/or best ask price implied by limit orders from market participants are not available.

The market will finish the liquidity auction once:

total_stake >= target_stake,

and both best bid and best ask as described above are available.

For more details on liquidity provision, and total stake and target stake, please see this section.

Auctions: Do auctions affect margin requirements?

Margin requirements for an order are different in auctions, as they are calculated based on price of orders, rather than on the mark price.

If, for example, you have a GTC limit order low in the order book during an auction, and your order is not crossed in the auction but makes it into continuous trading, your margin requirements may quickly change.


Governance: Life cycle of a proposal

  1. A governance proposal is submitted to the network.
  2. The network validates or rejects the proposal.
  3. If the proposal is valid, the network holds the proposal active for the proposal period set by the market’s proposer.
  4. During the proposal (voting) period, network participants who are eligible to vote on the proposal may submit votes for or against the proposal. We suggest you submit your market idea, and its proposal ID if you’ve already proposed it, on the community forum.
  5. After the close date, set by the market’s proposer, the network calculates the vote outcome.
  6. If the market passes, it opens on the enactment date set by the market’s proposer.

lifecycle of a proposal

Governance: How to propose a market

Anyone with the minimum required amount of testnet governance tokens (VEGA) staked to a validator can propose a futures market on Vega Fairground. That proposal can then be voted on by those who have a VEGA (testnet) balance.

When you propose a market, you’ll define specific inputs for a set of parameters, and if all of the inputs pass validation, the market proposal will enter into the voting period you set. Right now, you can propose a market by using the APIs. Coming soon you’ll be able to propose markets using Vega Console.

A valid liquidity commitment transaction with a liquidity commitment amount no less than the minimum_proposal_stake_amount per-asset network parameter must also be included in the proposal.

Note that each testnet reset will also clear any markets that were proposed and enacted since the previous reset.

Market proposal fields

Below is a list of inputs, and an explanation of what each of them means on Vega. Some of them are constrained by parameters set for the network, and if the value you set isn’t within that constraint, then your proposal will not be validated. See the full list of network parameters, which will always have the most updated parameters.

  • Changes: The contents of a changes object specifies what will be different after the proposal. In this case, these are the changes that will occur on the network, in the form of a new market
    • Decimal places: Set the smallest price increment on the book
    • Position decimal places: Set how big the smallest order / position on the market can be
    • Vote close timestamp: Time chosen to trigger when voting on the market proposal ends. It must be within the time frame defined by the network parameters and
    • Enactment timestamp: Time chosen to trigger when the market, if voted in, opens for trading. It must be within the time frame defined by the network parameters and
    • Instrument: The inputs under instrument define how this new instrument will be configured. An instrument is fungible, and therefore a single instrument could be used to create different markets, though currently in testnet that would make for duplicate markets. An instrument consists of the features below
      • Name: This should be a full and fairly descriptive name for the instrument. Example: BTC/USD DEC28
      • Code: This is a shortcode used to easily describe the instrument (e.g: FX:BTCUSD/DEC28)
      • Future product: Right now you can only propose futures markets on Vega testnet. Under this is where you define the maturity and the asset for the market.
        • Settlement Asset: This defines the asset (available on Vega) that the market will be margined in and settle in. You can get a list of supported assets by querying REST, GraphQL, or gRPC, and then select the ID of the asset
        • Quote name: The quote name represents the counter asset in a pair. For example, in BTCUSD, USD is the quote
        • Settlement Price Decimals: The number of decimal places to be used for the settlement price
        • Oracle spec for settlement price: This defines the data source that will be used to identify the settlement price when the market expires
          • Pub keys: Public key(s) that can sign and submit values for this oracle
          • Filters: Filters define which oracle data is of importance for the purposes of the type of governance proposal
            • Key: Defines the specific type of information the oracle provides that are is relevant to the proposed market. Example: If an oracle provides a list of prices for various markets, focus only on the specific relevant price for the market
              • Name: Specific name of the information that the filter provides. For example, prices.ETH.value
              • Type: Specifies the data type that is emitted. For example, for the prices.ETH.value, the type is an integer, as it is output as a non-fractional number
            • Conditions: A filter for the oracle data. The conditions that should to be matched by the data to be considered. This is an optional set of fields. For example you could use an operator and a value to denote that a price should be greater than zero
              • Operator: This adds a constraint to the value, such as LESS_THAN, GREATER_THAN. For example if you wanted to ensure that the price would always be above zero, you would set the operator to ‘GREATER_THAN’ and the Value to be ‘0’
              • Value: A number that is constrained by the operator
          • Oracle spec for trading termination: The fields below define the oracle used for terminating trading on the market
            • Pub keys: Public key(s) that can sign and submit values for this oracle
            • Filters: Each filter’s properties are for a single type of data
              • Key:
                • Name: Name of the property that this defines, such as ‘trading.terminated’
                • Type: Type of output that is expected for the named data above. For example, for trading.terminated, the output is TYPE_BOOLEAN, because the required output must be true or false
              • Conditions: The conditions that should to be matched by the data to be considered. This is an optional set of fields. For example you could use an operator and a value to denote that a price should be greater than zero
              • Operator: This adds a constraint to the value, such as LESS_THAN, GREATER_THAN. For example if you wanted to ensure that the price would always be above zero, you would set the operator to ‘GREATER_THAN’ and the Value to be ‘0’
              • Value: A number that is constrained by the operator
            • Oracle spec binding: The below fields describe how specific information provided by the oracle data is used. For example, they can identify the specific name of the settlement price output, or the specific name of the trading termination property
              • Settlement price property
              • Trading termination property
    • Metadata: Metadata fields are optional free text field to provide richer metadata information about the market. You can include all or none, but the more information you include, the better
      • Base: Highlight the first currency in a pair for a currency-based derivatives market
      • Quote: Highlight the second currency in a pair for a currency-based derivatives market
      • Class: Describe the classification of the product. Examples: shares, commodities, crypto, FX
      • Sector: Data about the sector Example: ‘automotive’ for a market based on value of Tesla shares
    • Price monitoring parameters: This is an optional configuration for price monitoring for the market
      • Price monitoring triggers: The list of triggers that configures the acceptable price movement bounds for price monitoring
        • Horizon: Price monitoring projection horizon τ in seconds (>0)
        • Probability: Price monitoring probability level p. (>0 and <1)
        • Auction extension in seconds: Price monitoring auction extension duration in seconds should the price breach its theoretical level over the specified horizon at the specified probability level (> 0)
    • Liquidity monitoring parameters: The below fields are optional, and if empty will default to the network parameters
      • Target stake parameters: Target stake parameters are derived from open interest history over a time window (defined below) to calculate the maximum open interest. If left empty, they will default to the network parameters
        • Time window: Defines the length of time over which open interest is measured. If empty, this field defaults to the network parameter Example: 1h0m0s
        • Scaling factor: This must be set within the range defined by the network parameter, and defines the scaling between the liquidity demand estimate, based on open interest and target stake. The scaling factor must be a number greater than zero and finite
      • Triggering ratio: Specifies the triggering ratio for entering liquidity auction. If empty, the network will default to the network parameter market.liquidity.targetstake.triggering.ratio
      • Auction extension: Specifies by how many seconds an auction should be extended if leaving the auction were to trigger a liquidity auction. If empty, the network will default to the network parameter market.monitor.price.defaultParameters
    • Risk parameters: You need to define the new market’s risk configuration. For more on this read about the risk parameters below, but here’s a brief list of all the risk parameters you’ll need to set. They define how much margin everyone will need to have available for trades
      • Log-normal: Log-normal risk model input, using the log-normal risk model parameters. Read more about the log-normal risk model and its parameters
        • Risk aversion parameter: Lambda parameter of the risk model
          • tau: Tau parameter of the risk model
        • params: Parameters for the log-normal risk model
          • mu: Mu parameter
          • r: R parameter
          • sigma: Sigma parameter
  • New market commitment input: The liquidity commitment submitted with the new market, based on the parameters set below. A liquidity commitment must be submitted with each market proposal
    • Commitment amount: This number represents the amount of the settlement asset for the market, written without a decimal point but to 5 decimal places (for example 5.00011 should be expressed as 500011)
    • Fee: The liquidity-nominated liquidity fee factor, which is an input to the calculation of taker fees on the market
    • Liquidity order input - Sells: A set of liquidity sell orders to meet the liquidity provision obligation
      • Reference: The sell order’s reference point for its price level. (Examples: mid, best bid, best ask)
      • Proportion: The relative proportion of the commitment to be allocated at the reference price level, written as a positive integer
      • Offset: The number of units away from the reference to place orders. (Example: 2)
    • Liquidity order input - Buys: A set of liquidity buy orders to meet the liquidity provision obligation
      • Reference: The buy order’s reference point for its price level (Examples: mid, best bid, best ask)
      • Proportion: The relative proportion of the commitment to be allocated the reference price level, written as a positive integer
      • Offset: The number of units away from the reference to place orders (Example: 2)
  • Rationale: A free-text field that describes the purpose of the proposal

In order for a market proposal to successfully pass the governance, you’ll need to make sure you’ve received enough votes from other Vega Fairground users (and in the future, mainnet users). The best way to share your market ideas, and get the community motivated to vote for your proposal, is to share it on Vega’s community forum.

Governance: Markets you can propose

Right now, you’ll only be able to propose direct futures markets with a minimum order size of 1. In the future, we will permit inverse futures and fractional order increments. For example, if someone were to propose a BTC/DAI futures market quoted in DAI/BTC, the minimum order increment is 1 BTC and the market must settle in DAI.

Governance: Vote requirements for a market proposal to pass

For a market to be created, it must receive a percentage of the amount (or weighting) of yes votes of all the votes, and a minimum amount of the total available Vote tokens at the end of the proposal period must have voted. You can see the weighting of yes votes required in the network parameter

Governance: Risk models and parameters for a market proposal

When proposing a market, the market proposer will need to choose the risk parameters associated with the risk model that’s appropriate for the product. Find out more about the relationship between the product, instrument, and tradable instrument above. The purpose of the risk model is for the calculation of margins on the market. For a detailed explanation, read our Margins and Credit Risk on Vega paper (note a position size of 1 is assumed throughout it).

The first product available to create on Fairground is built-in, direct, cash-settled future. That product uses a log-normal risk parameter. Here are the parameters:

Risk parameters

Below are the risk parameters, the accepted values for each parameter and suggested values for some of them.

Please note the parameters should be chosen so that the risk model adequately represents the dynamics of the underlying instrument and so that the resulting margins strike the right balance between prudence and capital efficiency.

When suggested values are provided, these should be used as a reference point and to aid derivation of the value appropriate for the market being proposed, and not in place of rigorous analysis and calibration.

Model independent parameters used in margin calculation are:

  • Risk aversion lambda - probability level used in Expected Shortfall calculation when obtaining Risk Factor Long and Risk Factor Short:
    • accepted values: strictly greater than 0 and strictly smaller than 1,
    • suggested value: 0.001 - indicates the probability that the position value drops by more than its current value at risk at level lambda.
  • Tau - projection horizon measured as a year fraction used in Expected Shortfall calculation when obtaining Risk Factor Long and Risk Factor Short:
    • accepted values: any strictly non-negative real number,
    • suggested value: 0.000114077116130504 - corresponds to one hour expressed as year fraction.
  • Risk free rate - annualised growth rate of the risk-free asset, it’s used for discounting of future cash flows:
    • accepted values: any real number,
    • suggested value: 0.

The remaining, model specific parameters are covered in sections below.


The log-normal model assumes that the price of the underlying asset follows the process specified by the stochastic differential equation:

dSt = St(Mudt+SigmadWt), S(t) = s,

where Mu, Sigma and s are constants and dW represents a Brownian Motion increment. For any time in t in the interval (0,T] the model implies a distribution where the natural logarithm of price is normally distributed (hence the name Log-Normal).

  • Mu - annualised growth rate of the underlying asset:
    • accepted values: any real number,
    • suggested value: 0.
  • Volatility (Sigma) - annualised volatility of the underlying asset:
    • accepted values: any strictly non-negative real number,
    • suggested value: asset dependent, should be derived from the historical time-series of prices.

Maintenance margin calculation

The maintenance margin level for each order/position is calculated as:

mmaintenance := Position Size * (Net Closeout P&L + Market Observable × Risk Factor).

The Net Closeout P&L is the volume weighted (as seen on the order book) price of the trade that would be required to close the trader’s position minus the trade price (the price at which the relevant trade was entered). In case of open limit orders, this is equal to 0.

The Market Observable is any value that can be directly seen in the market, for example, for futures it is simply the current price at which the futures are trading and for options it is the current price of the underlying.

The Risk Factor is a number that will be calculated by an appropriate stochastic risk model, and will be different for long (Risk Factor Long) and short (Risk Factor Short) orders / positions.

The values of Risk Factor Long and Risk Factor Short depend on the type of risk model used and its parameters. They are chosen so that the maintenance margin is equal to the expected shortfall of an order/position at probability level lambda over the horizon tau - please consult Margins and Credit Risk on Vega for details. You can also read a brief overview about the margin levels and how they impact your collateral, above.

Market monitoring

Market monitoring modules keep track of transactions and execute appropriate actions to assure optimal price discovery and risk management characteristics of the market. They work deterministically and are controlled by both network and market parameters.

Price monitoring: How Vega handles large price shifts

The dynamics of market price movements are such that prices don’t always represent the participants' true average view of the price, but are instead artefacts of the market microstructure: sometimes low liquidity and/or a large quantity of order volume can cause the price to diverge from the true market price. It is impossible to tell at any point in time if this has happened or not.

As a result, we assume that relatively small moves are “real” and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. If the move is deemed to be large, the market’s trading mode is temporarily changed into auction mode to get more information from market participants before any trades are generated. Distinguishing between small and large moves can be highly subjective and market-dependent. We rely on risk models to formalise this process. A market’s risk model can be used to obtain the price projection at a future point in time given the current price. A price monitoring auction trigger can be constructed using a projection fixed time horizon and probability level.

Price monitoring behaviour is governed by a set of price monitoring triggers specified for the market. Each trigger contains:

  • Horizon: time horizon of the price projection in seconds.
  • Probability: probability level for price projection, e.g. value of 0.95 will result in a price range such that over the specified projection horizon, the prices observed in the market should be in that range 95% of the time.
  • Auction extension: auction extension duration in seconds, should the price breach its theoretical level over the specified horizon at the specified probability level.

If the market has no triggers specified in the market proposal then the default triggers driven by a network parameter will be used. If triggers are set to an empty array (either explicitly or if they are omitted and that’s what the network parameter is set to), then price monitoring is effectively switched off, and the market will never go into price monitoring auction irrespective of prices generated by trades.

In case of multiple triggers, each trigger is checked separately and the resulting price monitoring auction length will be the sum of auction durations from all the triggers that were breached. Furthermore, there could be a situation where only a single trigger is breached to begin with, but as the initial price monitoring auction period comes to an end, the indicative uncrossing price breaches one or more of the other triggers resulting in an auction extension. This process continues until no more triggers are breached after the appropriate auction extension period elapses (either because price doesn’t breach any other triggers or all triggers have already been breached - once a given trigger is activated it’s not checked again until the price monitoring auction is resolved and market goes back into its default trading mode).

Let’s work through an example:

  • Assume the market is configured to have two price monitoring triggers, where horizon, probability and auction extension for the two triggers are:
    • trigger 1: 1h, 0.95, 1min,
    • trigger 2: 2h, 0.99, 5min.
  • Assume that the current mark price and price history imply the following valid price ranges for the two triggers:
    • trigger 1: [95,105],
    • trigger 2: [90,110].
  • Any trades with prices greater than or equal to 95 and less than or equal to 105 will be generated as per the default trading mode of the market.
  • Now:
    • If an incoming order would get matched so that the price of any of the resulting trades is less than 90 or more than 110, then that order won’t get processed in the default trading mode, the market will go into a price monitoring auction, the order will get processed in the auction mode (if order type is valid for an auction), and after 6 minutes the relevant (if any) trades will be generated as per the order book state at that time. The market will return to its default trading mode and price monitoring bounds will be reset, with price ranges depending on the last mark price available.
    • If an incoming order would get matched so that the price in any of the resulting trades is in the [90,95] or [105,110] range, the market goes into a price monitoring auction with the initial duration of 1 minute.
      • If after 1 minute has passed there are no trades resulting from the auction or the indicative price of the auction, then if in the [95,105] the trades are generated and the price monitoring auction concludes.
      • If after 1 minute has passed the indicative price of the auction is outside the [95,105], the auction gets extended by 5 minutes, as concluding the auction at the 1 minute mark would breach the valid ranges implied by the second trigger. After the 5 minutes, trades (if any) get generated irrespective of their price (there are no more active triggers) and the price monitoring auction concludes.

As mentioned above, price monitoring is meant to stop large market movements that are not ‘real’ from occurring, rather than just detect them after the fact. To achieve that the module works preemptively: a transaction that would’ve caused the price monitoring bounds to be breached doesn’t get processed in the default trading mode, the market first switches to price monitoring auction mode and then that transaction (and any subsequent ones until the auction time elapses) get processed. Clearly, the market can still make a large move within the auction as long as crossing orders from both buy and sell side get submitted. The purpose of price monitoring is only to extract more information out of the market in the event of a large move and not to stop the market from making that move altogether.