Skip to main content
Version: mainnet (v0.74)

Propose a network parameter change

Network parameters are a constant (or an array of constants) in the system, the values of which can be changed by on-chain governance.

This page describes what you need to propose a change to a network parameter, and provides proposal templates that you will need to edit before submitting.

You should also share your proposal idea in the Governance forum section ↗ before submitting it to the network.

Requirements

You will need:

Anatomy of a network parameter proposal

Read on for the key inputs to a network parameter 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.

Rationale requires a title and a description. They 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 asset proposal. Formatting your rationale with markdown makes it easier to read when it's displayed.

Key is the name of the network parameter that you are proposing a change to.

Value is the new value you're proposing that the network parameter should have.

Some network parameters include multiple pieces of information in one value. Changes to one of those network parameters needs to include the correct formatting. You can see how the existing value is formatted on Explorer ↗.

For example, a proposal to change the rewards.activityStreak.benefitTiers network parameter would include a value that looks like the following, using escaped JSON:

Code sample for multiple values
"value": 
" { \"tiers\": [
{ \"minimum_activity_streak\": 1,
\"reward_multiplier\": \"1.05\",
\"vesting_multiplier\": \"1.05\" },
{ \"minimum_activity_streak\": 2,
\"reward_multiplier\": \"1.10\",
\"vesting_multiplier\": \"1.10\" },
{ \"minimum_activity_streak\": 3,
\"reward_multiplier\": \"1.20\",
\"vesting_multiplier\": \"1.20\" }
]
}"

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

The governance dApp has a tool ↗ to help you build a network parameter proposal.

Replace the example data with the relevant details before submitting.

{
rationale: {
title: "Update market.fee.factors.infrastructureFee",
description: "Proposal to update market.fee.factors.infrastructureFee to 300"
},
terms: {
updateNetworkParameter: {
changes: {
// Unique key of the network parameter. (string)
key: "market.fee.factors.infrastructureFee",

// Value for the network parameter. (string)
value: "300"
}
},

// Timestamp as Unix time in seconds when voting closes for this proposal,
// constrained by `minClose` and `maxClose` network parameters. (int64 as string)
closingTimestamp: 1710091024,

// Timestamp as Unix time in seconds when proposal gets enacted if passed,
// constrained by `minEnact` and `maxEnact` network parameters. (int64 as string)
enactmentTimestamp: 1710177424,
}
}

Voting

All proposals are voted on by the community.

Building support is down to you. Share your proposal in the Governance section ↗ on the Vega community forum. You may also wish to share on Discord ↗.

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 🔗3% 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.

Enactment

If successful, the proposal will be enacted at the time you specify in the enactmentTimestamp field.