Vega software releases
Resources: Development
This section is part of a series on the topic of Development.
Docs:
Other resources:
The Vega software is publicly available on GitHub ↗. Below find summaries of key released features and breaking changes, as well as links to release notes in GitHub.
Vega core software - Below, find a summary of each version's features and breaking changes.
See the full release notes on GitHub ↗.
Vega Capsule on GitHub ↗ - Vega Capsule, which lets you create an instance of the Vega network on your computer to experiment with using the protocol, is public and you can read the contents of each release on GitHub.
Vega core software
The Vega core software is public on a business-source licence, so you can both view the repository change logs, and refer here for summary release notes for each version that the validators use to run the Vega mainnet. Releases are listed with their semantic version number and the date the release was made available to mainnet validators.
Release version 0.73.9 (patch) | 2023-12-09
Version 0.73.9 was released by the validators to mainnet on 09 December, 2023.
This release contains several fixes and improvements, including one to resolve a mainnet incident ↗.
The version contained the following improvements:
- Closed markets will not be subscribed to data sources when restored from a snapshot, 10166 ↗.
- Added validation so that order sizes are not unrealistically large, 10177 ↗.
- Ensured infra fees don't get counted for vesting, 10211 ↗. Volume discount stats no longer show volumes when party doesn't qualify for a discount tier, 10218 ↗.
- Fixed expiring stop orders panic, 10233 ↗.
Release version 0.73.6 (patch) | 2023-11-23
Version 0.73.6 was released by the validators to mainnet on 23 November, 2023.
This release contains a protocol optimisation required as a result of the following mainnet incident ↗ raised on the 21st November 2023 regarding the forwarding of events from Ethereum.
Check out the full details of what is contained in the patch release in the Vega core 0.73.6 ↗ release page.
Mainnet incident - protocol optimisation
The mainnet incident was resolved without any code change, however, the Vega project team identified improvements to reduce the Ethereum RPC load and minimise the chance of future similar incidents; given their impact. The improvements, of adding metrics and reducing the amount of requests sent to the Ethereum RPC, was done under the following issue.
Release version 0.73.5 (patch) | 2023-11-20
Version 0.73.5 was released by the validators to mainnet on 20 November, 2023.
This release contains a number of critical fixes required as a result of testing feedback after the 0.73 deployment.
Check out the full details of what is contained in the patch release in the Vega core 0.73.5 ↗ release page.
Critical fixes
An issue was noticed affecting perpetual markets when the market doesn't have at least 1 of each price observation (internal and external). When this occurs the funding payment doesn't get exchanged, however, the Margin Estimate assumes it has exchanged and thus provides and incorrect estimate for the side due to make the payment. This issue was resolved in 3 pull requests 10119 ↗, 10121 ↗ and 10124 ↗.
During a Market Simulation ↗ fuzzing test, when sending a batch market transaction, a bug was identified where it crashed the network. This was found to be an invalid stop order without a rises-above or falls-below that causes the count of how many pre-generated IDs required to fall out of sync. This was resolved in the pull request 10070 ↗
When carrying out some testing of StopOrdersSubmission in batch proposals it was found that sending this proposal without any values crashes the data node. The investigation found this to be a nill-pointer panic and this bug was fixed in the pull requests 10126 ↗
An issue with the GraphQL LedgerEntries API was identified resulting in the query failing if TransferType filter is specified. On investigation the API worked as intended however, the error message was misinforming users. The error message has been improved and the API documentation made consistent between the gRPC and GraphQL APIs. This bug was fixed in the pull requests 10117 ↗
Release version 0.73.4 (patch) | 2023-11-14
Version 0.73.4 was released by the validators to mainnet on 14 November, 2023.
This release contains 2 fixes required as a result of testing feedback after the 0.73 deployment.
Check out the full details in the Vega core 0.73.4 ↗ release page.
Critical fixes
An issue with the entry price value seen on the positions API was reported. The average entry price from the positions API is flickering - it sometimes briefly changes to read an incorrect value - thus impacting users of the API. This was resolved in this pull request ↗.
The list ledger entries API failed when pagination was provided. The query had been updated to use ledger entry time instead of Vega time, but the cursor for filtering did not recognise ledger entry time. This was resolved in this pull request ↗.
Release version 0.73.3 (patch) | 2023-11-09
Version 0.73.3 was released by the validators to mainnet on 09 November, 2023.
Check out the full details in the Vega core 0.73.3 ↗ release page.
Critical fixes
Shortly after the 0.73.1 release a user reported that immediately after trade the PnL shown in Console would flicker, affecting both realised and unrealised PnL. This was resolved in pull request ↗.
Release version 0.73.2 (patch) | 2023-11-01
Version 0.73.2 was released by the validators to mainnet on 01 November, 2023.
This release contains 3 fixes required as a result of testing feedback after the 0.73.1 deployment.
Check out the full details in the Vega core 0.73.2 ↗ release page.
Critical fixes
A number of liquidity providers reported that they had been penalised incorrectly after the migration of LP orders from the old mechanism to the new SLA liquidity mechanism. It was found that the default parameter changes were not being published to the markets on restart, this was resolved in commit ↗.
Due to this issue, bond penalties were temporarily disabled and will allow 7 epochs for LPs to adjust to the new SLA liquidity. This was introduced in this commit ↗. This code will be removed in a future release.
An issue with governance transfers was reported whereby the default parameter values were incorrect. This commit ↗ sets the default values correctly.
Release version 0.73.2 (patch) | 2023-11-01
Version 0.73.2 was released by the validators to mainnet on 01 November, 2023.
This release contains 3 fixes required as a result of testing feedback after the 0.73.1 deployment.
Check out the full details in the Vega core 0.73.2 ↗ release page.
Critical fixes
A number of liquidity providers reported that they had been penalised incorrectly after the migration of LP orders from the old mechanism to the new SLA liquidity mechanism. It was found that the default parameter changes were not being published to the markets on restart, this was resolved in commit ↗.
Due to this issue, bond penalties were temporarily disabled and will allow 7 epochs for LPs to adjust to the new SLA liquidity. This was introduced in this commit ↗. This code will be removed in a future release.
An issue with governance transfers was reported whereby the default parameter values were incorrect. This commit ↗ sets the default values correctly.
Release version 0.73.1 | 2023-11-01
Version 0.73.1 was released by the validators to mainnet on 01 November, 2023.
This release contains several new features, including the new product type perpetuals, Ethereum oracles and a refactored liquidity mechanism.
Check out the full details in the Vega core 0.73.1 ↗ release page.
Breaking changes
The snapshot configuration
load-from-block-heightno longer accepts -1 as a value. From 0.73.0 onwards, the value of 0 must be used to reload from the latest snapshot. Along with this change the snapshot configurationsnapshot-keep-recentonly accepts values from 1 to 10 inclusive. These changes have been included in the issue 8679 ↗ and are documented in 0.73 deployment instructions.The
AssetIDfield on theExportLedgerEntriesRequestgRPC API, for exporting ledger entries, has had its type changed in order to make it optional. This change has been included in the issue 8944 ↗.The command options for data node retention modes have been updated resulting in a breaking change. The
--liteand--archiveoptions to data node have been replaced with--retention-profile=[archive|conservative|minimal]with default mode as archive. This change has been included in the issue 9562 ↗ and is documented in 0.73 deployment instructions.A crafted payload containing a very large integer can trigger a descriptive internal server error with SQL reference. In order to mitigate the risk of this happening, specifying the range for pagination has been mandated. A default value of 1000 items per page has been applied. This change has been included in the issue 9408 ↗.
The SLA API endpoint has been updated such that it has both a
currentpart (amount, committed, fee proposed) and apendingpart (new amount and fee which will be activated at epoch boundary). This change has added apendingelement to theLiquidityProvisionobject causing a breaking change affecting the gRPC API. This change has been included in the issue 9757 ↗
New features
New liquidity mechanism
At a high level, this change replaces the legacy system that requires LPs to be on the book all the time. The new implementation, called SLA liquidity can be summarised as follows:
- LPs that meet an SLA (i.e. % of time spent providing their liquidity obligation within a range) are rewarded.
- LPs that have a better performance against the SLA receive more rewards, ensuring there is an incentive to do more than the bare minimum if market conditions allow.
- LPs that commit and do not meet the SLA within the LP price range will lose fee revenue and have a sliding penalty applied to their bond account, depending on if their underperformance continues.
How this is different:
In the previous liquidity model, providers would make a commitment and define a “shape” in their liquidity provision order. Any of their commitment volume that wasn't on the book from limit orders would be filled by orders that were automatically deployed based on the shape they defined. In this release, “shapes” are being removed and providers will now be required to deploy their own orders to fulfil their liquidity obligation.
What to expect during the migration:
All existing orders deployed as a result of the LP shapes will be cancelled immediately.
Any active liquidity provision orders will be converted to align to the new liquidity protocol implementation by removing the definition of the buy / sell shape.
Default values for the new liquidity network parameters will be applied, as follows:
| Network parameter | Default | Description |
|---|---|---|
| market.liquidity.sla.nonPerformanceBondPenaltySlope | 1 | Not meeting the SLA deprives an LP of liquidity fee revenue, and a sliding penalty is applied. How much penalty is based on the value of this network parameter. |
| market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.5 (50%) | Defines the maximum penalty on that sliding scale that will be applied to the liquidity provider’s bond account if they do not meet SLA. |
- All existing markets will have the following default parameters applied:
| Market parameter | Default | Description |
|---|---|---|
| priceRange | 0.05 (5%) | Maximum range on both sides of the mid price that orders need to be in to count towards SLA. |
| commitmentMinTimeFraction | 0.95 (95%) | Minimum per epoch that LPs must meet their commitment “on the book” in the price range to avoid penalties. |
| performanceHysteresisEpochs | 1 | Number of epochs for which past performance will affect future fee revenue. |
| slaCompetitionFactor | 0.9 (90%) | Amount of an LP’s accrued fees that may be allocated to other better scoring providers. |
For full details on these network and market parameters and what they represent please read the liquidity concepts pages.
We advise any existing liquidity providers to use Console on Fairground ↗ or the APIs to experiment with the new liquidity protocol ahead of the release to ensure they are comfortable with the changes.
To see lower level details of how the new SLA liquidity feature is designed check out the following spec ↗. The work items completed on this feature can be seen on issues and pull requests with the liquidity-sla ↗ label.
Perpetual futures markets
Perpetual futures markets are cash-settled and do not have a pre-specified “delivery” date/market expiry, so positions can be held indefinitely.
Payments are periodically exchanged between holders of the two sides, long and short, with the direction and magnitude of the settlement based on the difference between the latest mark price and that of the underlying asset, as well as, if applicable, the difference in margin between the two sides.
Along with this new product, there are new market governance options that provide the option to suspend, resume or terminate a market via a community proposal and vote.
To learn more about the implementation of perpetual markets on Vega see the spec. The work items completed on this feature can be seen on issues and pull requests with the perpetual ↗ label.
Ethereum oracles
In the current mainnet state, the markets on Vega are settled and terminated with data that come from centralised sources.
With this more flexible Ethereum oracle framework, there will be a new way to source data from the Ethereum blockchain, allowing for arbitrary data from Ethereum to be ingested as a data source. This had no impact on the already-existing Ethereum bridge.
To see more details check out this spec ↗. The work items completed on this feature can be seen on issues and pull requests with the ethereum-oracles ↗ label.
Referral program
To allow existing users of the protocol/community members to refer new users, the on-chain referral program lets participants enact and vote for a program that provides benefits for referrers and referees.
A party will be able to create a referral code and share this code with referees. Referees who apply the code will be added to the referrer's "referral set".
Whilst a referral program is active, the following benefits may be available to participants in the referral program.
- A referrer may receive a proportion of the referee's paid fees as a reward.
- A referee may be eligible for a discount on fees they incur.
Providing a party has been associated with a referral set for long enough, they will become eligible for greater benefits as their referral set's running taker volume increases. To see more details check out this spec ↗. The work items completed on this feature can be seen on issues and pull requests with the referral ↗ label.
Changes to reward framework
This release introduces locking and vesting for all rewards accrued, including staking, trading, and validator score rewards. Those rewards will go into a vesting account, and can be redeemed on a per-epoch basis. Some rewards may be locked for a number of epochs before they begin vesting, this is defined in each reward pool's funding transfer and may differ for each type of reward.
The initial base rate for vesting will be 25%, meaning 25% of your unlocked pool will vest every epoch. This is set in a network parameter and can be changed by the community through governance. At release time, there is no vesting period for staking rewards, and they will be available to transfer from the vested account to general account as they accrue.
The vesting rate can also be accelerated for faster vesting by keeping rewards in the vesting account, and gaining access to vesting benefit tiers if these are defined and enabled by the community. This is disabled at launch and controlled by governance.
Expanded reward opportunities
Trading rewards have increased to include 3 new reward types, and validator node operators can also benefit from a new reward.
See details on the trading rewards page and the validator rewards page.
Release version 0.72.14 | 2023-09-05
Version 0.72.14 was released by the validators to mainnet on 05 September, 2023.
This release contains several new features, including the ability to propose successor markets, submit stop orders and submit iceberg orders.
It also includes fixes to several APIs, including the API for exporting ledger entries.
Deprecation
The unused rewards-related network parameter reward.staking.delegation.payoutFraction has been deprecated and will be removed in the next release. This was done in 8280.
New features
Stop orders A stop order is an order to buy or sell once the price reaches a specified price, known as the trigger price. Stop orders can be used to help a trader limit losses (stop loss), or capitalise on a gain (take profit) automatically when they already have an open position. Stop orders can be submitted as a single stop order trigger or an OCO (one cancels the other) pair.
Iceberg orders An iceberg order is a limit order for a large amount that, rather than being entered as a single large order of that size, is placed on the book as a smaller order that is replenished as that order amount is filled. The peak / 'visible' amount can be filled with one trade, while the reserve is used to support the smaller order amount. As the Vega network is a public one, the iceberg amount below the peak can still be deduced.
Successor markets A successor market is a market that will carry on after the original market, or parent, that it is based on has settled, which offers liquidity providers the option to keep their equity-like share on the new market, even after the original market expires.
Fixes
Profit and loss data was flickering between different values when subscribed to. This is fixed in 8362.
Settled markets did not have a close timestamp available in the API. Fixed in 8186.
Added number of decimal places to data source events, so it can be determined how many decimal places are being referenced. Done in 8206.
The estimate positions endpoint did not correctly validate data, meaning it would accept values that it could not use. Fixed in 8222.
Check out the full details of the main release: 0.72.0 ↗, Patch releases, which primarily improve the new features, can also be found on GitHub: 0.72.1 ↗, 0.72.2 ↗, 0.72.3 ↗, 0.72.4 ↗, 0.72.5 ↗, 0.72.6 ↗, 0.72.7 ↗, 0.72.8 ↗, 0.72.9 ↗, 0.72.10 ↗, 0.72.11 ↗, 0.72.12 ↗, 0.72.13 ↗, 0.72.14 ↗.
Version 0.71.6 (patch) | 2023-06-19
This version was released to the Vega mainnet by validators on 19 June, 2023.
This patch release contains a security vulnerability fix, a number of critical fixes and minor but important enhancements.
Security vulnerability
A security vulnerability was identified that allows a malicious validator (consensus or pending) to trick the Vega network into re-processing past Ethereum events from Vega’s Ethereum bridge. To find out more please see the security advisory - GHSA-8rc9-vxjh-qjf2. Please ensure, if running a node, the version has been upgraded to 0.71.6, in which the vulnerability has been fixed.
Critical fixes
A fix has been implemented to avoid a potential division by 0 error when calculating the fees accrued by each party in the a market. If the total fees are 0, the protocol will now return 0 rather than trying to divide by 0 8402 ↗.
The orders subscription API was not emitting data for all active orders. When querying for some orders it would indicate that they have been updated, however, the message notifying the client that that order was updated was never received. This bug was resolved with 8414 ↗.
On the 9th of May, the protocol processed an auto delegation where a party had increased their stake during the epoch. As they were eligible for auto delegation their new stake was auto delegated to the validators they already had stake to; this led to events in a random order across the different validators. The issue 8412 ↗ fixes this bug.
The liquidation price estimate API now works when the open volume is 0 8313 ↗.
When creating database metadata on an empty database, the data node software was attempting to query timescale tables that did not yet exist. This fix returns an empty metadata object in this scenario. See 8226 ↗.
Trying to view a transaction in the block explorer API returned an error. Replay protection is now available and fixes the problem as of 8358 ↗.
A fix has been added to address an invalid auction duration for new market proposals. Auction durations now start from the closing time of the proposal, and run through until the proposal enactment time 8451 ↗.
An issue that was spotted during a snapshot test run has been addressed so that all combinations of core state in any snapshots taken are valid when used to restore a node 8471 ↗.
Enhancements
Since the deployment of the Alpha Mainnet release there has been some user feedback on improving the ledger entry CSV export. This has been carried out in 8353 ↗.
Check out the full details in the Vega core 0.71.6 ↗ release page.
Version 0.71.5 | 2023-05-26
Version 0.71.5 was released, by the validators, to mainnet on 26 May 2023.
Whilst investigating a failed withdrawal, a bug was identified in the Vega asset pool smart contract. This bug could cause assets to become stuck in the bridge and therefore required a rapid patch release. New versions of the bridge and asset pool contracts were deployed on the Ethereum mainnet and are in the control of the Vega network.
New bridge contracts:
- Bridge:
0x23872549cE10B40e31D6577e0A920088B0E0666a - Asset pool:
0xa226e2a13e07e750efbd2e5839c5c3be80fe7d4d
Take a look at the incident report for information regarding the requirement for this patch release. Check out the full details in the Vega core 0.71.5 ↗ release page.
Versions 0.54.0 through to 0.71.4 combined | 2023-05-09
Version 0.71.4 was released, by the validators, to mainnet on 09 May 2023.
This version brings the planned features for the alpha mainnet phase to mainnet, making the protocol ready to remove restrictions for the community to propose assets and markets. This deployment brings some key features built upon the restricted mainnet version:
Data node network history In a similar way to core snapshots, the data node can now obtain data node history after downtime without the need to replay the chain. Nodes can reach out to peer nodes to fetch the most recent history, as well as older history if desired, such that it can quickly get itself up to the latest block height of the network and start to consume events for the latest block from the Vega core. This feature is key in speeding up time-to-be-operational for new nodes joining the network. Take a look at the data node network history ↗ readme file for more information.
Protocol upgrades using Visor Until alpha mainnet, an upgrade of the network had to be carried out with a network checkpoint restore. This required a synchronous restart, with all nodes having to be restarted within a short time period so all state could be restored from Ethereum, and the network could start correctly.
With the implementation of the protocol upgrade process, which Vega Visor can orchestrate, the network upgrades can be done in an automated manner. Validators can choose a software version and at a predetermined block height the upgrade will take place. Read the spec ↗ to understand more about Visor and the protocol upgrade process.
Spam protection improvements Mitigating the risk of spam on the Vega blockchain requires both active monitoring for spamming transactions and a rate-limiting mechanism to keep the blocks from becoming clogged with malicious transactions.
If a transaction requires data from the chain for it to be validated, the network defers any checks for validity until it’s executed, meaning it cannot exclude all spam transactions from a block. This means it is possible that one spammer could essentially fill a block.
In order to mitigate this, spam protection will remove the offending transactions after the block is scheduled, i.e., not process them. The state can then be updated once a block is finalised and block transactions are based on the new state. The protection can then delete transactions from every (honest) validator’s mempool based on the new state.
More information is available in the spam protection concepts pages.
Freeform governance proposals Building on the governance features in restricted mainnet, the community can now propose freeform proposals. These differ from other proposals as when the enactment time comes, no changes are auto-enacted on the network if a proposal is successful. However, a record of how token holders voted will be stored on-chain and enactment will come at a future time, e.g., a code change that will come in a future deployment.
Find out more about freeform ↗ governance proposals in the specs.
Vega transaction gas costs and priorities Vega doesn't charge users gas costs per transaction. However, the system processing capacity is still limited; in order to ensure liveness, each transaction will have an associated gas cost. Each block will contain only transactions up to a certain block gas limit. Transactions with higher priorities will get scheduled first. More information on transaction gas costs and priorities in the Vega chain concept pages.
Vega wallet v2 APIs The Vega wallet APIs have been updated to version 2 and now offers JSON-RPC API support. This allows users and UIs to more easily interact with wallets and their keys, and sign and send transactions. This is the core of the wallet backend and is consistent across all implementations. Find out more about the latest wallet API updates in the API docs
Migration from Tendermint to CometBFT The consensus layer has been migrated from Tendermint to CometBFT ↗. This change has been implemented in order to ensure that the consensus layer used by Vega remains in support and that Vega can leverage the benefits of future developments. To find out more about the successor to Tendermint check out this blog ↗.
Network wide limits Network wide limits are aimed at keeping the protocol performant and responsive as usage increases. Vega has been designed with low-latency in mind so that the responsiveness of the network doesn't unduly impact the user's experience. Furthermore, the current implementation relies on an interplay between the execution layer (core) and the data consumption layer (data node).
For more information on Network Limits see the spec ↗
Breaking changes and deprecations
The changes below may affect any automations, scripts or workflows you'll have set up for Vega mainnet before this release. Review the following changes carefully.
Rename marketId and partyId in the orders queries' filter (v0.70)↗: To allow getting all orders for a single party or market so that users can more easily find their orders across multiple keys or markets, filtering on the orders endpoint has been enhanced. The API fields party_id and market_id have been changed to party_ids and market_ids respectively.
Use nanoseconds for one-off transfers (v0.70)↗: The time input field now validates for nanoseconds, which is consistent with other inputs.
Require slippage factors in market proposals (v0.69)↗: When creating a new market proposal the linear and quadratic slippage factor fields have been changed from optional to required.
Data node API rate limiting (v0.68)↗: Rate limiting has been introduced for the gRPC, REST and GraphQL APIs. Users will be warned, and where required, banned from submitting more requests. Should the user continue to breach the API rate limits, the ban length will increase exponentially.
IssueSignatures command (v0.68)↗: The IssueSignatures command is no longer limited to validators, and can now be used by any member of the community. It is also now covered by spam protection rules.
Removed: Grpc-Metadata- headers (v0.68)↗: The deprecated headers with the Grpc-Metadata- prefix in datanode API and REST and GraphQL gateways have been removed.
Removed: Network API fields removed(v0.68)↗: Legacy fields from network API have now been removed.
Deprecated: X-Vega-Connection HTTP header(v0.68)↗: The X-Vega-Connection HTTP header in data node API and REST and GraphQL gateways has been deprecated and will be removed in a future release.
Removed: Wallet command removals v0.66 ↗: A number of the CLI wallet APIs have been deprecated. To find out how to see all the current CLI wallet commands please refer to the CLI wallet documentation.
Renamed: Network parameter v0.66 ↗: The network parameter stakeToCcySiskas has been renamed to stakeToCcyVolume.
Format change: triggering ratio parameter v0.66 ↗: The triggeringRatio field has been changed from double to a string. When proposing a market, using a float value would lead to a passing proposal, however the response from the APIs was incorrect. This has been resolved by changing the accepted data format.
Market definition API v0.65 ↗: The market definition API has been extended with the new field for LP price range, this has resulted in a breaking change.
Data source decimal places v0.65 ↗: The decimal places are now defined in the oracle data source and removed from the market definition resulting in a breaking change.
Vega tools v0.62 ↗: The vegatools snapshot command has been updated to be consistent with other CLI options. The change also formats the json output so that it can be parsed and used programmatically.
Data sourcing v0.61 ↗: The data sourcing types have been updated to account for multiple types of data in the future. Data types are generalised as much as possible, as in the future data will be sourced from more than the currently implemented 'price' data - this is now represented by the types DataSpec and ExternalData.
Deprecation: Wallet API v1 v0.62: For most use cases, the v2 wallet API will soon be the only one available for interacting with the Vega Wallet. V1 will continue to be used for the testnet-only hosted wallet for testing and incentives, for slightly longer.
Data node init now requires the ChainID parameter v.0.59 ↗:
To share data across the network, all data nodes for a given network (chain) will be part of the same IPFS Swarm. The IPFS Swarm key is generated using the node's chain ID. Therefore, when initialising the data node, it is a requirement that the ChainID parameter is passed in the command.
User can now specify a different passphrase when isolating a key v.0.59 ↗: To harden the security of Vega key management for node operators, a different passphrase can be used to protect an isolated wallet. This ensures that the risk of the "full" wallet's passphrase being exposed is minimised. Before this change, when isolating a wallet, its passphrase was inherited from the original wallet, and there was no option to choose a different one.
Output from nodewallet reload is now more useful JSON v.0.59 ↗:
The output from vega nodewallet reload --output=json was not structured in a manner that was easy to use. This change creates a better UX for anyone interacting with the JSON output of the command.
Renamed API: get bundles function GetMultiSigSigner to ListMultiSigSigner v.0.59 ↗:
In order to be consistent with v2 APIs and return context aware results, the get bundles API function name has been changed from GetMultiSigSigner to ListMultiSigSigner.
Swap places of PID and date in log files in the wallet service v.0.59 ↗:
Before the implementation of this change wallet log files were named with the PID first e.g. 47060-2022-10-13-19-49-02.log. This makes log files easy to search for if you have the PID but less so if you do not. In order to be able to easily sort the log files by date the file format name has been changed to start with the date e.g. 2022-10-13-19-49-02-47060.log.
Renamed API: Balance history v.0.59 ↗:
The API field GetBalanceHistory has been renamed to ListBalanceHistory and has had improvements in the documentation to help users understand APIs the 'grouping' feature. This change also fixes an issue with leaking account IDs.
Negative position decimal places for market v.0.59 ↗: In order to maintain spam protection, a market with a price of 10^-3 should only allow the smallest position of something like 10000 so the position decimal places would equal -4 meaning an order size of 1 => 10000.
Renamed API: settlement price decimals v.0.58 ↗:
The market proposal (data source) field settlementPriceDecimals was changed to settlementDataDecimals to be future-proofed for when settlement data isn’t just driven by prices. To ensure consistency throughout the APIs the field oracleSpecForSettlementPrice has now also been changed to oracleSpecForSettlementData.
Require signature from new Ethereum key to validate key rotation submission v.0.58 ↗: To ensure that a compromised old key cannot validate a key rotation, a new CLI command has been introduced to send in an Ethereum key rotation submission that contains a signature generated with the new Ethereum key.
Improve the estimate fee and margin APIs v.0.58 ↗: The changes implemented to improve the estimate fee and margin APIs now mean that you only have to pass in the actual parameters required for the estimation calculation. This change also makes the required parameters mandatory.
Wallet improvements v.0.58 ↗:
The approve/reject transaction interaction has been updated to accept a "mode" instead of a simple boolean. The boolean has changed from yes | no to mode APPROVED_ONLY_THIS_TIME | REJECTED_ONLY_THIS_TIME.
Whatever the state of the sent transaction, the TransactionStatus was updated with an error field that was filled on error, and a transaction hash field that was filled on success. To create a better developer experience this has been split in two distinct notifications: TransactionFailed with the error field, and TransactionSucceeded with txHash field.
To make the framework clearer, the name pipeline has been updated to interactor.
Changing clef address requires re-importing config v.0.57 ↗:
The Nodewallet.ETH section of the config has been removed, and as a consequence some CLI arguments have changed when using clef. Before, when starting a Vega node with a clef wallet, Vega would read whatever clef address was in nodewallet.ETH, whereas after this change, the network will only ever use the value set for the clef address when the key was imported/generated.
Fork: Clef forked so signatures are readable v.0.57 ↗: When a clef wallet was used with a validator node, the validator heartbeats sent out, signed by the clef wallet, could not be verified when received by the network. This was being caused by the message being hashed clef before signing when using clef for validator heartbeats. The Vega team has created a fork of the Clef software to resolve this issue. This was done under issue 6187 ↗
Removed: Clean up unused network parameters v.0.57 ↗: A number of network parameters have been replaced or removed as they were not required.
Renamed fields: settlement price data v.0.56 ↗:
To ensure that the settlement API field name can scale to non-cash products, for example, where settlement data is not necessarily a price, the API field name has been changed from SettlementPriceDecimals to SettlementDataDecimals.
Renamed API: Positions WebSocket v.0.56 ↗:
To ensure clarity of the positions subscription API the field name Position has been updated to PositionUpdate.
Use the latest local snapshot as default behaviour when restarting a node v.0.55 ↗: The best experience for restarting a node is to load from the highest possible block before the node was stopped. This is most important when a node was started using state-sync and the tendermint block store does not contain enough history to replay the chain from block zero. To avoid any issues with not being able to reply from block zero, the default behaviour is now to always start from the most recent local snapshot.
Vega as a built-in application v.0.54 ↗: Vega is now a built-in application. This means that Tendermint does not need to be started separately, providing a simpler, streamlined user experience for node operators. This introduces some breaking changes to the commands used when running a node:
- The
vega nodecommand has been renamed tovega start. - The
vega tmcommand has been renamed tovega tendermint. - The
Blockchain.Tendermint.ClientAddrconfiguration field has been renamed toBlockchain.Tendermint.RPCAddr. - The
initcommand now also generates the configuration for tendermint, and also has the newly introduced flags--no-tendermint,--tendermint-homeand--tendermint-key.
Removed: Wallet support for launching a proxy in front of dApps v.0.54 ↗: Introducing the proxy was a way to navigate the browser security that prevents web apps from being able to talk to local web servers; this is now no longer required and therefore has been removed.
Versions 0.53.1 and 0.53.2 combined | 2023-03-22
This version was released, by the validators, to mainnet on 22 March 2023.
This deployment addresses a critical mainnet issue. A bug has been identified that caused a network outage at the time that the protocol was promoting a new validator to consensus validator status. The issue was caused by insufficient validation of the Tendermint public keys specified in the announce node command.
The fix introduced both resolved the issue and enhances the validation so that this cannot be repeated again.
To find out more please see the issue 7936 ↗ and the incident blog ↗
Versions 0.53-0.51 | 2022-08-15
This version was released, by the validators, to mainnet on 15 August, 2022.
0.53.0 (14 July 2022)
Smart contract upgrade: With the upgrade of the network to version v0.53 there was upgrade of the smart contracts. The multisig control contract and the collateral bridge will thus increase users' control over the funds they deposit (opt-out) and include performance improvements, such as decreasing gas cost when using the bridge. The Vega asset pool contract will not be upgraded. Once the new contracts are properly set up on Ethereum, the validators will migrate the asset pool to use the new contracts.
Checkpoint commands:
From version 0.53.0, checkpoints are always loaded via the genesis. To facilitate this the --genesis-file option has been added to the load_checkpoint command.
With the introduction of this, the restore checkpoint command has now been deprecated and removed.
Vega wallet in core repo: The core and Vega Wallet codebases have been unified. This reduces the risk that core and Vega Wallet software changes get out of sync. Users of the CLI wallet app can easily confirm if the version of their wallet is compatible with the core Vega software version as they will be built and released together, and thus have the same version number.
In the short term, the CLI wallet app will still be available to download from the Vega Wallet repo, but it will not be supported for future releases.
Decentralised validator selection bug: During the testing of the decentralised validator selection feature, a bug was found whereby if the network parameter that controls the number of ersatz validators is reduced in the same epoch that an ersatz validator is promoted, the network could be left with a node set where the actual number of ersatz validators was greater than the total allowed number. A fix has been implemented to handle Tendermint demotion and ersatz slot reduction at the same time and keep true to the configured network parameter values.
PostgreSQL database: Find out how to run a data node with Postgres in the data-node readme.
As of version 0.53, data node uses PostgreSQL as its storage back end instead of the previous mix of in-memory and BadgerDB file stores. We also make use of a Postgres extension called TimescaleDB, which adds a number of time series specific features.
Postgres is not an embedded database, but a separate server application that needs to be running before a data node starts. A side effect of this transition is a little bit of setup is required by the data node operator. By default, data node will attempt to connect to a database called vega listening on localhost:5432, using the username and password vega. This is all configurable in data node’s config.toml file.
We are developing using PostgreSQL 14.2 and Timescale 2.6 and strongly recommend that you also use the same versions. For more information see the data-node readme.
Critical bugs resolved: Collateral checkpoint locked global reward balance: With the deployment of version 0.50.3 a new format for the account owner of the global reward account was introduced. When the mainnet was upgraded, the above was interpreted as a general party account rather than the newly formatted global reward account. As such, a balance of 21500 VEGA became locked in an account that is no longer accessible. To resolve this issue and recover the trapped VEGA, when the checkpoint is read, and on discovery of an old account format, the balance is transferred to the relevant new reward account. Full details can be seen in issue 5546
Unable to query the VEGA asset due to large quantum: Part of testing the network version compatibility is to deploy the latest version of the software using a mainnet checkpoint file. During this test it was found that the VEGA asset could not be found in the data-node via the assets API. To resolve this issue support was introduced in the data-node for large integers for the asset quantum. Full details can be seen in issue 782
Incorrect prices returned from depth endpoint in data node API: The depth value in the data node API appeared to occasionally become desynchronised from the 'true' prices. This was observed on testnet when a market’s prices of the 'bids' values were much higher than those of 'ask' and did not tally with values from best bid/ask.
In V1 of the data node (which will be replaced with V2) there is a check which relies on the Vega time (block time) being correctly set. However, as the V1 broker is multi-threaded per event type, there is no guarantee that the time event that sets the Vega time will arrive at the market depth subscriber with the orders to which the time corresponds. This change sends the Vega time of the block along with the order event in the V1 broker to ensure that a correct sequence number is generated for each order event.
Note: this issue affects the V1 APIs which will be deprecated and replaced by V2 which is single threaded and thus could not have this bug.
Event subscriptions for orders was broken: When placing an order the orders subscription correctly emits an update for the newly created order. However, the bus event subscription did not emit the expected event. The fix for 719 (market depth in data-node V1 incorrect due to race condition) changed the type of the order event such that it no longer implemented these interfaces (no code broke as the check is dynamic), and this prevented the event bus from sending events using the party and market filters.
Full details can be seen in issue 730
0.52.0 (15 June 2022)
Spam protection updates: Until version 0.52 any changes to the proof of work network parameters would take effect immediately, which resulted in changes being enforced on transactions that were generated on blocks preceding the current one. This is not desired because someone may have prepared multiple transactions for a block before the changes were applied, which would then be rejected.
To ensure that this does not affect existing transactions the protocol verifies proof of work with the parameters as they were configured at the time of the block of the transaction.
0.51.2 (10 June 2022)
Version 0.51 of the Vega software implements some key changes to the features of governance and rewards as well as smart contracts. In addition, work continues on the data-node to transition to the time-series PostGres data storage and the migrated APIs which will help the data-node scale as usage increases on the network.
Breaking change - asset governance: In release 0.51.2, a breaking change has been introduced that may affect governance proposals that refer to assets. The function used to request the asset bundle before proposing an asset has been renamed to be clearer, as in the future there will be an option for removing assets.
The following method names have been updated:
GetERC20AssetBundleRequestis nowGetERC20ListAssetBundleRequestGetERC20AssetBundleResponseis nowGetERC20ListAssetBundleResponse
Breaking change - governance: There has been a breaking change made to the governance process. A rationale is now required for all governance proposals. Every proposal transaction must contain a link to a text file in markdown format which summarises the proposed change and links back to the complete proposed change.
Smart contract allow-listing: The MultisigControl smart contracts have been updated to permit allow listing oneself to deposit above the specified deposit limits. This change both ensures that there are steps to protect users of the network during the early period of trading being enabled and also gives control to the user to allow list themselves if they understand the risks.
The contract changes have recently been through an audit of which the final version will be published alongside the deployment of the contracts into testnet. As confidence in the network is established, it is expected that governance proposals will be made to increase the deposit limits.
Rewards: To enable giving rewards in arbitrary tokens that may not necessarily be the settlement asset for a given market or the Vega governance token, changes have been implemented to enhance recurring transfers to reward accounts.
When transferring to a reward account, it is possible to define the reward metric, the reward metric asset, and a subset of markets. Should a market not be defined when initiating the transfer the protocol proceeds with all the markets that settle in the reward metric asset.
Snapshots: A snapshot is generated every N blocks, and that information is stored in a GoLevelDB file on the local file system. By default a node will always start up in normal mode in which it connects to Tendermint and replays any historic blocks before catching up and running at the same pace as the existing nodes on the network.
The snapshot system will keep by default 10 versions of the snapshots. When it has created 10 it will remove the oldest each time it creates a new snapshot. Extensive testing of snapshots has been conducted and is ready for use by the validators for stopping and starting nodes.
There has also been an array of fixes implemented for snapshots that ensure that a node restored from a snapshot always maintains consensus.
Versions 0.50.4 | 2022-06-29
This release was shared with validators on 29 June, 2022. The validators released it to the mainnet network on on 30 June, 2022.
This is a patch release to address two high priority bugs seen in version 0.50.3.
A critical defect was identified on mainnet 0.50.3 where some staking events on Ethereum were replicated multiple times on Vega. During investigations it was identified that some validators were still running their event forwarder as an external service, which forwards events in a slightly different format, meaning those events were not successfully deduplicated. The defect that made it non-deterministic and not successfully deduplicate has now been resolved in 5510 - fix: dedupe sorting made consistent
When restarting from a checkpoint file during the 0.50.3 deployment, at the end of the epoch the reward was paid as expected. However, the rewardScore field for the validators in that first epoch was missing in GraphQL. For all following epochs the rewardScore field was present as it should be. The cause was identified: when the core emits the event at the end of the first epoch, after the checkpoint restart, it was emitted with the wrong epoch sequence. This has now been resolved in 5515 - fix: emit rewardScore correctly when loading from checkpoint
For full detailed information on the changes please see:
Versions 0.50.3-0.49.8 combined | 2022-04-27
This release was shared with validators on 27 April, 2022. The validators released it to the mainnet network on 22 June, 2022.
The primary focus of this and the next upcoming releases has been to complete the final remaining features, progress data-node improvements for scalability and to add test coverage and fix bugs.
Note: While many of the features below are related to trading, it is not yet enabled on mainnet.
Proposals to change market parameters: After a market has been proposed and enacted, changes to the market parameters can be proposed in a different governance action. Tokenholders will be able to submit proposals to change market parameters.
To change any market parameter, the proposer will submit the same data as if they were to create a market, except for the liquidity commitment, however this submission would contain the desired updates to the fields / structures that they wish to be changed. Some of the market parameters will not be able to be changed: market decimal places, position decimal places, settlement asset and the market name.
Read more:
Spam Protection: This release introduces a rate-limiting scheme to prevent clients from attacking the network by spamming the network with requests. Unlike many other systems Vega does not charge a transaction fee; fees are only charged on trades. To prevent spamming, there is a client-side Proof of Work (PoW) mechanism required along with all transaction submissions. The difficulty of the PoW puzzle can be adjusted by governance, and is low for most use-case scenarios. It is automatically increased if a single client submits an abnormal number of transactions.
This rate-limiting is based upon a client-side PoW which is quite different from the PoW term predominantly used for proof-of-work blockchains and associated with high energy consumption.
Read more: Spam protection POW
Checkpoint Improvements: Checkpoints have been simplified. Before, validators would have to have a synchronisation period between nodes in order to reconcile the state from Ethereum when restarting the network from a checkpoint. This was due to the fact that the validators and staking balances were not stored in the checkpoint files.
This data is now stored in the checkpoints, which means that it is now possible to restart from checkpoints asynchronously, which removes the synchronisation period (when feasible). This will become especially important as validator numbers increase and the network sees validators joining and leaving based on stake.
Add Ethereum key rotation support: Vega now supports validators rotating their Ethereum keys. Ethereum keys are required so that validators can allow deposits and withdrawals via the Ethereum bridge. The controller of the bridge is a multisig bundle, and periodically validators will want to change their keys but still be part of the controlling group. This feature allows them to do this with a new transaction type.
Read more: Key management
Liquidity Provision Improvements: Over the last month, the project team has been running a number of community incentives, including around liquidity provision. A number of bugs and enhancements have been introduced as a result of the incentive. These include:
- In some cases, amending liquidity orders triggered a liquidity auction. This was due to the fact that an order amend was effectively equivalent to a cancel and submit. During investigations it was found that if there was only 1 order on either side of the book, amending it would trigger an auction because, temporarily, there were no orders left
- A fix has been implemented to ensure that the margin is correctly released when an LP order is cancelled
- With the introduction of the market decimal places feature (see below), an issue was found related to decimal places and price bounds. This fix ensures that LP orders are adjusted to the min/max price according to the market precision
Tendermint: The current version of Tendermint being used by Vega has a bug where a transaction would pass checkTx but was never added to the memory pool. Tendermint has fixed the bug and the protocol is now able to use sendTx sync successfully. Therefore, if any transactions are rejected by the memory pool an error is raised to indicate why this has happened.
EEF internalising: The Ethereum Event Forwarder is functionality inside Vega that allows the network to be aware of activity on the Ethereum network. When the forwarder service is aware of events, such as the staking or unlocking of tokens, it translates and passes the events to the tendermint blockchain in Vega. Originally this was deployed as a single service alongside the Vega node, with the node needing to be configured to accept events from the forwarder service. This has now been rewritten and internalised into the Vega node, which simplifies the configuration of running a Vega node and makes it easier to deploy. Other benefits of doing this include it being easier to maintain and add future enhancements, which will be described in future release notes.
Data node: In order to have a scalable solution for accessing data, work has begun on migrating the datastore into a postgres with time-series database. Migrations of assets, accounts, markets, market data, orders and trades have been done. The changes have been made to the codebase and live in parallel with the existing solution. As the remaining APIs are migrated and testing is completed, the old datastore and APIs will be removed.
Market decimal places: In this release, the protocol now makes it possible to configure a market for which orders can only be priced in increments of a specific size. This is done by specifying a different (smaller) number of decimal places than its settlement asset supports. To explain this, consider a market that settles in GBP. This market can now be configured to have 0 decimal places so that the price levels on the orderbook will be separated by at least £1, rather than the default £0.01.
Read more: Market decimal places
Offsets for pegged and liquidity commitment orders: The numbers used to offset how far from the reference price a pegged and liquidity provision order (respectively) can now only be input as positive. Whether they need to be added or subtracted from the price will be dependent on the order side.
Read more: Pegged orders
Liquidity provision improvements: The LiquidityProvisionSubmission API was used for submitting, amending and cancelling liquidity provision. To both simplify the code and have a more explicit user experience a breaking change has been implemented to split these into three API commands.
Floating point determinism: Computations within a blockchain-based system need to be deterministic as the application state between nodes replicating it can start to differ potentially resulting in consensus failure. The protocol has been improved so that if the system has a differing floating point value there is a resolution strategy to reach consensus on the value that should be used. This is key due to the fact that validators will be running different hardware that could increase the chances of this happening.
Read more: Floating point consensus
Snapshots: In order to simplify and streamline the process for both restarting or adding a node on the Vega network, the snapshot feature has been implemented. To allow a Vega node to be restarted or join without the need to replay the whole blockchain, a Vega node can load an existing snapshot. Snapshots contain all the network state required to start a node; nodes can use a snapshot stored locally or one created by a different node in the network. Starting a node using a snapshot populates all the state inside the core as if the core had processed the historic blockchain. The node can then start or resume listening to blocks after the snapshot until it gets to the live block height where it will be classed as a normal contributing node. This is a key feature to both ensure the constant availability of the network and for decentralisation.
On-chain treasury: This release also sees the introduction of the on-chain treasury. This is a series of, per asset type, accounts that allows the transfer of the reward types that will be seen when trading is enabled. Part of this change has seen the enabling of transfers between wallets, this allows the reward accounts in the treasury to pay out rewards. With these recurring transfers the reward pools will be distributed in full each epoch. This means that the network parameters for fractional payout and payout delays will be removed. Rewards will be distributed to those staking and providing liquidity, first on testnet, and soon it will be available as a feature validators can release on mainnet.
An on-chain treasury, per asset type, has been implemented where the balance of the insurance pool is transferred when the market closes. To enable this transfers between Vega Wallets has been enabled, this not only is a feature of the on-chain treasury/rewards system but also allows people using the protocol to be able to transfer assets between wallets. With this feature there have been other changes around the rewards system meaning the full amount of the global reward pool will be distributed in all assets at the end of each epoch.
Read more:
Validators joining and leaving, and standby validators: In addition to the consensus validators, there is now functionality on testnet to allow a set of ersatz, or standby validators. These are validators that will not contribute to the chain, but are on standby to jump in if a current validator drops off or their performance drops below a certain threshold. In order to be considered as an ersatz validator, the node operators need to meet certain criteria, including a minimum self-stake as well as stake nominated by other token holders.
Note: The network will be set to allow 0 standby validators for alpha mainnet, and increase the validator numbers via governance as early alpha mainnet progresses.
Read more: Validators chosen by stake
For full detailed information on the changes please see:
Breaking changes
- Separate endpoints for liquidity provision submissions, amendment and cancellation
- Disallow negative offset for pegged and liquidity provision orders
- Add ranking scores and reward score to node
- Proposals have a new field for the rationale, which is optional for now but will be mandatory in a future release
- Add support for fractional order sizes
- Add more data to submit transaction endpoints
- Scale settlement price based on oracle definition
- Restructure Ethereum Config to separate staking and vesting contract addresses, plus add block height at which they have been added respectively
- Rework free form proposal protos so that they align with other proposals
- Add support for decimal places specific to markets. This means market price values and position events can have different values. Positions will be expressed in asset decimal places, market specific data events will list prices in market precision
- Remove tick size from market
- Remove maturity field from future
- Remove trading mode one-off from market proposal
Versions 0.46.0-0.47.6 combined | 2022-01-11
This release was shared with validators on 11 January, 2022. Validators released it to the mainnet network on 31 January, 2022.
A key theme of this combined release has been improvements to the checkpointing feature; this includes fixes to ensure epochs and other key data is preserved as they should be during checkpoint restarts. In addition to this, the “free-form governance” feature has been implemented. This feature further decentralises the protocol by allowing users to submit a range of governance proposals for community consideration and voting.
The protocol calculates a validator score for each validator. This score is used to set their voting power in Tendermint and determine their reward amounts. The changes introduced in this release mean that the protocol no longer prevents users from delegating to any node, however, an overcrowded node will impact the validator score thus affecting rewards. Further scoring of performance measurements in future releases will bring with it the mechanism to adjust rewards in reflection of validator performance in the network. This is another step in getting the network more decentralised, and open to new validators joining the network.
A “null blockchain” implementation of the protocol has been created. Whilst this has no impact on the validators running the nodes, or users using the network, it’s an important part of our future testing, and validation of the protocol strategy. In fact it’s the first step into building an integrated tool, or suite of tools, in order to simulate networks in various conditions.
For full detailed information on the changes please see:
Version 0.45.6 | 2021-12-22
For full detailed information on the changes please see:
Version 0.45.4 | 2021-11-05
Versions 0.45.0-0.45.2 combined | 2021-10-27
For full detailed information on the changes please see:
Version 0.44.1 | 2021-10-08
For full detailed information on the changes please see:
Version 0.44.0 | 2021-10-07
For full detailed information on the changes please see: