diff --git a/docs/api/architecture.md b/docs/api/architecture.md index b653fae16..81e469770 100644 --- a/docs/api/architecture.md +++ b/docs/api/architecture.md @@ -44,7 +44,7 @@ Anyone who wants to can run a data node. ## Next steps Once you have a high-level understanding, read through the following topics. -* **[Building blocks](./useful-endpoints.md)**: The basic building blocks you should know about and their APIs. +* **[Useful endpoints](./useful-endpoints.md)**: The basic features you should know about and their APIs. * **[Using the APIs](./using-the-apis.md)**: Quick intro to all the frameworks and smart contracts to help you find what you need. * **[Public servers](./public-servers.md)**: Public servers that are currently available for interacting with the APIs on the testnets. * **[Tutorials](../tutorials/index.md)**: Each tutorial includes info about the protocol that you need to use the guide, as well as instructions on how to interact with scripts, API calls, or other code. \ No newline at end of file diff --git a/docs/tutorials/programmatic-trading-basics.md b/docs/tutorials/programmatic-trading-basics.md index 4196191f7..dd832f3a0 100644 --- a/docs/tutorials/programmatic-trading-basics.md +++ b/docs/tutorials/programmatic-trading-basics.md @@ -5,7 +5,11 @@ hide_title: false description: Start bot development for submitting orders with this guide. --- -In this tutorial you'll learn the basics about how to use Vega and the Vega Wallet to submit orders using the APIs, so you can build bots or other software to interact with the network. +In this tutorial you'll learn the basics about how to use Vega and the Vega Wallet to submit orders using the APIs, so you can build bots or other software to interact with the network. + +:::note Network for tutorial +This guide suggests using Fairground, the Vega testnet, as well as Sepolia (test Ethereum) for testing purposes. +::: This guide covers how to: diff --git a/docs/tutorials/proposals/_json-instructions.md b/docs/tutorials/proposals/_json-instructions.md index 0f3b57d56..682250643 100644 --- a/docs/tutorials/proposals/_json-instructions.md +++ b/docs/tutorials/proposals/_json-instructions.md @@ -1,5 +1,5 @@ 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 ↗](https://governance.fairground.wtf/proposals/propose/raw). -5. Check you can see your proposal under Open Proposals on the [governance dApp ↗](https://governance.fairground.wtf/proposals). \ No newline at end of file +4. Submit your proposal on the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw). +5. Check you can see your proposal under Open Proposals on the [governance dApp ↗](https://governance.vega.xyz/proposals). \ No newline at end of file diff --git a/docs/tutorials/proposals/_terminal-instructions.md b/docs/tutorials/proposals/_terminal-instructions.md index 105326cff..7f054cd74 100644 --- a/docs/tutorials/proposals/_terminal-instructions.md +++ b/docs/tutorials/proposals/_terminal-instructions.md @@ -2,4 +2,4 @@ 2. Replace the placeholder values with those you want in the proposal. 3. Tip: Use markdown formatting in your proposal's rationale to make for easier community review. 4. Connect to your Vega wallet and use the command line to submit your proposal. -5. Check you can see your proposal under Open Proposals on the [governance dApp ↗](https://governance.fairground.wtf/proposals). +5. Check you can see your proposal under Open Proposals on the [governance dApp ↗](https://governance.vega.xyz/proposals). diff --git a/versioned_docs/version-v0.77/api/architecture.md b/versioned_docs/version-v0.77/api/architecture.md index c638abce3..460a1432e 100644 --- a/versioned_docs/version-v0.77/api/architecture.md +++ b/versioned_docs/version-v0.77/api/architecture.md @@ -44,7 +44,7 @@ Anyone who wants to can run a data node. ## Next steps Once you have a high-level understanding, read through the following topics. -* **[Building blocks](./useful-endpoints.md)**: The basic building blocks you should know about and their APIs. +* **[Useful endpoints](./useful-endpoints.md)**: The basic features you should know about and their APIs. * **[Using the APIs](./using-the-apis.md)**: Quick intro to all the frameworks and smart contracts to help you find what you need. * **[Public servers](./public-servers.md)**: Public servers that are currently available for interacting with the APIs on the testnets. * **[Tutorials](../tutorials/index.md)**: Each tutorial includes info about the protocol that you need to use the guide, as well as instructions on how to interact with scripts, API calls, or other code. \ No newline at end of file diff --git a/versioned_docs/version-v0.77/api/bridge/index.md b/versioned_docs/version-v0.77/api/bridge/index.md index 70393ff74..c3948dbe4 100644 --- a/versioned_docs/version-v0.77/api/bridge/index.md +++ b/versioned_docs/version-v0.77/api/bridge/index.md @@ -15,7 +15,7 @@ These are the smart contracts that make up the Vega <-> Ethereum interface Contains the functions necessary to deposit, withdraw, list assets, etc. It is controlled by Multisig Control and controls Asset Pool. -To read more about how the bridge works, see the [Vega ERC20 bridge blog post ↗](https://blog.vega.xyz/vega-erc20-bridge-331a5235efa2). If you're looking for a way to deposit tokens from Sepolia on to the Fairground testnet, head over to [Console for Fairground ↗](https://console.fairground.wtf). +To read more about how the bridge works, see the [Vega ERC20 bridge blog post ↗](https://blog.vega.xyz/vega-erc20-bridge-331a5235efa2). ### ERC20 Asset Pool @@ -44,7 +44,7 @@ The ERC20 token smart contract for VEGA token. All VEGA tokens are issued through this. Handles the linear vesting of VEGA tokens and allows users to stake VEGA they hold within the vesting contract, regardless of whether they have already vested or not. -To read more about how the bridge works, [see this blog post ↗](https://blog.vega.xyz/vega-erc20-bridge-331a5235efa2). If you're looking for a way to deposit tokens from Sepolia on to the Fairground testnet, head over to [Console for Fairground ↗](https://console.fairground.wtf). +To read more about how the bridge works, [see this blog post ↗](https://blog.vega.xyz/vega-erc20-bridge-331a5235efa2). ### [Multisig Control](./interfaces/IMultisigControl.md) diff --git a/versioned_docs/version-v0.77/releases/overview.md b/versioned_docs/version-v0.77/releases/overview.md index 12435cae7..2f170596f 100644 --- a/versioned_docs/version-v0.77/releases/overview.md +++ b/versioned_docs/version-v0.77/releases/overview.md @@ -15,11 +15,10 @@ See the full release notes on [GitHub ↗](https://github.com/vegaprotocol/vega/ ## Vega core software - The Vega core software is public and open source under the [AGPL ↗](https://www.gnu.org/licenses/agpl-3.0.en.html) license, 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. -## Version v0.77 | 2024-07-23 -This updated version was released to the Vega testnet on 23 July 2024. +## Version v0.77 | 2024-08-07 +This version was released by validators to the Vega mainnet on 7 August 2024. This release introduces the ability to create prediction markets, futures markets with a final settlement price cap, and fully collateralised futures markets. There are also a range of bug fixes and general improvements. @@ -66,8 +65,9 @@ Included in this release are a series of new network parameters. Below is a list To review these changes in the last released version, see [GitHub ↗](https://github.com/vegaprotocol/vega/compare/release/v0.76.8...v0.77.0-preview.10). -## Version v0.76 | 2024-05-09 -This version was released to the Vega testnet on 9 May 2024. +## Release version v0.76.8 | 2024-05-29 + +This version was released by the validators to mainnet on 29 May 2024. ### New features @@ -120,100 +120,35 @@ Transfers for rewards now allow for setting exactly when the reward is paid out - When querying historic ledger movements, an error would be received. This was fixed in [11059 ↗](https://github.com/vegaprotocol/vega/issues/11059). - The error for rejected batch proposals was not included in GraphQL. This was resolved in [11052 ↗](https://github.com/vegaprotocol/vega/pull/11052). -To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/release/v0.75.7...v0.76.1). - -## Pre-release version v0.75.7 | 2024-03-28 -This version was released to the Vega testnet on 28 March 2024. - -### Bug fixes - -- A missing enum value for the transaction type `REJECTION_REASON_STOP_ORDER_LINKED_PERCENTAGE_INVALID` has been fixed in [issue 11042 ↗](https://github.com/vegaprotocol/vega/issues/11042). -- The `collateralIncreaseEstimate` for limit orders in isolated margin was producing incorrect values via the API. This has been fixed in [issue 10928 ↗](https://github.com/vegaprotocol/vega/issues/10928). - -To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/v0.75.5...v0.75.7). - -## Pre-release version v0.75.5 | 2024-03-28 -This version was released to the Vega testnet on 28 March 2024. - -### Bug fixes - -- On the 27th March 2024 the mainnet network was halted due to a consensus failure. Full details of this issue can be seen in the [incident blog ↗](https://blog.vega.xyz/incident-report-network-outage-dd83e48072c8). The team found this to be related to ordering of price monitoring data in the snapshot files, which was resolved in [this patch ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.74.10-fix.1). - -To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/v0.75.4...v0.75.5). - - -## Pre-release version v0.75.4 | 2024-03-26 -This version was released to the Vega testnet on 26 March 2024. - -### Bug fixes - -- It was found that events being sent to the data node were not always being sent deterministically. This issue has been fixed by correctly sorting the vesting summary events before sending to the data node. This was resolved in [issue 11000 ↗](https://github.com/vegaprotocol/vega/issues/11000). -- During market simulation fuzz testing a panic was observed when leaving an opening auction triggered a monitoring auction. This has been fixed by defaulting to the last trade price if the opening auction breaches the price monitoring boundary. This was resolved in [issue 10997 ↗](https://github.com/vegaprotocol/vega/issues/10997). - - +To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/release/v0.75.7...v0.76.4). +## Release version 0.75.8 patch | 2024-05-24 +This version was released by the validators to mainnet on 23 May 2024. -To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/v0.75.3...v0.75.4). +This patch release resolves an issue where a snapshot of price monitoring price ranges was not sorted deterministically. This was fixed by using the existing price range component in the sorting order, such that if two entries have equal bounds they will be sorted by their "range" component. This was completed in [release 0.75.8-fix.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.75.8-fix.2). +## Release version 0.75.8 | 2024-04-04 +This version was released by the validators to mainnet on 04 April 2024. -## Pre-release version v0.75.3 | 2024-03-22 -This version was released to the Vega testnet on 22 March 2024. - -### Bug fixes - -- An issue was identified whereby incorrect rewards were showing in the `teamStats` API. It was found that the query behind the API was not filtering correctly on the `entityScope` thus not filtering out non-team rewards. This has been fixed in [issue 10969 ↗](https://github.com/vegaprotocol/vega/issues/10969). -- A bug was found where suspending a market in a proposed state, before it gets enacted, will result in the market not being able to leave the opening auction. This has been fixed in [issue 10973 ↗](https://github.com/vegaprotocol/vega/issues/10973). - -To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/v0.75.2...v0.75.3). - - -## Pre-release version v0.75.2 | 2024-03-21 -This version was released to the Vega testnet on 21 March 2024. - -### Bug fixes - -- An issue was identified where an LP that joins a market and leaves before the opening auction ends receives all of the LP fees. This issue was fixed in [issue 10950 ↗](https://github.com/vegaprotocol/vega/issues/10950). -- A bug was found whereby a user that is not the owner could update a referral set and create an associated team. This bug has been resolved in [issue 10960 ↗](https://github.com/vegaprotocol/vega/issues/10960). - -To review these changes in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/v0.75.1...v0.75.2). - +### Breaking change -## Pre-release version v0.75.1 | 2024-03-20 -This version was released to the Vega testnet on 20 March 2024. +Market proposals now require the minimum `tick size` field. This allows for changeable tick sizes to support market flexibility if an asset's value changes dramatically. This breaking change was made in [issue 10635 ↗](https://github.com/vegaprotocol/vega/issues/10635). -### Bug fix -Queries for governance-initiated transfers were not providing the dispatch strategy that was set when the transfers were proposed. This was resolved in [issue 10945 ↗](https://github.com/vegaprotocol/vega/issues/10945). +#### Isolated margin -To review the change in the last released version, see [GitHub](https://github.com/vegaprotocol/vega/compare/v0.75.0...v0.75.1). +The protocol now allows users to choose between one of two margining modes for each position. The current mode will be stored alongside the party's position record. +* Cross-margin mode (default): this is the mode used by all newly created orders, but it can be changed. When in cross-margin mode, margin is dynamically acquired and released as a position is marked to market, allowing profitable positions to offset losing positions for higher capital efficiency. +* Isolated margin mode: this mode sacrifices capital efficiency for predictability and risk management by segregating positions. In this mode, the entire margin for any newly opened position's volume is transferred to the margin account when the trade is executed. This includes completely new positions and increases to position size. Other than at time of future trades, the general account will then never be searched for additional funds - a position will be allowed to be closed out instead - nor will profits be moved into the general account from the margin account while a position is open. -## Pre-release versions v0.75.0-preview.9 and v0.75.0-preview.10 (combined) | 2024-03-18 -This version was released to the Vega testnet on 18 March 2024. +To see lower level details of how the new isolated margin feature is designed check out the following [spec ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0019-MCAL-margin_calculator.md#isolated-margin-mode). ### Bug fixes - In a previous release, [issue 10852 ↗](https://github.com/vegaprotocol/vega/issues/10852) was introduced to handle an auction leaving and starting in the same block. However, it did not undo the cached value of the total time spent in complete auction periods, resulting in a core panic. This was resolved in [issue 10916 ↗](https://github.com/vegaprotocol/vega/issues/10916). - A mainnet alert raised a suspected duplicate deposit. While the duplicate event was caught and rejected by the validation, and thus would never finalise, the status in the API was still showing as `OPEN`. The API will now correctly update with the introduction of the fix in [issue 10915 ↗](https://github.com/vegaprotocol/vega/issues/10915). - A user submitted feedback regarding the `balances` API taking a very long time to return any values. It was found that when a `from` and `to` date range was not specified, the query performed a full table scan, posing a risk to data node stability. This has been resolved by requiring a date range be provided with a 'from' or 'to' date, and the period must not be greater than 1 year. This has been fixed in [issue 10910 ↗](https://github.com/vegaprotocol/vega/issues/10910). - -### API change -- The `Get deposit`/ deposit status API now has a field for `STATUS_DUPLICATE_REJECTED`. - -To review the changes in the last released version, see [here](https://github.com/vegaprotocol/vega/compare/v0.75.0-preview.8...v0.75.0-preview.10). - - -## Pre-release versions v0.75.0-preview.8 | 2024-03-15 -This version was released to the Vega testnet on 15 March 2024. - -### Bug fixes - - Since the introduction of the notional time weighted average position API, using the endpoint would result in a data node panic. The `timeWeightedNotionalPositionService` and the `timeWeightedNotionalPositionStore` had not been initialised in the data node. The issues were fixed in [issue 10895 ↗](https://github.com/vegaprotocol/vega/issues/10895) and [issue 10897 ↗](https://github.com/vegaprotocol/vega/issues/10897) respectively. - -## Pre-release versions v0.75.0-preview.4, v0.75.0-preview.5 and v0.75.0-preview.6 (combined) | 2024-03-13 -This version was released to the Vega testnet on 13 March 2024. - -### Bug fixes - - The `ListTransfers` API would fail when given a cursor, resulting in the API not always constructing valid queries and returning an error. This has been resolved in [issue 10837 ↗](https://github.com/vegaprotocol/vega/issues/10837). - In testing using numerous auction triggers, markets were entering auctions for the correct duration but being extended for incorrect durations. A fix has been introduced to only break single bound on auction exit. This was resolved in [issue 10823 ↗](https://github.com/vegaprotocol/vega/issues/10823). - It was identified that the command line wallet leaves terminal input invisible upon Ctrl-C at the wrong time. This has now been fixed in [issue 10055 ↗](https://github.com/vegaprotocol/vega/issues/10055). @@ -222,6 +157,25 @@ This version was released to the Vega testnet on 13 March 2024. - A bug was found in the `EstimatePosition` API with regards to collateral increase. The estimate returned from the API and the actual difference between the general account balance was significantly different. This has now been addressed and the API estimate and actual difference are now the same. This was fixed in [issue 10852 ↗](https://github.com/vegaprotocol/vega/issues/10852). - During testing a snapshot restore was observed to have failed when pegged orders and iceberg pegged orders had been submitted. This bug has been fixed in [issue 10864 ↗](https://github.com/vegaprotocol/vega/issues/10864). - In a market sim fuzzing test a bug was found to cause a panic when converting an "unknown" event to a proto. The event binding for time weight event has now been fixed. This was resolved in [issue 10877 ↗](https://github.com/vegaprotocol/vega/issues/10877). +- During a market-sim fuzz test a core panic was observed when amending an order in place. This has been resolved in [issue 10804 ↗](https://github.com/vegaprotocol/vega/issues/10804). +- During performance testing of loading oracle data in the block explorer (carried out in [issue 10785 ↗](https://github.com/vegaprotocol/vega/issues/10785)) it was found that a further fix was required. This has been updated such that if there is a first `N` cursor traversing newest first data, without an after cursor, the query is also restricted by date to ensure performant loading of the data. This was resolved in [issue 10820 ↗](https://github.com/vegaprotocol/vega/issues/10820) +- Several bugs in isolated margin were resolved: + - Cancelling an order for party with multiple orders while in isolated margin, when entering an auction, would cause a panic. [10750 ↗](https://github.com/vegaprotocol/vega/issues/10750) + - Order margin was not being updated after an order was cancelled. [10696 ↗](https://github.com/vegaprotocol/vega/issues/10696) + - Amending an order would cause a failure when doing the isolated margin check. [10752 ↗](https://github.com/vegaprotocol/vega/issues/10752) + - A submitted and not-matched FoK order in isolated margin would cause an order to become unregistered from its position. [10753 ↗](https://github.com/vegaprotocol/vega/issues/10753) +- Testing scenarios determined that the market depths API was reporting a crossed order book while a market was in continuous trading. This bug has been fixed in [issue 10748 ↗](https://github.com/vegaprotocol/vega/issues/10748). +- The opening auction uncrossing price was not being registered by the perpetual markets engine. This bug has been fixed in [issue 10136 ↗](https://github.com/vegaprotocol/vega/issues/10136). +- Querying for oracle data was loading so slowly as to become unusable. This issue was resolved by adding a date constraint is added to the to the API query when the first page of results is requested. This bug has been fixed in [issue 10785 ↗](https://github.com/vegaprotocol/vega/issues/10785). +- When requesting multiple party IDs using REST, the API reported one or more invalid parties, however when requesting them individually, the given party IDs are valid and results are returned. The API was refactored to support this use case. This bug has been fixed in [issue 10780 ↗](https://github.com/vegaprotocol/vega/issues/10780). +- An issue was identified where an LP that joins a market and leaves before the opening auction ends receives all of the LP fees. This issue was fixed in [issue 10950 ↗](https://github.com/vegaprotocol/vega/issues/10950). +- A bug was found whereby a user that is not the owner could update a referral set and create an associated team. This bug has been resolved in [issue 10960 ↗](https://github.com/vegaprotocol/vega/issues/10960). +- An issue was identified whereby incorrect rewards were showing in the `teamStats` API. It was found that the query behind the API was not filtering correctly on the `entityScope` thus not filtering out non-team rewards. This has been fixed in [issue 10969 ↗](https://github.com/vegaprotocol/vega/issues/10969). +- A bug was found where suspending a market in a proposed state, before it gets enacted, will result in the market not being able to leave the opening auction. This has been fixed in [issue 10973 ↗](https://github.com/vegaprotocol/vega/issues/10973). +- It was found that events being sent to the data node were not always being sent deterministically. This issue has been fixed by correctly sorting the vesting summary events before sending to the data node. This was resolved in [issue 11000 ↗](https://github.com/vegaprotocol/vega/issues/11000). +- During market simulation fuzz testing a panic was observed when leaving an opening auction triggered a monitoring auction. This has been fixed by defaulting to the last trade price if the opening auction breaches the price monitoring boundary. This was resolved in [issue 10997 ↗](https://github.com/vegaprotocol/vega/issues/10997). +- On the 27th March 2024 the netword was halted due to a consensus failure. Full details of this issue can be seen in the [incident blog ↗](https://blog.vega.xyz/incident-report-network-outage-dd83e48072c8). The team found this to be related to ordering of price monitoring data in the snapshot files and was resolved in [this patch ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.74.10-fix.1). +- The `collateralIncreaseEstimate` for limit orders in isolated margin was producing incorrect values via the API. This has been fixed in [issue 10928 ↗](https://github.com/vegaprotocol/vega/issues/10928). ### Improvements @@ -232,120 +186,90 @@ This version was released to the Vega testnet on 13 March 2024. - A new API has been created to expose the notional time weighted average position of a party. It's now possible using the transfers API to calculate if a party is eligible for rewards based on the notional time weighted average position rewards requirement. This has been added in [issue 10831 ↗](https://github.com/vegaprotocol/vega/issues/10831). - The `ethcall` engine will now send to core a dummy chain event if it hasn't sent anything to core in the past hour. It will contain just the last `eth-block-height` checked. This allows core to store in the snapshot a more up to date `last-seen` block height meaning that a node will "re-check" fewer ethereum blocks after a protocol upgrade. This will reduce RPC calls to Ethereum after periods of inactivity sourcing data if there are no markets sourcing data from Ethereum data sources. This improvement has been made in [issue 10841 ↗](https://github.com/vegaprotocol/vega/issues/10841). - CometBFT has been updated to the [latest patch version](https://github.com/cometbft/cometbft/blob/v0.38.6/CHANGELOG.md#v0386), this has been carried out in [issue 10879 ↗](https://github.com/vegaprotocol/vega/issues/10879). +- A change has been implemented to cancel pegged orders when updating the tick size as implemented in [issue 10635 ↗](https://github.com/vegaprotocol/vega/issues/10635). When the tick size is updated, all existing pegged orders are checked. If the offset of an order is no longer an integer multiple of the tick size, the order is cancelled. This has been carried out in [issue 10778 ↗](https://github.com/vegaprotocol/vega/issues/10778). +- Changes have been implemented to allow an optional fee cap for takers to a market. If set, the actual amount of reward transferred to each public key during distribution for the transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. This was done in [issue 10517 ↗](https://github.com/vegaprotocol/vega/issues/10517). ### API changes +- The `Get deposit`/ deposit status API now has a field for `STATUS_DUPLICATE_REJECTED`. - `TimeWeightedNotionalPosition` can now be queried for a `party_id`, `asset_id` and `game_id` at a given `at_epoch`. - `GetTimeWeightedNotionalPositionRequest` can now be queried for a `party_id`, `game_id`, and `asset_id`. - `GetTimeWeightedNotionalPositionResponse` can now be queried for a `party_id`, `game_id`, and `asset_id`. +- `list transfers request` query allows for optional `from account type` and `to account type` filtering. +- `submit transfer`/`submit transfer proposal` commands and `list transfers` query now include optional `capRewardFeeMultiple`. +- `new market proposal` and `update market proposal` commands and `list market` query now includes `tickSize` field. +- `list votes` query has a new shape for equity-like share, `ELS per market`, which provides `market ID` and `els`. -To review the changes in the last released version, see [here](https://github.com/vegaprotocol/vega/compare/v0.75.0-preview.3...v0.75.0-preview.6). - +To review the changes in the last released version, see the [comparison file ↗](https://github.com/vegaprotocol/vega/compare/patch/v0.74.10...v0.75.8). -## Pre-release version v0.75.0-preview.3 | 2024-03-06 -This version was released to the Vega testnet on 06 March 2024. +## Release versions 0.74.10-fix.1 | 2024-03-27 +This version was shared with the validators on 27 March 2024. ### Bug fixes -- During a market-sim fuzz test a core panic was observed when amending an order in place. This has been resolved in [issue 10804 ↗](https://github.com/vegaprotocol/vega/issues/10804). -- During a snapshot test it was noticed that some of the state in the staking engine and ETH verifier engine used to deduplicate events (from ethereum or L2s) was not being saved in the snapshot as they should. This has been fixed in [issue 10811 ↗](https://github.com/vegaprotocol/vega/issues/10811). -- During performance testing of loading oracle data in the block explorer (carried out in [issue 10785 ↗](https://github.com/vegaprotocol/vega/issues/10785)) it was found that a further fix was required. This has been updated such that if there is a first `N` cursor traversing newest first data, without an after cursor, the query is also restricted by date to ensure performant loading of the data. This was resolved in [issue 10820 ↗](https://github.com/vegaprotocol/vega/issues/10820). - -### Improvements - -- A change has been implemented to cancel pegged orders when updating the tick size as implemented in [issue 10635 ↗](https://github.com/vegaprotocol/vega/issues/10635). When the tick size is updated, all existing pegged orders are checked. If the offset of an order is no longer an integer multiple of the tick size, the order is cancelled. This has been carried out in [issue 10778 ↗](https://github.com/vegaprotocol/vega/issues/10778). +- At 11:40 UTC on 27 March 2024, the Vega mainnet stopped producing blocks as detailed in [this incident report ↗](https://blog.vega.xyz/incident-report-network-outage-dd83e48072c8). Nodes had differing `appHash` values. The issue is related to how price monitoring bounds were sorted, and has been fixed in the following [patch release ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.74.10-fix.1). -To review the changes in the last released version, see [here](https://github.com/vegaprotocol/vega/compare/v0.75.0-preview.2...v0.75.0-preview.3). +To see deployment instructions for this patch please see the [migration guide](../node-operators/migration-guides/upgrade-node.md) -## Pre-release version v0.75.0 preview.2 | 2024-03-01 -This version was released to the Vega testnet on 01 March 2024. +To review the changes in the last released version, see the [comparison file ↗](https://github.com/vegaprotocol/vega/compare/v0.74.10...v0.74.10-fix.1). -### Breaking changes -Market proposals now require the minimum `tick size` field. This allows for changeable tick sizes to support market flexibility if an asset's value changes dramatically. This breaking change was made in [issue 10635 ↗](https://github.com/vegaprotocol/vega/issues/10635). +## Release versions 0.74.10 | 2024-03-07 +This version was released by the validators to mainnet on 07 March 2024. -#### Isolated margin +### Bug fixes -The protocol now allows users to choose between one of two margining modes for each position. The current mode will be stored alongside the party's position record. +- After the release of 0.74.9 validators reported an unusually high number of Ethereum RPC calls. As the markets were recently updated to source data from other EVM RPC compatible sources no events were received from Ethereum for a number of weeks. When a protocol upgrade happens the snapshot has a "last Ethereum block height" specified, in order for the network not to miss any events all blocks from this specified height are being checked thus causing a high number of RPC calls. As the deposits and withdrawals use the same client to monitor events these are affected. A temporary patch fix has been made in the following [issue 10842 ↗](https://github.com/vegaprotocol/vega/pull/10842). A further full fix will be included in the next published release. -* Cross-margin mode (default): this is the mode used by all newly created orders, but it can be changed. When in cross-margin mode, margin is dynamically acquired and released as a position is marked to market, allowing profitable positions to offset losing positions for higher capital efficiency. -* Isolated margin mode: this mode sacrifices capital efficiency for predictability and risk management by segregating positions. In this mode, the entire margin for any newly opened position's volume is transferred to the margin account when the trade is executed. This includes completely new positions and increases to position size. Other than at time of future trades, the general account will then never be searched for additional funds - a position will be allowed to be closed out instead - nor will profits be moved into the general account from the margin account while a position is open. +To review the changes in the last released version, see the [comparison file ↗](https://github.com/vegaprotocol/vega/compare/v0.74.9...v0.74.10). -To see lower level details of how the new isolated margin feature is designed check out the following [spec ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0019-MCAL-margin_calculator.md#isolated-margin-mode). -### Improvements +## Release versions 0.74.8 and 0.74.9 (combined) | 2024-03-07 +This version was released by the validators to mainnet on 07 March 2024. -- An improvement has been made to allow the transfers API to filter by from and to account type. This allows for building a network treasury view for the Block Explorer. This improvement to the API was made in the [issue 10686 ↗](https://github.com/vegaprotocol/vega/issues/10686). -- The price monitoring bounds limits have been raised from a value of `5` to now be `100`. This improvement was made in [issue 10770 ↗](https://github.com/vegaprotocol/vega/issues/10770). -- In order to further resolve issues seen with liquidations, a network disposal order will not cross with orders outside price monitoring bounds. Hence a network disposal cannot trade at a price outside the tightest price monitoring and it won't ever trigger a price monitoring auction. This improvement was made in [issue 10764 ↗](https://github.com/vegaprotocol/vega/issues/10764). -- The value of 0 is now allowed for the funding rate scaling factor. This has been resolved in [issue 10727 ↗](https://github.com/vegaprotocol/vega/issues/10727). -- The number of possible price monitoring triggers allowed has been increased to 100 (missed validation). This was done in [issue 10795 ↗](https://github.com/vegaprotocol/vega/issues/10795). -- Changes have been implemented to allow an optional fee cap for takers to a market. If set, the actual amount of reward transferred to each public key during distribution for the transfer will be `min(calculated_reward_in_quantum, cap_reward_fee_multiple × fees_paid_this_epoch_in_quantum)`. This was done in [issue 10517 ↗](https://github.com/vegaprotocol/vega/issues/10517). ### Bug fixes -- The `aggregationEpochs` API was returning the last 30 epochs that had results rather than the last 30 epochs overall. This has been fixed such that the response always starts from the current epoch and counts back the number of epochs given in the filter. This fix was implemented in the [issue 10722 ↗](https://github.com/vegaprotocol/vega/issues/10722). -- A snapshot bug was found when changing the SLA hysteresis network parameter in a batch proposal. This fix was implemented in the [issue 10743 ↗](https://github.com/vegaprotocol/vega/issues/10743). -- When LPs were voting on batch proposals they were not showing up in the API response. Batch proposal votes have been fixed to contain ELS per market and this now shows on the API. This fix was implemented in the [issue 10725 ↗](https://github.com/vegaprotocol/vega/issues/10725). -- It was possible to suspend a market via governance that was already in governance suspension. A fix has been implemented to prevent governance suspension of a market already suspended. This fix was implemented in the [issue 10744 ↗](https://github.com/vegaprotocol/vega/issues/10744). -- After a recent change to the ledger entries API it did not return data when filtering by transfer ID. The `transfer ID` is now associated with the ledger entry. This bug has been fixed in [issue 10374 ↗](https://github.com/vegaprotocol/vega/issues/10374). -- Several bugs in isolated margin were resolved: - - Cancelling an order for party with multiple orders while in isolated margin, when entering an auction, would cause a panic. [10750 ↗](https://github.com/vegaprotocol/vega/issues/10750) - - Order margin was not being updated after an order was cancelled. [10696 ↗](https://github.com/vegaprotocol/vega/issues/10696) - - Amending an order would cause a failure when doing the isolated margin check. [10752 ↗](https://github.com/vegaprotocol/vega/issues/10752) - - A submitted and not-matched FoK order in isolated margin would cause an order to become unregistered from its position. [10753 ↗](https://github.com/vegaprotocol/vega/issues/10753) -- Testing scenarios determined that the market depths API was reporting a crossed order book while a market was in continuous trading. This bug has been fixed in [issue 10748 ↗](https://github.com/vegaprotocol/vega/issues/10748). -- The opening auction uncrossing price was not being registered by the perpetual markets engine. This bug has been fixed in [issue 10136 ↗](https://github.com/vegaprotocol/vega/issues/10136). -- Querying for oracle data was loading so slowly as to become unusable. This issue was resolved by adding a date constraint is added to the to the API query when the first page of results is requested. This bug has been fixed in [issue 10785 ↗](https://github.com/vegaprotocol/vega/issues/10785). -- When requesting multiple party IDs using REST, the API reported one or more invalid parties, however when requesting them individually, the given party IDs are valid and results are returned. The API was refactored to support this use case. This bug has been fixed in [issue 10780 ↗](https://github.com/vegaprotocol/vega/issues/10780). - -### API changes -- `list transfers request` query allows for optional `from account type` and `to account type` filtering -- `submit transfer`/`submit transfer proposal` commands and `list transfers` query now include optional `capRewardFeeMultiple` -- `new market proposal` and `update market proposal` commands and `list market` query now includes `tickSize` field -- `list votes` query has a new shape for equity-like share, `ELS per market`, which provides `market ID` and `els` +- The number of possible price monitoring triggers allowed has been increased to 100, this was missed validation from [issue 10770 ↗](https://github.com/vegaprotocol/vega/issues/10770) deployed in 0.74.7. This was rectified in [issue 10795 ↗](https://github.com/vegaprotocol/vega/issues/10795). +- During a snapshot test, some of the state in the staking engine and ETH verifier engine used to deduplicate events (from Ethereum or EVM chains) was not being saved in the snapshot as they should. This has been fixed in [issue 10811 ↗](https://github.com/vegaprotocol/vega/issues/10811). -To review the changes in the last released version, see [here](https://github.com/vegaprotocol/vega/compare/v0.74.7...v0.75.0-preview.2). +To review the changes in the last released version, see the [comparison file ↗](https://github.com/vegaprotocol/vega/compare/v0.74.7...v0.74.9). -## Pre-release version 0.74.6 and 0.74.7 combined | 2024-02-28 -This version was released to the Vega testnet on 28 February 2024. +## Release versions 0.74.5, 0.74.6 and 0.74.7 (combined) | 2024-02-29 +This version was released by the validators to mainnet on 29 February 2024. ### Bug fixes - After a recent change to the ledger entries API it did not return data when filtering by transfer ID. The `transfer ID` is now associated with the ledger entry. This bug has been fixed in [issue 10374 ↗](https://github.com/vegaprotocol/vega/issues/10374). - The network parameter has been updated to support a block interval at which to call for new blocks. This was required to reduce the amount of EVM RPC data sourcing calls, and thus, the event forwarder snapshot size. This fix has been carried out in [issue 10698 ↗](https://github.com/vegaprotocol/vega/issues/10698). +- The `aggregationEpochs` API was returning the last 30 epochs that had results rather than the last 30 epochs overall. This has been fixed such that the response always starts from the current epoch and counts back the number of epochs given in the filter. This fix was implemented in the [issue 10722 ↗](https://github.com/vegaprotocol/vega/issues/10722). +- A snapshot bug was found when changing the SLA hysteresis network parameter in a batch proposal. This fix was implemented in the [issue 10743 ↗](https://github.com/vegaprotocol/vega/issues/10743). +- When LPs were voting on batch proposals they were not showing up in the API response. Batch proposal votes have been fixed to contain ELS per market and this now shows on the API. This fix was implemented in the [issue 10725 ↗](https://github.com/vegaprotocol/vega/issues/10725). +- It was possible to suspend a market via governance that was already in governance suspension. A fix has been implemented to prevent governance suspension of a market already suspended. This fix was implemented in the [issue 10744 ↗](https://github.com/vegaprotocol/vega/issues/10744). ### Improvements - In order to further resolve issues seen with liquidations, a network disposal order will not cross with orders outside price monitoring bounds. Hence a network disposal cannot trade at a price outside the tightest price monitoring and it won't ever trigger a price monitoring auction. This improvement was made in [issue 10764 ↗](https://github.com/vegaprotocol/vega/issues/10764). - It is now possible to make a market update proposal to set the `fundingRateScalingFactor` to a value of `0`. This improvement was made in [issue 10727 ↗](https://github.com/vegaprotocol/vega/issues/10727). - The price monitoring bounds limits have been raised from a value of `5` to now be `100`. This improvement was made in [issue 10770 ↗](https://github.com/vegaprotocol/vega/issues/10770). +- An improvement has been made to allow the transfers API to filter by from and to account type. This allows for building a network treasury view for the Block Explorer. This improvement to the API was made in the [issue 10686 ↗](https://github.com/vegaprotocol/vega/issues/10686). -To review the changes in the last released version, see [here](https://github.com/vegaprotocol/vega/compare/v0.74.5...v0.74.7). +To review the changes in the last released version, see the [comparison file ↗](https://github.com/vegaprotocol/vega/compare/v0.74.4...v0.74.7). -### API change +### API changes - `aggregated ledger entry` endpoint has a new optional field for filtering by `transfer ID` +- `list transfers request` allows for optional `from account type` and `to account type` filtering +- `list votes` has a new shape for equity-like share, `ELS per market`, which provides `market ID` and `els` -## Pre-release version 0.74.5 | 2024-02-25 -This version was released to the Vega testnet on 25 February 2024. +## Release version 0.74.4 | 2024-02-23 +This version was released by the validators to mainnet on 23 February 2024. -### Bug fixes +This release contains the changes to restore balances from manipulator withdrawals, as can be seen in the [release notes](https://github.com/vegaprotocol/vega/releases/tag/v0.74.4). It has been made available in response to the following [mainnet incident report ↗](https://medium.com/vegaprotocol/incident-report-network-outage-e60376912790). -- The `aggregationEpochs` API was returning the last 30 epochs that had results rather than the last 30 epochs overall. This has been fixed such that the response always starts from the current epoch and counts back the number of epochs given in the filter. This fix was implemented in the [issue 10722 ↗](https://github.com/vegaprotocol/vega/issues/10722). -- A snapshot bug was found when changing the SLA hysteresis network parameter in a batch proposal. This fix was implemented in the [issue 10743 ↗](https://github.com/vegaprotocol/vega/issues/10743). -- When LPs were voting on batch proposals they were not showing up in the API response. Batch proposal votes have been fixed to contain ELS per market and this now shows on the API. This fix was implemented in the [issue 10725 ↗](https://github.com/vegaprotocol/vega/issues/10725). -- It was possible to suspend a market via governance that was already in governance suspension. A fix has been implemented to prevent governance suspension of a market already suspended. This fix was implemented in the [issue 10744 ↗](https://github.com/vegaprotocol/vega/issues/10744). - -### Improvements +## Release version 0.74.3 | 2024-02-20 +This version was released by the validators to mainnet on 20 February 2024. -- An improvement has been made to allow the transfers API to filter by from and to account type. This allows for building a network treasury view for the Block Explorer. This improvement to the API was made in the [issue 10686 ↗](https://github.com/vegaprotocol/vega/issues/10686). - -To review the file changes between the last released version please see [here](https://github.com/vegaprotocol/vega/compare/v0.74.4...v0.74.5). - -## Pre-release version 0.74 | 2024-01-24 -This version was released to the Vega testnet on 24 January 2024. - -This pre-release contains several new features for the Palazzo milestone, including batch proposals, Ethereum RPC and EVM based data sources and a new mark price and price for perps funding TWAP methodology. +This release contains several new features for the Palazzo milestone, including batch proposals, Ethereum RPC and EVM based data sources, new mark price and perps funding TWAP methodology, LP fee setting improvements and team games and party profile updates. ### Breaking changes @@ -360,6 +284,7 @@ This pre-release contains several new features for the Palazzo milestone, includ This release brings in a number of new network parameters. The below table details the parameters, default values and the associated specs should the community wish to change these post deployment. + | Network parameter | Default value | Feature | | -------------------- | ----- | ------------- | | `blockchains.ethereumRpcAndEvmCompatDataSourcesConfig` | `{"network_id":"1","chain_id":"1","collateral_bridge_contract":{"address":"0x23872549cE10B40e31D6577e0A920088B0E0666a"},"confirmations":64,"staking_bridge_contract":{"address":"0x195064D33f09e0c42cF98E665D9506e0dC17de68","deployment_block_height":13146644},"token_vesting_contract":{"address":"0x23d1bFE8fA50a167816fBD79D7932577c06011f4","deployment_block_height":12834524},"multisig_control_contract":{"address":"0xDD2df0E7583ff2acfed5e49Df4a424129cA9B58F","deployment_block_height":15263593}}` | EVM RPC data sourcing [spec ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0087-EVMD-eth-rpc-and-evm-data-source.md) | @@ -371,6 +296,7 @@ This release brings in a number of new network parameters. The below table detai | `transfer.feeDiscountDecayFraction` | 0.8 | Transfer fee improvements [spec ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md) | | `transfer.feeDiscountMinimumTrackedAmount` | 0.01 | Transfer fee improvements [spec ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0057-TRAN-transfers.md) | + #### Batch proposals A `BatchProposalSubmission` is a top-level proposal type that allows grouping several individual proposals into a single proposal. All changes will pass or fail governance voting together. @@ -413,7 +339,7 @@ There are three methods for setting the liquidity fee factor, with the default m The liquidity fee factor is set as the weighted average of the liquidity fee factors, with weights assigned based on the supplied stake from each liquidity provider, which can also account for the impact of one supplier's actions on others. -**"Constant liquidity fee" method** +**"Constant liquidity fee" fethod** The liquidity fee factor is set to a constant directly as part of the market proposal. @@ -422,64 +348,68 @@ This has been implemented as per the [LP fee and rewards setting specification #### Teams games and party profiles -A number of changes have been introduced to incentivise the use of Vega through rewards. Along with the referral program users will be able to create teams and incentivise use via reward structures. The team reward metrics and accounts have been implemented as per the [rewards specification ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0056-REWA-rewards_overview.md#team-reward-metrics). +A number of changes have been introduced to incentivise the use of Vega through rewards. Along with the referral program users will be able to create teams and incentivse use via reward structures. The team reward metrics and accounts have been implemented as per the [rewards specification ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0056-REWA-rewards_overview.md#team-reward-metrics). Now, participants can also have an on-chain party profile allowing them to add an alias and metadata to a given party. This has been implemented as per the [party profile specification ↗](https://github.com/vegaprotocol/specs/blob/palazzo/protocol/0088-PPRF-party_profile.md) -### Pre-release version 0.73.12 (patch) | 2024-01-10 -Version 0.73.12 was released the Vega testnet on 10 January, 2024. -The version contained the following fix: +### Release version 0.73.14 (patch) | 2024-02-19 +Version 0.73.14 was released by the validators to mainnet on 19 February, 2024. -* To address an issue whereby blocks may stop being produced, Vega now limits the number of blocks queried in a single `eth_getLogs` call to prevent large requests to Ethereum nodes. This limit is configurable so that it can match the requirements of Ethereum node providers being used by a Vega validator. This has been resolved under the issue [9992 ↗](https://github.com/vegaprotocol/vega/issues/9992). +This version: -### Pre-release version 0.73.11 (patch) | 2024-01-05 -Version 0.73.11 was released the Vega testnet on 05 January, 2024. +* Contains changes that will suspend all markets at the time of the protocol upgrade and set the funding rate scaling factor to `0` as per the [0.73.14](https://github.com/vegaprotocol/vega/releases/tag/v0.73.14) release notes. +* This is in response to reports from the community of a potential intentional exploit and/or manipulation of markets as detailed in this [mainnet incident report ↗](https://medium.com/vegaprotocol/incident-report-network-outage-e60376912790) and is to protect the current markets. -The version contained the following fix: -* A situation was identified whereby stop orders placed during an opening auction can cause a core panic, this has been resolved under the issue [10318 ↗](https://github.com/vegaprotocol/vega/issues/10318). +### Release version 0.73.13 (patch) | 2024-02-06 +Version 0.73.13 was released by the validators to mainnet on 06 February, 2024. -### Pre-release version 0.73.10 (patch) | 2023-12-21 -Version 0.73.10 was released the Vega testnet on 21 December, 2023. +The version contained the following critical bug fixes: -The version contained the following improvements: +* In a situation where the mark-to-market calculation included data for a party with no position, the code would raise a panic, which would then cause a node to fail. This issue was a patch fix in responce to the following network outage [mainnet incdent ↗](https://medium.com/vegaprotocol/incident-report-network-outage-e60376912790) +* In some circumstances, PnL was incorrectly displayed by the API. This was resolved in issue [10568 ↗](https://github.com/vegaprotocol/vega/issues/10568) +* During the governance voted termination of the LINK/USDT market on mainnet a particular edge case bug was identified. This is where the TWAP calculation for the internal data point, happening at the end of a funding period, can be incorrect. This led to some balances being incorrect during the funding payments. The calculation error has been resolved in the issue [10520 ↗](https://github.com/vegaprotocol/vega/issues/10520). -* Fix the equity-like share votes count on update market proposals, [10257 ↗](https://github.com/vegaprotocol/vega/issues/10257). -* Do not include start epoch on referees set statistics API, [10241 ↗](https://github.com/vegaprotocol/vega/issues/10241). -### Pre-release version 0.73.9 (patch) | 2023-12-08 -Version 0.73.9 was released the Vega testnet on 08 December, 2023. +### Release versions 0.73.11 and 0.73.12 (patch) combined | 2024-01-12 -The version contained the following improvements: +Version 0.73.12 was released by the validators to mainnet on 12 January, 2024. -* Volume discount stats no longer show volumes when party didn't qualify for a discount tier, [10218 ↗](https://github.com/vegaprotocol/vega/issues/10218). -* Fixed expiring stop orders panic, [10233 ↗](https://github.com/vegaprotocol/vega/issues/10233). +The version contained the following fixes: -### Pre-release version 0.73.8 (patch) | 2023-12-05 -Version 0.73.8 was released to the Vega testnet on 05 December, 2023. +* To address an issue whereby blocks may stop being produced, Vega now limits the number of blocks queried in a single `eth_getLogs` call to prevent large requests to Ethereum nodes. This limit is configurable so that it can match the requirements of Ethereum node providers being used by a Vega validator. This has been resolved under the issue [9992 ↗](https://github.com/vegaprotocol/vega/issues/9992) and in [0.73.12](https://github.com/vegaprotocol/vega/releases/tag/v0.73.12). +* A situation was identified whereby stop orders placed during an opening auction can cause a core panic, this has been resolved under the issue [10318 ↗](https://github.com/vegaprotocol/vega/issues/10318) and in [0.73.11](https://github.com/vegaprotocol/vega/releases/tag/v0.73.11). -This release contains a fix required for the vesting balances API, which was erroneously showing infrastructure fees. -Check out the code change contained in the patch release in the Vega core [0.73.8 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.73.8) release page. +### Release version 0.73.10 (patch) | 2023-12-10 +Version 0.73.10 was released by the validators to mainnet on 28 December, 2023. -### Pre-release version 0.73.7 (patch) | 2023-12-04 -Version 0.73.7 was released to the Vega testnet on 04 December, 2023. +The version contained the following improvements: -This release contains a number of fixes required as a result of testing feedback after the 0.73 deployment. +* Market update proposals will now apply the correct equity-like-share threshold when accounting for votes, [10257 ↗](https://github.com/vegaprotocol/vega/issues/10257). +* The `aggregationEpochs` now does not count the start epoch to avoid a discrapancy between `totalRefereeNotionalTakerVolume` (aka `PeriodVolume`) and the sum of `epochNotionalTakerVolumes`, [10241 ↗](https://github.com/vegaprotocol/vega/issues/10241). -Check out the full details of what is contained in the patch release in the Vega core [0.73.7 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.73.7) release page. +Check out the full details of what is contained in the patch release in the Vega core [0.73.10 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.73.10) release page. -### Fixes +### Release version 0.73.9 (patch) | 2023-12-09 +Version 0.73.9 was released by the validators to mainnet on 09 December, 2023. -An issue was found during testing whereby the network could experience a consensus failure when restaring from a snapshot. A fix has been introduced so that closed markets subscribed to data sources, when restored from a snapshot, do not cause a consensus failure. This was fixed in the following [issue ↗](https://github.com/vegaprotocol/vega/issues/10166) +This release contains several fixes and improvements, including one to resolve a [mainnet incident ↗](https://blog.vega.xyz/incident-report-network-outage-991097f8cf5c). -Additionally validation has been introduced to stop an overflow if the order size registered with the position engine is very large. This was fixed in the following [issue ↗](https://github.com/vegaprotocol/vega/issues/10177) +The version contained the following improvements: +* Closed markets will not be subscribed to data sources when restored from a snapshot, [10166 ↗](https://github.com/vegaprotocol/vega/issues/10166). +* Added validation so that order sizes are not unrealistically large, [10177 ↗](https://github.com/vegaprotocol/vega/issues/10177). +* Ensured infra fees don't get counted for vesting, [10211 ↗](https://github.com/vegaprotocol/vega/issues/10211). +Volume discount stats no longer show volumes when party doesn't qualify for a discount tier, [10218 ↗](https://github.com/vegaprotocol/vega/issues/10218). +* Fixed expiring stop orders panic, [10233 ↗](https://github.com/vegaprotocol/vega/issues/10233). + +Check out the full details of what is contained in the patch release in the Vega core [0.73.9 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.73.9) release page. -### Pre-release version 0.73.6 (patch) | 2023-11-22 -Version 0.73.6 was released to the Vega testnet on 22 November, 2023. +### 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 ↗](https://medium.com/vegaprotocol/incident-report-forwarding-events-from-ethereum-a384fc35fbdf) raised on the 21st November 2023 regarding the forwarding of events from Ethereum. @@ -489,8 +419,8 @@ Check out the full details of what is contained in the patch release in the Vega 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](https://github.com/vegaprotocol/vega/issues/10153). -### Pre-release version 0.73.5 (patch) | 2023-11-20 -Version 0.73.5 was released to the Vega testnet on 20 November, 2023. +### 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. @@ -506,8 +436,8 @@ When carrying out some testing of `StopOrdersSubmission` in batch proposals it w 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 ↗](https://github.com/vegaprotocol/vega/pull/10117) -### Pre-release version 0.73.4 (patch) | 2023-11-10 -Version 0.73.4 was released to the Vega testnet on 10 November, 2023. +### 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. @@ -519,10 +449,8 @@ An issue with the entry price value seen on the positions API was reported. The 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 ↗](https://github.com/vegaprotocol/vega/pull/10043). - -### Pre-release version 0.73.3 (patch) | 2023-11-09 - -Version 0.73.3 was released to the Vega testnet on 09 November, 2023. +### 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 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.73.3) release page. @@ -530,9 +458,23 @@ Check out the full details in the Vega core [0.73.3 ↗](https://github.com/vega 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 ↗](https://github.com/vegaprotocol/vega/pull/9959). -### Pre-release version 0.73.2 (patch) | 2023-11-01 +### 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 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.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 ↗](https://github.com/vegaprotocol/vega/commit/53b2b19cbf462963532d115a4b4b4605125944da). + +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 ↗](https://github.com/vegaprotocol/vega/commit/8866cf289d7a99269a91caf16ee238db4a420414). 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 ↗](https://github.com/vegaprotocol/vega/commit/3f344142c465b279345c9f1e8c9aef66dbd9f086) sets the default values correctly. -Version 0.73.2 was released to the Vega testnet on 01 November, 2023. +### 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. @@ -546,16 +488,24 @@ Due to this issue, bond penalties were temporarily disabled and will allow 7 epo An issue with governance transfers was reported whereby the default parameter values were incorrect. This [commit ↗](https://github.com/vegaprotocol/vega/commit/3f344142c465b279345c9f1e8c9aef66dbd9f086) sets the default values correctly. -## Pre-release version 0.73 | 2023-09-20 -This version was released to the Vega testnet on 20 September 2023. +### 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. -This pre-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 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.73.1) release page. ### Breaking changes -The snapshot configuration `load-from-block-height` no 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 configuration `snapshot-keep-recent` only accepts values from 1 to 10 inclusive. These changes have been included in the issue [8679 ↗](https://github.com/vegaprotocol/vega/issues/8679) and are documented in [0.73 deployment instructions](../node-operators/migration-guides/upgrade-node.md). +1. The snapshot configuration `load-from-block-height` no 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 configuration `snapshot-keep-recent` only accepts values from 1 to 10 inclusive. These changes have been included in the issue [8679 ↗](https://github.com/vegaprotocol/vega/issues/8679) and are documented in [0.73 deployment instructions](../node-operators/migration-guides/upgrade-node.md). + +2. The `AssetID` field on the `ExportLedgerEntriesRequest` gRPC 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 ↗](https://github.com/vegaprotocol/vega/issues/8944). -The `AssetID` field on the `ExportLedgerEntriesRequest` gRPC 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 ↗](https://github.com/vegaprotocol/vega/issues/8944) +3. The command options for data node retention modes have been updated resulting in a breaking change. The `--lite` and `--archive` options 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 ↗](https://github.com/vegaprotocol/vega/issues/9562) and is documented in [0.73 deployment instructions](../node-operators/migration-guides/upgrade-node.md). + +4. 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 ↗](https://github.com/vegaprotocol/vega/issues/9408). + +5. The SLA API endpoint has been updated such that it has both a `current` part (amount, committed, fee proposed) and a `pending` part (new amount and fee which will be activated at epoch boundary). This change has added a `pending` element to the `LiquidityProvision` object causing a breaking change affecting the gRPC API. This change has been included in the issue [9757 ↗](https://github.com/vegaprotocol/vega/issues/9757) ### New features @@ -569,11 +519,11 @@ At a high level, this change replaces the legacy system that requires LPs to be **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 fulfill their liquidity obligation. +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 canceled immediately. +- 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: @@ -581,8 +531,7 @@ In the previous liquidity model, providers would make a commitment and define a | 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.05 (5%) | 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. - | +| 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: @@ -617,19 +566,20 @@ With this more flexible Ethereum oracle framework, there will be a new way to so To see more details check out this [spec ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0082-ETHD-ethereum-data-source.md). The work items completed on this feature can be seen on issues and pull requests with the [`ethereum-oracles` ↗](https://github.com/vegaprotocol/vega/issues?q=is%3Aclosed+label%3Aethereum-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 provide benefits for referrers and referees. + +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 referee's paid fees as a reward. +- 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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0083-RFPR-on_chain_referral_program.md). The work items completed on this feature can be seen on issues and pull requests with the [`referral ` ↗](https://github.com/vegaprotocol/vega/issues?q=is%3Aclosed+label%3Areferral+) label. #### Changes to reward framework -This release introduces locking and vesting for all rewards accrued, including trading, validator score, and staking rewards. Those rewards will go into a [vesting account](../concepts/trading-on-vega/discounts-rewards.md#how-rewards-are-paid), 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. +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](../concepts/trading-on-vega/discounts-rewards.md#how-rewards-are-paid), 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. @@ -640,17 +590,19 @@ Trading rewards have increased to include 3 new reward types, and validator node See details on the [trading rewards page](../concepts/trading-on-vega/discounts-rewards.md#trading-rewards) and the [validator rewards page](../concepts/vega-chain/validator-scores-and-rewards.md#validator-metric-based-rewards). -## Pre-release version 0.72.5 | 2023-07-20 -This version was released to the Vega testnet on 20 July, 2023. -This pre-release contains several new features, including the ability to propose successor markets, submit stop orders, submit iceberg orders, and initiate transfers between certain accounts through governance. It also includes some basic work to support future features. +### 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 ↗](https://github.com/vegaprotocol/vega/issues/8280). +#### 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](https://github.com/vegaprotocol/vega/issues/8280). -### New features +#### 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. @@ -660,29 +612,30 @@ An iceberg order is a limit order for a large amount that, rather than being ent **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 ↗](https://github.com/vegaprotocol/vega/issues/8362). +#### Fixes +Profit and loss data was flickering between different values when subscribed to. This is fixed in [8362](https://github.com/vegaprotocol/vega/issues/8362). -Settled markets did not have a close timestamp available in the API. Fixed in [8186 ↗](https://github.com/vegaprotocol/vega/issues/8186). +Settled markets did not have a close timestamp available in the API. Fixed in [8186](https://github.com/vegaprotocol/vega/issues/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 ↗](https://github.com/vegaprotocol/vega/issues/8206). +Added number of decimal places to data source events, so it can be determined how many decimal places are being referenced. Done in [8206](https://github.com/vegaprotocol/vega/issues/8206). -The estimate positions endpoint did not correctly validate data, meaning it would accept values that it could not use. Fixed in [8222 ↗](https://github.com/vegaprotocol/vega/issues/8222). +The estimate positions endpoint did not correctly validate data, meaning it would accept values that it could not use. Fixed in [8222](https://github.com/vegaprotocol/vega/issues/8222). -Check out the full details of the main pre-release and the patch bug fixes in the Vega core [0.72.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.0), [0.72.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.1), [0.72.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.2), [0.72.3 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.3), [0.72.4 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.4), [0.72.5 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.5) release pages. +Check out the full details of the main release: [0.72.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.0), +Patch releases, which primarily improve the new features, can also be found on GitHub: [0.72.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.1), [0.72.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.2), [0.72.3 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.3), [0.72.4 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.4), [0.72.5 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.5), [0.72.6 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.6), [0.72.7 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.7), [0.72.8 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.8), [0.72.9 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.9), [0.72.10 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.10), [0.72.11 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.11), [0.72.12 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.12), [0.72.13 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.13), [0.72.14 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.72.14). -## Pre-release patch version 0.71.6 | 2023-06-19 -This version was released to the Vega testnet on 19 June, 2023. +### 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 +#### Security vulnerability :::caution 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 ↗](https://github.com/vegaprotocol/vega/security/advisories/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. +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](https://github.com/vegaprotocol/vega/security/advisories/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 +#### 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 ↗](https://github.com/vegaprotocol/vega/issues/8402). @@ -700,605 +653,191 @@ A fix has been added to address an invalid auction duration for new market propo 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 ↗](https://github.com/vegaprotocol/vega/issues/8471). -### Enhancements +#### 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 ↗](https://github.com/vegaprotocol/vega/issues/8353). Check out the full details in the Vega core [0.71.6 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.6) release page. -## Pre-release versions 0.71.3, and 0.71.4 combined | 2023-05-05 -This version was released to the Vega testnet on 05 May, 2023. +### Version 0.71.5 | 2023-05-26 -This combined release contains fixes for two bugs found in data node during the final community incentive run on the alpha mainnet release candidate. +Version 0.71.5 was released, by the validators, to mainnet on 26 May 2023. -A bug was identified in the way expired orders were handled by the protocol. Orders were being inserted into the databases with different sequence numbers; this resulted in the logic to expire orders being unable to get deterministic data across the network. This issue was resolved by querying the data by `id` to ensure the correct sequencing on all nodes in the network. See the full details of this bug fix in issue [8251 ↗](https://github.com/vegaprotocol/vega/issues/8251) +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. -The network history status endpoint was found to be unresponsive due to a recent name change in the functions that get the network history peers and the status. The function names were updated, reinstating the functionality of the `GetNetworkHistoryStatus` API endpoint. See the full details of this bug fix in issue [8231 ↗](https://github.com/vegaprotocol/vega/issues/8231) +New bridge contracts: -This release contains the two aforementioned bug fixes and minor enhancements and makes up the software version recommended to the validators to deploy for the release of alpha mainnet. Check out the full details of these patch releases in the Vega core [0.71.3 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.3) and [0.71.4 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.4) release page. +- Bridge: `0x23872549cE10B40e31D6577e0A920088B0E0666a` +- Asset pool: `0xa226e2a13e07e750efbd2e5839c5c3be80fe7d4d` -## Pre-release versions 0.71.0, 0.71.1, and 0.71.2 combined | 2023-04-26 -This version was released to the Vega testnet on 26 April, 2023. +Take a look at the [incident report](https://medium.com/vegaprotocol/incident-report-incident-under-investigation-d41cb2815de0) for information regarding the requirement for this patch release. Check out the full details in the Vega core [0.71.5 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.5) release page. -This combined release contains improvements to API documentation, as well as bug fixes and minor enhancements to improve usability. +### Versions 0.54.0 through to 0.71.4 combined | 2023-05-09 -:::caution Breaking changes -**Remove WebSocket for rewards**: An unused and unnecessary event stream has been removed to simplify the APIs. +Version 0.71.4 was released, by the validators, to mainnet on 09 May 2023. -**Remove all offset pagination**: While cursor pagination has been available for a number of releases, some endpoints still also supported offset pagination. This has now been removed for clarity and simplicity. +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: -Check out a full summary of all the 0.71.0 [breaking changes ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0710) entries in the changelog. There were no breaking changes in 0.71.1 or 0.71.2. -::: +**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 ↗](https://github.com/vegaprotocol/vega/blob/develop/datanode/networkhistory/README.md) readme file for more information. -This release contains breaking changes, bug fixes and minor enhancements. Check out the full details in the Vega core [0.71.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.0), [0.71.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.1) and [0.71.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.71.2) release page. +**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. -## Pre-release versions 0.70.0, 0.70.1, and 0.70.2 combined | 2023-03-28 -This version was released to the Vega testnet on 28 March 2023, with the 0.70.2 patch released on 31 March, 2023. +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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0075-PLUP-protocol_upgrades.md) to understand more about Visor and the protocol upgrade process. -Versions 0.70.0-0.70.3 contain the fixes and minor enhancements to verify in Fairground before the validators deploy to the validator-run testnet for the Market Simulation #4 event. +**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. -Several new features were released with these versions: the addition of post-only and reduce-only options for certain order types. In addition, bugs in restoring deposits after checkpoints and order subscriptions were also fixed. +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. -These deployments also realised further data node enhancements to aid performance and improve management of stored data. The indexes on the positions table have been reworked in order to maintain performance of network history on the data nodes. Additionally, the buffer-size config has been adjusted to best utilise the node memory on startup. +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. -Finally, to help manage the volume of data being created, LP orders are no longer sent when resubmitted without any changes, giving a direct data storage benefit. +More information is available in the [spam protection concepts](../concepts/vega-chain/network.md#spam-protection) pages. -:::caution Breaking changes -**Rename `marketId` and `partyId` in the orders queries' filter** [(v0.70)↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0700): 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. +**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. -**Use nanoseconds for one off transfers**: During the Market Simulation #3, the data node crashed due to an invalid time input when carrying out an internal transfer. The field now validates for nanoseconds, which is consistent with other inputs. +Find out more about [freeform ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0028-GOVE-governance.md#6-freeform-governance-proposal) governance proposals in the specs. -**Rename table `current liquidity provisions` to `live liquidity provisions` and add a `live` option**: During testing it was identified that over time the current liquidity provisions table will continue to grow as LPs are created/deleted. This change will help the management of the data being created by the protocol. - -Check out a full summary of all the 0.70.0 [breaking changes ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0700) entries in the changelog. There were no breaking changes in 0.70.1 or 0.70.2. -::: +**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](../concepts/vega-chain/transactions.md#filling-a-block-transaction-gas-value) pages. -This release contains breaking changes, bug fixes and minor enhancements. Check out the full details in the Vega core [0.70.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.70.0), [0.70.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.70.1) and [0.70.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.70.2) release page. +**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](../api/vega-wallet/reference/core/index.md) -## Pre-release Version 0.69.0 | 2023-03-15 -This version was released to the Vega testnet on 15 March 2023. +**Migration from Tendermint to CometBFT** +The consensus layer has been migrated from Tendermint to [CometBFT ↗](https://github.com/cometbft/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 ↗](https://medium.com/the-interchain-foundation/cosmos-meet-cometbft-d89f5dce60dd). -Version 0.69.0 is a large release that incorporates both fixes from the Market Simulation activities and many improvements to the protocol. +**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). -One of the key improvements in this version has been to the process of restoring data from network history. The insert query time for the orders table was continually increasing, eventually resulting in the data node falling behind the core. This has been resolved by optimising the query and replacing the ‘current order’ flag with some SQL magic and carefully crafted indexing. +For more information on Network Limits see the [spec ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0078-NWLI-network_wide_limits.md) -The CLI wallet has been improved to allow a better UX to `locate`, `describe` and `reset` the wallet service configuration. These changes have been made in conjunction with other wallet improvements creating a better CLI and desktop wallet user experience. +#### Breaking changes and deprecations :::caution Breaking changes -**Require slippage factors in market proposals**: When creating a new market proposal the `linear` and `quadratic` slippage factor fields have been changed from optional to required. - -**Deprecated fields removed from the wallet API**: The `version` field has been removed from the `admin.import_wallet` wallet API. All references to file paths have now been removed from the `admin.import_wallet`, `admin.import_network`, `admin.create_wallet` and `admin.isolate_keywallet` API - -Checkout a full summary of all the 0.69.0 [breaking changes ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0690) entries in the changelog. +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. ::: -This release contains breaking changes, wallet improvements, bug fixes and minor enhancements. Check out the full details in the Vega core [0.69.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.69.0) release page. - -## Pre-release Version 0.68.0 | 2023-02-22 -This version was released to the Vega testnet on 22 February 2023. - -Version 0.68.0 addresses the required improvements and fixes identified during pre-Alpha Mainnet Market Sim 1. Much of the effort on this version was spent ensuring data node stability, and this identified two areas of concern. The first of these was a memory leak found in the event subscriber. This functionality is where events are emitted by the core and consumed by the data nodes. The code shared between the nodes has been simplified and the memory leak fixed. Secondly, it was noticed that the data node did not close GraphQL subscriptions once they had been finished with, meaning many connections were left open, increasing the memory usage of the data node. To further help with CPU utilisation on both the core and data nodes, the team consolidated order expiry events into a single event containing just the market and order IDs of those orders set to expire. - -In addition, improvements have been made to the protocol for margin calculations and capping of slippage. The latter of these changes resolves an issue whereby it was possible for a user to be closed out when the market moved in their favour. With the introduction of two new network parameters, the slippage component of the margin is never allowed to be larger than the `slippage_cap`, and if there is insufficient volume on the book, the cap is used instead of slippage per unit. - -Finally, API enhancements in this release include a new API to query the market conditions that led to closeouts and loss socialisation. These changes combined with improvements in error messaging in the wallet round off a number of great UX improvements taking the protocol a step closer to Alpha Mainnet. - -:::caution Breaking changes -**Data node API rate limiting**: 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**: 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. - -To find out more please see these issues [7445 ↗](https://github.com/vegaprotocol/vega/issues/7445) and [7382 ↗](https://github.com/vegaprotocol/vega/issues/7382) - -To find out more please see all 0.68.0 [breaking changes ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0680) entries in the changelog. -::: - -:::warning Removals -**`Grpc-Metadata-` headers**: The deprecated headers with the `Grpc-Metadata-` prefix in datanode API and REST and GraphQL gateways have now been removed. - -**Network API**: The legacy fields from network API have now been removed. - -To find out more please see these issues [7419 ↗](https://github.com/vegaprotocol/vega/issues/7419) and [6963 ↗](https://github.com/vegaprotocol/vega/issues/6963) -::: - -:::warning Deprecations -**`X-Vega-Connection` HTTP header**: 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. - -To find out more please see issue [7385 ↗](https://github.com/vegaprotocol/vega/issues/7385) -::: - -This release contains a large number of bug fixes and minor enhancements. Check out the full details in the Vega core [0.68.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.68.0) release page. - -## Pre-release Versions 0.67.0, 0.67.1, 0.67.2 and 0.67.3 combined | 2023-01-20 -This version was released to the Vega testnet on 20 January 2023, with patch 0.67.3 released on 24 January. - -Building on the stability improvements in the first release of 2023, this second release of the year is the version the team believe is ready for the first community Market Simulation. This release brings with it bug fixes around data sourcing and a critical fix whereby transfers and announce-node spam policies were not included in snapshots. These issues have been resolved and covered in tests to ensure no regression in the future. - -In addition to these fixes, improvements have been made to the data node API documentation and the data node operator UX. It is now possible to initialise a data node using one of the three [retention modes](https://github.com/vegaprotocol/specs/blob/master/protocol/0076-DANO-data-node.md#datanode-retention-modes). Finally for v0.67.2 the wallet API token support has been extended to support long lived tokens. - -Check out the full details of this combined release in the Vega core [0.67.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.67.0), [0.67.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.67.1), [0.67.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.67.3) and [0.67.3 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.67.2) release pages. - -## Pre-release Versions 0.66.0 and 0.66.1 combined | 2023-01-06 -This version was released to the Vega testnet on 6 January 2023. - -Happy New Year from the Vega team. - -The first testnet deployment of 2023 brings with it the final planned data node stability improvements ahead of the market simulations. Using the data from the last incentive, the team has made changes to the way the snapshot metadata is stored, which has significantly improved RAM usage during snapshot file creation. In addition to the memory usage optimisations, a panic when fetching data segment history has been resolved. - -These fixes and stability improvements bring the data node software into a state of readiness for the Alpha Mainnet market simulations. - -To round off this release several API improvements have been introduced, along with a number of bug fixes, preparing the core and wallet software for the market simulations. Until then, the team is focused on completing wallet API token support, increasing the test coverage and fixing any bugs found along the way. - -:::caution Breaking changes -**Wallet API and command removals**: Over the recent testnet releases a number of the wallet APIs have been deprecated. The deployment of `0.66.0` now removes a number of these deprecated fields, endpoints and commands. -**Network parameter name change**: The network parameter `stakeToCcySiskas` has been renamed to `stakeToCcyVolume`. -**Network parameter name change**: 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. - -To find out more please see the [breaking changes ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0660) entries in the changelog. -::: - -Check out the full details of this combined release in the Vega core [0.66.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.66.0) and [0.66.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.66.1) release pages. - -## Pre-release Versions 0.65.0 and 0.65.1 combined | 2022-12-23 -This version was released to the Vega testnet on 23 December 2022. - -The final scheduled testnet release of 2022 has introduced some refactors to the liquidity provision (LP) code. The protocol has been changed so LP margins will not be affected by the probability of trading, because that would make the job of being an LP overly difficult. Similarly, the protocol has been redesigned to discourage LPs from posting orders too far away from the mid price. This ensures that liquidity provided is 'useful' liquidity. Doing this refactor now addresses these points before liquidity providers integrate with the protocol, both for the mainnet sims and the Alpha Mainnet release. - -The way snapshot data is stored and retrieved has been improved to manage the memory load during these processes. This combined with some Postgres configuration changes introduces the first of a set of planned improvements to the network stability. This will be further updated and proved out in the incentives running over the coming weeks. - -Finally as a parting gift to 2022, the team has added a couple of additional APIs. One allows users to query the reward types and amounts distributed for a given epoch and the other can show the liquidity score in the market data response. - -This deployment brings with it many other fixes and improvements leading up to Alpha Mainnet; check out the full details of this combined release in the Vega core [0.65.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.65.0) and [0.65.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.65.1) release pages. - -:::caution Breaking changes -**Market definition API**: 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**: The decimal places are now defined in the oracle data source and removed from the market definition resulting in a breaking change. - -To find out more please see these issues [6955 ↗](https://github.com/vegaprotocol/vega/issues/6955) and [6645 ↗](https://github.com/vegaprotocol/vega/issues/6645) respectively. -::: - -:::warning Deprecations -**Vega Wallet**: A number of recent changes have deprecated commands in the Vega CLI wallet, these will be removed in the next release. - -To find out more please see these issues [6887 ↗](https://github.com/vegaprotocol/vega/issues/6887), [6957 ↗](https://github.com/vegaprotocol/vega/issues/6957), [6963 ↗](https://github.com/vegaprotocol/vega/issues/6963), [7067 ↗](https://github.com/vegaprotocol/vega/issues/7067), [7069 ↗](https://github.com/vegaprotocol/vega/issues/7069) and [7079 ↗](https://github.com/vegaprotocol/vega/issues/7079) -::: - -## Pre-release Versions 0.63.0, 0.63.1, 0.63.2 and 0.64.0 combined | 2022-12-09 -This version was released to the Vega testnet on 09 December 2022. - -As we approach the end of 2022 we are still pushing out some awesome updates to testnet. Any eagle eyed followers will have seen the recent demo on Twitch sharing the outputs of the performance testing. This has resulted in a few new features to help maintain the stability of the network as usage scales up: - -- [Network wide limits](https://github.com/vegaprotocol/specs/blob/master/protocol/0078-NWLI-network_wide_limits.md) will allow the community to tune the maximum number of pegged orders on a market and the number of LP shapes on the network. The expectation is that these will be increased via governance as the protocol is adopted as the performance and interplay between the core and data nodes is better understood in mainnet. -- [Vega transaction gas costs and priorities](https://github.com/vegaprotocol/specs/blob/master/protocol/0079-TGAP-transaction_gas_and_priority.md) Vega doesn't charge users gas costs per transaction, however, there are still constraints in the system processing capacity. In order to ensure liveness, each transaction will have an associated gas cost. This allows the protocol to ensure that each block will contain only transactions up to a certain block "gas limit". - -This deployment brings with it many other fixes and improvements leading up to Alpha Mainnet; check out the full details of this combined release in the Vega core [0.63.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.63.0), [0.63.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.63.1), [0.63.2 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.63.2) and [0.64.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.64.0) release pages. - - -:::warning Deprecations -**Vega Wallet**: A number of changes have been introduced resulting in the deprecation of commands in the Vega CLI wallet. - -These will be removed in the next release. - -To find out more please see the issues [7065 ↗](https://github.com/vegaprotocol/vega/issues/7065), [7066 ↗](https://github.com/vegaprotocol/vega/issues/7066) and [7068 ↗](https://github.com/vegaprotocol/vega/issues/7068) -::: - -:::caution Breaking changes -**Data node V1 APIs removed**: As flagged previously, the data node V1 APIs have now been removed. - -This release also introduces a number of [breaking changes ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0630) that should be reviewed if you are using data node APIs or starting to use the V2 wallet APIs. -::: - - -## Pre-release Versions 0.61.0, 0.62.0 and 0.62.1 combined | 2022-11-11 -This version was released to the Vega testnet on 11 November, 2022. - -As the software gets closer to being ready for Alpha Mainnet, all focus is on testing, bug fixing and measuring performace to ensure a stable network. The team has been running performance tests and gathering metrics to enhance both the core and the data node. This release brings enhancements to the data node ensuring performant operation, and the all-important accuracy of every APIs response. - -The last three weeks have seen unfortunate delays to the usual weekly testnet release cadence. This was caused by a large refactor of the `oracleSpec`, clarifying the naming and distinctions between oracles and the data they provide. Why do this now? The team wanted to mitigate against large breaking changes in the months after Alpha Mainnet when new features will be developed, and building on top of Vega gets into full swing... you can thank us later. - -Check out the full details of this combined release in the Vega core [0.61.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.61.0), [0.62.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.62.0) and [0.62.1 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.62.1) release pages. - -:::warning API deprecations -**Data node**: UPDATE: The v2 APIs ([REST](./../api/rest/overview) and [gRPC](./../api/grpc/data-node/api/v2/trading_data.proto)) for the data node will replace v1 in the next major version release to testnet. Therefore anyone building apps on top of Vega should start to use the v2 APIs immediately. - -**Vega Wallet**: For most use cases, the v2 [wallet API](../api/vega-wallet/before-you-start.md) 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. -::: - -:::caution Breaking changes -**Vega tools**: 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**: 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`. -::: - -## Pre-release Versions 0.59.0 and 0.60.0 combined | 2022-10-25 -This version was released to the Vega testnet on 25 October, 2022. - -For full details see the vega core [0.59.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0) and [0.60.0 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.60.0) release pages. - -The primary focus of this release has been to add general bug fixes and improvements, improve the stability of the network and implement data node snapshots to be used for protocol upgrades and new nodes joining the network. This feature is now in testing. - -:::warning API deprecations -**Data node**: The v2 APIs ([REST](./../api/rest/overview) and [gRPC](./../api/grpc/data-node/api/v2/trading_data.proto)) for the data node will replace V1, which will soon be removed. Therefore anyone building apps on top of Vega should start to use the v2 APIs from release 0.55 onwards. - -**Vega Wallet**: For most use cases, the v2 [wallet API](../api/vega-wallet/before-you-start.md) 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. -::: - -### Breaking Changes - -#### Data node `init` requires the `ChainID` parameter -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. To find out more about the feature please read the [Decentralised History readme file](https://github.com/vegaprotocol/vega/tree/develop/datanode/dehistory). This work was done under the issue [6227 ↗](https://github.com/vegaprotocol/vega/issues/6227). - -#### Allow the user to specify a different passphrase when isolating a key -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. This work was done under the issue [6477 ↗](https://github.com/vegaprotocol/vega/issues/6477). - -#### Output from nodewallet reload is now more useful JSON -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. This work was done under the issue [6549 ↗](https://github.com/vegaprotocol/vega/issues/6549). - -#### Rename get bundles API function `GetMultiSigSigner` to `ListMultiSigSigner` -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`. This work was done under the issue [6458 ↗](https://github.com/vegaprotocol/vega/issues/6458). - -#### Swap places of PID and date in log files in the wallet service -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`. This work was done under the issue [6506 ↗](https://github.com/vegaprotocol/vega/issues/6506). - -#### Refactor datanode API for getting balance history -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 aslo fixes an issue with leaking account IDs. This work was done under the issue [6513 ↗](https://github.com/vegaprotocol/vega/issues/6513). - -#### Allow negative position decimal places for market -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. This work was done under the issue [6505 ↗](https://github.com/vegaprotocol/vega/issues/6505). - -### Critical Bug fixes - -#### Price monitoring price-range cache restored incorrectly -When restoring the `pricemonitor` for a market from a snapshot, the integer-representation from the `wrappedDecimal`s used for the price-range cache are derived from the decimal representation. This is slightly different to how they are created in the normal, non-snapshot code path. This causes markets to act differently after a snapshot restore, and eventually the restored node falls out of consensus. This fix was implemented under issue [6525 ↗](https://github.com/vegaprotocol/vega/issues/6525). - -### New features: Core - -#### Add reason to stopped or rejected transfer events -In order to know why a transfer event has been stopped or rejected the reason for the transfer rejection is now exposed in `BUS_EVENT_TYPE_TRANSFER` events. This work was done under the issue [6529 ↗](https://github.com/vegaprotocol/vega/issues/6529) - -#### Update Tendermint to v0.34.22 -To keep Tendermint up-to-date with all of the latest bug fixes it has been upgraded to v0.34.22. To find out more about the changes please see the [Tendermint changelog](https://github.com/tendermint/tendermint/blob/v0.34.22/CHANGELOG.md#v03422). This work was done under the issue [6548 ↗](https://github.com/vegaprotocol/vega/issues/6548). - -### New features: Data node - -#### Data node handles upgrade block and ensures data is persisted before upgrade -In order to ensure that the whole state of the data node matches that of the validator nodes, the data node should ensure that it processes all blocks up to the block height of a scheduled upgrade before shutting down. Respectively the core node shouldn't shut down until the data node has consumed all the blocks in the broker queue. This work was done under the issue [6080 ↗](https://github.com/vegaprotocol/vega/issues/6080). - -#### Add last-block sub-command to data node CLI -To make the Vega Visor UX easier to restart a node on the network, a command has been added to the data node software that will return the height of the last block committed. This will make it easier for Visor to know at what snapshot height it should start the core. This work was done under the issue [6527 ↗](https://github.com/vegaprotocol/vega/issues/6527). - -### New features: Wallet - -#### Add new wallet commands -In order to further improve the UX on the wallets, two new commands have been added. These commands allow both the name and the passphrase of a wallet to be updated. These changes have been implemented in [6530 ↗](https://github.com/vegaprotocol/vega/issues/6530) and [6531 ↗](https://github.com/vegaprotocol/vega/issues/6531) respectively. - - -## Pre-release Version 0.58.0 | 2022-10-17 -This version was released to the Vega testnet on 17 October, 2022. - -For full details see the vega core [0.58.0 release page ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.58.0). - -The primary focus of this release has been to add general bug fixes and improvements, improve the stability of the network and continue to implement data node snapshots ahead of this feature being used for protocol upgrades and new nodes joining the network. - -### Breaking Changes - -#### Data-node API field name changes -The market proposal (data source) field `settlementPriceDecimals` was changed to `settlementDataDecimals`, in version 0.56, 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` This work was done under issue [6367 ↗](https://github.com/vegaprotocol/vega/issues/6367). - -#### Require signature from new Ethereum key to validate key rotation submission. -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. The work was completed in issue [6316 ↗](https://github.com/vegaprotocol/vega/pull/6316) where you can also see the new flow. - -#### Improve the estimate fee and margin APIs -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. This work was done in [6420 ↗](https://github.com/vegaprotocol/vega/pull/6402). - -#### Wallet improvements -As of today users can only temporarily approve or reject a wallet connection using a boolean. In the future, support will be required for other options, such as permanently approve or reject a host name. The interaction has been updated to accept a "mode" instead of a simple boolean. The boolean changes from `yes` | `no` to mode `APPROVED_ONLY_THIS_TIME` | `REJECTED_ONLY_THIS_TIME` and was implemented in [6428 ↗](https://github.com/vegaprotocol/vega/issues/6428). - -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. This work was implemented in [6430 ↗](https://github.com/vegaprotocol/vega/issues/6430). - -The final breaking change for the wallet in 0.58 improves the wallet interactions framework. To make the framework clearer, the name `pipeline` has been updated to `interactor`. The work was implemented under[6309 ↗](https://github.com/vegaprotocol/vega/pull/6309) where you can see all the API changes. - -### Critical Bug fixes - -#### Error if the same node is announced twice -During testing it was found that there was no error should a single node be announced to the network more than once. The core was not flagging the second announced (duplicate) node as added. The work completed in [6444 ↗](https://github.com/vegaprotocol/vega/issues/6444) ensures that the core will return an error if adding a node fails. - -#### Failed to extract orders as not enough volume within price limits -During testing, `cumlativeVolumeAndPrice` caused a panic with the error "Failed to extract orders as not enough volume within price limits". To resolve this, the protocol resets `minPrice` and `maxPrice` once the cumulative volume is built if it is recalculated. This work was done in [6406 ↗](https://github.com/vegaprotocol/vega/issues/6406). - -#### Failed to extract orders as not enough volume within price limits -At the end of final market settlement, there was a panic if the settlement balance is not zero. To resolve this in most cases, if there is one unit left over at the end of final market settlement, the balance will be transferred to the network treasury. Should there be more than one unit remaining the protocol will log all transfers and panic. [6434 ↗](https://github.com/vegaprotocol/vega/issues/6434). - -#### Wallet selection selection fails when wallet has a capitalised name -When the wallet name is capitalised, the wallet would fail saying that is is not a valid option. This is because the verification formats the name to lowercase to ensure the user input is not a problem. This change removes the lowercase formatting during the verification and therefore requires that the user respects the case of the wallet name. This work was done in [6359 ↗](https://github.com/vegaprotocol/vega/issues/6395). +**Rename `marketId` and `partyId` in the orders queries' filter** [(v0.70)↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0700): 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. -### New features: Core +**Use nanoseconds for one-off transfers** [(v0.70)↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0700): The time input field now validates for nanoseconds, which is consistent with other inputs. -#### Add `GetTransaction` API call for block explorer -In release 0.57 the new Block Explorer service code and APIs were created. This has now been enhanced to include the `GetTransaction` API call. This work was done in [6435 ↗](https://github.com/vegaprotocol/vega/issues/6435). +**Require slippage factors in market proposals** [(v0.69)↗](https://github.com/vegaprotocol/vega/releases/tag/v0.69.0): When creating a new market proposal the `linear` and `quadratic` slippage factor fields have been changed from optional to required. -:::info -The service to be able to interact with the block explorer API will be enabled in testnet before 0.59. Details on configuring and running will also part of the validator deployment instructions for mainnet, when it is applicable. -::: +**Data node API rate limiting** [(v0.68)↗](https://github.com/vegaprotocol/vega/releases/tag/v0.68.0): 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. -### New features: Data node +**`IssueSignatures` command** [(v0.68)↗](https://github.com/vegaprotocol/vega/releases/tag/v0.68.0): 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. -#### Add maximum lifetime to postgres connections -Before the release of 0.58, postgres connections in the pool were never closed. This created a risk whereby any memory leaks, in any of the postgres worker processes, would result in that memory never being reclaimed. The addition of `pgxpool` as a config option with default values means connections will be closed after a certain time, with functionality to avoid starving the pool all at once. This work was done in [6461 ↗](https://github.com/vegaprotocol/vega/issues/6461). +**Removed: `Grpc-Metadata-` headers** [(v0.68)↗](https://github.com/vegaprotocol/vega/releases/tag/v0.68.0): The deprecated headers with the `Grpc-Metadata-` prefix in datanode API and REST and GraphQL gateways have been removed. -#### Handle `BeginBlock` and `EndBlock` events -In order for the data node snapshots feature to work in alignment with core and the blockchain, the data node will use `BeginBlock` and `EndBlock` events. This will allow the datanode to know which block to stop processing data from, and which to start again from. This will provide seamless data during protocol upgrades. This work was implemented in [6211 ↗](https://github.com/vegaprotocol/vega/issues/6211). +**Removed: Network API fields removed**[(v0.68)↗](https://github.com/vegaprotocol/vega/releases/tag/v0.68.0): Legacy fields from network API have now been removed. -#### Add Ledger Entry API -This change introduces an API to query the `LedgerEntry` schema. `LedgerEntry` objects can be filtered by asset ID, market ID, or party ID for sending and receiving accounts, as well as on transfer types. This API was implemented under issue [6368 ↗](https://github.com/vegaprotocol/vega/issues/6368). +**Deprecated: `X-Vega-Connection` HTTP header**[(v0.68)↗](https://github.com/vegaprotocol/vega/releases/tag/v0.68.0): 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. -#### New features: Wallet -Version 0.58 brings with it a number of improvements to the wallet both for the end user and developers that will use the wallet APIs. The full list of wallet changes and improvements can be seen in the [0.58.0 release page ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.58.0) issues that are also labeled with `wallet`. +**Removed: Wallet command removals** [v0.66 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.66.0): 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](../tools/vega-wallet/cli-wallet/guides/get-help.md). -#### Support parallel requests in wallet API version 2 -This change brings with it the ability to support parallel requests, which from a CLI application point of view is ok, however may limit UX with the desktop wallet and any future UI based wallets. The work done to implement this improvement was done in [6308 ↗](https://github.com/vegaprotocol/vega/issues/6308). +**Renamed: Network parameter** [v0.66 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.66.0): The network parameter `stakeToCcySiskas` has been renamed to `stakeToCcyVolume`. -#### Improve interactions documentation -With a large amount of the improvements in this version focusing on the wallet interactions, this change updates existing and creates new documentation about the interactions. This will help speed up the lead times for developers to integrate with the existing service. The documentation improvements were made under [6427 ↗](https://github.com/vegaprotocol/vega/issues/6427). +**Format change: triggering ratio parameter** [v0.66 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.66.0): 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. -## Pre-release Version 0.57.0 | 2022-09-28 -This version was released to the Vega testnet on 28 September, 2022. +**Market definition API** [v0.65 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.65.0): The market definition API has been extended with the new field for LP price range, this has resulted in a breaking change. -For full details see the vega core [0.57.0 release page ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.57.0). +**Data source decimal places** [v0.65 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.65.0): The decimal places are now defined in the oracle data source and removed from the market definition resulting in a breaking change. -The primary focus of this release has been to improve the stability of the network, add functionality for better exploring the blockchain, and implement data node snapshots ahead of this feature being used for protocol upgrades and new nodes joining the network. +**Vega tools** [v0.62 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.62.0): 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. -### Breaking Changes -The release of [0.57 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.57.0) brings with it a small number of breaking changes. +**Data sourcing** [v0.61 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.61.0): 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`. -#### Changing clef address now requires re-importing config -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 only ever uses the value set for the clef address when the key was imported/generated. This work was done under issue [6291 ↗](https://github.com/vegaprotocol/vega/issues/6291) +**Deprecation: Wallet API v1** v0.62: For most use cases, the v2 [wallet API](../api/vega-wallet/before-you-start.md) 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. -#### Wallet v2 API `session` renamed -To add more clarity to what the wallet API does, the `session` namespace has been renamed to `client`. This work was done under issue [6314 ↗](https://github.com/vegaprotocol/vega/issues/6314) +**Data node `init` now requires the `ChainID` parameter** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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. -### New features: Core +**User can now specify a different passphrase when isolating a key** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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. -#### Block explorer APIs -To support the block explorer to list transactions and provide a good user experience, a service and new APIs have been implemented. This work was carried out in [6163 ↗](https://github.com/vegaprotocol/vega/issues/6163) +**Output from nodewallet reload is now more useful JSON** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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. -### New features: Data node +**Renamed API: get bundles function `GetMultiSigSigner` to `ListMultiSigSigner`** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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`. -#### Data node snapshots -As part of the protocol upgrade process and when new nodes join the network, the nodes need to ensure the data node data is correct. Data node snapshots will be used for these use cases. This is an ongoing in-development feature, this part was implemented in [6239](https://github.com/vegaprotocol/vega/pull/6239) +**Swap places of PID and date in log files in the wallet service** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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`. -#### Update asset proposal to include the asset ID in GraphQL response -In order to ensure GraphQL users understand which asset is being updated the field `assetId` has been added into the `UpdateAsset` proposals response. This work was done under issue [6296 ↗](https://github.com/vegaprotocol/vega/issues/6296) +**Renamed API: Balance history** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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. -#### Add rate limiter for GraphQL -During testing it was identified that GraphQL subscriptions could cause overloading on the data node. A rate limiter has been implemented for GraphQL subscriptions. This work was implemented under [6334 ↗](https://github.com/vegaprotocol/vega/pull/6334) +**Negative position decimal places for market** [v.0.59 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.59.0): +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. -### New features: Wallet +**Renamed API: settlement price decimals** [v.0.58 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.58.0): +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`. -#### Add commit hash to version if development version -To avoid version confusion by developers and builders due to the wallet not raising compatibility issues between different development versions of the software, the version check has been enhanced to add the commit hash (first 8 characters) behind the +dev build tag. This work was carried out in issue [6283 ↗](https://github.com/vegaprotocol/vega/issues/6283) +**Require signature from new Ethereum key to validate key rotation submission** [v.0.58 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.58.0): +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 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.58.0): +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. -## Pre-release Version 0.56.0 | 2022-09-26 -This version was released to the Vega testnet on 26 September, 2022. +**Wallet improvements** [v.0.58 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.58.0): +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`. -For full details see the vega core [0.56.0 release page ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.56.0). +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. -The primary focus of this release has been to resolve a number of critical bugs that have caused stability issues. +To make the framework clearer, the name `pipeline` has been updated to `interactor`. -### Breaking Changes -The release of [0.56 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.56.0) brings with it a small number of breaking changes. +**Changing clef address requires re-importing config** [v.0.57 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.57.0): +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. -#### Clef wallet signatures not readable by network +**Fork: Clef forked so signatures are readable** [v.0.57 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.57.0): 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 ↗](https://github.com/vegaprotocol/vega/issues/6187) -#### Clean up unused network parameters -During recent development, a number of network parameters have been replaced or are no longer required. In order to have clean code, the unused network parameters have been removed. This work was done under issue [6196 ↗](https://github.com/vegaprotocol/vega/issues/6196) - -#### Wallet v2 API field name change -To make the wallet API v2 clearer to understand, the field `Client` has been renamed to `User`. This work was implemented in issue [6155 ↗](https://github.com/vegaprotocol/vega/issues/6155) - -### Data-node API field name changes -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`. This change was made under [5641 ↗](https://github.com/vegaprotocol/vega/issues/5641) - -To ensure clarity of the positions subscription API the field name `Position` has been updated to `PositionUpdate`. This change was made under [6162 ↗](https://github.com/vegaprotocol/vega/issues/6162) - -### Critical Bug fixes - -#### Equity like share calculations -The equity like share feature applied the market growth scaling factor to the virtual stakes every block, instead of every market window. This resulted in the core spending an increasing amount of time carrying out calculations, thus having to serialise larger and larger decimals values and marshall and store each bit of data. The snapshot engine was unable to process correctly and caused network instability. The fix for this bug was carried out as part of [6245 ↗](https://github.com/vegaprotocol/vega/issues/6245) - -#### Data-node failed to process key rotation -During testing of the wallet key rotation feature, the wallet rotation transaction was not processed correctly by the data-node software, causing the data-node to crash on update. This bug was resolved in issue [6175 ↗](https://github.com/vegaprotocol/vega/issues/6175) - -#### Snapshot creation -It was found that when stopping a node core was being stopped before tendermint. This meant that the snapshot engine would close its connection to the snapshot database, however, as tendermint was still running it would try to commit a block and save a new snapshot even though the core had stopped. This issue was resolved in issue [6183 ↗](https://github.com/vegaprotocol/vega/issues/6183) - -### New features: Core -As the `BlockchainsEthereumConfig` network parameter has core code dependencies it should not be changed via the normal governance proposal and enactment process. This change ensures that a change to this via network parameter governance will be rejected. Adding this parameter to the `updateDisallowed` list in issue [6254 ↗](https://github.com/vegaprotocol/vega/issues/6254) ensures this parameter can only be considered for change through a freeform governance proposal. - -### New features: Data node -To enhance the GraphQL API user experience, newly added API endpoints have been documented and the schema (query and subscription types) have been ordered alphabetically. This work was done in [6221 ↗](https://github.com/vegaprotocol/vega/issues/6221) and [6170 ↗](https://github.com/vegaprotocol/vega/issues/6170) respectively. - -### New features: Wallet -The focus of the wallet work in this release is to migrate the remaining wallet capabilities to the v2 API. Any wallet UIs can stop using the soon-to-be-deprecated v1 APIs without loss of functionality. This work was done in [5600 ↗](https://github.com/vegaprotocol/vega/issues/5600) - -#### Add proof-of-work to transaction when using vegawallet command `sign` -Proof-of-work is now attached to the Vega Wallet return transaction command `sign`. This is done either by specifying a network which will be used to call `LastBlockHeightAndHash` or by passing in the `LastBlockData` manually. This work and information on using these instructions is detailed in issue [6077 ↗](https://github.com/vegaprotocol/vega/issues/6077) - -#### Automatic consent for transactions -The permission and connection requests for consent are the last layer of protection when using the Vega Wallet, however, in some cases users may require these requests have automatic consent. The command line flag `--automatic-consent` has been added to wallet API v2 to override the default security, which brings this v1 feature into the new API. This has been implemented in issue [6203 ↗](https://github.com/vegaprotocol/vega/issues/6203) - -## Pre-release Version 0.55.0 | 2022-09-20 -This version was released to the Vega testnet on 20 September, 2022. - -For full details see the vega core [0.55.0 release page ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.55.0). - -The primary focus of this release has been to progress work on the data node ensuring there is a scalable data store with historical data, resolve any bugs found and to improve the node operator experience. - -:::warning API deprecations -**Data node**: The v2 APIs ([REST](./../api/rest/overview) and [gRPC](./../api/grpc/data-node/api/v2/trading_data.proto)) for the data node will be replace v1, which will soon be removed. Therefore anyone building apps on to of Vega should start to use the v2 APIs from this release (0.55) onwards. - -**Vega Wallet**: For most use cases, the v2 [wallet API](../api/vega-wallet/before-you-start.md) 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. -::: - -### Breaking Changes -The release of [0.55 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.55.0) brings with it a small number of breaking changes. +**Removed: Clean up unused network parameters** [v.0.57 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.57.0): +A number of network parameters have been replaced or removed as they were not required. -#### Remove liquidity commitment from market proposal -Before the deployment of 0.55 liquidity commitment was optional on a market proposal. This change removes the option for any liquidity commitment completely from the market proposal. This work was done in issue [5989 ↗](https://github.com/vegaprotocol/vega/issues/5989). +**Renamed fields: settlement price data** [v.0.56 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.56.0): +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`. -#### Remove market name from GraphQL market type -The [market framework specification ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0001-MKTF-market_framework.md) does not mention having the market `name` field at the top level definition of a market. This has been fixed such that the `name` and `code` fields are at the instrument level as per the specification. This work was done in issue [6031 ↗](https://github.com/vegaprotocol/vega/issues/6031). +**Renamed API: Positions WebSocket** [v.0.56 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.56.0): +To ensure clarity of the positions subscription API the field name `Position` has been updated to `PositionUpdate`. -#### Rename rewards from taker fee to maker fee -In order to correct and clean up names in the APIs, the following account types and dispatch metrics names have been changed to match existing fee names: -`AccountType_ACCOUNT_TYPE_REWARD_TAKER_PAID_FEES` is now named `AccountType_ACCOUNT_TYPE_REWARD_MAKER_PAID_FEES` -`DispatchMetric_DISPATCH_METRIC_TAKER_FEES_PAID` is now named `DispatchMetric_DISPATCH_METRIC_MAKER_FEES_PAID` -This work was done in issue [6095 ↗](https://github.com/vegaprotocol/vega/issues/6095). +**Use the latest local snapshot as default behaviour when restarting a node** [v.0.55 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.55.0): +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. -#### Use the latest local snapshot as default behaviour when restarting a node -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. This work was done in issue [5442 ↗](https://github.com/vegaprotocol/vega/issues/5442). - -#### Return the key on `session.list_keys` endpoint on wallet API version 2 -With the introduction of the [v2 wallet API](../api/vega-wallet/before-you-start.md) there is now added security in order for a dApp to request metadata that can be used by the user to label a key in wallet and dApp, thus preventing data being leaked unintentionally. This work was done in issue [6139 ↗](https://github.com/vegaprotocol/vega/issues/6139). - -### Critical Bug fixes - -#### Data nodes serve stale data if their Vega node dies -It was identified that if a core node fails the validators data-node can serve stale data. In order to resolve this, the data node team has added headers `X-Block-Height`, `X-Block-Timestamp` and `X-Vega-Connection` to all API responses. Using this approach will not break any current client implementations that rely on a 200 status code, but gives a clear indicator of the state of the API responses. This work was done in issue [5971 ↗](https://github.com/vegaprotocol/vega/issues/5971). - -#### Asset cache was returning stale data -During QA testing, an asset which has been proposed, enabled and listed was being reported as `STATUS_PROPOSED`, when it should have been `STATUS_ENABLED`. This was due to fetching an asset by ID after it had been updated, but before the transaction was committed leading to a poisoned cache that returned stale values. This work was done in issue [5687 ↗](https://github.com/vegaprotocol/vega/issues/5687). - - -#### Fix panic on settlement -During testing using the [Vega Market Simulator ↗](https://github.com/vegaprotocol/vega-market-sim), the protocol panicked on a settlement. It was found that because trading was terminated the oracle data source has already been unsubscribed from thus causing the panic. This bug has been resolved under [6054 ↗](https://github.com/vegaprotocol/vega/issues/6054). - -#### Price and pegged offset in orders need to accept decimals -During investigations of this bug the team found that `orderPrice` and `peggedOffset` were using incorrect types. As the data node needs to be able to hold numbers greater than 9.2e18 for these values the types were updated. This bug was resolved in [6144 ↗](https://github.com/vegaprotocol/vega/issues/6144). - -### New features: Core -The project core engineering team have been working on completing the following features, on bug fixing, and on performance and stability improvements in readiness for a community governance vote to enable markets to be created on the network. - -#### Equity-like-share -The guiding principle of splitting fees between liquidity providers is that by committing stake, a liquidity provider gets a virtual stake of the market value that relates to how trading has grown on the market. The virtual stake then determines equity-like-share. Equity-like-share is then used to calculate the fee revenue split between LPs. A problem was identified whereby in extreme cases when trading volume was zero in the previous period, or if it is zero in the current period, then a growth variable was not defined. To resolve this, under the extreme conditions, the virtual stake now reverts to the physical stake. This work was carried out in [5358 ↗](https://github.com/vegaprotocol/vega/issues/5358) to match the spec change in [1088 ↗](https://github.com/vegaprotocol/specs/pull/1088). - -#### Vega Visor -Without Vega Visor, upgrading the protocol is near impossible when major changes are to be implemented, without using a [limited network life checkpoint restore ↗](https://github.com/vegaprotocol/specs/non-protocol-specs/0005-NP-LIMN-limited_network_life.md). This has the undesired effect of requiring synchronous restarts and for it to happen within a short window of time so all state can be restored from Ethereum, and the network can start properly with a checkpoint. The Vega Visor protocol upgrade process enables upgrading the network both asynchronously and without a restart / downtime. The validators signal their readiness to upgrade at a block height in the future and the Vega Visor orchestrates the upgrade, managing the state of the two versions. The development work on this feature has been completed and the QA team are now focused on proving its readiness for mainnet deployments. The work was carried out under the issue [5717 ↗](https://github.com/vegaprotocol/vega/issues/5717). - -#### Batch order instructions -The implementation of batch order instructions adds a transaction type that allows a user to submit multiple market instructions (e.g. submit order, cancel order, amend order) in a single transaction. This decreases the complexity of client integrations, and furthermore, reduces the computational and network load on both validators and clients. It will also make Vega's functionality and APIs closer to parity with those of traditional centralised exchanges. -The work for this feature was carried out under issue [5961 ↗](https://github.com/vegaprotocol/vega/issues/5961) to the following [specification ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0074-BTCH-batch-market-instructions.md). - -#### Add some Vega tools into the Vega repo -The `vegatools` repo contains a number of useful tools to aid development and investigations of the protocol. The tools that integrate most closely with the core software have been brought into the Vega repo, meaning these are exposed through the CLI and can be run in a terminal alongside the Vega binary. Specifically, tools to help investigate and debug streams, snapshots and checkpoints have been integrated. The work was carried out under the issue [5807 ↗](https://github.com/vegaprotocol/vega/issues/5807). - -### New features: Data node -Data node work has focused on addressing scalability and adding the final features to complement protocol upgrades and new nodes joining the network. The primary work that has made it into this release and deployment has been on the APIs: fixing bugs and improving the UX. - -#### Expose equity share weight in the API -For both users querying the data node and for front end applications to display liquidity provision information, an API to expose the total `equityLikeShare` has been added. This was implemented under issue [5682 ↗](https://github.com/vegaprotocol/vega/issues/5682) - -#### Added date range to a number of historic balances, deposits, withdrawals, orders and trades queries -To further enhance the pagination implemented in the version 2 data node APIs, date ranges have been added to a number of queries. This work was carried out under the issue: [5684 ↗](https://github.com/vegaprotocol/vega/issues/5684) - -#### Set GraphQL query complexity limit -To ensure that the data node does not have overly complex queries that could cause performance issues, a complexity limit has been calculated and implemented. This work has been carried out under the issue [6042 ↗](https://github.com/vegaprotocol/vega/issues/6042). - -#### Update GraphQL endpoints and add fields -In order to allow both users and front end applications to access data via GraphQL, the follow endpoints for Ethereum bundles have been added: `listAsset`, `updateAsset`, `addSigner` and `removeSigner`. The field `settlementPriceDecimals` has also been added to GraphQL future and future product types. This work was done in the issues [5678 ↗](https://github.com/vegaprotocol/vega/issues/5678) and [5694 ↗](https://github.com/vegaprotocol/vega/issues/5694) respectively. - -#### New features: Wallet -The focus of the wallet development work has been to implement the V2 APIs. This API version offers increased security for users as important data is no longer input into a dApp/website thus reducing the risk of data being unintentionally leaked. - -#### Signing transactions with the V2 API -In order to ensure that users can sign their transactions in the wallet using the V2 API the functionality and endpoints have been added. This work was carried out in issues [6106 ↗](https://github.com/vegaprotocol/vega/issues/6106) and -[6105](https://github.com/vegaprotocol/vega/issues/6105). - -#### Better notification for version update on the wallet -As development progresses both on the protocol and the wallet, it is important that users keep up-to-date. Additional notifications have been added to ensure that users are notified of the need to update their wallet version. This work was carried out in issues [5766 ↗](https://github.com/vegaprotocol/vega/issues/5766). - - -## Pre-release Version 0.54.0 | 2022-08-19 -This version was released to the Vega testnet on 19 August, 2022. - -For full details see the vega core [0.54.0 release page ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.54.0) - -#### Breaking Changes - -**Vega as a built-in application:** -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: +**Vega as a built-in application** [v.0.54 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.54.0): +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 node` command has been renamed to `vega start`. - The `vega tm` command has been renamed to `vega tendermint`. - The `Blockchain.Tendermint.ClientAddr` configuration field has been renamed to `Blockchain.Tendermint.RPCAddr`. - The `init` command now also generates the configuration for tendermint, and also has the newly introduced flags `--no-tendermint`,` --tendermint-home` and `--tendermint-key`. -This work was all done in issue [5579 ↗](https://github.com/vegaprotocol/vega/issues/5579) - -**Remove `updateFrequency` in price monitoring definition:** -The `updateFrequency` within price monitoring is not being used by the core protocol, therefore, this has now been removed. This work was done in issue [5624 ↗](https://github.com/vegaprotocol/vega/issues/5624) - -**Remove wallet support for launching a proxy in front of dApps:** -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. This has been carried out in the issue [5601 ↗](https://github.com/vegaprotocol/vega/issues/5601) - -#### Critical Bug Fixes - -**Updating oracle termination caused the core to panic:** -During a recent incentive on testnet it was found that when a user made the oracle termination conditions to be set to be ten seconds in the future and before the market could be enabled; when the network reached this time the core threw a panic. -This bug has been resolved in [5668 ↗](https://github.com/vegaprotocol/vega/pull/5668) - -**Network parameter set to `0` can cause node startup failure:** -An issue was discovered using the [Market Simulator](https://github.com/vegaprotocol/vega-market-sim) when the governance parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` is set to `0` in the `genesis.json`, this resulted in the node startup failing. The fix implemented in [5633 ↗](https://github.com/vegaprotocol/vega/issues/5633) addresses this and allows the value to be `0`. - -**Cannot unregister order caused core to crash in Market Simulator:** -When using the [Market Simulator ↗](https://github.com/vegaprotocol/vega-market-sim) it was found that a "cannot unregister order" error was thrown for pegged orders and caused the core to crash. This bug has been resolved in [5663](https://github.com/vegaprotocol/vega/issues/5663) - -**Pegged orders not removed from list after repricing:** -It was identified that during a market's life when it is not in an auction and a pegged order gets repriced, the order was removed from the book, however, it remained in the pegged orders list. If the market then goes into an auction the pegged order list is used to try to get the order from the book, but as the order no longer exists, it can't be done. This bug has been resolved in [5825 ↗](https://github.com/vegaprotocol/vega/issues/5825) -#### Core +**Removed: Wallet support for launching a proxy in front of dApps** [v.0.54 ↗](https://github.com/vegaprotocol/vega/releases/tag/v0.54.0): +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. -**Asset proposal:** -In order to complete the governance features, asset proposals have been implemented. This allows a user to propose and modify assets on the network via the governance process. This work was completed in [5242 ↗](https://github.com/vegaprotocol/vega/issues/5242) and [5851](https://github.com/vegaprotocol/vega/pull/5851) - -**Tendermint:** -During the development of this software version, the team upgraded Tendermint to 0.35. This change would have brought breaking changes with it, however, the Tendermint project team announced this version will be discontinued. To find out more please see [the Tendermint blog post ↗](https://interchain-io.medium.com/discontinuing-tendermint-v0-35-a-postmortem-on-the-new-networking-layer-3696c811dabc). In light of this, the upgrade has been rolled back and Vega 0.54 will use the tendermint version 0.34.20. This work was done in issue [5249 ↗](https://github.com/vegaprotocol/vega/issues/5249) and rolled back in issue [5804 ↗](https://github.com/vegaprotocol/vega/issues/5804) - -#### Data Node - -**Move data node into the core repository:** -In order to simplify the release process, running a node and manage dependencies across code repositories, the data node software has been incorporated into the core Vega repo. This work was done in issue [5613 ↗](https://github.com/vegaprotocol/vega/issues/5613). - -**Version 2 APIs:** -Since the introduction of the PostgresQL database and work to stabilise this, the team has now migrated all the APIs to use the new database. Version 2 APIs introduce pagination and filtering to provide a better user experience for people using the network both via the APIs and via dApps. This work was done in issue [5685 ↗](https://github.com/vegaprotocol/vega/issues/5685) and issue [5660 ↗](https://github.com/vegaprotocol/vega/issues/5660). Further work on the V2 APIs will be released in the next version. - -**API improvements:** -In order to ensure API parity between the API types the gRPC endpoints have all been mapped to REST. Further work on the GraphQL APIs remains in progress and will be in the next version. This work was done in issue [5760 ↗](https://github.com/vegaprotocol/vega/issues/5760) - -#### Wallet - -The Vega Wallet API has been completely rewritten to support all authentication happening within the wallet apps, rather than on the UI-side. These changes have been implemented to provide better wallet security. The wallet has also had some updates in order to provide more meaningful responses when a transaction fails providing a better UX for wallet users. The implementation has been carried out in issues [5439 ↗](https://github.com/vegaprotocol/vega/issues/5439), [5541 ↗](https://github.com/vegaprotocol/vega/issues/5541) and [5503 ↗](https://github.com/vegaprotocol/vega/issues/5503). - -Further information on these changes can be found in the updated documentation implemented in issues [5618 ↗](https://github.com/vegaprotocol/vega/issues/5618) and [5619 ↗](https://github.com/vegaprotocol/vega/issues/5619). - -## Versions 0.53.1 and 0.53.2 combined | 2023-03-22 -This version was released to the Vega mainnet on 22 March 2023. +### 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 ↗](https://github.com/vegaprotocol/vega/issues/7936) and the [incident blog ↗](https://blog.vega.xyz/incident-report-validator-nodes-down-in-mainnet-2ac2f724d67e) -## Versions 0.53-0.51 | 2022-08-15 -This version was released to mainnet by the validators on 15 August, 2022. +### 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 will come an 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. +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. @@ -1314,20 +853,20 @@ In the short term, the CLI wallet app will still be available to download from t 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 ↗](https://github.com/vegaprotocol/data-node/blob/v0.53.0/README.md).** +**Find out how to run a data node with Postgres in the [data-node readme](https://github.com/vegaprotocol/data-node/blob/v0.53.0/README.md).** -As of version 0.53, data node uses [PostgreSQL ↗](https://www.postgresql.org) 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](https://www.timescale.com), which adds a number of time series specific features. +As of version 0.53, data node uses [PostgreSQL](https://www.postgresql.org) 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](https://www.timescale.com), 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 ↗](https://github.com/vegaprotocol/data-node/blob/v0.53.0/README.md)**. +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](https://github.com/vegaprotocol/data-node/blob/v0.53.0/README.md)**. **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 ↗](https://github.com/vegaprotocol/vega/issues/5546) +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](https://github.com/vegaprotocol/vega/issues/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 ↗](https://github.com/vegaprotocol/data-node/issues/782) +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](https://github.com/vegaprotocol/data-node/issues/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. @@ -1337,17 +876,17 @@ In V1 of the data node (which will be replaced with V2) there is a check which r 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 ↗](https://github.com/vegaprotocol/data-node/issues/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. +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](https://github.com/vegaprotocol/data-node/issues/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 ↗](https://github.com/vegaprotocol/data-node/issues/730) +Full details can be seen in issue [730](https://github.com/vegaprotocol/data-node/issues/730) -### 0.52.0 (15 June 2022) +#### 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. +#### 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. @@ -1371,22 +910,22 @@ The snapshot system will keep by default 10 versions of the snapshots. When it h 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 +### 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 ↗](https://github.com/vegaprotocol/vega/pull/5510) - fix: dedupe sorting made consistent +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](https://github.com/vegaprotocol/vega/pull/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 ↗](https://github.com/vegaprotocol/vega/pull/5515) - fix: emit `rewardScore` correctly when loading from checkpoint +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](https://github.com/vegaprotocol/vega/pull/5515) - fix: emit `rewardScore` correctly when loading from checkpoint For full detailed information on the changes please see: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/release/v0.50.4/CHANGELOG.md#0504) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/release/v0.50.4/CHANGELOG.md#0504) -## Versions 0.50.3-0.49.8 combined | 2022-04-27 +### 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. +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. @@ -1395,14 +934,14 @@ Note: While many of the features below are related to trading, it is not yet ena 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: -* [Market framework spec ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0001-MKTF-market_framework.md#market) -* [Change market parameters ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0028-GOVE-governance.md#2-change-market-parameters) +* [Market framework spec](https://github.com/vegaprotocol/specs/blob/master/protocol/0001-MKTF-market_framework.md#market) +* [Change market parameters](https://github.com/vegaprotocol/specs/blob/master/protocol/0028-GOVE-governance.md#2-change-market-parameters) **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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) +Read more: [Spam protection POW](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) **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. @@ -1410,7 +949,7 @@ This data is now stored in the checkpoints, which means that it is now possible **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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0067-KEYS-key_management.md) +Read more: [Key management](https://github.com/vegaprotocol/specs/blob/master/protocol/0067-KEYS-key_management.md) **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 @@ -1425,17 +964,17 @@ Read more: [Key management ↗](https://github.com/vegaprotocol/specs/blob/maste **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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0070-MKTD-market-decimal-places.md) +Read more: [Market decimal places](https://github.com/vegaprotocol/specs/blob/master/protocol/0070-MKTD-market-decimal-places.md) **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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0037-OPEG-pegged_orders.md) +Read more: [Pegged orders](https://github.com/vegaprotocol/specs/blob/master/protocol/0037-OPEG-pegged_orders.md) **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 ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0065-FTCO-floating_point_consensus.md) +Read more: [Floating point consensus](https://github.com/vegaprotocol/specs/blob/master/protocol/0065-FTCO-floating_point_consensus.md) **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. @@ -1444,8 +983,8 @@ Read more: [Floating point consensus ↗](https://github.com/vegaprotocol/specs/ 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: -* [On-chain treasury spec ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0055-TREA-on_chain_treasury.md) -* [Transfers spec ↗](https://github.com/vegaprotocol/specs/blob/master/protocol/0057-TRAN-transfers.md) +* [On-chain treasury](https://github.com/vegaprotocol/specs/blob/master/protocol/0055-TREA-on_chain_treasury.md) +* [Transfers](https://github.com/vegaprotocol/specs/blob/master/protocol/0057-TRAN-transfers.md) **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. @@ -1455,8 +994,8 @@ Note: The network will be set to allow 0 standby validators for alpha mainnet, a Read more: [Validators chosen by stake](https://github.com/vegaprotocol/specs/blob/master/protocol/0069-VCBS-validators_chosen_by_stake.md) For full detailed information on the changes please see: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0502) -* [Data node change log ↗](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0500) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0502) +* [Data node change log](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0500) #### Breaking changes - Separate endpoints for liquidity provision submissions, amendment and cancellation @@ -1473,7 +1012,7 @@ For full detailed information on the changes please see: - Remove maturity field from future - Remove trading mode one-off from market proposal -## Versions 0.46.0-0.47.6 combined | 2022-01-11 +### 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. @@ -1483,26 +1022,26 @@ The protocol calculates a validator score for each validator. This score is used 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: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0476) -* [Data node change log ↗](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0471) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0476) +* [Data node change log](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0471) -## Version 0.45.6 | 2021-12-22 +### Version 0.45.6 | 2021-12-22 For full detailed information on the changes please see: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0456) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0456) -## Version 0.45.4 | 2021-11-05 -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0454) +### Version 0.45.4 | 2021-11-05 +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0454) -## Versions 0.45.0-0.45.2 combined | 2021-10-27 +### Versions 0.45.0-0.45.2 combined | 2021-10-27 For full detailed information on the changes please see: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0452) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0452) * [Vega data node change log](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0451) -## Version 0.44.1 | 2021-10-08 +### Version 0.44.1 | 2021-10-08 For full detailed information on the changes please see: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0441) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0441) -## Version 0.44.0 | 2021-10-07 +### Version 0.44.0 | 2021-10-07 For full detailed information on the changes please see: -* [Vega core change log ↗](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0440) -* [Vega data node change log ↗](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0440) +* [Vega core change log](https://github.com/vegaprotocol/vega/blob/develop/CHANGELOG.md#0440) +* [Vega data node change log](https://github.com/vegaprotocol/data-node/blob/develop/CHANGELOG.md#0440) \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tools/index.md b/versioned_docs/version-v0.77/tools/index.md index 812dffdee..c1ac751f9 100644 --- a/versioned_docs/version-v0.77/tools/index.md +++ b/versioned_docs/version-v0.77/tools/index.md @@ -13,8 +13,7 @@ There are several ways to interact with a Vega Wallet: * **[Desktop wallet app](./vega-wallet/desktop-app/index.md)** ## Trading interface -Use **[Vega Console](https://console.fairground.wtf)** to try trading on a testnet trading interface. The Fairground network is set up to provide a fairly realistic experience where you can place orders, provide liquidity, and see how the market mechanics work. - +Use **[Vega Console](https://console.vega.xyz)** to trade on markets created with Vega. * **[Charts on Console](./tools/vega-console/charts)** * **[Host Console on IPFS](./tools/vega-console/host-console-on-ipfs)** @@ -25,7 +24,7 @@ Use the **[Vega Governance dApp](https://governance.vega.xyz)** to stake your to The block explorer allows you to query transactions, network parameters, available assets (and their IDs) and more. * **[Block explorer for mainnet](https://explorer.vega.xyz/)** -* **[Block explorer for fairground](https://explorer.vega.xyz/)** +* **[Block explorer for fairground](https://explorer.fairground.wtf/)** ## Vega Tools repo The **[Vega Tools repo](https://github.com/vegaprotocol/vegatools)** provides a set of utilities for inspecting and interacting with a Vega network through the APIs. diff --git a/versioned_docs/version-v0.77/tools/vega-console/charts.md b/versioned_docs/version-v0.77/tools/vega-console/charts.md index a89bd9753..21c457427 100644 --- a/versioned_docs/version-v0.77/tools/vega-console/charts.md +++ b/versioned_docs/version-v0.77/tools/vega-console/charts.md @@ -6,7 +6,7 @@ hide_title: false description: Console's charts in a nutshell. --- -The [Console ↗](https://console.fairground.wtf) trading interface has a variety of tools to enhance your market analysis. This includes [TradingView ↗](https://www.tradingview.com/chart/) and Vega charts. +The [Console ↗](https://console.vega.xyz) trading interface has a variety of tools to enhance your market analysis. This includes [TradingView ↗](https://www.tradingview.com/chart/) and Vega charts. You can switch between Vega charts and TradingView in Console's chart area. @@ -29,5 +29,4 @@ It includes: * Mountain charts * Line charts * Candlestick charts -* Technical indicators - +* Technical indicators \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tools/vega-protocol-snap.md b/versioned_docs/version-v0.77/tools/vega-protocol-snap.md index 1b29cfa3a..f56fcdc93 100644 --- a/versioned_docs/version-v0.77/tools/vega-protocol-snap.md +++ b/versioned_docs/version-v0.77/tools/vega-protocol-snap.md @@ -5,4 +5,61 @@ hide_title: false A snap lets you use your existing MetaMask account to quickly set up a Vega keypair for trading, staking tokens, and sending other transactions. No Vega Wallet software required. -The Vega snap is only available for mainnet right now. To learn more about it, switch to the mainnet version in this site's top navigation bar, or [click through to the mainnet snap page](https://docs.vega.xyz/mainnet/tools/vega-protocol-snap). \ No newline at end of file +## Set up your Vega snap +Once you have MetaMask installed, the easiest way to set up your new Vega key with MetaMask is with [Vega Console ↗](https://console.vega.xyz) or the Vega [governance dApp ↗](https://governance.vega.xyz). + +You'll be creating a new Vega key, so if you have assets or VEGA tokens on an existing key, you'll need to transfer them to the new key to use them. + +1. Open the `Connect` dialog in Vega Console or the governance dApp. +2. If you have a version of MetaMask that supports Snaps, you'll see a button labelled `Install Vega MetaMask Snap`. +3. MetaMask will open a Connection request pop-up. Click `Connect`. +4. `Install` using the MetaMask pop-up. +5. `Confirm` that you want Vega Protocol to control your account. +6. Use the Vega dApp `Connect` dialog to `Connect via MetaMask Snap` + +You're now ready to deposit or transfer assets and use your new Vega keypair. + +## What's Vega snap for? +If you're already a MetaMask user, you won't need to create a Vega Wallet to create and use a Vega key. + +The snap lets you: +- Derive Vega cryptographic keys that can be used on the Vega network +- Receive in-depth information of transactions you've initiated in the Vega dApp +- Approve transactions that will then be signed and sent to the network, or reject them +- Automatically connect to the Vega network you're using + +## Limitations +The Vega Protocol snap cannot: +- Connect to an existing Vega Wallet or keypair, you'll need to start with a new keypair +- Cannot show your Vega assets or their balances in MetaMask + - To see your balances, rewards, or deposit, withdraw or transfer assets between keys, you'll need to interact with Console or the governance dApp +- Rename, import, or export keys +- Show a list of previous transactions + +## Help with your Vega snap + +### I can't see assets I've previously deposited +If this is your first time using Snap with Vega, but you have previously deposited assets on a different Vega key, you'll need to deposit new assets, or transfer assets to the new keys created by your snap. + +You can copy your Vega snap public key from within Vega Console. + +### Can I create more than one key pair with Vega snap? +You can only create one keypair derived from your MetaMask seed, though this may change in the future. + +### How do I recover my Vega keys? +The Vega keypairs created with snap are derived from the MetaMask seed. Use your MetaMask recovery phrase to recover those Vega keys, and any assets added to them. + +### Any other questions? +If you have any trouble with using your Vega snaps, or have questions about how it works, ask on the dedicated [Discord channel ↗](https://discord.com/channels/720571334798737489/1111311863213473843/1111313848788602981). + +Share your feedback on Vega's [GitHub discussions ↗](https://github.com/vegaprotocol/feedback/discussions). + +## Snaps resources +The source code for the Vega snap integration is available on [GitHub ↗](https://github.com/vegaprotocol/vega-snap). + +Read more about snaps on the [MetaMask Snaps ↗](https://metamask.io/snaps/) site. + +## Other ways to set up Vega keys +You could instead use the [Vega Wallet browser extension](./index.md#vega-wallet-browser-extension) for Firefox and Chrome. + +For a full list of the alternatives, check out the [Vega Wallet](./vega-wallet/index.md) intro page. \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tools/vega-wallet/index.md b/versioned_docs/version-v0.77/tools/vega-wallet/index.md index d598d4d40..48aa6b11c 100644 --- a/versioned_docs/version-v0.77/tools/vega-wallet/index.md +++ b/versioned_docs/version-v0.77/tools/vega-wallet/index.md @@ -11,9 +11,9 @@ A Vega Wallet is essential for interacting with Vega, whether it's for staking o You can interact with a Vega wallet and its keys through a browser extension, two different apps, or integrate using the API. ## Browser extension -The Vega Wallet browser extension is an early stage implementation of the Vega Wallet, available for Chrome and Firefox. The extensions linked are only for use with the Fairground network. +The Vega Wallet browser extension is an early stage implementation of the Vega Wallet, available for Chrome and Firefox. -**[Chrome extension ↗](https://chrome.google.com/webstore/detail/vega-wallet-fairground/nmmjkiafpmphlikhefgjbblebfgclikn)** +**[Chrome extension ↗](https://chromewebstore.google.com/detail/vega-wallet/codfcglpplgmmlokgilfkpcjnmkbfiel)** **[Firefox extension ↗](https://addons.mozilla.org/en-GB/firefox/addon/vega-wallet-beta/)** diff --git a/versioned_docs/version-v0.77/topics/_topic-governance.mdx b/versioned_docs/version-v0.77/topics/_topic-governance.mdx index 26e4f4bb4..11d07fc87 100644 --- a/versioned_docs/version-v0.77/topics/_topic-governance.mdx +++ b/versioned_docs/version-v0.77/topics/_topic-governance.mdx @@ -10,7 +10,7 @@ Docs: Tools: -- [Vote and propose on the governance dApp ↗](https://governance.fairground.wtf) +- [Vote and propose on the governance dApp ↗](https://governance.vega.xyz) \ No newline at end of file diff --git a/versioned_docs/version-v0.77/topics/_topic-staking.mdx b/versioned_docs/version-v0.77/topics/_topic-staking.mdx index 63766e634..ec3b4f630 100644 --- a/versioned_docs/version-v0.77/topics/_topic-staking.mdx +++ b/versioned_docs/version-v0.77/topics/_topic-staking.mdx @@ -8,7 +8,7 @@ Docs: - [Tutorial: Stake via APIs and smart contracts](/tutorials/assets-tokens/staking-tokens.md) Tools: -- [Associate tokens, nominate validators on the governance dApp ↗](https://governance.fairground.wtf) +- [Associate tokens, nominate validators on the governance dApp ↗](https://governance.vega.xyz) \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tutorials/assets-tokens/staking-tokens.md b/versioned_docs/version-v0.77/tutorials/assets-tokens/staking-tokens.md index bf682617a..353a58ad6 100644 --- a/versioned_docs/version-v0.77/tutorials/assets-tokens/staking-tokens.md +++ b/versioned_docs/version-v0.77/tutorials/assets-tokens/staking-tokens.md @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem'; :::tip -This tutorial describes how to stake using the smart contracts, the APIs, an Ethereum wallet, and a Vega Wallet. If you're looking for the easiest way to stake tokens, visit [governance.fairground.wtf ↗](https://governance.fairground.wtf/token) +This tutorial describes how to stake using the smart contracts, the APIs, an Ethereum wallet, and a Vega Wallet. If you're looking for the easiest way to stake tokens, visit [governance.vega.xyz ↗](https://governance.vega.xyz/token) ::: * Tokenholders can stake tokens to [validators on the Vega chain](../../concepts/vega-chain#delegated-proof-of-stake), also known as nominating validators. diff --git a/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-assets.md b/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-assets.md index a4e1eae3e..0d8902470 100644 --- a/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-assets.md +++ b/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-assets.md @@ -33,7 +33,7 @@ Assets received as rewards may be locked for a time. Each epoch, a percentage of 1. You can check the status of all your assets using the [Explorer dApp](https://explorer.vega.xyz) by providing your public key. -2. Any assets that are listed on Explorer as in the "Vested account" need to be redeemed. Assets that are locked or vesting can't be moved *yet*. To redeem your vested rewards, go to the rewards page on [Console](https://console.fairground.wtf/#/rewards). From there you can transfer those tokens from your vested account into your general account by clicking on "redeem rewards". +2. Any assets that are listed on Explorer as in the "Vested account" need to be redeemed. Assets that are locked or vesting can't be moved *yet*. To redeem your vested rewards, go to the rewards page on [Console](https://console.vega.xyz/#/rewards). From there you can transfer those tokens from your vested account into your general account by clicking on "redeem rewards". a. From the Governance dApp, you can click on Redeem on the wallet sidebar. This will take you to Console where you can transfer those assets to your Vega general account. diff --git a/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-vega-tokens.md b/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-vega-tokens.md index 7352d2c1f..aa81df9cb 100644 --- a/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-vega-tokens.md +++ b/versioned_docs/version-v0.77/tutorials/assets-tokens/withdrawing-vega-tokens.md @@ -16,7 +16,7 @@ If your tokens are in the *vesting contract*, they will need to be unlocked befo If you received them as *trading rewards*, each epoch, a percentage of locked tokens begin vesting. Once they're vested, they are moved into a vested account. From there, you can redeem vested tokens by transferring them into your general account, at which point they can be withdrawn. -1. Search for your Ethereum address into the redeem page on the [governance dApp](https://governance.fairground.wtf/token/redeem). +1. Search for your Ethereum address into the redeem page on the [governance dApp](https://governance.vega.xyz/token/redeem). 2. If you are connected to your Ethereum and Vega wallets, you can also see a breakdown of your tokens and their status in the wallet sidebar. @@ -27,10 +27,10 @@ For tokens that are already in your Ethereum wallet, and not locked, vesting or ### Remove staked VEGA If your tokens are associated to a Vega key and staked to a validator: -1. To remove your tokens immediately, use the governance dApp to [disassociate](https://governance.fairground.wtf/token/disassociate) the tokens from your Vega key. This will also remove any validator nominations you have. You'll lose any accrued staking rewards for the current epoch. +1. To remove your tokens immediately, use the governance dApp to [disassociate](https://governance.vega.xyz/token/disassociate) the tokens from your Vega key. This will also remove any validator nominations you have. You'll lose any accrued staking rewards for the current epoch. 2. To receive the current epoch's staking rewards, use the governance dApp. - a. Visit the [validators](https://governance.fairground.wtf/validators) page. + a. Visit the [validators](https://governance.vega.xyz/validators) page. b. Click on "Staked by me". @@ -41,26 +41,26 @@ If your tokens are associated to a Vega key and staked to a validator: ### Remove unstaked VEGA Tokens that are not held in a tranche and are associated to a Vega key, but not used for staking validators are easy to remove from the Vega network. -All you need to do is [disassociate](https://governance.fairground.wtf/token/disassociate) the tokens from your Vega key. +All you need to do is [disassociate](https://governance.vega.xyz/token/disassociate) the tokens from your Vega key. ## Withdraw VEGA from the vesting contract For VEGA tokens that are in the vesting contract and are now unlocked, you will need to disassociate and then redeem them. This moves the VEGA directly to your Ethereum address. -1. [Disassociate](https://governance.fairground.wtf/token/disassociate) your vested tokens. If you have nominated validators, disassociating without removing your nomination means you'll lose any staking rewards for that epoch. You can choose to un-nominate at the end of the epoch if you'd rather not lose rewards. +1. [Disassociate](https://governance.vega.xyz/token/disassociate) your vested tokens. If you have nominated validators, disassociating without removing your nomination means you'll lose any staking rewards for that epoch. You can choose to un-nominate at the end of the epoch if you'd rather not lose rewards. -2. Redeem your tokens to move them to your Ethereum address. Visit the Redeem page on the [Governance dApp](https://governance.fairground.wtf/token/redeem), enter the Ethereum address you used for those VEGA tokens, and follow the instructions. +2. Redeem your tokens to move them to your Ethereum address. Visit the Redeem page on the [Governance dApp](https://governance.vega.xyz/token/redeem), enter the Ethereum address you used for those VEGA tokens, and follow the instructions. ## Withdraw VEGA received as rewards Rewards also go through a vesting process, which is different from tokens in the vesting contract. Those tokens are held in accounts on Vega until they become vested. At that point, they can be moved into your general account on Vega, after which they can be withdrawn from the Vega network to the Ethereum network. -1. If you have associated your tokens to your Vega key for staking purposes, [disassociate](https://governance.fairground.wtf/token/disassociate) them. Disassociating without removing your validator nominations means you'll lose any staking rewards for that epoch. You can choose to un-nominate at the end of the epoch if you'd rather not lose rewards. +1. If you have associated your tokens to your Vega key for staking purposes, [disassociate](https://governance.vega.xyz/token/disassociate) them. Disassociating without removing your validator nominations means you'll lose any staking rewards for that epoch. You can choose to un-nominate at the end of the epoch if you'd rather not lose rewards. 2. Redeem your tokens to move them to your general account on Vega. You can redeem using either the Governance dApp or Console. - a. On the [Governance dApp](https://governance.fairground.wtf), you can click on Redeem on the wallet sidebar, which will take you to Console where you can transfer those tokens to your general account. + a. On the [Governance dApp](https://governance.vega.xyz), you can click on Redeem on the wallet sidebar, which will take you to Console where you can transfer those tokens to your general account. - b. On [Console](https://console.fairground.wtf/#/rewards) under Rewards, you can see any tokens or assets that are available to redeem. From there you can transfer those tokens from your vested account into your general account. + b. On [Console](https://console.vega.xyz/#/rewards) under Rewards, you can see any tokens or assets that are available to redeem. From there you can transfer those tokens from your vested account into your general account. 3. Withdraw tokens from Vega to your Ethereum wallet. In Console, you can use the Withdraw icon in the right sidebar to initiate your withdrawal into your Ethereum address. To use Etherscan, follow the [withdrawing assets tutorial](./withdrawing-assets.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tutorials/programmatic-trading-basics.md b/versioned_docs/version-v0.77/tutorials/programmatic-trading-basics.md index 4196191f7..dd832f3a0 100644 --- a/versioned_docs/version-v0.77/tutorials/programmatic-trading-basics.md +++ b/versioned_docs/version-v0.77/tutorials/programmatic-trading-basics.md @@ -5,7 +5,11 @@ hide_title: false description: Start bot development for submitting orders with this guide. --- -In this tutorial you'll learn the basics about how to use Vega and the Vega Wallet to submit orders using the APIs, so you can build bots or other software to interact with the network. +In this tutorial you'll learn the basics about how to use Vega and the Vega Wallet to submit orders using the APIs, so you can build bots or other software to interact with the network. + +:::note Network for tutorial +This guide suggests using Fairground, the Vega testnet, as well as Sepolia (test Ethereum) for testing purposes. +::: This guide covers how to: diff --git a/versioned_docs/version-v0.77/tutorials/proposals/asset-transfer-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/asset-transfer-proposal.md index 6705d0bc5..fc7fb5fef 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/asset-transfer-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/asset-transfer-proposal.md @@ -27,7 +27,7 @@ You will need: * A minimum of whichever is larger, associated with that public key: () or () * Familiarity with how [proposing an asset transfer](../../concepts/governance/asset.md#propose-an-asset-transfer) works - +You should also share your proposal idea in the [_Governance_ forum section ↗](https://community.vega.xyz/c/governance) before submitting it to the network. ## Anatomy of an asset transfer proposal Read on for the key inputs to a governance-initiated parameter proposal. @@ -114,7 +114,7 @@ You will need to define the dispatch strategy, which includes the metric, the le These templates show an example of how to fund rewards with a governance transfer. **To propose a different reward with a governance-initiated transfer, use the fields and information above to expand the proposal.** -* JSON example that can be submitted with the [governance dApp ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems @@ -257,7 +257,7 @@ vegawallet.exe transaction send --wallet YOUR_WALLETNAME --pubkey YOUR_PUBLIC_KE These templates show an example transfer from an asset's insurance pool to the insurance pool of a specific market, both of which need to use the same asset as specified in your transfer. -* JSON example that can be submitted with the [governance dApp ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems @@ -364,9 +364,7 @@ vegawallet.exe transaction send --wallet YOUR_WALLETNAME --pubkey YOUR_PUBLIC_KE ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of , or associated with their Vega key. @@ -375,4 +373,4 @@ Your proposal will need [participation](../../concepts/governance/lifecycle.md#h 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. +If successful, the proposal will be enacted at the time you specify in the `enactmentTimestamp` field. \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tutorials/proposals/freeform-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/freeform-proposal.md index f9fd5b82e..638873706 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/freeform-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/freeform-proposal.md @@ -34,10 +34,10 @@ You will need: * A minimum of whichever is larger, associated with that public key: () or () * Familiarity with [governance on Vega](../../concepts/governance/index.md) - +You should also share your proposal idea in the [_Freeform Proposals_ forum section ↗](https://community.vega.xyz/c/governance/free-form-proposals/31) before submitting it to the network. ## Submitting proposals in a batch + ## Templates and submitting @@ -45,7 +45,7 @@ You will need: 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details.** @@ -71,12 +71,10 @@ In the tabs below you'll see: ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or , associated to their Vega key. Your proposal will need [participation](../../concepts/governance/lifecycle.md#how-a-proposals-outcome-is-calculated) of and a voting majority of , 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. +Proposers who invite feedback, engage with comments, and make revisions to meet the needs of the community are more likely to be successful. \ No newline at end of file diff --git a/versioned_docs/version-v0.77/tutorials/proposals/market-state-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/market-state-proposal.md index 56320385d..addb188b2 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/market-state-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/market-state-proposal.md @@ -56,7 +56,7 @@ The proposal to suspend an open market requires: 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -183,7 +183,7 @@ The proposal to resume an open market requires the `marketID` for the one to sus 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -308,7 +308,7 @@ It also requires a final settlement price, with enough digits to account for the 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -430,9 +430,7 @@ vegawallet.exe transaction send --wallet "wallet-name" --pubkey "pubkey" --netwo ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated to their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/network-parameter-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/network-parameter-proposal.md index cad72b008..0666cfa77 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/network-parameter-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/network-parameter-proposal.md @@ -25,7 +25,7 @@ Network parameters are a constant (or an array of constants) in the system, the 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 ↗](https://community.vega.xyz/c/governance) before submitting it to the network. ## Requirements @@ -74,10 +74,10 @@ For example, a proposal to change the `rewards.activityStreak.benefitTiers` netw 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems -The governance dApp has a [tool ↗](https://governance.fairground.wtf/proposals/propose/network-parameter) to help you build a network parameter proposal. +The governance dApp has a [tool ↗](https://governance.vega.xyz/proposals/propose/network-parameter) to help you build a network parameter proposal. **Replace the example data with the relevant details before submitting.** @@ -102,9 +102,7 @@ The governance dApp has a [tool ↗](https://governance.fairground.wtf/proposals ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of , or associated with their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/new-asset-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/new-asset-proposal.md index 174375f4e..d6094d4c1 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/new-asset-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/new-asset-proposal.md @@ -123,7 +123,7 @@ If you want to submit this proposal as part of a larger batch of proposals, foll 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -149,9 +149,7 @@ In the tabs below you'll see: ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated with their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/new-market-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/new-market-proposal.md index 791d17101..1d19c2eb7 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/new-market-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/new-market-proposal.md @@ -40,7 +40,7 @@ You will need: * A connected [Vega wallet](../../tools/vega-wallet/index.md), with your wallet name and public key to hand * Enough VEGA associated with your public key. Have at least whichever is larger: , () or () - +You should also share your proposal idea in the [_Governance_ forum section ↗](https://community.vega.xyz/c/governance) before submitting it to the network. ## Anatomy of a market proposal In this section, the [full proposal template](#templates-and-submitting) has been divided into sections to provide more details on what you need to submit. @@ -230,6 +230,14 @@ Using the fields below, you can create a prediction market, or set a maximum set | `maxPrice` | Sets the highest possible settlement price. Use market decimal places to set this value. For example, 2 market decimals with a price cap of 3 would be 300. Must be greater than 0, if used. | 10000 | | `fullyCollateralised` | If set to true, the market will require participants' positions to be fully collateralised, and thus no market participants can be liquidated. | true or false | +### Submitting a verified settlement price +If you want the community to vote on the verified price used to settle the market: +* Supply your own Vega public key as the oracle signer under `pubkeys` +* Set the `conditions` to `OPERATOR_GREATER_THAN` 0 **and** `OPERATOR_LESS_THAN` 0 so no price will be accepted +After the market has terminated, update the price by: +1. Submitting an [update market proposal](./update-market-proposal.md#submitting-a-verified-settlement-price) with the verified price +2. Sending the [settlement transaction](../using-data-sources.md#1-define-your-json-structure). + ## Submitting proposals in a batch @@ -238,7 +246,7 @@ Using the fields below, you can create a prediction market, or set a maximum set 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * 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.** @@ -264,11 +272,9 @@ In the tabs below you'll see: ## Voting All proposals are voted on by the community. - -A vote can be submitted with a [transaction](../../api/grpc/vega/commands/v1/commands.proto.mdx#votesubmission) on the command line, or by using the [governance dApp](https://governance.fairground.wtf/proposals). +A vote can be submitted with a [transaction](../../api/grpc/vega/commands/v1/commands.proto.mdx#votesubmission) on the command line, or by using the [governance dApp](https://governance.vega.xyz/proposals). To vote, community members need, at a minimum, the larger of , or associated with their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/new-perpetuals-market.md b/versioned_docs/version-v0.77/tutorials/proposals/new-perpetuals-market.md index 5bf4718a6..46e54340a 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/new-perpetuals-market.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/new-perpetuals-market.md @@ -34,7 +34,7 @@ You will need: * Familiarity with [governance](../../concepts/governance/market.md) on Vega * Familiarity with using [Ethereum to provide data](../using-data-sources.md#ethereum-oracles) - +You should also share your proposal idea in the [_Governance_ forum section ↗](https://community.vega.xyz/c/governance) before submitting it to the network. ## Anatomy of a proposal @@ -244,7 +244,7 @@ Set up the liquidation strategy to minimise the impact of distressed traders on 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -270,7 +270,7 @@ In the tabs below you'll see: ## Voting All proposals are voted on by the community. - +Building support is down to you. Share your proposal in the [_Governance_ section ↗](https://community.vega.xyz/c/governance) on the Vega community forum. You may also wish to share on [Discord ↗](https://vega.xyz/discord). To vote, community members need, at a minimum, the larger of or associated to their Vega key. Proposers who invite feedback, engage with comments, and make revisions to meet the needs of the community are more likely to be successful. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/new-spot-market.md b/versioned_docs/version-v0.77/tutorials/proposals/new-spot-market.md index e6d28f0ea..ebfe7ad17 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/new-spot-market.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/new-spot-market.md @@ -127,7 +127,7 @@ The risk model uses the following properties: 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * 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.** @@ -386,11 +386,9 @@ vegawallet.exe transaction send --wallet YOUR_WALLETNAME --pubkey YOUR_PUBLIC_KE ## Voting All proposals are voted on by the community. - -A vote can be submitted with a [transaction](../../api/grpc/vega/commands/v1/commands.proto.mdx#votesubmission) on the command line, or by using the [governance dApp](https://governance.fairground.wtf/proposals). +A vote can be submitted with a [transaction](../../api/grpc/vega/commands/v1/commands.proto.mdx#votesubmission) on the command line, or by using the [governance dApp](https://governance.vega.xyz/proposals). To vote, community members need, at a minimum, the larger of , or associated with their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/new-successor-market-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/new-successor-market-proposal.md index 11c1685eb..5e6812737 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/new-successor-market-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/new-successor-market-proposal.md @@ -54,7 +54,7 @@ The following `successor` parameters need to be used if you are proposing a mark 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -80,9 +80,7 @@ In the tabs below you'll see: ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated to their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/referral-program-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/referral-program-proposal.md index 5aa11981a..230e1c62a 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/referral-program-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/referral-program-proposal.md @@ -65,7 +65,7 @@ To end an existing program early, set your proposal up with the exact same param ## Templates and submitting Below you will find: -* JSON example that can be submitted with the [governance dApp ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems @@ -223,11 +223,9 @@ vegawallet.exe transaction send --wallet YOUR_WALLETNAME --pubkey YOUR_PUBLIC_KE ## Voting -All proposals are voted on by the community. +All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated to their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/update-asset-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/update-asset-proposal.md index ce77e280f..a8e46a7ff 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/update-asset-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/update-asset-proposal.md @@ -61,7 +61,7 @@ In addition to the parameters you want to change, you must include the existing 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -88,9 +88,7 @@ In the tabs below you'll see: All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated with their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/update-market-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/update-market-proposal.md index b51d84423..477cf6a31 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/update-market-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/update-market-proposal.md @@ -56,6 +56,15 @@ Note that some network parameters may differ, such as the limits on how long the | `closingTimestamp` | Timestamp (Unix time in seconds) when voting closes for this proposal. The chosen time must be between and after the proposal submission time. (int64 as string) | | `enactmentTimestamp ` | Timestamp (Unix time in seconds) when proposal gets enacted (if passed). The chosen time must be between and after `closingTimestamp`. (int64 as string) | +## Submitting a verified settlement price +If a market proposal was submitted to accept a [community-verified price](new-market-proposal.md#submitting-a-verified-settlement-price), once that market has reached its termination time, you can submit an update to the market using the verified price. + +Under `dataSourceSpecForSettlementData`: +* Set the `conditions` to `OPERATOR_EQUALS`, and set the verified price under `value` with the correct decimal precision based on the data source's decimal precision, which should also match `numberDecimalPlaces` +* Set the `time` to be the same as this proposal's `enactmentTimestamp` + +Once the proposal passes the governance vote, the nominated Vega key (`dataSourceSpecForSettlementData` -> `signers` -> `pubkey`) will need to [submit the price to the network](../using-data-sources.md#submitting-JSON-data). + ## Submitting proposals in a batch @@ -64,7 +73,7 @@ Note that some network parameters may differ, such as the limits on how long the 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -90,9 +99,7 @@ In the tabs below you'll see: ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated to their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/update-spot-market.md b/versioned_docs/version-v0.77/tutorials/proposals/update-spot-market.md index c3acbce1e..e8cf49e99 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/update-spot-market.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/update-spot-market.md @@ -59,7 +59,7 @@ Note that some network parameters may differ, such as the limits on how long the 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 ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems **Replace the example data with the relevant details before submitting.** @@ -299,9 +299,7 @@ vegawallet.exe transaction send --wallet YOUR_WALLETNAME --pubkey YOUR_PUBLIC_KE ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated to their Vega key. diff --git a/versioned_docs/version-v0.77/tutorials/proposals/volume-discount-program-proposal.md b/versioned_docs/version-v0.77/tutorials/proposals/volume-discount-program-proposal.md index c45dd9119..91e4e2f98 100644 --- a/versioned_docs/version-v0.77/tutorials/proposals/volume-discount-program-proposal.md +++ b/versioned_docs/version-v0.77/tutorials/proposals/volume-discount-program-proposal.md @@ -54,7 +54,7 @@ To end an existing program early, set your proposal up with the exact same param ## Templates and submitting Below you will find: -* JSON example that can be submitted with the [governance dApp ↗](https://governance.fairground.wtf/proposals/propose/raw) +* JSON example that can be submitted with the [governance dApp ↗](https://governance.vega.xyz/proposals/propose/raw) * Command line examples for different operating systems @@ -172,9 +172,7 @@ vegawallet.exe transaction send --wallet YOUR_WALLETNAME --pubkey YOUR_PUBLIC_KE ## Voting All proposals are voted on by the community. - To vote, community members need, at a minimum, the larger of or associated to their Vega key.