Market and Trading Info

Market and Trading Info

What are the fees for trading on the Vega Testnet, 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 all of those roles, 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 in testnet 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.

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.

What leverage can I achieve on testnet?

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?.

Market information view

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.

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.

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 can be negative or positive.

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

What is the testnet Vote token?

Vote (or tVOTE) is Vega’s testnet governance token, which is used to vote for or against market proposals on testnet, and other governance actions in the future. During testnet, everyone will be re-allocated with a set amount of VOTE tokens at each network reset. Learn more about market proposals.

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.

Where is all the trading activity coming from, when there are so few users with access to the testnet?

We’re running bots that create volume on markets by tracking the prices on other exchanges, and then post limit orders around that price point at random with a fixed distribution. Sometimes their orders cross, resulting in a trade which, at least early on, is likely most of the activity you will see.

If you’re finding it easy to make a profit on the testnet, it’s because most of the bot trading is done with very basic logic. As more sophisticated participants begin trading on the testnet, making a profit will get harder.

Let us know you’re interested in building and running a trading bot by sending your Vega contact a message, or sharing your interest on the testnet section of the community forum.

How does settlement work on Vega?

To start, all markets will be (in concept) cash settled futures. This means that settlement would occur in the settlement asset of the market, which is defined in the market framework. These may comprise assets that don’t match the ‘quote units’ (i.e. BTC/ETH on a BTC/ETH December 2020 market).

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.

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. Upon reaching the maturity date for a given market a final settlement is carried out.

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.

What are the trading limits?

On the first version of testnet, no trading limits will be enforced.

Are the markets open 24 hours per day, 7 days per week?

Yes, in the initial testnet release markets are open 24/7. In future releases we plan the possibility for the market creator to set opening times.

How much historical price data can I get?

In the initial testnet release, the amount of historical price data is limited by the amount of time that the testnet has been running (so for a testnet that’s been up for 3 days you can access up to 3 days of tick-by-tick data). You can see it in the chart view in Vega Console, as well as by API.

How does money get allocated and moved in Vega?

Throughout the life of a trade, Vega will settle against the mark to market of the trade (in future price protection mechanisms will protect this process from vulnerability to large price swings).

On the expiry of an instrument, collateral is reallocated between traders in the market according to the final settlement instructions.

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.

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.

How does mark to market settlement work on Vega?

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.

The process is repeated each time the mark price changes until the maturity date for the market is reached.

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.

Where does Vega get its prices from?

The prices you see on the testnet are a result of:

  • Users (like you) posting orders and trading
  • Liquidity provision and trading bots, which access market prices on other exchanges and use these to post orders and trade. Depending on the underlying, they get the “real” price every minute to about every 15 minutes.

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. Learn more about how to deposit tokens for collateral and governance.

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 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.

Market proposals and governance

Market proposals and governance: How to propose a market

Anyone with the minimum required amount of governance tokens (tVOTE) can propose a futures market on Vega’s testnet. That proposal can then be voted on by those who have a tVOTE balance. [Find out how to get governance tokens.(/docs/wallet/deposits/#governance-assets)

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.

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

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.

  • Closing date and time: (ISO-8601 standard) when voting closes for the proposal. The proposal will only be validated if the closing date and time is compatible with the network parameters minCloseInSeconds and maxCloseInSeconds. Learn more about Vega time.
  • Enactment date and time is the ISO-8601 standard date and time when this proposed market goes live (if it passed). Note that it must be after closing date and time. It is constrained by the minEnactInSeconds and maxEnactInSeconds network parameters.
  • New market: If using APIs, you’ll need to ensure that you’ve defined that you’re proposing a new market. It can only be set if update market and update network are not set, otherwise the proposal will be rejected.
    • 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 DEC18
      • Code: This is a shortcode used to easily describe the instrument (e.g: FX:BTCUSD/DEC18)
      • 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.
        • Maturity: Maturity is the date and time that the future product will mature and the market will close. It uses the ISO8601/RFC3339 timestamp. Example: 2018-12-31T23:59:59. As settlement at expiry is not currently implemented, any markets should be created with a maturity date at least 2 months after the enactment date. Positions on an expired market will look open, but if you try to trade on the expired market, your order will be rejected. (Markets created by governance are removed with every testnet reset.)
        • 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 settlement asset for a futures market in testnet. For example, in BTCUSD, USD is the quote. The quoted asset is also used as the settlement asset for a futures product in testnet.
    • Decimal places: Number of decimal places used for the new market. This also currently defines the tick size, which will be set to smallest possible increment of the quote asset. Vega supports up to 5 decimal places, but it’s worth considering what the right decimal places would be for your market, rather than just choosing the maximum or minimum.
    • 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.
        • Log-normal risk model input
        • 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
    • Metadata: This is an optional free text field to provide richer metadata information about the market.
    • 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)
    • Continuous trading: Choose continuous trading. This will create the market in a mode in which Vega tries to execute an order as soon as it is received. This is the only option available right now, and this uses a limit order book as the default price determination method. This is valid only if discrete trading is not set, and discrete trading mode is currently not available.
      • Tick size: This is the size of a minimum increment in price, in terms of the quote currency. Note that this field isn’t yet implemented, so there’s no need to fill it out. However you may see it as a field in the market creation process. Currently the number of decimal places defines the tick size, which will be set to smallest possible increment of the quote asset.
    • Discrete trading: This trading mode is currently not supported in testnet. It is a trading mode for frequent batch auctions.
      • Duration: Duration of the discrete trading batch in nanoseconds. Each auction can be a maximum of 1 month long.
      • Tick size: Size of a minimum increment in price in terms of the quote currency. Note that this field isn’t yet implemented, so there’s no need to fill it out. However you may see it in the market creation process. Currently the number of decimal places defines the tick size, which will be set to smallest possible increment of the quote asset.

When you have a clear idea of the market you want to propose, share it in the community forum so fellow community members know about the market and they vote on it when it’s in the proposal period.

Market proposals and governance: Life cycle of a proposal

  1. A governance proposal (currently available: market 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

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 testnet 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.

Market proposals and 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.

Market proposals and 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

Market proposals and governance: How does the risk model work, what are the risk parameters?

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 the testnet 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 pre-emptively: 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.