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

Propose an update to an asset

Some of the properties of an asset can be changed through governance. Those fields are: withdrawal and deposit limits, and the asset's quantum.

The underlying contract, asset name and symbol cannot be changed.


You will need:

After a new asset vote passes, the change has to be submitted to the asset bridge on Ethereum. See the tutorial for how to do that.

Anatomy of an update asset proposal​

The key inputs on an update asset proposal are as follows.

In addition to the parameters you want to change, you must include the existing parameters from the original new asset proposal, even if they are not being changed.

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.

asset IDUnique Vega ID for the asset (string)
quantumThe minimum economically meaningful amount of the asset (string). This should be the amount of the asset roughly equal to 1 USD. It is used in a number of ways by the protocol but only requires precision to an order of magnitude level. For example, if one BTC = 26,583 USD, then in this case a quantum of 1 / 25,000 or 0.00004 is sufficient. Converted to asset decimals it would be 40000000000000.1000000000000000000
withdrawThresholdThe maximum you can withdraw instantly. All withdrawals over the threshold will be delayed by the withdrawal delay, which can be seen on the ERC-20 bridge per asset. Setting this to 1 means all withdrawals will be subject to the delay. It's measured in asset decimals, so 1 is the smallest increment of the market's asset.1
lifetimeLimitThe lifetime deposit limit per public key, in asset decimals. Users are able to opt out of this functionality using the exempt_depositor write function on the ERC20 contract if they wish to. Suggested value: equivalent of 10,000 USD10000000000000000000000

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

Replace the example data with the relevant details before submitting.

proposalSubmission: {
rationale: {
title: "Update asset",
description: "Proposal to change withdrawal threshold for asset"
terms: {
updateAsset: {
// Asset ID the update is for. (string)
assetId: "ebcd94151ae1f0d39a4bde3b21a9c7ae81a80ea4352fb075a92e07608d9c953d",
changes: {
// Minimum economically meaningful amount in the asset. (string)
quantum: "1",
erc20: {
// Maximum you can withdraw instantly. All withdrawals over the threshold will be delayed by the withdrawal delay.
// There’s no limit on the size of a withdrawal (string)
withdrawThreshold: "10",

// Lifetime limits deposit per address.
// This will be interpreted against the asset decimals. (string)
lifetimeLimit: "10",

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

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


All proposals are voted on by the community.

To vote, community members need, at a minimum, the larger of πŸ”—more than 0 tokens or πŸ”—1 token associated with their Vega key.

Your proposal will need participation of πŸ”—9% 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.


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