Skip to main content
Version: testnet (v0.76)

Propose new spot market

Requirements​

You will need:

Spot market assets​

Both the base and quote assets for the market need to be enabled on one of the bridges.

Use the list assets API for REST to see all currently enabled assets.

For an asset that's not already on the bridge, you'll need to propose a new asset, and if it passes governance, update the asset bridge.

Anatomy of a new spot market proposal​

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

Rationale requires a title and description, which are free-text fields that describe the purpose of the proposal. Within the description, include links with more information about your proposal (such as to the IPFS content or forum post) that voters can reference to learn more about the market proposal. Formatting your rationale with markdown makes it easier to read when it's displayed.

Timestamps are required for ending the voting period, as well as enacting the market. The time between closing and enactment also defines how long an opening auction will be, which must be smaller than/equal to the difference between 🔗governance.proposal.market.maxClose: 720h and 🔗governance.proposal.market.maxEnact: 720h.

FieldDescriptionExample
closingTimestampTimestamp (Unix time in seconds) when voting closes for this proposal. If it passes the vote, liquidity can be committed from this time. The chosen time must be between 🔗1m and 🔗720h after the proposal submission time. (int64 as string)1663517914
enactmentTimestamp Timestamp (Unix time in seconds) when the market will be enacted, ready for trading. The chosen time must be between 🔗1m and 🔗720h after closingTimestamp. (int64 as string)1663604314

Instrument​

The instrument shape is as follows, see below for a description of each property:

An instrument contains the following properties:

FieldDescriptionExample
nameA string for the market name. Best practice is to include a full and fairly descriptive name for the instrument.Oranges DEC18.
code (instrument)This is a shortcode used to easily describe the instrument. The more information you add, the easier it is for people to know what the market offers.FX:BTCUSD
spotAn object that provides details about the spot market to be proposed.
quoteAssetQuote specifies the asset which can be exchanged for the base asset. This field requires the asset ID. You can get a list of supported assets by querying REST, GraphQL, or gRPC, and then selecting the asset ID.
baseAssetBase asset specifies the asset to be bought or sold on the market. Requires the asset ID. You can get a list of supported assets by querying REST, GraphQL, or gRPC, and then selecting the asset ID.
tickSizeSets the smallest possible change in the price in the market. Tick size is in relation to the market decimalPlaces, as an integer. If a BTCUSDT market is configured with 5 mdp, tick size 1 would make the smallest tick size 0.00001. Tick size can help manage a market with 'too many' decimal places, or an asset's value dropping dramatically.A value of 2000 with 5 decimalPlaces is a scaled tick size of 0.02.

Decimal places need to be defined for both order sizes and the market. A market cannot specify more decimal places than its settlement asset supports. The values for these fields cannot be changed, even through governance.

FieldDescriptionExample
priceDecimalPlacesSets the smallest price increment on the book that can be stored by Vega. Use with tickSize to get bigger price increments that are currently financially meaningful. Though pricedecimalPlaces can't be changed via governance, tickSize can.18
sizeDecimalPlacesSets the size that the smallest order on the market can be. Price decimal places can also be negative integers.3

Price monitoring​

Price monitoring parameters are optional, and configure the acceptable price movement bounds for price monitoring.

Price monitoring uses the following properties:

FieldDescriptionExample
horizonPrice monitoring projection horizon τ in seconds (set as >0)43200
probabilityPrice monitoring probability level p (set as >0 and <1)0.9999999
auctionExtensionPrice monitoring auction extension duration (in seconds) should the price breach its theoretical level over the specified horizon at the specified probability level (set as >0)600

You can use a maximum of 5 sets of price monitoring parameters for a market.

Liquidity SLA parameters​

The liquidity parameters set the requirements that liquidity providers on the market must meet in order to avoid being penalised and to earn fee revenue. There is also an option to change how the liquidity fee is determined.

FieldDescriptionSample value
liquiditySlaParametersParameters for minimum requirements and measurements
priceRangeSets the percentage move up and down from the mid price that LPs must be within to count towards their commitment0.1
commitmentMinTimeFractionThe minimum fraction of time that LPs must spend on the book and within the price range0.1
performanceHysteresisEpochsSets the number of epochs over which past performance will continue to affect rewards.10
slaCompetitionFactorSets the maximum fraction of their accrued fees an LP that meets the SLA will lose to liquidity providers that achieved a higher SLA performance than them.0.2
liquidityFeeSettingsOptional setting for how the liquidity fee factor is determined. See liquidity fees for more.METHOD_MARGINAL_COST (default) METHOD_CONSTANT, METHOD_WEIGHTED_AVERAGE
feeConstantFor the fee setting METHOD_CONSTANT, a constant fee factor needs to be provided.0.00005

Liquidity monitoring​

The liquidity monitoring settings detect when the market's liquidity drops below the ideal level.

Liquidity monitoring uses the following properties:

FieldDescriptionExample
targetStakeParametersTarget stake parameters are derived from open interest history over a time window to calculate the maximum open interest.
timeWindowDefines the length of time (in seconds) over which open interest is measured.3600
scalingFactorThe target stake scaling factor scales the estimated required liquidity (based on the market's risk model and current market data) to yield the market's target stake. The scaling factor must be a number greater than zero and finite10

Risk model​

Choose the individual parameters for the log-normal risk model. This is used to determine the probability of trading, which influences how liquidity providers are scored.

The risk model uses the following properties:

FieldDescriptionSuggested value
tauProjection horizon measured as a year fraction.

Accepted values: any strictly non-negative real number; suggested value: 0.000114077116130504 - corresponds to one hour expressed as year fraction		0.000114077116130504
riskAversionParameterProbability confidence level; lower values will mean tighter price monitoring bounds.

Accepted values: strictly greater than 0 and strictly smaller than 1		0.00001
param: muAnnualised growth rate of the underlying asset.

Accepted values: any real number		0
param: rAnnualised growth rate of the risk-free asset, it's used for discounting of future cash flows. Use 0.0 unless otherwise required.

Accepted values: any real number		0.0
param: sigmaAnnualised historic 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.		0.8 (converts to 80%)

Submitting proposals in a batch​

If you want to submit this proposal as part of a larger batch of proposals, follow this sample structure:

{
    "batchProposalSubmission": {
        "rationale": {
            "title": "High level title",
            "description": "Description of all parts of this batch of proposals"
        },
        "terms": {
            "closingTimestamp": "123",
            "changes": [
                {
                    "enactmentTimestamp": 123,
                    "cancelTransfer": {
                        "changes": {
                            "transferId": "345"
                        }
                    }
                },
                {
                    "enactmentTimestamp": 123,
                    "cancelTransfer": {
                        "changes": {
                            "transferId": "789"
                        }
                    }
                }
            ]
        }
    }
}

Templates and submitting​

In the tabs below you'll see:

  • Annotated example describing what each field is for
  • JSON example that can be submitted with the governance dApp ↗
  • Command line examples for different operating systems that can be submitted with a Vega Wallet app.

Replace the example data with the relevant details before submitting.

  1. Copy the JSON example below into a text editor.
  2. Replace the placeholder values with those you want for the market.
  3. Tip: Use markdown formatting in your proposal's rationale to make for easier community review.
  4. Submit your proposal on the governance dApp ↗.
  5. Check you can see your proposal under Open Proposals on the governance dApp ↗.
{
"proposalSubmission": {
  "rationale": {
    "description": "Propose a spot market for Bitcoin and USDT",
    "title": "Bitcoin/USDT spot market"
  },
  "terms": {
    "closingTimestamp": "1683626590",
    "enactmentTimestamp": "1683626600",
    "newSpotMarket": {
      "changes": {
        "instrument": {
          "name": "Bitcoin / Tether USD (Spot)",
          "code": "BTC/USDT spot",
          "spot": {
            "baseAsset": "b335cd4ba8a9c5b387b66117e5ee6dbd5a03fb7c74ee4a1d012589aafd45eb25",
            "quoteAsset": "948970482946248f0d04dd271d063cd44458822c67609d230e072d6d51d60956"
          }
        },
        "tickSize": "10",        
        "priceDecimalPlaces": "2",
        "metadata": [
          "base:BTC",
          "quote:USDT",
          "class:fx/crypto",
          "spot",
          "sector:defi"
        ],
    
        "priceMonitoringParameters": {
          "triggers": [
            {
              "horizon": "21600",
              "probability": "0.9999999",
              "auctionExtension": "86400"
            },
            {
              "horizon": "4320",
              "probability": "0.9999999",
              "auctionExtension": "3600"
            },
            {
              "horizon": "1440",
              "probability": "0.9999999",
              "auctionExtension": "1800"
            },
            {
              "horizon": "360",
              "probability": "0.9999999",
              "auctionExtension": "300"
            }
          ]
        },
        "targetStakeParameters": {
          "timeWindow": "3600",
          "scalingFactor": 0.05
        },
        "sizeDecimalPlaces": "4",
        "slaParams": {
          "priceRange": "0.03",
          "commitmentMinTimeFraction": "0.75",
          "performanceHysteresisEpochs": "1",
          "slaCompetitionFactor": "0.8"
        },
        "liquidityFeeSettings": {
          "method": "METHOD_MARGINAL_COST"
        },
        "logNormal": {
          "riskAversionParameter": 1e-06,
          "tau": 3.995e-06,
          "params": {
            "sigma": 1.0
          }
        }
      }
    }
  }
 }
}

Voting​

All proposals are voted on by the community.

A vote can be submitted with a transaction on the command line, or by using the governance dApp.

To vote, community members need, at a minimum, the larger of 🔗1 token, or 🔗1 token associated with their Vega key.

Your proposal will need participation of 🔗7% and a majority of 🔗66%, so having community support is essential.

Proposers who invite feedback, engage with comments, and make revisions to meet the needs of the community are more likely to be successful.

Learn more about voting on the governance concepts page.

Enactment​

If successful, the proposal will be enacted at the time you specify in the enactmentTimestamp field, or as soon as the opening auction has successfully concluded, whichever is later.