From 0069f838c72b32dcdf0bb85f5dd341408bbcd5bf Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 17 Jan 2023 16:18:15 +0100 Subject: [PATCH 001/649] refactor: let max oi drop during auciton --- protocol/0041-TSTK-target_stake.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index f767ffa25..a7d77df0c 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -21,6 +21,8 @@ The parameter c_1 is a market parameter (with network parameter `market.liquidit First, `max_oi` is defined maximum (open interest) measured over a time window, `t_window = [max(t-market.stake.target.timeWindow,t0),t]`. Here `t` is current time with `t0` being the end of market opening auction. Note that `max_oi` should be calculated recorded per transaction, so if there are multiple OI changes withing the same block (which implies the same timestamp), we should pick the max one, NOT the last one that was processed. +If the market is in auction mode the `max_oi` can only increase while `auction duration` <= `market.stake.target.timeWindow`. Once the market's been in the auction for more than `market.stake.target.timeWindow` the `max_oi` is whatever the current positions and `indicative_uncrossing_volume` imply - specifically, this allows the `target_stake` to drop as a result of trades generated in the auction so that `target_stake` > `supplied_stake` (even in absence of changes to `supplied_stake`) and the market can go back to its default trading mode. + Example 1: `t_market.stake.target.timeWindow = 1 hour` the market opened at `t_0 = 1:55`. From 0d9df2c26fe60bfceea7a6c3c9e16d699aef6b6d Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 19 Jan 2023 12:44:50 +0000 Subject: [PATCH 002/649] fix: duplicate AC codes in 0069-VCBS (#1536) (#1537) --- protocol/0069-VCBS-validators_chosen_by_stake.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 5b9c41ccc..de2847c52 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -511,13 +511,13 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). 1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002) 1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003) 1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004) -1. Can update multisig for new validator, and expect rewards (0069-VCBS-050) +1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-051) +1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. From 4786b0f74b96f677d50219df80c95a4209a0109d Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 25 Jan 2023 13:59:53 +0000 Subject: [PATCH 003/649] Update `cosmicelevator` branch from `master` branch (#1550) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> --- .../0011-NP-CLIE-client-interaction-tests.md | 4 +- protocol/0018-RSKM-quant_risk_models.ipynb | 16 ++-- protocol/0035-LIQM-liquidity_monitoring.md | 22 +++--- protocol/0062-SPAM-spam_protection.md | 79 +++++++++---------- .../0063-VALK-validator_vega_master_keys.md | 2 +- .../0069-VCBS-validators_chosen_by_stake.md | 1 + 6 files changed, 60 insertions(+), 64 deletions(-) diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index 488e3834c..b83585410 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -13,8 +13,8 @@ This specification contains a set of tests/acceptance criteria that clients (wal 3. The parameter `spam.pow.difficulty` is increased. Verify that: - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-003) 4. The parameter `spam.pow.difficulty` is decreased. Verify that - - This is communicated to the wallet, and the wallet use these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) + - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) 5. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-005) -6. The parameter `spam.pow.increaseDifficulty` is changed from `1` to `0`. Verify that +6. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) diff --git a/protocol/0018-RSKM-quant_risk_models.ipynb b/protocol/0018-RSKM-quant_risk_models.ipynb index faf8bef4a..8f60842e0 100644 --- a/protocol/0018-RSKM-quant_risk_models.ipynb +++ b/protocol/0018-RSKM-quant_risk_models.ipynb @@ -108,15 +108,13 @@ "source": [ "## Acceptance Criteria\n", "\n", - "1. [ ] Different markets can have a different risk model (i.e. a market A can be specified to run with risk model R1 while market B can be specified to run with risk model R2). (0018-RSKM-001)\n", - "1. [ ] The risk factors are recalculated only when the inputs have changed since the last call. (0018-RSKM-002)\n", - "1. [ ] If any of the input data has changed then an update to risk factors is initiated. (0018-RSKM-003)\n", - "1. [ ] Risk factors are agreed upon by consensus. (0018-RSKM-004)\n", - "1. [ ] If the risk factor calculation reports \"guaranteed accuracy\" then the risk factors are appropriately rounded. (0018-RSKM-005)\n", - "1. [ ] If an async update to risk factors is already running, don't start a new one until the previous one has finished. (0018-RSKM-006)\n", - "1. [ ] Quant risk suite can compute max move up/down ($\\Delta^-$ and $\\Delta^+$) given current price level and a projection horizon such that the resulting prices are within a specified probability level. (0018-RSKM-007)\n", - "1. [ ] Quant risk suite can compute probability of trading at a given level. (0018-RSKM-008)\n", - "1. [ ] Lognormal risk model has defined ranges of valid parameters and market proposals and market update proposals are checked against these. The ranges can be found in core (https://github.com/vegaprotocol/vega/blob/develop/commands/proposal_submission.go#L820). (0018-RSKM-009)" + "1. Different markets can have a different risk model (i.e. a market A can be specified to run with risk model R1 while market B can be specified to run with risk model R2). (0018-RSKM-001)\n", + "1. If any of the input data has changed then an update to risk factors is initiated. (0018-RSKM-003)\n", + "1. Risk factors are agreed upon by consensus. (0018-RSKM-004)\n", + "1. If the risk factor calculation reports \"guaranteed accuracy\" then the risk factors are appropriately rounded. (0018-RSKM-005)\n", + "1. Quant risk suite can compute max move up/down ($\\Delta^-$ and $\\Delta^+$) given current price level and a projection horizon such that the resulting prices are within a specified probability level. (0018-RSKM-007)\n", + "1. Quant risk suite can compute probability of trading at a given level. (0018-RSKM-008)\n", + "1. Lognormal risk model has defined ranges of valid parameters and market proposals and market update proposals are checked against these. The ranges can be found in core (https://github.com/vegaprotocol/vega/blob/develop/commands/proposal_submission.go#L820). (0018-RSKM-009)" ] }, { diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 4d3008e6a..8a7d58986 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -16,9 +16,9 @@ Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate s (*) Having `best_bid` and `best_offer` implies that `mid` also exists. If, in the future, [LP batch orders](./0038-OLIQ-liquidity_provision_order_type.md) are updated to allow other pegs then the protocol must enforce that they are also on the book. -## Liquidity auction network parameters +## Liquidity auction parameters -**c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it's name is `market.liquidity.targetstake.triggering.ratio` and it's a market parameter (with a network parameter providing a default value for markets that don't specify it). +**c1** - constant multiple for [target stake](./0041-TSTK-target_stake.md) triggering the commencement of liquidity auction. In this spec it is referred to as `c_1` but in fact it `triggering_ratio` in `LiquidityMonitoringParameters` in market creation or update proposal. ## Total stake @@ -75,12 +75,12 @@ As mentioned, as a consequence, intrablock, we may end with one side of the book ## Acceptance Criteria 1. The scenarios in the feature test [0026-AUCT-auction_interaction.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0026-AUCT-auction_interaction.feature) are verified and pass. (0035-LIQM-001) -2. An incoming order that would consume `best_bid` or `best_offer` gets executed (unless it will also trigger price monitoring auction at the same time), the trades are generated. The volume implied by LP provision is removed (from both sides of the book and for all LPs). If `best_bid` is missing but `best_ask` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_ask` as peg are still deployed. If `best_ask` is missing but `best_bid` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_bid` as peg are still deployed. The market goes into a liquidity auction at the end of a block (because there is a peg missing and the liquidity provision volume is not deployed). (0035-LIQM-002) -3. A market which enters a state requiring liquidity auction at the end of a block through increased open interest remains in open trading between entering that state and the end of the block. (0035-LIQM-003) -4. A market which enters a state requiring liquidity auction at the end of a block through decreased total stake (e.g. through LP bankruptcy) remains in open trading between entering that state and the end of the block. (0035-LIQM-004) -5. A market which enters a state requiring liquidity auction through increased open interest during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-005) -6. A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) -7. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) -8. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) -9. When the network parameter `market.liquidity.targetstake.triggering.ratio` is updated via governance, future new market and update market proposals which do not specify a `triggeringRatio` should copy the new network parameter as the market parameter value. (0035-LIQM-009) -10. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) +1. An incoming order that would consume `best_bid` or `best_offer` gets executed (unless it will also trigger price monitoring auction at the same time), the trades are generated. The volume implied by LP provision is removed (from both sides of the book and for all LPs). If `best_bid` is missing but `best_ask` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_ask` as peg are still deployed. If `best_ask` is missing but `best_bid` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_bid` as peg are still deployed. The market goes into a liquidity auction at the end of a block (because there is a peg missing and the liquidity provision volume is not deployed). (0035-LIQM-002) +1. A market which enters a state requiring liquidity auction at the end of a block through increased open interest remains in open trading between entering that state and the end of the block. (0035-LIQM-003) +1. A market which enters a state requiring liquidity auction at the end of a block through decreased total stake (e.g. through LP bankruptcy) remains in open trading between entering that state and the end of the block. (0035-LIQM-004) +1. A market which enters a state requiring liquidity auction through increased open interest during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-005) +1. A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) +1. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) +1. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) +1. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) +1. When proposing a new market if the triggering_ratio is not supplied then the current value of `market.liquidity.targetstake.triggering.ratio` is used in its place. (0035-LIQM-011) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index b657774ab..ff2aafbca 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -1,82 +1,79 @@ # Spam protection -At this point, we cannot reject a transaction based on any data that is not the shared state -of the blockchain. This means, it is unavoidable that one spammer can essentially fill a block. +At this point, the network cannot reject a transaction based on any data that is not the shared state of the blockchain. This means, it is unavoidable that one spammer can essentially fill a block. -What we can do is: +What the network can do is: - remove the offending transactions after the block is scheduled, i.e., not process them - update the state once a block is finalised and block transactions based on the new state - delete transactions from every (honest) validators mempool based on the new state. -Thus, no matter what the anti-spam policy is, there is a scenario where someone creates -a lot of identities and spams one block with each. Therefore, we have to enforce a minimum -investment to be allowed to send anything to the Vega network. +Thus, no matter what the anti-spam policy is, there is a scenario where someone creates a lot of identities and spams one block with each. Therefore, we have to enforce a minimum investment to be allowed to send anything to the Vega network. -For governance votes, that means that there is a minimum amount of tokens required to be allowed -to issue a proposal/vote (`spam.protection.proposal.min.tokens`/`spam.protection.voting.min.tokens`). If the network detects successful spam in spite of this minimum, then the limit can be increased automatically. +## Governance spam -For SW, we only have governance, so the following two policies will do: +The spam protection enforcement for governance actions require that a public key must have a set minimum amount of tokens to be allowed to issue a proposal or vote on a proposal (`spam.protection.proposal.min.tokens`/`spam.protection.voting.min.tokens`). If the network detects successful spam in spite of this minimum, then the limit can be increased automatically. -Vote transactions can be rejected if a if a party has less than `spam.protection.voting.min.tokens`. Any governance proposal transaction can be rejected if a party has less than `spam.protection.proposal.min.tokens`. Setting these reasonably high provides some level of protection. -Any qualified voter can vote `spam.protection.max.votes` times per epoch per active proposal (e.g., if it's `3` then one initial vote and twice change their mind). +The following three policies are also specific to governance actions: -If 3 blocks in a row for filled with spam i.e., parties sending substantially more than 3 votes, let's say 50 votes), -then the number of required tokens is doubled, up to a maximum of 1600 (if someone pays 1.5 million to spam us for 60 -seconds so be it). +- Vote transactions can be rejected if a party has less than `spam.protection.voting.min.tokens`. +- Any governance proposal transaction can be rejected if a party has less than `spam.protection.proposal.min.tokens`. Setting these reasonably high provides some level of protection. +- Any qualified voter can vote `spam.protection.max.votes` times per epoch per active proposal (e.g., if it's `3` then one initial vote and 2 follow-on votes to change their mind. -All parameters are up to discussion/governance vote. A change of parameters is taking effect in the epoch following the acceptance of the -corresponding proposals. +If 3 blocks in a row are filled with spam, i.e., parties send substantially more than 3 votes, let's say 50 votes), then the number of required tokens is doubled, up to a maximum of 1600. -## More detailed description +All are network parameters and thus up for discussion/governance vote. A change of parameters takes effect in the epoch following the acceptance of the corresponding proposal. ### Policy Enforcement -The policy enforcement mechanism rejects messages that do not follow the anti-spam rules. This can happen in two different ways: +The policy enforcement mechanism rejects governance messages that do not follow the anti-spam rules. This can happen in two different ways: -- pre-block reject: A transaction is rejected before it enters the validators mempool. For Tendermint-internal reasons, this can only happen based on the global state coordinated through the previous block; especially, it cannot be based on any other transactions received by the validator but not yet put into a block (e.g., only three transactions per party per block). Once a block is scheduled, all validators also test all transactions in their mempool if they are still passing the test, and remove them otherwise. -- post-block-reject: A transaction has made it into the block, but is rejected before it is passed to the application layer. This mechanism allows for more fine-grained policies than the previous one, but at the price that the offending transaction has already taken up space in the blockchain. +- pre-block rejection: A transaction is rejected before it enters the validators' mempool. For Tendermint-internal reasons, this can only happen based on the global state coordinated through the previous block; in particular, it cannot be based on any other transactions received by the validator but not yet put into a block (e.g., only three transactions per party per block). Once a block is scheduled, all validators also test all transactions in their mempool to confirm they are still passing the test, and remove them otherwise. +- post-block-rejection: A transaction has made it into the block, but is rejected before it is passed to the application layer. This mechanism allows for more fine-grained policies than the previous one, but at the price that the offending transaction has already taken up space in the blockchain. -For Sweetwater, the policies we enforce are relatively simple: +The policies enforced are relatively simple: -```math - = 3 - = 1 - = 3 - = 200000 +```text +num_votes = 3 +min_voting_tokens = 1 +num_proposals = 3 +min_proposing_tokens = 200000 ``` -- Any tokenholder with more than `` tokens has `` voting attempts per epoch and proposal, i.e., they can change their mind `-1` times in one epoch. This means, a transaction is pre_block rejected, if there are `` or more votes on the same proposal in the blockchain in this epoch, and post_block rejected, if there are `` or more on the same proposal in the blockchain plus earlier in the current block. -- Any tokenholder that had more than 50% if its post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all its governance related transactions ( but no no trading related transactions) are immediately rejected. E.g. if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so a it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. - -The voting counters are unaffected by the ban, so voting again on an issue that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now likely to not trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. - -- A proposal can only be issued by a tokenholder owning more than `` at the start of the epoch. Also (like above), only `` proposals can be made per tokenholder per epoch, i.e., every proposal past `` in an epoch is rejected by post-block-reject (if there sum of proposals in past blocks and the ones in the current block exceed ``) or pre-block reject (if the sum of proposals already in the blockchain for that epoch equals or exceeds ``. This parameter is the same for all proposals (also market-creation related ones). There also is a separate parameter to the same end that is enforced in the core. For SW, both these parameters have the same value. In the future, we can set the spam protection value lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also be covered by the core then. +- Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. +- Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. +- A proposal can only be issued by a tokenholder with more than `min_proposing_tokens` associated with one public key at the start of the epoch. Also (like above), only `num_proposals` proposals can be made per tokenholder per epoch. For example, every proposal past `num_proposals` in an epoch is rejected by post-block-rejected if the sum of their proposals in past blocks and the ones in the current block exceed `num_proposals`, or pre-block rejected if the sum of proposals already in the blockchain for that epoch equals or exceeds `num_proposals`. This parameter is the same for **all proposals**. There also is a separate parameter to the same end that is enforced in the core. For Sweetwater, both these parameters had the same value, but the spam protection value can be set lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also then be covered by the core. ### Notes - What counts is the number of tokens at the beginning of the epoch. While it is unlikely (given gas prices and ETH speed) that the same token is moved around to different entities, this explicitly doesn't work. -- This means that every tokenholder with more than `` can spam exactly one block on SW. +- Every tokenholder with more than `min_voting_tokens` can spam exactly one block. - There is some likelihood that policies will change. It would thus be good to have a clean separation of policy definition and enforcement, so a change in the policies can be implemented and tested independently of the enforcement code. ### Increasing thresholds -If on average for the last 10 blocks, more than 30% of all voting and proposal transactions need to be post-rejected, then the network is -under Spam attack. In this case, the `` value is doubled, until it reaches 1600. The threshold -is then not increased for another 10 blocks. At the beginning of every epoch, the value of `` is reset to its original. +If on average for the last 10 blocks, more than 30% of all voting and proposal transactions need to be post-rejected, then the network is under spam attack. In this case, the `min_voting_tokens` value is doubled, until it reaches 1600. The threshold is then not increased for another 10 blocks. At the beginning of every epoch, the value of `min_voting_tokens` is reset to its original. + +### Issues -### Issues: It is possible for a tokenholder to deliberately spam the network to block poorer parties from voting +**It is possible for a tokenholder to deliberately spam the network to block poorer parties from voting.** -Due to the banning policy this is not doable from one account, but with a sybil attack it can be done. If this ends up being a problem, we can address it by increasing the ban-time. +Due to the banning policy this is not doable from one key, but with a sybil attack it can be done. If this ends up being a problem, we can address it by increasing the ban-time. -### Withdrawal Spam +## Withdrawal spam As unclaimed withdrawals do not automatically expire, an attacker could generate a large number of messages as well as an ever-growing data structure through [withdrawal requests](0030-ETHM-multisig_control_spec.md). To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWitdrawalQuantumMultiple`. -The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any vega asset that has roughly value of 1 USD. +The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any Vega asset that has a rough value of 1 USD. + Any withdrawal requests for a smaller amounts are immediately rejected. +### Related topics + +- [Spam protection: Proof of work](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) +- [Transaction gas and priority](https://github.com/vegaprotocol/specs/blob/master/protocol/0079-TGAP-transaction_gas_and_priority.md) + ### Acceptance Criteria A spam attack using votes/governance proposals is detected and the votes transactions are rejected, i.e., a party that issues too many votes/governance proposals gets the follow on transactions rejected. This means (given the original parameters parameters from [0054-NETP-network_parameters.md](https://github.com/vegaprotocol/specs-internal/blob/master/protocol/0054-NETP-network_parameters.md)) @@ -92,7 +89,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Transaction creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) - Transaction submitting votes by parties with less than `spam.protection.voting.min.tokens` vega associated are rejected. (0062-SPAM-005) - Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006) -- Above thresholds are exceeded in one block, leading to a post-block-reject (0062-SPAM-007) +- Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007) - If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008) - It is possible for spam transactions to fill a block (0062-SPAM-010) - Parties that continue spamming are blocked and eventually unblocked again (0062-SPAM-011) diff --git a/protocol/0063-VALK-validator_vega_master_keys.md b/protocol/0063-VALK-validator_vega_master_keys.md index 1fc34d3f4..2f753a209 100644 --- a/protocol/0063-VALK-validator_vega_master_keys.md +++ b/protocol/0063-VALK-validator_vega_master_keys.md @@ -46,4 +46,4 @@ The public master key has to be added to validators' identities in the genesis c - If several key change transactions are submitted simultaneously (i.e., a new key change is submitted before the target block of a previous one is reached, if key change message 1 has a lower sequence number and a higher/the same target block as change message 2, then the key established by message 2 is not replaced by the key from message 1. This can be done either by managing the parallel executions appropriately or by rejecting additional submissions(0063-VALK-010) - Once the target block of a key change action us reached, all preceding keys (the original key as well as all hot keys rotated in through a key-change ,messager with a lower sequence number) are invalid. (0063-VALK-011) - Key change message with a lower sequence number than the last one executed are rejected. (0063-VALK-012) -- Once a validator hot key has been rotated, reward balances are carried over to the new key. (0063-VALK-013) +- Once a validator hot key has been rotated, it is possible to withdraw all rewards in the original keys account or submit a transfer to move them to the new key's account i.e the old key is still functional as a non-validator vega key. (0063-VALK-013) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index de2847c52..57cd4692d 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -524,3 +524,4 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) From e84c67471562ec371862650d4e73a59deb60460a Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 30 Jan 2023 15:01:36 +0000 Subject: [PATCH 004/649] Update cosmicelevator branch from master to keep up-to-date (#1560) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> --- .../config/markdownlinkcheckignore.json | 12 ++++++ .github/workflows/config/markdownlint.json | 4 +- makefile | 23 +++++++++-- markdownlint.sh | 9 +++++ protocol/0013-ACCT-accounts.md | 8 ++-- ...5-INSR-market_insurance_pool_collateral.md | 2 +- protocol/0020-APIS-core_api.md | 6 +-- protocol/0026-AUCT-auctions.md | 2 +- protocol/0027-ASSP-asset_proposal.md | 2 +- protocol/0028-GOVE-governance.md | 2 +- protocol/0031-ETHB-ethereum_bridge_spec.md | 2 +- ...038-OLIQ-liquidity_provision_order_type.md | 4 +- protocol/0050-EPOC-epochs.md | 2 +- protocol/0051-PROD-product.md | 2 +- protocol/0056-REWA-rewards_overview.md | 4 +- protocol/0057-TRAN-transfers.md | 16 ++++---- ...0059-STKG-simple_staking_and_delegating.md | 8 ++-- protocol/0060-WEND-wendy.md | 2 +- protocol/0062-SPAM-spam_protection.md | 38 +++++++++++-------- ...ALP-validator_performance_based_rewards.md | 4 +- .../0065-FTCO-floating_point_consensus.md | 2 +- protocol/0068-MATC-matching_engine.md | 16 ++++---- .../0069-VCBS-validators_chosen_by_stake.md | 8 ++-- ...071-STAK-erc20_governance_token_staking.md | 2 +- protocol/0073-LIMN-limited_network_life.md | 4 +- protocol/0075-PLUP-protocol_upgrades.md | 2 +- protocol/0076-DANO-data-node.md | 2 +- protocol/README.md | 3 +- spellcheck.sh | 13 +++++++ spellcheck.yaml | 27 ------------- 30 files changed, 132 insertions(+), 99 deletions(-) create mode 100644 .github/workflows/config/markdownlinkcheckignore.json create mode 100755 markdownlint.sh create mode 100755 spellcheck.sh diff --git a/.github/workflows/config/markdownlinkcheckignore.json b/.github/workflows/config/markdownlinkcheckignore.json new file mode 100644 index 000000000..eff12910e --- /dev/null +++ b/.github/workflows/config/markdownlinkcheckignore.json @@ -0,0 +1,12 @@ +{ + "ignorePatterns": [ + { + "_comment": "Finds /protocol AC codes e.g. #0001-MKTF-001", + "pattern": "^#[0-9]{4}-[A-Z]{4}-[0-9]{3}" + }, + { + "_comment": "Finds /non-protocol-specs AC codes e.g. #0001-NP-LIQB-001", + "pattern": "^#[0-9]{4}-[A-Z]{2}-[A-Z]{4}-[0-9]{3}" + } + ] +} diff --git a/.github/workflows/config/markdownlint.json b/.github/workflows/config/markdownlint.json index 403f776d9..ea3d61a0c 100644 --- a/.github/workflows/config/markdownlint.json +++ b/.github/workflows/config/markdownlint.json @@ -5,5 +5,5 @@ "commands-show-output": false, "no-bare-urls": true, "no-inline-html": false, - "no-hard-tabs": false, -} \ No newline at end of file + "no-hard-tabs": false +} diff --git a/makefile b/makefile index d2e5fe53a..c192ee4bd 100644 --- a/makefile +++ b/makefile @@ -1,18 +1,35 @@ -all: names codes references +# Set default to run all checks if none specified +.DEFAULT_GOAL := all + +all: spellcheck markdownlint names codes links references # Check that all the specifications are named appropriately +.PHONY: names names: npx @vegaprotocol/approbation check-filenames # Count how many Acceptance Criteria each specification has +.PHONY: codes codes: npx @vegaprotocol/approbation check-codes # Which Acceptance Criteria are referenced in which feature files? +.PHONY: references references: npx @vegaprotocol/approbation check-references # Imperfect, but useful - hence not included in ALL +.PHONY: links links: - npx markdown-link-check protocol/*.md - npx markdown-link-check non-protocol-specs/*.md + npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json protocol/*.md + npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json non-protocol-specs/*.md + +# check the markdown formatting (/protocol specs only at this time) +.PHONY: markdownlint +markdownlint: + @./markdownlint.sh + +# check the markdown spelling (/protocol specs only at this time) +.PHONY: spellcheck +spellcheck: + @./spellcheck.sh diff --git a/markdownlint.sh b/markdownlint.sh new file mode 100755 index 000000000..bf1aa2fcd --- /dev/null +++ b/markdownlint.sh @@ -0,0 +1,9 @@ +#!/bin/bash -x + +echo "Installing markdownlint-cli..." + +npm install -g markdownlint-cli --yes + +echo "Running markdownlint-cli..." + +markdownlint --ignore-path .github/workflows/config/markdownlintignore --config .github/workflows/config/markdownlint.json . diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 745d6504a..9d82ff779 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -10,7 +10,7 @@ Any party can submit a withdrawal transaction to withdraw assets from the genera Any party can set up a transfer from their general account to other Vega accounts as described by the [transfer spec](./0057-TRAN-transfers.md). -Note that a party can also associate the governance / staking asset via the [Vega staking bridge contract](../non-protocol-specs/0006-NP-STAK-erc20_governance_token_staking.md) but this number is *not* an account balance because it *cannot* be used as [collateral](./0005-COLL-collateral.md) for trading and it cannot be transferred. +Note that a party can also associate the governance / staking asset via the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) but this number is *not* an account balance because it *cannot* be used as [collateral](./0005-COLL-collateral.md) for trading and it cannot be transferred. ## Accounts controlled by Vega @@ -81,13 +81,13 @@ Every market will have at least one insurance pool account that holds collateral **Creation/Deletion:** -When a [market launches](./0043-MKTL_market_livecycle.md), an insurance pool account is created for that market for each settlement asset. This account is used by the protocol during the collection of [margin requirements](./0010-MARG-margin_orchestration.md) and the collection of [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). +When a [market launches](./0043-MKTL-market_lifecycle.md), an insurance pool account is created for that market for each settlement asset. This account is used by the protocol during the collection of [margin requirements](./0010-MARG-margin_orchestration.md) and the collection of [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). When a market is finalised / closed remaining funds are distributed to the on chain treasury. This occurs using ledger entries to preserve double entry accounting records within the collateral engine. ## Staking accounts -In Vega governance is controlled by a [governance token](./0029-GOVE-governance.md#governance-asset) which is [nominated and staked](./0059-STKG-simple_staking_and_governance.md), and is held in a smart contract on Ethereum. As the assets are held off-chain, a party's staking balance is treated differently to the account types above. +In Vega governance is controlled by a [governance token](./0028-GOVE-governance.md#governance-asset) which is [nominated and staked](./0059-STKG-simple_staking_and_delegating.md), and is held in a smart contract on Ethereum. As the assets are held off-chain, a party's staking balance is treated differently to the account types above. - Like [margin accounts](#margin-accounts), a party cannot transfer or place orders with the balance in staking accounts @@ -129,7 +129,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Special case: Staking accounts -One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](../non-protocol-specs/0006-NP-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. For more information on staking and stake delegation see [Simple staking and delegation](./0050-STKG-simple_staking_and_delegating.md). +One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. For more information on staking and stake delegation see [Simple staking and delegation](./0059-STKG-simple_staking_and_delegating.md). ### Party staking accounts diff --git a/protocol/0015-INSR-market_insurance_pool_collateral.md b/protocol/0015-INSR-market_insurance_pool_collateral.md index 830e6bcf6..0b9bd267e 100644 --- a/protocol/0015-INSR-market_insurance_pool_collateral.md +++ b/protocol/0015-INSR-market_insurance_pool_collateral.md @@ -20,4 +20,4 @@ When a market is finalised / closed remaining funds are distributed equally amon - When a market proposal gets accepted and the opening auction commences, there is an insurance account that is available for use by that market for the settlement asset of that market and its balance is zero. (0015-INSR-001) - When the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) -- The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) +- The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) diff --git a/protocol/0020-APIS-core_api.md b/protocol/0020-APIS-core_api.md index 2748655b3..d129cc0b6 100644 --- a/protocol/0020-APIS-core_api.md +++ b/protocol/0020-APIS-core_api.md @@ -17,9 +17,9 @@ To *observe the operation, and validate the state of the protocol, we must be ab ### Governance - List all [governance proposals](./0028-GOVE-governance.md), regardless of state -- List all proposals, filtered by the [party identitifier](./0016-PART-party.md) of the party that created it. +- List all proposals, filtered by the [party identitifier](./0017-PART-party.md) of the party that created it. - Retrieve a specified proposal -- List all [votes](./0027-GOVE-governance.md#voting-for-a-proposal) +- List all [votes](./0028-GOVE-governance.md#voting-for-a-proposal) - List [governance stake](./0059-STKG-simple_staking_and_delegating.md) for a specific party - List [delegations](./0059-STKG-simple_staking_and_delegating.md) for a specific party @@ -35,7 +35,7 @@ To *observe the operation, and validate the state of the protocol, we must be ab ### Party -- List all known [parties](./0016-PART-party.md). +- List all known [parties](./0017-PART-party.md). ### [Network wide limits](./0078-NWLI-network_wide_limits.md) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index f9238487c..4db5087ed 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -170,7 +170,7 @@ message Market { - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: 1. the enactment time assuming there are orders crossing on the book, [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask so that [liquidity can be deployed](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-009) 1. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed and we have limit orders such that after the auction uncrossing we will have best bid and best ask so that [liquidity can be deployed](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-010) - 1. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md0041). It will only end if + 1. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-011) - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-012) 1. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have diff --git a/protocol/0027-ASSP-asset_proposal.md b/protocol/0027-ASSP-asset_proposal.md index 54e8ae551..4e22102eb 100644 --- a/protocol/0027-ASSP-asset_proposal.md +++ b/protocol/0027-ASSP-asset_proposal.md @@ -190,7 +190,7 @@ This must be an integer strictly greater than `0`. - `validationTimestamp` must occur after the governance proposal opens voting, and before it closes (0027-ASSP-017) - `validationTimestamp` must be provided and in the future for all new ERC20 asset proposals (0027-ASSP-018) - `quantum` must be an integer strictly greater than `0` (0027-ASSP-019) -- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-0027-ASSP-020) +- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-ASSP-020) - There can be multiple concurrent proposals for the same new ERC20 asset (same means identical Ethereum address). Once the nodes agree (based on events from the external blockchain queue), that the asset is enabled on the bridge all the remaining proposals for the same asset are rejected. (0027-COSMICELEVATOR-025) - An invalid contract address, specified in the ERC20 proposal **must** be rejected(0027-ASSP-021) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 269f9c573..c889f8343 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -57,7 +57,7 @@ A party on the Vega network will have a weighting for each type of proposal that To submit a proposal the party has to have more (strictly greater) than a minimum set by a network parameter `governance.proposal.market.minProposerBalance` of the governance tokens associated to the Vega network via the [Ethereum staking bridge](0071-STAK-erc20_governance_token_staking.md) (the network parameter sets the number of tokens). The minimum valid value for this parameter is `0`. -Weighting will initially be determined by the sum of the locked and staked token balances on the [staking bridge](../non-protocol-specs/0004-NP-APIN-api_node.md). +Weighting will initially be determined by the sum of the locked and staked token balances on the [staking bridge](./0076-DANO-data-node.md). In future, governance weighting for some proposal types will be based on alternative measures, such as: diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 1145d9516..7a88be6cf 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -26,7 +26,7 @@ Each bridge contains two primary functions and emits two primary events, each ta ### Block confirmations -It is normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. For example, [this is Kraken's wait time](https://support.kraken.com/hc/en-us/articles/203325283-Cryptocurrency-deposit-processing-times). We need to do the same, to be sure that enough time has passed that it is a certainty that the event we saw is included in the chain. +It is normal behaviour when validating transfers to wait a certain number of blocks for a deposit to be 'confirmed'. We need to do the same, to have acceptably high probability that the event is on the longest chain and there won't be a fork in the future which will invalidate this. We achieve this by ensuring that enough time has passed. This will need to be configured per chain that we connect to. ETH, ERC-20, ERC-XXX can all share a value, which should be configurable and changeable via governance. For Ethereum, this should be 20 confirmations. It is safe to lower this for development networks. diff --git a/protocol/0038-OLIQ-liquidity_provision_order_type.md b/protocol/0038-OLIQ-liquidity_provision_order_type.md index 10cffaf50..f340d1972 100644 --- a/protocol/0038-OLIQ-liquidity_provision_order_type.md +++ b/protocol/0038-OLIQ-liquidity_provision_order_type.md @@ -196,8 +196,8 @@ Note that any other orders that the LP has on the book (limit orders, other pegg ## Acceptance Criteria -- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios there. (0038-OLIQ-001); -- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios that test fractional order sizes (smallest order position of 0.01). (0038-OLIQ-002); +- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios there. (0038-OLIQ-001); +- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios that test fractional order sizes (smallest order position of 0.01). (0038-OLIQ-002); - If an LP order has offset set such that the resulting price falls outside `[min_lp_vol_price, max_lp_vol_price]` then the system adjusts it automatically so that it's placed on the bound (0038-OLIQ-011) ### LP commitment order creation diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index b5767c721..2c439e83a 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -217,4 +217,4 @@ Nomination takes effect at epoch changeover: ## See also -- [0059 - STKG - Simple staking and delegating](./0059-STKG-simple_staking_and_delegating) - staking and delegation are both calculated in terms of epochs. +- [0059 - STKG - Simple staking and delegating](./0059-STKG-simple_staking_and_delegating.md) - staking and delegation are both calculated in terms of epochs. diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index 8908f8fd5..b64a11abb 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -128,5 +128,5 @@ Product updates via governance: ## See also -- [Product: Built In Futures](./016-PFUT-product_builtin_future.md) +- [Product: Built In Futures](./0016-PFUT-product_builtin_future.md) - [Product: Cash settled Perpetual Future](./0053-PERP-product_builtin_perpetual_future.md) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 83eeb87f2..65792570a 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -3,12 +3,12 @@ The reward framework provides a mechanism for measuring and rewarding a number of key activities on the Vega network. These rewards operate in addition to the main protocol economic incentives which come from [fees](0029-FEES-fees.md) on every trade. -These fees are the fundamental income stream for [liquidity providers LPs](0042-LIQF-setting_fees_and_rewarding_lps.md) and [validators](0061-REWP-simple_pos_rewards_sweetwater.md). +These fees are the fundamental income stream for [liquidity providers LPs](0042-LIQF-setting_fees_and_rewarding_lps.md) and [validators](./0061-REWP-pos_rewards.md). The additional rewards described here can be funded arbitrarily by users of the network and may be used by the project team, token holders (via governance), and individual traders and market makers to incentivise mutually beneficial behaviour. Note that transfers via governance, including to fund rewards, is a post-Oregon Trail feature. -Note that validator rewards (and the reward account for those) is covered in [validator rewards](0061-REWP-simple_pos_rewards_sweetwater.md) and is separate from the trading reward framework described here. +Note that validator rewards (and the reward account for those) is covered in [validator rewards](./0061-REWP-pos_rewards.md) and is separate from the trading reward framework described here. ## New network parameter for market creation threshold diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 11a88d6bb..b327a8015 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -6,18 +6,18 @@ These transfers are not to be confused with the internal concept of transfers wh Allowing users to initiate transfers allows for the following capabilities: - A user can transfer funds from a public key A to a public key B. -- A user can transfer funds from and to a locked account used for staking (yet to be specified) [LOCKED_FOR_STAKING](0059-STKG-simple_staking_and_delegating.md). +- A user can transfer funds from and to a locked account used for staking (yet to be specified) [LOCKED_FOR_STAKING](./0059-STKG-simple_staking_and_delegating.md). - A user can set up a recurring transfer. - A user can set up a recurring transfer to one or more [reward accounts](0056-REWA-rewards_overview.md#reward-accounts). ## Limits -Transfer can only be initiated by a party using their own funds from [accounts](./0013-accounts.md) that they are in control of: +Transfer can only be initiated by a party using their own funds from [accounts](./0013-ACCT-accounts.md) that they are in control of: Here's the list of accounts types from which a user send funds from: - [GENERAL](0013-ACCT-accounts.md) -- [LOCKED_FOR_STAKING](./0059-simple-staking-and-delegating.md) (not in Oregon Trail) +- [LOCKED_FOR_STAKING](./0059-STKG-simple_staking_and_delegating.md) (not in Oregon Trail) Here's the list of accounts types into which funds can be sent: @@ -39,7 +39,7 @@ In order to prevent the abuse of user-initiated transfers as spam attack there w ## Minimum transfer amount -This is controlled by the `transfer.minTransferQuantumMultiple` and quantum specified for the [asset](0040-asset-framework.md)). +This is controlled by the `transfer.minTransferQuantumMultiple` and quantum specified for the [asset](0040-ASSF-asset_framework.md)). The minimum transfer amount is `transfer.minTransferQuantumMultiple x quantum`. ## Recurring transfers @@ -61,7 +61,7 @@ Party1 can have a recurring transfer rt1 from A1 to A2 and another one (call it A recurring transfers needs to contain this specific information: -- start amount uint specifying the amount (interpreted according to the number of decimals specified by the [asset](0040-asset-framework.md)). +- start amount uint specifying the amount (interpreted according to the number of decimals specified by the [asset](0040-ASSF-asset_framework.md)). - start epoch: at the end of this epoch the first recurring transfer will be made between - end epoch (optional): at the end of this epoch the last recurring transfer will be made between, optional. If not specified the transfer run until cancelled (by its creator or by the network as described below). - factor, decimal > 0.0 (a factor used with the amount specified for the transfer). @@ -118,11 +118,11 @@ Note: if there is no market with contribution to the reward metric - no transfer ## Fees -A fee is taken from all transfers, and paid out to validators in a similar manner to the existing [infrastructure fees](0059-simple-POS-rewards.md). For recurring transfers, the fee is charged each time the transfer occurs. +A fee is taken from all transfers, and paid out to validators in a similar manner to the existing [infrastructure fees](0061-REWP-pos_rewards.md). For recurring transfers, the fee is charged each time the transfer occurs. -The fee is set by the `transfer.fee.factor` [network parameter](#network-parameter) that defines the proportion of each transfer taken as a fee. +The fee is set by the `transfer.fee.factor` [network parameter](#network-parameters) that defines the proportion of each transfer taken as a fee. The fee is taken from the transfer initiator's account immediately on execution, and is taken on top of the total amount transferred. -It is [paid in to the infrastructure fee pool](./0029-fees.md#collecting-and-distributing-fees). +It is [paid in to the infrastructure fee pool](./0029-FEES-fees.md#collecting-and-distributing-fees). Fees are charged in the asset that is being transferred. ## Proposed command diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index b1e4f50ff..b5a4b4838 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -8,7 +8,7 @@ Validators and delegators receive incentives from the network, depending on vari Staking requires the combined action of: -- Associating tokens on the [Vega staking bridge contract](./0071-NP-STAK-erc20_governance_token_staking.md); and +- Associating tokens on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md); and - Nominating these tokens to one or more validators - Delegation in some contexts is used to mean `associate + nominate`. For the purposes of this document, once it's clear from context that association has happened `delegate` and `nominate` may be used interchangeably. @@ -193,7 +193,7 @@ These accounts will be created: ### Adding more stake -- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-NP-STAK-erc20_governance_token_staking.md) (0059-STKG-008) +- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) (0059-STKG-008) - More stake may be delegated at any time (see [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - amount refers to size by which to increment existing staked amount) (0059-STKG-009) - Same timings apply as per staking for the first time (0059-STKG-010) @@ -211,7 +211,7 @@ These accounts will be created: - Changing the validator to whom a participant wants to validate to involves: - Announcing removal of stake for current validator - - Staking on the new validator, as per normal [function: Stake](../non-protocol-specs/0006-NP-STAK-erc20_governance_token_staking.md) + - Staking on the new validator, as per normal [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - These can happen concurrently, so that at the next epoch, the stake is removed from the current validator and staked on the new validator ## Auto delegation scenarios @@ -255,5 +255,5 @@ These accounts will be created: - [0013-ACCT Acccounts](./0013-ACCT-accounts.md) - staking accounts are not like other account types, but the differences are covered here. - [0028-GOVE Governance](./0028-GOVE-governance.md) - a party's stake controls their ability to participate in governance. -- [0069-VALW Validators chosen by stake](./0069-VALW-validators_chosen_by_stake.md) - staking and delegation is used to pick validators. +- [0069-VALW Validators chosen by stake](./0069-VCBS-validators_chosen_by_stake.md) - staking and delegation is used to pick validators. - [0050-EPOC Epochs](./0050-EPOC-epochs.md) - epochs control how frequently validator sets can change as a result of staking and delegation. diff --git a/protocol/0060-WEND-wendy.md b/protocol/0060-WEND-wendy.md index 0b03d35ab..37c8d89ef 100644 --- a/protocol/0060-WEND-wendy.md +++ b/protocol/0060-WEND-wendy.md @@ -2,7 +2,7 @@ ## Sources -- [Paper](https://github.com/vegaprotocol/research-internal/blob/master/Fairness/SBC22/Wendy2b.pdf) +- [Paper](https://vega.xyz/papers/Wendy_Grows_Up.pdf) - [Code so far](https://github.com/vegaprotocol/wendy) ## Implementation diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index ff2aafbca..dbe9b4bd3 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -6,7 +6,7 @@ What the network can do is: - remove the offending transactions after the block is scheduled, i.e., not process them - update the state once a block is finalised and block transactions based on the new state -- delete transactions from every (honest) validators mempool based on the new state. +- delete transactions from every (honest) validator's mempool based on the new state. Thus, no matter what the anti-spam policy is, there is a scenario where someone creates a lot of identities and spams one block with each. Therefore, we have to enforce a minimum investment to be allowed to send anything to the Vega network. @@ -34,12 +34,20 @@ The policy enforcement mechanism rejects governance messages that do not follow The policies enforced are relatively simple: ```text -num_votes = 3 -min_voting_tokens = 1 -num_proposals = 3 -min_proposing_tokens = 200000 +num_votes = 3 // maximum number of times per epoch a tokenholder van change their vote on an issue +min_voting_tokens = 1 // minimum tokens required to be allowed to vote +num_proposals = 3 // maximum number of governance proposals per tokenholder per epoch +min_proposing_tokens = 200000 // minimum amount of tokens required to make governance proposals +max_delegations = 390 // maximal number of de-delegations per tokenholder per epioch +min_tokens_for_delegation = 1 // minimum number of tokens needed to re-delegate +minimum_withdrawal = 10 // minimum amount of asset withdrawals +min_transfer = 0.1 // minimum amount of assets for internal transfers +max_transfer_commands_per_epoch = 20 // maximal amount of internal asset transfers per epoch per key +max_batch_size = 15 // maximal number of transactions allowed in one batch; this is the maximum size of a batch ``` +(for consistency reasons, the prevailing source for all parameter values is the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go)code file. In case of differences, the information in that file is the valid one). + - Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. - Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. - A proposal can only be issued by a tokenholder with more than `min_proposing_tokens` associated with one public key at the start of the epoch. Also (like above), only `num_proposals` proposals can be made per tokenholder per epoch. For example, every proposal past `num_proposals` in an epoch is rejected by post-block-rejected if the sum of their proposals in past blocks and the ones in the current block exceed `num_proposals`, or pre-block rejected if the sum of proposals already in the blockchain for that epoch equals or exceeds `num_proposals`. This parameter is the same for **all proposals**. There also is a separate parameter to the same end that is enforced in the core. For Sweetwater, both these parameters had the same value, but the spam protection value can be set lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also then be covered by the core. @@ -67,7 +75,7 @@ As unclaimed withdrawals do not automatically expire, an attacker could generate To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWitdrawalQuantumMultiple`. The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any Vega asset that has a rough value of 1 USD. -Any withdrawal requests for a smaller amounts are immediately rejected. +Any withdrawal request for a smaller amount is immediately rejected. ### Related topics @@ -76,7 +84,7 @@ Any withdrawal requests for a smaller amounts are immediately rejected. ### Acceptance Criteria -A spam attack using votes/governance proposals is detected and the votes transactions are rejected, i.e., a party that issues too many votes/governance proposals gets the follow on transactions rejected. This means (given the original parameters parameters from [0054-NETP-network_parameters.md](https://github.com/vegaprotocol/specs-internal/blob/master/protocol/0054-NETP-network_parameters.md)) +A spam attack using votes/governance proposals is detected and the votes transactions are rejected, i.e., a party that issues too many votes/governance proposals gets the follow-on transactions rejected. This means (given the original parameters from [0054-NETP-network_parameters.md](https://github.com/vegaprotocol/specs-internal/blob/master/protocol/0054-NETP-network_parameters.md)) More than 360 delegation changes in one epoch (or, respectively, the value of `spam.protection.max.delegation`). This includes the undelegate transactions. Specifically, verify: @@ -86,8 +94,8 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Delegating while having less than one vega (`10^18` of our smallest unit) (`spam.protection.delegation.min.tokens`) (0062-SPAM-002) - Making a proposal when having less than 100.000 vega (`spam.protection.proposal.min.tokens`) (0062-SPAM-003) - Changing the value of network parameter `spam.protection.proposal.min.tokens` will immediately change the minimum number of associated tokens needed for any kind of governance proposal. Proposals already active aren't affected.(0062-SPAM-014) -- Transaction creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) -- Transaction submitting votes by parties with less than `spam.protection.voting.min.tokens` vega associated are rejected. (0062-SPAM-005) +- Transactions creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) +- Transactions submitting votes by parties with less than `spam.protection.voting.min.tokens` of Vega associated are rejected. (0062-SPAM-005) - Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006) - Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007) - If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008) @@ -101,10 +109,10 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018) - During a ban due to too many votes, all governance related transactions are rejected (0062-SPAM-019) - After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020) -- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWitdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) -- Try to set `spam.protection.minimumWitdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) -- Increase `spam.protection.minimumWitdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) -- Decrease `spam.protection.minimumWitdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) -- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWitdrawalQuantumMultiple` to a value that that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) +- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) +- Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) +- Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) +- Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) +- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) -> **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed on a follow up version. +> **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. diff --git a/protocol/0064-VALP-validator_performance_based_rewards.md b/protocol/0064-VALP-validator_performance_based_rewards.md index eb5b4e1e6..ff169cdf3 100644 --- a/protocol/0064-VALP-validator_performance_based_rewards.md +++ b/protocol/0064-VALP-validator_performance_based_rewards.md @@ -5,7 +5,7 @@ The Vega chain is a delegated proof-of-stake based chain where validators are rewarded from fees generated or from on-chain treasury. The rewards are based on their own stake and the amount of stake delegated to them, -see [validator rewards](./0061-REWP-simple_pos_rewards_sweetwater.md), as well as their performance score. +see [validator rewards](./0061-REWP-pos_rewards.md), as well as their performance score. The purpose of the specification is to define how the validator rewards will be additionally scaled based on their performance. @@ -48,7 +48,7 @@ The message with the signed block hash must be in blocks `b + numBlocks` to `b + Initially the performance score is set to `0`. Both Tendermint validators and pending validators should be signing and sending these messages but only for the pending validators does this impact their score. -The performance score should be available on all the same API endpoints as the `validatorScore` from [validator rewards](./0061-REWP-simple_pos_rewards_sweetwater.md). +The performance score should be available on all the same API endpoints as the `validatorScore` from [validator rewards](./0061-REWP-pos_rewards.md). ## Acceptance criteria diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index e8f945860..f068ef9a2 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -6,7 +6,7 @@ Any intermediate results originating from 3rd party-libraries relying on floatin ## Background -Computations within a blockchain-based system [need to be deterministic](https://docs.tendermint.com/master/introduction/what-is-tendermint.html#a-note-on-determinism) as otherwise application state between nodes replicating it can start to differ potentially leading to a consensus failure. This issue has been long known in a different type of a distributed system: [networked games](https://gafferongames.com/post/floating_point_determinism/). +Computations within a blockchain-based system [need to be deterministic](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html#a-note-on-determinism) as otherwise application state between nodes replicating it can start to differ potentially leading to a consensus failure. This issue has been long known in a different type of a distributed system: [networked games](https://gafferongames.com/post/floating_point_determinism/). The two strategies for dealing with the problem have been to either synchronise the entire game state across all agents or to assure that computations yield identical results irrespective of the platform they run on. While the first strategy might work for games with limited state size due to the use of a central server it cannot be applied to a peer-to-peer application like `vega` which relies on low latency. The second strategy is trivial to implement for `integer` or `decimal` data types, but while still possible, much [more complex](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) in case of `floating-point` datatypes as it usually involves rewriting a lot of the tooling and libraries that the application relies on. diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 55f6b25d1..957c07474 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -6,7 +6,7 @@ The matching engine co-ordinates the trading of incoming orders with existing or ### In a market that is in [Continuous Trading](./0001-MKTF-market_framework.md#trading-mode---continuous-trading) -An [Immediate or Cancel (IOC)](./0014-ORDT_order_types.md#time-in-force---validity) order: +An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validity) order: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001) - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002) @@ -15,7 +15,7 @@ An [Immediate or Cancel (IOC)](./0014-ORDT_order_types.md#time-in-force---validi - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) -A [Fill or KILL (FOK)](./0014-ORDT-order-types.md#time-in-force---validity) order: +A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will either be: @@ -23,7 +23,7 @@ A [Fill or KILL (FOK)](./0014-ORDT-order-types.md#time-in-force---validity) orde - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) -For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order-types.md#time-in-force---validity) orders: +For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014) @@ -35,9 +35,9 @@ For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)]( In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): -- [IOC/FOK/GFN](./0014-ORDT-order-types.md#time-in-force---validity) +- [IOC/FOK/GFN](./0014-ORDT-order_types.md#time-in-force--validity) - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021) -- GTC/GTT/GFA](./0014-ORDT-order-types.md#time-in-force---validity) +- [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022) - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023) - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) @@ -47,14 +47,14 @@ In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): - All [PEGGED](./0014-ORDT-order_types.md#auction) orders are parked (and have their status set to PARKED). (0068-MATC-026) -- All [GFN](./0014-ORDT-order-types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) -- All [GTC/GTT](./0014-ORDT-order-types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) +- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) +- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auction-mode): - The book is uncrossed. (0068-MATC-029) - Self trading is allowed during uncrossing. (0068-MATC-030) -- All [GFA](./0014-ORDT-order-types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) +- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced where possible. (0068-MATC-032) - Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 57cd4692d..60f87a3f2 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -14,7 +14,7 @@ Note that to be eligible as a potential validator certain criteria need to be me 1. Own stake >= `reward.staking.delegation.minimumValidatorStake`. 1. Network has verified key ownership (see below). -At the end of each epoch Vega will calculate the unnormalised `validator_score`, see [rewards spec](./0061-REWP-simple_pos_rewards_sweetwater.md). +At the end of each epoch Vega will calculate the unnormalised `validator_score`, see [rewards spec](./0061-REWP-pos_rewards.md). For validators currently in the Vega validator set it will scale the `validator_score` by `(1+network.validators.incumbentBonus)`. Note that this number combines own + delegated stake together with `performance_score` which measures basic node performance. @@ -406,16 +406,18 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Also verify that the ersatz validator with the insufficient own but the most delegated stake has a ranking score of 0 and doesn't get promoted. - No validator with stake attached to them is ever completely removed 1. (Alternative until we can build a large enough network for above AC ) (0069-VCBS-059) - 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, + 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` + - the pending validator has sufficient `ownstake` - Verify that the the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, + 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) - 2 ersatz validators have 6000 stake and sufficient `ownstake` + - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, diff --git a/protocol/0071-STAK-erc20_governance_token_staking.md b/protocol/0071-STAK-erc20_governance_token_staking.md index e01662902..836b8caa6 100644 --- a/protocol/0071-STAK-erc20_governance_token_staking.md +++ b/protocol/0071-STAK-erc20_governance_token_staking.md @@ -75,7 +75,7 @@ Functions: ### ERC-20 vesting contract (`ERC20_Vesting.sol`) -The ERC-20 vesting contract implements the [Token V2](./0002-NP-TOKT-token_v2.md) specification and must also support the staking of tokens it holds as specified here. It will [ERC20_Vesting.sol](https://github.com/vegaprotocol/Vega_Token_V2/blob/main/contracts/ERC20_Vesting.sol) emit the `Stake_Deposited` and `Stake_Removed` events. +The ERC-20 vesting contract implements the [Token V2](../non-protocol-specs/0002-NP-TOKT-token_v2.md) specification and must also support the staking of tokens it holds as specified here. It will [ERC20_Vesting.sol](https://github.com/vegaprotocol/Vega_Token_V2/blob/main/contracts/ERC20_Vesting.sol) emit the `Stake_Deposited` and `Stake_Removed` events. Functions: diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 8c1fd777e..74c1ac985 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -45,8 +45,8 @@ Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_ - Staking: - last block of a confirmed stake_deposit on the staking contract on the Ethereum chain with `number_of_confirmations`. [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md#network-parameters) - last block of a confirmed stake_deposit on the vesting contract on the Ethereum chain with `number_of_confirmations`. [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md#network-parameters) - - all the staking events from both contracts [staking](./protocol/0059-STKG-simple_staking_and_delegating.md) - - all the pending staking events [staking](./protocol/0059-STKG-simple_staking_and_delegating.md) + - all the staking events from both contracts [staking](./0059-STKG-simple_staking_and_delegating.md) + - all the pending staking events [staking](./0059-STKG-simple_staking_and_delegating.md) When to create a checkpoint: diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index f2dc33b82..00614548b 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -4,7 +4,7 @@ ### Current state of upgrading the vega network -As of today, upgrading the protocol is near impossible when a major changes to the step are possible without proceeding with a [Limited Network Life checkpoint restore](./non-protocol-specs/0005-NP-LIMN-limited_network_life.md). This functionality has the following significant issues: +As of today, upgrading the protocol is near impossible when a major changes to the step are possible without proceeding with a [Limited Network Life checkpoint restore](./0073-LIMN-limited_network_life.md). This functionality has the following significant issues: - A synchronous restart is required - All node need to be restarted in a very short time so all state can be restore from Ethereum, and the network can start properly with a checkpoint. diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 7867ce8e7..302716bea 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -84,7 +84,7 @@ All proposals ever submitted + votes (asset, network parameter change, market). ### Market Data -- as [specified in](./0021-market-data-spec.md). This is emitted once per block. This is kept for backward compatibility. Note that below we may duplicate some of this. +- as [specified in](./0021-MDAT-market_data_spec.md). This is emitted once per block. This is kept for backward compatibility. Note that below we may duplicate some of this. ### Market lifecycle events diff --git a/protocol/README.md b/protocol/README.md index f12c15573..90d265af2 100644 --- a/protocol/README.md +++ b/protocol/README.md @@ -61,7 +61,6 @@ - [Market insurance pool](./0015-INSR-market_insurance_pool_collateral.md) - [Margin calculator](./0019-MCAL-margin_calculator.md) - [Quant risk models (Python notebook)](./0018-RSKM-quant_risk_models.ipynb) -- [Quant risk model Calibrators](./0023-CALI-calibrators.md) ## Data Sourcing @@ -81,7 +80,7 @@ - [Staking & Delegating](./0059-STKG-simple_staking_and_delegating.md) - [Rewards Overview](./0056-REWA-rewards_overview.md) -- [Simple Proof Of Stake rewards](./0058-REWS-simple_pos_rewards.md) +- [Simple Proof Of Stake rewards](./0061-REWP-pos_rewards.md) - [On chain treasury](./0055-TREA-on_chain_treasury.md) ## Architecture diff --git a/spellcheck.sh b/spellcheck.sh new file mode 100755 index 000000000..5f0c26bd4 --- /dev/null +++ b/spellcheck.sh @@ -0,0 +1,13 @@ +#!/bin/bash -x + +echo "Installing pyspelling..." + +pip3 install pyspelling + +echo "Installing aspell..." + +brew install aspell + +echo "Running the spell checker..." + +pyspelling --config spellcheck.yaml diff --git a/spellcheck.yaml b/spellcheck.yaml index afac368e5..27149b6ba 100644 --- a/spellcheck.yaml +++ b/spellcheck.yaml @@ -46,30 +46,3 @@ matrix: - api-ref-button - code - pre - - - name: Python - sources: - - "scripts/*.py" - default_encoding: utf-8 - aspell: - d: en_GB - lang: en - dictionary: - encoding: utf-8 - output: .pyspelling-custom-py.dic.tmp - wordlists: - - wordlist.txt - pipeline: - - pyspelling.filters.context: - context_visible_first: true - escapes: '\\[\\`]' - delimiters: - # Ignore multiline content between (possibly indented) triple backticks - - open: '(?s)^(?P[ ]*```)' - close: '^(?P=open)$' - # Ignore text between inline back ticks - - open: '(?P`)' - close: '(?P=open)' - - pyspelling.filters.python: - strings: false - comments: false From a73123bca7df97819a4738652228a4128141ec12 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 1 Feb 2023 09:13:20 +0000 Subject: [PATCH 005/649] chore: Update cosmicelevator from master branch (#1564) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> --- .github/workflows/config/markdownlintignore | 5 +- glossaries/distributed-ledger-glossary.md | 18 +- glossaries/staking-and-governance.md | 15 +- glossaries/trading-and-protocol-glossary.md | 204 +++++++++--------- makefile | 28 ++- .../0001-NP-LIQB-liquidity_providing_bots.md | 33 +-- non-protocol-specs/0002-NP-TOKT-token_v2.md | 12 +- ...0003-NP-LIMI-limits_aka_training_wheels.md | 74 +++---- ...007-NP-SNTP-sweetwater_signed_netparams.md | 11 +- .../0008-NP-NULB-null_blockchain_vega.md | 6 +- ...042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- protocol/0062-SPAM-spam_protection.md | 5 +- spellcheck.sh | 4 + spellcheck.yaml | 5 +- wordlist.txt | 16 ++ 15 files changed, 240 insertions(+), 198 deletions(-) diff --git a/.github/workflows/config/markdownlintignore b/.github/workflows/config/markdownlintignore index d0cb33a3d..d7c52fd53 100644 --- a/.github/workflows/config/markdownlintignore +++ b/.github/workflows/config/markdownlintignore @@ -1,3 +1,2 @@ -glossaries/* -non-protocol-specs/* -user-interface/* \ No newline at end of file +user-interface/* +LICENSE.md \ No newline at end of file diff --git a/glossaries/distributed-ledger-glossary.md b/glossaries/distributed-ledger-glossary.md index db5db5012..53d8a1091 100644 --- a/glossaries/distributed-ledger-glossary.md +++ b/glossaries/distributed-ledger-glossary.md @@ -2,7 +2,7 @@ ## ABI -Application Binary Interface - A JSON representation list of a smart contract's functions and arguments. It is used by wallets or clients to produce a transaction that interacts with a contract that exists on the the Ethereum chain - mapping function calls and parameters in to a bytecode form that the [EVM](#EVM) will execute. +Application Binary Interface - A JSON representation list of a smart contract's functions and arguments. It is used by wallets or clients to produce a transaction that interacts with a contract that exists on the the Ethereum chain - mapping function calls and parameters in to a bytecode form that the [EVM](#evm) will execute. ## Algorithm @@ -12,7 +12,7 @@ A generally understood set of rules and calculations for solving a particular pr The process of verifying that an actor (person or machine) is who they claim they are. -## Authorization +## Authorisation The process of verifying that an actor (person or machine) is allowed to take an action. @@ -47,7 +47,7 @@ Short for [Distributed Ledger Technology](https://en.wikipedia.org/wiki/Distribu ## Erasure Coding -... TODO but see [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding). +... `TODO` but see [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding). ## Eventual consistency @@ -77,7 +77,7 @@ A rule for determining which fork is correct when faced with multiple possibly-v The [Greedy Heaviest-Observed Subtree](https://eprint.iacr.org/2013/881.pdf), a fork choice rule. -## Hashchain +## Hash chain ... @@ -95,7 +95,7 @@ The amount of time before a system can achieve both consensus and finality; it's ## Longest Chain -The longest chain approach is one way to solve consensus. It consists of a mechanism that (not necessarily uniquely) determinas a leader that can propose the next block in the blockchain. If a node sees a longer chain than the one it knows, it uses that one as its new chain. Longest chain protocols do not offer finallity, i.e., every block can (theoretically) be undone. +The longest chain approach is one way to solve consensus. It consists of a mechanism that (not necessarily uniquely) determines a leader that can propose the next block in the blockchain. If a node sees a longer chain than the one it knows, it uses that one as its new chain. Longest chain protocols do not offer finality, i.e., every block can (theoretically) be undone. ## MainNet @@ -137,7 +137,7 @@ There are entire protocols ([Band](https://bandprotocol.com/), [Chainlink](https ## Reliable Broadcast -A reliable broadcast assures that all receiving of a broadcasr nodes receive the same set of messages, and that a message sent by an honest sender is received. ... see [here](https://www.semanticscholar.org/paper/Asynchronous-consensus-and-broadcast-protocols-Bracha-Toueg/130ce1bcd496a7b9192f5f53dd8d7ef626e40675), +A reliable broadcast assures that all receiving of a broadcast nodes receive the same set of messages, and that a message sent by an honest sender is received. ... see [here](https://www.semanticscholar.org/paper/Asynchronous-consensus-and-broadcast-protocols-Bracha-Toueg/130ce1bcd496a7b9192f5f53dd8d7ef626e40675), [here](https://www.shoup.net/papers/ckps.pdf) or [here](https://arxiv.org/pdf/1510.06882.pdf). ## State Channels @@ -162,7 +162,7 @@ The amount of data that can be processed by a system in a given unit of time, e. ## Validators -From the [Tendermint documentation](https://docs.tendermint.com/master/nodes/validators.html): -> Validators are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key. +From the [Tendermint documentation](https://docs.tendermint.com/v0.34/tendermint-core/validators.html): -> Some Proof-of-Stake consensus algorithms aim to create a "completely" decentralized system where all stakeholders (even those who are not always available online) participate in the committing of blocks. [Tendermint](#tendermint) has a different approach to block creation. Validators are expected to be online, and the set of validators is permissioned/curated by some external process. +> Validators are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key. +> Some Proof-of-Stake consensus algorithms aim to create a "completely" decentralised system where all stakeholders (even those who are not always available online) participate in the committing of blocks. [Tendermint](#tendermint) has a different approach to block creation. Validators are expected to be online, and the set of validators is permissioned/curated by some external process. diff --git a/glossaries/staking-and-governance.md b/glossaries/staking-and-governance.md index 28364df09..95aa5873d 100644 --- a/glossaries/staking-and-governance.md +++ b/glossaries/staking-and-governance.md @@ -6,21 +6,22 @@ This is a general term that may have specific meaning in different contexts. Veg ## Delegation -This is the process of assigning Vega tokens to validators on Vega chain. It is a two step process consisting of -1) [Association](#associate) which happens on the Ethereum blockchain by interaction with the Staking and Delegation bridges. -2) [Nomination](#nominate) which happens on the Vega blockchain, assigning voting power to validators. +This is the process of assigning Vega tokens to validators on Vega chain. It is a two step process consisting of: + +1. [Association](#associate) which happens on the Ethereum blockchain by interaction with the Staking and Delegation bridges. +1. [Nomination](#nominate) which happens on the Vega blockchain, assigning voting power to validators. ## Associate -This allows a user with Vega Tokens on Ethereum to associate their tokens with a vega key so that the Vega key can participate in [Governance](#Governance) and [Nominate](#Nominate) their Stake to a [validator](distributed-ledger-glossary.md#validators). +This allows a user with Vega Tokens on Ethereum to associate their tokens with a vega key so that the Vega key can participate in [Governance](#governance) and [Nominate](#nominate) their Stake to a [validator](distributed-ledger-glossary.md#validators). This is done by interaction with the Staking and Delegation bridge contracts (the vesting contract implements this functionality for Vega held by the vesting contract). ## Dissociate To opposite of association. Tokens can be dissociated via Ethereum staking and delegation bridge. Vega tokens are thus no longer associated to a Vega key (on either the Staking bridge or the Vesting contract, depending on how they were [Associated](#associate)). This means that in the future they can be associated to a different (or same) Vega key. -This action happens on Ethereum. The staking and delegation smart contract and does not know when an [Epoch](#Epoch) ends meaning the relevant Vega key will not be due any rewards from that epoch. -Users are recommended to first [De-nominate](#De-nominate) sufficient amount using their Vega key and interacting with the Vega chain. This way, when the Epoch ends they can dissociate without loosing any due rewards. Moreover they get to choose which validator they are removing their nomination from. +This action happens on Ethereum. The staking and delegation smart contract and does not know when an [Epoch](#epoch) ends meaning the relevant Vega key will not be due any rewards from that epoch. +Users are recommended to first [De-nominate](#de-nominate) sufficient amount using their Vega key and interacting with the Vega chain. This way, when the Epoch ends they can dissociate without loosing any due rewards. Moreover they get to choose which validator they are removing their nomination from. ## Governance @@ -44,4 +45,4 @@ A window of time, In which tokens that are staked on a are due a reward. If toke ## Self Staking -That act of putting Vega tokens on a Validator node that you are running, as apposed to having tokens staked on a node via [Nomination](#Nominate). +That act of putting Vega tokens on a Validator node that you are running, as apposed to having tokens staked on a node via [Nomination](#nominate). diff --git a/glossaries/trading-and-protocol-glossary.md b/glossaries/trading-and-protocol-glossary.md index 9abcca051..28307da7f 100644 --- a/glossaries/trading-and-protocol-glossary.md +++ b/glossaries/trading-and-protocol-glossary.md @@ -4,38 +4,32 @@ ### Average Entry Price -This is the *volume weighted price* of a trader's [Open Volume](#open-volume). The open volume will always be comprised of all buys or all sells. +This is the **volume weighted price** of a trader's [Open Volume](#open-volume). The open volume will always be comprised of all buys or all sells. -*Example 1 - all buys:* +**Example 1 - all buys:** A trader has 3 price levels at which their open volume was purchased: -1. Long 3 contracts @ $100 -2. Long 2 contracts @ $80 -3. Long 5 contracts @ $150 +1. Long 3 contracts @ $100 +1. Long 2 contracts @ $80 +1. Long 5 contracts @ $150 -***Average Entry Price*** = (3 * $100 + 2 * $80 + 5 * $150)/(3 + 2 + 5) = ($300 + $160 + $750) / 10 = $121 +**Average Entry Price** = `(3 * $100 + 2 * $80 + 5 * $150)/(3 + 2 + 5) = ($300 + $160 + $750) / 10 = $121` -*Example 2 - all sells:* +**Example 2 - all sells:** A trader has 3 price levels at which their open volume was sold: -1. Short -3 contracts @ $100 -2. Short -2 contracts @ $80 -3. Short -5 contracts @ $150 +1. Short -3 contracts @ $100 +1. Short -2 contracts @ $80 +1. Short -5 contracts @ $150 Note, with position management we treat the volume of sells as negative for calculation purposes (not necessarily display purposes to users). Note, that in this calculation however, the negatives cancel each other out. -***Average Entry Price*** = (-3 * $100 + -2 * $80 + -5 * $150)/(-3 - 2 - 5) = (-$300 - $160 - $750) / -10 = $121 +**Average Entry Price** = `(-3 * $100 + -2 * $80 + -5 * $150)/(-3 - 2 - 5) = (-$300 - $160 - $750) / -10 = $121` The Average Entry Price is useful when calculating [Unrealised P&L](#unrealised-pnl) or [Realised P&L](#realised-pnl) -### Fills - -> Fill is the term used to refer to the satisfying of an order to trade a financial asset. It is the basic act of any market transaction – when an order has been completed, it is often referred to as ‘filled’ or as the order having been executed. However, it is worth noting that there is no guarantee that every trade will become filled. - -[IG Index: Fill Definition](https://www.ig.com/uk/glossary-trading-terms/fill-definition) - ## B ### Base currency @@ -58,11 +52,11 @@ When a trader's collateral level in the risk universe drops below the [close out ### Closed position -The set of long and short contracts with price and volume specified that are matched as offset volume during the [FIFO](#fifo) netting process. +The set of long and short contracts with price and volume specified that are matched as offset volume during the [FIFO](#fifo-first-in-first-out) netting process. ### Closed volume -The volume that is matched into [closed volume](#closed-volume) during the [FIFO](#fifo) netting process. It is measured as the sum of the buys of the matched volume. So, if 2 long (or +2) contracts are netted with 2 short (or -2) contracts, the ***Closed Volume*** = 2. +The volume that is matched into [closed volume](#closed-volume) during the [FIFO](#fifo-first-in-first-out) netting process. It is measured as the sum of the buys of the matched volume. So, if 2 long (or +2) contracts are netted with 2 short (or -2) contracts, the **Closed Volume** = 2. The profit or loss that a trader locks in when they close volume is called the [Realised P&L](#realised-pnl) and is not affected by future price moves in the instrument. @@ -83,6 +77,7 @@ Any order that trades any amount and as much as possible but does not remain on ### Fees Fees are incurred on trades in Vega. There are three categories of fee, each of which is paid out to different participants: + - Infrastructure fee: paid to [validators](#validators), - Maker fee: paid to the price maker, - Liquidity fee: paid to [Liquidity Providers](#liquidity-providers) @@ -95,40 +90,40 @@ A matching methodology which prioritises older volume as an offset when counter Use Case 2 - Calculating a trader's open and closed position. -***Example - FIFO on an individual trader's trades:*** - -1. 24-July-07:00 Buy 3 contracts @ $100 -2. 24-July-07:10 Sell 1 contract @ $400 -3. 24-July-07:14 Sell 6 contracts @ $370 -4. 24-July-07:15 Buy 2 contracts @ $80 -5. 24-July-07:46 Buy 5 contracts @ $150 -6. 24-July-09:00 Sell 2 contracts @ $300 -7. 24-July-10:10 Sell 2 contract @ $ 320 -7. 24-July-10:10 Sell 3 contract @ $ 379 - -*Fifo matching - calculating [closed position](#open-position)s*: - -* -1 contract @ $400 -* +1 contract @ $100 -* -2 contract @ $370 -* +2 contract @ $100 -* +2 contract @ $80 -* -2 contract @ $370 -* +2 contract @ $150 -* -2 contract @ $370 -* -2 contract @ $300 -* +2 contract @ $150 -* -1 contract @ $320 -* +1 contract @ $150 +**Example - FIFO on an individual trader's trades:** + +1. 24-July-07:00 Buy 3 contracts @ $100 +1. 24-July-07:10 Sell 1 contract @ $400 +1. 24-July-07:14 Sell 6 contracts @ $370 +1. 24-July-07:15 Buy 2 contracts @ $80 +1. 24-July-07:46 Buy 5 contracts @ $150 +1. 24-July-09:00 Sell 2 contracts @ $300 +1. 24-July-10:10 Sell 2 contract @ $ 320 +1. 24-July-10:10 Sell 3 contract @ $ 379 + +**Fifo matching - calculating [closed position](#open-position)s**: + +- -1 contract @ $400 +- +1 contract @ $100 +- -2 contract @ $370 +- +2 contract @ $100 +- +2 contract @ $80 +- -2 contract @ $370 +- +2 contract @ $150 +- -2 contract @ $370 +- -2 contract @ $300 +- +2 contract @ $150 +- -1 contract @ $320 +- +1 contract @ $150 The above represent the [closed position](#closed-position) which can be inputted into the [Realised P&L](#realised-pnl) calculation to determine how profitable these trades were. The [closed volume](#closed-volume) is considered to be 9 (offset) contracts. -*Fifo matching - remainder [open position](#open-position)*: +**Fifo matching - remainder [open position](#open-position)**: The remainder (unmatched) positions are comprised of: -* -1 contract @ $320 -* -3 contract @ $379 +- -1 contract @ $320 +- -3 contract @ $379 The above represent the [open position](#open-position) which can be inputted into the [Unrealised P&L](#unrealised-pnl) and the [Average Entry Price](#average-entry-price) calculations. @@ -166,16 +161,17 @@ An order that trades any amount and as much as possible and remains on the book ### Instrument -An instance of a *smart product* that can be traded on Vega network with all parameters required for settlement and / or margin requirements specified. +An instance of a **smart product** that can be traded on Vega network with all parameters required for settlement and / or margin requirements specified. Parameters: -* Name: Example: BTCUSD Dec 2018 Future. -* Underlying -* Base currency -* Tick size -* Expiry -* Payoff / settlement formula -* Minimum contract size + +- Name: Example: `BTCUSD` Dec 2018 Future. +- Underlying +- Base currency +- Tick size +- Expiry +- Payoff / settlement formula +- Minimum contract size ### Insurance Pool @@ -189,7 +185,7 @@ The net riskiest composition of a trader's open positions and live orders. For ### Liquidity Providers -Liquidity providers commit a bond and place a special Liquidity Commitment that automatically maintains orders on the book for a specific market. In return, liquidity providers earn a [fee](#fee) for ensuring that markets always have open volume. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail. +Liquidity providers commit a bond and place a special Liquidity Commitment that automatically maintains orders on the book for a specific market. In return, liquidity providers earn a [fee](#fees) for ensuring that markets always have open volume. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail. ## M @@ -201,8 +197,8 @@ The amount of collateral (due in the base currency of the product) that a trader An instrument's market valuation at any point in time. This will be set to the higher / lower of the: -* last traded price; -* bid / offer +- last traded price; +- bid / offer ### Mark to Market @@ -240,23 +236,23 @@ Assume an individual has a set of trades which they have executed on one market. Calculate: -1. Open Volume Sign: If sum of the long volume > sum of the short volume, trader's open position is net long (and vice versa). +1. Open Volume Sign: If sum of the long volume > sum of the short volume, trader's open position is net long (and vice versa). -2. Closed Volume Amount: If Open Volume Sign > 0, the ***Closed Volume Amount*** is the sum of the short volume of the trades (and vice versa). +1. Closed Volume Amount: If Open Volume Sign > 0, the **Closed Volume Amount** is the sum of the short volume of the trades (and vice versa). -3. Closed Long Contracts - ***the first n volume***, where n is the ***Closed Volume Amount*** (note this methodology is a shortcut way to implementing FIFO at any point in time). +1. Closed Long Contracts - **the first n volume**, where n is the **Closed Volume Amount** (note this methodology is a shortcut way to implementing FIFO at any point in time). -4. Closed Short Contracts - ***the first n volume***, where n is the ***Closed Volume Amount*** (note this methodology is a shortcut way to implementing FIFO at any point in time). +1. Closed Short Contracts - **the first n volume**, where n is the **Closed Volume Amount** (note this methodology is a shortcut way to implementing FIFO at any point in time). -5. Open Contracts - whatever is left of the volume that isn't in ***Closed Long Contracts*** or ***Closed Short Contracts***. These will always be either long contracts OR short contracts but never both (else they'd have been matched off). Contracts specify a price level and a volume. They are not trades, as they may be residual volume from a trade that has been partially matched. +1. Open Contracts - whatever is left of the volume that isn't in **Closed Long Contracts** or **Closed Short Contracts**. These will always be either long contracts OR short contracts but never both (else they'd have been matched off). Contracts specify a price level and a volume. They are not trades, as they may be residual volume from a trade that has been partially matched. -* ***Realised Volume*** is the ***Closed Volume Amount*** +- **Realised Volume** is the **Closed Volume Amount** -* ***Realised PnL*** = ***Closed Volume Amount*** * (***Average Entry Price*** (of Closed Short Contracts) - [Average Entry Price](#average-entry-prive) (of Closed Long Contracts)) +- **Realised PnL** = **Closed Volume Amount** * (**Average Entry Price** (of Closed Short Contracts) - [Average Entry Price](#average-entry-price) (of Closed Long Contracts)) -* ***Unrealised Volume*** is the sum of the volume of all the ***Open Contracts*** +- **Unrealised Volume** is the sum of the volume of all the **Open Contracts** -* ***Unrealised PnL*** = ***Unrealised Volume*** * (***Mark Price*** - ***Average Entry Price***(of Open Contracts)) +- **Unrealised PnL** = **Unrealised Volume** * (**Mark Price** - **Average Entry Price**(of Open Contracts)) ### Notional Value @@ -271,12 +267,12 @@ Reported for a market / instrument, this is the sum of [Open Volume](#open-volum Example (assume zero trading in the market so far): 1. Candida buys 4 contracts from David. The Open Interest is 4. -2. Candida then sells her 4 contracts back to David. The Open Interest is 0. -3. Rather than selling back to David, Candida sells to Chris. The Open Interest is 4. +1. Candida then sells her 4 contracts back to David. The Open Interest is 0. +1. Rather than selling back to David, Candida sells to Chris. The Open Interest is 4. ### Open position -The set of long OR short contracts with price and volume specified that are NOT matched as offset volume during the [FIFO](#fifo) netting process. They are the residual contracts that have exposure to the market price changes and require margin to be deposited. +The set of long OR short contracts with price and volume specified that are NOT matched as offset volume during the [FIFO](#fifo-first-in-first-out) netting process. They are the residual contracts that have exposure to the market price changes and require margin to be deposited. ### Open Volume @@ -284,10 +280,10 @@ This the total volume of long OR short [open position](#open-position). Example, if an individual trader's [open position](#open-position) on an instrument is: -* +1 @ $100 -* +4 @ 109 +- +1 @ $100 +- +4 @ 109 -The ***Open Volume*** = 1 + 4 = 5 contracts +The **Open Volume** = 1 + 4 = 5 contracts The exposure that a trader has on their Open Volume to the market's price moves is called the [unrealised P&L](#unrealised-pnl) @@ -307,7 +303,7 @@ The risk value of the total open interest for an instrument calculated by the ri ### Oracle Feed -A definite source of price information for an underlying (could come from another instrument's market activity (eg. trading or prices) on the Vega network, or from an external source). +A definite source of price information for an underlying (could come from another instrument's market activity (e.g. trading or prices) on the Vega network, or from an external source). ### Order Book @@ -337,26 +333,26 @@ For the creation an instrument, the time between the initial proposal period and ### Realised PnL -The ***Realised PnL*** calculates the profitability that has been locked in by a trader who exits an existing [open position](#open-position). -The inputs to a ***Realised PnL*** calculation is the set of positions, including specification of volume and price, that are the result of matched volume, calculated by [FIFO](#fifo). +The **Realised PnL** calculates the profitability that has been locked in by a trader who exits an existing [open position](#open-position). +The inputs to a **Realised PnL** calculation is the set of positions, including specification of volume and price, that are the result of matched volume, calculated by [FIFO](#fifo-first-in-first-out). Example: A trader's closed position is comprised of the following: -1. +3 contracts @ $100 -2. +2 contracts @ $80 -3. +5 contracts @ $150 -4. -1 contract @ $400 -5. -6 contracts @ $370 -6. -2 contracts @ $300 -7. -1 contract @ $ 320 +1. +3 contracts @ $100 +1. +2 contracts @ $80 +1. +5 contracts @ $150 +1. -1 contract @ $400 +1. -6 contracts @ $370 +1. -2 contracts @ $300 +1. -1 contract @ $ 320 -Note, for closed positions, the number of longs and number of shorts should equal each other (in this case we are 10 long and 10 short). Short positions are represented by -'ve numbers for volume. +Note, for closed positions, the number of longs and number of shorts should equal each other (in this case we are 10 long and 10 short). Short positions are represented by `-ve` numbers for volume. -***Realised PnL*** = Total Volume * (Average Entry Price (sells) - Average Entry Price (buys)) +**Realised PnL** = `Total Volume * (Average Entry Price (sells) - Average Entry Price (buys)) = 10 ( (-1 * $400 + -6 * $370 + -2 * $300 + -1 * $320 )/-10 - (3 * $100 + $2 * 80 + 5 * $150)/10 ) -= 10 ($354 - $121) = $2330 += 10 ($354 - $121) = $2330` ### Risk Engine @@ -398,7 +394,7 @@ Staking and delegation are used relatively interchangeably as in Vega, staking h ### Trade Volume -The number of contracts multiplied by the size of each contract for each market. For example, the market may have a contract size of $1USD and one trade may be for 10 contracts. The *trade volume* then equals $1 x 10 = $10. +The number of contracts multiplied by the size of each contract for each market. For example, the market may have a contract size of $1USD and one trade may be for 10 contracts. The _trade volume_ then equals $1 x 10 = $10. ### Trade Entry Price @@ -408,49 +404,49 @@ The quote price which a buyer and seller are matched at. ### Unrealised PnL -The ***Unrealised PnL*** calculates the profitability that a trader would receive if they were able to close their open positions at the current market price, as measured by the [mark price](#mark-price). It is sometimes referred to as [mark to market](#mark-to-market). It helps traders to understand what the 'value' of their portfolio is. Also they are required to cover any unrealised losses in their margin requirements. +The **Unrealised PnL** calculates the profitability that a trader would receive if they were able to close their open positions at the current market price, as measured by the [mark price](#mark-price). It is sometimes referred to as [mark to market](#mark-to-market). It helps traders to understand what the 'value' of their portfolio is. Also they are required to cover any unrealised losses in their margin requirements. -The inputs to a ***Unrealised PnL*** calculation is the set of trades (or partial trades) which specify volume and price, that are the result of unmatched volume, calculated by [FIFO](#fifo). This will always be either all buys or all sells. +The inputs to a **Unrealised PnL** calculation is the set of trades (or partial trades) which specify volume and price, that are the result of unmatched volume, calculated by [FIFO](#fifo-first-in-first-out). This will always be either all buys or all sells. -***Example 1 (trader has a net long open position):*** +**Example 1 (trader has a net long open position):** A trader's open volume is comprised of the following: -1. +3 contracts @ $100 -2. +2 contracts @ $80 -3. +5 contracts @ $150 +1. +3 contracts @ $100 +1. +2 contracts @ $80 +1. +5 contracts @ $150 Let's assume the latest [mark price](#mark-price) is set by the last trade in this market at $120. -***Unrealised PnL*** = Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) +**Unrealised PnL** = `Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) = 10 ( $120 - (3 * $100 + $2 * 80 + 5 * $150)/Abs(10) ) -= 10 ($120 - $121) = - $10 += 10 ($120 - $121) = - $10` The trader has made a loss of -$10 across their trades. However, this isn't locked in (realised) and the market may still move back in their favour. -***Example 2 (trader has a net short open position):*** +**Example 2 (trader has a net short open position):** A trader's open volume is comprised of the following: -1. -1 contract @ $750 -2. -6 contracts @ $330 -3. -2 contracts @ $999 +1. -1 contract @ $750 +1. -6 contracts @ $330 +1. -2 contracts @ $999 Let's assume the latest [mark price](#mark-price) is set by the last trade in this market at $666. -***Unealised PnL*** = Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) +_Unrealised PnL_ = `Total Volume * ([mark price](#mark-price) - [average entry price](#average-entry-price)) = -9 * ( $666 - (-1 * $750 + -6 * $330 + -2 * $999)/-9 ) -= -9 * ($666 - $525.33) = - $140.67 += -9 * ($666 - $525.33) = - $140.67` The trader has made a loss of -$140.67 across their trades. However, this isn't locked in (realised) and the market may still move back in their favour. -# V +## V -## Validators +### Validators Validators are the nodes that run Vega and participate in the creation of the blocks. See [the distributed ledger glossary](distributed-ledger-glossary.md#validators) for more information on validators. -## Vega time +### Vega time Vega time is the current time of the chain (decided through consensus); it's based on the timestamp* agreed by the nodes. Vega needs validators to have a share idea of what time it is, regardless of their location or their clock being incorrect. diff --git a/makefile b/makefile index c192ee4bd..9f36d8ccf 100644 --- a/makefile +++ b/makefile @@ -1,7 +1,7 @@ # Set default to run all checks if none specified .DEFAULT_GOAL := all -all: spellcheck markdownlint names codes links references +all: spellcheck markdownlint names codes references links clean # Check that all the specifications are named appropriately .PHONY: names @@ -13,16 +13,33 @@ names: codes: npx @vegaprotocol/approbation check-codes +TEMP=./.build +.PHONY:clone-sources +clone-sources: + @mkdir -p $(TEMP) + + @echo "Cloning/updating test repos..." + @cd $(TEMP); \ + git -C MultisigControl pull || git clone https://github.com/vegaprotocol/MultisigControl.git & \ + git -C vega pull || git clone https://github.com/vegaprotocol/vega.git & \ + git -C vega_token_v2 pull || git clone https://github.com/vegaprotocol/vega_token_v2.git & \ + git -C staking_bridge pull || git clone https://github.com/vegaprotocol/staking_bridge.git & \ + git -C system-tests pull || git clone https://github.com/vegaprotocol/system-tests.git + # Which Acceptance Criteria are referenced in which feature files? +# Runs make clone-sources in a shell so that it properly waits for them to run in parallel and finish .PHONY: references references: - npx @vegaprotocol/approbation check-references + @$(MAKE) clone-sources + + cd $(TEMP); npx -y @vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files + + @$(MAKE) clean # Imperfect, but useful - hence not included in ALL .PHONY: links links: - npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json protocol/*.md - npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json non-protocol-specs/*.md + npx --yes markdown-link-check --config .github/workflows/config/markdownlinkcheckignore.json ./*protocol*/*.md # check the markdown formatting (/protocol specs only at this time) .PHONY: markdownlint @@ -33,3 +50,6 @@ markdownlint: .PHONY: spellcheck spellcheck: @./spellcheck.sh + +clean: + rm -rf $(TEMP) diff --git a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md index dc24dc444..37efa641e 100644 --- a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md +++ b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md @@ -3,7 +3,9 @@ ## Introduction At the moment bots on Vega run on certain markets to make them look "real". + For that purpose they: + 1. Are given large amounts of collateral via faucets. 1. Keep track of current spot or futures price on another exchange (at e.g. 30s, 5 min intervals) 1. Post GTC limit orders randomly on both sides of the order book at random volumes using the above reference price as mid. @@ -12,10 +14,12 @@ This achieves the following: the price on the market looks "real" and there is v The downside is that if the bot is "unlucky" they can run out of even large amount of collateral and their orders / positions are liquidated. To avoid this they need regular collateral top-ups. -From Flamenco Tavern onvards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../protocol/0038-OLIQ-liquidity_provision_order_type.md). +From Flamenco Tavern onwards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../protocol/0038-OLIQ-liquidity_provision_order_type.md). If a feature is marked as "optional" then the bot can be configured in such a way that it is not providing this functionality but still doing other tasks. -The aim of this spec is bots that + +The aim of this spec is bots that: + 1. submit a market proposal (optional) or connects to an existing market 1. serve as a liquidity provider for the market by submitting the [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) (optional). 1. participate in an opening auction (optional) @@ -33,15 +37,15 @@ The bot needs to be able to query Vega to know the risk model and parameters for - vega Wallet credentials - market proposal file - market ID (the market to engage with), can come from proposal above -- reference price source (optional), it is assumed that this is updated in real time. provided by an independent process / bot to keep things simple here. So in particular if a price source has API time limits then a separate bot / process should be accessing the price source and making up random price moves to fill the time(*) and , *not* the bot we are specifying here. +- reference price source (optional), it is assumed that this is updated in real time. provided by an independent process / bot to keep things simple here. So in particular if a price source has API time limits then a separate bot / process should be accessing the price source and making up random price moves to fill the `time(*)` and , _not_ the bot we are specifying here. - `expectedMarkPrice` (optional, can be from the reference price above). This will be used in markets that don't yet have mark price to calculate margin cost of orders meeting liquidity requirement. - `auctionVolume` - `maxLong` and `maxShort` position limits and `posManagementFraction` controlling size of market order used to manage position - `stakeFraction`, `ordersFraction`, these will be used in rule-of-thumb heuristics to decide how the bot should deploy collateral. -- `shorteningShape`, `longeningShape` both of these are *both* sides of the book (note that the initial shape used will be the buying shape because being long is a little cheaper in position margin than being short) +- `shorteningShape`, `longeningShape` both of these are _both_ sides of the book (note that the initial shape used will be the buying shape because being long is a little cheaper in position margin than being short) - `positionManagementSleep` e.g. 10s and `posManagementFraction` e.g. `0.1` - `marketPriceSteeringRate` e.g. 2 per second would be 2 -- `targetLNVol` target log-normal volatility (e.g. 0.5 for 50%), `limitOrderDistributionParams` (a little data structure which sets the algo and params for how limits orders are generated). +- `targetLNVol` target log-normal volatility (e.g. 0.5 for 50%), `limitOrderDistributionParams` (a little data structure which sets the algorithm and parameters for how limits orders are generated). (*) This separate process will then also need to use correct distributions to make the price moves look plausible. @@ -50,10 +54,8 @@ The bot needs to be able to query Vega to know the risk model and parameters for This is only relevant if the option to submit a market proposal is enabled. The bot will read the required market proposal from a file (configuration option), decide if it has minimum LP stake in the right asset, check it's got enough vote tokens and then submit the proposal and vote for it. They will also need to submit [liquidity shapes](../protocol/0038-OLIQ-liquidity_provision_order_type.md) but that will be treated below. -To decide that it will ask Vega for `assetBalance`, `quantum` for asset and `min_LP_stake_quantum_multiple` and proceed if -``` -assetBalance x stakeFraction > min_LP_stake_quantum_multiple x quantum -``` +To decide that it will ask Vega for `assetBalance`, `quantum` for asset and `min_LP_stake_quantum_multiple` and proceed if `assetBalance x stakeFraction > min_LP_stake_quantum_multiple x quantum` + It will then check whether it has enough collateral for maintaining the commitment but that will be described below as it applies below too. ### Serving as a liquidity provider for a market @@ -108,7 +110,7 @@ fi This section is only relevant if the option to participate in an opening auction is selected and the relevant market given by the market ID is still in an opening auction. If the bot has `currentPrice` then it should place buy / sell limit orders (good till time with duration a bit longer than opening auction length) in the auction at random distance and volume away from `currentPrice` up to total `auctionVolume`. -The distance and volume should be consistent with market risk parameters (spec work for later, Witold, do you feel like coming up with a formula?) +The distance and volume should be consistent with market risk parameters. ### Create markets that look real @@ -129,6 +131,7 @@ limitOrderDistributionParams = { numIdenticalBots = 3 } ``` + With the above example you can generate the correct orders using the method in the [notebook](./0010-NP-BOTC-bot_parameter_calc_and_test.ipynb) with `delta=tickSize x numTicksFromMid` and `N = 3600 x 2 / 3`. Another Example: @@ -145,13 +148,13 @@ limitOrderDistributionParams = { } ``` -Again, the algorithm for choosing the parameters and generating samples is in the [notebook](./BotParameterCalcAndTest.ipynb) with `delta=tickSize x numTicksFromMid` and `N = 3600 x 0.5 / 10`. +Again, the algorithm for choosing the parameters and generating samples is in the [notebook](./0010-NP-BOTC-bot_parameter_calc_and_test.ipynb) with `delta=tickSize x numTicksFromMid` and `N = 3600 x 0.5 / 10`. -Generate the orders using the above method *but*: +Generate the orders using the above method _but_: -If the position of the bot is long *only* place sell orders. +If the position of the bot is long _only_ place sell orders. -If the position of the bot is short *only* place buy orders here. +If the position of the bot is short _only_ place buy orders here. ### Manage their position @@ -211,7 +214,7 @@ Don't use any of the pseudocode above! 1. Bot can submit a market proposal (optional), commit liquidity and then manage it's position as described above, see also [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md). (0001-NP-LIQB-001) 1. Bot can connect to an existing market, submit an [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) and then manage it's position as described above. (0001-NP-LIQB-002) -1. Bot can participate in an opening auction placing orders around target price (set via params, see above).(0001-NP-LIQB-003) +1. Bot can participate in an opening auction placing orders around target price (set via parameters, see above).(0001-NP-LIQB-003) 1. Can read a price target from external source and and places limit orders that "steer" the price up-or-down as appropriate and have the right `targetLNVol` using one of the methods above (note that this has to take into account other identical bots trying to do the same on the same market).(0001-NP-LIQB-004) 1. Bot manages its position in such a way that it stays close to zero and starts placing market orders if configured maxima are breached.(0001-NP-LIQB-005) 1. The repository is public from the start. diff --git a/non-protocol-specs/0002-NP-TOKT-token_v2.md b/non-protocol-specs/0002-NP-TOKT-token_v2.md index b8008fc5d..a4e0f3b87 100644 --- a/non-protocol-specs/0002-NP-TOKT-token_v2.md +++ b/non-protocol-specs/0002-NP-TOKT-token_v2.md @@ -1,6 +1,6 @@ # Token V2 -Version 2 of the $VEGA token replaces the existing token and providse two crucial upgrades: +Version 2 of the $VEGA token replaces the existing token and provides two crucial upgrades: 1. It allows for more sophisticated unlocking (vesting) schedules to be implemented and enforced on chain 1. It places the total supply of the token in the control of network/token holder governance @@ -8,7 +8,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia ## 1. Token supply 1. Supply is fixed initially at `64,999,723` -1. Supply canot be increased before a date (TBC) known as the `supply fix cut-off date` +1. Supply cannot be increased before a date (TBC) known as the `supply fix cut-off date` 1. After the `supply fix cut-off date`, supply **can** be increased by community governance on the Vega chain (i.e. via multisig control) 1. Supply cannot be changed by the contract owner/administrator 1. If supply is ever increased, the issuance of this supply should be done by the Vega chain too (i.e. via multisig control). It is not obvious that we need to enforce this, as long as multisig control can be an allowed issuer. @@ -20,7 +20,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia 1. Deployment/activation of the token contract will automatically issue tokens based on the wallet balances of the V1 token at deployment time 1. The contract owner must be able to assign vesting tranches for auto-issued tokens 1. Tokens held by a single address may comprise tokens in multiple tranches -1. Each address receiving auto-issed tokens may have a different vesting tranche +1. Each address receiving auto-issued tokens may have a different vesting tranche 1. Auto-issued tokens with no assigned vesting tranche must remain locked ## 3. Issuance mechanics @@ -56,7 +56,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia ## 6. Security and control -1. It should be possible for the contract owner to be a multisig, an instance of multisig control, or another smart cnotract, if needed +1. It should be possible for the contract owner to be a multisig, an instance of multisig control, or another smart contract, if needed 1. The contract owner must not be able to change anything about tokens that have been issued and unlocked 1. The contract owner must not be able to change the supply of the token 1. The contract owner must not be able to effect a token contract upgrade @@ -64,7 +64,7 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia ## 7. Staking and delegation -1. Staking mostly occurs on the Vega protocol side, however for two reasons, it _may_ be sensible or necessary to include some support for it in the token itself: +1. Staking mostly occurs on the Vega protocol side, however for two reasons, it *may* be sensible or necessary to include some support for it in the token itself: 1. We need to support staking of locked tokens 1. There may be a security advantage to not having staked tokens under the control of the bridge/multisigcontrol (i.e. so that taking over the validators/network would not allow you to also take ownership of **all** staked tokens) @@ -73,4 +73,4 @@ Version 2 of the $VEGA token replaces the existing token and providse two crucia 1. Unlocked tokens that have been transferred away cannot be or remain staked. 1. Once staked on the Vega side, tokens cannot be allowed to be transferred to another address even if they are unlocked from the perspective of vesting -For instance these goals could be achieved by using a special "stake" function on the smart contract that interacts with the bridge/multisigcontrol to mark them as staked (for either valdiator staking or delegation), and allowing "unstaking" to occur only from the Vega side, via multisigcontrol. This way even once vested, the tokens would still be marked as staked until the network releases them, and even though the network has control over whether they are staked, it does not hold them in the bridge pool while staked and cannot transfer them. +For instance these goals could be achieved by using a special "stake" function on the smart contract that interacts with the bridge/multisigcontrol to mark them as staked (for either validator staking or delegation), and allowing "unstaking" to occur only from the Vega side, via multisigcontrol. This way even once vested, the tokens would still be marked as staked until the network releases them, and even though the network has control over whether they are staked, it does not hold them in the bridge pool while staked and cannot transfer them. diff --git a/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md b/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md index 3b3ee2f5a..6761e86af 100644 --- a/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md +++ b/non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md @@ -2,11 +2,12 @@ This spec describes a set of limits and controls that must be supported by deployments of the Vega system to mitigate the risk of loss or misappropriation of funds early in the life of the system while it is relatively less well tested and more likely to contain major bugs or mechanism design issues. The aim is to achieve this by implementing features which reduce both the expected magnitude and the probability of financial loss, from the perspective of participants interacting with the Vega protocol. -These limits are expected to be used in early deployments of Vega and are desiogned to be raised and/or removed over time via the governance protocol as the security and the robustness of the implementation is demonstrated. +These limits are expected to be used in early deployments of Vega and are designed to be raised and/or removed over time via the governance protocol as the security and the robustness of the implementation is demonstrated. ## Principles These features: + - Must not introduce points of centralisation. They are therefore designed to be operated by decentralised governance protocols in keeping with the core Vega protocol. - Should be as simple as possible and should operate correctly independent of whether any aspect of the core protocol is functioning as expected (i.e. they should allow recovery from issues in which someone is able to exploit bugs in products, margins, data sourcing, settlement, collateral, etc.). - Are designed to be resilient to failure of the Vega chain and operable assuming only the continued existence of an honest quorum of validators (with their private keys) and the multisig control and bridge pool contract holding control over assets on the Ethereum chain. @@ -21,9 +22,9 @@ These features: For Sweetwater, we only require the ability to: 1. Prevent the submission of market creation proposals until a validator initiated and agreed change to the genesis configuration -2. Prevent the submission of asset addition proposals until a validator initiated and agreed change to the genesis configuration -3. Set a date/time before which no market creation proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) -4. Set a date/time before which no asset addition proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) +1. Prevent the submission of asset addition proposals until a validator initiated and agreed change to the genesis configuration +1. Set a date/time before which no market creation proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) +1. Set a date/time before which no asset addition proposal will be enacted as a network parameter (note if the above submission prevention is in place the proposal must still be rejected after this date) At genesis, Sweetwater will be started with only one asset: VEGA. As no new assets can be proposed (limit 2), only VEGA tokens can be deposited or withdrawn via the bridge. There will be no markets at genesis, and due to point 1 above, no markets can be created. @@ -86,10 +87,10 @@ This is primarily for liquidity providers and other sophisticated participants a ## Limitations - These features do not protect against a malicious validator set. -- No attempt is made to prevent sybils with these features, although the ratio between gas fees for deposites and withdrawals and the limits per public key will affect the attractiveness of **any** money making scheme whether by intended or unintended behaviour of the protocol, therefore low limits can provide some level of mitigation here. +- No attempt is made to prevent sybils with these features, although the ratio between gas fees for deposits and withdrawals and the limits per public key will affect the attractiveness of **any** money making scheme whether by intended or unintended behaviour of the protocol, therefore low limits can provide some level of mitigation here. - Users could submit multiple small withdrawals to get around the size limits for delays. To mitigate this, sizes can be set such that gas costs of such an approach would be significant, or to zero so that all withdrawals are delayed. -- -# Network Parameters + +## Network Parameters | Property | Type | Example value | Description | |------------------|--------| ------------|--------------| @@ -108,7 +109,7 @@ This is primarily for liquidity providers and other sophisticated participants a - Any valid market creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) - With `propose_market_enabled_from` set to the past - Any valid market creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) -2. Asset creation can be restricted using genesis configuration (0028-GOVE-025) +1. Asset creation can be restricted using genesis configuration (0028-GOVE-025) - With `propose_asset_enabled` set to true in the genesis configuration - With `propose_asset_enabled_from` set to the future: - Any asset creation proposal is rejected @@ -116,34 +117,33 @@ This is primarily for liquidity providers and other sophisticated participants a - Any valid asset creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) - With `propose_asset_enabled_from` set to the past: - Any valid asset creation proposal is allowed, as per [0028-GOVE](./../protocol/0028-GOVE-governance.md) -3. `propose_market_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) -4. `propose_asset_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) +1. `propose_market_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) +1. `propose_asset_enabled_from` can be changed through a network parameter update proposal (0028-GOVE-008) ### Smart contract criteria -5. `max lifetime deposit` is enforced by the [ERC20 bridge](./../protocol/0031-ETHB-ethereum_bridge_spec.md) (0003-NP-LIMI-001) - - This does not apply to the [governance staking contract](./../glossaries/staking-and-governance.md) - - With an Ethereum address that has never deposited to Vega before: - - A valid deposit transaction that is less than `max lifetime deposit` is not rejected - - A valid second deposit transaction that, in addition to the first TX exceeds `max lifetime deposit` is rejected - - This is true even if both TXs target different [Vega public keys](./../protocol/0017-PART-party.md) - - Withdrawing all funds after the first transaction, then placing a valid second deposit transaction that causes total lifetime deposits to exceed `max lifetime deposit` is still rejected - - A single deposit transaction that is more than `max lifetime deposit` rejected - -6. `max lifetime deposit` can be overridden for specific Ethereum addresses through an Ethereum transaction (0003-NP-LIMI-002) - - An ETH address that is listed on the smart contract as exempt can deposit more than `max lifetime deposit` - - Any ETH address can use a method on the smart contract to add or remove itself (own ETH address) from the exemption list - -7. `max lifetime deposit` can be updated per asset via an Ethereum transaction (0003-NP-LIMI-003) -8. Validators can, via multisig, stop and recommence processing bridge transactions (0003-NP-LIMI-004) - - A representative set of validators can produce a multisig transaction that stops all future deposits and withdrawals - - A representative set of validators can produce a multisig transaction that allows the bridge to resume processing future deposits and withdrawals - - All withdrawals that are submitted while the bridge is 'stopped' are rejected - - All deposits that are submitted while the bridge is 'stopped' are rejected -9. Withdrawal delay network parameter requires a wait between withdrawals creation & submission if it meets or exceeds a threshold (0003-NP-LIMI-005) - - For valid withdrawals that have been approved by validators, when the user submits the TX to the bridge smart contract: - - If the withdrawal amount is below or equal to `withdrawal delay threshold`, the withdrawal is accepted by the bridge smart contract - - If the withdrawal amount is above `withdrawal delay threshold` for the asset, - - If it is submitted before `withdrawal delay period`, it is rejected by the bridge smart contract - - If it is submitted after `withdrawal delay period`, it is accepted by the bridge smart contract - - `withdrawal delay threshold` can be changed, per asset, by multisig control on the bridge contract -10. A withdrawal that is subject to delay can be cancelled by a validator (0003-NP-LIMI-006) + +1. `max lifetime deposit` is enforced by the [ERC20 bridge](./../protocol/0031-ETHB-ethereum_bridge_spec.md) (0003-NP-LIMI-001) + - This does not apply to the [governance staking contract](./../glossaries/staking-and-governance.md) + - With an Ethereum address that has never deposited to Vega before: + - A valid deposit transaction that is less than `max lifetime deposit` is not rejected + - A valid second deposit transaction that, in addition to the first TX exceeds `max lifetime deposit` is rejected + - This is true even if both TXs target different [Vega public keys](./../protocol/0017-PART-party.md) + - Withdrawing all funds after the first transaction, then placing a valid second deposit transaction that causes total lifetime deposits to exceed `max lifetime deposit` is still rejected + - A single deposit transaction that is more than `max lifetime deposit` rejected +1. `max lifetime deposit` can be overridden for specific Ethereum addresses through an Ethereum transaction (0003-NP-LIMI-002) + - An ETH address that is listed on the smart contract as exempt can deposit more than `max lifetime deposit` + - Any ETH address can use a method on the smart contract to add or remove itself (own ETH address) from the exemption list +1. `max lifetime deposit` can be updated per asset via an Ethereum transaction (0003-NP-LIMI-003) +1. Validators can, via multisig, stop and recommence processing bridge transactions (0003-NP-LIMI-004) + - A representative set of validators can produce a multisig transaction that stops all future deposits and withdrawals + - A representative set of validators can produce a multisig transaction that allows the bridge to resume processing future deposits and withdrawals + - All withdrawals that are submitted while the bridge is 'stopped' are rejected + - All deposits that are submitted while the bridge is 'stopped' are rejected +1. Withdrawal delay network parameter requires a wait between withdrawals creation & submission if it meets or exceeds a threshold (0003-NP-LIMI-005) + - For valid withdrawals that have been approved by validators, when the user submits the TX to the bridge smart contract: + - If the withdrawal amount is below or equal to `withdrawal delay threshold`, the withdrawal is accepted by the bridge smart contract + - If the withdrawal amount is above `withdrawal delay threshold` for the asset, + - If it is submitted before `withdrawal delay period`, it is rejected by the bridge smart contract + - If it is submitted after `withdrawal delay period`, it is accepted by the bridge smart contract + - `withdrawal delay threshold` can be changed, per asset, by multisig control on the bridge contract +1. A withdrawal that is subject to delay can be cancelled by a validator (0003-NP-LIMI-006) diff --git a/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md b/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md index 55351b0b6..5ccba9522 100644 --- a/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md +++ b/non-protocol-specs/0007-NP-SNTP-sweetwater_signed_netparams.md @@ -1,11 +1,12 @@ # Network Parameters Signed for Sweetwater There are parameters within Vega that influence the behaviour of the system: + - some are set in genesis block but fixed once network is running, - while others are changeable by on-chain [governance](../protocol/0028-GOVE-governance.md) but initialised to genesis values during network launch. For more info see [network paramters](../protocol/0054-NETP-network_parameters.md) -On [Sweetwater Release](../milestones/2.5-Sweetwater.md) Vega Team wishes to control how certain parameters are initialised while letting validators change others as they see fit. -As the process of decentalisation progresses Vega Team the number of such parameters will be reduced. +On [Sweetwater (Restricted Mainnet) Release](https://github.com/orgs/vegaprotocol/projects/114) Vega Team wishes to control how certain parameters are initialised while letting validators change others as they see fit. +As the process of decentralisation progresses Vega Team the number of such parameters will be reduced. ## Signing @@ -16,8 +17,8 @@ The configuration of the network parameters defined here will be signed and veri The values to be specified as a PR against ??? repo. -TODO: once the repo is chosen put a link here. -TODO: find where `validator min balance` is defined and reference correctly. +`TODO`: once the repo is chosen put a link here. +`TODO`: find where `validator min balance` is defined and reference correctly. | Name | Comment | Suggested value (optional) | |-------------------------------------------------------------|:------------------------------------------------------------------:| :-------------------------:| @@ -25,7 +26,7 @@ TODO: find where `validator min balance` is defined and reference correctly. | `validator min balance` | Not in [network paramters](../protocol/0054-NETP-network_parameters.md) | 3000 VEGA | | `governance.proposal.updateNetParam.requiredMajority` | So that what is set in genesis cannot be changed too easily | 0.5 | | `governance.proposal.updateNetParam.requiredParticipation` | So that what is set in genesis cannot be changed too easily | 0.5 | -| `validators.epoch.length` | Rewards currently make an assumption on epoch lenght, best fix it. | 1 day | +| `validators.epoch.length` | Rewards currently make an assumption on epoch length, best fix it. | 1 day | | `genesis asset section` | Only one asset: VEGA | | | `blockchains.ethereumConfig` | Sets collateral and staking bridge addresses. | | | `network.checkpoint.chainEndOfLifeDate` | Can enforce code upgrade by setting this not too far ahead. | 21 days | diff --git a/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md b/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md index e07077cc8..df25159a0 100644 --- a/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md +++ b/non-protocol-specs/0008-NP-NULB-null_blockchain_vega.md @@ -41,9 +41,7 @@ An extra API is added to allow the user to control the time and block start/end - The null blockchain block time does not control the automatic creation of blocks - With the block time set to `1 second`, if at block height 1 I perform no actions for 5 seconds, the block height will still be 1 (0008-NP-NULB-003) - With the transactions-per-block configuration set to `2` - - If at block height 1 I submit 3 transactions, the block height will have increased to 2 (0008-NP-NULB-004) - - If at block height 1 I submit 1 transaction, the block height will still be 1 (0008-NP-NULB-005) + - If at block height 1 I submit 3 transactions, the block height will have increased to 2 (0008-NP-NULB-004) + - If at block height 1 I submit 1 transaction, the block height will still be 1 (0008-NP-NULB-005) - If at block height 1 I move time forward by 1s, the block height will have increased to 2 (0008-NP-NULB-006) - There is golang example which creates three parties, gives them assets, one party proposes a market and acts as LP, the remaining two parties trade, placing one trade per day for "365 days". The LP party submits a trading terminated transaction after "365 days" and a subsequent settlement price transaction and the market settles. (0008-NP-NULB-007) - - diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 7042b7a0a..62ae33e8f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -277,4 +277,4 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment (and the traded value is the same in both epochs). (0042-LIQF-018) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index dbe9b4bd3..bf2f1f0f2 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -72,8 +72,9 @@ Due to the banning policy this is not doable from one key, but with a sybil atta As unclaimed withdrawals do not automatically expire, an attacker could generate a large number of messages as well as an ever-growing data structure through [withdrawal requests](0030-ETHM-multisig_control_spec.md). -To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWitdrawalQuantumMultiple`. -The minimum allowed withdrawal amount is `spam.protection.minimumWitdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any Vega asset that has a rough value of 1 USD. +To avoid this, all withdrawal requests need a minimum withdrawal amount controlled by the network parameter `spam.protection.minimumWithdrawalQuantumMultiple`. + +The minimum allowed withdrawal amount is `spam.protection.minimumWithdrawalQuantumMultiple x quantum`, where `quantum` is set per [asset](0040-ASSF-asset_framework.md) and should be thought of as the amount of any asset on Vega that has a rough value of 1 USD. Any withdrawal request for a smaller amount is immediately rejected. diff --git a/spellcheck.sh b/spellcheck.sh index 5f0c26bd4..84df29653 100755 --- a/spellcheck.sh +++ b/spellcheck.sh @@ -11,3 +11,7 @@ brew install aspell echo "Running the spell checker..." pyspelling --config spellcheck.yaml + +echo "Remove dictionary binary..." + +rm -r dictionary.dic diff --git a/spellcheck.yaml b/spellcheck.yaml index 27149b6ba..dd46032a7 100644 --- a/spellcheck.yaml +++ b/spellcheck.yaml @@ -6,6 +6,9 @@ matrix: - name: Markdown sources: - 'protocol/*.md' + - 'non-protocol-specs/*.md' + - 'glossaries/*.md' + - 'README.md' default_encoding: utf-8 aspell: d: en_GB @@ -13,7 +16,7 @@ matrix: ignore-case: true dictionary: encoding: utf-8 - output: .pyspelling-custom-md-en.dic.tmp + # output: .pyspelling-custom-md-en.dic.tmp wordlists: - wordlist.txt pipeline: diff --git a/wordlist.txt b/wordlist.txt index f3ee3e846..9b8fac7bd 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -27,6 +27,7 @@ CCP ccy ceil ceiled +CFD CSF checkpointing CLEF @@ -54,6 +55,7 @@ datetime decentralised decentralises decrypt +decrypted decrypts delegateable delegator @@ -61,6 +63,7 @@ delegators deterministically discoverability disincentivise +DLT DPOS durations ECDSA @@ -108,12 +111,14 @@ GTC GTT Gwei hardcoded +Homomorphic HSM HTTP HTTPS IBC incentivise incentivised +incrementing init initialisation initialise @@ -126,12 +131,14 @@ IOC JSON keyholder keypair +keypairs keystore KMS lifecycle linearised linkings linux +Liskov liveness LNL lognormal @@ -145,6 +152,7 @@ margining messager math mempool +Merkle MetaMask microstructure midprice @@ -193,6 +201,7 @@ RPC runnable runtime scalable +scalability Scholes selectable sepolia @@ -214,10 +223,15 @@ SSL suboptimal subtype subtypes +SVTs SweetWater +sybil +sybils tau +TBC Tendermint testnet +testnets TIF tokenholder tokenholders @@ -226,7 +240,9 @@ trackable Tron trustless tx +TXs quant +UI uint unmarshal unamended From 2af392c7d91ce79e53ce17caf0d5e85419581bdf Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 7 Feb 2023 18:00:30 +0000 Subject: [PATCH 006/649] chore: Update cosmicelevator branch from master (#1573) --- .gitignore | 6 +++++ makefile | 26 +++++++++++++------ .../0011-NP-CLIE-client-interaction-tests.md | 21 +++++++++++---- protocol/0029-FEES-fees.md | 6 ++--- ...042-LIQF-setting_fees_and_rewarding_lps.md | 11 ++++---- protocol/0048-DSRI-data_source_internal.md | 1 + protocol/0050-EPOC-epochs.md | 12 ++++----- ...0059-STKG-simple_staking_and_delegating.md | 2 +- protocol/0062-SPAM-spam_protection.md | 4 ++- .../0069-VCBS-validators_chosen_by_stake.md | 20 ++++++++++++-- protocol/0076-DANO-data-node.md | 2 +- 11 files changed, 79 insertions(+), 32 deletions(-) diff --git a/.gitignore b/.gitignore index c612fbd71..590772b83 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,9 @@ .ipynb_checkpoints/ .obsidian/ .vscode/ + +# Used by makefile to clone repos for approbation checks +.build/ + +# Used by ./spellcheck.sh +dictionary.dic diff --git a/makefile b/makefile index 9f36d8ccf..47682edc2 100644 --- a/makefile +++ b/makefile @@ -6,12 +6,14 @@ all: spellcheck markdownlint names codes references links clean # Check that all the specifications are named appropriately .PHONY: names names: - npx @vegaprotocol/approbation check-filenames + @$(MAKE) clone-sources + npx @vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" # Count how many Acceptance Criteria each specification has .PHONY: codes codes: - npx @vegaprotocol/approbation check-codes + @$(MAKE) clone-sources + npx @vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" TEMP=./.build .PHONY:clone-sources @@ -19,12 +21,22 @@ clone-sources: @mkdir -p $(TEMP) @echo "Cloning/updating test repos..." + @echo "===============================" + @echo "" @cd $(TEMP); \ - git -C MultisigControl pull || git clone https://github.com/vegaprotocol/MultisigControl.git & \ - git -C vega pull || git clone https://github.com/vegaprotocol/vega.git & \ - git -C vega_token_v2 pull || git clone https://github.com/vegaprotocol/vega_token_v2.git & \ - git -C staking_bridge pull || git clone https://github.com/vegaprotocol/staking_bridge.git & \ + echo "- MultisigControl"; \ + git -C MultisigControl pull || git clone https://github.com/vegaprotocol/MultisigControl.git; \ + echo "- Vega"; \ + git -C vega pull || git clone https://github.com/vegaprotocol/vega.git; \ + echo "- Vega_token_v2"; \ + git -C vega_token_v2 pull || git clone https://github.com/vegaprotocol/vega_token_v2.git; \ + echo "- staking_bridge"; \ + git -C staking_bridge pull || git clone https://github.com/vegaprotocol/staking_bridge.git; \ + echo "- system-tests"; \ git -C system-tests pull || git clone https://github.com/vegaprotocol/system-tests.git + @echo "" + @echo "===============================" + @echo "" # Which Acceptance Criteria are referenced in which feature files? # Runs make clone-sources in a shell so that it properly waits for them to run in parallel and finish @@ -34,8 +46,6 @@ references: cd $(TEMP); npx -y @vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files - @$(MAKE) clean - # Imperfect, but useful - hence not included in ALL .PHONY: links links: diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index b83585410..cf3e95385 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -8,13 +8,24 @@ This specification contains a set of tests/acceptance criteria that clients (wal 1. The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that: - The new parameter is communicated to and adapted by the wallet, i.e., if a user has too many transactions according to the new parameter, the wallet does not submit transactions with a too low PoW difficulty (either by submitting a PoW of higher difficulty, or by submitting the transactions later). (0011-NP-CLIE-001) -2. The parameter `spam.pow.numberOfTxPerBlock` is increased. Verify that: +1. The parameter `spam.pow.numberOfTxPerBlock` is increased. Verify that: - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This means that a wallet that has had a number of transactions exceeding the previous limit, but not the current one, does not increase the PoW difficulty or delay the transactions (0011-NP-CLIE-002) -3. The parameter `spam.pow.difficulty` is increased. Verify that: +1. The parameter `spam.pow.difficulty` is increased. Verify that: - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-003) -4. The parameter `spam.pow.difficulty` is decreased. Verify that +1. The parameter `spam.pow.difficulty` is decreased. Verify that - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) -5. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that +1. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-005) -6. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that +1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-007) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned.(0011-NP-CLIE-008) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-009) +1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same issue at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-010) +1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-011) +1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-012) +1. Submit one vote less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new simultaneous votes on that issue in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-013) +1. Submit one proposal less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 proposal to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-014) +1. Submit one delegation less than (`SpamProtectionMaxDelegations` = 390) , i.e., 389 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 100 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 delegation to be submitted simultaneously, i.e., cause the account to get blocked. Submit 100 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-015) +1. Create a key with sufficient tokens to be allowed to submit proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the account never gets banned, and that the client never crashed. (0011-NP-CLIE-016) +1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-017) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index df2b0b826..64bef4130 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -94,9 +94,9 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria - Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) -- Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their margin account and the remainder is split between the market making pool and staging pool. (0029-FEES-002) -- Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their margin account and the remainder is split between the market making pool and staging pool. (0029-FEES-003) -- Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their margin account and the remainder is split between the market making pool and staging pool. (0029-FEES-004) +- Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) +- Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) +- Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 62ae33e8f..5c8395d70 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -199,7 +199,8 @@ On every trade, liquidity fee should be collected immediately into an account fo This account is not under control of the LP party (they cannot initiate transfers in or out of the account). The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's margin account for the market. If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. +A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. +If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. @@ -234,9 +235,9 @@ LP 4 els = 0.33 When the time defined by `market.liquidity.providers.fee.distributionTimeStep` elapses we do transfers: ```math -67.275 ETH from LP 1's LP account to LP 1's margin account -25.875 ETH from LP 2's LP account to LP 2's margin account -10.350 ETH from LP 3's LP account to LP 3's margin account +67.275 ETH from LP 1's LP account to LP 1's general account +25.875 ETH from LP 2's LP account to LP 2's general account +10.350 ETH from LP 3's LP account to LP 3's general account ``` ### APIs for fee splits and payments @@ -277,4 +278,4 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment (and the traded value is the same in both epochs). (0042-LIQF-018) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-018) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 7e4fb9210..ffa3333f3 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -122,6 +122,7 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna - update the market to have a time based termination - update the market to have an earlier time based termination - wait until the first timer to tick + - send through valid settlement data - assert the the market settles successfully 1. Time based termination across multiple markets (0048-DSRI-014) - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index 2c439e83a..517da9c74 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -199,15 +199,15 @@ All parameters that are changed through a governance vote are valid starting the Epochs change at the end of the first block that is after the epoch expiry has passed: -- Given an epoch length of `1d`, with a block time of `1h`, at block 1 the current epoch is `1` (0050-EPOC-001) -- Given an epoch length of `1d`, with a block time of `1h`, at end of block 23 the current epoch is `1` (0050-EPOC-002) -- Given an epoch length of `1d`, with a block time of `1h`, at end of block 24 the current epoch is `2` (0050-EPOC-003) +- Given an epoch length of `x`, with a block time arbitrary but `0050-EPOC-001) +- Given an epoch length of `x`, with a block time `x/y`, at end of block `y-1` the current epoch is `1` (0050-EPOC-002) +- Given an epoch length of `x`, with a block time of `x/y`, at end of block `y` the current epoch is `2` (0050-EPOC-003) Edge case: Multiple epochs can pass within the same block (0050-EPOC-004): -- Given an epoch length of `1s`, with a block time of `1m`, at end of block 1 the current epoch is `1` -- Given an epoch length of `1s`, with a block time of `1m`, at end of block 61 the current epoch is `61` - +- Given an epoch length of `x`, with a block time of `x*y`, at end of block 1 the current epoch is `1` +- Given an epoch length of `x`, with a block time of `x*y`, at end of block `y+1` the current epoch is `y+1` + Nomination takes effect at epoch changeover: - During epoch 1, `party 1` nominates any valid amount to `validator 1` diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index b5a4b4838..3cb481662 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -205,7 +205,7 @@ These accounts will be created: - Removal of delegation may happen in the following 2 ways: - Announcing removal, but maintaining stake until last block of the current epoch. This "announced stake" may be then (re)delegated (e.g. to a different validator). (0059-STKG-014) - Announcing removal and withdrawing stake immediately. Rewards are still collected for this stake until the end of the epoch, but they are sent to the on-chain treasury account for that asset. (0059-STKG-015) -- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that this only affects the balance of the current epoch - we don't attempt to reconcile the balance for the next epoch until the epoch ends, so if for example the party had an association of a 100 tokens, then they requested to nominate 100 tokens to `validator1`, their balance for the next epoch would remain 100 until the end of the epoch even if they immediately dissociate the 100 tokens. (0059-STKG-016) +- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that for the current epoch nomination balance we consider the minimum stake that the party had for the duration of the period evaluated (from the beginning of the epoch). Also, for next epoch's nomination balance we consider the current balance of the association. Have one party stake 100 tokens split 70-30 between two validators. With a an epoch of length 5 minutes, at the beginning of the epoch remove 50 tokens off the stake. Within 30 seconds of the confirmation of updated association, verify that the nomination balances for the current epoch and next has been removed with respect to the 70/30 split, such that it is now 35/15. (0059-STKG-016) ### Changing delegation diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index bf2f1f0f2..b6209beaa 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -48,6 +48,8 @@ max_batch_size = 15 // maximal number of transactions allowed (for consistency reasons, the prevailing source for all parameter values is the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go)code file. In case of differences, the information in that file is the valid one). +As (due to Tendermint constraints) it is currently possible to exceed all thresholds within one block, an attacker can always spam one block; to mitigate this, a attacker that does so is temporarily banned. For now, all bans are independent, i.e., a ban due to excessive voting only affects further votes. + - Any tokenholder with more than `min_voting_tokens` tokens on a public key has `num_votes` voting attempts per epoch and proposal, i.e., they can change their mind `num_votes-1` times in one epoch. This means a transaction is pre-block rejected if there are `num_votes` or more on the same proposal in the blockchain in the same epoch, and post_block rejected if there are `num_votes` or more on the same proposal in the blockchain plus earlier in the current block. - Any tokenholder that had more than 50% of its governance transactions post-rejected is banned for max (30 seconds, 1/48 of an epoch) or until the next epoch starts, and all of its governance related transactions (but no trading related transactions) are immediately rejected. E.g., if the epoch duration is 1 day, then the ban period is 30 minutes. If however the epoch is 10 seconds, then the ban period is 30 seconds (or until the start of the next epoch). The test for 50% of the governance transactions is repeated once the next governance related transaction is post-rejected, so it is possible for a violating party to get banned quite quickly again; the test is only done in case of a new post-rejection, so the account does not get banned twice just because the 50% quota is still exceeded when the ban ends. The voting counters are unaffected by the ban, so voting again on a proposal that already had the full number of votes in the epoch will lead to a rejection of the new vote; this is now unlikely to trigger a new ban, as this rejection will happen pre-consensus, and thus not affect the 50% rule. - A proposal can only be issued by a tokenholder with more than `min_proposing_tokens` associated with one public key at the start of the epoch. Also (like above), only `num_proposals` proposals can be made per tokenholder per epoch. For example, every proposal past `num_proposals` in an epoch is rejected by post-block-rejected if the sum of their proposals in past blocks and the ones in the current block exceed `num_proposals`, or pre-block rejected if the sum of proposals already in the blockchain for that epoch equals or exceeds `num_proposals`. This parameter is the same for **all proposals**. There also is a separate parameter to the same end that is enforced in the core. For Sweetwater, both these parameters had the same value, but the spam protection value can be set lower, as the amplification effect of a proposal (i.e., a proposal resulting in a very large number of votes) would also then be covered by the core. @@ -108,7 +110,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - If the ban of a party ends because the epoch ends, transactions from that party are no longer rejected (0062-SPAM-016) - If a party gets banned, the ban ends due to the epoch ending, and it gets banned again at the beginning of the new epoch, the ban still lasts the entire time (or until the next epoch end), i.e., the ban-expiration timer is reset. (0062-SPAM-017) - If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018) -- During a ban due to too many votes, all governance related transactions are rejected (0062-SPAM-019) +- A ban only affects transactions of the type that caused the ban, i.e., a voting ban only affects further votes.(0062-SPAM-019) - After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020) - Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) - Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 60f87a3f2..f76fb16f7 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -420,6 +420,21 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. + 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, + - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) + - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) + - 1 validator drops to the lowest delegated stake (1000) + - 1 ersatz validator has 6000 stake and sufficient `ownstake` + - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. + - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. + 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, + - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) + - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) + - 2 ersatz validators have 6000 stake and sufficient `ownstake` + - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is not removed + - Now reduce the `ownstake` of both ersatz validators and one real validator below the `ownstake` requirement; verify that both ersatz validators are not demoted to pending, and that the tendermint validator is not demoted to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). + - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). + - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators @@ -438,8 +453,8 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled 1. Number of slots decreased (0069-VCBS-052): - - Setup a network with 7 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - - Decrease the number of tendermint validators to 5. + - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). + - Decrease the number of tendermint validators to 3. - Verify that in each of the following two epochs, the validator with the lowest score is demoted to Ersatz validator and an Ersatz validator is demoted to pending 1. Number of Ersatz validators increased (0069-VCBS-058): - Setup a network with 4 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators @@ -522,6 +537,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). 1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. + - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 302716bea..027bb220f 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -190,4 +190,4 @@ It must be possible to add to the data node APIs that return the result of calcu 1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017) 1. All events that are emitted on the full unfiltered event stream are processed by the DataNode (no data is lost) (0076-DANO-018) 1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019) -1. The DataNode must provide its current block height and connection status on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) +1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) From 56aed7d587fd74e86cfe1f6e477cd02548dd1560 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 9 Feb 2023 14:12:20 +0000 Subject: [PATCH 007/649] docs: post only orders (#1562) * docs: Adding specs for post-only orders --- protocol/0014-ORDT-order_types.md | 7 ++++++- protocol/0068-MATC-matching_engine.md | 27 ++++++++++++++++++++++++++- 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 02e0bb991..f8131f5a7 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -42,7 +42,12 @@ Notes on scope of current version of this spec: **Market-state:** 1. **Good For Auction (GFA):** This order will only be accepted by the system if it arrives during an auction period, otherwise it will be rejected. The order can act like either a GTC or GTT order depending on whether the `expiresAt` field is set. -1. **Good For Normal (GFN):** This order will only be accepted by the system if it arrived during normal trading, otherwise it will be rejected. Normal trading is defined as either continuous trading on a normal market or auction trading in a frequent batch auction market. The order can act like either a GTC or GTT order depending on whether the `expiresAt` field is set. +2. **Good For Normal (GFN):** This order will only be accepted by the system if it arrived during normal trading, otherwise it will be rejected. Normal trading is defined as either continuous trading on a normal market or auction trading in a frequent batch auction market. The order can act like either a GTC or GTT order depending on whether the `expiresAt` field is set. + +### Execution flags + +1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees. +1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. ### Valid order entry combinations diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 957c07474..f998c8dca 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -14,6 +14,16 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit - If there is no match the order will be cancelled. (0068-MATC-004) - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057) + +- For Reduce-Only = True orders: + - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-056) + - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-043) + - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-044) + - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-045) + - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-046) + - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-058) + - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-038) A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: @@ -22,6 +32,16 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order - Fully matched if possible to the other side of the book (0068-MATC-009) - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039) + +- For Reduce-Only = TRUE orders: + - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) + - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-048) + - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-049) + - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-050) + - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-051) + - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-052) + - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-053) For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: @@ -29,9 +49,13 @@ For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)]( - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced and placed on the book if the price is valid, except GFN which are rejected by the wallet validation layer. (0068-MATC-015) - otherwise they are parked. (0068-MATC-016) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040) + - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041) + - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042) - A market will enter auction if the volume on either side of the book is empty. (0068-MATC-017) - A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018) - All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019) +- All orders with Reduce-Only set to TRUE are rejected as invalid. (0068-MATC-054) In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): @@ -40,9 +64,10 @@ In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): - [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022) - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023) + - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055) - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are parked (and have their status set to PARKED). (0068-MATC-025) - - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038) + - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-059) When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): From 417eb02c8c851c29e982c0d38921c002f3542ee7 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 3 Mar 2023 09:03:26 +0000 Subject: [PATCH 008/649] Update from master (#1602) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md * Update 0069-VCBS-validators_chosen_by_stake.md Added ACs to match the implementation so its codified (i.e., if an Ersatzvalidator drops below ownstake and there's no-one there to replace it, it is not demoted to pending. * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Update acceptance criteria to correctly reflect implementation (#1549) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * fix: update epoch ACs (#1555) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update 0042, LP fee Transfer, Distribution * Add build folder to gitigore The approbation checks in `makefile` use this folder. Make sure it's not checked in. * Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Ignore dictionary Spellcheck creates a dictionary file. Ensure it isn't committed. * Un parallelise clone-sources in makefile The makefile tried to be clever and run all the remote-repo clones for Approbation checks in parallel. Due to my limited makefile skills, the check could run before a clone was finished. Run them in series instead. This also improves the output a little * Add specs param to names and codes in makefile The old behaviour (default paths) should have been deprecated ages ago, but hasn't been. This change makes it provide the same paths as the defaults. * feat: update maker fee transfer account * Update 0069-VCBS-validators_chosen_by_stake.md * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update 0048-DSRI-data_source_internal.md * fix: refactor 0069-VCBS-052 (#1570) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * fix: MD and spelling lint checks * fix: MD and spelling lint errors * fix: update wording for AC 0059-VCBS-016- (#1566) * Update 0062-SPAM-spam_protection.md (#1571) * Update 0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md (#1542) * Update 0011-NP-CLIE-client-interaction-tests.md Added ACs to test static spam protection (wallet doesn't allow you to get banned) * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update 0011-NP-CLIE-client-interaction-tests.md * chore: fix spelling and MD lint checks --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * Update 0011-NP-CLIE-client-interaction-tests.md (#1579) * refactor: clarify AC * fix: adding bound on slippage part of margin * fix: adding bound on slippage part of margin - ACs * chore: lint * chore: format * chore: add ac codes * chore: lint * feat: make it nonlinear * fix: remove obsolete ac * fix: typo * fix: typo from comments Co-authored-by: Tom * fix: code block in list formatting (#1584) * chore: Remove untestable acceptance criteria * feat: add rate limit spec * Update 0057-TRAN-transfers.md (#1588) * Update 0057-TRAN-transfers.md * Update 0057-TRAN-transfers.md * chore: add AC codes * Update 0057-TRAN-transfers.md (#1590) * Update 0069-VCBS-validators_chosen_by_stake.md Added Acs for IssueSignature * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Expand acceptance criteria to make them clear for 0011-NP-CLIE-client-interaction (#1585) * fix: Expand acceptance criteria to make them clear * chore: Fix formatting * fix: Address review comments --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> * feat: Add new PLUP AC for state-sync in protocol upgrade. * feat: add closeout API * chore: tidy up * chore: remove blank line * chore: by more specific about when a client should be banned * feat: update formula line 140 * fix: Add extra cases for various things that might be affected by validators joining and leaving. * fix: Review comments for new ACs. * fix: Satisfy the linter. * refactor: add slippage to orders * refactor: update examples * chore: fix linter issues * refactor: fix typo * refactor: formlise margin level treatment * refactor: amend/add ACs * Update 0042-LIQF-setting_fees_and_rewarding_lps.md (#1598) * Update 0042-LIQF-setting_fees_and_rewarding_lps.md * fix: linting errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: linting error * fix: MD lint and spelling * Update 0069-VCBS-validators_chosen_by_stake.md (#1604) * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * fix: MD linting and spelling errors --------- Co-authored-by: gordsport * Update 0069-VCBS-validators_chosen_by_stake.md (#1596) * Update 0069-VCBS-validators_chosen_by_stake.md * fix: spelling errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: More validator join/leave test cases involving checkpoints. (#1601) * fix: More validator join/leave test cases involving checkpoints. * fix: spelling error * fix: Update AC codes to not be duplicates. --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update make file and add approabtion to CI (#1605) * feat: update make file and add approabtion to CI * chore: add more checks and fix errors * fix: checkout PR branch * fix: get branch * fix: approbation errors --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: Tom Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett --- .github/workflows/quality_check.yml | 15 ++ makefile | 6 +- .../0011-NP-CLIE-client-interaction-tests.md | 37 ++--- protocol/0007-POSN-non_core_positions_api.md | 3 + protocol/0010-MARG-margin_orchestration.md | 5 + protocol/0012-POSR-position_resolution.md | 2 +- protocol/0019-MCAL-margin_calculator.md | 136 +++++++++--------- ...042-LIQF-setting_fees_and_rewarding_lps.md | 13 ++ protocol/0057-TRAN-transfers.md | 4 +- protocol/0068-MATC-matching_engine.md | 4 +- .../0069-VCBS-validators_chosen_by_stake.md | 87 ++++++++--- protocol/0075-PLUP-protocol_upgrades.md | 1 + protocol/0076-DANO-data-node.md | 16 ++- 13 files changed, 218 insertions(+), 111 deletions(-) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index ed4d24487..d90c2e85a 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -51,3 +51,18 @@ jobs: files: . config_file: .github/workflows/config/markdownlint.json ignore_path: .github/workflows/config/markdownlintignore + + checkcodes: + name: "Approbation" + runs-on: ubuntu-latest + steps: + - name: "Check out" + uses: actions/checkout@v3 + + - name: "Run Check AC codes" + run: | + npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + + - name: "Run Check file names" + run: | + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" diff --git a/makefile b/makefile index 47682edc2..1cafcf49f 100644 --- a/makefile +++ b/makefile @@ -7,13 +7,13 @@ all: spellcheck markdownlint names codes references links clean .PHONY: names names: @$(MAKE) clone-sources - npx @vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" # Count how many Acceptance Criteria each specification has .PHONY: codes codes: @$(MAKE) clone-sources - npx @vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" TEMP=./.build .PHONY:clone-sources @@ -44,7 +44,7 @@ clone-sources: references: @$(MAKE) clone-sources - cd $(TEMP); npx -y @vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files + cd $(TEMP); npx -y github:vegaprotocol/approbation@latest check-references --specs="../*protocol*/*.{md,ipynb}" --tests="./**/*.{js,py,feature}" --categories="../protocol/categories.json" --show-branches --show-mystery --verbose --show-files # Imperfect, but useful - hence not included in ALL .PHONY: links diff --git a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md index cf3e95385..39d3512cb 100644 --- a/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md +++ b/non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md @@ -7,25 +7,28 @@ This specification contains a set of tests/acceptance criteria that clients (wal ## Acceptance criteria 1. The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that: - - The new parameter is communicated to and adapted by the wallet, i.e., if a user has too many transactions according to the new parameter, the wallet does not submit transactions with a too low PoW difficulty (either by submitting a PoW of higher difficulty, or by submitting the transactions later). (0011-NP-CLIE-001) + - The new parameter is communicated to and adapted/used by the wallet, i.e., if a user has too many transactions according to the new parameter, the wallet does not submit the excess transactions and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-001) + - The new parameter is communicated to and adapted/used by the wallet, i.e., if a user has too many transactions according to the new parameter, AND if the parameter `spam.pow.increaseDifficulty` is set to `1`, the wallet submits the excess transactions by submitting a PoW of higher difficulty. (0011-NP-CLIE-002) 1. The parameter `spam.pow.numberOfTxPerBlock` is increased. Verify that: - - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This means that a wallet that has had a number of transactions exceeding the previous limit, but not the current one, does not increase the PoW difficulty or delay the transactions (0011-NP-CLIE-002) + - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. + - This means that a wallet, for each transaction tied to a block with a height lower than the one in which the change happened will honour the previous limit. (0011-NP-CLIE-003) + - This means that a wallet, for each transaction tied to a block with a height higher than the one in which the change happened will honour the new limit. (0011-NP-CLIE-004) 1. The parameter `spam.pow.difficulty` is increased. Verify that: - - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-003) + - This is communicated to the wallet, and the wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-005) 1. The parameter `spam.pow.difficulty` is decreased. Verify that - - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-004) + - This is communicated to the wallet, and the wallet uses these new parameters for each transaction tied to a block with a height higher than the one in which the change happened. (0011-NP-CLIE-006) 1. The parameter `spam.pow.increaseDifficulty` is changed from `0` to `1`. Verify that - - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-005) + - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. This requires the wallet to be subjected to a difficulty increase due to too many messages (0011-NP-CLIE-007) 1. The parameter `spam.pow.decreaseDifficulty` is changed from `1` to `0`. Verify that - - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` PoWs tied to a given block before using another. If this results in none being available the transaction should not be sent. (0011-NP-CLIE-006) -1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-007) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned.(0011-NP-CLIE-008) -1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client delays or removes the transactions to not exceed the transactions-per-block limit and get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-009) -1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same issue at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-010) -1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-011) -1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., cause the account to get blocked.(0011-NP-CLIE-012) -1. Submit one vote less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new simultaneous votes on that issue in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-013) -1. Submit one proposal less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 proposal to be submitted simultaneously, i.e., cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-014) -1. Submit one delegation less than (`SpamProtectionMaxDelegations` = 390) , i.e., 389 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 100 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 delegation to be submitted simultaneously, i.e., cause the account to get blocked. Submit 100 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-015) -1. Create a key with sufficient tokens to be allowed to submit proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the account never gets banned, and that the client never crashed. (0011-NP-CLIE-016) -1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-017) + - This is communicated to the wallet, and wallet uses the new parameter for each transaction tied to a block with a height higher than the one in which the change happened. The wallet should submit no more than `spam.pow.numberofTxPerBlock` number of transactions when tied to a block higher than the one in which the change happened. In case of excess transactions (i.e. greater than `spam.pow.numberofTxPerBlock`), transactions should not be sent and returns an appropriate error message OR reprocesses the transactions. (0011-NP-CLIE-008) +1. Set the parameter `SpamPoWNumberOfPastBlocks` to 10. Send significantly more than `SpamPoWNumberOfTxPerBlock` * `SpamPowNumberOfPastBlocks` (about 100 is a good number) transactions at the same time, and keep sending transactions at a rate of more than 20 in the time a block is processed for at least 10 more blocks. Assure that the user does not get banned, and either sends all transactions eventually, or returns a meaningful error. (0011-NP-CLIE-009) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once. Assure that the client reprocesses the transactions or removes the transactions to not exceed the transactions-per-block limit and hence not get banned.(0011-NP-CLIE-010) +1. Submit significantly (i.e., twice) more than `SpamPoWNumberOfTxPerBlock * SpamPowNumberOfPastBlocks` (currently 200) transactions at once, and keep submitting transactions at a rate of 20 tx per second for at least 10 minutes. Assure that the client reprocesses the transactions or removes the transactions to not exceed the transactions-per-block limit and hence not get banned, and that the client does not crash due to a buffer overload.(0011-NP-CLIE-011) +1. Submit significantly (ten times) more votes than allowed (`SpamProtectionMaxVotes` = 3) for the same proposal at the same time, and verify that the wallet does not allow more than (`SpamProtectionMaxVotes` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-012) +1. Submit significantly (ten times) more proposals than allowed (`SpamProtectionMaxProposals` = 3) at the same time (from an account that has more than `SpamProtectionMinTokensForProposal` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 3) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-013) +1. Submit significantly (ten times) more delegation changes than allowed (`SpamProtectionMaxDelegations` = 390) at the same time (from an account that has more than `SpamProtectionMinTokensForDelegation` tokens), and verify that the wallet does not allow more than (`SpamProtectionMaxProposals` = 390) to be submitted simultaneously, i.e., does not cause the account to get blocked.(0011-NP-CLIE-014) +1. Submit one vote less than (`SpamProtectionMaxVotes` = 3) , i.e., 2 votes in the same epoch. Once all votes are processed, submit 2 new votes at once (still in the same epoch). Verify that the wallet does not allow more than 1 to be submitted simultaneously, i.e., does not cause the account to get blocked. Submit 2 new simultaneous votes on that proposal in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-015) +1. Submit one proposal less than (`SpamProtectionMaxProposals` = 3) , i.e., 2 proposals in an epoch from an account that has more than `SpamProtectionMinTokensForProposal` tokens). Once all proposals are processed, submit 2 new proposals at once (still in the same epoch). Verify that the wallet does not allow more than 1 proposal to be submitted simultaneously, i.e., does not cause the account to get blocked. Submit 2 new proposals at the same time in the next epoch and verify that the wallet allows it (and the account does not get blocked)(0011-NP-CLIE-016) +1. Submit one delegation less than (`SpamProtectionMaxDelegations` = 10) , i.e., 9 delegations in the same epoch from an account that has more than `SpamProtectionMinTokensForDelegation` tokens). Once all delegations are processed, submit 5 new delegations at once (still in the same epoch). Verify that the wallet does not allow more than 1 delegation to be submitted simultaneously, i.e., does not cause the account to get blocked. Submit 10 new delegations at once in the next epoch and verify that the wallet allows it (and the account does not get blocked).(0011-NP-CLIE-017) +1. Create a key with sufficient tokens to be allowed to submit proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. Submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the wallet returns an error for the excess transactions OR reprocesses the transactions. Verify the account never gets banned, and that the client never crashed. (0011-NP-CLIE-018) +1. Create 20 keys with sufficient tokens to be allowed proposals and delegations (i.e., more than `SpamProtectionMinTokensForDelegation` and `SpamProtectionMinTokensForProposal`. For all keys (within their respective wallets), submit random (but valid) votes, delegation changes, transactions and proposals in sets of at least 13 each at the same time, at a rate of one set per second. Let that run for 4 epochs, with an epoch length of at least 100 blocks. Verify that the wallet returns an error for the excess transactions OR reprocesses the transactions. Verify that no account ever gets banned, and that the clients never crash. (0011-NP-CLIE-019) diff --git a/protocol/0007-POSN-non_core_positions_api.md b/protocol/0007-POSN-non_core_positions_api.md index 43fab6c21..a5fa0f244 100644 --- a/protocol/0007-POSN-non_core_positions_api.md +++ b/protocol/0007-POSN-non_core_positions_api.md @@ -12,6 +12,8 @@ The Position API provides access to net position per party per market. Specifica - Uses VW methodology to adjust the realised PnL resulting from any trade that caused volume to have been closed out. (0007-POSN-006) - Stores all traders’ realised PnL for every trade that caused volume to have been closed out. (0007-POSN-007) - Stores all traders' total realised PnL. (0007-POSN-008) +- Stores a status field for all the traders, the status field will be set to ORDERS_CLOSED if a trader was distressed based on the margin requirements for their worst possible long/short, but their margin balance was sufficient to maintain their open position (i.e. their active orders will be removed from the book, after which the party was no longer distressed) (0007-POSN-015) +- The status field will be set to CLOSED_OUT if the party was closed out (0007-POSN-016) ## Summary @@ -58,6 +60,7 @@ The API is expected to expose: - When a party has a position which gets (partially) closed-out, the unrealised PnL should reflect the change of position while the realised PnL reflect the closed-out position (0007-POSN-011) - During settlement, all the parties' position should become 0, unrealised PnL should become 0 and realised PnL should update based on settlement price (0007-POSN-012) - If a party is subject to loss socialisation (its MTM gains get scaled down) the loss amount (forgone profit) should get recorded in realised PnL(0007-POSN-013) +- If a party is subject to loss socialisation, the profits that could not be paid out due to loss socialisation is logged as "loss socialisation amount" which is accessible from API (0007-POSN-014) ## Definitions / glossary diff --git a/protocol/0010-MARG-margin_orchestration.md b/protocol/0010-MARG-margin_orchestration.md index 79acb0ee1..e2129a8eb 100644 --- a/protocol/0010-MARG-margin_orchestration.md +++ b/protocol/0010-MARG-margin_orchestration.md @@ -77,6 +77,11 @@ The protocol compares these levels to the balance in the trader's margin account | greater than _collateral release level_ | Collateral release | Collateral release | greater than _collateral search level_ and less than _initial margin_ | no action | No financial risk to network +When posting a new order the initial margin for the overall position including the new order is calculated and order is only allowed to go ahead if party has enough funds to bring their margin account balance to that figure. An exception to this is when a party has an open position and tries to reduce it, but cannot afford the new margin. Then orders from the opposite side (short orders for a long position, long orders for a short position) are accepted as follows: + +- limit order: accept order when sum sizes of all the party's order's for that side of the book including the one being posted is less than or equal to the absolute open volume that a party has, +- market order: accept order as long as its size is less than or equal to the absolute open volume that a party has. + #### Collateral search When a trader's balance in their margin account (for a market) is less than their position’s collateral search level the protocol will attempt to transfer sufficient collateral from the trader’s main collateral account to top up their margin account to the level of the _initial margin_. diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index b20e732f8..35b2028c7 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -8,7 +8,7 @@ - Mark Price is never updated during position resolution (0012-POSR-004) - Non-distressed traders who trade with the network because their open orders are hit during the close out trade have their positions settled correctly. (0012-POSR-005) - When a distressed party has a [staking account](./0013-ACCT-accounts.md) with the same currency as the settlement currency of the market where it's distressed the staking account is NOT used in margin search and liquidation. (0012-POSR-006) -- When a party is distressed at the point of leaving an auction it should get closed out immediately. (0012-POSR-007) +- When a party is distressed at the point of leaving an auction it should get closed out as soon as the market returns to continuous trading mode and all the parked orders (pegged and LP) get added back to the order book. (0012-POSR-008) ## Summary diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index aed53b19e..74efc324b 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -2,16 +2,43 @@ ## Acceptance Criteria -1. Get four margin levels for one or more parties (0019-MCAL-001) -2. Margin levels are correctly calculated against riskiest long and short positions (0019-MCAL-002) -3. Zero position and zero orders results in all zero margin levels (0019-MCAL-003) -4. If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-004) -5. If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to the *volume weighted price of the order book bids*. (0019-MCAL-005) -6. If `riskiest short < 0` and there are no offers on the order book, the `exit price` is equal to the initial mark price, as set by a market parameter. (0019-MCAL-006) -7. If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < riskiest short`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-007) -8. A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) -9. For each market and each party which has either orders or positions on the market, the API provides the 4 margin levels. (0019-MCAL-009) -10. A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) +- Get four margin levels for one or more parties (0019-MCAL-001) + +- Margin levels are correctly calculated against riskiest long and short positions (0019-MCAL-002) + +- Zero position and zero orders results in all zero margin levels (0019-MCAL-003) + +- If `riskiest long > 0` and there are no bids on the order book, the `exit price` is equal to infinity and hence the slippage cap is used as the slippage component of the margin calculation. (0019-MCAL-014) + +- If `riskiest long > 0 && 0 < *sum of volume of order book bids* < riskiest long`, the `exit price` is equal to infinity. (0019-MCAL-015) + +- If `riskiest short < 0 && 0 < *sum of absolute volume of order book offers* < abs(riskiest short)`, the `exit price` is equal to infinity. (0019-MCAL-016) + +- If `riskiest long > 0 && riskiest long < *sum of volume of order book bids*`, the `exit price` is equal to the *volume weighted price of the order book bids* with cumulative volume equal to the riskiest long, starting from best bid. (0019-MCAL-017) + +- If `riskiest short < 0 && 0 abs(riskiest short) == *sum of absolute volume of order book offers* <`, the `exit price` is equal to the *volume weighted price of the order book offers*. (0019-MCAL-018) + +- A feature test that checks margin in case market PDP > 0 is created and passes. (0019-MCAL-008) + +- For each market and each party which has either orders or positions on the market, the API provides the 4 margin levels. (0019-MCAL-009) + +- A feature test that checks margin in case market PDP < 0 is created and passes. (0019-MCAL-010) + +- If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF short = 0.1` and order book is + + ```book + buy 1 @ 15 000 + buy 10 @ 14 900 + and + sell 1 @ 100 000 + sell 10 @ 100 100 + ``` + + then the maintenance margin for the party is `15 900 x (0.25 x 1 + 0.25 x 1 x 1) + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) + +- In the same situation as above, if `market.maxSlippageFraction[1] = 100`, `market.maxSlippageFraction[2] = 100` (i.e. 10 000% for both) instead, then the margin for the party is `84 100 + 0.1 x 1 x 15900 = 85 690`. (0019-MCAL-012) + +- If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. (0019-MCAL-013) ## Summary @@ -38,6 +65,7 @@ The calculator takes as inputs: - `mark price` - `scaling levels` defined in the risk parameters for a market - `quantitative risk factors` +- `market.maxSlippageFactors` which is a 2 dimensional decimal optional market creation parameter with a default of `[0.1,0.1]` i.e. `[10%,10%]` with the following validation: `0 <= market.maxSlippageFactors[1] <= 1 000 000` and `0 <= market.maxSlippageFactors[2] <= 1 000 000`. Note: `open_volume` may be fractional, depending on the `Position Decimal Places` specified in the [Market Framework](./0001-MKTF-market_framework.md). If this is the case, it may also be that order/positions sizes and open volume are stored as integers (i.e. int64). In this case, **care must be taken** to ensure that the actual fractional sizes are used when calculating margins. For example, if Position Decimals Places (PDP) = 3, then an open volume of 12345 is actually 12.345 (`12345 / 10^3`). This is important to avoid margins being off by orders of magnitude. It is notable because outside of margin calculations, and display to end users, the integer values can generally be used as-is. Note also that if PDP is negative e.g. PDP = -2 then an integer open volume of 12345 is actually 1234500. @@ -75,40 +103,27 @@ If `riskiest long == 0` then `maintenance_margin_long = 0`. In this simple methodology, a linearised margin formula is used to return the maintenance margin, using risk factors returned by the [quantitative model](./0018-RSKM-quant_risk_models.ipynb). -`maintenance_margin_long = maintenance_margin_long_open_position + maintenance_margin_long_open_orders` - with -`maintenance_margin_long_open_position = max(slippage_volume * slippage_per_unit, 0) + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, - -`maintenance_margin_long_open_orders = buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, - -where - -`slippage_volume = max( open_volume, 0 )`, - -and - -if `open_volume > 0` then - -`slippage_per_unit = Product.value(market_observable) - Product.value(exit_price)`, - -else `slippage_per_unit = 0`. +```formula +maintenance_margin_long + = max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + + max(open_volume, 0) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, +``` where -`market_observable` = `settlement_mark_price` if in continuous trading and `indicative_uncrossing_price` if in an auction +`market_observable` = `settlement_mark_price` if in continuous trading, refer to [auction subsection](#margin-calculation-for-auctions) for details of the auction behaviour. `settlement_mark_price` refers to the mark price most recently utilised in [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). If no previous mark to market settlement has occurred, the initial mark price, as defined by a market parameter, should be used. `exit_price` is the price that would be achieved on the order book if the trader's position size on market were exited. Specifically: - **Long positions** are exited by the system considering what the volume weighted price of **selling** the size of the open long position (not riskiest long position) on the order book (i.e. by selling to the bids on the order book). If there is no open long position, the slippage per unit is zero. -- **Short positions** are exited by the system considering what the volume weighted price of **buying** the size of the open short position (not riskiest short position) on the order book (i.e. by buying from the offers (asks) on the order book). If there is no open short position, the slippage per unit is zero. -Note, if there is insufficient order book volume for this `exit_price` to be calculated (per position), the `exit_price` is the price that would be achieved for as much of the volume that could theoretically be closed (in general we expect market protection mechanisms make this unlikely to occur). +- **Short positions** are exited by the system considering what the volume weighted price of **buying** the size of the open short position (not riskiest short position) on the order book (i.e. by buying from the offers (asks) on the order book). If there is no open short position, the slippage per unit is zero. -If there is zero order book volume on the relevant side of the order book to calculate the `exit_price`, the most recent calculation of the mark price, should be used instead. +If there is zero or insufficient order book volume on the relevant side of the order book to calculate the `exit_price`, then take `slippage_per_unit = +Infinity` which means that `min(slippage_volume * slippage_per_unit, mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])) = mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])` above. ### **Step 2** @@ -116,18 +131,14 @@ If `riskiest short == 0` then `maintenance_margin_short = 0`. Else -`maintenance_margin_short = maintenance_margin_short_open_position + maintenance_margin_short_open_orders` - -with - -`maintenance_margin_short_open_position = max(abs(slippage_volume) * slippage_per_unit, 0) + abs(slippage_volume) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` - -`maintenance_margin_short_open_orders = abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]`, +```formula +maintenance_margin_short + = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) + + abs(min( open_volume, 0 )) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] + abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` +``` where meanings of terms in Step 1 apply except for: -`slippage_volume = min( open_volume, 0 )`, - `slippage_per_unit = -1 * (Product.value(market_observable) - Product.value(exit_price) )` ### **Step 3** @@ -138,16 +149,15 @@ where meanings of terms in Step 1 apply except for: We are assuming that: -- `indicative_uncrossing_price` is *not* the mark price, so no mark-to-market transfers happen (update mark-to-market spec) - mark price never changes during an auction, so it's the last mark price from before auction, - during an auction we never release money from the margin account, however we top-it-up as required, - no closeouts during auctions Use the same calculation as above with the following re-defined: -- in `slippage_per_unit` we use `indicative_uncrossing_price` instead of `exit_price`. If there is no `indicative_uncrossing_price` then use `slippage_per_unit = 0`. -- For the open position part of the margin use the mark price. -- For the orders part of the margin: if mark price is not available (as is the case during the opening auction) use `market_observable = indicative_uncrossing_price`. If there is no current `indicative_uncrossing_price`, then use the volume weighted average price of the party's long / short orders. +- For the orders part of the margin: use `market_observable` = volume weighted average price of the party's long / short orders. + +Note that because the order book is empty during auctions we will always end up with the slippage value implied by the the slippage cap. ## Scaling other margin levels @@ -186,10 +196,13 @@ bids: [ {volume: 7, price: $108} ] +market.maxSlippageFraction[1] = 0.25 +market.maxSlippageFraction[2] = 0.001 + risk_factor_short = 0.11 risk_factor_long = 0.1 -last_trade = $144 +mark_price = $144 search_level_scaling_factor = 1.1 initial_margin_scaling_factor = 1.2 @@ -199,21 +212,20 @@ Trader1_futures_position = {open_volume: 10, buys: 4, sells: 8} getMargins(Trader1_position) -riskiest long = max( open_volume + buy_orders, 0 ) = max( 10 + 4, 0 ) = 14 -riskiest short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 +riskiest_long = max( open_volume + buy_orders, 0 ) = max( 10 + 4, 0 ) = 14 +riskiest_short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 # Step 1 ## exit price considers what selling the open position (10) on the order book would achieve. -slippage_per_unit = Product.value(previous_mark_price) - Product.value(exit_price) = Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10) = 144 - 110 = 34 +slippage_per_unit = Product.value(market_observable) - Product.value(exit_price) = Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10) = 144 - 110 = 34 -slippage_volume = max( open_volume, 0 ) = max ( 10, 0 ) = 10 +maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + + max(open_volume, 0 ) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] -maintenance_margin_long = max(slippage_volume * slippage_per_unit, 0) + slippage_volume * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] - -= max(10 * 34, 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 541.6 += max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 # Step 2 @@ -221,13 +233,13 @@ Since riskiest short == 0 then maintenance_margin_short = 0 # Step 3 -maintenance_margin = max ( 541.6, 0) = 541.6 +maintenance_margin = max ( 677.6, 0) = 677.6 # Step 4 -collateral_release_level = 541.6 * collateral_release_scaling_factor = 541.6 * 1.1 -initial_margin = 541.6 * initial_margin_scaling_factor = 541.6 * 1.2 -search_level = 541.6 * search_level_scaling_factor = 541.6 * 1.3 +collateral_release_level = 677.6 * collateral_release_scaling_factor = 677.6 * 1.1 +initial_margin = 677.6 * initial_margin_scaling_factor = 677.6 * 1.2 +search_level = 677.6 * search_level_scaling_factor = 677.6 * 1.3 ``` @@ -248,30 +260,18 @@ riskiest long: 2 riskiest short: -1 -slippage volume long: 1 - -slippage volume short: 0 - #### *case-2* riskiest long: 1 riskiest short: -1 -slippage volume long: 0 - -slippage volume short: -1 - #### *case-3* riskiest long: 1 riskiest short: -1 -slippage volume long: 1 - -slippage volume short: 0 - ## SCENARIOS Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 5c8395d70..ded7ad547 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -271,6 +271,19 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - If a market has `market.liquidity.providers.fee.distributionTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) +### LP JOINING AND LEAVING MARKETS + +- An LP joining a market that is below the target stake with a higher fee bid than the current fee: their fee is used (0042-LIQF-019) +- An LP joining a market that is below the target stake with a lower fee bid than the current fee: fee doesn't change (0042-LIQF-020) +- An LP joining a market that is above the target stake with a sufficiently large commitment to push ALL higher bids above the target stake and a lower fee bid than the current fee: their fee is used (0042-LIQF-029) +- An LP joining a market that is above the target stake with a commitment not large enough to push any higher bids above the target stake, and a lower fee bid than the current fee: the fee doesn't change (0042-LIQF-030) +- An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a lower fee bid than the current fee: the fee changes to the other lower bid (0042-LIQF-023) +- An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a higher fee bid than the current fee: the fee doesn't change (0042-LIQF-024) +- An LP leaves a market that is above target stake when their fee bid is currently being used: fee changes to fee bid by the LP who takes their place in the bidding order (0042-LIQF-025) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size changes the LP that meets the target stake: fee changes to fee bid by the LP that is now at the place in the bid order to provide the target stake (0042-LIQF-026) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't the LP that meets the target stake: fee doesn't change (0042-LIQF-027) +- An LP leaves a market that is above target stake when their fee bid is higher than the one currently being used: fee doesn't change (0042-LIQF-028) + ### API - Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index b327a8015..52bf0480e 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -273,10 +273,10 @@ A user's recurring transfer to a reward account does not occur if there are no p - In the second epoch, 2 * 10^6 trading occurs, and at the end of the epoch the transfer to the reward account occurs - At the end of the third epoch, no transfer occurs -If the network parameter `transfer.minTransferFeeFactor` is modified, this modification is applied +If the network parameter `transfer.fee.factor` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062) -If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied from the next Epoch on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-060) +If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060) If the network parameter `transfer.minTransferQuantumMultiple` is modified, this modification is applied immediately on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-061) diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index f998c8dca..2caf427b2 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -23,7 +23,7 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-045) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-046) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-058) - - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-038) + - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-059) A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: @@ -67,7 +67,7 @@ In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055) - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are parked (and have their status set to PARKED). (0068-MATC-025) - - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-059) + - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038) When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index f76fb16f7..475fb212a 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -33,7 +33,7 @@ Note that we only do this check once per epoch so at most one validator can be c The same way, if there are free slots for ersatz validators and nodes that have submitted the transaction to join and satisfy all joining conditions, they are added as ersatz validators in the next round. -If a node that submitted the transaction to join and satisfies all other conditions and has a higher score than the lowest scoring ersatz validator (scaled up by the incumbent factor), then (assuming it did not just become a Tendermint validator), it becomes an ersatz validator and the lowest scoring ersatz validator is demoted to pending validator. The 'transaction to join' of a validator demoted this way remains active until the delegated stake drops below the required minimum +If a node that submitted the transaction to join and satisfies all other conditions and has a higher score than the lowest scoring ersatz validator (scaled up by the incumbent factor), then (assuming it did not just become a Tendermint validator), it becomes an ersatz validator and the lowest scoring ersatz validator is demoted to pending (also referred to as candidate) validator. The 'transaction to join' of a validator demoted this way remains active until the delegated stake drops below the required minimum As both these checks are done between epochs, it is possible for a validator to be demoted first from a consensus forming (Tendermint) validator to an ersatz validator, and then from an ersatz validator to a pending validator. @@ -107,9 +107,9 @@ In the case where a node is removed due reduced delegation, or due to not meetin Note that this could become obsolete if a future version of the protocol implements threshold signatures or another method that allows all validators to approve Ethereum actions. -## Ersatz validators +## Ersatz/Standby validators -In addition to the normal validators, there is an additional set of Ersatz validators as defined by the corresponding network parameter. These are validators that do not contribute to the chain, but are on standby to jump in if a normal validator drops off. The network will have +In addition to the normal validators, there is an additional set of Ersatz validators (also referred to as Standby Validators) as defined by the corresponding network parameter. These are validators that do not contribute to the chain, but are on standby to jump in if a normal validator drops off. The network will have `n' := ceil(network.validators.multipleOfTendermintValidators x network.validators.tendermint.number)` @@ -397,22 +397,26 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Self-delegate to all of them. - Announce 2 new nodes but self-delegate only to one of them. - Verify that, after 1000 blocks and on the following epoch, only the validator to which we self-delegated got promoted and we now have 4 Tendermint validators and 1 pending validator. -1. Change `ownstake` requirement (0069-VCBS-053) - - Network with 5 tendermint validators and 7 ersatz validators + +### `Ownstake` Scenarios + +1. `Ownstake` scenario1 (0069-VCBS-053) + - Network with 3 tendermint validators and 7 ersatz validators - In the same epoch, change the network parameter `reward.staking.delegation.minimumValidatorStake` in a way that 3 tendermint validators and 3 ersatz validators drop below the `ownstake` requirement, and change the delegation so that 4 (not affected) Ersatz validators have a higher score than two (not affected) Validators. Also, give one of the Ersatz validators with insufficient `ownstake` the highest stake (delegated) of all Ersatz validators. - At the end of the epoch all validators with insufficient own stake will get a ranking score of 0. - No ersatz validator with insufficient stake will get unlisted as ersatz validator - The 3 tendermint validators would be swapped with the top 3 ersatz validators over the following 3 epochs - Also verify that the ersatz validator with the insufficient own but the most delegated stake has a ranking score of 0 and doesn't get promoted. - No validator with stake attached to them is ever completely removed -1. (Alternative until we can build a large enough network for above AC ) (0069-VCBS-059) - 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, +1. `Ownstake` scenario2 (0069-VCBS-073) +Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) - 1 validator drops to the lowest delegated stake (1000) - 1 ersatz validator has 6000 stake and sufficient `ownstake` - the pending validator has sufficient `ownstake` - - Verify that the the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. + - Verify that the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. +1. `Ownstake` scenario3 (0069-VCBS-074) 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -420,6 +424,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. +1. `Ownstake` scenario4 (0069-VCBS-075) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -427,6 +432,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. +1. `Ownstake` scenario5 (0069-VCBS-076) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -435,14 +441,21 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Now reduce the `ownstake` of both ersatz validators and one real validator below the `ownstake` requirement; verify that both ersatz validators are not demoted to pending, and that the tendermint validator is not demoted to ersatz (i.e., tendermint validators are not demoted if there is no appropriate ersatz). - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. + +1. `Ownstake` scenario6 (0069-VCBS-077) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators + +1. `Ownstake` scenario7 (0069-VCBS-078) -Verify that 2 validators are replaced, one in each epoch 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, and higher stake than the validators - Verify that one validator is replaced the following epoch, one in the epoch after + +### Ersatz Rewards + 1. Ersatz validator reward (0069-VCBS-061) - Setup a network with 5 validators with the following distribution of delegation: - 10%, 10%, 10%, 10%. 60% of the total delegation of tendermint validators @@ -452,6 +465,19 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - At the end of the epoch expect the validator with 60% of the stake to be swapped as a tendermint validator for one of the ersatz validators. - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled + +1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) + - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 + - Verify that at the end of the Epoch, the Ersatz Validators get no reward + - Increase the `rewardFactor` to 0.5 + - Verify that at the end of the Epoch, the Ersatz validators get half the reward that the validators get (in total) + - Decrease the `rewardFactor` to 0.4 + - Verify that at the end of the Epoch, the Ersatz validators get 40% of the reward that the validators get (in total) + - Set the `rewardFactor` to 0.32832979375934745648654893643856748734895749785943759843759437549837534987593483498 + - Verify that all validators round the value of reward for the Ersatz validators to the same value. + +### Slot Adjustments + 1. Number of slots decreased (0069-VCBS-052): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Decrease the number of tendermint validators to 3. @@ -478,15 +504,10 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that all Validators round it the same way, and that there are no Ersatz validators - Set the factor to 3.00000000000000000000000000000000000000001 and run the network with just one tendermint (consensus) validator. - Verify that all Validators round it the same way, and that there are three Ersatz validators -1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) - - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 - - Verify that at the end of the Epoch, the Ersatz Validators get no reward - - Increase the `rewardFactor` to 0.5 - - Verify that at the end of the Epoch, the Ersatz validators get half the reward that the validators get (in total) - - Decrease the `rewardFactor` to 0.4 - - Verify that at the end of the Epoch, the Ersatz validators get 40% of the reward that the validators get (in total) - - Set the `rewardFactor` to 0.32832979375934745648654893643856748734895749785943759843759437549837534987593483498 - - Verify that all validators round the value of reward for the Ersatz validators to the same value. + +1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) +1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070). Restart from checkpoint ((0069-VCBS-080)), all validator nodes are still correct. +1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) ### Announce Node @@ -522,6 +543,14 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Restart the network starting only 3 of the validators. - Restore from the checkpoint. - Verify the network is not able to produce blocks. +1. Checkpoints store validator changes (0069-VCBS-079): + - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). + - Stop and relegate one of the original validators (v1) such that v6 is promoted to tendermint validator, and v7 is promoted to ersatz. + - Restart v1 and announce to pending. + - Take a checkpoint. + - Restart the network + - Verify that v2-v6 are tendermint validators, v7 is ersatz and v1 is pending. + - Verify that all stakes and delegations are correct for each node. ### Multisig update @@ -543,3 +572,27 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. 1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) + +### Re-Issuing Signature Bundles by non Validators + +1. Submit two `IssueSignature` requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the result is the same. +(0069-VCBS-081) + +1. Submit two `IssueSignature` requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. +(0069-VCBS-082) + +1. Submit two `IssueSignature` requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. +(0069-VCBS-083) + +1. Submit two `IssueSignature` requests for the same bundle from different Vega keys in different blocks. Verify that both get executed. +(0069-VCBS-084) + +1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 `IssueSignature` requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one `IssueSignature` request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. +(0069-VCBS-085) + +1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. +(0069-VCBS-086) + +1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. +(0069-VCBS-087) diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index 00614548b..0fd167b83 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -156,6 +156,7 @@ For the purposes of protocol upgrade each validator that participates in consens - (0075-PLUP-023) Post a validator becoming a consensus-participating validator they should be immediately allowed to propose an upgrade and be included in the overall total count - (0075-PLUP-024) Ensure that required majority is not met when enough validators join between validator proposals and target block, i.e: In a network with 5 validators, required majority is two thirds, 4 vote to upgrade, 2 more validators join before upgrade block and do not vote. Upgrade does not take place. - (0075-PLUP-025) Node starting from snapshot which has a proposal at a given block, ensure during replay when the block height is reached a new version is loaded and also post load an upgrade takes place at target block. +- (0075-PLUP-045) Arrange a network where n nodes are required for consensus, and at least n+1 nodes in the network. Schedule a protocol upgrade where n-1 nodes automatically start on the new version after upgrade, i.e: No consensus after upgrade. Start the (n+1)th node and consensus is achieved. For the nth node, clear vega and tm, and restart the node using state-sync at the upgrade block height. All nodes produce blocks. ## LNL Checkpoints diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 027bb220f..af5e19252 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -183,11 +183,25 @@ It must be possible to add to the data node APIs that return the result of calcu 2. Standard nodes should retain data in accordance with the configured data retention policy (0076-DANO-027) 3. Archival nodes should retain all data from the height at which they joined the network (0076-DANO-028) +### API Request Rate Limiting + +1. Datanode should provide an optional mechanism for limiting the average number of requests per second over on its API +2. That rate should be specified in the datanode configuration file +3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. (0076-DANO-029) +4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file (0076-DANO-030) +5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031) +6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032) +7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033) +8. If the rate of denied (due to rate limiting) requests subsequently exceed the same maximum rate/burst parameters the client should be banned (0076-DANO-034) +9. The ban denies all access to the API for a configurable length of time (0076-DANO-035) +10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036) +11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037) +12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client (0076-DANO-038) + ### General Acceptance 1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015) 1. The validator node will only accept requests for event bus subscriptions. All other API subscription requests will be invalid. (0076-DANO-016) 1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017) -1. All events that are emitted on the full unfiltered event stream are processed by the DataNode (no data is lost) (0076-DANO-018) 1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019) 1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) From 612fa4fbad3ed4778ca2a1044d79cb6799c55ed0 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 17 Mar 2023 11:52:30 +0000 Subject: [PATCH 009/649] fix: lint errors and duplicate paragraph (#1630) * fix: lint errors and duplicate paragraph * fix: MD lint error --- protocol/0014-ORDT-order_types.md | 5 ----- protocol/0019-MCAL-margin_calculator.md | 3 +-- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 33790cf5a..f8131f5a7 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -49,11 +49,6 @@ Notes on scope of current version of this spec: 1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees. 1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. -### Execution flags - -1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees. -1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. - ### Valid order entry combinations #### Continuous trading diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 63612e37a..0171359cb 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -241,7 +241,6 @@ collateral_release_level = 677.6 * collateral_release_scaling_factor = 677.6 * 1 initial_margin = 677.6 * initial_margin_scaling_factor = 677.6 * 1.2 search_level = 677.6 * search_level_scaling_factor = 677.6 * 1.3 - ``` ### EXAMPLE 2 - calculating correct slippage volume @@ -274,4 +273,4 @@ riskiest short: -1 ## SCENARIOS -Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) \ No newline at end of file +Scenarios found [here](https://docs.google.com/spreadsheets/d/1VXMdpgyyA9jp0hoWcIQTUFrhOdtu-fak/edit#gid=1586131462) From 4be1ba0ab6a3a98c41a553c841637fcc85fa9821 Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Wed, 29 Mar 2023 11:33:15 +0100 Subject: [PATCH 010/649] First draft --- protocol/0000-ETHD-ethereum-data-source.md | 98 ++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 protocol/0000-ETHD-ethereum-data-source.md diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0000-ETHD-ethereum-data-source.md new file mode 100644 index 000000000..8f03fbe9b --- /dev/null +++ b/protocol/0000-ETHD-ethereum-data-source.md @@ -0,0 +1,98 @@ +# Ethereum data source + + +## Summary + +This specification adds a new way of sourcing data from the Ethereum blokchain to allow arbitrary data from the Ethereum blockchain to be ingested as a [data source](./0045-DSRC-data_sourcing.md). +This is in addition to the existing [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md), which is unchanged by this spec. + + +## Description + +Currently, data is sourced from Ethereum only as a result of watching for pre-defined events, on a specific contract, at a specific address. +Namely, the ERC20 bridge contract. +These events are picked up by the [event queue](./0036-BRIE-event_queue.md) processor and submitted by each node as transactions to the Vega chain. +Once a quroum of nodes have ratified the transaction, it is reflected in the Vega state. + +Ethereum data sources extend this in three important ways: + +1. In addition to listening for events defined on a contract, `read` methods can be called on a contract. + +2. The event to listen for or function to be read (along with any parameters that must be passed) are specified as part of the data source, rather than being pre-defined across the whole system. + +3. The address of the contract being observed is also specified as part of the data source. + + +Like all data sources, Ethereum oracles may be subject to filters or other processing or aggregation functions. +Once observed, the data is treated as any other data source and available to any part of the system that accepts a data source as input. +The event queue may evaluate filters before submitting the observation to the Vega chain, in order to avoid submitting transactions containing data that will be dropped due to filters in any case. +Particularly, if the + + +## Functional design + +### Contracts and ABI + +An Ethereum oracle has as its subject a smart contract that is deployed on the Ethereum blockchain. +All such contracts have an address, and an "ABI" that defines the methods an events exposed by the contract. +In order interpret the oracle specification and interact with the smart contract, both the contract address and Ethereum ABI JSON for the contract (or a subset, covering the relevant parts) must therefore be included in the oracle specification. + +Event data and data returned from functions will be emitted by the Ethereum node in an ABI-encoded format. +This data, including any structs should be decoded using the ABI into a JSON-like representation. + +Note: as with any data source containing JSON formatted (or other arbitrary structured) data, the data required by the consumer of the data source may be a fields or sub-objects (including nested fields and objects). +The data sourcing framework therefore requires functionality to apply a query/selector extract the relevant subset of the observed data and pass it to the next consumer. +This would be expected to use JSONPath/JSONPointer or similar, and be applicable to any arbitrary JSON. +Regardless, the specification of this functionaltiy is out of scope for this document and the approach must be standardised across the data sourcing framework (for example, specifiyng the target of filters must use the same format as selecting data to pass on). + + +### Ethereum chain data enrichment + +All data sourced from Ethereum should be structured as an object containing both a payload and Ethereum chain metadata, namely: + +- Ethereum block height at which the data was observed/event ocurred + +- Ethereum block timestamp at which the data was observed/event ocurred + + +These data can be used as the subject of filters or even extracted as the oracle data of interest. +Filters on Ethreum block height, Ethereum timestamp, or Vega timestamp should be applied prior to submitting the data to the Vega chain, in addition to being re-applied when the data is confirmed on chain. +This would prevent spamming the Vega chain with event data that is not relevant. + + +### Events + +When the data source is an event emitted by the Ethereum contract, the event name must be specified in the data source specification. +The specified event must be defined in the supplied ABI. + + +### Contract read + +When the data source is a contract read, the method name and any arguments to be passed must be specified in the data source specification. +The specified method must be defined in the supplied ABI. + + +## Pseudocode examples + +Event data source specification: + +```json +Select { + source: Filter { + source: EthereumEvent { + contract: 0xDEADBEEF + ABI: "...JSON..." + event: "StakeDeposited" + } + where: [ + { selector: '$.ethereum_block_height, condition: '>69420' } + ] + } + selector: '$.amount_deposited' +} +``` + + +## Assessment criteria + +TBD From 77c8577b97d2cb5da20a77857ebc61edad2074cc Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 30 Mar 2023 09:25:20 +0100 Subject: [PATCH 011/649] Chore: Update cosmicelevator from master (#1646) * feat: Add new cases, mostly around eth changes during outages. A few extra cases for PUP. * chore: Linting fixes. * fix: More linting issues. * fix: spelling and AC code lint errors * fix: spelling * feat: Clarifying fees paid (or not paid) by post-only orders (#1635) * chore: remove invalid and unimplemented use cases * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport --------- Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Rado Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0014-ORDT-order_types.md | 2 +- protocol/0019-MCAL-margin_calculator.md | 2 +- .../0069-VCBS-validators_chosen_by_stake.md | 1 + protocol/0073-LIMN-limited_network_life.md | 45 ++++++++++++++--- protocol/0075-PLUP-protocol_upgrades.md | 50 +++++++++++++++++++ user-interface/0001-WALL-wallet.md | 5 -- user-interface/7002-SORD-submit_orders.md | 16 ++++++ user-interface/7003-MORD-manage_orders.md | 3 ++ 8 files changed, 109 insertions(+), 15 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index f8131f5a7..72d9568ca 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -46,7 +46,7 @@ Notes on scope of current version of this spec: ### Execution flags -1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees. +1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees, and will not incur fees in general if executed in continuous trading. It is possible for some liquidity and infrastructure fees to be paid if the resultant limit order trades at the uncrossing of an auction, as specified in [0029-FEES](https://github.com/vegaprotocol/specs/blob/master/protocol/0029-FEES-fees.md#normal-auctions-including-market-protection-and-opening-auctions). 1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. ### Valid order entry combinations diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 6b1e4c976..d521dd40b 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -119,7 +119,7 @@ and if `open_volume > 0` then -`slippage_per_unit = Product.value(market_observable) - Product.value(exit_price)`, +`slippage_per_unit = max(0, Product.value(market_observable) - Product.value(exit_price))`, else `slippage_per_unit = 0`. diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 34c448bbe..ea1270e91 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -104,6 +104,7 @@ Thus a validator who is not there but should be has incentive to pay gas to upda As a consequence, if a potential validator joined the Vega chain validators but has *not* updated the Multisig members (and/or weights) then at the end of the epoch their score will be `0`. They will not get any rewards. In the case where a node is removed due reduced delegation, or due to not meeting self-delegation criteria, or due to lack of performance, or due to a reduction in the value of `network.validators.tendermint.number`, the onus is on all of the remaining validators to remove the demoted member from the Multisig contract. They are incentivised to do so by all receiving a `validator_score` of `0` *in the reward calculation* until the excess member is removed. +Bear in mind that currently in this situation the unpaid rewards stay in the reward pool and eventually everything gets distributed at the end of any epoch where the multisig is updated. Note that this could become obsolete if a future version of the protocol implements threshold signatures or another method that allows all validators to approve Ethereum actions. diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 74c1ac985..7cf68d112 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -233,7 +233,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 4. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. 5. That party has a USD general account balance of 200 USD -### Test case 5: Delegation (test with N=5, 10, 20000) (0073-LIMN-017) +### Test case 5: Add or remove stake during checkpoint restart (0073-LIMN-017) 1. There is a Vega token asset. 1. There are `5` validators on the network. @@ -241,17 +241,17 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There are `N` other parties. Each of the other parties has `other_party_i`, `i=1,2,...,N` has locked exactly `i` tokens on that staking Ethereum bridge and these tokens are undelegated at this point. 1. Other party `i` delegates all its tokens to `validator_party_j` with `j = i mod 5` (i.e. the remainder after integer division of `j` by `i`.). For example if `N=20000` then party `i=15123` will delegate all its `15123` tokens to validator `validator_party_3` since `15123 mod 5 = 3`. 1. The `Staking and delegation` rewards are active so that every hour each party that has delegated tokens receives `0.01` of the delegated amount as a reward. -1. The network runs for 5 hours. 1. Each of the `other_party_i` has Vega token general account balance equal to `5 x 0.01 x i`. Note that these are separate from the tokens locked on the staking Ethereum bridge. -1. Enough time passes after the 5 hour period so that a checkpoint is created and no party submitted any withdrawal transactions throughout. +1. Enough time passes so that a checkpoint is created and no party submitted any withdrawal transactions throughout. 1. The network is shut down. -1. Validator `1` has freed `500` tokens from the Vega Ethereum staking contract. +1. One party `1` with stake delegated has freed `500` tokens from the Vega Ethereum staking contract. +1. One party `2` with stake delegated adds `500` tokens to the Vega Ethereum staking contract. 1. The network is restarted with the same `5` validators and checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. 1. There is a Vega token asset. -1. Validator parties `validator_party_2`,...,`validator_party_5` has `1000` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core. -1. Validator party `validator_party_1` has `500` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core. -1. There are `N` other parties and the delegation info in core says that other party `i` has delegated all its tokens to `validator_party_j` with `j = i mod 5`. -1. Each of the `other_party_i` has Vega token general account balance equal to `5 x 0.01 x i`. Note that these are separate from the tokens locked on the staking Ethereum bridge. +1. Validator parties `validator_party_1`,...,`validator_party_5` has `1000` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core. +1. Other party `1` has `-500` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core, including updated delegation amounts. +1. Other party `2` has `+500` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core, including updated delegation amounts via auto delegation. +1. There are `N-2` other parties and the delegation info in core says that other party `i` has delegated all its tokens to `validator_party_j` with `j = i mod 5`. 1. Each of the `other_party_i` has Vega token general account balance equal to `5 x 0.01 x i`. Note that these are separate from the tokens locked on the staking Ethereum bridge. ### Test case 6: Network Parameters / Exceptional case handling @@ -364,3 +364,32 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - price monitoring bounds (0073-LIMN-071) - oracle settings (0073-LIMN-072) - margin scaling factors (0073-LIMN-073) + +### Test case 19: Deposit tokens during checkpoint restore + +1. On a vega network which has some ERC20 tokens enabled. +1. Wait for a checkpoint to be available for checkpoint restart. +1. Stop the network. +1. Deposit tokens to a vega party via the ERC20 assert bridge. +1. Restart the vega network from the checkpoint created earlier. +1. There party's newly deposited assets are available. (0073-LIMN-074) + +### Test case 20: Multisig updates during checkpoint restart + +1. On a vega network where one validator has been promoted in favour of another (do not update multisig contract to reflect this), and there are tokens in reward accounts ready for distribution. +1. Wait for a checkpoint to be available for checkpoint restart. +1. Retrieve the signatures to update the multisig contract (do not update yet). +1. Stop the network. +1. Update the multisig contract. +1. Restart the vega network from the checkpoint created earlier. +1. Vega observes the multisig change and rewards are paid at the end of the current epoch. (0073-LIMN-075) + +### Test case 21: Loading from checkpoint with invalid multisig + +1. On a vega network where one validator has been promoted in favour of another (do not update multisig contract to reflect this), and there are tokens in reward accounts ready for distribution. +1. Wait for a checkpoint to be available for checkpoint restart. +1. Retrieve the signatures to update the multisig contract (do not update yet). +1. Stop the network. +1. Do not update the multisig contract. +1. Restart the vega network from the checkpoint created earlier. +1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076) diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index 3054b8612..02b640ef8 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -200,3 +200,53 @@ For the purposes of protocol upgrade each validator that participates in consens - (0075-PLUP-042) Trader balances available prior to upgrade is still available post upgrade. - (0075-PLUP-043) Pending and active assets available prior to upgrade is still available post upgrade. - (0075-PLUP-044) Network parameter, market and asset proposals can span a protocol upgrade. + +### Ethereum events during outage + +- (0075-PLUP-051) Deposit events that take place during protocol upgrade are registered by the network once the upgrade is complete. + 1. Schedule an upgrade on a network that is not using visor. + 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. + 1. Deposit tokens via the ERC20 bridge. + 1. Start the network using the upgrade binary. + 1. Balance reported as added in the appropriate account(s). +- (0075-PLUP-052) Staking events that take place during protocol upgrade are registered by the network once the upgrade is complete. + 1. Ensure parties A & B have some stake, which is delegated to a/some node(s). + 1. Schedule an upgrade on a network that is not using visor. + 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. + 1. Add stake to party A. + 1. Remove some (not all) stake from party B. + 1. Start the network using the upgrade binary. + 1. Additional stake reported for party A and auto-delegated. Stake removed for party B and delegation reduced. +- (0075-PLUP-047) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. + 1. Arrange a network where one validator is promoted to replace another validator. Collect signatures to update the multisig contract, but do not yet update the multisig. + 1. Schedule an upgrade on the network (should not be using visor). + 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. + 1. Update the multisig contract to reflect the correct validators. + 1. Start the network using the upgrade binary. + 1. At the end of the current epoch, rewards are paid out. +- (0075-PLUP-048) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. + 1. Arrange a network where one validator is promoted to replace another validator. Collect signatures to update the multisig contract, but do not yet update the multisig. + 1. Schedule an upgrade on the network (should not be using visor). + 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. + 1. Do not update the multisig contract to reflect the correct validators. + 1. Start the network using the upgrade binary. + 1. At the end of the current epoch, rewards are not paid out. + 1. Update the multisig contract to reflect the correct validators. + 1. At the end of the current epoch, rewards are paid out. + +### Transactions during upgrade + +- (0075-PLUP-049) Network handles filled mempool during upgrade. + 1. Schedule a protocol upgrade in a network with no nodes using visor. + 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. + 1. Start one node on the new binary. + 1. Send enough transactions to the node to fill the tendermint mempool. (Expect sane rejection once mempool is full) + 1. Start the other nodes on the correct upgrade binary. + 1. Expect all transactions that reached the mempool without being rejected to be correctly processed over several blocks. +- (0075-PLUP-050) Transactions can be made in block immediately before protocol upgrade. + 1. Schedule a protocol upgrade in a network with no nodes using visor. + 1. Continuously send transactions as the upgrade block approaches. + 1. When the nodes stop processing blocks for the upgrade, make a note of all transactions which reached blocks already (transactions which did not are expected to be discarded). + 1. Shut down the nodes. + 1. Start all nodes on the new binary. + 1. Expect all transactions that reached blocks prior to upgrade to have taken effect. None of the other transactions did. diff --git a/user-interface/0001-WALL-wallet.md b/user-interface/0001-WALL-wallet.md index 1c5290ff0..186e0b992 100644 --- a/user-interface/0001-WALL-wallet.md +++ b/user-interface/0001-WALL-wallet.md @@ -12,7 +12,6 @@ When opening the wallet for the first time, I... - I can restore a wallet from a seed phrase (0001-WALL-004) - I can create a new wallet (0001-WALL-005) - I can view the back up phrase (0001-WALL-006) - - I can view the version number of the algorithm used to derive key pairs from the back up phrase (0001-WALL-007) - I can see the first key without having to "add key". (i.e. The wallet auto generates the first key from the seed phrase) (0001-WALL-008) ...so I can sign transactions @@ -65,7 +64,6 @@ When thinking about a recent or specific transaction, I ... - I can see a history of transactions the wallet has signed. As read from the local app (Current "session" only, as persistent data storage has other requirements (see commented out ACs)) (0001-WALL-034) - I can see pending transactions (Transactions I have not yet confirmed/rejected) (0001-WALL-035) - I can see transactions that were rejected by the wallet user (me) (0001-WALL-037) -- (for tainted keys) I can see attempts to use a tainted key (these did not prompt the user, but allows a user to change permissions) (0001-WALL-038) ... so that I can ensure my wallet is being used appropriately and find transaction I might have missed @@ -82,8 +80,6 @@ When using a Vega wallet, I... - I can create new keys (derived from the source of wallet) (0001-WALL-052) - I can see full public key or be able to copy it to clipboard (0001-WALL-054) - I can change key name/alias (0001-WALL-055) -- I can amend other arbitrary key meta data (0001-WALL-056) -- I can control whether the wallet app queries for data (e.g. asset balances) on each key (to prevent info leaking about what keys belong to a wallet) (0001-WALL-078) ... so I can manage risk (e.g. isolate margin), mitigate the damage of a key being compromised, or use multiple trading strategies @@ -92,7 +88,6 @@ When protecting myself from use of keys that may be compromised, I.. - I can select a key I wish to taint (0001-WALL-057) - I am prompted to enter wallet password to taint key (0001-WALL-058) -- (Dapps that request use of tainted keys **must** not prompt a prompt user to sign transaction) (0001-WALL-059) - I can see tainted keys flagged as tainted (0001-WALL-060) ... so that tainted keys must not be used diff --git a/user-interface/7002-SORD-submit_orders.md b/user-interface/7002-SORD-submit_orders.md index b785c0a15..9f3b05214 100644 --- a/user-interface/7002-SORD-submit_orders.md +++ b/user-interface/7002-SORD-submit_orders.md @@ -114,6 +114,22 @@ When populating a deal ticket I... ... so I can control if and how my order stays on the order book +## Execution flags + +... could select some execution flags. When selecting execution flags (aka order conditions)... + +- **must** see an option to select "Post only" (7003-SORD-054) + - **should** see explanation of what Post only is/does + - **must** see the post only option is unselected and disabled (can not be checked) if the time in force is set to IOC or FOK (7003-SORD-055) + - **must** see an explanation of why the option is disabled (7003-SORD-056) + +- **must** see an option to select "Reduce only" (7003-SORD-057) + - **should** see explanation of what Reduce only is/does (7003-SORD-058) + +- **must** see that selecting "Post only" or "reduce only" de-select the other (if selected). As is it not possibly to apply them both to an order (7003-SORD-059) + +... so I can control in more detail how my order is executed + ## Auto Populating a deal ticket non-manual methods - TODO Populate by selecting a size/price in the order book diff --git a/user-interface/7003-MORD-manage_orders.md b/user-interface/7003-MORD-manage_orders.md index 38e4b0e5e..30d58522d 100644 --- a/user-interface/7003-MORD-manage_orders.md +++ b/user-interface/7003-MORD-manage_orders.md @@ -46,6 +46,8 @@ When looking at a list of orders, I... - Why is the market currently in auction - Link to pegged shape (see below) +- **must** see any [reason (mainnet docs)](https://docs.vega.xyz/mainnet/api/graphql/enums/order-rejection-reason) that has been supplied by the API along with the order status e.g. "Rejected: Due to insufficient margin", "Stopped: Reduce only, would open new volume" (7003-MORD-018) + - **must** see what [market](9001-DATA-data_display.md#market) an order is related to (either code, ID or name, preferable name) (7003-MORD-002) - **should** see what the `status` is of the market (particularly if it is not "normal") - **must** see the [size](9001-DATA-data_display.md#size) of the order (7003-MORD-003) @@ -62,6 +64,7 @@ When looking at a list of orders, I... - if order type = `Market`: **must** not see a price for active or parked orders, a `-`, `Market` or `n/a` is more appropriate (API may return `0`). - **must** see the [time in force](9001-DATA-data_display.md#time-in-force) applied to the order (can be abbreviated here) (7003-MORD-006) +- **must** see if any execution flags (aka conditions. e.g. Post only, Reduce only) were applied to the order (7003-MORD-019) - **should** see "created at" [time](9001-DATA-data_display.md#time) - **could** see updated at (this is used by the system when an order is amended, or repriced (in pegged and LP) not sure this in needed) From 018c4e773993581f094a2f6a15754a9d6fba6e05 Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Mon, 3 Apr 2023 10:15:29 +0100 Subject: [PATCH 012/649] Small fixes plus section on error handling. --- protocol/0000-ETHD-ethereum-data-source.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0000-ETHD-ethereum-data-source.md index 8f03fbe9b..db391b076 100644 --- a/protocol/0000-ETHD-ethereum-data-source.md +++ b/protocol/0000-ETHD-ethereum-data-source.md @@ -25,8 +25,7 @@ Ethereum data sources extend this in three important ways: Like all data sources, Ethereum oracles may be subject to filters or other processing or aggregation functions. Once observed, the data is treated as any other data source and available to any part of the system that accepts a data source as input. -The event queue may evaluate filters before submitting the observation to the Vega chain, in order to avoid submitting transactions containing data that will be dropped due to filters in any case. -Particularly, if the +The event queue may evaluate filters before submitting the observation to the Vega chain, in order to avoid submitting transactions containing data that will be dropped due to filters in any case. ## Functional design @@ -72,6 +71,20 @@ When the data source is a contract read, the method name and any arguments to be The specified method must be defined in the supplied ABI. +## Error checking and handling + +Errors in the data source specification should be caught where possible during validation. +Errors that occur or are detected later (e.g. when data arrives) should not propagate to other parts of the system. +That is, they should be contained within the data sourcing subsystem. +It should be possible to determine if such errors have occurred by listening for events or querying the data source APIs. + +- Attempts to select data from non-existent fields or structures in observed data should be recorded as errors on the event bus and in APIs, and no data should be emitted to the reciever. + +- Incorrect ABI (where this cannot be validated at the time the ABI is submitted) and/or the inability to decode data with the provided ABI should be recorded as errors on the event bus and in APIs, and no data should be emitted to the reciever. + +- A mismatch in data types between a data field and the data required by the receiver should be recorded as errors on the event bus and in APIs, and no data should be emitted to the reciever. + + ## Pseudocode examples Event data source specification: @@ -93,6 +106,6 @@ Select { ``` -## Assessment criteria +## Acceptance criteria TBD From edcc333355a69ca67176c6eca6605baf9ebea49c Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Mon, 3 Apr 2023 10:17:28 +0100 Subject: [PATCH 013/649] Tighten wording --- protocol/0000-ETHD-ethereum-data-source.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0000-ETHD-ethereum-data-source.md index db391b076..77b4356be 100644 --- a/protocol/0000-ETHD-ethereum-data-source.md +++ b/protocol/0000-ETHD-ethereum-data-source.md @@ -74,15 +74,15 @@ The specified method must be defined in the supplied ABI. ## Error checking and handling Errors in the data source specification should be caught where possible during validation. -Errors that occur or are detected later (e.g. when data arrives) should not propagate to other parts of the system. -That is, they should be contained within the data sourcing subsystem. +Errors that occur or are detected later (e.g. when data arrives) must not propagate to other parts of the system. +That is, they must be contained within the data sourcing subsystem. It should be possible to determine if such errors have occurred by listening for events or querying the data source APIs. -- Attempts to select data from non-existent fields or structures in observed data should be recorded as errors on the event bus and in APIs, and no data should be emitted to the reciever. +- Attempts to select data from non-existent fields or structures in observed data should be recorded as errors on the event bus and in APIs, and the system must not emit data to the reciever. -- Incorrect ABI (where this cannot be validated at the time the ABI is submitted) and/or the inability to decode data with the provided ABI should be recorded as errors on the event bus and in APIs, and no data should be emitted to the reciever. +- Incorrect ABI (where this cannot be validated at the time the ABI is submitted) and/or the inability to decode data with the provided ABI should be recorded as errors on the event bus and in APIs, and the system must not emit data to the reciever. -- A mismatch in data types between a data field and the data required by the receiver should be recorded as errors on the event bus and in APIs, and no data should be emitted to the reciever. +- A mismatch in data types between a data field and the data required by the receiver should be recorded as errors on the event bus and in APIs, and the system must not emit data to the reciever. ## Pseudocode examples From c30052512ac7a1faac6fc909c2d6dcc671f9900e Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 17 May 2023 11:27:46 +0100 Subject: [PATCH 014/649] chore: Update cosmicelevator from master (#1699) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * feat: Add new cases, mostly around eth changes during outages. A few extra cases for PUP. * chore: Linting fixes. * fix: More linting issues. * fix: spelling and AC code lint errors * fix: spelling * feat: Clarifying fees paid (or not paid) by post-only orders (#1635) * chore: remove invalid and unimplemented use cases * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport * feat: update FOK MO reduce-only * fix: Add some more cancel order ACs. * Update protocol/0033-OCAN-cancel_orders.md Co-authored-by: Tom * feat: Add a test for checking performance scores when checkpoint rest… (#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces). * feat: Add a test for checking performance scores when checkpoint rest… (#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces). * Update 0069-VCBS-validators_chosen_by_stake.md (#1653) Deleted half an AC as discussed on slack (as the number for the performance score didn't make sense here) * Amend price monitoring ACs (#1660) * refactor: update ACs * chore: tell approbation to leave me alone * chore: try again * refactor: rephrase AC * refactor: clarify * refactor: fix spelling * feat: update datanode spec with functionality to rollback node and functionality to fetch csv files containing network history (#1659) * feat: update datanode spec with functionality to rollback node and functionality to fetch csv files containing network history * fix: spell checker --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * spec: draft for time-based mempool pruning (#1645) * spec: draft for time-based mempool pruning Signed-off-by: Elias Van Ootegem * spec: spelling Signed-off-by: Elias Van Ootegem * Spelling + clarify how block height is determined Signed-off-by: Elias Van Ootegem * spec: add some additional ACs, remove mention of TxV4, clarify that transaction data includes block hash in addition to block height Signed-off-by: Elias Van Ootegem * complete acceptance criteria Signed-off-by: Elias Van Ootegem * fix typo Signed-off-by: Elias Van Ootegem --------- Signed-off-by: Elias Van Ootegem Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * re-word ac * chore: Add decision notes template (#1658) * chore: Add decision notes template Added a decision template based loosely on the [Any Decision Records](https://adr.github.io/madr/) template Also updated some MD linting to allow sibling duplicated header titles and double spacing to make reading easier. * fix: Spelling error * feat: update for distributing remainder of liq fee * fix: correct AC * refactor: address feedback * add spec for current collateral * clarify total margin available * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * add asset file * Add ACs for asset detail dialog and link up with collateral spec * add suggested sort order per account type * fix: 005 AC code link (#1671) * fix: mempool pruning with PoW only * fix: linting errors * refactor: add liquidation price estimate * refactor: add ACs * refactor: another AC * refactor: cosmetic change * Update 0045-DSRC-data_sourcing.md (#1674) * Update 0045-DSRC-data_sourcing.md * Update 0045-DSRC-data_sourcing.md * Wording of timestamp AC --------- Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Barney Mannerings * add spec for current functionality fo fills data grid * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Make notional value of feels a could * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * add clarification on user role for trades during continuos vs auction * fix: typo in ac number * feat: update typo in 0061 * feat: add explaination on ersatz validators * feat: correct typos * feat: typo * Update user-interface/7005-FILL-fills.md * add browser wallet spec as part of approbation set up * chore: fix typo and add browser specs to app.json * chore: add browser wallet to categories, hopefully in the right place * chore: Update 0033-OCAN-cancel_orders.md (#1686) * feat: update BRIE specs (#1654) * feat: update BRIE specs Signed-off-by: Jeremy Letang * chore: update spelling and linting * feat: update BRIE specs Signed-off-by: Jeremy Letang * chore: update spelling and linting * fix: spelling and lint and rebase * fix: spelling --------- Signed-off-by: Jeremy Letang Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * chore: Update cosmic elevator branch from master (#1688) * refactor: let max oi drop during auciton * fix: duplicate AC codes in 0069-VCBS (#1536) (#1537) * Update `cosmicelevator` branch from `master` branch (#1550) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update cosmicelevator branch from master to keep up-to-date (#1560) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * chore: Update cosmicelevator from master branch (#1564) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * chore: Update cosmicelevator branch from master (#1573) * docs: post only orders (#1562) * docs: Adding specs for post-only orders * Update from master (#1602) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md * Update 0069-VCBS-validators_chosen_by_stake.md Added ACs to match the implementation so its codified (i.e., if an Ersatzvalidator drops below ownstake and there's no-one there to replace it, it is not demoted to pending. * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Update acceptance criteria to correctly reflect implementation (#1549) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * fix: update epoch ACs (#1555) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update 0042, LP fee Transfer, Distribution * Add build folder to gitigore The approbation checks in `makefile` use this folder. Make sure it's not checked in. * Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Ignore dictionary Spellcheck creates a dictionary file. Ensure it isn't committed. * Un parallelise clone-sources in makefile The makefile tried to be clever and run all the remote-repo clones for Approbation checks in parallel. Due to my limited makefile skills, the check could run before a clone was finished. Run them in series instead. This also improves the output a little * Add specs param to names and codes in makefile The old behaviour (default paths) should have been deprecated ages ago, but hasn't been. This change makes it provide the same paths as the defaults. * feat: update maker fee transfer account * Update 0069-VCBS-validators_chosen_by_stake.md * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update 0048-DSRI-data_source_internal.md * fix: refactor 0069-VCBS-052 (#1570) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * fix: MD and spelling lint checks * fix: MD and spelling lint errors * fix: update wording for AC 0059-VCBS-016- (#1566) * Update 0062-SPAM-spam_protection.md (#1571) * Update 0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md (#1542) * Update 0011-NP-CLIE-client-interaction-tests.md Added ACs to test static spam protection (wallet doesn't allow you to get banned) * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update 0011-NP-CLIE-client-interaction-tests.md * chore: fix spelling and MD lint checks --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * Update 0011-NP-CLIE-client-interaction-tests.md (#1579) * refactor: clarify AC * fix: adding bound on slippage part of margin * fix: adding bound on slippage part of margin - ACs * chore: lint * chore: format * chore: add ac codes * chore: lint * feat: make it nonlinear * fix: remove obsolete ac * fix: typo * fix: typo from comments Co-authored-by: Tom * fix: code block in list formatting (#1584) * chore: Remove untestable acceptance criteria * feat: add rate limit spec * Update 0057-TRAN-transfers.md (#1588) * Update 0057-TRAN-transfers.md * Update 0057-TRAN-transfers.md * chore: add AC codes * Update 0057-TRAN-transfers.md (#1590) * Update 0069-VCBS-validators_chosen_by_stake.md Added Acs for IssueSignature * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Expand acceptance criteria to make them clear for 0011-NP-CLIE-client-interaction (#1585) * fix: Expand acceptance criteria to make them clear * chore: Fix formatting * fix: Address review comments --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> * feat: Add new PLUP AC for state-sync in protocol upgrade. * feat: add closeout API * chore: tidy up * chore: remove blank line * chore: by more specific about when a client should be banned * feat: update formula line 140 * fix: Add extra cases for various things that might be affected by validators joining and leaving. * fix: Review comments for new ACs. * fix: Satisfy the linter. * refactor: add slippage to orders * refactor: update examples * chore: fix linter issues * refactor: fix typo * refactor: formlise margin level treatment * refactor: amend/add ACs * Update 0042-LIQF-setting_fees_and_rewarding_lps.md (#1598) * Update 0042-LIQF-setting_fees_and_rewarding_lps.md * fix: linting errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: linting error * fix: MD lint and spelling * Update 0069-VCBS-validators_chosen_by_stake.md (#1604) * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * fix: MD linting and spelling errors --------- Co-authored-by: gordsport * Update 0069-VCBS-validators_chosen_by_stake.md (#1596) * Update 0069-VCBS-validators_chosen_by_stake.md * fix: spelling errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: More validator join/leave test cases involving checkpoints. (#1601) * fix: More validator join/leave test cases involving checkpoints. * fix: spelling error * fix: Update AC codes to not be duplicates. --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update make file and add approabtion to CI (#1605) * feat: update make file and add approabtion to CI * chore: add more checks and fix errors * fix: checkout PR branch * fix: get branch * fix: approbation errors --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: Tom Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett * fix: lint errors and duplicate paragraph (#1630) * fix: lint errors and duplicate paragraph * fix: MD lint error * Chore: Update cosmicelevator from master (#1646) * feat: Add new cases, mostly around eth changes during outages. A few extra cases for PUP. * chore: Linting fixes. * fix: More linting issues. * fix: spelling and AC code lint errors * fix: spelling * feat: Clarifying fees paid (or not paid) by post-only orders (#1635) * chore: remove invalid and unimplemented use cases * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport --------- Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Rado Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --------- Co-authored-by: Witold Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: Tom Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett Co-authored-by: Rado Co-authored-by: Michael * fix: fix prefix for browser wallet * chore: fixed wrong file.. * chore: now undo my formatting for the other file * chore: undo formatting change * add missing AC * add more ac * typoe * chore: add ac for the sprint --------- Signed-off-by: Elias Van Ootegem Signed-off-by: Jeremy Letang Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Rado Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: Matthew Pendrey Co-authored-by: Elias Van Ootegem Co-authored-by: Charlie Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> Co-authored-by: Matthew Russell Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Barney Mannerings Co-authored-by: daro-maj <119658839+daro-maj@users.noreply.github.com> Co-authored-by: dalebennett1992 Co-authored-by: dalebennett1992 <37066267+dalebennett1992@users.noreply.github.com> Co-authored-by: Jeremy Letang Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: RomanLeca Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: Edd Co-authored-by: claudiumilea Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> --- .github/workflows/config/markdownlint.json | 9 +- 0000-TEMP-template-notes.md | 52 ++++++ ...0012-NP-LIPE-liquidation-price-estimate.md | 60 ++++++ protocol/0019-MCAL-margin_calculator.md | 1 - protocol/0032-PRIM-price_monitoring.md | 6 +- protocol/0033-OCAN-cancel_orders.md | 3 + protocol/0036-BRIE-event_queue.md | 172 +++++++++--------- ...042-LIQF-setting_fees_and_rewarding_lps.md | 12 +- protocol/0045-DSRC-data_sourcing.md | 4 + protocol/0061-REWP-pos_rewards.md | 8 +- protocol/0068-MATC-matching_engine.md | 2 +- .../0069-VCBS-validators_chosen_by_stake.md | 12 +- protocol/0072-SPPW-spam-protection-PoW.md | 13 ++ protocol/0075-PLUP-protocol_upgrades.md | 2 +- protocol/0076-DANO-data-node.md | 2 + .../0004-EWAL-connect_ethereum_wallet.md | 3 +- user-interface/1101-BWAL-browser_wallet.md | 118 ++++++++++++ user-interface/6501-ASSE-assets.md | 21 +++ user-interface/7001-COLL-collateral.md | 29 ++- user-interface/7005-FILL-fills.md | 20 +- user-interface/apps.json | 3 + user-interface/categories.json | 22 +-- wordlist.txt | 3 + 23 files changed, 463 insertions(+), 114 deletions(-) create mode 100644 0000-TEMP-template-notes.md create mode 100644 non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md create mode 100644 user-interface/1101-BWAL-browser_wallet.md create mode 100644 user-interface/6501-ASSE-assets.md diff --git a/.github/workflows/config/markdownlint.json b/.github/workflows/config/markdownlint.json index ea3d61a0c..4db16e28b 100644 --- a/.github/workflows/config/markdownlint.json +++ b/.github/workflows/config/markdownlint.json @@ -1,9 +1,14 @@ - { "default": true, "line-length": false, "commands-show-output": false, "no-bare-urls": true, "no-inline-html": false, - "no-hard-tabs": false + "no-hard-tabs": false, + "MD012": { + "maximum": 2 + }, + "MD024": { + "siblings_only": true + } } diff --git a/0000-TEMP-template-notes.md b/0000-TEMP-template-notes.md new file mode 100644 index 000000000..6159fdb77 --- /dev/null +++ b/0000-TEMP-template-notes.md @@ -0,0 +1,52 @@ +# 0000-TEMP decision notes + +## Context / Problem Statement 1 + +| Opened | Last updated | Status | +|:----------:|:------------:|:------------:| +| DD/MM/YYYY | DD/MM/YYYY | open/resoved | + +Describe the context and problem statement... + +### Considered Options + +* Option 1... +* Option 2... + +### Decision Outcome + +Chosen option: Option X, because... (include why paramemters are chosen, any dependancies and / or assumptions this decision is based upon) + +### Open risks + +* Risk 1 - details any risks or gaps that are not yet resolved + +### Limitations + +Are there any issues we wanted to address but could not e.g., A core rewrite or CometBFT limtitaion + + +## Context / Problem Statement 2 + +| Opened | Last updated | Status | +|:----------:|:------------:|:------------:| +| DD/MM/YYYY | DD/MM/YYYY | open/resoved | + +Describe the context and problem statement... + +### Considered Options + +* Option 1... +* Option 2... + +### Decision Outcome + +Chosen option: Option X, because... (include why paramemters are chosen, any dependancies and / or assumptions this decision is based upon) + +### Open risks + +* Risk 1 - details any risks or gaps that are not yet resolved + +### Limitations + +Are there any issues we wanted to address but could not e.g., A core rewrite or CometBFT limtitaion diff --git a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md new file mode 100644 index 000000000..1debadacf --- /dev/null +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -0,0 +1,60 @@ +# Liquidation price estimate + +## Summary + +Provide an estimate of the price range at which the liquidation of a specified position is likely to occur. + +## Overview + +Provide a range of liquidation price, where the lower bound assumes no slippage in the [margin level calculation](../protocol/0019-MCAL-margin_calculator.md) and the upper bound assumes that the slippage cap is applied. + +This amounts to carrying out the same computation twice, once with both linear and quadratic slippage factor set to `0` and once with the actual values used by the market for which the specified position is being considered. + +The system carries out [position resolution](../protocol/0012-POSR-position_resolution.md) when the available collateral (amount in margin account for the market along with amount in the general account denominated in the same asset) is less than the maintenance margin level for the position. The first step is to cancel any open orders that a distressed party may have. After that the margin requirement is re-evaluated to see if the position is still distressed. Therefore we provide three sets of estimates of a liquidation price range: current open volume only, current open volume with active buy orders, current open volume with active sell orders. + +## Calculation + +### Position only + +We start with the case which estimates the liquidation price given the current open volume and ignoring any orders a party may have. We need to keep in mind that as the mark price moves the maintenance margin changes and the collateral available a party has changes due to [mark to market](../protocol/0003-MTMK-mark_to_market_settlement.md) gains/losses. Therefore, to estimate the liquidation price we need to find $S^{\text{liquidation}}$ such that: + +$$ +\text{collateral available} + V(S^{\text{liquidation}}-S^{\text{current}}) = \text{maintenance margin}(S^{\text{liquidation}}), +$$ + +where $V$ is the open volume (negative for a short position) and $S^\text{current}$ is the current mark price. + +We assume margin is calculated as per continuous trading formula (as there are no closeouts in auctions) and that the slippage cap always applies, therefore we get: + +$$ +\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}), +$$ + +where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. Solving for $S^{\text{liquidation}}$ we get: + +$$ +S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V} +$$ + +if the denominator in the above expression evaluates to $0$ the liquidation price is undefined and we return an error, otherwise we return the result floored at $0$ (as the negative price is not attainable for any of the currently supported products). + +### Including orders + +When including orders we sort the orders in the order they will get filled in (descending for buy orders, ascending for sell orders) and assume any market orders get filled instantaneously at the current mark price. Then separately for each side: + +- Calculate open volume with including the remaining volume of all the market orders for a given side ($V$) and calculate the liquidation price ($S^{\text{liquidation}}$) using the formula outlined above and the current mark price or indicative uncrossing price if market is in auction ($S^{\text{current}}$). +- For each limit order: + - if the order price ($S^{\text{order}}$) is above (buy side) / below (sell side) the liquidation price ($S^{\text{liquidation}}$): + - recalculate $V$ to include the order's remaining volume (assumes order gets filled as soon as its price level is filled), + - update $\text{collateral available}$ to include the MTM gains/losses: $V(S^{\text{order}}-S^{\text{current}})$, + - update $S^{\text{current}}$ to equal $S^{\text{order}}$, + - otherwise return last calculated $S^{\text{liquidation}}$ (assumes other orders will get cancelled and the remaining position will be liquidated). + +### Acceptance criteria + +1. An estimate is obtained for a long position with no open orders, mark price keeps going down in small increments and the actual liquidation takes place within the estimated range. (0012-NP-LIPE-001) +1. An estimate is obtained for a short position with no open orders, mark price keeps going up in small increments and the actual liquidation takes place within the estimated range. (0012-NP-LIPE-002) +1. An estimate is obtained for a position with no open volume and a single limit buy order, after the order fills the mark price keeps going down in small increments and the actual liquidation takes place within the obtained estimated range. (0012-NP-LIPE-003) +1. An estimate is obtained for a long position with multiple limit sell order with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with sell orders is higher than that for the open volume only. As the limit orders get filled the estimated liquidation price for the (updated) open volume converges to the estimate originally obtained with open sell orders. (0012-NP-LIPE-004) +1. An estimate is obtained for a short position with multiple limit sell order with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with sell orders is lower than that for the open volume only. As the limit orders get filled the estimated liquidation price for the (updated) open volume converges to the estimate originally obtained with open sell orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with sell orders) (0012-NP-LIPE-005) +1. There's no difference in the estimate for an open volume and that with `0` open volume and market order of the same size. (0012-NP-LIPE-006) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index d521dd40b..83d25ec02 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -236,7 +236,6 @@ slippage_per_unit = Product.value(market_observable) - Product.value(exit_price maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + max(open_volume, 0 ) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] - = max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 # Step 2 diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 7dc3b3109..0bbf71e76 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -87,7 +87,7 @@ Specifically: to the risk model and obtains the range of valid up/down price moves per each of the specified triggers. Please note that these can be expressed as either additive offsets or multiplicative factors depending on the risk model used. The reference price is the latest price such that it's at least τ old or the earliest available price should price history be shorter than τ. - It holds the history of volume weighted average prices looking back to the maximum τ configured in the market. - Every time a new price is received from the matching engine the price monitoring engine checks all the [τ, up factor, down factor] triplets relevant for the timestamp, looks-up the associated past (volume weighted) price and sends the signal back to the matching engine informing if the received price would breach the min/max move prescribed by the risk model. -- The bounds corresponding to the current time instant and the arrival price of the next transaction will be used to indicate if the price protection auction should commence, and if so, what should its' period be (see below). +- The bounds corresponding to the current time instant and the arrival price of the next transaction will be used to indicate if the price protection auction should commence. The triggers are sorted by period τ (increasing order) and probability level (decreasing order). As soon the first bound is violated the price monitoring auction with the extension period defined for the corresponding trigger is initiated. After that period elapses the indicative uncrossing price is checked against the remaining bounds and auction gets extended if another bound is violated. The process is repeated until the uncrossing price satisfies all the remaining bounds or there are no active triggers left. - To give an example, with 3 triggers the price protection auction can be calculated as follows: - \>=1% move in 10 min window -> 5 min auction, - \>=2% move in 30 min window -> 15 min auction (i.e. if after 5 min this trigger condition is satisfied by the price we'd uncross at, extend auction by 10 minutes), @@ -110,10 +110,8 @@ to the risk model and obtains the range of valid up/down price moves per each of ## Acceptance Criteria - Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001) -- Persistent order results in an auction (2 out of 2 triggers breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-002) - Non-persistent order does not result in an auction (1 out of 2 triggers breached), order gets cancelled (never makes it to the order book) (0032-PRIM-003) -- Persistent order results in an auction (2 out of 2 triggers breached), more orders placed during auction, auction concludes after the combined `auctionExtension` time from both triggers elapses. (0032-PRIM-004) - The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005) - Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006) - A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007) @@ -129,3 +127,5 @@ to the risk model and obtains the range of valid up/down price moves per each of - Specifying a non-positive auction extension results in an error. (0032-PRIM-017) - Settlement price outside the current price monitoring bounds does not trigger an auction (0032-PRIM-018) - A network trade (during closeout) with a price outside price monitoring bounds does not trigger an auction. (0032-PRIM-019) +- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020) +- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021) diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index cd137d1a6..1a8670988 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -8,6 +8,9 @@ - Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004) - A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005) - Margins must be recalculated after a cancel event (0033-OCAN-007) +- An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008) +- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009) +- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010) ## Summary diff --git a/protocol/0036-BRIE-event_queue.md b/protocol/0036-BRIE-event_queue.md index dd13f8c2c..ca9c25670 100644 --- a/protocol/0036-BRIE-event_queue.md +++ b/protocol/0036-BRIE-event_queue.md @@ -2,65 +2,46 @@ ## Summary -Latency and throughput is of paramount importance to Vega validator nodes, so monitoring various 3rd party (and notably low transaction speed) blockchains and crypto-assets isn’t possible. -To counter this problem we have created an event queue management system. -This event queue allows the standardisation and propagation of transactions from 3rd party asset chains in the Vega event message format. +The vega network relies solely on other networks for issuing the of coins or tokens that are used for settlement. Because of this, bridges controlled by the Vega network are created on these external chains (as of the first Alpha Mainnet deployment only ERC-20 tokens are supported via a bridge to the Ethereum chain). + +In order for these bridges to operate correctly and for Vega to reflect their activity, each validator node embeds mechanisms to source, validate and monitor activity on these bridges. ## Guide-level explanation -Events and transactions are gathered and processed by the Event Queue from a given 3rd party blockchain, and only the ones subscribed to by Vega nodes will be propagated through consensus and then validated by the validator nodes. -The Event Queue continually scans local or hosted external blockchain nodes to discover on-chain events that are applicable to Vega. -Found external blockchain events are then sent to Vega validator nodes. -This makes the event queue works as a buffer between the slow/complicated world of various blockchains, and the high throughput, low latency of Vega Core. -This message queue will use gRPC to communicate with the Vega network via 3 main functions: +As of the first Alpha Mainnet deployment, four contracts are being monitored by the Vega network: -1. `GetSubscribedEventSources` returns a list of smart contract addresses and events that consensus has deemed as a valid source. -1. `PropagateChainEvent` allows an event queue to send events raised on 3rd party blockchains (deposits, withdrawals, etc) through Vega consensus to ensure an event has been seen by the network. This function must support multiple blockchains as sources of events and multiple sources on a single blockchain (such as multiple deployments of an ERC20 bridge). - - Each validator will individually process and validate the given transaction and process the specified event reported using their local chain node (such as Ethereum). -1. `GetEventAcceptanceStatus` returns the consensus acceptance status of a requested event. The event queue uses this function to determine if it should attempt to send the event again. +- ERC-20 collateral bridge +- staking contract +- vesting contract +- multisig control contract -## Reference-level explanation +Every time a method is being called successfully on these contracts (for example a deposit on the collateral bridge) an event is emitted by the smart contract. The validator nodes will be monitoring all blocks created by Ethereum, and be looking for this event. This process is the sourcing of events. -- The event queue calls `GetSubscribedEventSources` on a Vega node to get the list of subscribed smart contracts -- Using configured external blockchain nodes, the Event Queue filters for specific events provided in `GetSubscribedEventSourcesResponse` -- For each event it calls `GetEventAcceptanceStatus` on a Vega node -- Event Queue then creates an `PropagateChainEventRequest` for each applicable event that has yet to be accepted and submits them to `PropagateChainEvent` on a Vega validator node -- Vega validators each verify each event against local external blockchain nodes as the event is gossiped -- Consensus agrees and writes event into the Vega chain +Once an event has been sourced by a validator, it will be forwarded to the other validators in the network under the form of a vega transaction. -## Pseudo-code / Examples +Upon receipt of the event, and confirmation it was sent by a legitimate validator node, the other validators will then try to find and verify the same event on the external chain. -The protobuf of the service: +Once all validators have confirmed the event happened on the external chain, the action will be executed on the network (in the case of the deposit, the funds will be deposited into an account). -```proto +## Reference-level explanation -service trading{ - /*....*/ - rpc PropagateChainEvent(PropagateChainEventRequest) returns (PropagateChainEventResponse); - rpc GetSubscribedEventSources() returns (GetSubscribedEventSourcesResponse); - rpc GetEventAcceptanceStatus(GetEventAcceptanceStatusRequest) returns (GetEventAcceptanceStatusResponse); - /*....*/ -} +### Smart contracts in use -message GetSubscribedEventSourcesResponse { - repeated string subscribed_event_source = 1; -} +All the smart contracts monitored by the validator nodes are defined in the `ethereumConfig` network parameter. Along with the contract itself, the creation time of the contract is required for the very first launch of the network. This is required in order for the validator nodes to poll all blocks since the creation of the contract. +Later on in the life of the network, this information is stored in the snapshot state / checkpoint with last sourced block on Ethereum to avoid interpreting events twice. -message PropagateChainEventRequest { - // The event - vega.ChainEvent evt = 1; - string pubKey = 2; - bytes signature = 3; -} +Finally, the amount of confirmations expected for Ethereum is specified, this is set to 50 confirmation in mainnet. -// The response for a new event sent to vega -message PropagateChainEventResponse { - // Did the event get accepted by the node successfully - bool success = 1; -} +### Event sourcing + +Every validator node needs a constant connection to an Ethereum archival node. This allows the node to poll for Ethereum blocks as they are constructed, and scan for events emitted by the contracts related to the Vega network. +The core node will look for new blocks on Ethereum every 10 to 15 seconds. Once a relevant event is found, the block, log index and transaction hash are extracted from it. A `ChainEvent` transaction is constructed then forwarded to the rest of the nodes through the Vega chain. +Simplified chain event transaction: + +```proto // An event being forwarded to the vega network // providing information on things happening on other networks message ChainEvent { @@ -69,10 +50,9 @@ message ChainEvent { string txID = 1; oneof event { - BuiltinAssetEvent builtin = 1001; ERC20Event erc20 = 1002; - BTCEvent btc = 1003; ValidatorEvent validator = 1004; + // more in the future } } @@ -125,47 +105,77 @@ message ERC20Withdrawal { // The reference nonce used for the transaction string referenceNonce = 4; } +``` -message GetEventAcceptanceStatusRequest { - string transaction_hash = 1; - uint32 log_index = 2; -} +### Event validation -//can be expanded as needed -enum EventAcceptanceStatus { - EVENT_ACCEPTANCE_STATUS_UNSPECIFIED = 0; - EVENT_ACCEPTANCE_STATUS_ACCEPTED = 1; - EVENT_ACCEPTANCE_STATUS_REJECTED = 2; -} +Once the `ChainEvent` transaction is received by the other validator nodes a routine is started internally to verify the events. + +Specifically the nodes will: + +- Find the event for the contract address, transaction hash, block and event log. +- Ensure this event has not been seen before +- Ensure that the required number of confirmations has been seen on the network -message GetEventAcceptanceStatusResponse { - string transaction_hash = 1; - uint32 log_index = 2; - EventAcceptanceStatus acceptance_status = 3; +As soon as the validator nodes confirm the event, they emit a new transaction in the Vega network to confirm the event is legitimate and it can be processed. + +As soon as the protocol receive 2/3 of the votes for the event, the corresponding action related to this event will be executed (e.g., funding an account in the case of a deposit). The confirmation of each validator is weighted with the validator power. + +Example of the node vote transaction: + +```proto +// Used when a node votes for validating that a given resource exists or is valid, +// for example, an ERC20 deposit is valid and exists on ethereum. +message NodeVote { + // Reference, required field. + string reference = 2; + // type of NodeVote, also required. + Type type = 3; + enum Type { + // Represents an unspecified or missing value from the input + TYPE_UNSPECIFIED = 0; + // A node vote a new stake deposit + TYPE_STAKE_DEPOSITED = 1; + // A node vote for a new stake removed event + TYPE_STAKE_REMOVED = 2; + // A node vote for new collateral deposited + TYPE_FUNDS_DEPOSITED = 3; + // A node vote for a new signer added to the erc20 bridge + TYPE_SIGNER_ADDED = 4; + // A node vote for a signer removed from the erc20 bridge + TYPE_SIGNER_REMOVED = 5; + // A node vote for a bridge stopped event + TYPE_BRIDGE_STOPPED = 6; + // A node vote for a bridge resumed event + TYPE_BRIDGE_RESUMED = 7; + // A node vote for a newly listed asset + TYPE_ASSET_LISTED = 8; + // A node vote for an asset limits update + TYPE_LIMITS_UPDATED = 9; + // A node vote to share the total supply of the staking token + TYPE_STAKE_TOTAL_SUPPLY = 10; + // A node vote to update the threshold of the signer set for the multisig contract + TYPE_SIGNER_THRESHOLD_SET = 11; + // A node vote to validate a new assert governance proposal + TYPE_GOVERNANCE_VALIDATE_ASSET = 12; + } } ``` ## Acceptance Criteria -### Event Queue - -- Event Queue calls `GetSubscribedEventSources` and successfully parses the response (0036-BRIE-001) -- Event Queue connects to a configured local or hosted external blockchain node (0036-BRIE-002) -- Event Queue gathers and filters applicable events from configured external blockchain node (0036-BRIE-003) -- Event Queue calls `GetEventAcceptanceStatus` and marks accepted events internally as complete (0036-BRIE-004) -- Event Queue propagates unaccepted events to Vega node via `PropagateEvent` (0036-BRIE-005) -- Event Queue retries sending events that have gone too long without being accepted (0036-BRIE-006) - -### Vega Nodes - -- Vega nodes respond to `GetSubscribedEventSources` with a list of valid smart contract events (0036-BRIE-007) -- Vega nodes accept events submitted to `PropagateEvent` and verifies them against configured external blockchain node (0036-BRIE-008) -- Vega nodes write events to chain once verified (0036-BRIE-009) -- Vega nodes respond appropriately to `GetEventAcceptanceStatus` (0036-BRIE-010) -- Vega nodes verify Event existence and outcomes using local Ethereum node - - Verify balance changes (0036-BRIE-011) - - Verify account identities (0036-BRIE-012) - - Verify transaction hashes (0036-BRIE-013) -- Vega nodes reject invalid events that fail verification in the previous step (0036-BRIE-014) -- Vega nodes responds appropriately to event triggers - - Users are credited on deposit (see also [0013-ACCT](./0013-ACCT-accounts.md)) (0036-BRIE-015) +- A valid event is processed by vega (0036-BRIE-001) + - A transaction is successfully executed on the bridge (e.g deposit) + - A validator node successfully source the event and emit a chain event transaction on the vega chain + - The others validators successfully validates the event on the ethereum chain and send a node vote on chain + - The required amount of node votes, weighted by validator score is received + - The processing of the event have effect on the network (e.g: for a deposit funds are deposited on an account) +- A valid duplicated event is processed (0036-BRIE-002) + - A transaction is successfully executed on the bridge (e.g deposit) and successfully processed by vega + - A node sends again the chain event after sourcing it + - The nodes reject this event as duplicated, nothing else happens +- A invalid event is processed (0036-BRIE-003) + - A malicious node sends a chain event for a non existing transaction on the bridge + - The node start validating this event on chain, but cannot find it + - After a given delay this chain event is rejected, no node votes are being sent by the validators + - This event has no repercussion on the vega state. diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 4a7d927fb..9e9347e55 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -195,15 +195,17 @@ The liquidity score should always be rounded to 10 decimal places to prevent spu ### Distributing fees -On every trade, liquidity fee should be collected immediately into an account for each liquidity provider (call it LP fee account). Each party will have an LP fee account on every market on which they committed liquidity by providing LP stake. +On every trade, liquidity fee should be collected immediately into an account for that market (call it the liquidity fee account). The account is under control of the network and funds from this account will be transferred to a LP party according to the mechanism below. -This account is not under control of the LP party (they cannot initiate transfers in or out of the account). The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. - -A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. +A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the liquidity fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens funds in this account are transferred to the liquidity providers general accounts for the market settlement asset. If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. +Flooring non-zero amounts due to integer representation can result in a remainder in the liquidity fee account. The remainder should be left in the market liquidity fee account and carried over to the next distribution window. + +If the fees are being distributed as a part of market settlement and distribution results in a remainder in the liquidity fee account. The remainder should be transferred to the network treasury for that asset. + #### Example We have `4` LPs with equity-like share shares: @@ -269,7 +271,9 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - The total amount of liquidity fee distributed is equal to the most recent `liquidity-fee-factor` x `notional-value-of-all-trades` (0042-LIQF-011) - Liquidity providers with a commitment of 0 will not receive a share ot the fees (0042-LIQF-012) - If a market has `market.liquidity.providers.fee.distributionTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) +- If after fee distribution during market settlement, there is a remainder in the market liquidity fee account, the remainder should be transferred to the network treasury for that asset. (0042-LIQF-031) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) +- After fee distribution, if there is a remainder in the liquidity fee account and the market is not being settled, it should be left in the liquidity fee account and carried over to the next distribution window. (0042-LIQF-032) ### LP JOINING AND LEAVING MARKETS diff --git a/protocol/0045-DSRC-data_sourcing.md b/protocol/0045-DSRC-data_sourcing.md index 63f44d465..3b6573ea1 100644 --- a/protocol/0045-DSRC-data_sourcing.md +++ b/protocol/0045-DSRC-data_sourcing.md @@ -246,3 +246,7 @@ Vega should reject any data source tx that is not explicitly required, so this w 1. After trading termination has been triggered the trading terminated data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-019) 1. After settlement data has been received and the market has settled, the settlement data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-020) 1. Where the same oracle definition is used for trading terminated and settlement, and data has been received. Trading is terminated and the market is settled with the same data event (a single message does both). The data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed. (0045-DSRC-021) +1. It should be possible to update the market termination spec from external to internal and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-022) +1. It should be possible to update the market termination spec from internal to external and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-023) +1. It should not be possible to update the market settlement data spec to change the type from an external data source to an internal Vega timestamp data source. NB: this is because the internal Vega timestamp data source does not emit a value that can be used as a price, only a date/time. (0045-DSRC-024) +1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025) diff --git a/protocol/0061-REWP-pos_rewards.md b/protocol/0061-REWP-pos_rewards.md index d01dcfe56..608457d2d 100644 --- a/protocol/0061-REWP-pos_rewards.md +++ b/protocol/0061-REWP-pos_rewards.md @@ -11,7 +11,7 @@ This applies both the rewards coming from the [on-chain-treasury](./0055-TREA-on 1. `totalStake` - the total number of units of the staking and governance asset (VEGA) associated to the Vega chain (but not necessarily delegated to a specific validator). 1. `compLevel` - This is a Network parameter that can be changed through a governance vote. Full name: `reward.staking.delegation.competitionLevel`. Default `1.1`. 1. `reward.staking.delegation.optimalStakeMultiplier` - another network parameter which together with `compLevel` control how much the validators "compete" for delegated stake. -1. `network.ersatzvalidators.reward.factor` - a decimal in `[0,1]` with default of `1`. It controls how much the ersatz validator own + delegated stake counts for reward purposes. +1. `network.ersatzvalidators.reward.factor` - a decimal in `[0,1]` with default of `1`. It controls how much the ersatz validator(standby validator) own + delegated stake counts for reward purposes. ## Other network parameters @@ -33,7 +33,7 @@ This is to ensure that validators (all validators) have incentive to pay Ethereu ## Primary (consensus forming) Nodes, Ersatz Nodes, Non-validator nodes -From the point of view of proof of stake rewards three are three types of nodes: +From the point of view of proof of stake rewards there are three types of nodes: 1. Non-validator nodes that process transactions and can run the [data node](./0076-DANO-data-node.md) for client use but they don't determine which transactions go into blocks and they get no proof of stake rewards. Any such validator [can submit a transaction](./0069-VCBS-validators_chosen_by_stake.md) to join the ersatz nodes / validator nodes set. Once they submit such transaction they become [pending nodes](./0064-VALP-validator_performance_based_rewards.md) and their performance is measured to determine their suitability. If they meet staking and performance criteria will get "promoted" to the next level. 1. The [ersatz validators](./0069-VCBS-validators_chosen_by_stake.md) who, from the point of view of consensus protocol are non-validator nodes but they have sufficient stake (own or delegated) and meet performance criteria. Their role is to be readily available if any of the primary (Tendermint) validators was to drop out in which case they become primary validators. They can also become primary validators if the stake composition [changes sufficiently](./0069-VCBS-validators_chosen_by_stake.md). They receive proof of stake rewards. If their performance score or amount of delegated stake drops they can be demoted to a pending non-validator node. @@ -41,8 +41,8 @@ From the point of view of proof of stake rewards three are three types of nodes: ### Proof of stake reward split between primary (tendermint) validators and ersatz validators -The reward pool is split into two parts, proportional to the total own+delegated stake the primary- and ersatz validators have. -Thus, if `s_t = network.ersatzvalidators.reward.factor x s_e + s_p` is the total amount of own+delegated stake to both sets (with ersatz scaling taken into account), `s_p` the total stake delegated to the primary / Tendermint validators and `s_e x network.ersatzvalidators.reward.factor` the total stake delegated to the ersatz validators (scaled appropriately), then the primary / Tendermint pool has a fraction of `s_p/s_t` of the total reward, while the ersatz pool has `network.ersatzvalidators.reward.factor x s_e / s_t` (both rounded down appropriately). +The reward pool is split into two parts, proportional to the total own+delegated stake the primary and ersatz validators have. +Thus, if `s_t = network.ersatzvalidators.reward.factor x s_e + s_p` is the total amount of own+delegated stake to both sets (with ersatz scaling taken into account), `s_p` the total stake delegated to the primary / Tendermint validators and `s_e x network.ersatzvalidators.reward.factor` the total stake delegated to the ersatz validators (scaled appropriately), then the primary / Tendermint pool has a fraction of `s_p / s_t` of the total reward, while the ersatz pool has `network.ersatzvalidators.reward.factor x s_e / s_t` (both rounded down appropriately). The following formulas then apply to both primary and ersatz validators, where 'total available reward' and 'total delegation', total_stake and 'number_of_validators' or `s_total` refer to the corresponding reward pool and the total own+delegated corresponding set of validators (i.e., `s_p` or `s_e`, respectively). diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 12e175fcd..864c65e02 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -34,7 +34,7 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039) - For Reduce-Only = TRUE orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) - - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-048) + - If not enough volume is available to **fully** fill the order, the order will be cancelled(0068-MATC-048) - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-049) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-050) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders which increase the trader's absolute position will be stopped (0068-MATC-051) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index ea1270e91..4397a5aaa 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -21,7 +21,7 @@ Note that this number combines own + delegated stake together with `performance_ Vega will sort all current consensus forming (also called Tendermint) validators as `[v_1, ..., v_n]` with `v_1` with the highest and `v_n` with the lowest score. If for any `l,m=1,...,n` we have `v_l == v_m` then we place higher the one who's been validator for longer (so this is a mechanism for resolving ties). Vega will sort all those who submitted a transaction wishing to be validators using `validator_score` as `[w_1, ..., w_k]`. -These may be ersatz validators (ie getting rewards) or others who just submitted the transaction to join. +These may be ersatz validators (i.e. standby validators who are getting rewards) or others who just submitted the transaction to join. If `empty_slots := network.validators.tendermint.number - n > 0` (we have empty consensus (Tendermint) validator slots) then the top `empty_slots` from `[w_1, ..., w_k]` are promoted to consensus (Tendermint) validators. If `w_1>v_n` (i.e. the highest scored potential validator has more than the lowest score incumbent validator) then in the new epoch `w_1` becomes a consensus forming (Tendermint) validator, and the lowest scoring incumbent becomes an ersatz validator. @@ -392,7 +392,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - In the middle of the epoch, shut node 1 down. - Verify that at the beginning of the next epoch the announced node replaced node 1 as a Tendermint validator. - Restart node 1 again from a snapshot - - Verify that node 1 is in a pending state and it’s ranking score is ~ 0.006666666667. + - Verify that node 1 is in a pending state. 1. 2 empty spots, only one available to replace (0069-VCBS-043): - Setup a network with 5 slots for Tendermint validators and 3 actual Tendermint validators. - Self-delegate to all of them. @@ -553,6 +553,14 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the network - Verify that v2-v6 are tendermint validators, v7 is ersatz and v1 is pending. - Verify that all stakes and delegations are correct for each node. +1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088): + - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). + - Take a checkpoint. + - Wait until the current epoch will have expired. + - Restart the network. (This will result in a 1-block epoch) + - Verify that v1-v5 are tendermint validators, v6 is ersatz and v7 is pending. + - Verify that all tendermint validators have non-zero performance scores, which will reflect the data that was collected pre-checkpoint to calculate scores at the end of the last epoch. + - Verify that ersatz and pending validators have non-zero performance scores. ### Multisig update diff --git a/protocol/0072-SPPW-spam-protection-PoW.md b/protocol/0072-SPPW-spam-protection-PoW.md index 5dce3a40b..001cb67d8 100644 --- a/protocol/0072-SPPW-spam-protection-PoW.md +++ b/protocol/0072-SPPW-spam-protection-PoW.md @@ -76,6 +76,15 @@ Depending on how things pan out, we may have an issue with the timing; to make s The initial hash-function used is SHA3. To allow for a more fine-grained control over the difficulty of the PoW (the number of zeros only allows halving/doubling), the parameter `spam.pow.hashFunction` allows increasing the number of rounds of the hash function (currently 24), e.g., `spam.pow.hashFunction` = `sha3_36_rounds`. The parameter can in the future also be used to replace the SHA-3 through a governance vote (assuming other functions have been made available by then) should this prove necessary. +## Mempool pruning + +Vega nodes will periodically inspect the mempool. Any transaction sitting in the mempool with PoW tied to a historical block with number `N_old` which satisfies that `N_old + spam.pow.numberOfPastBlocks < N_current` will be removed from the mempool. Here `N_current` is the current block the vega node is processing (has just processed). + +Clients can use this simulate "time-to-live" for transactions. If the PoW is tied to a very recent block then the transaction will remain valid for (almost) the full `spam.pow.numberOfPastBlocks`. If, on the other hand, the PoW is tied to very old block then the transaction will remain valid only for a few blocks; it will be included in a block soon or not at all. + +All Vega clients that submitted transactions can verify that their transaction has succeeded by waiting that it's been included in a block; if they submitted a transaction with PoW tied to `N_old` and `N_old + spam.pow.numberOfPastBlocks < N_current` then they know the transaction was pruned and will never be included on chain. + + ## Acceptance Criteria - A message with a missing/wrong PoW is rejected (0072-SPPW-001) @@ -115,3 +124,7 @@ The initial hash-function used is SHA3. To allow for a more fine-grained control - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-COSMICELEVATOR-014) + + +- *Mempool pruning* Cause congestion in the mempool by submitting many transactions (perhaps from several parties). Submit a transaction `T` tied to block number `N_old`. Make sure the transactions causing congestion create sufficiently large `N_current`. At some point we'll have `N_old + spam.pow.numberOfPastBlocks < N_current` and the transaction `T` is removed from the mempool and never scheduled. (0072-SPPW-012) + diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index 02b640ef8..d3279ccbf 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -108,7 +108,7 @@ message ProtocolUpgradeEvent { - (0075-PLUP-002) Validator proposes a protocol upgrade on a block height preceding the current block - should result in an error - (0075-PLUP-003) Propose and enact a version downgrade - (0075-PLUP-004) Non-validator attempts to propose upgrade -- (0075-PLUP-005) Ersatz validator attempts to propose upgrade +- (0075-PLUP-005) Ersatz validator (standby validator) attempts to propose upgrade ### Block height validation diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index af5e19252..4dc6a1d2d 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -151,6 +151,7 @@ It must be possible to add to the data node APIs that return the result of calcu 1. Nodes must be able to start processing new blocks having loaded the only the most recent history (0076-DANO-023) 1. Nodes that have been temporarily disconnected from the network should be able to load the missed history to get back up to the current network height (or most recently produced history) and then be able to start processing new blocks (0076-DANO-024) 1. It must be possible to fetch history from the network whilst the node processes new blocks. So for example, if setting up a new Archive node, the node can keep up to date with the network whilst retrieving history all the way back to the first block. Once this is done the node should be able to reconcile the fetched history with that produced whilst the history was being retrieved such that the node will have a full history from the first block all the way to the networks current height. (0076-DANO-025) +1. It must be possible to rollback the data-node to a previous block height and have it process events from this height onwards. The state of the datanode at the rollback height must match exactly the state of the node as it was when it originally reached the given height. (0076-DANO-039) ### Data integrity @@ -166,6 +167,7 @@ It must be possible to add to the data node APIs that return the result of calcu 1. Starting a core node at block height greater than the data-nodes block height must result in an error and a refusal to start (0076-DANO-014) 1. If a data-node snapshot fails during the restore the process, it should error and the node(s) won't start (0076-DANO-009) 1. When queried via the APIs a node restored from decentralised history should return identical results to a node with the same block span which has been populated by event consumption. [project front end dApps](https://github.com/vegaprotocol/frontend-monorepo/actions/workflows/generate-queries.yml). (0076-DANO-022) +1. All network history retained by a node for a given block span and type must be downloadable in CSV format. (0076-DANO-040) ### Data-node network determinism diff --git a/user-interface/0004-EWAL-connect_ethereum_wallet.md b/user-interface/0004-EWAL-connect_ethereum_wallet.md index 6c9567ae1..7944a23df 100644 --- a/user-interface/0004-EWAL-connect_ethereum_wallet.md +++ b/user-interface/0004-EWAL-connect_ethereum_wallet.md @@ -29,7 +29,6 @@ When wanting or needing to write to Ethereum, I... When I'm finished using a connected Ethereum wallet I may wish to disconnect... - **must** see a link to disconnect (0004-EWAL-006) -- **must** destroy all session so that hitting connect again connects as if it is the first use (0004-EWAL-007) -- **should** see a connect button to start a fresh connection (e.g. to a different wallet but via Wallet connect) + - **must** destroy dapp -> ETH wallet session so that hitting connect again triggers the modal that asks what method you'd like to use to connect to an ETH wallet, (note: it is not possible to invalidate the permission the metamask wallet has granted the app, therefore users will need to know that if they want to connect to a new ETH key they will have to do so from the wallet) (0004-EWAL-007) ... so that I can use a different wallet, or ensure may wallet can not be used by other apps \ No newline at end of file diff --git a/user-interface/1101-BWAL-browser_wallet.md b/user-interface/1101-BWAL-browser_wallet.md new file mode 100644 index 000000000..e00d6c484 --- /dev/null +++ b/user-interface/1101-BWAL-browser_wallet.md @@ -0,0 +1,118 @@ +# Browser Wallet + +## Create app password + +As a browser wallet user I want to create a password for my browser wallet app So that I can secure my wallets and keys on this device + +- When I haven't submitted my password, I can go back to the previous step (1101-BWAL-001) +- I can see an explanation of what the password is for and that it cannot be used to recover my keys or recover itself (1101-BWAL-002) +- I can enter a password for the browser wallet (1101-BWAL-003) +- I can verify the password I set for my browser wallet (to help ensure I typed it correctly and can replicate it) (1101-BWAL-004) +- I can verify that I understand that Vega doesn't store and therefore can't recover this password if I lose it (1101-BWAL-005) +- I can NOT submit an empty password (1101-BWAL-006) +- I can submit the password I entered (1101-BWAL-007) +- When I have submitted my new password, I am given some feedback that it was set successfully (1101-BWAL-008) +- When I have submitted my new password, I am taken to the next step (1101-BWAL-009) +- When I have submitted my new password, I can NOT go back to the previous step (1101-BWAL-010) + +## Create or import wallet + +As a browser wallet user I want to decide whether to create a new wallet or import an existing one So that I understand my options and don't waste time creating a new wallet when I already created one elsewhere + +- I can choose to create a wallet (1101-BWAL-011) +- I can choose to import an existing wallet (1101-BWAL-012) + +## Create wallet and key pair + +As a browser wallet user When I am using the browser wallet for the first time I want to create a new wallet (and key pair) So that I can get started using Console / another Vega dapp to trade / take part in governance + +- I am provided with a recovery phrase for my new wallet that is initially hidden from view(1101-BWAL-013) +- I can see an explanation of what the recovery phrase is for and that it cannot be recovered itself (1101-BWAL-014) +- I can choose when to reveal/show the recovery phrase (1101-BWAL-015) +- I can copy the recovery phrase into my clipboard (1101-BWAL-016) +- I can verify that I understand that Vega doesn't store and therefore can't recover this recovery phrase if I lose it (1101-BWAL-017) +- I am given feedback that my wallet was successfully created (1101-BWAL-018) +- I am redirected to the next step - opt in to error reporting (1101-BWAL-019) +- The new Wallet name and key pair are auto generated in the background "Wallet" "Vega Key 1" (1101-BWAL-020) +- When I have already created a wallet, I am redirected to the landing page where I can view that wallet (rather than the onboarding flow) (1101-BWAL-021) + +## Confirm recovery phrase + +As a wallet user I want to validate I have "recorded" or saved the recovery phrase accurately So that I feel secure and confident to go ahead + +- I can confirm I have written down / saved my recovery phrase by entering parts of it again in the UI(1101-BWAL-022) +- There is a way to go back to see the full recovery phrase if I have written / saved it incorrectly (1101-BWAL-023) +- I can click to continue to the next step of onboarding once I've successfully entered the relevant parts of the phrase (1101-BWAL-024) +- There is a way to understand if the details I've entered are incorrect e.g. highlight in red (1101-BWAL-025) + +## View network connected to + +As a browser wallet user I want to know which vega network my browser wallet is connected to So that I know if I am on the network I expect to be, and whether I am transacting with real or fake assets + +- The browser wallet defaults to use the Fairground network (1101-BWAL-026) +- I can see which vega network the browser wallet is connected to from everywhere in the app(1101-BWAL-027) + +## Create key pairs + +As a wallet user I want to be able to create multiple key pairs in my wallet So that I can use different keys for different + +- I can create a new key pair from the wallet view (1101-BWAL-028) +- New key pairs are assigned a name automatically "Vega Key 1" "Vega Key 2" etc.(1101-BWAL-029) +- New key pairs are listed in order they were created - oldest first(1101-BWAL-030) + +## Remember where I am in the onboarding flow + +As a browser wallet user When I have started onboarding in the browser wallet and I close the extension / browser I want to be able to reopen the extension and it remember where I was in the onboarding flow So that I don't have to start again + +- I can close the extension and when I reopen it it opens on the same page / view (1101-BWAL-031) +- When I reopen the extension after last viewing the recovery phrase and hadn't yet acknowledged and moved to the next step, it opens on the recover phrase step with the recovery phrase hidden(1101-BWAL-032) + +## Connect all key(s) only + +As a wallet user I want to connect my key(s) to a dapp So that I can verify transactions like orders, transfers etc. + +- There is a way to approve or deny a connection request (1101-BWAL-033) +- I can see a visual representation of the dapp requesting access e.g. the favicon (1101-BWAL-034) +- I can see what approving a connection request enables the site / dapp to do (1101-BWAL-035) +- I can see the URL of the site / dapp requesting access(1101-BWAL-036) +- All new connections are for all keys in a wallet and all future keys added to the wallet(1101-BWAL-037) +- There is a way to understand that i.e. this connection request gives access to ALL my keys now and in the future (1101-BWAL-038) +- When I go away from the extension and come back to the connected site, the browser extension remembers the connection and does not ask me to reconnect (1101-BWAL-039) +- There is a visual way to understand that a connection has been successful(1101-BWAL-040) + +## Approve transaction request + +As a browser wallet user I want to be able to approve a transaction request So that I can verify and complete the action I am trying to make on the vega dapp I'm using + +- When I view a transaction request I can choose to approve it (1101-BWAL-041) +- When I approve a transaction I can see confirmation that the transaction has been approved (1101-BWAL-042) +- When I approve a transaction the transaction gets signed and the approved status gets fed back to the dapp that requested it (1101-BWAL-043) +- When I approve a transaction after I have approved it we revert to the next transaction if there's a queue OR we revert to the key view (the front / homepage) (1101-BWAL-044) + +## Reject transaction request + +As a browser wallet user I want to be able to reject a transaction request So that I can prevent a transaction going through that I don't recognise as mine, or have changed my mind on / identified a mistake etc. + +- When I view a transaction request I can choose to reject it(1101-BWAL-045) +- When I reject a transaction I can see confirmation that the transaction has been rejected (1101-BWAL-046) +- When I reject a transaction the transaction does not get signed and the rejected status gets fed back to the dapp that requested it (1101-BWAL-047) +- When I reject a transaction after I have rejected it we revert to the next transaction if there's a queue OR we revert to the key view (start / home page) (1101-BWAL-048) + +## View trasaction request (generic) + +As a user I want to recognise transactions that are not orders or withdraw / transfer requests with at least the bear minimum information needed to proceed So that I can continue my task (e.g. governing, staking) + +- When the dapp requests a transaction with a key we don't know about, we don't see a request in the wallet but instead send an error back to the dapp(1101-BWAL-049) +- When the dapp requests a transaction type / or includes transaction details that we don't recognise, we don't present the transaction request in the wallet but provide an error to the dapp that feeds back that the transaction can not be processed (1101-BWAL-050) +- When the user opens the extension (or it has automatically opened) they can immediately see a transaction request (1101-BWAL-051) +- If the browser extension is closed during a transaction request, the request persists (1101-BWAL-052) +- For transactions that are not orders or withdraw / transfers, there is a standard template with the minimum information required i.e. (1101-BWAL-053) -- [ ] Transaction title -- [ ] Where it is from e.g. console.vega.xyz with a favicon -- [ ] The key you are using to sign with a visual identifier -- [ ] When it was received -- [ ] Raw JSON details +- It is visually similar to other transaction types but essentially has less of the human readable detail(s) (design note) (1101-BWAL-054) +- I can copy the raw json to my clipboard (1101-BWAL-055) + +## Log in (next time password expires) + +As a wallet user I want a way to enter my password when my login has expired So that I can continue with my task + +- When I have quit my browser, and then reopened, I am asked to enter my browser extension password(1101-BWAL-056) +- I am informed if I enter my password incorrectly (1101-BWAL-057) diff --git a/user-interface/6501-ASSE-assets.md b/user-interface/6501-ASSE-assets.md new file mode 100644 index 000000000..0f068bedd --- /dev/null +++ b/user-interface/6501-ASSE-assets.md @@ -0,0 +1,21 @@ +# Assets + +## Asset detail dialog + +- **Must** see asset ID (6501-ASSE-001) +- **Must** see asset type (only ERC20 for now) (6501-ASSE-002) +- **Must** see full asset name (6501-ASSE-003) +- **Must** see asset symbol (6501-ASSE-004) +- **Must** see asset decimals (6501-ASSE-005) +- **Must** see asset quantum value (6501-ASSE-006) +- **Must** see asset status (Proposed, Rejected, Pending listing, Enabled) (6501-ASSE-007) +- **Must** see withdrawal threshold (6501-ASSE-008) +- **Must** see lifetime withdrawal limit (6501-ASSE-009) +- **Must** see infrastructure fee account balance (6501-ASSE-010) +- **Must** see global reward pool account balance (6501-ASSE-011) +- **Must** be able to close the dialog (6501-ASSE-012) + +### Asset types + +- ERC20 + - **Must** see contract address (6501-ASSE-013) diff --git a/user-interface/7001-COLL-collateral.md b/user-interface/7001-COLL-collateral.md index a569541c4..d2c688b43 100644 --- a/user-interface/7001-COLL-collateral.md +++ b/user-interface/7001-COLL-collateral.md @@ -1 +1,28 @@ -# Collateral \ No newline at end of file +# Collateral + +## Collateral Data Grid + +- **Must** be shown grouped by [asset](9001-DATA-data_display.md#asset-balances) (7001-COLL-001) +- For each asset: + - **Must** show used [amount](9001-DATA-data_display.md#asset-balances), which is the total of all Margin and Liquidity bond accounts (7001-COLL-002) + - **Must** show available [amount](9001-DATA-data_display.md#asset-balances), which is the total of your General account (7001-COLL-003) + - **Must** show total [amount](9001-DATA-data_display.md#asset-balances), which is the sum of your General account and all Margin accounts (7001-COLL-004) + - **Must** provide a method for depositing asset (7001-COLL-005) + - **Must** provide a method for withdrawing asset (7001-COLL-006) + - **Must** show the asset symbol (7001-COLL-007) + - **Must** provide a way to see the [full asset details](6501-ASSE-assets.md) (7001-COLL-008) + - **Must** provide a way to see all accounts, their type, and their balance for a single asset (7001-COLL-009) + - **Could** have default sort order (7001-COLL-010) + - General + - Margin + - Bond + - Fees - Maker + - Fees - Liquidity + - Rewards - Maker Paid + - Rewards - Maker Received + - Rewards - Liquidity Provision Received Fees + - Rewards - Market Proposers + +## Deal Ticket + +- **Must** see your current total margin (General balance + Margin balance - Maintenance level) available (7001-COLL-011) diff --git a/user-interface/7005-FILL-fills.md b/user-interface/7005-FILL-fills.md index 1ca8f3e59..bfdc7768a 100644 --- a/user-interface/7005-FILL-fills.md +++ b/user-interface/7005-FILL-fills.md @@ -1 +1,19 @@ -# My fills \ No newline at end of file +# Fills + +## Fills Data Grid + +- **Must** see the [market](9001-DATA-data_display.md#market) the fill occurred in (7005-FILL-001) +- **Must** see the [size](9001-DATA-data_display.md#size) of the fill (7005-FILL-002) + - **Must** see indication if the current party was the buyer (7005-FILL-003) + - **Must** see indication if the current party was the seller (7005-FILL-004) +- **Must** see the [price](9001-DATA-data_display.md#quote-price) of the fill (7005-FILL-005) +- **Could** see the notional value of the fill (7005-FILL-006) +- **Must** see the [fee](9001-DATA-data_display.md#asset-balances) that applies for current party for the fill (7005-FILL-007) + +### Continuous Trading + +- **Must** see the role of the user (taker, maker or n/a) (7005-FILL-008) + +### Auction + +TBD. Currently any trade made during auction will result in the both parties having the role of 'taker'. This may be incorrect and is being investigated. diff --git a/user-interface/apps.json b/user-interface/apps.json index 46ee14c81..e9c09536d 100644 --- a/user-interface/apps.json +++ b/user-interface/apps.json @@ -2,6 +2,9 @@ "Desktop-Wallet": { "specs": ["0001-WALL"] }, + "Browser-Wallet": { + "specs": ["1101-BWAL"] + }, "Token": { "specs": ["9001-DATA", "1002-WITH", "1004-ASSO", "1005-VEST", "2001-STKE", "2002-SINC", "7001-COLL", "3001-VOTE", "3002-PROP", "3003-PMAN", "3004-PMAC", "3005-PASN", "3006-PASC", "3007-PNEC", "3008-PFRO", "0002-WCON", "0003-WTXN", "0004-EWAL", "005-ETXN", "0006-NETW" ] }, diff --git a/user-interface/categories.json b/user-interface/categories.json index 77b023b2f..03ec46461 100644 --- a/user-interface/categories.json +++ b/user-interface/categories.json @@ -1,32 +1,32 @@ { "Wallets & Signing Transactions & Network Selection": { - "specs": ["0001-WALL", "0002-WCON", "0003-WTXN", "0004-EWAL", "0005-ETXN", "0006-NETW"] + "specs": ["0001-WALL", "0002-WCON", "0003-WTXN", "0004-EWAL", "0005-ETXN", "0006-NETW", "1101-BWAL"] }, "Bridges & Transfers & Vesting": { - "specs": ["1001-DEPO", "1002-WITH", "1003-TRAN", "1004-ASSO", "1005-VEST"] + "specs": ["1001-DEPO", "1002-WITH", "1003-TRAN", "1004-ASSO", "1005-VEST"] }, "Staking": { - "specs": ["2001-STKE", "2002-SINC"] + "specs": ["2001-STKE", "2002-SINC"] }, "Governance": { - "specs": ["3001-VOTE", "3002-PROP", "3003-PMAN", "3004-PMAC", "3005-PASN", "3006-PASC", "3007-PNEC", "3008-PFRO"] + "specs": ["3001-VOTE", "3002-PROP", "3003-PMAN", "3004-PMAC", "3005-PASN", "3006-PASC", "3007-PNEC", "3008-PFRO"] }, "Treasury": { - "specs": ["4001-TRES"] + "specs": ["4001-TRES"] }, "Liquidity Provision": { - "specs": ["5001-LIQF", "5002-LIQP", "5003-LIQI"] + "specs": ["5001-LIQF", "5002-LIQP", "5003-LIQI"] }, "Markets & Analysis": { - "specs": ["6001-MARK", "6002-MDET", "6003-ORDB", "6004-PHIS", "6005-THIS"] + "specs": ["6001-MARK", "6002-MDET", "6003-ORDB", "6004-PHIS", "6005-THIS"] }, "Collateral & Orders & Positions & Fills": { - "specs": ["7001-COLL", "7002-SORD", "7003-MORD", "7004-POSI", "7005-FILL", "7006-FEES"] + "specs": ["7001-COLL", "7002-SORD", "7003-MORD", "7004-POSI", "7005-FILL", "7006-FEES"] }, "Block Exploring": { - "specs": ["8001-BLOX"] + "specs": ["8001-BLOX"] }, "Data Display": { - "specs": ["9001-DATA"] + "specs": ["9001-DATA"] } - } + } \ No newline at end of file diff --git a/wordlist.txt b/wordlist.txt index 9b8fac7bd..400440dc7 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -25,10 +25,12 @@ cashflow cashflows CCP ccy +cdot ceil ceiled CFD CSF +CSV checkpointing CLEF closedout @@ -91,6 +93,7 @@ FIFO filesystem FOK FOREX +frac freeform frontend funder From b9921a5e40fa9819ea7daa5177c3dc956b88c06a Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 17 May 2023 12:29:30 +0100 Subject: [PATCH 015/649] feat: successor market (#1500) * feat: successor market * feat: successor market * fix: small edit from review * chore: linting * chore: linting * fix: don't talk of ELS in ACs, talk of virtual stake instead * fix: successor that settles before parent case * feat: allow fraction of insurance pool * chore: spelling * chore: sacrifical offereng to the linting gods * fix: make new AC codes unique * Update protocol/0028-GOVE-governance.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update protocol/0028-GOVE-governance.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update protocol/0028-GOVE-governance.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update protocol/0043-MKTL-market_lifecycle.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update protocol/0001-MKTF-market_framework.md Co-authored-by: Witold * Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md * chore: marketID only * Update protocol/0001-MKTF-market_framework.md * Update protocol/0028-GOVE-governance.md * Update protocol/0028-GOVE-governance.md * Update protocol/0028-GOVE-governance.md * add network.liquidity.successorLaunchWindowLength * fix: markdown linting * fix: AC code numbering * fix: backtick marketID and remove from wordlist --------- Co-authored-by: gordsport Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Witold Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0001-MKTF-market_framework.md | 14 +++++ protocol/0019-MCAL-margin_calculator.md | 4 +- protocol/0028-GOVE-governance.md | 18 +++++- ...042-LIQF-setting_fees_and_rewarding_lps.md | 59 ++++++++++++------- protocol/0043-MKTL-market_lifecycle.md | 19 +++--- protocol/0068-MATC-matching_engine.md | 2 + 6 files changed, 81 insertions(+), 35 deletions(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 4a86e205b..8c8e5a302 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -216,9 +216,23 @@ Market { } ``` +## Successor market + +If a market proposal, see [governance](./0028-GOVE-governance.md), designates an existing market as a *parent market* then it must have the same *product*, *settlement asset(s)* and *margin asset(s)*. +It may propose new risk model and parameters, price monitoring parameters, position and market decimal places and oracles, both for trading terminated and for settlement data. +Each market can have exactly one market as a *successor* market. + +1. if there already is a market (possibly pending i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)) naming a parent market which is referenced in the proposal then the proposal is rejected. +1. if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market not available". + + ## Acceptance criteria - Details of a market's instrument must be available for each market through the API (0001-MKTF-001) - Details of a market's product must be available for each market through the API (0001-MKTF-002) - Details of a market's tradable instrument must be available for each market through the API (0001-MKTF-003) - Market framework can report position decimal places 0001-MKTF-004 +- It is possible to designate a market as perpetual; this is visible via APIs in market data. 0001-MKTF-005 +- A market may have a "parent" market; the parent market is visible via APIs in the form of the `marketID` of the parent market. 0001-MKTF-006 +- A market may have a "successor" market; the parent market is visible via APIs in the form of the `marketID` (or `proposalID`) of the successor market. 0001-MKTF-007 +- A parent and successor markets must have the same product, settlement asset(s) and margin asset(s). 0001-MKTF-008 diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 83d25ec02..4397d0f02 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -235,8 +235,7 @@ slippage_per_unit = Product.value(market_observable) - Product.value(exit_price maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + max(open_volume, 0 ) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] - -= max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 + = max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 # Step 2 @@ -251,7 +250,6 @@ maintenance_margin = max ( 677.6, 0) = 677.6 collateral_release_level = 677.6 * collateral_release_scaling_factor = 677.6 * 1.1 initial_margin = 677.6 * initial_margin_scaling_factor = 677.6 * 1.2 search_level = 677.6 * search_level_scaling_factor = 677.6 * 1.3 - ``` ### EXAMPLE 2 - calculating correct slippage volume diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 8f0b14482..8fd3d4c4b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -215,10 +215,24 @@ Note the following key points from the market lifecycle spec: - A market enters a Pending status as soon as the proposal is Successful (before enactment) - A market usually enters Active status at the proposal's enactment date/time, but some conditions may delay this or cause the market to be Cancelled instead -A proposal to create a market contains: +A proposal to create a market contains -1. a complete market specification as per the Market Framework (see spec) that describes the market to be created. +1. a complete market specification as per the [Market Framework](./0001-MKTF-market_framework.md) that describes the market to be created. 1. an enactment time that is at least the _minimum auction duration_ after the vote closing time (see [auction spec](./0026-AUCT-auctions.md)) +1. if the market is meant to be a _successor_ of a given market then it contains the `marketID` of the market it's succeeding (parent market), a parameter called `insurancePoolFraction` which is a decimal in `[0,1]` (i.e. it can be `0` or `1` or anything in between) and certain entries in the market proposal must be identical to those of the market it's succeeding OR the proposal should simply not contain the fields that cannot be changed. +In a particular instrument, the settlement asset, margin asset, and `market.value.windowLength` must match. +The parent market must be in one of `active` or `suspended` or `trading terminated` states or `settled` but with time since settlement less than or equal `network.liquidity.successorLaunchWindowLength` or `cancelled` (closed by governance) but with the closing time less than or equal `network.liquidity.successorLaunchWindowLength`. +In particular the market cannot be `pending`. +If the parent market is `proposed` or `pending` then the proposal should be rejected at the validation stage with an error "parent market cannot be in `*` state" with `*` being one of the dis-allowed states above. +The point of setting up a market to be successor of an existing market is to +a) allow LPs continue claim their equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and +b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. + +Note that each market can have exactly one market as a _successor_ market. + +- if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. +- if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market no longer available". +- if there is a successor market naming a parent market that terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market successor is set to empty and a different successor can be proposed. All _new market proposals_ initially have their validation configured by the network parameters `Governance.CreateMarket.All.*`. These may be split from `All` to subtypes in future, for instance when other market types like RFQ are created. diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 9e9347e55..cc4318393 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -21,7 +21,7 @@ The [liquidity fee factor](./0029-FEES-fees.md) is an input to the total taker f As part of the [commit liquidity network transaction](./0038-OLIQ-liquidity_provision_order_type.md), the liquidity provider submits their desired level for the [liquidity fee factor](./0042-LIQF-setting_fees_and_rewarding_lps.md) for the market. Here we describe how this fee factor is set from the values submitted by all liquidity providers for a given market. First, we produce a list of pairs which capture committed liquidity of each LP together with their desired liquidity fee factor and arrange this list in an increasing order by fee amount. Thus we have -```math +```text [LP-1-stake, LP-1-liquidity-fee-factor] [LP-2-stake, LP-2-liquidity-fee-factor] ... @@ -38,7 +38,7 @@ Finally, we set the liquidity-fee-factor for this market to be the fee `LP-k-liq In the example below there are 3 liquidity providers all bidding for their chosen fee level. The LP orders they submit are sorted into increasing fee order so that the lowest fee bid is at the top and the highest is at the bottom. The fee level chosen for the market is derived from the liquidity commitment of the market (`target stake`) and the amount of stake committed from each bidder. Vega processes the LP orders from top to bottom by adding up the commitment stake as it goes until it reaches a level greater than or equal to the `target stake`. When that point is reached the fee used is the fee of the last liquidity order processed. -```math +```text [LP 1 stake = 120 ETH, LP 1 liquidity-fee-factor = 0.5%] [LP 2 stake = 20 ETH, LP 2 liquidity-fee-factor = 0.75%] [LP 3 stake = 60 ETH, LP 3 liquidity-fee-factor = 3.75%] @@ -70,25 +70,32 @@ The guiding principle of this section is that by committing stake a liquidity pr The parameter which determines the period over which market value and hence growth is `market.value.windowLength` which could be e.g. a week. From the end of the opening auction, which we will refer to as `t0` until `t0+market.value.windowLength` is the `0th` or "bootstrap period". Then from `t0+market.value.windowLength` until `t0 + 2 x market.value.windowLength` is the `1st` period and so on. For each LP we track the stake they have and also their virtual stake. -Before and during the 0th (bootstrap) any stake commitment or removal is mirrored in the virtual stake. +For markets that have no "parent" market, see [governance](./0028-GOVE-governance.md) we postulate that before and during the 0th (bootstrap) any stake commitment or removal is mirrored in the virtual stake. -For any period `n >= 1` LP can add stake or remove stake but virtual stake is treated differently: +For any period `n >= 1` LP can add stake or remove stake but virtual stake is treated differently for markets with "parent market": + +If the market has a "parent market" then each LP which commits liquidity (to this market) gets the virtual stake copied from the parent market as the 1st step of the process and the stake they are committing here minus the stake on parent market is treated as the `delta` here. Say an `LP i` wants increases their commitment by `delta > market.liquidityProvision.minLpStakeQuantumMultiple x quantum` (this could also be the initial commitment). Then we update -`LP i virtual stake <- LP i virtual stake + delta`. +```text +LP i virtual stake <- LP i virtual stake + delta. +``` Say an `LP i` wants to decrease their commitment by `delta < 0`. Then we update -`LP i virtual stake <- LP i virtual stake x (LP i stake + delta)/(LP i stake)`. +```text +LP i virtual stake <- LP i virtual stake x (LP i stake + delta)/(LP i stake). +``` Independently of the above we also update all virtual stakes at start of each new period. To that end "total value for fee purposes" is cumulated over the period set by `market.value.windowLength`. For a period `n` call this `T(n)`. We let the `0`th period start the moment the opening auction ends and last for `market.value.windowLength`. -We include the volume of the trades that resolved the opening auction in `T(0)`. +We include the volume of the trades that resolved the opening auction in `T(0)` for markets with no parent market. +For markets with a parent market we take `T(0)` to be the most recent `T_{parent}(latest)`. From this we calculate the running average trade value for fee purposes: -```math +```text A(0) <- T(0), A(n) <- A(n-1) x n/(n+1) + T(n)/(n+1), for `n=1,2,... ``` @@ -115,7 +122,7 @@ Moreover, in situations when trading volume was zero in the previous period or i The equity-like share for each LP is then -```math +```text (LP i equity-like share) = (LP i virtual stake) / (sum over j from 1 to N of (LP j virtual stake)). ``` @@ -128,7 +135,7 @@ The average entry valuation (which should be reported by the APIs and could be c So `Delta S > 0` (and so `S+Delta S > 0`) in what follows. 2. Calculate the entry valuation at the time stake `Delta S` is added / removed as -```math +```text (entry valuation) = sum over j from 1 to N of (LP j virtual stake) ``` @@ -136,21 +143,21 @@ Note, the `virtual stake` used in the calculation of `entry valuation` is after This in particular means that if this is the first LP commitment on the market then the `(entry valuation) = Delta S`. 3. Update the average entry valuation to -```math +```text (average entry valuation) <- (average entry valuation) x S / (S + Delta S) + (entry valuation) x (Delta S) / (S + Delta S) ``` Example 1: Currently the sum of all virtual stakes is `900`. A new LP has `0` stake and add stake `Delta S = 100`. The sum of all virtual stakes is now `1000`. The average entry valuation is -```math +```text (average entry valuation) <- 0 + 1000 x 100 / (0 + 100) = 1000 ``` Example 2: A new LP1 has `0` stake and they wish to add `Delta S = 8000` and a new LP2 has `0` stake and they wish to add `Delta S = 2000`. Currently the sum of all virtual stakes is `10000` after the LP commitments added. The average entry valuations are: -```math +```text (average entry valuation LP1) <- 0 + 8000 x 8000 / (0 + 8000) = 8000 (average entry valuation LP2) <- 0 + (8000 + 2000) x 2000 / (0 + 2000) = 10000 ``` @@ -158,14 +165,14 @@ A new LP1 has `0` stake and they wish to add `Delta S = 8000` and a new LP2 has Example 3: An existing LP has `average entry valuation 1000` and `S=100`. Currently the sum of all virtual stakes is `2000`. They wish to add `10` to their stake. -```math +```text (average entry valuation) <- 1000 x 100 / (100 + 10) + 2000 x 10 / (100 + 10) = 1090.9.... ``` Example 4: An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the sum of all virtual stakes is `3000`. They wish to remove `20` from their stake. Their average entry valuation stays the same -```math +```text (average entry valuation) = 1090.9 ``` @@ -197,7 +204,10 @@ The liquidity score should always be rounded to 10 decimal places to prevent spu On every trade, liquidity fee should be collected immediately into an account for that market (call it the liquidity fee account). The account is under control of the network and funds from this account will be transferred to a LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the liquidity fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens funds in this account are transferred to the liquidity providers general accounts for the market settlement asset. +This account is not under control of the LP party (they cannot initiate transfers in or out of the account). The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. + +A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. + If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. @@ -211,7 +221,7 @@ If the fees are being distributed as a part of market settlement and distributio We have `4` LPs with equity-like share shares: share as below -```math +```text LP 1 els = 0.65 LP 2 els = 0.25 LP 3 els = 0.1 @@ -219,7 +229,7 @@ LP 3 els = 0.1 Trade happened, and the trade value for fee purposes multiplied by the liquidity fee factor is `103.5 ETH`. The following amounts be collected immediately into the LP fee accounts for the market: -```math +```text 0.65 x 103.5 = 67.275 ETH to LP 1's LP account 0.25 x 103.5 = 25.875 ETH to LP 2's LP account 0.10 x 103.5 = 10.350 ETH to LP 3's LP account @@ -227,7 +237,7 @@ Trade happened, and the trade value for fee purposes multiplied by the liquidity Then LP 4 made a delayed LP commitment, and updated share as below: -```math +```text LP 1 els = 0.43 LP 2 els = 0.17 LP 3 els = 0.07 @@ -236,7 +246,7 @@ LP 4 els = 0.33 When the time defined by `market.liquidity.providers.fee.distributionTimeStep` elapses we do transfers: -```math +```text 67.275 ETH from LP 1's LP account to LP 1's general account 25.875 ETH from LP 2's LP account to LP 2's general account 10.350 ETH from LP 3's LP account to LP 3's general account @@ -295,4 +305,11 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-018) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) + +### successor market + +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-033) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-034) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-035) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-036) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 8d2c6901d..172f36a90 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -81,9 +81,9 @@ When a Market Proposal is not successful, see [governance proposal](./0028-GOVE- ### Pending -When a Market Proposal is successful at the end of the voting period, the Market state becomes "Pending". Currently a Pending Market is always in an [auction call period](./0026-AUCT-auctions.md) that ends at the enactment date as specified in the Market Proposal. +When a Market Proposal is successful at the end of the voting period, the Market state becomes "Pending". Currently a Pending Market is always in an [auction call period](./0026-AUCT-auctions.md) that ends at the enactment date as specified in the Market Proposal if the other conditions for exiting auction period are met (liquidity committed, best static bid / ask present). If, initially, at the specified enactment date it was not possible to leave the auction period, the auction will conclude as soon as possible once the conditions for auction exit are met. -Note: this state represents any market that will be created, which currently means a Market Proposal vote has concluded successfully. In reasonably near future there will be automated market creation e.g. for a series of markets that is voted on once, market creation from a data source (oracle), etc. so market creation and the market lifecycle should be implemented independently of the governance framework and the lifecycle of a proposal. +Note: this state represents any market that will be created, which currently means a Market Proposal vote has concluded successfully. **Entry:** @@ -108,7 +108,7 @@ Auction period ends when any of the following occur: A market becomes Cancelled when a Market Proposal is successful and conditions are not met to transition the Market to the Active state during the Pending period, and the trading terminated data source input rings, see [data sourcing](./0045-DSRC-data_sourcing.md). -When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset and any insurance pool balance should be transferred into the network treasury account for that asset. +When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset. After `network.liquidity.successorLaunchWindowLength` has elapsed since cancellation any insurance pool balance should be transferred into the network treasury account for that asset. Once "cancelled" there must be no open positions tracked by the protocol for the market and any open positions must have been closed including returning all margin and other related collateral if necessary and also notifying downstream event consumers that the positions are closed. Specific position related actions may be unnecessary if the cancelled state is being entered from a state in which there cannot possibly have been any open positions. All data sources that are only referenced by this market should be unregistered. @@ -210,7 +210,6 @@ A market moves from this termination state to Settled when enough information ex - During the transition out of this state: - All final settlement cashflows are calculated and applied (settled) - Margins are transferred back to general accounts - - Insurance pool funds are redistributed - No risk management or price/liquidity monitoring occurs ### Settled @@ -218,9 +217,11 @@ A market moves from this termination state to Settled when enough information ex Once the required data to calculate the settlement cashflows is provided by oracle input for a market in status Trading Terminated, these cashflows are calculated and applied to all traders with an open position (settlement). The positions are then closed and all orders cleared. All money held in margin accounts after final settlement is returned to traders' general accounts. -[Insurance pool funds](./0015-INSR-market_insurance_pool_collateral.md) are transferred to the on-chain treasury for the asset. [LP fees](0042-LIQF-setting_fees_and_rewarding_lps.md) that have been cumulated but not yet paid out are distributed to the market LPs as per the LP spec. -The market can be deleted entirely at this point, from a core perspective. +After `network.liquidity.successorLaunchWindowLength` has elapsed since the settlement time + +- [Insurance pool funds](./0015-INSR-market_insurance_pool_collateral.md) are transferred to the on-chain treasury for the asset for markets that have no successor market, see [governance](./0028-GOVE-governance.md). For markets that have a named successor market the insurance pool balance is transferred to the insurance pool of the successor market. +- The market can be deleted entirely at this point, from a core perspective. **Entry:** @@ -237,7 +238,6 @@ The market can be deleted entirely at this point, from a core perspective. - During the transition into this state: - All final settlement cashflows are calculated and applied (settled) - Margins are transferred back to general accounts - - All insurance pool funds are redistributed or moved to a network wide insurance fund account - All fees are distributed (after a delay/at the next relevant epoch if needed - this means the market may continue to need to be "tracked" by the core until this step is complete) - Market is over and can be removed from core data, nothing happens after the final settlement above is complete. @@ -282,8 +282,9 @@ The market state is `trading terminated`. 1. The settlement price oracle transaction is sent and it is *not* equal to `p`. Parties that had open positions see settlement cash-flows happen. Margin account balances are transferred to the general account. -Any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. The market state is `settled`. +After `network.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. + ### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003) @@ -291,6 +292,6 @@ The market state is `settled`. 1. Trading terminated data source rings before the market leaves the opening auction (so market never left Pending state so far). 1. All orders should be cancelled and collateral returned to respective parties general account for the relevant asset. 1. All LP commitments should be cancelled and their bond returned to the general account for the relevant asset. -1. Any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +1. After `network.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 864c65e02..f605f1ea5 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -15,6 +15,7 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057) + - For Reduce-Only = True orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-056) - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-043) @@ -32,6 +33,7 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) - Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039) + - For Reduce-Only = TRUE orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) - If not enough volume is available to **fully** fill the order, the order will be cancelled(0068-MATC-048) From ebb9afc6a43c34ad938b903588bee7e768641433 Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Wed, 17 May 2023 12:40:52 +0100 Subject: [PATCH 016/649] chore: Add acceptance criteria --- protocol/0000-ETHD-ethereum-data-source.md | 82 +++++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0000-ETHD-ethereum-data-source.md index 77b4356be..4d626b9d2 100644 --- a/protocol/0000-ETHD-ethereum-data-source.md +++ b/protocol/0000-ETHD-ethereum-data-source.md @@ -108,4 +108,84 @@ Select { ## Acceptance criteria -TBD +### External Oracles - Creation: + +1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) +2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment +3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message +4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) + +### External Oracles - Amendments: +1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted. +2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted , the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted. +3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted. + +### External Oracles - Deletions: +1. Ability to delete a data source if and only if the data source is NOT used by any active markets +2. Should NOT be able to delete a data source if its being actively used by a market +3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source + +### External Oracles - Validations: +1. Validate if the smart contract address is valid +2. Validate if the data elements of the oracle data source is valid - e.g. source for a value thats returned as boolean but have a filter / condition for greater than 0 +3. Validations for min / max frequency of listening for events / read a smart contract +4. Create a new market with an inactive external oracle data source, system should throw an error +5. Validations to be applied - need to be expanded +6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event + +### New Network parameters: + +1. Test min / max values / validations for any new network parameters that are added +2. Test the impact / behavior of the system, after the changes to the new network params are enacted + +### Negative Tests: + +1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) +2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value +3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this +4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error +5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error +6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting. + +### API: + +1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired / +2. Ability to query historic data sent by an oracle data source + +### Non Functional: + +1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out +2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 mins and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event +3. Phase 2 - Define behavior for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition. +4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed +5. SPAM rules if any defined should be tested for +6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly +7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market + +### Usage: + +1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles +2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market +3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market +4. Data sourcing should be completely decoupled from data filtering + +### Checkpoints: + +1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints +2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config. + +### Snapshots: + +1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots. +2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config. + +### Protocol Upgrade: + +1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade. +2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade. +3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config. + +### Regression: + +1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one. + From b8330e4d689fa7fef5fab165a2713d47812f426e Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 6 Jan 2023 11:41:03 +0000 Subject: [PATCH 017/649] feat: add spec 0080 for Spot product --- protocol/0080-SPOT-product_builtin_spot.md | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 protocol/0080-SPOT-product_builtin_spot.md diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md new file mode 100644 index 000000000..ca1c5f4b1 --- /dev/null +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -0,0 +1,48 @@ +# Built-in [Product](./0051-PROD-product.md): Spot + +This built-in product provides spot contracts which allow the buying and selling of a "base" asset with a "quote" asset with immediate delivery (settlement). + +When trading with Spot products, parties can only use assets they own - there is no leverage or margin. As such, target stake is to be calculated from volume over a period defined by the liquidity monitoring parameter `target_stake_parameter.time_window` rather than open interest. + + +## 1. Product parameters + +1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. (This would usually be a date/time based trigger but may also use an oracle.) This will move market to `cancelled` state if market never left `pending state` (opening auction). +1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. +1. `base_asset (Settlement Asset)`: this is used to specify the asset to be purchased or sold on the market. +1. `quote_asset (Settlement Asset)`: this is used to specify the asset which can be exchanged for the base asset. + + +## 2. Settlement assets + +1. Returns `[spot.base_asset, spot.quote_asset]` + +## 3. Valuation function +```javascript + +``` + + +## 4. Lifecycle triggers + +### 4.1 Termination of trading + +```javascript +spot.trading_termination_trigger(event) { + setMarketStatus(TRADING_TERMINATED) +} +``` + + +# Acceptance Criteria + +1. Settlement assets + 1. A product of any type cannot be created without specifying an enabled settlement asset for the base asset (0080-SPOT-001) + 1. A product of any type cannot be created without specifying an enabled settlement asset for the quote asset (0080-SPOT-002) + 1. A Spot product can be created for any pair or enabled assets that are configured in Vega (0080-SPOT-003) +1. Lifecycle triggers + 1. A Spot product can be created with trading termination triggered by a date/time based data source (0080-SPOT-004) + 2. A Spot product can be created with trading termination triggered by an external data source (0080-SPOT-005) +1. Governance + 1. Settlement assets cannot be changed through governance (0080-SPOT-006) + 1. Either data-source can be changed through governance (0080-SPOT-007) \ No newline at end of file From f0c7d9d4e583afa992fcb9736d856333dcfc8de7 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 6 Jan 2023 14:41:45 +0000 Subject: [PATCH 018/649] refactor: reformat spec into new template --- protocol/0080-SPOT-product_builtin_spot.md | 73 +++++++++++++++------- 1 file changed, 49 insertions(+), 24 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index ca1c5f4b1..9ebc3d11d 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -1,48 +1,73 @@ # Built-in [Product](./0051-PROD-product.md): Spot -This built-in product provides spot contracts which allow the buying and selling of a "base" asset with a "quote" asset with immediate delivery (settlement). +This built-in product provides spot contracts which allow the buying and selling of a "base" asset with a "quote" asset for immediate delivery. -When trading with Spot products, parties can only use assets they own - there is no leverage or margin. As such, target stake is to be calculated from volume over a period defined by the liquidity monitoring parameter `target_stake_parameter.time_window` rather than open interest. +When trading Spot products, parties can only use assets they own - there is no leverage or margin. ## 1. Product parameters -1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. (This would usually be a date/time based trigger but may also use an oracle.) This will move market to `cancelled` state if market never left `pending state` (opening auction). 1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. 1. `base_asset (Settlement Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Settlement Asset)`: this is used to specify the asset which can be exchanged for the base asset. +1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger would usually be a datetime based trigger but may also use an oracle. +## 2. Market parameters -## 2. Settlement assets +1. `base_decimal_places`: sets the number of decimal places of the `base` asset when specifying order size (specified in place of `position_decimal_places`). +1. `quote_decimal_places`: sets the number of decimal places of the `quote` asset when specifying order price (specified in place of `market_decimal_places`). -1. Returns `[spot.base_asset, spot.quote_asset]` -## 3. Valuation function -```javascript +## 3. Trading +1. When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. + +1. If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. + +1. When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. + + +## 4. Liquidity Fees + +As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake` from `max_oi` over a `time_window`. + +For `Spot` products either a new method of calculating `target_stake` or an entire new method of determining the market `liquidity_fee` is required. + +### 4.2 Option 1 + +Keeping the current `liquidity_fee` selection method implemented for `future` products, `target_stake` should be calculated as follows: +``` +target_stake = volume over time-window * mark price * target_stake_scaling_factor ``` +### 4.1 Option 2 + +In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by a market parameter). + +``` +Example 1: + +liquidity_fee_consensus = 0.49 + +LP1 commits 2000 ETH @ 0.01 fee +LP2 commits 1000 ETH @ 0.02 fee +LP3 commits 1000 ETH @ 0.03 fee + +liquidity_fee_factor = 0.01 +``` +``` +Example 2: -## 4. Lifecycle triggers +liquidity_fee_consensus = 0.51 -### 4.1 Termination of trading +LP1 commits 2000 ETH @ 0.01 fee +LP2 commits 1000 ETH @ 0.02 fee +LP3 commits 1000 ETH @ 0.03 fee -```javascript -spot.trading_termination_trigger(event) { - setMarketStatus(TRADING_TERMINATED) -} +liquidity_fee_factor = 0.02 ``` -# Acceptance Criteria +## 5. Auctions -1. Settlement assets - 1. A product of any type cannot be created without specifying an enabled settlement asset for the base asset (0080-SPOT-001) - 1. A product of any type cannot be created without specifying an enabled settlement asset for the quote asset (0080-SPOT-002) - 1. A Spot product can be created for any pair or enabled assets that are configured in Vega (0080-SPOT-003) -1. Lifecycle triggers - 1. A Spot product can be created with trading termination triggered by a date/time based data source (0080-SPOT-004) - 2. A Spot product can be created with trading termination triggered by an external data source (0080-SPOT-005) -1. Governance - 1. Settlement assets cannot be changed through governance (0080-SPOT-006) - 1. Either data-source can be changed through governance (0080-SPOT-007) \ No newline at end of file +As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is also no need for liquidity auctions. From 52a6c2b395281991ce8eae5562e849f281d92fb6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 16 Jan 2023 15:26:14 +0000 Subject: [PATCH 019/649] feat: update liquidity fees section --- protocol/0080-SPOT-product_builtin_spot.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 9ebc3d11d..322ff472a 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -39,6 +39,11 @@ Keeping the current `liquidity_fee` selection method implemented for `future` pr ``` target_stake = volume over time-window * mark price * target_stake_scaling_factor ``` +#### Advantages +- Prevents LPs removing a commitment whenever they like, due to mechanics in 0044-LIME. +- The fee is tied to activity in a market, prevents a whale forcing a high fee by providing a large liquidity commitment where it is not needed (need to clarify the need for liquidity in a Spot market). +#### Disadvantages +- Possible there is no need for a high target-stake (and therefore high-fee) just because there has been a high traded volume over the last time-window (again need to clarify the need for liquidity in a Spot market). ### 4.1 Option 2 @@ -66,6 +71,9 @@ LP3 commits 1000 ETH @ 0.03 fee liquidity_fee_factor = 0.02 ``` +#### Advantages +#### Disadvantages +- With the absence of target-stake, there is nothing currently preventing an LP removing a liquidity commitment (only current reason not to do so is loss of virtual stake from market growth). ## 5. Auctions From c69ee06a22c458aeb22b28249fc3fe2e45b7532b Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Jan 2023 11:11:27 +0000 Subject: [PATCH 020/649] feat: add liquidity commitment section --- protocol/0080-SPOT-product_builtin_spot.md | 54 ++++++++++------------ 1 file changed, 24 insertions(+), 30 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 322ff472a..e9abe08f3 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -8,51 +8,49 @@ When trading Spot products, parties can only use assets they own - there is no l ## 1. Product parameters 1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. -1. `base_asset (Settlement Asset)`: this is used to specify the asset to be purchased or sold on the market. -1. `quote_asset (Settlement Asset)`: this is used to specify the asset which can be exchanged for the base asset. +1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. +1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. 1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger would usually be a datetime based trigger but may also use an oracle. -## 2. Market parameters +## 2. Network parameters: + +1. `spot_obligation_calculation_window`: time (in seconds) between recalculation of the amount of the `base_asset` which must be locked in the bond account for the `base_asset`. +1. `spot_commitment_lock_window`: time (in seconds) which a commitment is "locked" after it is submitted or amended before it can be amended or cancelled. +1. `spot_liquidity_fee_consensus`: required fraction of LPs to propose a liquidity fee (or lower) for it to be accepted + +## 3. Market parameters 1. `base_decimal_places`: sets the number of decimal places of the `base` asset when specifying order size (specified in place of `position_decimal_places`). 1. `quote_decimal_places`: sets the number of decimal places of the `quote` asset when specifying order price (specified in place of `market_decimal_places`). -## 3. Trading +## 4. Trading -1. When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. +- When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. -1. If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. +- If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. -1. When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. +- When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. -## 4. Liquidity Fees +## 5. Liquidity Commitments -As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake` from `max_oi` over a `time_window`. +- When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake. To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` at the current `spot_price` for the commitment to be valid. Both the committed amount of the `quote_asset` and committed amount of the `base_asset` will then be locked in two separate bond accounts. -For `Spot` products either a new method of calculating `target_stake` or an entire new method of determining the market `liquidity_fee` is required. +- Every n seconds (n being controlled by the network parameter `spot_obligation_calculation_window`), the required amount of the `base_asset` to be locked in the bond account will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. -### 4.2 Option 1 +- To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. -Keeping the current `liquidity_fee` selection method implemented for `future` products, `target_stake` should be calculated as follows: -``` -target_stake = volume over time-window * mark price * target_stake_scaling_factor -``` -#### Advantages -- Prevents LPs removing a commitment whenever they like, due to mechanics in 0044-LIME. -- The fee is tied to activity in a market, prevents a whale forcing a high fee by providing a large liquidity commitment where it is not needed (need to clarify the need for liquidity in a Spot market). -#### Disadvantages -- Possible there is no need for a high target-stake (and therefore high-fee) just because there has been a high traded volume over the last time-window (again need to clarify the need for liquidity in a Spot market). +## 6. Liquidity Fees -### 4.1 Option 2 +- As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. -In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by a market parameter). +- In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). ``` Example 1: -liquidity_fee_consensus = 0.49 +spot_liquidity_fee_consensus = 0.49 LP1 commits 2000 ETH @ 0.01 fee LP2 commits 1000 ETH @ 0.02 fee @@ -63,7 +61,7 @@ liquidity_fee_factor = 0.01 ``` Example 2: -liquidity_fee_consensus = 0.51 +spot_liquidity_fee_consensus = 0.51 LP1 commits 2000 ETH @ 0.01 fee LP2 commits 1000 ETH @ 0.02 fee @@ -71,11 +69,7 @@ LP3 commits 1000 ETH @ 0.03 fee liquidity_fee_factor = 0.02 ``` -#### Advantages -#### Disadvantages -- With the absence of target-stake, there is nothing currently preventing an LP removing a liquidity commitment (only current reason not to do so is loss of virtual stake from market growth). - -## 5. Auctions +## 7. Auctions -As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is also no need for liquidity auctions. +As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. From 83317268a1fce5f38eabfeb181855647727be940 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Jan 2023 11:13:02 +0000 Subject: [PATCH 021/649] fix: corrections for linting --- protocol/0080-SPOT-product_builtin_spot.md | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index e9abe08f3..33af67fb5 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -4,47 +4,35 @@ This built-in product provides spot contracts which allow the buying and selling When trading Spot products, parties can only use assets they own - there is no leverage or margin. - ## 1. Product parameters 1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. 1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger would usually be a datetime based trigger but may also use an oracle. - ## 2. Network parameters: 1. `spot_obligation_calculation_window`: time (in seconds) between recalculation of the amount of the `base_asset` which must be locked in the bond account for the `base_asset`. 1. `spot_commitment_lock_window`: time (in seconds) which a commitment is "locked" after it is submitted or amended before it can be amended or cancelled. 1. `spot_liquidity_fee_consensus`: required fraction of LPs to propose a liquidity fee (or lower) for it to be accepted - ## 3. Market parameters 1. `base_decimal_places`: sets the number of decimal places of the `base` asset when specifying order size (specified in place of `position_decimal_places`). 1. `quote_decimal_places`: sets the number of decimal places of the `quote` asset when specifying order price (specified in place of `market_decimal_places`). - ## 4. Trading - When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. - - If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. - - When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. - - ## 5. Liquidity Commitments - When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake. To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` at the current `spot_price` for the commitment to be valid. Both the committed amount of the `quote_asset` and committed amount of the `base_asset` will then be locked in two separate bond accounts. - - Every n seconds (n being controlled by the network parameter `spot_obligation_calculation_window`), the required amount of the `base_asset` to be locked in the bond account will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. - - To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. - ## 6. Liquidity Fees - As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. - - In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). ``` @@ -58,6 +46,7 @@ LP3 commits 1000 ETH @ 0.03 fee liquidity_fee_factor = 0.01 ``` + ``` Example 2: @@ -69,7 +58,6 @@ LP3 commits 1000 ETH @ 0.03 fee liquidity_fee_factor = 0.02 ``` - ## 7. Auctions As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. From b3041eaad3a14c8252ef9eb2a84a2dacf353b59e Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Jan 2023 11:17:52 +0000 Subject: [PATCH 022/649] fix: corrections for linting --- protocol/0080-SPOT-product_builtin_spot.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 33af67fb5..a3582f077 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -10,11 +10,13 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. 1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger would usually be a datetime based trigger but may also use an oracle. + ## 2. Network parameters: 1. `spot_obligation_calculation_window`: time (in seconds) between recalculation of the amount of the `base_asset` which must be locked in the bond account for the `base_asset`. 1. `spot_commitment_lock_window`: time (in seconds) which a commitment is "locked" after it is submitted or amended before it can be amended or cancelled. 1. `spot_liquidity_fee_consensus`: required fraction of LPs to propose a liquidity fee (or lower) for it to be accepted + ## 3. Market parameters 1. `base_decimal_places`: sets the number of decimal places of the `base` asset when specifying order size (specified in place of `position_decimal_places`). @@ -25,17 +27,19 @@ When trading Spot products, parties can only use assets they own - there is no l - When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. - If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. - When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. + ## 5. Liquidity Commitments - When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake. To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` at the current `spot_price` for the commitment to be valid. Both the committed amount of the `quote_asset` and committed amount of the `base_asset` will then be locked in two separate bond accounts. - Every n seconds (n being controlled by the network parameter `spot_obligation_calculation_window`), the required amount of the `base_asset` to be locked in the bond account will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. - To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. + ## 6. Liquidity Fees - As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. - In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). -``` +```psuedo Example 1: spot_liquidity_fee_consensus = 0.49 @@ -47,7 +51,7 @@ LP3 commits 1000 ETH @ 0.03 fee liquidity_fee_factor = 0.01 ``` -``` +```psuedo Example 2: spot_liquidity_fee_consensus = 0.51 @@ -58,6 +62,7 @@ LP3 commits 1000 ETH @ 0.03 fee liquidity_fee_factor = 0.02 ``` + ## 7. Auctions As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. From 7c02ad119408bccac7d1f1f5277aac4229bd6e61 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 30 Jan 2023 11:19:39 +0000 Subject: [PATCH 023/649] fix: corrections for linting --- protocol/0080-SPOT-product_builtin_spot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index a3582f077..de6f3ed75 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -11,7 +11,7 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. 1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger would usually be a datetime based trigger but may also use an oracle. -## 2. Network parameters: +## 2. Network parameters 1. `spot_obligation_calculation_window`: time (in seconds) between recalculation of the amount of the `base_asset` which must be locked in the bond account for the `base_asset`. 1. `spot_commitment_lock_window`: time (in seconds) which a commitment is "locked" after it is submitted or amended before it can be amended or cancelled. From 07e8717c9a97bc216346616a7a7a0a7ad849e5c6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 6 Feb 2023 11:26:50 +0000 Subject: [PATCH 024/649] feat: add liquidity shortfall section --- protocol/0080-SPOT-product_builtin_spot.md | 61 ++++++++++++++++------ 1 file changed, 44 insertions(+), 17 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index de6f3ed75..f2959a64b 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -9,13 +9,13 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. -1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger would usually be a datetime based trigger but may also use an oracle. +1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger may be a datetime trigger, oracle, or governance event. ## 2. Network parameters 1. `spot_obligation_calculation_window`: time (in seconds) between recalculation of the amount of the `base_asset` which must be locked in the bond account for the `base_asset`. 1. `spot_commitment_lock_window`: time (in seconds) which a commitment is "locked" after it is submitted or amended before it can be amended or cancelled. -1. `spot_liquidity_fee_consensus`: required fraction of LPs to propose a liquidity fee (or lower) for it to be accepted +1. `spot_liquidity_fee_consensus`: required fraction of LPs (scaled by their commitments) to propose a liquidity fee (or lower) for it to be accepted. ## 3. Market parameters @@ -24,29 +24,52 @@ When trading Spot products, parties can only use assets they own - there is no l ## 4. Trading -- When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. -- If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. -- When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. +When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. + +If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. + +When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. ## 5. Liquidity Commitments -- When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake. To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` at the current `spot_price` for the commitment to be valid. Both the committed amount of the `quote_asset` and committed amount of the `base_asset` will then be locked in two separate bond accounts. -- Every n seconds (n being controlled by the network parameter `spot_obligation_calculation_window`), the required amount of the `base_asset` to be locked in the bond account will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. -- To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. +When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake (the `quote_commitment_amount`). To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` (the `base_commitment_amount`) at the current `spot_price` for the commitment to be valid. Both the `quote_commitment_amount` and the `base_commitment_amount` will then be locked in two separate bond accounts. + +```pseudo +quote_asset: USD +base_asset: ETH + +spot_price = 1000 USD + +quote_commitment_amount = 10000 usd +base_commitment_amount = quote_commitment_amount / spot_price = 10000 / 1000 = 10 ETH +``` + +Every `n` seconds (`n` being controlled by the network parameter `spot_obligation_calculation_window`), the required `base_commitment_amount` to be locked in the bond account will be recalculated using the current +`spot_price`. Funds can then be released from the bond account to the general account or vice versa. + +To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. -## 6. Liquidity Fees +## 6. Liquidity Shortfalls -- As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. -- In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). +If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall. As there is no need for an insurance pool in a spot market, there is no need for a bond penalty. + +An LPs `quote_commitment_amount` or `base_commitment_amount` must be recalculated whenever funds from a `base_bond_account` or `quote_bond_account` are used to cover a shortfall respectively. + + +## 7. Liquidity Fees + +As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. + +In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). ```psuedo Example 1: spot_liquidity_fee_consensus = 0.49 -LP1 commits 2000 ETH @ 0.01 fee -LP2 commits 1000 ETH @ 0.02 fee -LP3 commits 1000 ETH @ 0.03 fee +LP1 commits 2000 USD @ 0.01 fee +LP2 commits 1000 USD @ 0.02 fee +LP3 commits 1000 USD @ 0.03 fee liquidity_fee_factor = 0.01 ``` @@ -56,9 +79,9 @@ Example 2: spot_liquidity_fee_consensus = 0.51 -LP1 commits 2000 ETH @ 0.01 fee -LP2 commits 1000 ETH @ 0.02 fee -LP3 commits 1000 ETH @ 0.03 fee +LP1 commits 2000 USD @ 0.01 fee +LP2 commits 1000 USD @ 0.02 fee +LP3 commits 1000 USD @ 0.03 fee liquidity_fee_factor = 0.02 ``` @@ -66,3 +89,7 @@ liquidity_fee_factor = 0.02 ## 7. Auctions As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. + +Price-monitoring auctions are still required and should be implemented following the [price-monitoring](./0032-PRIM-price_monitoring.md) spec. + +## 8. Acceptance Criteria From d21aeb60dc21e805ca09b29cc447ef971797d23c Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 6 Feb 2023 11:54:39 +0000 Subject: [PATCH 025/649] feat: add acceptance criteria --- protocol/0080-SPOT-product_builtin_spot.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index f2959a64b..fb4f500f7 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -9,7 +9,7 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. -1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger may be a datetime trigger, oracle, or governance event. +1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger may be a datetime trigger or an oracle. Note: a `Spot` market may also be terminated through governance. ## 2. Network parameters @@ -35,16 +35,18 @@ When an order is fulfilled or cancelled any remaining funds in the `holding` acc When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake (the `quote_commitment_amount`). To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` (the `base_commitment_amount`) at the current `spot_price` for the commitment to be valid. Both the `quote_commitment_amount` and the `base_commitment_amount` will then be locked in two separate bond accounts. ```pseudo +Example: + quote_asset: USD base_asset: ETH spot_price = 1000 USD -quote_commitment_amount = 10000 usd +quote_commitment_amount = 10000 USD base_commitment_amount = quote_commitment_amount / spot_price = 10000 / 1000 = 10 ETH ``` -Every `n` seconds (`n` being controlled by the network parameter `spot_obligation_calculation_window`), the required `base_commitment_amount` to be locked in the bond account will be recalculated using the current +Every `n` seconds (`n` being controlled by the network parameter `spot_obligation_calculation_window`), the required `base_commitment_amount`, to be locked in the bond account, will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. @@ -93,3 +95,14 @@ As there is no margin or leverage when dealing with `Spot` products, there is no Price-monitoring auctions are still required and should be implemented following the [price-monitoring](./0032-PRIM-price_monitoring.md) spec. ## 8. Acceptance Criteria + +1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-COSMICELEVATOR-001) +1. It is not possible to change the `quote_asset` via governance (0080-COSMICELEVATOR-002) +1. It is not possible to change the `base_asset` via governance (0080-COSMICELEVATOR-003) +1. A `Spot` market can be terminated through governance (0080-COSMICELEVATOR-004) +1. Parties are unable to place orders they do not have the necessary funds for (0080-COSMICELEVATOR-005) +1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-COSMICELEVATOR-006) +1. Market liqudity fees are calculated correctly (0080-COSMICELEVATOR-007) + + From 2c1f1c87b8905aa0288dc5a10ca027b000293602 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 6 Feb 2023 12:03:12 +0000 Subject: [PATCH 026/649] fix: correct linting fails --- protocol/0080-SPOT-product_builtin_spot.md | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index fb4f500f7..eae2961ba 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -46,8 +46,7 @@ quote_commitment_amount = 10000 USD base_commitment_amount = quote_commitment_amount / spot_price = 10000 / 1000 = 10 ETH ``` -Every `n` seconds (`n` being controlled by the network parameter `spot_obligation_calculation_window`), the required `base_commitment_amount`, to be locked in the bond account, will be recalculated using the current -`spot_price`. Funds can then be released from the bond account to the general account or vice versa. +Every `n` seconds (`n` being controlled by the network parameter `spot_obligation_calculation_window`), the required `base_commitment_amount`, to be locked in the bond account, will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. @@ -57,7 +56,6 @@ If at any point in time, a liquidity provider has insufficient capital in their An LPs `quote_commitment_amount` or `base_commitment_amount` must be recalculated whenever funds from a `base_bond_account` or `quote_bond_account` are used to cover a shortfall respectively. - ## 7. Liquidity Fees As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. @@ -96,13 +94,10 @@ Price-monitoring auctions are still required and should be implemented following ## 8. Acceptance Criteria -1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-COSMICELEVATOR-001) +1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-COSMICELEVATOR-001) 1. It is not possible to change the `quote_asset` via governance (0080-COSMICELEVATOR-002) 1. It is not possible to change the `base_asset` via governance (0080-COSMICELEVATOR-003) 1. A `Spot` market can be terminated through governance (0080-COSMICELEVATOR-004) 1. Parties are unable to place orders they do not have the necessary funds for (0080-COSMICELEVATOR-005) 1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-COSMICELEVATOR-006) -1. Market liqudity fees are calculated correctly (0080-COSMICELEVATOR-007) - - +1. Market liquidity fees are calculated correctly (0080-COSMICELEVATOR-007) From d6b472c1d826b7a10f00ad9fdac018585365b50e Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 13 Feb 2023 15:53:50 +0000 Subject: [PATCH 027/649] refactor: segregated commitments --- protocol/0080-SPOT-product_builtin_spot.md | 26 +++++++++------------- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index eae2961ba..8c86f012d 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -32,23 +32,11 @@ When an order is fulfilled or cancelled any remaining funds in the `holding` acc ## 5. Liquidity Commitments -When submitting a liquidity commitment, an LP will specify the amount of the `quote_asset` they are willing to stake (the `quote_commitment_amount`). To ensure the LP is providing an equal amount of liquidity on each side of the book, they will also need to have a sufficient amount of the `base_asset` (the `base_commitment_amount`) at the current `spot_price` for the commitment to be valid. Both the `quote_commitment_amount` and the `base_commitment_amount` will then be locked in two separate bond accounts. +When a Liquidity Provider submits a liquidity commitment to a market, they are able to submit a separate commitment for each side of the market. There is no requirement to submit a commitment on both sides of the market or submit commitments of equal value. -```pseudo -Example: +Liquidity commitments on the "BUY" side of the market must be specified in the `quote_asset` and commitments on the "SELL" side of the market must be specified in the `base_asset`. For a commitment to be valid, the LP must have a sufficient amount of the relevant asset. This will be locked in the `bond_account` for that market asset pair. -quote_asset: USD -base_asset: ETH - -spot_price = 1000 USD - -quote_commitment_amount = 10000 USD -base_commitment_amount = quote_commitment_amount / spot_price = 10000 / 1000 = 10 ETH -``` - -Every `n` seconds (`n` being controlled by the network parameter `spot_obligation_calculation_window`), the required `base_commitment_amount`, to be locked in the bond account, will be recalculated using the current `spot_price`. Funds can then be released from the bond account to the general account or vice versa. - -To prevent LPs frequently providing, amending, and cancelling liquidity commitment amounts; all liquidity commitments will be "locked" for a certain period of time before the amount can be amended or the the entire commitment cancelled. This period of time will be controlled with a network parameter `spot_commitment_lock_length`. +To prevent LPs frequently reducing or cancelling liquidity commitments; liquidity cancellations or amendments which reduce the committed amount will not be enacted until the end of the current trading window. Liquidity amendments which increase the commitment amount or amend the liquidity shape will be allowed and enacted instantly. ## 6. Liquidity Shortfalls @@ -86,6 +74,14 @@ LP3 commits 1000 USD @ 0.03 fee liquidity_fee_factor = 0.02 ``` +As LPs are able to make un-equal commitments on each side of the book, a separate liquidity fee should be calculated for buy and sell orders. + +- liquidity fee for **buy** orders should be calculated from the pool of liquidity committed on the **sell** side. +- the liquidity fee for **sell** orders should be calculated from the pool of liquidity commitments on the **buy** side. + +Fees gathered from buy and sell orders should also be transferred to a separate liquidity pool. An LPs share of the buy fees or sell fees is calculating using their **buy** and **sell** commitments respectively. + + ## 7. Auctions As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. From bc351b35574bbced0bfdce4628f471ba9a3aff83 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 20 Feb 2023 11:03:19 +0000 Subject: [PATCH 028/649] refactor: research hour feedback --- protocol/0080-SPOT-product_builtin_spot.md | 74 +++++++++++++++------- 1 file changed, 52 insertions(+), 22 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 8c86f012d..522fdc8f4 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -22,42 +22,70 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_decimal_places`: sets the number of decimal places of the `base` asset when specifying order size (specified in place of `position_decimal_places`). 1. `quote_decimal_places`: sets the number of decimal places of the `quote` asset when specifying order price (specified in place of `market_decimal_places`). -## 4. Trading +## 4. Liquidity Commitments -When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. - -If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. +A Liquidity Provision submitted to a market must commit liquidity on both sides of the book in a single commitment. The LP can specify a separate commitment amount for the buy side and sell side of the market. These commitment amounts are specified in the `quote_asset` and `base_asset` respectively. -When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. +```psuedo +Example `LiquidityProvisionSubmission` command to an ETH/DAI market: + +submission = { + "liquidityProvisionSubmission": + { + marketId: "abcdefghik1lkmopqrstuvwxyz", + fee: "0.01", + buyCommitmentAmount: 15000 + buys: [ + { + offset: "1" + proportion: "1" + reference: "PEGGED_REFERENCE_BEST_BID" + } + ] + sellCommitmentAmount: 10 + sells: [ + { + offset: "1" + proportion: "1" + reference: "PEGGED_REFERENCE_BEST_ASK" + } + ] + reference: "example_liquidity_provision_submission" + } +} +``` -## 5. Liquidity Commitments +As the LP now has a different commitment amount on each side of the book, the following considerations must be made: -When a Liquidity Provider submits a liquidity commitment to a market, they are able to submit a separate commitment for each side of the market. There is no requirement to submit a commitment on both sides of the market or submit commitments of equal value. +- An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake` where the current `virtual_stake` for fee splitting is the smaller of the two values. +- An LPs `liquidity_score` should be treated separately for each side of the book - call these the `buy_liquidity_score` and the `sell_liquidity_score` where the current `liquidity_score` for fee splitting is the smaller of the two values. -Liquidity commitments on the "BUY" side of the market must be specified in the `quote_asset` and commitments on the "SELL" side of the market must be specified in the `base_asset`. For a commitment to be valid, the LP must have a sufficient amount of the relevant asset. This will be locked in the `bond_account` for that market asset pair. +The above conditions will incentivise LPs to provide an equal value of liquidity to both sides of the book at comparable levels of competitiveness. To prevent LPs frequently reducing or cancelling liquidity commitments; liquidity cancellations or amendments which reduce the committed amount will not be enacted until the end of the current trading window. Liquidity amendments which increase the commitment amount or amend the liquidity shape will be allowed and enacted instantly. -## 6. Liquidity Shortfalls +## 5. Liquidity Shortfalls -If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall. As there is no need for an insurance pool in a spot market, there is no need for a bond penalty. +If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall. -An LPs `quote_commitment_amount` or `base_commitment_amount` must be recalculated whenever funds from a `base_bond_account` or `quote_bond_account` are used to cover a shortfall respectively. +As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global insurance pool for that asset. -## 7. Liquidity Fees +## 6. Liquidity Fees As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). +An LPs influence in the "vote" is weighted by their current equity_like_share and liquidity_score. + ```psuedo Example 1: spot_liquidity_fee_consensus = 0.49 -LP1 commits 2000 USD @ 0.01 fee -LP2 commits 1000 USD @ 0.02 fee -LP3 commits 1000 USD @ 0.03 fee +LP1, equity_like_share=0.50 and liquidity_score=0.50, commits @ fee = 0.01 +LP2, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.02 +LP3, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.03 liquidity_fee_factor = 0.01 ``` @@ -67,20 +95,22 @@ Example 2: spot_liquidity_fee_consensus = 0.51 -LP1 commits 2000 USD @ 0.01 fee -LP2 commits 1000 USD @ 0.02 fee -LP3 commits 1000 USD @ 0.03 fee +LP1, equity_like_share=0.50 and liquidity_score=0.50, commits @ fee = 0.01 +LP2, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.02 +LP3, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.03 liquidity_fee_factor = 0.02 ``` -As LPs are able to make un-equal commitments on each side of the book, a separate liquidity fee should be calculated for buy and sell orders. +To stabilise liquidity fees, liquidity fees are calculated using LPs `equity_like_share` and `liquidity_score` values at the end of the last window. The fee is then locked for the duration of the next window. -- liquidity fee for **buy** orders should be calculated from the pool of liquidity committed on the **sell** side. -- the liquidity fee for **sell** orders should be calculated from the pool of liquidity commitments on the **buy** side. +## 7. Trading -Fees gathered from buy and sell orders should also be transferred to a separate liquidity pool. An LPs share of the buy fees or sell fees is calculating using their **buy** and **sell** commitments respectively. +When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. +If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. + +When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. ## 7. Auctions From cad1bd5aafec9faadeaf0fee4e356d62fd3ecc9a Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 22 Feb 2023 13:39:14 +0000 Subject: [PATCH 029/649] refactor: parameter changes --- protocol/0080-SPOT-product_builtin_spot.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 522fdc8f4..6d6512590 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -6,10 +6,8 @@ When trading Spot products, parties can only use assets they own - there is no l ## 1. Product parameters -1. `base_quote_pair (Explicit Value)`: human readable name/abbreviation of the base/quote pair. 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. -1. `trading_termination_trigger (Data Source)`: triggers the market to move to `trading terminated` status. This trigger may be a datetime trigger or an oracle. Note: a `Spot` market may also be terminated through governance. ## 2. Network parameters @@ -19,8 +17,8 @@ When trading Spot products, parties can only use assets they own - there is no l ## 3. Market parameters -1. `base_decimal_places`: sets the number of decimal places of the `base` asset when specifying order size (specified in place of `position_decimal_places`). -1. `quote_decimal_places`: sets the number of decimal places of the `quote` asset when specifying order price (specified in place of `market_decimal_places`). +1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. Future specs could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. +1. `position_decimal_places` should be used to specify the number of decimal places of the `base_asset` asset when specifying order size. Future iterations of specs could rename `position_decimal_places` to something more general, e.g. `position_decimal_places`. ## 4. Liquidity Commitments From 73906c7c475a11ae9dcfcda4d7973321145c5772 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 24 Feb 2023 09:51:56 +0000 Subject: [PATCH 030/649] refactor: minor changes --- protocol/0080-SPOT-product_builtin_spot.md | 95 +++++++++++++++------- 1 file changed, 64 insertions(+), 31 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 6d6512590..b6f542753 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -9,11 +9,10 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. -## 2. Network parameters +## 2. Liquidity Monitoring parameters -1. `spot_obligation_calculation_window`: time (in seconds) between recalculation of the amount of the `base_asset` which must be locked in the bond account for the `base_asset`. -1. `spot_commitment_lock_window`: time (in seconds) which a commitment is "locked" after it is submitted or amended before it can be amended or cancelled. -1. `spot_liquidity_fee_consensus`: required fraction of LPs (scaled by their commitments) to propose a liquidity fee (or lower) for it to be accepted. +1. `time_window`: length of rolling window (in seconds) over which the maximum `total_stake` is measured. +1. `target_stake_factor`: fraction of `total_stake` to be selected as the `target_stake`. ## 3. Market parameters @@ -22,7 +21,9 @@ When trading Spot products, parties can only use assets they own - there is no l ## 4. Liquidity Commitments -A Liquidity Provision submitted to a market must commit liquidity on both sides of the book in a single commitment. The LP can specify a separate commitment amount for the buy side and sell side of the market. These commitment amounts are specified in the `quote_asset` and `base_asset` respectively. +### Submissions + +A liquidity provision submitted to a `Spot` market allows a separate commitment amount to be specified for the buy and sell sides of the market. These commitment amounts are specified in the `quote_asset` and `base_asset` respectively. ```psuedo Example `LiquidityProvisionSubmission` command to an ETH/DAI market: @@ -30,7 +31,7 @@ Example `LiquidityProvisionSubmission` command to an ETH/DAI market: submission = { "liquidityProvisionSubmission": { - marketId: "abcdefghik1lkmopqrstuvwxyz", + marketId: "abcdefghiklkmnopqrstuvwxyz", fee: "0.01", buyCommitmentAmount: 15000 buys: [ @@ -55,56 +56,88 @@ submission = { As the LP now has a different commitment amount on each side of the book, the following considerations must be made: +- An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake` where the current `physical_stake` is the smaller of the two values. - An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake` where the current `virtual_stake` for fee splitting is the smaller of the two values. - An LPs `liquidity_score` should be treated separately for each side of the book - call these the `buy_liquidity_score` and the `sell_liquidity_score` where the current `liquidity_score` for fee splitting is the smaller of the two values. -The above conditions will incentivise LPs to provide an equal value of liquidity to both sides of the book at comparable levels of competitiveness. +From the above conditions, an LP is incentivised to provide an equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. + +It is therefore important LPs are able to freely reduce or increase their commitment amounts to ensure parity between their buy and sell commitments as the `spot_price` moves. + +### Amendments and Cancellations + +A liquidity amendment or cancellation is determined as valid following spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: + +- the `maximum_reduction_amount` should be expressed in the `quote_asset` when reducing the `buy_commitment_amount` and the `base_asset` when reducing the `sell_commitment_amount`. +- the `maximum_reduction_amount` should be `INF` in the case where the liquidity `time_window=Os` (Note: this is not strictly necessary but an LP is effectively able to reduce their commitment to zero anyway in this case through multiple commitments.) + +```pseudo +Market Data: + + base_asset: ETH + quote_asset: DAI + + spot_price = 1000 + +Market Liquidity: + + total_stake = 100,000 DAI (or 100 ETH) + target_stake = 25,000 DAI (or 25 ETH) -To prevent LPs frequently reducing or cancelling liquidity commitments; liquidity cancellations or amendments which reduce the committed amount will not be enacted until the end of the current trading window. Liquidity amendments which increase the commitment amount or amend the liquidity shape will be allowed and enacted instantly. + maximum_reduction_amount = 1000,000 - 25,0000 = 75,000 DAI (or 75 ETH) +``` + +`virtual_stake` values should be updated during liquidity amendments or cancellations following the mechanisms detailed in spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: + +- reducing the `buy_commitment_amount` only reduces the `buy_virtual_stake` +- reducing the `sell_commitment_amount` only reduces the `sell_virtual_stake` -## 5. Liquidity Shortfalls +### Liquidity Shortfalls If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall. As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global insurance pool for that asset. -## 6. Liquidity Fees +## 5. Spot Liquidity Mechanisms +### Market Total Stake -As there is no margin or leverage when dealing with `Spot` products there is no need for a certain level of liquidity to ensure distressed parties can be closed out. There is therefore no need to calculate `target_stake`. +The `total_stake` for a `Spot` market is calculated simply as the sum of each LPs `physical_stake` and should be expressed in the `quote_asset` of the market. -In the absence of a `target_stake` value, the liquidity fee should be determined as the lowest possible fee that a fraction of the committed LPs propose (controlled by the network parameter `spot_liquidity_fee_consensus`). +### Market Target Stake -An LPs influence in the "vote" is weighted by their current equity_like_share and liquidity_score. +The target stake of a market is calculated as a fraction of the maximum `total_stake` over a rolling time window. The fraction is controlled by the parameter `consensus_factor` and the length of the window is controlled by the parameter `time_window`. -```psuedo -Example 1: +```pseudo +e.g. -spot_liquidity_fee_consensus = 0.49 +Given: the following total_stake values -LP1, equity_like_share=0.50 and liquidity_score=0.50, commits @ fee = 0.01 -LP2, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.02 -LP3, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.03 + [time, total_stake] = [[17:59, 12000], [18:01, 11000], [18:30, 9000], [18:59, 10000]] -liquidity_fee_factor = 0.01 -``` +If: the time value and market parameters are -```psuedo -Example 2: + current_time = 19:00 -spot_liquidity_fee_consensus = 0.51 + time_window = 3600s + target_stake_factor = 0.25 -LP1, equity_like_share=0.50 and liquidity_score=0.50, commits @ fee = 0.01 -LP2, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.02 -LP3, equity_like_share=0.25 and liquidity_score=0.25, commits @ fee = 0.03 +Then: the target stake value is -liquidity_fee_factor = 0.02 + target_stake = 0.25 * 11000 = 2750 DAI ``` -To stabilise liquidity fees, liquidity fees are calculated using LPs `equity_like_share` and `liquidity_score` values at the end of the last window. The fee is then locked for the duration of the next window. +The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` indirectly controls the `total_stake` as the amount an LP is able to reduce their commitment is restricted by the `maximum_reduction_amount`. + +### Market Liquidity Fees + +The market liquidity fee is calculated using the same mechanism defined in [0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) with the exception that an LPs `physical_stake` is the minimum of their `buy_physical_stake` and their `sell_physical_stake` where the later must be expressed in the quote_asset at the current spot_price. + +The liquidity fee is re-calculated at the start of a fee distribution epoch and is fixed for that epoch (Note: this may later be applied universally to all products.) + ## 7. Trading -When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. +When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. For sell orders there is no need for the party to have any `quote` asset as the fees can be subtracted from the general account for their base asset `immediately` after trading. If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. @@ -121,7 +154,7 @@ Price-monitoring auctions are still required and should be implemented following 1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-COSMICELEVATOR-001) 1. It is not possible to change the `quote_asset` via governance (0080-COSMICELEVATOR-002) 1. It is not possible to change the `base_asset` via governance (0080-COSMICELEVATOR-003) -1. A `Spot` market can be terminated through governance (0080-COSMICELEVATOR-004) +1. A `Spot` market can be closed through governance (0080-COSMICELEVATOR-004) 1. Parties are unable to place orders they do not have the necessary funds for (0080-COSMICELEVATOR-005) 1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-COSMICELEVATOR-006) 1. Market liquidity fees are calculated correctly (0080-COSMICELEVATOR-007) From 92cf1528509c6b44cb01206b1caea7edfc68c5b6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 24 Feb 2023 10:15:34 +0000 Subject: [PATCH 031/649] refactor: minor tweaks --- protocol/0080-SPOT-product_builtin_spot.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index b6f542753..eb169286c 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -16,8 +16,13 @@ When trading Spot products, parties can only use assets they own - there is no l ## 3. Market parameters -1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. Future specs could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. -1. `position_decimal_places` should be used to specify the number of decimal places of the `base_asset` asset when specifying order size. Future iterations of specs could rename `position_decimal_places` to something more general, e.g. `position_decimal_places`. +1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. + +The Cash Settled Futures spec could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. + +1. `position_decimal_places` should be used to specify the number of decimal places of the `base_asset` asset when specifying order size. + +The Cash Settled Futures spec could rename `position_decimal_places` to something more general, e.g. `size_decimal_places`. ## 4. Liquidity Commitments @@ -135,9 +140,11 @@ The market liquidity fee is calculated using the same mechanism defined in [0042 The liquidity fee is re-calculated at the start of a fee distribution epoch and is fixed for that epoch (Note: this may later be applied universally to all products.) -## 7. Trading +## 6. Trading + +Both buy and sell orders on a `Spot` market define an amount of the `base_asset` to buy or sell at a given price of the `quote_asset`. When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order. -When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order as well as any fees incurred from the order trading instantly. For sell orders there is no need for the party to have any `quote` asset as the fees can be subtracted from the general account for their base asset `immediately` after trading. +(Note: For buy orders the party will need a sufficient amount of the quote asset to cover any fees incurred if the order was to trade instantly. For sell orders, there is no need for the party to have any `quote` asset as the fees can be subtracted from the general account for their base asset immediately after trading). If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. From 8878f99455a6213613a12fa23d046fd75638d4ef Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 24 Feb 2023 11:34:39 +0000 Subject: [PATCH 032/649] refactor: live share updates --- protocol/0041-TSTK-target_stake.md | 34 +++++++++++ protocol/0080-SPOT-product_builtin_spot.md | 66 +++++++++------------- 2 files changed, 61 insertions(+), 39 deletions(-) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index a7d77df0c..fb0779ca6 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -1,5 +1,7 @@ # Target stake +# Target stake for derivatives markets (cash settled futures / perps...) + This spec outlines how to measure how much stake we want committed to a market relative to what is happening on the market (currently open interest). The target stake is a calculated quantity, utilised by various mechanisms in the protocol: @@ -65,3 +67,35 @@ Example 3: if `market.stake.target.scalingFactor = 10`, `rf = 0.004` and `max_oi - if open interest changes to a value that is less then or equal to the maximum open interest over the time window and if the mark price is unchanged, then the liquidity demand doesn't change. (0041-TSTK-003) - Change of `market.stake.target.scalingFactor` will immediately change the scaling between liquidity demand estimate based on open interest and target stake, hence immediately change the target stake. (0041-TSTK-004) - Change of `market.stake.target.timeWindow` will immediately change the length of time window over which open interest is measured, hence will immediately change the value of `max_oi`. (0041-TSTK-005) + + +# Target stake for spot markets + +See [spot market spec](0080-SPOT-product_builtin_spot.md).3600s + +The target stake of a market is calculated as a fraction of the maximum `total_stake` over a rolling time window. The fraction is controlled by the parameter `consensus_factor` and the length of the window is controlled by the parameter `time_window`. + +```pseudo +e.g. + +Given: the following total_stake values + + [time, total_stake] = [[17:59, 12000], [18:01, 11000], [18:30, 9000], [18:59, 10000]] + +If: the time value and market parameters are + + current_time = 19:00 + + time_window = 3600s + target_stake_factor = 0.25 + +Then: the target stake value is + + target_stake = 0.25 * 11000 = 2750 DAI +``` + +The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` indirectly controls the `total_stake` as the amount an LP is able to reduce their commitment is restricted by the `maximum_reduction_amount`. + +### Acceptance criteria + +TBD \ No newline at end of file diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index eb169286c..49086af1f 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -9,6 +9,10 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. +## 1. Network Parameter + +1. `spot_trading_enabled`: parameter defines whether markets using Spot products are enabled on the network. + ## 2. Liquidity Monitoring parameters 1. `time_window`: length of rolling window (in seconds) over which the maximum `total_stake` is measured. @@ -18,11 +22,11 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. -The Cash Settled Futures spec could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. + The Cash Settled Futures spec could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. 1. `position_decimal_places` should be used to specify the number of decimal places of the `base_asset` asset when specifying order size. -The Cash Settled Futures spec could rename `position_decimal_places` to something more general, e.g. `size_decimal_places`. + The Cash Settled Futures spec could rename `position_decimal_places` to something more general, e.g. `size_decimal_places`. ## 4. Liquidity Commitments @@ -61,17 +65,17 @@ submission = { As the LP now has a different commitment amount on each side of the book, the following considerations must be made: -- An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake` where the current `physical_stake` is the smaller of the two values. -- An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake` where the current `virtual_stake` for fee splitting is the smaller of the two values. -- An LPs `liquidity_score` should be treated separately for each side of the book - call these the `buy_liquidity_score` and the `sell_liquidity_score` where the current `liquidity_score` for fee splitting is the smaller of the two values. +- An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake` where the later is expressed in the `quote_asset` converted at the current `mark_price`. The current `physical_stake` is the smaller of the two values. +- An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake`. +- The same growth factor - as specified in the [LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md) - derived from the `total value for fee purposes` in the quote asset is used to update both buy/sell virtual stakes (still in their respective assets). +- The current `virtual_stake` for fee splitting is the smaller of the two values where the `sell_virtual_stake` is converted to `quote_asset` at the current `mark_price`. +- An LPs `liquidity_score` as in [the liquidity score section of the LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md). -From the above conditions, an LP is incentivised to provide an equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. - -It is therefore important LPs are able to freely reduce or increase their commitment amounts to ensure parity between their buy and sell commitments as the `spot_price` moves. +From the above conditions, an LP is incentivised to provide a roughly equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. ### Amendments and Cancellations -A liquidity amendment or cancellation is determined as valid following spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: +A liquidity amendment or a cancellation is determined as valid following spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: - the `maximum_reduction_amount` should be expressed in the `quote_asset` when reducing the `buy_commitment_amount` and the `base_asset` when reducing the `sell_commitment_amount`. - the `maximum_reduction_amount` should be `INF` in the case where the liquidity `time_window=Os` (Note: this is not strictly necessary but an LP is effectively able to reduce their commitment to zero anyway in this case through multiple commitments.) @@ -82,7 +86,7 @@ Market Data: base_asset: ETH quote_asset: DAI - spot_price = 1000 + mark_price = 1000 Market Liquidity: @@ -97,9 +101,12 @@ Market Liquidity: - reducing the `buy_commitment_amount` only reduces the `buy_virtual_stake` - reducing the `sell_commitment_amount` only reduces the `sell_virtual_stake` +A single LP will never be able to reduce their commitment to `0`. They can either keep reducing to a sufficiently small amount they're willing to ignore, or they can submit a governance vote to cancel the market, see the [governance spec](). +For market cancellation proposal a sole LP in the market holds all the voting power (unless governance token holders override them). + ### Liquidity Shortfalls -If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall. +If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall, applying the bond penalty factor (slashing the bond). As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global insurance pool for that asset. @@ -110,43 +117,24 @@ The `total_stake` for a `Spot` market is calculated simply as the sum of each LP ### Market Target Stake -The target stake of a market is calculated as a fraction of the maximum `total_stake` over a rolling time window. The fraction is controlled by the parameter `consensus_factor` and the length of the window is controlled by the parameter `time_window`. - -```pseudo -e.g. - -Given: the following total_stake values - - [time, total_stake] = [[17:59, 12000], [18:01, 11000], [18:30, 9000], [18:59, 10000]] - -If: the time value and market parameters are - - current_time = 19:00 - - time_window = 3600s - target_stake_factor = 0.25 - -Then: the target stake value is - - target_stake = 0.25 * 11000 = 2750 DAI -``` - -The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` indirectly controls the `total_stake` as the amount an LP is able to reduce their commitment is restricted by the `maximum_reduction_amount`. - +See spec [0041-TSTK](./0041-TSTK-target_stake.md). ### Market Liquidity Fees -The market liquidity fee is calculated using the same mechanism defined in [0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) with the exception that an LPs `physical_stake` is the minimum of their `buy_physical_stake` and their `sell_physical_stake` where the later must be expressed in the quote_asset at the current spot_price. +The market liquidity fee is calculated using the same mechanism defined in [0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). -The liquidity fee is re-calculated at the start of a fee distribution epoch and is fixed for that epoch (Note: this may later be applied universally to all products.) +The liquidity fee is re-calculated at the start of a fee distribution epoch and is fixed for that epoch. +Note: 1. this may later be applied universally to all products. 2. this "fee distribution epoch" is unrelated to blockchain staking and delegation epochs. ## 6. Trading -Both buy and sell orders on a `Spot` market define an amount of the `base_asset` to buy or sell at a given price of the `quote_asset`. When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) to cover the value of the order. +Both buy and sell orders on a `Spot` market define an amount of the `base_asset` to buy or sell at a given price of the `quote_asset`. +When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) in the general accounts for the respective assets to cover the value of the order. -(Note: For buy orders the party will need a sufficient amount of the quote asset to cover any fees incurred if the order was to trade instantly. For sell orders, there is no need for the party to have any `quote` asset as the fees can be subtracted from the general account for their base asset immediately after trading). +For buy orders the party will also need a sufficient amount of the `quote_asset` to cover any fees incurred as if the order was to trade instantly. +For sell orders, there is no need for the party to have any `quote_asset` as the fees will be subtracted from the resulting `quote_asset` amount due to the party as a a result from the trade. -If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` account. +If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` accounts for the market. When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. From ff51ce1474d995879baa555f75adb183ea86dcc3 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 24 Feb 2023 13:26:33 +0000 Subject: [PATCH 033/649] refactor: update trading rules --- protocol/0080-SPOT-product_builtin_spot.md | 48 +++++++++++++--------- 1 file changed, 29 insertions(+), 19 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 49086af1f..f7c5e6ab3 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -9,16 +9,16 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. 1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. -## 1. Network Parameter +## 2. Network Parameter 1. `spot_trading_enabled`: parameter defines whether markets using Spot products are enabled on the network. -## 2. Liquidity Monitoring parameters +## 3. Liquidity Monitoring parameters 1. `time_window`: length of rolling window (in seconds) over which the maximum `total_stake` is measured. 1. `target_stake_factor`: fraction of `total_stake` to be selected as the `target_stake`. -## 3. Market parameters +## 4. Market parameters 1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. @@ -28,7 +28,7 @@ When trading Spot products, parties can only use assets they own - there is no l The Cash Settled Futures spec could rename `position_decimal_places` to something more general, e.g. `size_decimal_places`. -## 4. Liquidity Commitments +## 5. Liquidity Commitments ### Submissions @@ -65,11 +65,13 @@ submission = { As the LP now has a different commitment amount on each side of the book, the following considerations must be made: -- An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake` where the later is expressed in the `quote_asset` converted at the current `mark_price`. The current `physical_stake` is the smaller of the two values. -- An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake`. -- The same growth factor - as specified in the [LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md) - derived from the `total value for fee purposes` in the quote asset is used to update both buy/sell virtual stakes (still in their respective assets). -- The current `virtual_stake` for fee splitting is the smaller of the two values where the `sell_virtual_stake` is converted to `quote_asset` at the current `mark_price`. -- An LPs `liquidity_score` as in [the liquidity score section of the LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md). +- Physical Stake: + - An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake`. + - The current `physical_stake` for market stake calculations is the smaller of the two values, where the `sell_physical_stake` is converted into the `quote_asset` at the current `mark_price`. +- Virtual Stake: + - An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake`. + - The same growth factor - as specified in the [LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md) - derived from the `total value for fee purposes` in the quote asset is used to update both buy/sell virtual stakes (still in their respective assets). + - The current `virtual_stake` for fee splitting is the smaller of the two values where the `sell_virtual_stake` is converted to `quote_asset` at the current `mark_price`. From the above conditions, an LP is incentivised to provide a roughly equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. @@ -110,7 +112,7 @@ If at any point in time, a liquidity provider has insufficient capital in their As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global insurance pool for that asset. -## 5. Spot Liquidity Mechanisms +## 6. Spot Liquidity Mechanisms ### Market Total Stake The `total_stake` for a `Spot` market is calculated simply as the sum of each LPs `physical_stake` and should be expressed in the `quote_asset` of the market. @@ -126,25 +128,33 @@ The liquidity fee is re-calculated at the start of a fee distribution epoch and Note: 1. this may later be applied universally to all products. 2. this "fee distribution epoch" is unrelated to blockchain staking and delegation epochs. -## 6. Trading +## 7. Trading -Both buy and sell orders on a `Spot` market define an amount of the `base_asset` to buy or sell at a given price of the `quote_asset`. -When placing an order, the party should have a sufficient amount of the `quote` asset (for "buy" orders) or `base` asset (for "sell" orders) in the general accounts for the respective assets to cover the value of the order. +Both buy and sell orders on a `Spot` market define a size (amount of the `base_asset`) to buy or sell at a given price (amount of the `quote_asset`). An orders "value for fee purposes" is always expressed in the `quote_asset`. -For buy orders the party will also need a sufficient amount of the `quote_asset` to cover any fees incurred as if the order was to trade instantly. -For sell orders, there is no need for the party to have any `quote_asset` as the fees will be subtracted from the resulting `quote_asset` amount due to the party as a a result from the trade. +### Sell Orders: -If the order does not immediately trade (or only trades in part) then the party will have to transfer the amount of the `quote` asset (for "buy" orders) or the `base` asset (for "sell" orders) required to cover the value of the outstanding order as well as possible fees to a `holding` accounts for the market. +For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid. -When an order is fulfilled or cancelled any remaining funds in the `holding` account (after the trade has been executed) can be returned to to the parties `general` account. +If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. -## 7. Auctions +If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`. + +### Buy Orders: + +For a "buy" order to be considered valid, the party will need a sufficient amount of the `quote_asset` in the `general_account` to cover both the value of the trade as well as any possible fees incurred. + +If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover the remaining size of the order, as well as any possible fees, should be transferred to a `holding_account` for the `quote_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. + +As limit orders will only incur fees if they trade in an auction - for GFN orders, the possible fees are `"0"`, and for all other existing TIF options, the possible fees are calculated as if the order was to trade in full during an auction at the price of the order (this gives the maximum possible fee). + +## 8. Auctions As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. Price-monitoring auctions are still required and should be implemented following the [price-monitoring](./0032-PRIM-price_monitoring.md) spec. -## 8. Acceptance Criteria +## 9. Acceptance Criteria 1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-COSMICELEVATOR-001) 1. It is not possible to change the `quote_asset` via governance (0080-COSMICELEVATOR-002) From 6149ee11ebad836b15b35907f6bbf1a2e5b13c38 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 24 Feb 2023 13:34:57 +0000 Subject: [PATCH 034/649] refactor: linting fixes --- protocol/0041-TSTK-target_stake.md | 17 +++++++------ protocol/0080-SPOT-product_builtin_spot.md | 28 ++++++++++++---------- 2 files changed, 23 insertions(+), 22 deletions(-) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index fb0779ca6..be978df0c 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -1,6 +1,6 @@ # Target stake -# Target stake for derivatives markets (cash settled futures / perps...) +## Target stake for derivatives markets (cash settled futures / perpetuals...) This spec outlines how to measure how much stake we want committed to a market relative to what is happening on the market (currently open interest). The target stake is a calculated quantity, utilised by various mechanisms in the protocol: @@ -9,7 +9,7 @@ The target stake is a calculated quantity, utilised by various mechanisms in the The parameter c_1 is a market parameter (with network parameter `market.liquidity.targetstake.triggering.ratio` providing a default value) defined in the [liquidity Monitoring](./0035-LIQM-liquidity_monitoring.md) spec. - It is used to set the fee factor for the LPs: see [Setting fees and rewarding LPs](./0042-LIQF-setting_fees_and_rewarding_lps.md). -## Definitions / Parameters used +### Definitions / Parameters used - **Open interest**: the volume of all open positions in a given market. - `market.stake.target.timeWindow` is a market parameter defining the length of window over which we measure open interest (see below). This should be measured in seconds and a typical value is one week i.e. `7 x 24 x 3600` seconds. @@ -18,7 +18,7 @@ The parameter c_1 is a market parameter (with network parameter `market.liquidit - `mark_price`, see [mark price](./0009-MRKP-mark_price.md) spec. - `indicative_uncrossing_price`, see [auction](./0026-AUCT-auctions.md) spec. -### Current definitions +#### Current definitions First, `max_oi` is defined maximum (open interest) measured over a time window, `t_window = [max(t-market.stake.target.timeWindow,t0),t]`. Here `t` is current time with `t0` being the end of market opening auction. Note that `max_oi` should be calculated recorded per transaction, so if there are multiple OI changes withing the same block (which implies the same timestamp), we should pick the max one, NOT the last one that was processed. @@ -54,13 +54,13 @@ Note that the units of `target_stake` are the settlement currency of the market Example 3: if `market.stake.target.scalingFactor = 10`, `rf = 0.004` and `max_oi = 120` then `target_stake = 4.8`. -### APIs +#### APIs - target stake - return current (real-time) target stake when market is in default trading mode. - return theoretical (based on indicative uncrossing volume) target stake when market is in auction mode. -### Acceptance Criteria +#### Acceptance Criteria - examples showing a growing list (before we hit time window) (0041-TSTK-001) - examples showing a list that drops off values (0041-TSTK-002) @@ -68,8 +68,7 @@ Example 3: if `market.stake.target.scalingFactor = 10`, `rf = 0.004` and `max_oi - Change of `market.stake.target.scalingFactor` will immediately change the scaling between liquidity demand estimate based on open interest and target stake, hence immediately change the target stake. (0041-TSTK-004) - Change of `market.stake.target.timeWindow` will immediately change the length of time window over which open interest is measured, hence will immediately change the value of `max_oi`. (0041-TSTK-005) - -# Target stake for spot markets +## Target stake for spot markets See [spot market spec](0080-SPOT-product_builtin_spot.md).3600s @@ -96,6 +95,6 @@ Then: the target stake value is The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` indirectly controls the `total_stake` as the amount an LP is able to reduce their commitment is restricted by the `maximum_reduction_amount`. -### Acceptance criteria +### Acceptance criteria -TBD \ No newline at end of file +TBD diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index f7c5e6ab3..565920169 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -20,7 +20,7 @@ When trading Spot products, parties can only use assets they own - there is no l ## 4. Market parameters -1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. +1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. The Cash Settled Futures spec could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. @@ -66,14 +66,14 @@ submission = { As the LP now has a different commitment amount on each side of the book, the following considerations must be made: - Physical Stake: - - An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake`. - - The current `physical_stake` for market stake calculations is the smaller of the two values, where the `sell_physical_stake` is converted into the `quote_asset` at the current `mark_price`. + - An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake`. + - The current `physical_stake` for market stake calculations is the smaller of the two values, where the `sell_physical_stake` is converted into the `quote_asset` at the current `mark_price`. - Virtual Stake: - - An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake`. - - The same growth factor - as specified in the [LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md) - derived from the `total value for fee purposes` in the quote asset is used to update both buy/sell virtual stakes (still in their respective assets). - - The current `virtual_stake` for fee splitting is the smaller of the two values where the `sell_virtual_stake` is converted to `quote_asset` at the current `mark_price`. + - An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake`. + - The same growth factor - as specified in the [LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md) - derived from the `total value for fee purposes` in the quote asset is used to update both buy/sell virtual stakes (still in their respective assets). + - The current `virtual_stake` for fee splitting is the smaller of the two values where the `sell_virtual_stake` is converted to `quote_asset` at the current `mark_price`. -From the above conditions, an LP is incentivised to provide a roughly equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. +From the above conditions, an LP is incentivised to provide a roughly equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. ### Amendments and Cancellations @@ -103,8 +103,9 @@ Market Liquidity: - reducing the `buy_commitment_amount` only reduces the `buy_virtual_stake` - reducing the `sell_commitment_amount` only reduces the `sell_virtual_stake` -A single LP will never be able to reduce their commitment to `0`. They can either keep reducing to a sufficiently small amount they're willing to ignore, or they can submit a governance vote to cancel the market, see the [governance spec](). -For market cancellation proposal a sole LP in the market holds all the voting power (unless governance token holders override them). +A single LP will never be able to reduce their commitment to `0`. They can either keep reducing to a sufficiently small amount they're willing to ignore, or they can submit a governance vote to cancel the market, see the [governance spec](./0028-GOVE-governance.md). + +For market cancellation proposal a sole LP in the market holds all the voting power (unless governance token holders override them). ### Liquidity Shortfalls @@ -113,6 +114,7 @@ If at any point in time, a liquidity provider has insufficient capital in their As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global insurance pool for that asset. ## 6. Spot Liquidity Mechanisms + ### Market Total Stake The `total_stake` for a `Spot` market is calculated simply as the sum of each LPs `physical_stake` and should be expressed in the `quote_asset` of the market. @@ -120,6 +122,7 @@ The `total_stake` for a `Spot` market is calculated simply as the sum of each LP ### Market Target Stake See spec [0041-TSTK](./0041-TSTK-target_stake.md). + ### Market Liquidity Fees The market liquidity fee is calculated using the same mechanism defined in [0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). @@ -127,12 +130,11 @@ The market liquidity fee is calculated using the same mechanism defined in [0042 The liquidity fee is re-calculated at the start of a fee distribution epoch and is fixed for that epoch. Note: 1. this may later be applied universally to all products. 2. this "fee distribution epoch" is unrelated to blockchain staking and delegation epochs. - ## 7. Trading -Both buy and sell orders on a `Spot` market define a size (amount of the `base_asset`) to buy or sell at a given price (amount of the `quote_asset`). An orders "value for fee purposes" is always expressed in the `quote_asset`. +Both buy and sell orders on a `Spot` market define a size (amount of the `base_asset`) to buy or sell at a given price (amount of the `quote_asset`). An orders "value for fee purposes" is always expressed in the `quote_asset`. -### Sell Orders: +### Sell Orders For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid. @@ -140,7 +142,7 @@ If a "sell" order does not trade immediately (or only trades in part), an amount If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`. -### Buy Orders: +### Buy Orders For a "buy" order to be considered valid, the party will need a sufficient amount of the `quote_asset` in the `general_account` to cover both the value of the trade as well as any possible fees incurred. From d2e8681eb922777cf5c4e64f2e6041a6fa179773 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 21 Mar 2023 11:57:38 +0000 Subject: [PATCH 035/649] feat: change insurance pool to network treasury --- protocol/0041-TSTK-target_stake.md | 2 +- protocol/0080-SPOT-product_builtin_spot.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index be978df0c..b285b2cab 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -97,4 +97,4 @@ The above design ensures the `target_stake` of a market is unable to fluctuate d ### Acceptance criteria -TBD +Too be decided. diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 565920169..14468361a 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -111,7 +111,7 @@ For market cancellation proposal a sole LP in the market holds all the voting po If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall, applying the bond penalty factor (slashing the bond). -As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global insurance pool for that asset. +As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global network treasury for that asset. ## 6. Spot Liquidity Mechanisms From e1f1ac4702395f0d0705b3c883b3a85a3acb4848 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 17 May 2023 11:39:29 +0100 Subject: [PATCH 036/649] feat: update ac codes --- protocol/0080-SPOT-product_builtin_spot.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 14468361a..a3acc989f 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -158,10 +158,10 @@ Price-monitoring auctions are still required and should be implemented following ## 9. Acceptance Criteria -1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-COSMICELEVATOR-001) -1. It is not possible to change the `quote_asset` via governance (0080-COSMICELEVATOR-002) -1. It is not possible to change the `base_asset` via governance (0080-COSMICELEVATOR-003) -1. A `Spot` market can be closed through governance (0080-COSMICELEVATOR-004) -1. Parties are unable to place orders they do not have the necessary funds for (0080-COSMICELEVATOR-005) -1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-COSMICELEVATOR-006) -1. Market liquidity fees are calculated correctly (0080-COSMICELEVATOR-007) +1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-SPOT-001) +1. It is not possible to change the `quote_asset` via governance (0080-SPOT-002) +1. It is not possible to change the `base_asset` via governance (0080-SPOT-003) +1. A `Spot` market can be closed through governance (0080-SPOT-004) +1. Parties are unable to place orders they do not have the necessary funds for (0080-SPOT-005) +1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-SPOT-006) +1. Market liquidity fees are calculated correctly (0080-SPOT-007) From dd80c31b0605037972f31bfa415594c97ba923c2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 17 May 2023 12:18:17 +0100 Subject: [PATCH 037/649] feat: update trading rules --- protocol/0080-SPOT-product_builtin_spot.md | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index a3acc989f..10becce76 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -144,11 +144,25 @@ If a "sell" order incurs fees through trading (i.e. is the aggressor or trades i ### Buy Orders -For a "buy" order to be considered valid, the party will need a sufficient amount of the `quote_asset` in the `general_account` to cover both the value of the trade as well as any possible fees incurred. +As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered. -If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover the remaining size of the order, as well as any possible fees, should be transferred to a `holding_account` for the `quote_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. +#### Continuous Trading -As limit orders will only incur fees if they trade in an auction - for GFN orders, the possible fees are `"0"`, and for all other existing TIF options, the possible fees are calculated as if the order was to trade in full during an auction at the price of the order (this gives the maximum possible fee). +For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor). + +If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. + +#### Entering an Auction + +When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled. + +For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction. + +If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`. + +#### Exiting an Auction + +When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order. ## 8. Auctions From dcb3ecf70cb4233ff5767974055df79c11855534 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 17 May 2023 14:31:17 +0100 Subject: [PATCH 038/649] allow pending / proposed --- .../0015-INSR-market_insurance_pool_collateral.md | 2 +- protocol/0028-GOVE-governance.md | 12 ++++++++---- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/protocol/0015-INSR-market_insurance_pool_collateral.md b/protocol/0015-INSR-market_insurance_pool_collateral.md index 0b9bd267e..fc0974e2b 100644 --- a/protocol/0015-INSR-market_insurance_pool_collateral.md +++ b/protocol/0015-INSR-market_insurance_pool_collateral.md @@ -19,5 +19,5 @@ When a market is finalised / closed remaining funds are distributed equally amon ## Acceptance Criteria - When a market proposal gets accepted and the opening auction commences, there is an insurance account that is available for use by that market for the settlement asset of that market and its balance is zero. (0015-INSR-001) -- When the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) +- After the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), and `network.liquidity.successorLaunchWindowLength` has elapsed from the settlement time, the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) - The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 8fd3d4c4b..fc2aecbf9 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -221,13 +221,17 @@ A proposal to create a market contains 1. an enactment time that is at least the _minimum auction duration_ after the vote closing time (see [auction spec](./0026-AUCT-auctions.md)) 1. if the market is meant to be a _successor_ of a given market then it contains the `marketID` of the market it's succeeding (parent market), a parameter called `insurancePoolFraction` which is a decimal in `[0,1]` (i.e. it can be `0` or `1` or anything in between) and certain entries in the market proposal must be identical to those of the market it's succeeding OR the proposal should simply not contain the fields that cannot be changed. In a particular instrument, the settlement asset, margin asset, and `market.value.windowLength` must match. -The parent market must be in one of `active` or `suspended` or `trading terminated` states or `settled` but with time since settlement less than or equal `network.liquidity.successorLaunchWindowLength` or `cancelled` (closed by governance) but with the closing time less than or equal `network.liquidity.successorLaunchWindowLength`. -In particular the market cannot be `pending`. -If the parent market is `proposed` or `pending` then the proposal should be rejected at the validation stage with an error "parent market cannot be in `*` state" with `*` being one of the dis-allowed states above. +The parent market must be either: +- in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` +- or `settled` state but with time since settlement less than or equal `network.liquidity.successorLaunchWindowLength` +- or `cancelled` (closed by governance) but with the closing time less than or equal `network.liquidity.successorLaunchWindowLength`. The point of setting up a market to be successor of an existing market is to -a) allow LPs continue claim their equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and +a) allow LPs continue claim their virtual stake / equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. +If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketId may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent. + + Note that each market can have exactly one market as a _successor_ market. - if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. From 954420d26aa2f16b158f3ac38d5c95c204d4b249 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 17 May 2023 14:32:53 +0100 Subject: [PATCH 039/649] allow pending / proposed --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index fc2aecbf9..cde86ad64 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -229,7 +229,7 @@ The point of setting up a market to be successor of an existing market is to a) allow LPs continue claim their virtual stake / equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. -If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketId may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent. +If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketId may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). Note that each market can have exactly one market as a _successor_ market. From 4455900ab70edb0f8d30c479c3cb5228c6bfbfc8 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 18 May 2023 17:22:46 +0100 Subject: [PATCH 040/649] allow pending / proposed --- protocol/0001-MKTF-market_framework.md | 3 ++- protocol/0028-GOVE-governance.md | 12 ++++++++++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 8c8e5a302..781ea2663 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -219,7 +219,8 @@ Market { ## Successor market If a market proposal, see [governance](./0028-GOVE-governance.md), designates an existing market as a *parent market* then it must have the same *product*, *settlement asset(s)* and *margin asset(s)*. -It may propose new risk model and parameters, price monitoring parameters, position and market decimal places and oracles, both for trading terminated and for settlement data. +It may propose new risk model and parameters, price monitoring parameters, position and market decimal places. +It must provide oracle definitions, both for trading terminated and for settlement data. Each market can have exactly one market as a *successor* market. 1. if there already is a market (possibly pending i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)) naming a parent market which is referenced in the proposal then the proposal is rejected. diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index cde86ad64..fd5a859ae 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -146,7 +146,9 @@ For market change proposals the network will additionally calculate 1. `LP participation rate = SUM (equity-like share of all LPs who cast a vote)` (no need to divide by anything as equity-like share sums up to `1`). 1. `LP for rate = SUM (all who voted for) / LP participation rate`. -A market parameter change is passed only when: +If the market that the proposal is changing is pending at the vote resolution time then only token holder votes are used. + +For a market that's out of the pending state (so the opening auction has concluded) a market parameter change is passed only when: - either the governance token holder vote is successful i.e. `participation_rate >= governance.proposal.updateMarketParam.requiredParticipation` AND `for_rate > governance.proposal.updateMarketParam.requiredMajority` (in this case the LPs were overridden by governance token holders) - or the governance token holder vote does not reach participation threshold but the LP vote does and approves the proposal `participation_rate < governance.proposal.updateMarketParam.requiredParticipation` AND `LP participation rate >= governance.proposal.updateMarketParam.requiredParticipationLP` AND `LP for rate >= governance.proposal.updateMarketParam.requiredMajorityLP`. @@ -236,7 +238,7 @@ Note that each market can have exactly one market as a _successor_ market. - if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. - if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market no longer available". -- if there is a successor market naming a parent market that terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market successor is set to empty and a different successor can be proposed. +- if there is a successor market naming a parent market that terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market successor field is set to empty and a different successor can be proposed by a future market proposal. All _new market proposals_ initially have their validation configured by the network parameters `Governance.CreateMarket.All.*`. These may be split from `All` to subtypes in future, for instance when other market types like RFQ are created. @@ -464,6 +466,12 @@ APIs should also exist for clients to: - Change of the network parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` will immediately change the minimum proposer ELS for a market change proposal for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-064) - Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065) - Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066) +- A market that's attempting to modify any parameters on a market in `proposed` state (i.e. voting hasn't completed) will be rejected. (0028-GOVE-069) +- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has sucessfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) +- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has sucessfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the propsed parent doesn't already have a successor). (0028-GOVE-071) +- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has sucessfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) + + #### Network parameter change proposals From 77d6c6ad18b75c17985f6c5e45bcad77a6c50272 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 18 May 2023 17:38:18 +0100 Subject: [PATCH 041/649] allow pending / proposed --- protocol/0028-GOVE-governance.md | 10 +++++----- wordlist.txt | 1 + 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index fd5a859ae..e1370a166 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -146,7 +146,7 @@ For market change proposals the network will additionally calculate 1. `LP participation rate = SUM (equity-like share of all LPs who cast a vote)` (no need to divide by anything as equity-like share sums up to `1`). 1. `LP for rate = SUM (all who voted for) / LP participation rate`. -If the market that the proposal is changing is pending at the vote resolution time then only token holder votes are used. +If the market that the proposal is changing is pending (so accepted but hasn't left opening auction yet) at the vote resolution time then only token holder votes are used. For a market that's out of the pending state (so the opening auction has concluded) a market parameter change is passed only when: @@ -231,7 +231,7 @@ The point of setting up a market to be successor of an existing market is to a) allow LPs continue claim their virtual stake / equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. -If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketId may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). +If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketID may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). Note that each market can have exactly one market as a _successor_ market. @@ -467,9 +467,9 @@ APIs should also exist for clients to: - Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065) - Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066) - A market that's attempting to modify any parameters on a market in `proposed` state (i.e. voting hasn't completed) will be rejected. (0028-GOVE-069) -- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has sucessfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) -- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has sucessfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the propsed parent doesn't already have a successor). (0028-GOVE-071) -- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has sucessfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) +- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) +- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) +- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) diff --git a/wordlist.txt b/wordlist.txt index 400440dc7..ad2292c39 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -152,6 +152,7 @@ mainnet malus margined margining +marketID messager math mempool From 5f6042cead12cb32af5d77fb5c294cb20667e49b Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 18 May 2023 17:56:39 +0100 Subject: [PATCH 042/649] allow pending / proposed --- protocol/0028-GOVE-governance.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index e1370a166..e08e73038 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -146,7 +146,7 @@ For market change proposals the network will additionally calculate 1. `LP participation rate = SUM (equity-like share of all LPs who cast a vote)` (no need to divide by anything as equity-like share sums up to `1`). 1. `LP for rate = SUM (all who voted for) / LP participation rate`. -If the market that the proposal is changing is pending (so accepted but hasn't left opening auction yet) at the vote resolution time then only token holder votes are used. +If the market that the proposal is changing is pending (so accepted but hasn't left opening auction yet) at the vote resolution time then only token holder votes are used. For a market that's out of the pending state (so the opening auction has concluded) a market parameter change is passed only when: @@ -223,15 +223,14 @@ A proposal to create a market contains 1. an enactment time that is at least the _minimum auction duration_ after the vote closing time (see [auction spec](./0026-AUCT-auctions.md)) 1. if the market is meant to be a _successor_ of a given market then it contains the `marketID` of the market it's succeeding (parent market), a parameter called `insurancePoolFraction` which is a decimal in `[0,1]` (i.e. it can be `0` or `1` or anything in between) and certain entries in the market proposal must be identical to those of the market it's succeeding OR the proposal should simply not contain the fields that cannot be changed. In a particular instrument, the settlement asset, margin asset, and `market.value.windowLength` must match. -The parent market must be either: -- in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` -- or `settled` state but with time since settlement less than or equal `network.liquidity.successorLaunchWindowLength` -- or `cancelled` (closed by governance) but with the closing time less than or equal `network.liquidity.successorLaunchWindowLength`. +The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` +or b) `settled` state but with time since settlement less than or equal `network.liquidity.successorLaunchWindowLength` +or c) `cancelled` (closed by governance) but with the closing time less than or equal `network.liquidity.successorLaunchWindowLength`. The point of setting up a market to be successor of an existing market is to a) allow LPs continue claim their virtual stake / equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. -If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketID may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). +If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketID may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). Note that each market can have exactly one market as a _successor_ market. @@ -472,7 +471,6 @@ APIs should also exist for clients to: - A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) - #### Network parameter change proposals - As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-026) From a49a6e0e567e3e25844bd3ff752e53f330cdbf3c Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 19 May 2023 09:54:59 +0100 Subject: [PATCH 043/649] chore: Update categories.json with latest specs for cosmic elevator (#1708) This PR adds the latest new specs added for cosmic elevator into the categories.json file so that the approbation report details these. --- protocol/categories.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/categories.json b/protocol/categories.json index 09c07a63c..1ec59f955 100644 --- a/protocol/categories.json +++ b/protocol/categories.json @@ -1,6 +1,6 @@ { "Fundamentals": { - "specs": ["0017-PART", "0022-AUTH", "0051-PROD", "0016-PFUT", "0053-PERP", "0040-ASSF", "0013-ACCT", "0054-NETP", "0068-MATC", "0067-KEYS", "0057-TRAN", "0052-FPOS"] + "specs": ["0017-PART", "0022-AUTH", "0051-PROD", "0016-PFUT", "0053-PERP", "0040-ASSF", "0013-ACCT", "0054-NETP", "0068-MATC", "0067-KEYS", "0057-TRAN", "0052-FPOS", "0080-SPOT"] }, "Markets": { "specs": ["0035-LIQM", "0032-PRIM", "0043-MKTL", "0026-AUCT", "0006-POSI", "0008-TRAD", "0001-MKTF", "0009-MRKP", "0012-POSR", "0021-MDAT", "0039-MKTD", "0070-MKTD"] @@ -12,7 +12,7 @@ "specs": ["0073-LIMN", "0072-SPPW", "0062-SPAM", "0060-WEND", "0003-NP-LIMI", "0072-SPPW", "0078-NWLI", "0079-TGAP"] }, "Liquidity": { - "specs": ["0044-LIME", "0042-LIQF", "0034-PROB"] + "specs": ["0044-LIME", "0042-LIQF", "0034-PROB", "0012-NP-LIPE"] }, "Governance": { "specs": ["0028-GOVE", "0027-ASSP", "0058-REWS", "0056-REWA", "0055-TREA"] From 91d8883626dc0438cda54729d53643a6bc1a0dae Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 19 May 2023 12:05:10 +0100 Subject: [PATCH 044/649] allow pending / proposed --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index e08e73038..3d6f7983e 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -237,7 +237,7 @@ Note that each market can have exactly one market as a _successor_ market. - if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. - if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market no longer available". -- if there is a successor market naming a parent market that terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market successor field is set to empty and a different successor can be proposed by a future market proposal. +- if there is a successor market naming a parent market and the parent terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market can again act as successor to a differnt market proposed by a future market proposal. All _new market proposals_ initially have their validation configured by the network parameters `Governance.CreateMarket.All.*`. These may be split from `All` to subtypes in future, for instance when other market types like RFQ are created. From abcc4cd923635afa4f6f81232911342f8a4aa193 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 24 May 2023 12:11:55 +0100 Subject: [PATCH 045/649] fix: markdown and spelling lint errors --- protocol/0000-ETHD-ethereum-data-source.md | 80 +++++++++++----------- wordlist.txt | 1 + 2 files changed, 42 insertions(+), 39 deletions(-) diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0000-ETHD-ethereum-data-source.md index 4d626b9d2..090e9582a 100644 --- a/protocol/0000-ETHD-ethereum-data-source.md +++ b/protocol/0000-ETHD-ethereum-data-source.md @@ -3,16 +3,16 @@ ## Summary -This specification adds a new way of sourcing data from the Ethereum blokchain to allow arbitrary data from the Ethereum blockchain to be ingested as a [data source](./0045-DSRC-data_sourcing.md). +This specification adds a new way of sourcing data from the Ethereum blockchain to allow arbitrary data from the Ethereum blockchain to be ingested as a [data source](./0045-DSRC-data_sourcing.md). This is in addition to the existing [Ethereum bridge](./0031-ETHB-ethereum_bridge_spec.md), which is unchanged by this spec. ## Description -Currently, data is sourced from Ethereum only as a result of watching for pre-defined events, on a specific contract, at a specific address. +Currently, data is sourced from Ethereum only as a result of watching for pre-defined events, on a specific contract, at a specific address. Namely, the ERC20 bridge contract. These events are picked up by the [event queue](./0036-BRIE-event_queue.md) processor and submitted by each node as transactions to the Vega chain. -Once a quroum of nodes have ratified the transaction, it is reflected in the Vega state. +Once a quorum of nodes have ratified the transaction, it is reflected in the Vega state. Ethereum data sources extend this in three important ways: @@ -23,9 +23,9 @@ Ethereum data sources extend this in three important ways: 3. The address of the contract being observed is also specified as part of the data source. -Like all data sources, Ethereum oracles may be subject to filters or other processing or aggregation functions. +Like all data sources, Ethereum oracles may be subject to filters or other processing or aggregation functions. Once observed, the data is treated as any other data source and available to any part of the system that accepts a data source as input. -The event queue may evaluate filters before submitting the observation to the Vega chain, in order to avoid submitting transactions containing data that will be dropped due to filters in any case. +The event queue may evaluate filters before submitting the observation to the Vega chain, in order to avoid submitting transactions containing data that will be dropped due to filters in any case. ## Functional design @@ -41,21 +41,21 @@ This data, including any structs should be decoded using the ABI into a JSON-lik Note: as with any data source containing JSON formatted (or other arbitrary structured) data, the data required by the consumer of the data source may be a fields or sub-objects (including nested fields and objects). The data sourcing framework therefore requires functionality to apply a query/selector extract the relevant subset of the observed data and pass it to the next consumer. -This would be expected to use JSONPath/JSONPointer or similar, and be applicable to any arbitrary JSON. -Regardless, the specification of this functionaltiy is out of scope for this document and the approach must be standardised across the data sourcing framework (for example, specifiyng the target of filters must use the same format as selecting data to pass on). +This would be expected to use `JSONPath`/`JSONPointer` or similar, and be applicable to any arbitrary JSON. +Regardless, the specification of this functionality is out of scope for this document and the approach must be standardised across the data sourcing framework (for example, specifyng the target of filters must use the same format as selecting data to pass on). ### Ethereum chain data enrichment All data sourced from Ethereum should be structured as an object containing both a payload and Ethereum chain metadata, namely: -- Ethereum block height at which the data was observed/event ocurred +- Ethereum block height at which the data was observed/event occurred -- Ethereum block timestamp at which the data was observed/event ocurred +- Ethereum block timestamp at which the data was observed/event occurred These data can be used as the subject of filters or even extracted as the oracle data of interest. -Filters on Ethreum block height, Ethereum timestamp, or Vega timestamp should be applied prior to submitting the data to the Vega chain, in addition to being re-applied when the data is confirmed on chain. +Filters on Ethereum block height, Ethereum timestamp, or Vega timestamp should be applied prior to submitting the data to the Vega chain, in addition to being re-applied when the data is confirmed on chain. This would prevent spamming the Vega chain with event data that is not relevant. @@ -73,16 +73,16 @@ The specified method must be defined in the supplied ABI. ## Error checking and handling -Errors in the data source specification should be caught where possible during validation. -Errors that occur or are detected later (e.g. when data arrives) must not propagate to other parts of the system. +Errors in the data source specification should be caught where possible during validation. +Errors that occur or are detected later (e.g. when data arrives) must not propagate to other parts of the system. That is, they must be contained within the data sourcing subsystem. It should be possible to determine if such errors have occurred by listening for events or querying the data source APIs. -- Attempts to select data from non-existent fields or structures in observed data should be recorded as errors on the event bus and in APIs, and the system must not emit data to the reciever. +- Attempts to select data from non-existent fields or structures in observed data should be recorded as errors on the event bus and in APIs, and the system must not emit data to the receiver. -- Incorrect ABI (where this cannot be validated at the time the ABI is submitted) and/or the inability to decode data with the provided ABI should be recorded as errors on the event bus and in APIs, and the system must not emit data to the reciever. +- Incorrect ABI (where this cannot be validated at the time the ABI is submitted) and/or the inability to decode data with the provided ABI should be recorded as errors on the event bus and in APIs, and the system must not emit data to the receiver. -- A mismatch in data types between a data field and the data required by the receiver should be recorded as errors on the event bus and in APIs, and the system must not emit data to the reciever. +- A mismatch in data types between a data field and the data required by the receiver should be recorded as errors on the event bus and in APIs, and the system must not emit data to the receiver. ## Pseudocode examples @@ -92,7 +92,7 @@ Event data source specification: ```json Select { source: Filter { - source: EthereumEvent { + source: EthereumEvent { contract: 0xDEADBEEF ABI: "...JSON..." event: "StakeDeposited" @@ -108,37 +108,40 @@ Select { ## Acceptance criteria -### External Oracles - Creation: +### External Oracles - Creation 1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) -2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment +2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment 3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message 4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) -### External Oracles - Amendments: +### External Oracles - Amendments + 1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted. 2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted , the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted. 3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted. -### External Oracles - Deletions: +### External Oracles - Deletions + 1. Ability to delete a data source if and only if the data source is NOT used by any active markets 2. Should NOT be able to delete a data source if its being actively used by a market 3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source -### External Oracles - Validations: +### External Oracles - Validations + 1. Validate if the smart contract address is valid -2. Validate if the data elements of the oracle data source is valid - e.g. source for a value thats returned as boolean but have a filter / condition for greater than 0 +2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 3. Validations for min / max frequency of listening for events / read a smart contract 4. Create a new market with an inactive external oracle data source, system should throw an error 5. Validations to be applied - need to be expanded 6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event -### New Network parameters: +### New Network parameters 1. Test min / max values / validations for any new network parameters that are added -2. Test the impact / behavior of the system, after the changes to the new network params are enacted +2. Test the impact / behaviour of the system, after the changes to the new network parameters are enacted -### Negative Tests: +### Negative Tests 1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) 2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value @@ -147,45 +150,44 @@ Select { 5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error 6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting. -### API: +### API -1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired / +1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired / 2. Ability to query historic data sent by an oracle data source -### Non Functional: +### Non Functional 1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out -2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 mins and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event -3. Phase 2 - Define behavior for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition. -4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed +2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event +3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition. +4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed 5. SPAM rules if any defined should be tested for 6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly 7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market -### Usage: +### Usage 1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles 2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market 3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market 4. Data sourcing should be completely decoupled from data filtering -### Checkpoints: +### Checkpoints 1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints 2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config. -### Snapshots: +### Snapshots 1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots. 2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config. -### Protocol Upgrade: +### Protocol Upgrade 1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade. 2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade. -3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config. - -### Regression: +3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config. -1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one. +### Regression +1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one. diff --git a/wordlist.txt b/wordlist.txt index f3ee3e846..79c774672 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -209,6 +209,7 @@ stakers statebridge stateful statesync +structs SSD SSL suboptimal From e506ce6ccb7532bc7de7bd95eb63d44a038d3881 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 24 May 2023 12:15:49 +0100 Subject: [PATCH 046/649] fix: spelling error --- protocol/0000-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0000-ETHD-ethereum-data-source.md index 090e9582a..d8cfae9d3 100644 --- a/protocol/0000-ETHD-ethereum-data-source.md +++ b/protocol/0000-ETHD-ethereum-data-source.md @@ -42,7 +42,7 @@ This data, including any structs should be decoded using the ABI into a JSON-lik Note: as with any data source containing JSON formatted (or other arbitrary structured) data, the data required by the consumer of the data source may be a fields or sub-objects (including nested fields and objects). The data sourcing framework therefore requires functionality to apply a query/selector extract the relevant subset of the observed data and pass it to the next consumer. This would be expected to use `JSONPath`/`JSONPointer` or similar, and be applicable to any arbitrary JSON. -Regardless, the specification of this functionality is out of scope for this document and the approach must be standardised across the data sourcing framework (for example, specifyng the target of filters must use the same format as selecting data to pass on). +Regardless, the specification of this functionality is out of scope for this document and the approach must be standardised across the data sourcing framework (for example, specifying the target of filters must use the same format as selecting data to pass on). ### Ethereum chain data enrichment From ab040caa0ae14d5e70a4d1c86ca20a1226cd2660 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 24 May 2023 16:54:41 +0100 Subject: [PATCH 047/649] fix: spelling error --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 3d6f7983e..8c1f37a00 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -237,7 +237,7 @@ Note that each market can have exactly one market as a _successor_ market. - if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. - if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market no longer available". -- if there is a successor market naming a parent market and the parent terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market can again act as successor to a differnt market proposed by a future market proposal. +- if there is a successor market naming a parent market and the parent terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market can again act as successor to a different market proposed by a future market proposal. All _new market proposals_ initially have their validation configured by the network parameters `Governance.CreateMarket.All.*`. These may be split from `All` to subtypes in future, for instance when other market types like RFQ are created. From 54c3b1cfa50bafe6e3c715a7f5a57681b8c32148 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Sun, 30 Apr 2023 13:13:41 +0200 Subject: [PATCH 048/649] feat: SLA liquidity --- ...038-OLIQ-liquidity_provision_order_type.md | 1 + ...042-LIQF-setting_fees_and_rewarding_lps.md | 50 +++++---- protocol/0044-LIME-lp_mechanics.md | 103 +++++++++--------- 3 files changed, 79 insertions(+), 75 deletions(-) diff --git a/protocol/0038-OLIQ-liquidity_provision_order_type.md b/protocol/0038-OLIQ-liquidity_provision_order_type.md index f340d1972..dcda386c2 100644 --- a/protocol/0038-OLIQ-liquidity_provision_order_type.md +++ b/protocol/0038-OLIQ-liquidity_provision_order_type.md @@ -185,6 +185,7 @@ No cancellation of orders that arise from this LP batch order type other than by Note that any other orders that the LP has on the book (limit orders, other pegged orders) that are *not* part of this LP batch order (call them "normal" in this paragraph) can be cancelled and amended as normal. When volume is removed / added / pegs moved (on "normal" orders) then as part of the normal peg updates the LP batch order may add or remove volume as described in section "How they are constructed for the order book" above. + ## Network Parameters - `market.liquidity.probabilityOfTrading.tau.scaling`: scaling factor multiplying risk model value of tau to imply probability of trading. diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index cc4318393..33875edd7 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -2,7 +2,7 @@ ## Summary -The aim of this specification is to set out how fees on Vega are set based on committed liquidity provider stake and prevailing open interest on the market leading to [target stake](../protocol/0041-TSTK-target_stake.md). Let us recall that liquidity providers can commit and withdraw stake by submitting / amending a special liquidity provider pegged order type [liquidity provider order spec](./0038-OLIQ-liquidity_provision_order_type.md). +The aim of this specification is to set out how fees on Vega are set based on committed liquidity provider stake and prevailing open interest on the market leading to [target stake](../protocol/0041-TSTK-target_stake.md). Let us recall that liquidity providers can commit and withdraw stake by submitting / amending a special [liquidity commitment transaction](./0044-LIME-lp_mechanics.md). ## Definitions / Glossary of terms used @@ -10,7 +10,7 @@ The aim of this specification is to set out how fees on Vega are set based on co - **Target stake**: as defined in [target stake spec](./0041-TSTK-target_stake.md). The ideal amount of stake LPs would commit to a market. - `market.liquidityProvision.minLpStakeQuantumMultiple`: There is a network wide parameter specifying the minimum LP stake as the `quantum` specified per asset, see [asset framework spec](../protocol/0040-ASSF-asset_framework.md). -## CALCULATING LIQUIDITY FEE FACTOR +## Calculating liquidity fee factor The [liquidity fee factor](./0029-FEES-fees.md) is an input to the total taker fee that a price taker of a trade pays: @@ -176,11 +176,12 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s (average entry valuation) = 1090.9 ``` -### Calculating the liquidity score +### Calculating the instantenaous liquidity score At every vega time change calculate the liquidity score for each committed LP. -This is done by taking into account all orders they have deployed within the `[min_lp_price,max_lp_price]` [range](./0038-OLIQ-liquidity_provision_order_type.md#refining-list-of-orders) and then calculating the volume-weighted [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) at each price level - call it instantaneous liquidity score. For orders outside the tightest price monitoring bounds set probability of trading to 0. -When we say "all orders" we mean their limit orders, [pegged orders](./0037-OPEG-pegged_orders.md) and the volume deployed on their behalf as part of their [liquidity commitment order](./0038-OLIQ-liquidity_provision_order_type.md). +This is done by taking into account all orders they have deployed within the `[min_lp_price,max_lp_price]` [range](./0044-LIME-lp_mechanics.md) and then calculating the volume-weighted [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) at each price level - call it instantaneous liquidity score. +For orders outside the tightest price monitoring bounds set probability of trading to 0. +Note that parked [pegged orders](./0037-OPEG-pegged_orders.md) and not-yet-triggered [stop orders](./0014-ORDT-order_types.md) are not included. Now calculate the total of the instantaneous liquidity scores obtained for each committed LP: @@ -191,7 +192,7 @@ Otherwise calculate fractional instantaneous liquidity score for each committed `fractional instantaneous liquidity score = instantaneous liquidity score / total` -If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then for each committed LP `liquidity score` is set to `fractional instantaneous liquidity score`. +If `market.liquidity.providers.fee.calculationTimeStep` is set to `0` then for each committed LP `liquidity score` is set to `fractional instantaneous liquidity score`. Otherwise whenever a new LP fee distribution period starts set a counter `n=1`. Then on every Vega time change, after `fractional instantaneous liquidity score` has been obtained for all the committed LPs, update: @@ -200,17 +201,21 @@ Then on every Vega time change, after `fractional instantaneous liquidity score` The liquidity score should always be rounded to 10 decimal places to prevent spurious accuracy and overly long string representation of a number. -### Distributing fees +### Distributing fees into LP-per-market fee account -On every trade, liquidity fee should be collected immediately into an account for that market (call it the liquidity fee account). The account is under control of the network and funds from this account will be transferred to a LP party according to the mechanism below. +On every trade, liquidity fee should be collected immediately into the market LP fee account. +The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -This account is not under control of the LP party (they cannot initiate transfers in or out of the account). The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. +A network parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market LP fee account. +Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.calculationTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. -A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. +The liquidity fees are transferred from the market LP fee account into the LP-per-market fee account, pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. + +The LP parties don't control the LP-per-market fee account; the fees from there are then tranferred to the LPs' general account at the end epoch as described below. + +### Distributing fees from LP-per-market-fee accounts based on meeting SLA commitments -If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. -The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. Flooring non-zero amounts due to integer representation can result in a remainder in the liquidity fee account. The remainder should be left in the market liquidity fee account and carried over to the next distribution window. @@ -244,7 +249,7 @@ LP 3 els = 0.07 LP 4 els = 0.33 ``` -When the time defined by `market.liquidity.providers.fee.distributionTimeStep` elapses we do transfers: +When the time defined by `market.liquidity.providers.fee.calculationTimeStep` elapses we do transfers: ```text 67.275 ETH from LP 1's LP account to LP 1's general account @@ -280,8 +285,7 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - The examples provided result in the given outcomes. (0042-LIQF-008) - The total amount of liquidity fee distributed is equal to the most recent `liquidity-fee-factor` x `notional-value-of-all-trades` (0042-LIQF-011) - Liquidity providers with a commitment of 0 will not receive a share ot the fees (0042-LIQF-012) -- If a market has `market.liquidity.providers.fee.distributionTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) -- If after fee distribution during market settlement, there is a remainder in the market liquidity fee account, the remainder should be transferred to the network treasury for that asset. (0042-LIQF-031) +- If a market has `market.liquidity.providers.fee.calculationTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) - After fee distribution, if there is a remainder in the liquidity fee account and the market is not being settled, it should be left in the liquidity fee account and carried over to the next distribution window. (0042-LIQF-032) @@ -295,21 +299,21 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e - An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a higher fee bid than the current fee: the fee doesn't change (0042-LIQF-024) - An LP leaves a market that is above target stake when their fee bid is currently being used: fee changes to fee bid by the LP who takes their place in the bidding order (0042-LIQF-025) - An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size changes the LP that meets the target stake: fee changes to fee bid by the LP that is now at the place in the bid order to provide the target stake (0042-LIQF-026) -- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't change the LP that meets the target stake: fee doesn't change (0042-LIQF-027) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't the LP that meets the target stake: fee doesn't change (0042-LIQF-027) - An LP leaves a market that is above target stake when their fee bid is higher than the one currently being used: fee doesn't change (0042-LIQF-028) ### API -- Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) -- Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) +- [ ] Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) +- [ ] Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) +- [ ] If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) ### successor market -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-033) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-034) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-035) -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-036) +- [ ] If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) +- [ ] If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-032) +- [ ] If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) +- If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f2c5a0e88..d3913f46e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -1,16 +1,50 @@ # Liquidity provision mechanics -The point of liquidity provision on Vega is to incentivise people to place orders on the market that maintain liquidity on the book. This is done via a financial commitment and reward + penalty mechanics, and through the use of a special batch order type that automatically updates price/size as needed to meet the commitment and automatically refreshes its volume after trading to ensure continuous liquidity provision. +The point of liquidity provision on Vega is to incentivise people to place orders on the market that maintain liquidity on the book. +This is done via a financial commitment and reward + penalty mechanics, and through the use of a special batch order type that announces that a party is entering the liquidity provision (LP) service level agreement (SLA). -Each market on Vega must have at least one committed liquidity provider (LP). -This is enforced when a [governance proposal to create a market is submitted](./0028-GOVE-governance.md#1-create-market). -In particular the proposal has to include [liquidity provision commitment](./0038-OLIQ-liquidity_provision_order_type.md), -see also below. Important note on wording: - liquidity provision / liquidity COMMITMENTs are the amount of stake a liquidity provider places as a bond on the market to earn rewards. -- the COMMITMENT is converted to a liquidity OBLIGATION, measured in siskas. +- the COMMITMENT is converted via a multiplicative network parameter `market.liquidity.stakeToCcyVolume` to a liquidity OBLIGATION, measured in price level x volume i.e. settlement currency of the market. + +## Network and market parameters + +### Network parameters + +- `market.liquidity.bondPenaltyParameter` - used to calculate the penalty to liquidity providers when they fail to meet their obligations. +Valid values: any decimal number `>= 0` with a default value of `0.1`. +- `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of [lp order type](./0038-OLIQ-liquidity_provision_order_type.md). Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. +- `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. +- `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). + + +### Market parameters + +- `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. This is set / can be modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal. + +- `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. + +- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `12h` or `7d`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. + +- `market.liqudity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. + +For LP reward calculations based on the SLA see the [0042-LIQF spec](./0042-LIQF-setting_fees_and_rewarding_lps.md). + + +## Mechanism overview + +At a high level, the liqudity mechanism in Vega allows Liquidity Providers (LPs) to commit liquidity to a market and "bid" to set the liqudity fee on the market. LPs that meet this commitment are rewarded from the fee revenue. This is done by: + +- Requiring LPs to meet an SLA (i.e. % of time spent providing liquidity within the defined range) in order to be rewarded. + +- Rewarding LPs more for better performance against the SLA vs other LPs, ensuring there is an incentive to do more than the bare minimum and more than other LPs, if market conditions allow. + +- Penalising LPs that commit and do not meet the SLA, to reduce the attractiveness of opportunistically going after rewards with no intention to meet the SLA in more challenging conditions, and of leeching style attacks on the rewards. + +Once committed LPs attempt to meet their comitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and iceberg to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. + ## Commit liquidity network transaction @@ -19,27 +53,12 @@ Any Vega participant can apply to become a liquidity provider (LP) on a market b 1. Market ID 1. COMMITMENT AMOUNT: liquidity commitment amount (specified as a unitless number that represents the amount of settlement asset of the market) 1. FEES: nominated [liquidity fee factor](./0029-FEES-fees.md), which is an input to the calculation of taker fees on the market, as per [setting fees and rewarding lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) -1. ORDERS: a set of _liquidity buy orders_ and _liquidity sell orders_ ("buy shape" and "sell shape") to meet the liquidity provision obligation, see [MM orders spec](./0038-OLIQ-liquidity_provision_order_type.md). Accepted if all of the following are true: -- The order is valid - see [0038-OLIQ-Liquidity provision order type spec](./0038-OLIQ-liquidity_provision_order_type.md) for full details -- The participant has sufficient collateral in their general account to meet the size of their nominated commitment amount as well as the margin requirements +- The transaction is valid: the submitting party has sufficient collateral in their general account to meet the size of their nominated commitment amount. - The market is in a state that accepts new liquidity provision [market lifecycle spec](./0043-MKTL-market_lifecycle.md). -General notes: - -- If market is in auction mode it won't be possible to check the margin requirements for orders generated from LP commitment. If on transition from auction the funds in margin and general accounts are insufficient to cover the margin requirements associated with those orders funds in bond account should be used to cover the shortfall (with no penalty applied as outlined in the [Penalties](#penalties) section). If even the entire bond account balance is insufficient to cover those margin requirement the liquidity commitment transaction should get cancelled. - -### Valid submission combinations - -Assume `MarketID` is always submitted, then a participant can submit the following combinations: - -1. A transaction containing all fields specified can be submitted at any time to either create or change a commitment (if commitment size is zero, the orders and fee bid cannot be supplied - i.e. tx is invalid) -1. Any other combination of a subset of fields can be supplied any time a liquidity provider has a non-zero commitment already, to request to amend part of their commitment. - -Example: it's possible to amend fee bid or orders individually or together without changing the commitment level. -Example: amending only a commitment amount but retaining old fee bid and orders is also allowed. ## COMMITMENT AMOUNT @@ -48,13 +67,14 @@ Example: amending only a commitment amount but retaining old fee bid and orders When a commitment is made the liquidity commitment amount is assumed to be specified in terms of the settlement currency of the market. There is an minimum LP stake which is `market.liquidityProvision.minLpStakeQuantumMultiple x quantum` where `quantum` is specified per asset, see [asset framework spec](./0040-ASSF-asset_framework.md). -If the participant has sufficient collateral to cover their commitment and margins for the orders generated from their proposed commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are commitment liquidity, created as needed). For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). +If the participant has sufficient collateral to cover their commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are committing liquidity, created as needed). +For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). Liquidity provider bond account: - Each active market has one bond account per liquidity provider, per settlement asset for that market. - When a liquidity provider transaction is approved, the size of their staked bond is immediately transferred from their general account to this bond account. -- A liquidity provider can only prompt a transfer of funds to or from this account by submitting a valid transaction to create, increase, or decrease their commitment to the market, which must be validated and pass all checks (e.g. including those around minimum liquidity commitment required, when trying to reduce commitment). +- A liquidity provider can only prompt a transfer of funds to or from this account by (re)submitting the LP commitment transaction: a valid transaction to create, increase, or decrease their commitment to the market. - Transfers to/from this account also occur when it is used for settlement or margin shortfall, when penalties are applied, and if the account is under-collateralised because of these uses and is subsequently topped up to the commitment amount during collateral search (see below) - Collateral withdrawn from this account may only be transferred to either: - The insurance pool of the market (in event of penalties/slashing) @@ -115,36 +135,22 @@ The [liquidity_fee](./0029-FEES-fees.md) of a market on Vega takes as an input, When calculating fees for a trade, the size of a liquidity provider’s commitment along with when they committed and the market size are inputs that will be used to calculate how the liquidity fee is distributed between liquidity providers. See [setting fees and rewarding lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) for the calculation of the split. -## Orders (buy shape/sell shape) - -In a market maker proposal transaction the participant must submit a valid set of liquidity provider orders (buy shape and sell shape). Liquidity provider orders are a special order type described in the [liquidity provision orders spec](./0038-OLIQ-liquidity_provision_order_type.md). Validity is also defined in that spec. Note, liquidity provider participants can place regular (non liquidity provider orders) and these are considered to be contributing to them meeting their obligation, but they must also have provided the set of valid buy/sell orders as described in the [liquidity provision orders spec](./0038-OLIQ-liquidity_provision_order_type.md). - -A liquidity provider can amend their orders by providing a new set of liquidity provision orders in the liquidity provider network transaction. If the amended orders are invalid the transaction is rejected, and the previous set of orders will be retained. - -### Checking margins for orders - -As pegged orders are parked during an auction and not placed on the book, margin checks will not occur for these orders. This includes checking the orders margin when checking the validity of the transaction so orders are accepted. Open positions are treated the same as any other open positions and their liquidity provider orders are pegged orders and will be treated the same as any other pegged orders. ## Liquidity provision and penalties ### Calculating liquidity from commitment -Each liquidity provider supplies an amount of liquidity which is calculated from their commitment (stake) and measured in 'currency siskas' (i.e. USD siskas, ETH siskas, etc.).This is calculated by multiplying the stake by the network parameter `market.liquidity.stakeToCcyVolume` as follows: - -`lp_liquidity_obligation_in_ccy_volume = market.liquidity.stakeToCcyVolume ⨉ stake`. - -Note here "ccy" stands for "currency". Liquidity measure units are 'currency x volume'. This is because the calculation is basically `volume ⨉ price of the volume` and the price of the volume is in the said currency. - -### How liquidity is supplied +Committed Liqudity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined by TODO: define. -When a liquidity provider commits to a market, the LP Commitment transaction includes a _buy shape_ and _sell shape_ which allow the LP to spread their liquidity provision over a number of pegged orders at varying distances from the best prices on each side of the book. These 'shapes' are used to generate pegged orders (see the [liquidity provision order type spec](./0038-OLIQ-liquidity_provision_order_type.md)). +The multiple is controlled by a network parameter `market.liquidity.stakeToCcyVolume`: -Since liquidity provider orders automatically refresh, the protocol ensures that a liquidity provider always supplies their committed liquidity as long as they have sufficient capital to meet the margin requirements of these orders. +``` +liquidity_required = stake_amount ✖️ market.liquidity.stakeToCcyVolume +``` **During auction:** -- Pegged orders generated from liquidity provider Commitments are parked like all pegged orders during auctions. Limit orders placed by liquidity providers obey the normal rules for their specific order type in an auction. -- Liquidity providers are not required to supply any orders that offer liquidity or trade during an auction uncrossing. They must maintain their stake however and their liquidity will be placed back on the book when normal trading resumes. +- Liquidity providers, who wish to meet their SLA, are expected to supply liquidity during auctions. ### Penalties @@ -173,7 +179,7 @@ The network will: Note: -- As mentioned above, closeout should happen as per regular trader account (with the addition of cancelling the liquidity provision and the associated LP rewards & fees consequences). So, if after cancelling all open orders (both manually maintained and the ones created automatically as part of liquidity provision commitment) the party can afford to keep the open positions sufficiently collateralised they should be left open, otherwise the positions should get liquidated. +- As mentioned above, closeout should happen as per regular trader account (with the addition of cancelling the liquidity provision and the associated LP rewards & fees consequences). So, if after cancelling all open orders the party can afford to keep the open positions sufficiently collateralised they should be left open, otherwise the positions should get liquidated. - Bond account balance should never get directly confiscated. It should only be used to cover margin shortfalls with appropriate penalty applied each time it's done. Once the funds are in margin account they should be treated as per normal rules involving that account. ### Bond account top up by collateral search @@ -182,12 +188,6 @@ In the same way that a collateral search is initiated to attempt to top-up a tra This should happen every time the network is performing a margin calculation and search. The system should prioritise topping up the margin account first, and then the bond account, if there are insufficient funds to do both. -## Network parameters - -- `market.liquidity.bondPenaltyParameter` - used to calculate the penalty to liquidity providers when they fail to meet their obligations. -Valid values: any decimal number `>= 0` with a default value of `0.1`. -- `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of [lp order type](./0038-OLIQ-liquidity_provision_order_type.md). Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. -- `market.liquidity.stakeToCcySiskas` - used to translate a commitment to an obligation (in siskas). Any decimal number `>0` with default value `1`. ## What data do we keep relating to liquidity provision? @@ -207,7 +207,6 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - Through the API, I can list all active liquidity providers for a market (0044-LIME-001) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) -- Change of `market.liquidityProvision.shapes.maxSize` will change the maximum number of entries in the order shape of the LP commitment. If `market.liquidityProvision.shapes.maxSize` is decreased all the LP orders that have already been submitted are unaffected. However any new submissions or amendments must respect the new (lower) maximum. (0044-LIME-005) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) - Check that bond slashing works with non-default asset decimals, market decimals, position decimals. This can be done by following a similar story to [bond slashing feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature). Should test at least three different combinations, each decimal settings different to each other. (0044-LIME-009) - Change of `market.liquidity.stakeToCcyVolume` will change the liquidity obligation hence change the size of the LP orders on the order book. (0044-LIME-010) From 5b0a25dc5df159b981ff3b0cc6ce742053c4b224 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Sun, 30 Apr 2023 14:40:37 +0200 Subject: [PATCH 049/649] feat: SLA liquidity --- ...042-LIQF-setting_fees_and_rewarding_lps.md | 78 +++++++++++++------ protocol/0044-LIME-lp_mechanics.md | 2 + 2 files changed, 55 insertions(+), 25 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 33875edd7..006ae4cfb 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -213,49 +213,77 @@ The liquidity fees are transferred from the market LP fee account into the LP-pe The LP parties don't control the LP-per-market fee account; the fees from there are then tranferred to the LPs' general account at the end epoch as described below. -### Distributing fees from LP-per-market-fee accounts based on meeting SLA commitments +### Calculating SLA performance +#### Measuring time spent meeting their commitment + +During the epoch, the amount of time in nanoseconds (of Vega time) that each LP spends meeting the SLA is recorded. This can be done by maintaning a counter `s_i` as shown below: + +* At the start of a new epoch, `s_i = 0` + + * If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. + +* At the end of each block: + + * If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): + + * Store the current Vega time as the time the LP began meeting their commitment + + * If LP has stopped meeting their committed volume of notional after previously doing so: + + * Add the difference in nanoseconds between the current Vega time and the time the LP began meeting their commitment (stored in the step above) to `s_i` + + * Store `nothing` as the time the LP began meeting their commitment, to signify the LP not meeting their commitment + +* At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. + +Note that we only need to evaluate each LP's status at the end of each block, as no _Vega time_ passes between transactions in a block. + +### Calculating SLA performance + +<<<<<<< HEAD Flooring non-zero amounts due to integer representation can result in a remainder in the liquidity fee account. The remainder should be left in the market liquidity fee account and carried over to the next distribution window. If the fees are being distributed as a part of market settlement and distribution results in a remainder in the liquidity fee account. The remainder should be transferred to the network treasury for that asset. -#### Example +#### Calculating the SLA performance penalty -We have `4` LPs with equity-like share shares: -share as below +Calculate the fraction of the time the LP spent on the book: -```text -LP 1 els = 0.65 -LP 2 els = 0.25 -LP 3 els = 0.1 +``` +fraction_of_time_on_book = s_i / observed_epoch_length ``` -Trade happened, and the trade value for fee purposes multiplied by the liquidity fee factor is `103.5 ETH`. The following amounts be collected immediately into the LP fee accounts for the market: +For any LP where `fraction_of_time_on_book < market.liquidity.commitmentMinTimeFraction` the SLA penalty fraction `p_i = 1` (that is, the penalty is 100% of their fees). -```text -0.65 x 103.5 = 67.275 ETH to LP 1's LP account -0.25 x 103.5 = 25.875 ETH to LP 2's LP account -0.10 x 103.5 = 10.350 ETH to LP 3's LP account +For each LP where `fraction_of_time_on_book ≥ market.liquidity.commitmentMinTimeFraction`, the SLA penalty fraction `p_i` is calculated as follow: + +```python +p_i = (1.0 - (fraction_of_time_on_book - market.liquidity.committmentMinTimeFraction) / (1.0 - market.liquidity.committmentMinTimeFraction)) * market.liqudity.slaCompetitionFactor ``` -Then LP 4 made a delayed LP commitment, and updated share as below: +### Applying LP SLA performance penalties to accrued fees -```text -LP 1 els = 0.43 -LP 2 els = 0.17 -LP 3 els = 0.07 -LP 4 els = 0.33 -``` +As defined above, for each LP for each epoch you have "penalty fraction" `p_i` which is between `[0,1]` with `0` indicating LP has met committment 100% of the time and `1` indicating that LP was below `market.liquidity.committmentMinTimeFraction` of the time. -When the time defined by `market.liquidity.providers.fee.calculationTimeStep` elapses we do transfers: +Calculate `w_i = LP-per-market fee i / sum over all LP-per-market fee accounts`. +For each LP transfer `(1-p_i) x amount in LP-per-market fee account` to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -```text -67.275 ETH from LP 1's LP account to LP 1's general account -25.875 ETH from LP 2's LP account to LP 2's general account -10.350 ETH from LP 3's LP account to LP 3's general account +Tranfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. Record its balance to be `B`. + +Let `b_i := (1-p_i) x w_i` and renormalise `b_i`s so that they sum up to `1` i.e. +``` +b_i <- b_i / (sum over i of all b_i). ``` +Each LP further gets a performance bonus: `b_i x B` with a transfer type that marks this as the "LP relative SLA performance bonus distribution". + +Note that after this process completes the balance of the temporary (one per market) bonus distribution account decscribed above **must be zero** and the account may be destroyed (and recreated again when needed). + +There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's tranfer this to a fixed example. + + ### APIs for fee splits and payments diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index d3913f46e..e9fc22547 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -30,6 +30,8 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liqudity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. +- `market.liqudity.slaCompetitionFactor` - the maximum fraction of their accrued fees an LP that meets the SLA implied by `market.liquidity.committmentMinTimeFraction` will lose to LPs that achieved a higher SLA performance than them. + For LP reward calculations based on the SLA see the [0042-LIQF spec](./0042-LIQF-setting_fees_and_rewarding_lps.md). From e4f27faf44c31d8b61c329566e45a6d2ed55744e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 1 May 2023 14:29:59 +0200 Subject: [PATCH 050/649] feat: SLA liquidity --- ...038-OLIQ-liquidity_provision_order_type.md | 218 ------------------ ...042-LIQF-setting_fees_and_rewarding_lps.md | 32 ++- protocol/0044-LIME-lp_mechanics.md | 60 +++-- 3 files changed, 62 insertions(+), 248 deletions(-) delete mode 100644 protocol/0038-OLIQ-liquidity_provision_order_type.md diff --git a/protocol/0038-OLIQ-liquidity_provision_order_type.md b/protocol/0038-OLIQ-liquidity_provision_order_type.md deleted file mode 100644 index dcda386c2..000000000 --- a/protocol/0038-OLIQ-liquidity_provision_order_type.md +++ /dev/null @@ -1,218 +0,0 @@ -# Liquidity Provisioning Order Type - -## Summary - -When market makers commit to providing liquidity they are required to submit a set of valid buy shapes and sell shapes [Liquidity Provisioning mechanics](./0044-LIME-lp_mechanics.md). This commitment will ensure that they are eligible for portion of the market fees as set out in [Setting Fees and Rewarding Market Makers](./0042-LIQF-setting_fees_and_rewarding_lps.md). - -## Liquidity Provisioning order features - -LP orders are a special order type with the following features: - -- Is a batch order: allows simultaneously specifying multiple orders in one message/transaction -- Initially all are pegged orders but other price types may be available in future -- Are always priced limit orders that sit on the book -- Are “post only” and do not trade on entry (as per normal pegged orders) -- The order is always refreshed after it trades (once the tx is processed so not refreshed before closeouts, etc.) based on the above requirements so that the full commitment is always supplied. - -## How they are submitted - -2 x shapes are submitted as part of a market making transaction (one for buy side, one for sell side). Each entry in this shape must specify a proportion of the liquidity obligation applicable to that entry and a price peg. - -The network will translate these shapes into order book volume by creating an order set according to a set of rules (see below). - -Each entry must specify: - -1. **Liquidity proportion:** the relative proportion of the commitment to be allocated at a price level. Note, the network will normalise the liquidity proportions of the refined order set (see below). This must be a strictly positive number. - -2. A **price peg:** , as per normal [pegged orders](../protocol/0037-OPEG-pegged_orders.md), a price level specified by a reference point (e.g mid, best bid, best offer) and an amount of units away. The amount is always positive and is subtracted for buy orders and added for sell orders to the reference price. - -```proto -# Example 1: -Buy-shape: { - buy-entry-1: [buy-liquidity-proportion-1, [buy-price-peg-reference-1, buy-number-of-units-from-reference-1]], - buy-entry-2: [buy-liquidity-proportion-2, [buy-price-peg-reference-2, buy-number-of-units-from-reference-2]], -} -Sell-shape: { - sell-entry-1: [sell-liquidity-proportion-1, [sell-price-peg-reference-1, sell-number-of-units-from-reference-1]], - sell-entry-2: [sell-liquidity-proportion-2, [sell-price-peg-reference-2, sell-number-of-units-from-reference-2]], -} - -# Example 1 with values -Buy-shape: { - buy-entry-1: [2, [best-bid, 10]], - buy-entry-2: [13, [best-bid, 11]], -} -Sell-shape: { - sell-entry-1: [5, [best-ask, 8]], - sell-entry-2: [5, [best-ask, 9]], -} - -``` - -## How they are constructed for the order book - -Input data: - -1. The commitment, buy-shape, sell-shape (as submitted in the [liquidity provision network transaction](./0038-OLIQ-liquidity_provision_order_type.md).) -1. Any persistent orders that the liquidity provider has on the book at a point in time. - -### Refining list of orders - -Steps: - -1. From the market parameter - to be set as part of [market proposal](0028-GOVE-governance.md) `market.liquidity.priceRange` which is a percentage price move (e.g. `0.05 = 5%` and from `mid_price` calculate: - -`min_lp_price = (1.0 - market.liquidity.priceRange) x mid_price` - -and - -`max_lp_price = (1.0 + market.liquidity.priceRange) x mid_price` - -1. Calculate `liquidity_obligation`, as per calculation in the [market making mechanics spec](./0044-LIME-lp_mechanics.md). - -1. The `liquidity_obligation` calculated as per [LP mechanics](0044-LIME-lp_mechanics.md). Some of it may be fulfilled by persistent orders the liquidity provider has on the book at this point in time that are between and including `min_lp_vol_price` and `max_lp_vol_price`. -The contribution is `volume x price`; sum up the contribution across the relevant side of the book and subtract it from `liquidity_obligation` obtained above. -If you end up with 0 or a negative number, stop, you are done. - -1. Using the adjusted `liquidity_obligation`, calculate the `liquidity-normalised-proportion` for each of the remaining entries in the buy / sell shape (for clarity, this does not include any other persistent orders that the market maker has). - -1. Calculate the volume implied by each entry in the refined buy/sell order list. You will now create orders from this volume at the relevant price point and apply them to the order book. - -#### Normalising liquidity proportions for a set of market making orders (step 3) - -Calculate the `liquidity-normalised-proportion` for all entries, where for buy and sell side separately: - -`liquidity-normalised-proportion = liquidity-proportion-for-entry / sum-all-entries(liquidity-proportion-for-order)` - -```math -Example 1 (from above) where refined-order-list = [buy-entry-1, buy-entry-2, sell-entry-1, sell-entry-2]: - -liquidity-normalised-proportion-buy-order-1 = 2 / (2 + 13) = 0.13333... -liquidity-normalised-proportion-buy-order-2 = 13 / (2 + 13) = 0.86666... -liquidity-normalised-proportion-sell-order-1 = 5 / (5 + 5) = 0.5 -liquidity-normalised-proportion-sell-order-2 = 5 / (5 + 5) = 0.5 - -``` - -The sum of all normalised proportions must = 1 on each side. - -#### Calculating volumes for a set of market making orders (step 6) - -Any shape entry with a peg less than `min_lp_vol_price` should have the resulting volume implied at `min_lp_vol_price` (instead of what level the peg would be) while any shape entry with peg greater than `max_lp_vol_price` should have the resulting volume implied at `max_lp_vol_price`. - -Calculate the volume at the peg as - -`volume = ceiling(liquidity_obligation x liquidity-normalised-proportion / price)`. - -where `liquidity_obligation` is calculated as defined in the [market making mechanics spec](./0044-LIME-lp_mechanics.md) and `price` is the price level at which the `volume` will be placed. -At this point `volume` may have decimal places. - -Note: if the resulting quote price of any of the entries in the buy / sell shape leads to negative product value from the [product quote-to-value function](0051-PROD-product.md#quote-to-value-function) but strictly positive volume then the entire LP order for this LP is undeployed, their stake won't count towards target stake being met and they shall not receive any LP fees regardless of their equity-like share. This can lead to a [liquidity auction](0035-LIQM-liquidity_monitoring.md) if the supplied stake for the market is below the required level due to this LP. - -Note: calculating the order volumes needs take into account Position Decimal Places and create values (which may be int64s or similar) that are the correct size and precision given the number of Position Decimal Places specified in the [Market Framework](./0001-MKTF-market_framework.md). -This means that the `integerVolume = ceil(volume x 10^(PDP))`. -For example, if the offset, commitment and prob of trading imply volume of say `0.65` then the `integerVolume` we want to see on the book depends on position decimals. If we have: - -- `0dp` then round up to volume `1` -- `1dp` then round up to volume `7` (i.e. `0.7` i.e. `1dp`). -- `3dp` then no need for any rounding it's `650` (i.e. `0.650`) - -and so on. - -```proto -Example: - -best-static-bid-on-order-book = 103 - -shape-entry = { - peg: {reference: 'best-bid', units-from-ref: 2}, - liquidity-normalised-proportion-order: 0.32 -} - -peg-implied-price = 103 - 2 = 101 - -Call probability-of-trading function with best-static-bid-on-order-book = 105, time-horizon given by risk model tau multiplied by `market.liquidity.probabilityOfTrading.tau.scaling`, peg-implied-price. - -This will return probably of trading at price = 101. This can be used in the formula for volume, above. - -``` - -## Refreshing of orders / recalculating order volume - -Liquidity provider orders are recalculated and refreshed whenever an order that is part of the commitment has changed, including if a market maker's order(s) have traded (both persistent orders and shape implied orders), orders are amended, cancelled, or expired. - -In these cases, repeat all steps above, preserving the order as an order, but recalculating the volume and price of it. Note, this should only happen at the end of a transaction (that caused the trade), not immediately following the trade itself. - -### Time priority for refreshing - -1. For all orders that are repriced but not as a result of trading (i.e. pegged orders that move as a result of peg moving), treat as per normal pegged orders. - -1. The system should refresh the liquidity provider's pegged orders, in time priority according to which traded first (see below example). - -________________________ -**Example**: we have a buy side of an order book that looks like this: - -```proto -{ - [mm-1-order, buy-volume=3, buy-price=100, order-time=13007] - [mm-2-order, buy-volume=5, buy-price=99, order-time=13004] -} -``` - -and a new market order sells 8. Then, a plausible refreshed set of orders could look like this*: - -```proto -add this first - [mm-1-order, buy-volume=3, buy-price=97, order-time=16458] - -and then this - [mm-2-order, buy-volume=5, buy-price=96, order-time=16459] -``` - -*Note: the actual values of the buy-prices and buy-volumes are dependent on the result of step 2 above and this example is not to test that, so don't try to replicate this with numbers, it's for illustrative purposes only. -________________________ - -### Transfers in / out of margin account - -When the system refreshes orders (because a peg moved) and the implied volumes now sit at different price levels there may be different overall margin requirement for the LP party. -If the resulting amount is outside search / release then there will be *at most* one transfer in / out of the party's margin account for the entire LP order. - -## Amending the LP order - -Liquidity providers are always allowed to amend their shape generated orders by submitting a new liquidity provider order with a set of revised order shapes (see [Liquidity Provisioning mechanics](./0044-LIME-lp_mechanics.md)). They are not able to amend orders using "normal" amend orders. - -No cancellation of orders that arise from this LP batch order type other than by lowering commitment as per [[Liquidity Provisioning mechanics spec](./0044-LIME-lp_mechanics.md). - -Note that any other orders that the LP has on the book (limit orders, other pegged orders) that are *not* part of this LP batch order (call them "normal" in this paragraph) can be cancelled and amended as normal. When volume is removed / added / pegs moved (on "normal" orders) then as part of the normal peg updates the LP batch order may add or remove volume as described in section "How they are constructed for the order book" above. - - -## Network Parameters - -- `market.liquidity.probabilityOfTrading.tau.scaling`: scaling factor multiplying risk model value of tau to imply probability of trading. -- `market.liquidity.minimum.probabilityOfTrading.lpOrders`: a minimum probability of trading; any shape proportions at pegs that would have smaller probability of trading are to be moved to pegs that imply price that have probability of trading no less than the `market.liquidity.minimum.probabilityOfTrading.lpOrders`. - -## APIs - -- Order datatype for LP orders. Any order APIs should contain these orders. - -## Acceptance Criteria - -- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios there. (0038-OLIQ-001); -- Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0034-PROB-liquidity_measure.feature) in all the various scenarios that test fractional order sizes (smallest order position of 0.01). (0038-OLIQ-002); -- If an LP order has offset set such that the resulting price falls outside `[min_lp_vol_price, max_lp_vol_price]` then the system adjusts it automatically so that it's placed on the bound (0038-OLIQ-011) - -### LP commitment order creation - -- A liquidity provisioning order must specify orders for both sides of the book (0038-OLIQ-003) -- All orders created by an LP commitment must be pegged orders (0038-OLIQ-004) -- Filled orders are replaced immediately to conform to the LP commitment shapes (0038-OLIQ-005) -- Change of the market parameter `market.liquidity.priceRange` which decreases the value will, when volumes are next recalculated, tighten `[min_lp_vol_price, max_lp_vol_price]` and volume that was previously pegged inside the valid range and would now be outside is shifted to the bounds. (0038-OLIQ-012) -- Change of the market parameter `market.liquidity.priceRange` which increases the value will, when volumes are next recalculated, widen `[min_lp_vol_price, max_lp_vol_price]` and volume that was previously being shifted to stay inside the range is now deployed at the desired peg. (0038-OLIQ-013) - -### LP commitment amendment - -- If amending a commitment size would reduce the market's supplied liquidity below the target stake, the amendment will be rejected (see [0035 Liquidity Monitoring](./0035-LIQM-liquidity_monitoring.md#decreasing-supplied-stake)) (0038-OLIQ-006) - -### LP commitment repricing due to peg price moves - -- If best bid / ask has changed and the LP order volume is moved around to match the shape / new peg levels then the margin requirement for the party may change. There is at most one transfer in / out of the margin account of the LP party as a result of one of the pegs moving. (0038-OLIQ-008) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 006ae4cfb..3da6257d1 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -217,7 +217,7 @@ The LP parties don't control the LP-per-market fee account; the fees from there ### Calculating SLA performance -#### Measuring time spent meeting their commitment +#### Measuring time spent meeting their commitment in a single epoch During the epoch, the amount of time in nanoseconds (of Vega time) that each LP spends meeting the SLA is recorded. This can be done by maintaning a counter `s_i` as shown below: @@ -248,7 +248,7 @@ Flooring non-zero amounts due to integer representation can result in a remainde If the fees are being distributed as a part of market settlement and distribution results in a remainder in the liquidity fee account. The remainder should be transferred to the network treasury for that asset. -#### Calculating the SLA performance penalty +#### Calculating the SLA performance penalty for a single epoch Calculate the fraction of the time the LP spent on the book: @@ -264,20 +264,34 @@ For each LP where `fraction_of_time_on_book ≥ market.liquidity.commitmentMinTi p_i = (1.0 - (fraction_of_time_on_book - market.liquidity.committmentMinTimeFraction) / (1.0 - market.liquidity.committmentMinTimeFraction)) * market.liqudity.slaCompetitionFactor ``` +#### Calculating the SLA performance penalty for over hysteresis period + +Now, for each LP $i$ take the $p_i$ values calculated over the last `market.liqudity.performanceHysteresisEpochs - 1`, call these $p_i^1, p_i^2, ..., p_i^{n-1}$ (if all the historical ones are not yet available, take as many as there are - i.e. expanding window till you get to the full length). + +Now calculate $p_i^n$ to be the arithmetic average of $p_i^k$ for $k = 1,2,...,n-1$. +Finally set +$$ +p_i^n \leftarrow \max(p_i,p_i^n)\,. +$$ +i.e. your penalty is the bigger of current epoch and average over the hysteresis period + ### Applying LP SLA performance penalties to accrued fees As defined above, for each LP for each epoch you have "penalty fraction" `p_i` which is between `[0,1]` with `0` indicating LP has met committment 100% of the time and `1` indicating that LP was below `market.liquidity.committmentMinTimeFraction` of the time. -Calculate `w_i = LP-per-market fee i / sum over all LP-per-market fee accounts`. -For each LP transfer `(1-p_i) x amount in LP-per-market fee account` to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". +Calculate +$$ +w_i = \frac{\text{LP-per-market fee account}\, i}{\sum_k \text{LP-per-market fee account}\, k}. +$$ +For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". Tranfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. Record its balance to be `B`. -Let `b_i := (1-p_i) x w_i` and renormalise `b_i`s so that they sum up to `1` i.e. -``` -b_i <- b_i / (sum over i of all b_i). -``` -Each LP further gets a performance bonus: `b_i x B` with a transfer type that marks this as the "LP relative SLA performance bonus distribution". +Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. +$$ +b_i \leftarrow \frac{b_i}{\sum_k b_k}\,. +$$ +Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". Note that after this process completes the balance of the temporary (one per market) bonus distribution account decscribed above **must be zero** and the account may be destroyed (and recreated again when needed). diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index e9fc22547..d9e1b6826 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -18,7 +18,9 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of [lp order type](./0038-OLIQ-liquidity_provision_order_type.md). Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. - `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). - +- `market.liquidity.earlyExitPenalty` (decimal between 0 and 1 inclusive), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited. +- `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). +- `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. ### Market parameters @@ -62,7 +64,7 @@ Accepted if all of the following are true: - The market is in a state that accepts new liquidity provision [market lifecycle spec](./0043-MKTL-market_lifecycle.md). -## COMMITMENT AMOUNT +## Commitment amount ### Processing the commitment @@ -83,45 +85,45 @@ Liquidity provider bond account: - The liquidity provider's margin account or the network's settlement account/other participant's margin accounts (during a margin search and mark to market settlement) in the event that they have zero balance in their general account. - The liquidity provider's general account (in event of liquidity provider reducing their commitment) -### liquidity provider proposes to amend commitment amount +### Liquidity provider proposes to amend commitment amount The commitment transaction is also used to amend any aspect of their liquidity provision obligations. A participant may apply to amend their commitment amount by submitting a transaction for the market with a revised commitment amount. `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` -#### INCREASING COMMITMENT +#### Increasing commitment _Case:_ `proposed-commitment-variation >= 0` A liquidity provider can always increase their commitment amount as long as they have sufficient collateral in the settlement asset of the market to meet the new commitment amount and cover the margins required. If they do not have sufficient collateral the transaction is rejected in entirety. This means that any data from the fees or orders are not applied. This means that the `old-commitment-amount` is retained. -#### DECREASING COMMITMENT +#### Decreasing commitment _Case:_ `proposed-commitment-variation < 0` -We to calculate whether the liquidity provider may lower their commitment amount and if so, by how much. To do this we first evaluate the maximum amount that the market can reduce by given the current liquidity demand in the market. +We to calculate how much the LP can reduce commitment without incurring a penalty. +To do this we first evaluate the maximum amount that the market can reduce without penalty by given the current liquidity demand in the market. -`maximum-reduction-amount = total_stake - target_stake` +`maximum-penalty-free-reduction-amount = total_stake - target_stake` where: - `total_stake` is the sum of all stake of all liquidity providers bonded to this market. - `target_stake` is a measure of the market's current stake requirements, as per the calculation in the [target stake](./0041-TSTK-target_stake.md). -- `actual-reduction-amount = min(-proposed-commitment-variation, maximum-reduction-amount)` -- `new-actual-commitment-amount = old-commitment-amount - actual-reduction-amount` -- `market.liquidityProvision.shapes.maxSize` is the maximum entry of the LP order shape on liquidity commitment. -i.e. liquidity providers are allowed to decrease the liquidity commitment subject to there being sufficient stake committed to the market so that it stays above the market's required stake threshold. The above formulae result in the fact that if `maximum-reduction-amount = 0`, then `actual-reduction-amount = 0` and therefore the liquidity provider is unable to reduce their commitment amount. +If `-proposed-commitment-variation <= maximum-penalty-free-reduction-amount` then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). -When `actual-reduction-amount > 0`: +If `-proposed-commitment-variation > maximum-penalty-free-reduction-amount` then first establish +``` +penalty-incuring-reduction-amount = -proposed-commitment-variation - maximum-penalty-free-reduction-amount +``` +Transfer `maximum-penalty-free-reduction-amount` to their general account. +Now transfer `(1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount` to their general account and transfer `market.liquidity.earlyExitPenalty x penalty-incuring-reduction-amount` to the market insurance pool. +Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire `proposed-commitment-variation` as the `delta`. -- the difference between their actual staked amount and new commitment is transferred back to their general account, i.e. -`transferred-to-general-account-amount = actual-stake-amount - new-actual-commitment-amount` -- the revised fee amount and set of orders are processed. +Note that as a consequence the market may land in a liquidity auction the next time the next time conditions for liquidity auctions are evaluated (but there is no need to tie the event of LP reducing their commitment to an immediate liquidity auction evaluation). -Example: if you have a commitment of 500DAI and your bond account only has 400DAI in it (due to slashing - see below), and you submit a new commitment amount of 300DAI, then we only transfer 100DAI such that your bond account is now square. -When `actual-reduction-amount = 0` the transaction is still processed for any data and actions resulting from the transaction's new fees or order information. ## Fees @@ -142,17 +144,33 @@ When calculating fees for a trade, the size of a liquidity provider’s commitme ### Calculating liquidity from commitment -Committed Liqudity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined by TODO: define. +Committed Liqudity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below. The multiple is controlled by a network parameter `market.liquidity.stakeToCcyVolume`: - ``` liquidity_required = stake_amount ✖️ market.liquidity.stakeToCcyVolume ``` -**During auction:** +### Meeting the committed volume of notional + +#### During continuous trading +If there is no mid price then no LP is meeting their committed volume of notional. +If there is mid price then we calculate the volume of notional that is in the range +``` +(1.0-market.liquidity.priceRange) x mid =< price levels that count <= (1+market.liquidity.priceRange)x mid. +``` +If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. + +#### During auctions +We calculate the volume of notional that is in the range +``` +(1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) =< price levels that count <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). +``` +If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. + + +Note: we don't evaluate whether LPs meet the SLA during opening auctions so there will always be a mark price. -- Liquidity providers, who wish to meet their SLA, are expected to supply liquidity during auctions. ### Penalties From 0492ce1081ae2f74947edc217d18b7f8b2694190 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 1 May 2023 14:41:40 +0200 Subject: [PATCH 051/649] feat: SLA liquidity --- protocol/0035-LIQM-liquidity_monitoring.md | 26 +++++++--------------- 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 8a7d58986..bce3bf5d2 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -9,12 +9,11 @@ Similarly to [price monitoring](./0032-PRIM-price_monitoring.md), we need to be Note that as long as all pegs that LP batch orders can peg to exists on the book there is one-to-one correspondence between the total stake committed by liquidity providers (LPs), see [LP mechanics](./0044-LIME-lp_mechanics.md) spec, and the total supplied liquidity. Indeed -`lp_liquidity_obligation_in_ccy_siskas = stake_to_ccy_siskas ⨉ stake`. +`lp_liquidity_obligation_in_ccy_volume = market.liquidity.stakeToCcyVolume ⨉ stake`. -Thus it is sufficient to compare `target_stake` with `total_stake` while also ensuring that `best_bid` and `best_offer` are present on the book (*). +Thus it is sufficient to compare `target_stake`. Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate spec. -(*) Having `best_bid` and `best_offer` implies that `mid` also exists. If, in the future, [LP batch orders](./0038-OLIQ-liquidity_provision_order_type.md) are updated to allow other pegs then the protocol must enforce that they are also on the book. ## Liquidity auction parameters @@ -28,7 +27,7 @@ Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate s The auction is triggered when -`total_stake < c_1 x target_stake OR there is no best_bid OR there is no best offer`. +`total_stake < c_1 x target_stake`. Here 0 < c1 < 1, to reduce the chance of another auction getting triggered soon after e.g. c1 = 0.7. The parameter c1 is a network parameter. @@ -40,21 +39,17 @@ If an incoming order would match orders on the book resulting in trades increasi ### Decreasing supplied stake -If the [liquidity provision transaction would decrease](./0044-LIME-lp_mechanics.md#liquidity-provider-proposes-to-amend-commitment-amount) `supplied_stake` so that liquidity auction gets triggered then the liquidity provision amendment should be rejected and market should stay in it's current trading mode. +If the [liquidity provision transaction would decrease](./0044-LIME-lp_mechanics.md#liquidity-provider-proposes-to-amend-commitment-amount) `supplied_stake` so that liquidity auction gets triggered then a liquidity auction is triggered the next time the next time conditions for liquidity auctions are evaluated. -If the `supplied_stake` decreases as a result of a closeout of an insolvent liquidity provider, then closeout should proceed and market should go into liquidity auction. - -### Removing `best_bid` or `best_offer` - -If an incoming order would get matched so that entire side of the order book gets consumed and `best_bid` or `best_offer` no longer exists, then the order should be allowed to go through and market should go into liquidity auction after it gets matched and the resulting trades get generated. +If the `supplied_stake` decreases as a result of a closeout of an insolvent liquidity provider, then closeout should proceed and market should go into liquidity auction the next time the next time conditions for liquidity auctions are evaluated. ## Trigger for exiting the auction We exit if -`total_stake >= target_stake AND there is best_bid AND there is best_offer`. +`total_stake >= target_stake`. -During the liquidity monitoring auction new or existing LPs can commit more stake (and hence liquidity) through the special market making order type and enable this by posting enough margin - see the [liquidity provision mechanics](./0044-LIME-lp_mechanics.md) spec for details. These need to be monitored to see if auction mode can be exit. +During the liquidity monitoring auction new or existing LPs can commit more stake (and hence liquidity) through the special market making order type and enable this by posting enough margin - see the [liquidity provision mechanics](./0044-LIME-lp_mechanics.md) spec for details. These need to be monitored to see if auction mode can be exitted. ## What happens during the auction? @@ -67,20 +62,15 @@ The auction proceeds as usual. Please see the [auction spec](./0026-AUCT-auction To resolve this, the conditions for entering a liquidity auction should only be checked at the end of each batch of transactions occurring with an identical timestamp (in the current Tendermint implementation this is equivalent to once per block). At the end of each such period the auction conditions should be checked and the market moved into liquidity auction state if the conditions for entering a liquidity auction are satisfied. The criteria for exiting any auction (liquidity or price monitoring) should be checked only on timestamp change (ie block boundary with Tendermint). This means that a market cannot leave a liquidity auction only to immediately re-enter it at the end of the block. - A liquidity provider amending LP provision order can reduce their stake (as long as total stake >= target stake) even if doing so would mean that at the end of block the system enters liquidity auction (because e.g. max open interest increased or because another LP was removed due to not meeting margin commitments). -An implication is that within the same time stamp an aggressive order may remove the `best_bid` or `best_ask`. At that point all LP provision volume is removed from the book (and by implication at least one side of the book is empty). If a subsequent limit order re-creates the peg (still with the same timestamp / from the same block) then the LP volume is re-deployed. If no subsequent limit order places a limit order restoring the peg and we reach end of the block we end up in a liquidity auction. - -As mentioned, as a consequence, intrablock, we may end with one side of the book empty which means that a party not meeting margin requirement *cannot* be closed out. We accept this consequence, their margin will be checked again when the mark price changes and either the book is restored (and they can get closed out) or the market is in liquidity auction. +A liquidity provider amending LP provision order can reduce their stake even if doing so would mean that at the end of block the system enters liquidity auction. ## Acceptance Criteria 1. The scenarios in the feature test [0026-AUCT-auction_interaction.feature](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0026-AUCT-auction_interaction.feature) are verified and pass. (0035-LIQM-001) -1. An incoming order that would consume `best_bid` or `best_offer` gets executed (unless it will also trigger price monitoring auction at the same time), the trades are generated. The volume implied by LP provision is removed (from both sides of the book and for all LPs). If `best_bid` is missing but `best_ask` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_ask` as peg are still deployed. If `best_ask` is missing but `best_bid` is present then all the "normal pegged orders" (i.e. not the LP ones) which use `best_bid` as peg are still deployed. The market goes into a liquidity auction at the end of a block (because there is a peg missing and the liquidity provision volume is not deployed). (0035-LIQM-002) 1. A market which enters a state requiring liquidity auction at the end of a block through increased open interest remains in open trading between entering that state and the end of the block. (0035-LIQM-003) 1. A market which enters a state requiring liquidity auction at the end of a block through decreased total stake (e.g. through LP bankruptcy) remains in open trading between entering that state and the end of the block. (0035-LIQM-004) 1. A market which enters a state requiring liquidity auction through increased open interest during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-005) 1. A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) -1. A liquidity provider cannot remove their liquidity within the block if this would bring the current total stake below the target stake as of that transaction. (0035-LIQM-007) 1. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) 1. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) 1. When proposing a new market if the triggering_ratio is not supplied then the current value of `market.liquidity.targetstake.triggering.ratio` is used in its place. (0035-LIQM-011) From 40a9c6f403434b0360b506f72069fd6f9403d304 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 1 May 2023 15:14:19 +0200 Subject: [PATCH 052/649] feat: SLA liquidity --- protocol/0044-LIME-lp_mechanics.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index d9e1b6826..49a1b9a9e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -13,8 +13,9 @@ Important note on wording: ### Network parameters -- `market.liquidity.bondPenaltyParameter` - used to calculate the penalty to liquidity providers when they fail to meet their obligations. +- `market.liquidity.bondPenaltyParameter` - used to calculate the penalty to liquidity providers when they fail to support their open position through sufficient `general+margin` balance. Valid values: any decimal number `>= 0` with a default value of `0.1`. +- `market.liquidity.sla.nonPerformanceBondPenalty` - use to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` with a default value of `2.0`. - `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of [lp order type](./0038-OLIQ-liquidity_provision_order_type.md). Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. - `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). @@ -172,7 +173,22 @@ If this is greater than or equal to `liquidity_required` then the LP is meeting Note: we don't evaluate whether LPs meet the SLA during opening auctions so there will always be a mark price. -### Penalties +### Penalty for not meeting the SLA + +See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. +This is available at the end of each epoch. +If, at, the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. +Otherwise we calculate a penalty to be applied to the bond as follows. +Let $t$ be `fraction_of_time_on_book` and let $s$ be `market.liquidity.committmentMinTimeFraction`. +Let $p$ be `market.liquidity.sla.nonPerformanceBondPenalty`. +Let +$$ +f = p - \frac{p}{s}t\,. +$$ +Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. +Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). + +### Penalty for not supporting open positions If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. From 5b329ba49905cd0c1f728504de72ccd58dfb58f2 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 1 May 2023 15:58:15 +0200 Subject: [PATCH 053/649] feat: SLA liquidity --- protocol/0044-LIME-lp_mechanics.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 49a1b9a9e..6e6186950 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -15,7 +15,8 @@ Important note on wording: - `market.liquidity.bondPenaltyParameter` - used to calculate the penalty to liquidity providers when they fail to support their open position through sufficient `general+margin` balance. Valid values: any decimal number `>= 0` with a default value of `0.1`. -- `market.liquidity.sla.nonPerformanceBondPenalty` - use to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` with a default value of `2.0`. +- `market.liquidity.sla.nonPerformanceBondPenaltySlope` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` with a default value of `2.0`. +- `market.liquidity.sla.nonPerformanceBondPenaltyMax` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` and `<=1.0` with a default value of `0.5`. - `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of [lp order type](./0038-OLIQ-liquidity_provision_order_type.md). Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. - `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). @@ -180,10 +181,11 @@ This is available at the end of each epoch. If, at, the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. Otherwise we calculate a penalty to be applied to the bond as follows. Let $t$ be `fraction_of_time_on_book` and let $s$ be `market.liquidity.committmentMinTimeFraction`. -Let $p$ be `market.liquidity.sla.nonPerformanceBondPenalty`. +Let $p$ be `market.liquidity.sla.nonPerformanceBondPenaltySlope`. +Let $m$ be `nonPerformanceBondPenaltyMax`. Let $$ -f = p - \frac{p}{s}t\,. +f = \min\left(m,p - \frac{p}{s}t\right)\,. $$ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). From 9a26660e1fadae0f385eef885888a18675475222 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 1 May 2023 16:04:31 +0200 Subject: [PATCH 054/649] feat: SLA liquidity --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 6 ++++++ protocol/0044-LIME-lp_mechanics.md | 2 ++ 2 files changed, 8 insertions(+) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 3da6257d1..eb72d15fa 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -270,9 +270,11 @@ Now, for each LP $i$ take the $p_i$ values calculated over the last `market.liqu Now calculate $p_i^n$ to be the arithmetic average of $p_i^k$ for $k = 1,2,...,n-1$. Finally set + $$ p_i^n \leftarrow \max(p_i,p_i^n)\,. $$ + i.e. your penalty is the bigger of current epoch and average over the hysteresis period ### Applying LP SLA performance penalties to accrued fees @@ -280,17 +282,21 @@ i.e. your penalty is the bigger of current epoch and average over the hysteresis As defined above, for each LP for each epoch you have "penalty fraction" `p_i` which is between `[0,1]` with `0` indicating LP has met committment 100% of the time and `1` indicating that LP was below `market.liquidity.committmentMinTimeFraction` of the time. Calculate + $$ w_i = \frac{\text{LP-per-market fee account}\, i}{\sum_k \text{LP-per-market fee account}\, k}. $$ + For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". Tranfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. Record its balance to be `B`. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. + $$ b_i \leftarrow \frac{b_i}{\sum_k b_k}\,. $$ + Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". Note that after this process completes the balance of the temporary (one per market) bonus distribution account decscribed above **must be zero** and the account may be destroyed (and recreated again when needed). diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 6e6186950..eeaeadac4 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -184,9 +184,11 @@ Let $t$ be `fraction_of_time_on_book` and let $s$ be `market.liquidity.committme Let $p$ be `market.liquidity.sla.nonPerformanceBondPenaltySlope`. Let $m$ be `nonPerformanceBondPenaltyMax`. Let + $$ f = \min\left(m,p - \frac{p}{s}t\right)\,. $$ + Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). From dac81125a966b1381daa86e218b1e605e0c0e430 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 1 May 2023 16:06:12 +0200 Subject: [PATCH 055/649] feat: SLA liquidity --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index eb72d15fa..bbdea249c 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -272,7 +272,7 @@ Now calculate $p_i^n$ to be the arithmetic average of $p_i^k$ for $k = 1,2,...,n Finally set $$ -p_i^n \leftarrow \max(p_i,p_i^n)\,. +p_i^n \leftarrow \max(p_i,p_i^n). $$ i.e. your penalty is the bigger of current epoch and average over the hysteresis period @@ -284,7 +284,7 @@ As defined above, for each LP for each epoch you have "penalty fraction" `p_i` w Calculate $$ -w_i = \frac{\text{LP-per-market fee account}\, i}{\sum_k \text{LP-per-market fee account}\, k}. +w_i = \frac{\text{LP-per-market fee account } i}{\sum_k \text{LP-per-market fee account } k}. $$ For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". From 103143c7ef2eb220537d9a2f9d526f4eeb5aedb2 Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Mon, 1 May 2023 19:16:44 +0200 Subject: [PATCH 056/649] Glassberg spec draft Signed-off-by: Barney Mannerings --- protocol/0014-ORDT-order_types.md | 111 ++++++++++++++++++++++++++++++ 1 file changed, 111 insertions(+) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 72d9568ca..c655f56b1 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -49,6 +49,117 @@ Notes on scope of current version of this spec: 1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees, and will not incur fees in general if executed in continuous trading. It is possible for some liquidity and infrastructure fees to be paid if the resultant limit order trades at the uncrossing of an auction, as specified in [0029-FEES](https://github.com/vegaprotocol/specs/blob/master/protocol/0029-FEES-fees.md#normal-auctions-including-market-protection-and-opening-auctions). 1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. + +### 'Glassberg' transparent iceberg orders + +On centralised exchanges, icebergs are a type of order that enables a trader to make an order with a relatively small visible "display quantiy" and a larger hidden total size. +Like an iceberg, most of the order is not visible to other traders. +After the full size of the visible portion of the order has traded away, the order is "refreshed" and reappears with its maximum display quantity. +This is repeated until the order is cancelled or expires, or its full volume trades away. +Some platforms also allow the display quantity to be randomised on each refresh to further frustrate traders trying to identify the existence of the iceberg ordeer). + +Vega, being a decentralised and fully transparent protocol, cannot (in its current form) achieve the hidden characteristic of iceberg orders. +But it can do the rest hence, _glassberg_ orders. +These are still helpful, especially for market makers and in combination with pegged orders, as they allow a trader to remain competitively present on the order book through the refresh facility without needing to supply excessive volume into a large aggressive order. + + +#### Definitions + +These terms are used to refer to fields on an order: + +* `quantity` - the full initial size of the order on entry. + +* `displayed quantity` - the current displayed quantity, i.e. the amount of the remaining quantity that is active on the book and can be hit. +Note that for a non-glassberg order, `displayed quantity == remaining`. + +* `remaining` - the total quantity of the order remaining that could trade. + + +#### Creating glassberg orders + +Glassberg orders are created by populating three additional fields on any valid persistent limit order: + +* `initial peak size` - this specifies the amount displayed and available on the order book for a new or newly refreshed glassberg order. + +* `minimum peak size` - this determines when a glassberg order is eligible for refresh. +The glassberg is refreshed any time the order's displayed quantity less than the minimum peak size. + +* `refresh policy` - this specifies when a glassberg order that is eligible for refresh and has remaining volume >0 is refreshed: + + * `IMMEDIATE` - the refresh occurs _after_ processing the transaction that depleted the display quantity to zero. + + * `BLOCK_END` - the rerresh occurs after processing the _entire block_ containing the transaction that depleted the display quantity to zero. + + +#### Validity + +* The order's non-glassberg-related fields must be set so as to make a valid order. + +* Any persistent TIF (GTC, GTT, GFA, GFN) can be a glassberg order. + +* A glassberg order may have either an ordinary or pegged limit price. +Market glassberg orders are not supported, even if with a persistent TIF. + +* Glassbergs may be post only. + +* `initial peak size` must be greater than TODO + +* `minimum peak size` must be `>` 0 and `≤ initial peak size` + + +#### Execution + +* Glassberg orders trade just like non-glassberg persistent order, as if the order entered the book with quantity = initial peak size on submission and again each time they are refreshed. +That is: + + * On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. + + * As for any other order, `remaning == quantity` on entry. + +* The maximum size for a trade involving a glassberg order is the `displayed quantity` immediataly prior to the trade. +(This is technically also true for a normal order, given that for non-glassberg orders `displayed quantity == remaining`.) + +* When a glassberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. + +* Glassberg orders can trade many times without refresh, reducing `displayed quantity` each time. +The order will not be refreshed after each trade while `displayed quantity ≥ minimum peak size`. + +* The order will also not be refreshed within a block even if multiple trades occur or `displayed quantity == 0` if the refresh policy is set to `BLOCK_END`. + +* Glassberg orders never trade more than their `displayed quantity` at the start of the transaction, as the result of any one transaction. + +* When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: + + * The refresh either happens at the end of the transaction when the order became eligible for refresh, if the `refresh policy == IMMEDIATE`; or at the end of the block containing that transaction if the `refresh policy == BLOCK_END` + + * On refresh `display quantity` is set to `min(remaining, initial peak size)`. + +* Once the remaning quantity is equal to the displayed quantity, no further refresh is possible. +The order now behaves like a normal limit order and will leave the book if it trades away completely. + + +#### Amendment + +* Amending the size of a glassberg order amends the total remaining quantity and leaves the displayed quantiy unaffected unless the new remaining quanity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. + + +#### Auctions + +* Glassbergs can be entered or carried into auctions if the underlying TIF is supported. + +* Glassbergs can trade in the auction uncrossing up to their current size as for any other transaxction that would cause a trade. + +* Glassbergs are refreshed after an auction uncrossing if they traded away, according to the same rules for the refresh policy as for normal execution. + + +#### APIs + +* The fields `displayed quantity`, `remaining`, `quantity`, `initial peak size`, `minimum peak size`, `refresh policy` must be exposed by data node APIs in addition to all normal fields for an order. + +* Glassberg refresh must generate an event bus event. + + + ### Valid order entry combinations #### Continuous trading From f608e5cab0fb89bca3a08b4b848baf75056faf89 Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Tue, 2 May 2023 10:25:51 +0200 Subject: [PATCH 057/649] Clarify glassberg price/time priority handling. Signed-off-by: Barney Mannerings --- protocol/0014-ORDT-order_types.md | 16 ++++++++++++++-- protocol/0025-OCRE-order_submission.md | 4 +++- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index c655f56b1..a53efecbf 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -107,7 +107,7 @@ Market glassberg orders are not supported, even if with a persistent TIF. * `minimum peak size` must be `>` 0 and `≤ initial peak size` -#### Execution +#### Execution and subsequent refresh * Glassberg orders trade just like non-glassberg persistent order, as if the order entered the book with quantity = initial peak size on submission and again each time they are refreshed. That is: @@ -134,13 +134,25 @@ The order will not be refreshed after each trade while `displayed quantity ≥ m * On refresh `display quantity` is set to `min(remaining, initial peak size)`. + * A refresh simulate a cancel/replace, which means that on refresh a glassberg order will always lose time priority relative to other orders at the same price. + + * If multiple glassberg orders need to be refresh at the same time: + + * `refresh policy == IMMEDIATE` glassbergs are _always_ refreshed before those with `refresh policy == BLOCK_END` + + * within the same `refresh policy`, glassbergs are refreshed in the order that their eligibility for refresh was triggered, so the glassberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). + * Once the remaning quantity is equal to the displayed quantity, no further refresh is possible. The order now behaves like a normal limit order and will leave the book if it trades away completely. #### Amendment -* Amending the size of a glassberg order amends the total remaining quantity and leaves the displayed quantiy unaffected unless the new remaining quanity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. +* Amending the size of a glassberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quanity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. + +* Amending the size/quantity of a glassberg order does not cause it to lose time priority. +This is because the increase applies to the `remaining` quantity and not to the `displayed quantity`. +This is allowed because the order will lose time priority on refresh, i.e. before the increased quantity is available to trade. #### Auctions diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index af6308731..251f7f27e 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -8,7 +8,9 @@ To allow traders to interact with the market, they must be able to enter an orde - Orders can be submitted into any market that is active - i.e not in [a protective auction](./0026-AUCT-auctions.md) or [matured/expired/settled](./0043-MKTL-market_lifecycle.md). - Orders will only be accepted if sufficient margin can be allocated (see : [Margin Orchestration](./0010-MARG-margin_orchestration.md) and [Margin Calculator](./0019-MCAL-margin_calculator.md)) -- Amendments that change price or increase size will be executed as an atomic cancel/replace (i.e. as if the original order was cancelled and removed from the book and a new order submitted with the modified values - that is, time priority is lost) +- Amendments that change price or increase available (displayed) quantity will be executed as an atomic cancel/replace (i.e. as if the original order was cancelled and removed from the book and a new order submitted with the modified values - that is, time priority is lost) +Note that this means that increasing the quantity of a glassberg (transparent iceberg) order can be done without losing time priority, as the current displayed size will not be changed. +The order will lose time priority on its next refresh in any case (i.e. before the increased size becomes 'displayed' and tradable). - Execution of an order during continuous trading will be stopped and the order cancelled and removed (if on the book) if it is about to match with another order on the book for the same party (that is, execution can proceed up to the point a "wash" trade would be generated but stopped before that and the order cancelled). Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an auction). - Orders may be fractional in size with the maximum number of decimal places allowable being the `Position Decimal Places` specified in the [Market Framework](./0001-MKTF-market_framework.md), and any order containing more precision that this being rejected. (NB: orders may end up being specified as integers similar to how prices are, in which case this does not apply and 1 == the smallest increment given the configured position d.p.s for the market). From 4183c65eebaf9bc49dbf9fcfbeb5a4a3812e6346 Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Tue, 2 May 2023 09:54:34 +0100 Subject: [PATCH 058/649] Update protocol/0014-ORDT-order_types.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index a53efecbf..f400719f4 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -52,7 +52,7 @@ Notes on scope of current version of this spec: ### 'Glassberg' transparent iceberg orders -On centralised exchanges, icebergs are a type of order that enables a trader to make an order with a relatively small visible "display quantiy" and a larger hidden total size. +On centralised exchanges, icebergs are a type of order that enables a trader to make an order with a relatively small visible "display quantity" and a larger hidden total size. Like an iceberg, most of the order is not visible to other traders. After the full size of the visible portion of the order has traded away, the order is "refreshed" and reappears with its maximum display quantity. This is repeated until the order is cancelled or expires, or its full volume trades away. From 09c5f3934186cd3262c8a8cba85351f683e9325a Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Tue, 2 May 2023 09:54:57 +0100 Subject: [PATCH 059/649] Update protocol/0035-LIQM-liquidity_monitoring.md Co-authored-by: Tom --- protocol/0035-LIQM-liquidity_monitoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index bce3bf5d2..c0afba377 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -11,7 +11,7 @@ Indeed `lp_liquidity_obligation_in_ccy_volume = market.liquidity.stakeToCcyVolume ⨉ stake`. -Thus it is sufficient to compare `target_stake`. +Thus it is sufficient to compare `target_stake` with `total_stake`. Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate spec. From c7001973774d0f31ffc641b2bbf4d86a9a426965 Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Tue, 2 May 2023 09:55:24 +0100 Subject: [PATCH 060/649] Update protocol/0014-ORDT-order_types.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index f400719f4..2ae3361a4 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -88,7 +88,7 @@ The glassberg is refreshed any time the order's displayed quantity less than the * `IMMEDIATE` - the refresh occurs _after_ processing the transaction that depleted the display quantity to zero. - * `BLOCK_END` - the rerresh occurs after processing the _entire block_ containing the transaction that depleted the display quantity to zero. + * `BLOCK_END` - the rerresh occurs after processing the _entire block_ containing the transaction that depleted the display quantity to less than minimum peak size. #### Validity From bfd2e9587e513227da26844b82d97d829f553b93 Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Tue, 2 May 2023 09:55:34 +0100 Subject: [PATCH 061/649] Update protocol/0014-ORDT-order_types.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 2ae3361a4..6199580f8 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -86,7 +86,7 @@ The glassberg is refreshed any time the order's displayed quantity less than the * `refresh policy` - this specifies when a glassberg order that is eligible for refresh and has remaining volume >0 is refreshed: - * `IMMEDIATE` - the refresh occurs _after_ processing the transaction that depleted the display quantity to zero. + * `IMMEDIATE` - the refresh occurs _after_ processing the transaction that depleted the display quantity to less than minimum peak size. * `BLOCK_END` - the rerresh occurs after processing the _entire block_ containing the transaction that depleted the display quantity to less than minimum peak size. From da8a42a40f29ad2b8f811c2089fa333b1bf3b505 Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Tue, 2 May 2023 09:55:59 +0100 Subject: [PATCH 062/649] Update protocol/0014-ORDT-order_types.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 6199580f8..eded19c85 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -102,7 +102,7 @@ Market glassberg orders are not supported, even if with a persistent TIF. * Glassbergs may be post only. -* `initial peak size` must be greater than TODO +* `initial peak size` must be greater than or equal to minimum position size (i.e. minimum order size). * `minimum peak size` must be `>` 0 and `≤ initial peak size` From 107819369eb346cd7e30d32765139f638723aedc Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Tue, 2 May 2023 11:06:41 +0200 Subject: [PATCH 063/649] Clarify ALL glassberg order refreshes occur before block-end luqiidity SLA evaluation. Signed-off-by: Barney Mannerings --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index bbdea249c..837ee81ef 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -227,6 +227,9 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP * At the end of each block: + * Note that this happens _after_ any glassberg order refreshes, including those with `refresh policy == BLOCK_END`. + This means that while a glassberg has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size` of liquidity. + * If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): * Store the current Vega time as the time the LP began meeting their commitment From 3a93011ff1abf720890722227dfdda30a2c3f724 Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Tue, 2 May 2023 10:10:48 +0100 Subject: [PATCH 064/649] Update protocol/0035-LIQM-liquidity_monitoring.md Co-authored-by: Witold --- protocol/0035-LIQM-liquidity_monitoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index c0afba377..cee0be77d 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -49,7 +49,7 @@ We exit if `total_stake >= target_stake`. -During the liquidity monitoring auction new or existing LPs can commit more stake (and hence liquidity) through the special market making order type and enable this by posting enough margin - see the [liquidity provision mechanics](./0044-LIME-lp_mechanics.md) spec for details. These need to be monitored to see if auction mode can be exitted. +During the liquidity monitoring auction new or existing LPs can commit more stake (and hence liquidity) through the special market making transaction and enable this by posting enough margin - see the [liquidity provision mechanics](./0044-LIME-lp_mechanics.md) spec for details. These need to be monitored to see if auction mode can be exited. ## What happens during the auction? From 6cace05161ae601c5037ebf7c62b3df7178bcc33 Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Tue, 2 May 2023 11:15:12 +0200 Subject: [PATCH 065/649] Fix typo Signed-off-by: Barney Mannerings --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index eded19c85..3a20021ff 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -134,7 +134,7 @@ The order will not be refreshed after each trade while `displayed quantity ≥ m * On refresh `display quantity` is set to `min(remaining, initial peak size)`. - * A refresh simulate a cancel/replace, which means that on refresh a glassberg order will always lose time priority relative to other orders at the same price. + * A refresh simulates a cancel/replace, which means that on refresh a glassberg order will always lose time priority relative to other orders at the same price. * If multiple glassberg orders need to be refresh at the same time: From b3d71cb2264704805a72cfa8fba4daeef2b6e64c Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Tue, 2 May 2023 13:15:13 +0200 Subject: [PATCH 066/649] Randomise SLA evaluation to prevent abuse Signed-off-by: Barney Mannerings --- ...0042-LIQF-setting_fees_and_rewarding_lps.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 837ee81ef..921556995 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -225,20 +225,26 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP * If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -* At the end of each block: +* At the start of each block generate a pseudorandom integer `k` between `1..N` (inclusive of `1` and `N`) where `N` is the number of transactions in the block (note: transactions not orders, a batch is one transaction for this purpose). +Use a suitable deterministic seed to minimise the probability of an LP gaming `k` or being able to target transactions around (directly before or after) the point `k`. +For example, the seed might combinee the hash of all transactions in the block itself with the number of transactions `N`. +Using only information from the prior block as the seed may allow exploits based on pre-generation of `k`. - * Note that this happens _after_ any glassberg order refreshes, including those with `refresh policy == BLOCK_END`. - This means that while a glassberg has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size` of liquidity. +* In each block, immediately after processing transaction `k`: + + * Note that this happens _before_ any glassberg order refreshes with `refresh policy == BLOCK_END`, even if `k == N`, and after glassbergs refreshed with `refresh policy == IMMEDIATELY` that need refreshing as a result of transaction `k`. + This means that while a glassberg has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `initial peak size` of liquidity if it's policy is `IMMEDIATELY`. + A `BLOCK_END` glassberg will **never** be refreshed within before the SLA achievement is evaluated for that block, and can therefore only be guaranteed to be contributing at least `minimum peak size` of liquidity, even when it has plenty of remaining volume. * If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): - * Store the current Vega time as the time the LP began meeting their commitment + * Store the current Vega time attached to the block being processed as the time the LP began meeting their commitment. * If LP has stopped meeting their committed volume of notional after previously doing so: - * Add the difference in nanoseconds between the current Vega time and the time the LP began meeting their commitment (stored in the step above) to `s_i` + * Add the difference in nanoseconds between the current Vega time attached to the block being processed and the time the LP began meeting their commitment (stored in the step above) to `s_i`. - * Store `nothing` as the time the LP began meeting their commitment, to signify the LP not meeting their commitment + * Store `nothing` as the time the LP began meeting their commitment, to signify the LP not meeting their commitment. * At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. From 7af60cf96a009e9aaf1af009a687a7d626936dc8 Mon Sep 17 00:00:00 2001 From: Barney Mannerings Date: Wed, 3 May 2023 09:49:14 +0200 Subject: [PATCH 067/649] Fixes during walkthrough with Charlie Signed-off-by: Barney Mannerings --- protocol/0014-ORDT-order_types.md | 33 +++++++------------ ...042-LIQF-setting_fees_and_rewarding_lps.md | 27 ++++++--------- protocol/0044-LIME-lp_mechanics.md | 33 ++++++++++++------- 3 files changed, 44 insertions(+), 49 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 3a20021ff..249442bbc 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -84,12 +84,6 @@ Glassberg orders are created by populating three additional fields on any valid * `minimum peak size` - this determines when a glassberg order is eligible for refresh. The glassberg is refreshed any time the order's displayed quantity less than the minimum peak size. -* `refresh policy` - this specifies when a glassberg order that is eligible for refresh and has remaining volume >0 is refreshed: - - * `IMMEDIATE` - the refresh occurs _after_ processing the transaction that depleted the display quantity to less than minimum peak size. - - * `BLOCK_END` - the rerresh occurs after processing the _entire block_ containing the transaction that depleted the display quantity to less than minimum peak size. - #### Validity @@ -109,14 +103,17 @@ Market glassberg orders are not supported, even if with a persistent TIF. #### Execution and subsequent refresh -* Glassberg orders trade just like non-glassberg persistent order, as if the order entered the book with quantity = initial peak size on submission and again each time they are refreshed. +* On entry, if a glassberg order is crossed with the best bid/ask, it trades first with its **full quantity**, i.e. the peak sizes do not come into play during aggressive execution. +This is to prevent a glassberg order ever being crossed after refreshing. + +* Once they enter the book passively, Glassberg orders trade just like non-glassberg persistent order, as if the order entered the book with `quantity = initial peak size` on submission, and again each time they are refreshed until `remanining == 0` (or they are cancelled or expired, etc.). That is: * On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. - * As for any other order, `remaning == quantity` on entry. + * As for any other order, `remaining == quantity` on entry. -* The maximum size for a trade involving a glassberg order is the `displayed quantity` immediataly prior to the trade. +* The maximum total size for all trades involving a glassberg order in any given transaction (including a batch) is the `displayed quantity` immediataly prior to the trade. (This is technically also true for a normal order, given that for non-glassberg orders `displayed quantity == remaining`.) * When a glassberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. @@ -124,25 +121,19 @@ That is: * Glassberg orders can trade many times without refresh, reducing `displayed quantity` each time. The order will not be refreshed after each trade while `displayed quantity ≥ minimum peak size`. -* The order will also not be refreshed within a block even if multiple trades occur or `displayed quantity == 0` if the refresh policy is set to `BLOCK_END`. - * Glassberg orders never trade more than their `displayed quantity` at the start of the transaction, as the result of any one transaction. * When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: - * The refresh either happens at the end of the transaction when the order became eligible for refresh, if the `refresh policy == IMMEDIATE`; or at the end of the block containing that transaction if the `refresh policy == BLOCK_END` - + * The refresh happens at the end of the transaction when the order becomes eligible for refresh. + * On refresh `display quantity` is set to `min(remaining, initial peak size)`. * A refresh simulates a cancel/replace, which means that on refresh a glassberg order will always lose time priority relative to other orders at the same price. - * If multiple glassberg orders need to be refresh at the same time: - - * `refresh policy == IMMEDIATE` glassbergs are _always_ refreshed before those with `refresh policy == BLOCK_END` - - * within the same `refresh policy`, glassbergs are refreshed in the order that their eligibility for refresh was triggered, so the glassberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). + * If multiple glassberg orders need to be refresh at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the glassberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). -* Once the remaning quantity is equal to the displayed quantity, no further refresh is possible. +* Once the remaining quantity is equal to the displayed quantity, no further refresh is possible. The order now behaves like a normal limit order and will leave the book if it trades away completely. @@ -159,9 +150,9 @@ This is allowed because the order will lose time priority on refresh, i.e. befor * Glassbergs can be entered or carried into auctions if the underlying TIF is supported. -* Glassbergs can trade in the auction uncrossing up to their current size as for any other transaxction that would cause a trade. +* Glassbergs can trade in the auction uncrossing up to their current `displayed quanitity` as for any other transaxction that would cause a trade with a glassberg order. -* Glassbergs are refreshed after an auction uncrossing if they traded away, according to the same rules for the refresh policy as for normal execution. +* Glassbergs are refreshed after an auction uncrossing if they traded to below their `minimum peak size`, according to the same rules as for normal execution. #### APIs diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 921556995..b56ff5b47 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -227,14 +227,13 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP * At the start of each block generate a pseudorandom integer `k` between `1..N` (inclusive of `1` and `N`) where `N` is the number of transactions in the block (note: transactions not orders, a batch is one transaction for this purpose). Use a suitable deterministic seed to minimise the probability of an LP gaming `k` or being able to target transactions around (directly before or after) the point `k`. -For example, the seed might combinee the hash of all transactions in the block itself with the number of transactions `N`. -Using only information from the prior block as the seed may allow exploits based on pre-generation of `k`. +For example, the seed might combine the hash of all transactions in the block itself with the number of transactions `N`. +Using only information from the prior block as the seed may allow exploits based on pre-generation of `k` and must be avoided. * In each block, immediately after processing transaction `k`: - * Note that this happens _before_ any glassberg order refreshes with `refresh policy == BLOCK_END`, even if `k == N`, and after glassbergs refreshed with `refresh policy == IMMEDIATELY` that need refreshing as a result of transaction `k`. - This means that while a glassberg has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `initial peak size` of liquidity if it's policy is `IMMEDIATELY`. - A `BLOCK_END` glassberg will **never** be refreshed within before the SLA achievement is evaluated for that block, and can therefore only be guaranteed to be contributing at least `minimum peak size` of liquidity, even when it has plenty of remaining volume. + * Note that this happens _after_ glassbergs, that need refreshing as a result of transaction `k` are refreshed. + This means that while a glassberg has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. * If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): @@ -248,14 +247,6 @@ Using only information from the prior block as the seed may allow exploits based * At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. -Note that we only need to evaluate each LP's status at the end of each block, as no _Vega time_ passes between transactions in a block. - -### Calculating SLA performance - -<<<<<<< HEAD -Flooring non-zero amounts due to integer representation can result in a remainder in the liquidity fee account. The remainder should be left in the market liquidity fee account and carried over to the next distribution window. - -If the fees are being distributed as a part of market settlement and distribution results in a remainder in the liquidity fee account. The remainder should be transferred to the network treasury for that asset. #### Calculating the SLA performance penalty for a single epoch @@ -286,9 +277,11 @@ $$ i.e. your penalty is the bigger of current epoch and average over the hysteresis period -### Applying LP SLA performance penalties to accrued fees +### Applying LP SLA performance penalties to accrued fees + +As defined above, for each LP for each epoch you have "penalty fraction" $p_i^n$ which is between `[0,1]` with `0` indicating LP has met committment 100% of the time and `1` indicating that LP was below `market.liquidity.committmentMinTimeFraction` of the time. -As defined above, for each LP for each epoch you have "penalty fraction" `p_i` which is between `[0,1]` with `0` indicating LP has met committment 100% of the time and `1` indicating that LP was below `market.liquidity.committmentMinTimeFraction` of the time. +If for all $i$ (all the LPs) have $p_i^n = 1$ then all the fees go into the market insurance pool and we stop. Calculate @@ -298,8 +291,8 @@ $$ For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -Tranfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. Record its balance to be `B`. - +Tranfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. +Record its balance to be $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. $$ diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index eeaeadac4..565b1d69e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -1,7 +1,7 @@ # Liquidity provision mechanics The point of liquidity provision on Vega is to incentivise people to place orders on the market that maintain liquidity on the book. -This is done via a financial commitment and reward + penalty mechanics, and through the use of a special batch order type that announces that a party is entering the liquidity provision (LP) service level agreement (SLA). +This is done via a financial commitment and reward + penalty mechanics, and through the LP commitment transaction that announces that a party is entering the liquidity provision (LP) service level agreement (SLA). Important note on wording: @@ -17,10 +17,10 @@ Important note on wording: Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.sla.nonPerformanceBondPenaltySlope` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` with a default value of `2.0`. - `market.liquidity.sla.nonPerformanceBondPenaltyMax` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` and `<=1.0` with a default value of `0.5`. -- `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of [lp order type](./0038-OLIQ-liquidity_provision_order_type.md). Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. +- `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of the LP commitment transaction. Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. - `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). -- `market.liquidity.earlyExitPenalty` (decimal between 0 and 1 inclusive), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited. +- `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. @@ -28,7 +28,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. This is set / can be modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal. -- `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. +- `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. - `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `12h` or `7d`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. @@ -49,7 +49,7 @@ At a high level, the liqudity mechanism in Vega allows Liquidity Providers (LPs) - Penalising LPs that commit and do not meet the SLA, to reduce the attractiveness of opportunistically going after rewards with no intention to meet the SLA in more challenging conditions, and of leeching style attacks on the rewards. -Once committed LPs attempt to meet their comitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and iceberg to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. +Once committed LPs attempt to meet their comitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and glassberg (transparent iceberg) to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. ## Commit liquidity network transaction @@ -76,6 +76,12 @@ There is an minimum LP stake which is `market.liquidityProvision.minLpStakeQuant If the participant has sufficient collateral to cover their commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are committing liquidity, created as needed). For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). +Entering commitment will happen(*) at the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated). It's the prospective LP's responsibility to have sufficient balance in their general account at the epoch boundary; if not the LP commitment is cancelled. + +(*) The expection is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. + +The fee for the market is only [updated at the epoch boundary using the "auction" mechanism set here](0042-LIQF-setting_fees_and_rewarding_lps.md). + Liquidity provider bond account: - Each active market has one bond account per liquidity provider, per settlement asset for that market. @@ -94,12 +100,14 @@ A participant may apply to amend their commitment amount by submitting a transac `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` +The amendment is actioned at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated). It's the amending LP's responsibility to have sufficient balance in their general account at the epoch boundary; if not the LP amendment is not actioned. + #### Increasing commitment _Case:_ `proposed-commitment-variation >= 0` -A liquidity provider can always increase their commitment amount as long as they have sufficient collateral in the settlement asset of the market to meet the new commitment amount and cover the margins required. +A liquidity provider can always increase their commitment amount as long as they have sufficient collateral in the settlement asset of the market to meet the new commitment amount. -If they do not have sufficient collateral the transaction is rejected in entirety. This means that any data from the fees or orders are not applied. This means that the `old-commitment-amount` is retained. +If they do not have sufficient collateral the transaction is rejected in entirety. This means that any change in fee bid is not applied and that the `old-commitment-amount` is retained. #### Decreasing commitment @@ -121,7 +129,7 @@ If `-proposed-commitment-variation > maximum-penalty-free-reduction-amount` then penalty-incuring-reduction-amount = -proposed-commitment-variation - maximum-penalty-free-reduction-amount ``` Transfer `maximum-penalty-free-reduction-amount` to their general account. -Now transfer `(1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount` to their general account and transfer `market.liquidity.earlyExitPenalty x penalty-incuring-reduction-amount` to the market insurance pool. +Now transfer `min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to their general account and transfer `market.liquidity.earlyExitPenalty x penalty-incuring-reduction-amount` to the market insurance pool. Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire `proposed-commitment-variation` as the `delta`. Note that as a consequence the market may land in a liquidity auction the next time the next time conditions for liquidity auctions are evaluated (but there is no need to tie the event of LP reducing their commitment to an immediate liquidity auction evaluation). @@ -186,7 +194,7 @@ Let $m$ be `nonPerformanceBondPenaltyMax`. Let $$ -f = \min\left(m,p - \frac{p}{s}t\right)\,. +f = \max\left[0,\min\left(m,p - \frac{p}{s}t\right)\right]\,. $$ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. @@ -226,17 +234,20 @@ Note: In the same way that a collateral search is initiated to attempt to top-up a trader's margin account if it drops below the _collateral search level_, the system must also attempt to top up the bond account if its balance drops below the size of the LP's commitment. -This should happen every time the network is performing a margin calculation and search. The system should prioritise topping up the margin account first, and then the bond account, if there are insufficient funds to do both. +This should happen every time the network is performing a margin calculation and search. The system should prioritise topping up the margin account first, and then the bond account, if there are insufficient funds to do both. + +If, at the end of an epoch (and before any LP rewards and penalties were applied), the LPs bond account isn't topped up to the level of their commitment then, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). + ## What data do we keep relating to liquidity provision? 1. List of all liquidity providers and their commitment sizes and their “equity-like share” for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) -1. Liquidity provision orders (probably need to be indexed somewhere in addition to the order book) 1. New account per market holding all committed liquidity provider bonds 1. Actual amount of liquidity supplied (can be calculated from order book, [see 0034-prob-weighted-liquidity-measure](./0034-PROB-prob_weighted_liquidity_measure.ipynb)) 1. Each liquidity provider's actual bond amount (i.e. the balance of their bond account) + ## APIs - Transfers to and from the bond account, new or changed commitments, and any penalties applied should all be published on the event stream From 50d45c45e15c812dc803823572ef5cd1d7d356dd Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 11 May 2023 13:14:02 +0100 Subject: [PATCH 068/649] Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 565b1d69e..bda6f4303 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -17,7 +17,7 @@ Important note on wording: Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.sla.nonPerformanceBondPenaltySlope` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` with a default value of `2.0`. - `market.liquidity.sla.nonPerformanceBondPenaltyMax` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` and `<=1.0` with a default value of `0.5`. -- `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of the LP commitment transaction. Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>0` and `<=1`. Default value `1`. +- `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of the LP commitment transaction. Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>=0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. - `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. From 5715f36452c04968406b815e729ce02a3f1696f0 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 11 May 2023 13:30:35 +0100 Subject: [PATCH 069/649] Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index bda6f4303..2e022d30d 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -30,7 +30,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. -- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `12h` or `7d`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. +- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. - `market.liqudity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. From ac3d6c96b1de95c65fbc77d09063669371305045 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 15 May 2023 16:36:26 +0100 Subject: [PATCH 070/649] Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 2e022d30d..8be22be01 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -100,7 +100,9 @@ A participant may apply to amend their commitment amount by submitting a transac `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` -The amendment is actioned at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated). It's the amending LP's responsibility to have sufficient balance in their general account at the epoch boundary; if not the LP amendment is not actioned. +The amendment is actioned in two steps. +1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. +2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. ``` #### Increasing commitment From 3533c2dd8fb08c7b61af35e6af4504636c77bc12 Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 17 May 2023 11:05:51 +0100 Subject: [PATCH 071/649] feat: Adding ACs to SLA specs (#1697) * feat: Adding ACs to SLA specs * feat: Add more ACs * feat: Add more ACs * feat: Add more ACs --- protocol/0026-AUCT-auctions.md | 16 +++--- ...042-LIQF-setting_fees_and_rewarding_lps.md | 53 +++++++++++++++---- protocol/0044-LIME-lp_mechanics.md | 49 +++++++++++++---- 3 files changed, 90 insertions(+), 28 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 4db5087ed..762b1d5b4 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -168,13 +168,13 @@ message Market { - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book, [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask so that [liquidity can be deployed](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-009) - 1. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed and we have limit orders such that after the auction uncrossing we will have best bid and best ask so that [liquidity can be deployed](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-010) - 1. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) and after the auction uncrossing we will have best bid and best ask but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - - more liquidity is committed (0026-AUCT-011) - - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-012) - 1. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have - - best bid; it will only end once an LO providing best bid is supplied. (0026-AUCT-013) - - or best ask; it will only end once an LO providing best bid is supplied. (0026-AUCT-014) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) + 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) + 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if + - more liquidity is committed (0026-AUCT-019) + - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) + 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have + - best bid; it will still open. (0026-AUCT-021) + - or best ask; it will still open. (0026-AUCT-022) - When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015) - When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index b56ff5b47..29db647dd 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -176,7 +176,7 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s (average entry valuation) = 1090.9 ``` -### Calculating the instantenaous liquidity score +### Calculating the instantaneous liquidity score At every vega time change calculate the liquidity score for each committed LP. This is done by taking into account all orders they have deployed within the `[min_lp_price,max_lp_price]` [range](./0044-LIME-lp_mechanics.md) and then calculating the volume-weighted [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) at each price level - call it instantaneous liquidity score. @@ -258,11 +258,18 @@ fraction_of_time_on_book = s_i / observed_epoch_length For any LP where `fraction_of_time_on_book < market.liquidity.commitmentMinTimeFraction` the SLA penalty fraction `p_i = 1` (that is, the penalty is 100% of their fees). -For each LP where `fraction_of_time_on_book ≥ market.liquidity.commitmentMinTimeFraction`, the SLA penalty fraction `p_i` is calculated as follow: +For each LP where `fraction_of_time_on_book ≥ market.liquidity.commitmentMinTimeFraction`, the SLA penalty fraction `p_i` is calculated as follows: -```python -p_i = (1.0 - (fraction_of_time_on_book - market.liquidity.committmentMinTimeFraction) / (1.0 - market.liquidity.committmentMinTimeFraction)) * market.liqudity.slaCompetitionFactor -``` + +Let $t$ be `fraction_of_time_on_book` + +Let $s$ be `market.liquidity.committmentMinTimeFraction`. + +Let $c$ be `market.liquidity.slaCompetitionFactor`. + +$$ +p_i = (1 - \frac{t - s}{1 - s}) \cdot c. +$$ #### Calculating the SLA performance penalty for over hysteresis period @@ -291,7 +298,7 @@ $$ For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -Tranfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. +Transfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. Record its balance to be $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. @@ -301,7 +308,7 @@ $$ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". -Note that after this process completes the balance of the temporary (one per market) bonus distribution account decscribed above **must be zero** and the account may be destroyed (and recreated again when needed). +Note that after this process completes the balance of the temporary (one per market) bonus distribution account described above **must be zero** and the account may be destroyed (and recreated again when needed). There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's tranfer this to a fixed example. @@ -334,7 +341,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - The examples provided result in the given outcomes. (0042-LIQF-008) - The total amount of liquidity fee distributed is equal to the most recent `liquidity-fee-factor` x `notional-value-of-all-trades` (0042-LIQF-011) -- Liquidity providers with a commitment of 0 will not receive a share ot the fees (0042-LIQF-012) +- Liquidity providers with a commitment of 0 will not receive a share of the fees (0042-LIQF-012) - If a market has `market.liquidity.providers.fee.calculationTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) - After fee distribution, if there is a remainder in the liquidity fee account and the market is not being settled, it should be left in the liquidity fee account and carried over to the next distribution window. (0042-LIQF-032) @@ -363,7 +370,31 @@ There is an example [google sheet for this step](https://docs.google.com/spreads ### successor market -- [ ] If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) -- [ ] If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-032) -- [ ] If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-032) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) - If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) + +### Calculating SLA Performance +- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 1`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.5`. This will be true whether: + - Their liquidity is all provided at the start of the epoch and then none is provided for the second half (0042-LIQF-037) + - Their liquidity is provided scattered throughout the epoch (0042-LIQF-038) + +- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0`. (0042-LIQF-041) +- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0.5`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.25`. (0042-LIQF-042) + +- When `market.liquidity.performanceHysteresisEpochs = 0`: + - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) + - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch(0042-LIQF-036) +- When `market.liquidity.performanceHysteresisEpochs = n`: + - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) + - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) + - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they never meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 0` for the latest epoch a penalty rate of `1` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-040) + + +### SLA Performance bonus transfers + +- The balance of the per-market liquidity fee bonus distribution account should always be zero after bonus distribution is completed (0042-LIQF-041) +- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-042) +- With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-043) +- With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-044) \ No newline at end of file diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 8be22be01..cded4e047 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -104,6 +104,8 @@ The amendment is actioned in two steps. 1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. 2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. ``` +Commitment amendmends should be processed in the time order of their latest updates within the epoch. For example if an LP places an amendment at time `t1`, followed by LP2 placing an amendment at `t2` and the first LP amending again at `t1`, LP2's amendment will be executed first. + #### Increasing commitment _Case:_ `proposed-commitment-variation >= 0` @@ -124,11 +126,11 @@ where: - `total_stake` is the sum of all stake of all liquidity providers bonded to this market. - `target_stake` is a measure of the market's current stake requirements, as per the calculation in the [target stake](./0041-TSTK-target_stake.md). -If `-proposed-commitment-variation <= maximum-penalty-free-reduction-amount` then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). +If `-1 * proposed-commitment-variation <= maximum-penalty-free-reduction-amount` then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). -If `-proposed-commitment-variation > maximum-penalty-free-reduction-amount` then first establish +If `-1 * proposed-commitment-variation > maximum-penalty-free-reduction-amount` then first establish ``` -penalty-incuring-reduction-amount = -proposed-commitment-variation - maximum-penalty-free-reduction-amount +penalty-incuring-reduction-amount = -1 * proposed-commitment-variation - maximum-penalty-free-reduction-amount ``` Transfer `maximum-penalty-free-reduction-amount` to their general account. Now transfer `min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to their general account and transfer `market.liquidity.earlyExitPenalty x penalty-incuring-reduction-amount` to the market insurance pool. @@ -156,7 +158,7 @@ When calculating fees for a trade, the size of a liquidity provider’s commitme ### Calculating liquidity from commitment -Committed Liqudity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below. +Committed Liquidity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below. The multiple is controlled by a network parameter `market.liquidity.stakeToCcyVolume`: ``` @@ -188,15 +190,21 @@ Note: we don't evaluate whether LPs meet the SLA during opening auctions so ther See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. This is available at the end of each epoch. -If, at, the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. +If, at the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. Otherwise we calculate a penalty to be applied to the bond as follows. -Let $t$ be `fraction_of_time_on_book` and let $s$ be `market.liquidity.committmentMinTimeFraction`. + +Let $t$ be `fraction_of_time_on_book` + +Let $s$ be `market.liquidity.committmentMinTimeFraction`. + Let $p$ be `market.liquidity.sla.nonPerformanceBondPenaltySlope`. -Let $m$ be `nonPerformanceBondPenaltyMax`. + +Let $m$ be `market.liquidity.sla.nonPerformanceBondPenaltyMax`. + Let $$ -f = \max\left[0,\min\left(m,p - \frac{p}{s}t\right)\right]\,. +f = \max\left[0,\min\left(m, p \cdot (1 - \frac{t}{s})\right)\right]\,. $$ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. @@ -230,7 +238,7 @@ The network will: Note: - As mentioned above, closeout should happen as per regular trader account (with the addition of cancelling the liquidity provision and the associated LP rewards & fees consequences). So, if after cancelling all open orders the party can afford to keep the open positions sufficiently collateralised they should be left open, otherwise the positions should get liquidated. -- Bond account balance should never get directly confiscated. It should only be used to cover margin shortfalls with appropriate penalty applied each time it's done. Once the funds are in margin account they should be treated as per normal rules involving that account. + ### Bond account top up by collateral search @@ -265,3 +273,26 @@ If, at the end of an epoch (and before any LP rewards and penalties were applied - Change of `market.liquidity.stakeToCcyVolume` will change the liquidity obligation hence change the size of the LP orders on the order book. (0044-LIME-010) - If `market.liquidity.stakeToCcyVolume` is set to `0.0` then the [LP provision order](./0038-OLIQ-liquidity_provision_order_type.md) places `0` volume on the book for the LP regardless of the shape submitted and regardless of the `stake` committed. (0044-LIME-011) - If `market.liquidity.stakeToCcyVolume` is set to `0.0`, there is [target stake](./0041-TSTK-target_stake.md) of `1000` and there are 3 LPs on the market with stake / fee bid submissions of `100, 0.01`, `1000, 0.02` and `200, 0.03` then the liquidity fee is `0.02`. (0044-LIME-012) + +- If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.committmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) +- If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) +- If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) + +- If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. (0044-LIME-018) +- If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) +- If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the bond stake has been slashed to a level lower than the amendment, this slashed level will be retained (i.e. the protocol will not attempt to now increase the commitment) (0044-LIME-020) +- If a liquidity provider with an active liquidity provision at the start of an epoch amends the fee level associated to this commitment during the epoch, this change will only take effect at the end of the epoch. (0044-LIME-021) + +- A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-023) + +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) +- +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: + - `LP1` places a transaction to reduce their stake by `30` + - `LP2` places a transaction to reduce their stake by `100`, + - `LP1` places a transaction to update their reduction to `100` + `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-025) + From d3786279aed5609c9eb2eb1bab7812b3ad528135 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Thu, 18 May 2023 18:07:39 +0100 Subject: [PATCH 072/649] replace glass with ice --- protocol/0014-ORDT-order_types.md | 72 ++++++++++++++++--------------- 1 file changed, 38 insertions(+), 34 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 249442bbc..c41a7bca4 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -46,21 +46,25 @@ Notes on scope of current version of this spec: ### Execution flags -1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees, and will not incur fees in general if executed in continuous trading. It is possible for some liquidity and infrastructure fees to be paid if the resultant limit order trades at the uncrossing of an auction, as specified in [0029-FEES](https://github.com/vegaprotocol/specs/blob/master/protocol/0029-FEES-fees.md#normal-auctions-including-market-protection-and-opening-auctions). +1. **Post-Only (True/False):** Only valid for Limit orders. Cannot be True at the same time as Reduce-Only. If set to true, once an order reaches the orderbook, this order acts identically to a limit order set at the same price. However, prior to being placed a check is run to ensure that the order will not (neither totally nor in any part) immediately cross with anything already on the book. If the order would immediately trade, it is instead immediately `Stopped` with a reason informing the trader that the order was stopped to avoid a trade occurring. As a result, placing a Post-Only order will never incur taker fees, and will not incur fees in general if executed in continuous trading. It is possible for some liquidity and infrastructure fees to be paid if the resultant limit order trades at the uncrossing of an auction, as specified in [0029-FEES](https://github.com/vegaprotocol/specs/blob/master/protocol/0029-FEES-fees.md#normal-auctions-including-market-protection-and-opening-auctions). 1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. -### 'Glassberg' transparent iceberg orders +### Iceberg / transparent iceberg orders On centralised exchanges, icebergs are a type of order that enables a trader to make an order with a relatively small visible "display quantity" and a larger hidden total size. + Like an iceberg, most of the order is not visible to other traders. + After the full size of the visible portion of the order has traded away, the order is "refreshed" and reappears with its maximum display quantity. + This is repeated until the order is cancelled or expires, or its full volume trades away. -Some platforms also allow the display quantity to be randomised on each refresh to further frustrate traders trying to identify the existence of the iceberg ordeer). -Vega, being a decentralised and fully transparent protocol, cannot (in its current form) achieve the hidden characteristic of iceberg orders. -But it can do the rest hence, _glassberg_ orders. -These are still helpful, especially for market makers and in combination with pegged orders, as they allow a trader to remain competitively present on the order book through the refresh facility without needing to supply excessive volume into a large aggressive order. +Some platforms also allow the display quantity to be randomised on each refresh to further frustrate traders trying to identify the existence of the iceberg order). + +Vega, being a decentralised and fully transparent protocol, cannot (in its current form) achieve the hidden characteristic of iceberg orders. But it can do the rest. + +Iceberg orders (or in other words, transparent iceberg orders) are still helpful, especially for market makers and in combination with pegged orders, as they allow a trader to remain competitively present on the order book through the refresh facility without needing to supply excessive volume into a large aggressive order. #### Definitions @@ -70,31 +74,31 @@ These terms are used to refer to fields on an order: * `quantity` - the full initial size of the order on entry. * `displayed quantity` - the current displayed quantity, i.e. the amount of the remaining quantity that is active on the book and can be hit. -Note that for a non-glassberg order, `displayed quantity == remaining`. +Note that for a non-iceberg order, `displayed quantity == remaining`. * `remaining` - the total quantity of the order remaining that could trade. -#### Creating glassberg orders +#### Creating iceberg orders -Glassberg orders are created by populating three additional fields on any valid persistent limit order: +Iceberg orders are created by populating three additional fields on any valid persistent limit order: -* `initial peak size` - this specifies the amount displayed and available on the order book for a new or newly refreshed glassberg order. +* `initial peak size` - this specifies the amount displayed and available on the order book for a new or newly refreshed iceberg order. -* `minimum peak size` - this determines when a glassberg order is eligible for refresh. -The glassberg is refreshed any time the order's displayed quantity less than the minimum peak size. +* `minimum peak size` - this determines when an iceberg order is eligible for refresh. +The iceberg is refreshed any time the order's displayed quantity is less than the minimum peak size. #### Validity -* The order's non-glassberg-related fields must be set so as to make a valid order. +* The order's non-iceberg-related fields must be set so as to make a valid order. -* Any persistent TIF (GTC, GTT, GFA, GFN) can be a glassberg order. +* Any persistent TIF (GTC, GTT, GFA, GFN) can be an iceberg order. -* A glassberg order may have either an ordinary or pegged limit price. -Market glassberg orders are not supported, even if with a persistent TIF. +* An iceberg order may have either an ordinary or pegged limit price. +Market iceberg orders are not supported, even if with a persistent TIF. -* Glassbergs may be post only. +* Icebergs may be post only. * `initial peak size` must be greater than or equal to minimum position size (i.e. minimum order size). @@ -103,25 +107,25 @@ Market glassberg orders are not supported, even if with a persistent TIF. #### Execution and subsequent refresh -* On entry, if a glassberg order is crossed with the best bid/ask, it trades first with its **full quantity**, i.e. the peak sizes do not come into play during aggressive execution. -This is to prevent a glassberg order ever being crossed after refreshing. +* On entry, if an iceberg order is crossed with the best bid/ask, it trades first with its **full quantity**, i.e. the peak sizes do not come into play during aggressive execution. +This is to prevent an iceberg order ever being crossed after refreshing. -* Once they enter the book passively, Glassberg orders trade just like non-glassberg persistent order, as if the order entered the book with `quantity = initial peak size` on submission, and again each time they are refreshed until `remanining == 0` (or they are cancelled or expired, etc.). +* Once they enter the book passively, iceberg orders trade just like non-iceberg persistent order, as if the order entered the book with `quantity = initial peak size` on submission, and again each time they are refreshed until `remaining == 0` (or they are cancelled or expired, etc.). That is: * On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. * As for any other order, `remaining == quantity` on entry. -* The maximum total size for all trades involving a glassberg order in any given transaction (including a batch) is the `displayed quantity` immediataly prior to the trade. -(This is technically also true for a normal order, given that for non-glassberg orders `displayed quantity == remaining`.) +* The maximum total size for all trades involving an iceberg order in any given transaction (including a batch) is the `displayed quantity` immediately prior to the trade. +(This is technically also true for a normal order, given that for non-iceberg orders `displayed quantity == remaining`.) -* When a glassberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. +* When an iceberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. -* Glassberg orders can trade many times without refresh, reducing `displayed quantity` each time. +* Iceberg orders can trade many times without refresh, reducing `displayed quantity` each time. The order will not be refreshed after each trade while `displayed quantity ≥ minimum peak size`. -* Glassberg orders never trade more than their `displayed quantity` at the start of the transaction, as the result of any one transaction. +* Iceberg orders never trade more than their `displayed quantity` at the start of the transaction, as the result of any one transaction. * When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: @@ -129,9 +133,9 @@ The order will not be refreshed after each trade while `displayed quantity ≥ m * On refresh `display quantity` is set to `min(remaining, initial peak size)`. - * A refresh simulates a cancel/replace, which means that on refresh a glassberg order will always lose time priority relative to other orders at the same price. + * A refresh simulates a cancel/replace, which means that on refresh an iceberg order will always lose time priority relative to other orders at the same price. - * If multiple glassberg orders need to be refresh at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the glassberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). + * If multiple iceberg orders need to be refreshed at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the iceberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). * Once the remaining quantity is equal to the displayed quantity, no further refresh is possible. The order now behaves like a normal limit order and will leave the book if it trades away completely. @@ -139,27 +143,27 @@ The order now behaves like a normal limit order and will leave the book if it tr #### Amendment -* Amending the size of a glassberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quanity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. +* Amending the size of an iceberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quanity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. -* Amending the size/quantity of a glassberg order does not cause it to lose time priority. +* Amending the size/quantity of an iceberg order does not cause it to lose time priority. This is because the increase applies to the `remaining` quantity and not to the `displayed quantity`. This is allowed because the order will lose time priority on refresh, i.e. before the increased quantity is available to trade. #### Auctions -* Glassbergs can be entered or carried into auctions if the underlying TIF is supported. +* Icebergs can be entered or carried into auctions if the underlying TIF is supported. -* Glassbergs can trade in the auction uncrossing up to their current `displayed quanitity` as for any other transaxction that would cause a trade with a glassberg order. +* Icebergs can trade in the auction uncrossing up to their current `displayed quantity` as for any other transaction that would cause a trade with an iceberg order. -* Glassbergs are refreshed after an auction uncrossing if they traded to below their `minimum peak size`, according to the same rules as for normal execution. +* Icebergs are refreshed after an auction uncrossing if they traded to below their `minimum peak size`, according to the same rules as for normal execution. #### APIs * The fields `displayed quantity`, `remaining`, `quantity`, `initial peak size`, `minimum peak size`, `refresh policy` must be exposed by data node APIs in addition to all normal fields for an order. -* Glassberg refresh must generate an event bus event. +* An iceberg order refresh must generate an event bus event. @@ -200,7 +204,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) - - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporate its volume and/or price level. (0014-ORDT-004) + - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) - No party can submit a [network order type](#network-orders) (0014-ORDT-006) From 277e7e537d884507480457af9950f94dd87058b5 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Thu, 18 May 2023 18:09:07 +0100 Subject: [PATCH 073/649] replace glass with ice --- protocol/0025-OCRE-order_submission.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index 251f7f27e..267702b2e 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -9,7 +9,7 @@ To allow traders to interact with the market, they must be able to enter an orde - Orders can be submitted into any market that is active - i.e not in [a protective auction](./0026-AUCT-auctions.md) or [matured/expired/settled](./0043-MKTL-market_lifecycle.md). - Orders will only be accepted if sufficient margin can be allocated (see : [Margin Orchestration](./0010-MARG-margin_orchestration.md) and [Margin Calculator](./0019-MCAL-margin_calculator.md)) - Amendments that change price or increase available (displayed) quantity will be executed as an atomic cancel/replace (i.e. as if the original order was cancelled and removed from the book and a new order submitted with the modified values - that is, time priority is lost) -Note that this means that increasing the quantity of a glassberg (transparent iceberg) order can be done without losing time priority, as the current displayed size will not be changed. +Note that this means that increasing the quantity of an iceberg (transparent iceberg) order can be done without losing time priority, as the current displayed size will not be changed. The order will lose time priority on its next refresh in any case (i.e. before the increased size becomes 'displayed' and tradable). - Execution of an order during continuous trading will be stopped and the order cancelled and removed (if on the book) if it is about to match with another order on the book for the same party (that is, execution can proceed up to the point a "wash" trade would be generated but stopped before that and the order cancelled). Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an auction). @@ -38,7 +38,7 @@ Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an ## Acceptance Criteria - An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001) -- Margin will taken before the order is entered in to the book (0025-OCRE-002) +- Margin will taken before the order is entered into the book (0025-OCRE-002) - If sufficient margin cannot be reserved, the order will have a status of `REJECTED` (0025-OCRE-003) - Fees are charged as per [0029-FEES](./0029-FEES-fees.md). From cfb17cfe576926324dd620ff2dc536ba02e82c25 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Thu, 18 May 2023 18:17:09 +0100 Subject: [PATCH 074/649] replace glass with ice --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index cded4e047..f26e4569c 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -49,7 +49,7 @@ At a high level, the liqudity mechanism in Vega allows Liquidity Providers (LPs) - Penalising LPs that commit and do not meet the SLA, to reduce the attractiveness of opportunistically going after rewards with no intention to meet the SLA in more challenging conditions, and of leeching style attacks on the rewards. -Once committed LPs attempt to meet their comitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and glassberg (transparent iceberg) to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. +Once committed LPs attempt to meet their comitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and iceberg (or more accurately, transparent iceberg) to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. ## Commit liquidity network transaction From 68f9b74ad31b6cbca10806b552d77517986441dd Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Thu, 18 May 2023 18:18:23 +0100 Subject: [PATCH 075/649] replace glass with ice --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 29db647dd..90c5be0ce 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -232,8 +232,8 @@ Using only information from the prior block as the seed may allow exploits based * In each block, immediately after processing transaction `k`: - * Note that this happens _after_ glassbergs, that need refreshing as a result of transaction `k` are refreshed. - This means that while a glassberg has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. + * Note that this happens _after_ iceberg orders, that need refreshing as a result of transaction `k` are refreshed. + This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. * If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): @@ -397,4 +397,4 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - The balance of the per-market liquidity fee bonus distribution account should always be zero after bonus distribution is completed (0042-LIQF-041) - With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-042) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-043) -- With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-044) \ No newline at end of file +- With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-044) From 23692aad76355243d90f67f4718a73b1cfac7d8c Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 10 May 2023 10:11:51 +0100 Subject: [PATCH 076/649] feat: updates for SLA changes --- protocol/0080-SPOT-product_builtin_spot.md | 53 ++++------------------ 1 file changed, 8 insertions(+), 45 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 10becce76..19ecaca01 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -32,7 +32,9 @@ When trading Spot products, parties can only use assets they own - there is no l ### Submissions -A liquidity provision submitted to a `Spot` market allows a separate commitment amount to be specified for the buy and sell sides of the market. These commitment amounts are specified in the `quote_asset` and `base_asset` respectively. +Liquidity commitments to a Spot market are made as detailed in [0044-LIME](./0044-LIME-lp_mechanics.md). + +A liquidity provision submitted to a `Spot` market specifies a single commitment amount in the `quote` asset. ```psuedo Example `LiquidityProvisionSubmission` command to an ETH/DAI market: @@ -42,7 +44,7 @@ submission = { { marketId: "abcdefghiklkmnopqrstuvwxyz", fee: "0.01", - buyCommitmentAmount: 15000 + commitmentAmount: 15000 (DAI) buys: [ { offset: "1" @@ -50,7 +52,6 @@ submission = { reference: "PEGGED_REFERENCE_BEST_BID" } ] - sellCommitmentAmount: 10 sells: [ { offset: "1" @@ -63,61 +64,23 @@ submission = { } ``` -As the LP now has a different commitment amount on each side of the book, the following considerations must be made: - -- Physical Stake: - - An LPs `physical_stake` should be treated separately for each side of the book - call these the `buy_physical_stake` and the `sell_physical_stake`. - - The current `physical_stake` for market stake calculations is the smaller of the two values, where the `sell_physical_stake` is converted into the `quote_asset` at the current `mark_price`. -- Virtual Stake: - - An LPs `virtual_stake` should be treated separately for each side of the book - call these the `buy_virtual_stake` and `sell_virtual_stake`. - - The same growth factor - as specified in the [LIQF spec](0042-LIQF-setting_fees_and_rewarding_lps.md) - derived from the `total value for fee purposes` in the quote asset is used to update both buy/sell virtual stakes (still in their respective assets). - - The current `virtual_stake` for fee splitting is the smaller of the two values where the `sell_virtual_stake` is converted to `quote_asset` at the current `mark_price`. - -From the above conditions, an LP is incentivised to provide a roughly equal value of liquidity on each side of the book at comparable levels of competitiveness in order to maximise their share of the liquidity fees. +To receive rewards for this commitment, An LP is then obligated to provide orders with a total value equalling their commitment amount on both the `buy` and `sell` sides of the market. As orders on a Spot market have their price expressed in the `quote` asset and their size expressed in the `base` asset, a trades value will be expressed in the `quote` asset. ### Amendments and Cancellations A liquidity amendment or a cancellation is determined as valid following spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: -- the `maximum_reduction_amount` should be expressed in the `quote_asset` when reducing the `buy_commitment_amount` and the `base_asset` when reducing the `sell_commitment_amount`. -- the `maximum_reduction_amount` should be `INF` in the case where the liquidity `time_window=Os` (Note: this is not strictly necessary but an LP is effectively able to reduce their commitment to zero anyway in this case through multiple commitments.) - -```pseudo -Market Data: +- the `maximum_reduction_amount` should be `INF` in the case where the liquidity `time_window=Os` (Note: this is not strictly necessary but an LP is effectively able to reduce their commitment to zero anyway in this case through multiple commitment amendments) - base_asset: ETH - quote_asset: DAI - - mark_price = 1000 - -Market Liquidity: - - total_stake = 100,000 DAI (or 100 ETH) - target_stake = 25,000 DAI (or 25 ETH) - - maximum_reduction_amount = 1000,000 - 25,0000 = 75,000 DAI (or 75 ETH) -``` - -`virtual_stake` values should be updated during liquidity amendments or cancellations following the mechanisms detailed in spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: - -- reducing the `buy_commitment_amount` only reduces the `buy_virtual_stake` -- reducing the `sell_commitment_amount` only reduces the `sell_virtual_stake` - -A single LP will never be able to reduce their commitment to `0`. They can either keep reducing to a sufficiently small amount they're willing to ignore, or they can submit a governance vote to cancel the market, see the [governance spec](./0028-GOVE-governance.md). +As the target stake (and therefore `maximum_reduction_amount`) is some factor of the total stake (see [Target Stake](./0080-SPOT-product_builtin_spot.md#market-target-stake)), a single LP will never be able to reduce their commitment to `0` if they are the only LP in a market. They can either keep reducing to a sufficiently small amount they're willing to ignore, or they can submit a governance vote to cancel the market, see the [governance spec](./0028-GOVE-governance.md). For market cancellation proposal a sole LP in the market holds all the voting power (unless governance token holders override them). -### Liquidity Shortfalls - -If at any point in time, a liquidity provider has insufficient capital in their general accounts to cover a transfer arising from a filled liquidity order, the network will utilise the liquidity commitment, held in the relevant bond account to cover the shortfall, applying the bond penalty factor (slashing the bond). - -As there is no market insurance pool, funds from bond slashing in the result of shortfall will be transferred to the global network treasury for that asset. - ## 6. Spot Liquidity Mechanisms ### Market Total Stake -The `total_stake` for a `Spot` market is calculated simply as the sum of each LPs `physical_stake` and should be expressed in the `quote_asset` of the market. +The `total_stake` for a `Spot` market is calculated simply as the sum of each LPs `physical_stake` and therefore should be expressed in the `quote_asset` of the market. ### Market Target Stake From 2e5235b5e12ae39ece724012ace3334f45cc7f89 Mon Sep 17 00:00:00 2001 From: ze97286 Date: Thu, 25 May 2023 22:48:13 +0100 Subject: [PATCH 077/649] chore: update spec for governance transfers to include more details about recurring transfers anc cancellation --- protocol/0028-GOVE-governance.md | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 8c1f37a00..a4854b8e2 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -289,18 +289,14 @@ The below table shows the allowable combinations of source and destination accou | Source type | Destination type | Governance transfer permitted | | --- | --- | --- | | Party account (any type) | Any | No | -| Network treasury | Reward pool account | Yes | +| Network treasury | Network treasury | Yes | | Network treasury | Party general account(s) | Yes | | Network treasury | Party other account types | No | -| Network treasury | Network insurance pool account | Yes | | Network treasury | Market insurance pool account | Yes | | Network treasury | Any other account | No | -| Network insurance pool account | Network treasury | Yes | -| Network insurance pool account | Market insurance pool account | Yes | -| Network insurance pool account | Any other account | No | | Market insurance pool account | Party account(s) | Yes | | Market insurance pool account | Network treasury | Yes | -| Market insurance pool account | Network insurance pool account | Yes | +| Market insurance pool account | Market insurance pool account | Yes | | Market insurance pool account | Any other account | No | | Any other account | Any | No | @@ -308,7 +304,7 @@ The below table shows the allowable combinations of source and destination accou The proposal specifies: -- `source_type`: the source account type (i.e. network treasury, network insurance pool, market insurance pool) +- `source_type`: the source account type (i.e. network treasury, market insurance pool) - `source` specifies the account to transfer from, depending on the account type: - network treasury: leave blank (only one per asset) - network insurance pool: leave blank (only one per asset) @@ -325,6 +321,10 @@ The proposal specifies: - party: the party's public key - network insurance pool: leave blank (there's only one per asset) - market insurance pool: market ID +- A proposal can be for a one off transfer or recurring. +- If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. +- If the proposal is recurring it has to define a start epoch and an optional end epoch. In such cast the transfer will be executed every epoch whil still active. + - Plus the standard proposal fields (i.e. voting and enactment dates, etc.) ### Transfer proposal enactment @@ -354,6 +354,20 @@ transfer_amount == min( proposal.amount ) ``` +### Transfer cancellation +This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance transfer. Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal. + +### Checkpoint/snapshot +Enacted and active transfers (i.e. scheduled one off governance transfers, or recurring governance transfers) must be included in banking checkpoint and resume after the checkpoint restore. + +All in memory active governance transfers must be included in the snapshot of the banking engine. + +### Additional information +1. When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with different type (i.e. similar to one-off, and recurring of regular transfers, there are governance-one-off and governance-recurring types). At the time of enactment no amount is attached to the transfer and it will show 0. +2. When a transfer is *made* an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. +3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. +4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. + ## 6. Freeform governance proposal The aim of this is to allow community to provide votes on proposals which don't change any of the behaviour of the currently running Vega blockchain. That is to say, at enactment time, no changes are effected on the system, but the record of how token holders voted will be stored on chain. The proposal will contain only the fields common to all proposals i.e. From 83c4eca6ef17728991c5d3d0e29d6d88f89e0fc4 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 26 May 2023 09:45:57 +0100 Subject: [PATCH 078/649] fix: md linting and spelling --- protocol/0028-GOVE-governance.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index a4854b8e2..5009b9ef1 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -321,9 +321,9 @@ The proposal specifies: - party: the party's public key - network insurance pool: leave blank (there's only one per asset) - market insurance pool: market ID -- A proposal can be for a one off transfer or recurring. -- If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. -- If the proposal is recurring it has to define a start epoch and an optional end epoch. In such cast the transfer will be executed every epoch whil still active. +- A proposal can be for a one off transfer or recurring. +- If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. +- If the proposal is recurring it has to define a start epoch and an optional end epoch. In such cast the transfer will be executed every epoch while still active. - Plus the standard proposal fields (i.e. voting and enactment dates, etc.) @@ -355,18 +355,21 @@ transfer_amount == min( ``` ### Transfer cancellation -This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance transfer. Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal. + +This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance transfer. Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal. ### Checkpoint/snapshot + Enacted and active transfers (i.e. scheduled one off governance transfers, or recurring governance transfers) must be included in banking checkpoint and resume after the checkpoint restore. -All in memory active governance transfers must be included in the snapshot of the banking engine. +All in memory active governance transfers must be included in the snapshot of the banking engine. ### Additional information -1. When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with different type (i.e. similar to one-off, and recurring of regular transfers, there are governance-one-off and governance-recurring types). At the time of enactment no amount is attached to the transfer and it will show 0. -2. When a transfer is *made* an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. -3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. -4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. + +1. When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with different type (i.e. similar to one-off, and recurring of regular transfers, there are governance-one-off and governance-recurring types). At the time of enactment no amount is attached to the transfer and it will show 0. +2. When a transfer is _made_ an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. +3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. +4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. ## 6. Freeform governance proposal From 9fa1897af1db4a1349b8ff5e66c6ab010a09d39a Mon Sep 17 00:00:00 2001 From: Zohar Etzioni Date: Fri, 26 May 2023 17:58:24 +0100 Subject: [PATCH 079/649] chore: Update protocol/0028-GOVE-governance.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 5009b9ef1..ab4779e2c 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -323,7 +323,7 @@ The proposal specifies: - market insurance pool: market ID - A proposal can be for a one off transfer or recurring. - If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. -- If the proposal is recurring it has to define a start epoch and an optional end epoch. In such cast the transfer will be executed every epoch while still active. +- If the proposal is recurring it has to define a start epoch and an optional end epoch. In such case the transfer will be executed every epoch while still active. - Plus the standard proposal fields (i.e. voting and enactment dates, etc.) From 674c4bfd40a6fdc3d86ce19702ac191dbbbf6719 Mon Sep 17 00:00:00 2001 From: Zohar Etzioni Date: Fri, 26 May 2023 17:58:33 +0100 Subject: [PATCH 080/649] chore: Update protocol/0028-GOVE-governance.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index ab4779e2c..d3073e296 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -360,7 +360,7 @@ This is done as a governance proposal. Takes a transfer ID (which is the proposa ### Checkpoint/snapshot -Enacted and active transfers (i.e. scheduled one off governance transfers, or recurring governance transfers) must be included in banking checkpoint and resume after the checkpoint restore. +Enacted and active transfers (i.e. scheduled one off governance transfers, or recurring governance transfers) must be included in LNL banking checkpoint and resume after the checkpoint restore. All in memory active governance transfers must be included in the snapshot of the banking engine. From 1f283dd880d72727e8bc0d25d54639513a9c9a48 Mon Sep 17 00:00:00 2001 From: Zohar Etzioni Date: Fri, 26 May 2023 17:58:42 +0100 Subject: [PATCH 081/649] chore: Update protocol/0028-GOVE-governance.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index d3073e296..c94452621 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -370,6 +370,7 @@ All in memory active governance transfers must be included in the snapshot of th 2. When a transfer is _made_ an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. 3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. 4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. +5. Governance initiated transfers are subject to neither minimum transfer amounts nor to fees. ## 6. Freeform governance proposal From 9db472d86baba12c6d7425a8154416af5f0c60b7 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 26 May 2023 18:10:30 +0100 Subject: [PATCH 082/649] fix/linting --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index c94452621..138ecdc3d 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -370,7 +370,7 @@ All in memory active governance transfers must be included in the snapshot of th 2. When a transfer is _made_ an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. 3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. 4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. -5. Governance initiated transfers are subject to neither minimum transfer amounts nor to fees. +5. Governance initiated transfers are subject to neither minimum transfer amounts nor to fees. ## 6. Freeform governance proposal From 526763d24861997091c9b7705d8b2974982d9538 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 26 May 2023 21:52:02 +0100 Subject: [PATCH 083/649] fix: address feedback - remove buys and sells --- protocol/0080-SPOT-product_builtin_spot.md | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 19ecaca01..31beee024 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -45,20 +45,6 @@ submission = { marketId: "abcdefghiklkmnopqrstuvwxyz", fee: "0.01", commitmentAmount: 15000 (DAI) - buys: [ - { - offset: "1" - proportion: "1" - reference: "PEGGED_REFERENCE_BEST_BID" - } - ] - sells: [ - { - offset: "1" - proportion: "1" - reference: "PEGGED_REFERENCE_BEST_ASK" - } - ] reference: "example_liquidity_provision_submission" } } From 9a8e880028e962245dbeb0d4ab1ac3b3d67b3e79 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 30 May 2023 20:05:19 +0100 Subject: [PATCH 084/649] feat: Governance transfer ACs (#1715) * feat: add governance transfer ACs * chore: give ACs numbering for approbation * feat: add ACs for update (recurring, cancelling) * chore: update spelling * chore: tidy up format * fix: trailing white space * Update 0028-GOVE-governance.md * feat: update Checkpoints and Snapshots AC-103 --------- Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 78 ++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 138ecdc3d..0211e2f78 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -512,3 +512,81 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - Approved governance proposals sharing the same enactment time should be enacted in the order the proposals were created. (0028-GOVE-067) - Approved governance proposals sharing the same enactment time and changing the same parameter should all be applied, the oldest proposal will be applied first and the newest will be applied last, overwriting the changes made by the older proposals. (0028-GOVE-068) + + +#### Governance Transfer proposals + + +##### Proposer Requirements + +- The transfer proposer must have at a staking balance which matches or exceeds `minProposerBalance` network parameter for this proposal type (0028-GOVE-073) + + +##### APIs + +- Governance transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074) + + +##### Transfer proposal submission validation + +- Proposals are either permitted or rejected according to the following source/destination combinations. (0028-GOVE-075) +- Transfer amount and fraction of balance are mutually exclusive and will cause the proposal to reject (0028-GOVE-076) +- Invalid source and destination account types will cause the proposal to reject (0028-GOVE-077) +- Source Type can be any of the predefined types in the above table (0028-GOVE-078) +- Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) +- Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080) +- For transfer source types of Market Insurance the source must be a valid market ID else is rejected (0028-GOVE-081) +- Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082) +- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083) +- Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084) +- Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085) +- Destination Type can be any of the predefined types in the above table (0028-GOVE-086) +- Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087) +- Destination must be a valid Reward Scheme ID for a transfer type of Reward Pool else is rejected (0028-GOVE-088) +- Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089) +- Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090) +- For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091) +- The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092) +- For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) + + +##### Governance transfer enactment + +- For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094) +- When insufficient tokens are found in the source account at time of transfer (enactment) a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-095) +- Transfers can occur for terminated markets (0028-GOVE-096) +- Transfers cannot occur for settled markets and a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-097) +- Transfers cannot occur for pending markets unless they become active on or before the enactment time of the transfer (0028-GOVE-098) + + +##### Transferred Amount + +- If the type of transfer is “All or nothing” then the minimum of either `fraction_of_balance * source_balance` and the transfer amount is transfers between accounts. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-099) +- If the type of transfer is “Best effort” then the transfer amount is derived from the minimum of `proposal.fraction_of_balance * source.balance, proposal.amount, NETWORK_MAX_AMOUNT, NETWORK_MAX_FRACTION * source.balance`. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-100) + + +##### Transfer Fees + +- No fees are incurred by the transfer and therefore the the number of tokens deducted from the source account should always equal the tokens added to the destination account (0028-GOVE-101) + + +##### Protocol Upgrade + +- Transfer proposals in either a pre or post enactment state are not restored after a protocol upgrade (0028-GOVE-102) + +#### Checkpoints and Snapshots + +- Active governance transfer (one-off or recurring) must be included in checkpoint and snapshot (0028-GOVE-103) + +##### Recurring Governance transfers + +- For a recurring proposal, the proposal is only active from defined start epoch and optional end epoch, the transfer will be executed every epoch while the proposal is active. (0028-GOVE-104) + +- Enacted and active recurring governance transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105) + +- When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106) + + +##### Cancelling governance transfers + +- Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) From 53b3a065b3145e10a5d779b5f74cf35259a46ae5 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 31 May 2023 13:57:35 +0100 Subject: [PATCH 085/649] chore: update spec number and add AC codes --- ...e.md => 0081-ETHD-ethereum-data-source.md} | 90 +++++++++---------- 1 file changed, 45 insertions(+), 45 deletions(-) rename protocol/{0000-ETHD-ethereum-data-source.md => 0081-ETHD-ethereum-data-source.md} (71%) diff --git a/protocol/0000-ETHD-ethereum-data-source.md b/protocol/0081-ETHD-ethereum-data-source.md similarity index 71% rename from protocol/0000-ETHD-ethereum-data-source.md rename to protocol/0081-ETHD-ethereum-data-source.md index d8cfae9d3..6087f4a60 100644 --- a/protocol/0000-ETHD-ethereum-data-source.md +++ b/protocol/0081-ETHD-ethereum-data-source.md @@ -110,84 +110,84 @@ Select { ### External Oracles - Creation -1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) -2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment -3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message -4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) +1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) (0081-ETHD-001) +2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment (0081-ETHD-002) +3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message (0081-ETHD-003) +4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) (0081-ETHD-004) ### External Oracles - Amendments -1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted. -2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted , the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted. -3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted. +1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted (0081-ETHD-005) +2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted , the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-006) +3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-007) ### External Oracles - Deletions -1. Ability to delete a data source if and only if the data source is NOT used by any active markets -2. Should NOT be able to delete a data source if its being actively used by a market -3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source +1. Ability to delete a data source if and only if the data source is NOT used by any active markets (0081-ETHD-008) +2. Should NOT be able to delete a data source if its being actively used by a market (0081-ETHD-009) +3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source (0081-ETHD-010) ### External Oracles - Validations -1. Validate if the smart contract address is valid -2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 -3. Validations for min / max frequency of listening for events / read a smart contract -4. Create a new market with an inactive external oracle data source, system should throw an error -5. Validations to be applied - need to be expanded -6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event +1. Validate if the smart contract address is valid (0081-ETHD-011) +2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 (0081-ETHD-012) +3. Validations for min / max frequency of listening for events / read a smart contract (0081-ETHD-013) +4. Create a new market with an inactive external oracle data source, system should throw an error (0081-ETHD-014) +5. Validations to be applied - need to be expanded (0081-ETHD-015) +6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event (0081-ETHD-016) ### New Network parameters -1. Test min / max values / validations for any new network parameters that are added -2. Test the impact / behaviour of the system, after the changes to the new network parameters are enacted +1. Test min / max values / validations for any new network parameters that are added (0081-ETHD-017) +2. Test the impact / behaviour of the system, after the changes to the new network parameters are enacted (0081-ETHD-018) ### Negative Tests -1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) -2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value -3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this -4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error -5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error -6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting. +1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) (0081-ETHD-019) +2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value (0081-ETHD-020) +3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this (0081-ETHD-021) +4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0081-ETHD-022) +5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0081-ETHD-023) +6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting (0081-ETHD-024) ### API -1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired / -2. Ability to query historic data sent by an oracle data source +1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0081-ETHD-025) +2. Ability to query historic data sent by an oracle data source (0081-ETHD-026) ### Non Functional -1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out -2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event -3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition. -4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed -5. SPAM rules if any defined should be tested for -6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly -7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market +1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out (0081-ETHD-027) +2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0081-ETHD-028) +3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0081-ETHD-029) +4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0081-ETHD-030) +5. SPAM rules if any defined should be tested for (0081-ETHD-031) +6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly (0081-ETHD-032) +7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market (0081-ETHD-033) ### Usage -1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles -2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market -3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market -4. Data sourcing should be completely decoupled from data filtering +1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles (0081-ETHD-034) +2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0081-ETHD-035) +3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market (0081-ETHD-036) +4. Data sourcing should be completely decoupled from data filtering (0081-ETHD-037) ### Checkpoints -1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints -2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config. +1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints (0081-ETHD-038) +2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0081-ETHD-039) ### Snapshots -1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots. -2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config. +1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots (0081-ETHD-040) +2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0081-ETHD-041) ### Protocol Upgrade -1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade. -2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade. -3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config. +1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade (0081-ETHD-042) +2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade (0081-ETHD-043) +3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config (0081-ETHD-044) ### Regression -1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one. +1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one (0081-ETHD-045) From d5d385ab4935c61d2c8a580eb597f2ad13f7231a Mon Sep 17 00:00:00 2001 From: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Date: Wed, 31 May 2023 15:13:17 +0100 Subject: [PATCH 086/649] chore: Add acceptance criteria for iceberg orders (#1716) * chore: Add acceptance criteria for iceberg orders * chore: Correct typos * fix: Address review comments * chore: add the AC codes for approbation runs --------- Co-authored-by: gordsport --- protocol/0014-ORDT-order_types.md | 62 +++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index c41a7bca4..0fa34dfe7 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -208,6 +208,68 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) - No party can submit a [network order type](#network-orders) (0014-ORDT-006) +### Iceberg Orders AC's + +#### Iceberg Order Submission + +1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007) +2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008) +3. An iceberg post only order can be submitted (0014-ORDT-009) +4. An iceberg reduce only order is rejected (0014-ORDT-010) +5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) +6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) + - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue +7. For an iceberg order that's submitted when the market is in auction, only the displayed quantity is filled when coming out of auction (0014-ORDT-013) + +#### Iceberg Order Batch Submission + +1. For multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, margin calculations , order status are all correct (0014-ORDT-014) +2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book , the iceberg order does not refresh until the end of the batch after it is depleted (0014-ORDT-015) + +#### Iceberg Order Submission - Negative tests + +1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016) +2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017) +3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018) +4. An iceberg order with initial peak size less than the minimum order size rejected with a valid error message (0014-ORDT-019) +5. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) +6. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) +7. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) + +#### Iceberg Order Amendment + +1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023) +2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024) +3. Amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost (0014-ORDT-025) + +#### Iceberg Order Cancellation + +1. Cancelling an iceberg order will cancel the order, remove it from the order book , release margin and update order book to reflect the change (0014-ORDT-026) + +#### Iceberg Order Execution + +1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027) +2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is partially filled , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders thar are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) +3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) +4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030) +5. Submit an aggressive iceberg order for say size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (Low Priority AC) (0014-ORDT-031) +6. Submit an aggressive iceberg order for say size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (Low Priority AC)(0014-ORDT-032) +7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue , another normal order in opposite direction , the iceberg at the back comes in front and matches either fully OR partially and gets rejected( 0014-ORDT-034) + +### Snapshots + +1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035) + +### API + +1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) +2. The additional fields relating to iceberg orders should be available in the streaming api end points + +### Protocol Upgrade + +1. No impact. + ### See also - [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) From aee7bd1f8f665960d0d11c70fbe40013e07a2269 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 31 May 2023 16:17:58 +0100 Subject: [PATCH 087/649] fix: spelling and markdown linting --- protocol/0014-ORDT-order_types.md | 53 ++++---- protocol/0035-LIQM-liquidity_monitoring.md | 4 +- ...042-LIQF-setting_fees_and_rewarding_lps.md | 113 ++++++++++-------- protocol/0044-LIME-lp_mechanics.md | 90 +++++++------- wordlist.txt | 4 + 5 files changed, 146 insertions(+), 118 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 0fa34dfe7..b871d9ba7 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -6,8 +6,8 @@ A market using a limit order book will permit orders of various types to be subm Notes on scope of current version of this spec: -- Includes only detailed specification for orders valid for *continuous trading*, does not specify behaviour of these order types in an auction. -- Does not include detailed specification for **stop** orders. Inclusion of stops in guide level explanation is a placeholder/indicator of future requirements. +* Includes only detailed specification for orders valid for *continuous trading*, does not specify behaviour of these order types in an auction. +* Does not include detailed specification for **stop** orders. Inclusion of stops in guide level explanation is a placeholder/indicator of future requirements. ## Guide-level explanation @@ -95,7 +95,7 @@ The iceberg is refreshed any time the order's displayed quantity is less than th * Any persistent TIF (GTC, GTT, GFA, GFN) can be an iceberg order. -* An iceberg order may have either an ordinary or pegged limit price. +* An iceberg order may have either an ordinary or pegged limit price. Market iceberg orders are not supported, even if with a persistent TIF. * Icebergs may be post only. @@ -113,9 +113,9 @@ This is to prevent an iceberg order ever being crossed after refreshing. * Once they enter the book passively, iceberg orders trade just like non-iceberg persistent order, as if the order entered the book with `quantity = initial peak size` on submission, and again each time they are refreshed until `remaining == 0` (or they are cancelled or expired, etc.). That is: - * On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. - - * As for any other order, `remaining == quantity` on entry. + * On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. + + * As for any other order, `remaining == quantity` on entry. * The maximum total size for all trades involving an iceberg order in any given transaction (including a batch) is the `displayed quantity` immediately prior to the trade. (This is technically also true for a normal order, given that for non-iceberg orders `displayed quantity == remaining`.) @@ -129,13 +129,13 @@ The order will not be refreshed after each trade while `displayed quantity ≥ m * When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: - * The refresh happens at the end of the transaction when the order becomes eligible for refresh. - - * On refresh `display quantity` is set to `min(remaining, initial peak size)`. + * The refresh happens at the end of the transaction when the order becomes eligible for refresh. + + * On refresh `display quantity` is set to `min(remaining, initial peak size)`. - * A refresh simulates a cancel/replace, which means that on refresh an iceberg order will always lose time priority relative to other orders at the same price. + * A refresh simulates a cancel/replace, which means that on refresh an iceberg order will always lose time priority relative to other orders at the same price. - * If multiple iceberg orders need to be refreshed at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the iceberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). + * If multiple iceberg orders need to be refreshed at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the iceberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). * Once the remaining quantity is equal to the displayed quantity, no further refresh is possible. The order now behaves like a normal limit order and will leave the book if it trades away completely. @@ -143,16 +143,16 @@ The order now behaves like a normal limit order and will leave the book if it tr #### Amendment -* Amending the size of an iceberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quanity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. +* Amending the size of an iceberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quantity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. -* Amending the size/quantity of an iceberg order does not cause it to lose time priority. +* Amending the size/quantity of an iceberg order does not cause it to lose time priority. This is because the increase applies to the `remaining` quantity and not to the `displayed quantity`. This is allowed because the order will lose time priority on refresh, i.e. before the increased quantity is available to trade. #### Auctions -* Icebergs can be entered or carried into auctions if the underlying TIF is supported. +* Icebergs can be entered or carried into auctions if the underlying TIF is supported. * Icebergs can trade in the auction uncrossing up to their current `displayed quantity` as for any other transaction that would cause a trade with an iceberg order. @@ -166,7 +166,6 @@ This is allowed because the order will lose time priority on refresh, i.e. befor * An iceberg order refresh must generate an event bus event. - ### Valid order entry combinations #### Continuous trading @@ -194,19 +193,19 @@ This is allowed because the order will lose time priority on refresh, i.e. befor Network orders are used during [position resolution](./0012-POSR-position_resolution.md#position-resolution-algorithm). Network orders are orders triggered by Vega to close out positions for distressed traders. -- Network orders have a counterparty of `Network` -- Network orders are a Fill Or Kill, Market orders -- Network orders cannot be submitted by any party, they are created during transaction processing. +* Network orders have a counterparty of `Network` +* Network orders are a Fill Or Kill, Market orders +* Network orders cannot be submitted by any party, they are created during transaction processing. ## Acceptance Criteria -- Immediate orders, continuous trading: - - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) - - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) - - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) - - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) - - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) -- No party can submit a [network order type](#network-orders) (0014-ORDT-006) +* Immediate orders, continuous trading: + * An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) + * An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) + * An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) + * Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) + * A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) +* No party can submit a [network order type](#network-orders) (0014-ORDT-006) ### Iceberg Orders AC's @@ -218,7 +217,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 4. An iceberg reduce only order is rejected (0014-ORDT-010) 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) 6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) - - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue + * If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue 7. For an iceberg order that's submitted when the market is in auction, only the displayed quantity is filled when coming out of auction (0014-ORDT-013) #### Iceberg Order Batch Submission @@ -272,4 +271,4 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ### See also -- [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) +* [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index cee0be77d..e4ef34d02 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -11,7 +11,7 @@ Indeed `lp_liquidity_obligation_in_ccy_volume = market.liquidity.stakeToCcyVolume ⨉ stake`. -Thus it is sufficient to compare `target_stake` with `total_stake`. +Thus it is sufficient to compare `target_stake` with `total_stake`. Note that [target stake](./0041-TSTK-target_stake.md) is defined in a separate spec. @@ -39,7 +39,7 @@ If an incoming order would match orders on the book resulting in trades increasi ### Decreasing supplied stake -If the [liquidity provision transaction would decrease](./0044-LIME-lp_mechanics.md#liquidity-provider-proposes-to-amend-commitment-amount) `supplied_stake` so that liquidity auction gets triggered then a liquidity auction is triggered the next time the next time conditions for liquidity auctions are evaluated. +If the [liquidity provision transaction would decrease](./0044-LIME-lp_mechanics.md#liquidity-provider-proposes-to-amend-commitment-amount) `supplied_stake` so that liquidity auction gets triggered then a liquidity auction is triggered the next time the next time conditions for liquidity auctions are evaluated. If the `supplied_stake` decreases as a result of a closeout of an insolvent liquidity provider, then closeout should proceed and market should go into liquidity auction the next time the next time conditions for liquidity auctions are evaluated. diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 90c5be0ce..ac27b9f63 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -179,9 +179,9 @@ An existing LP has `average entry valuation 1090.9` and `S=110`. Currently the s ### Calculating the instantaneous liquidity score At every vega time change calculate the liquidity score for each committed LP. -This is done by taking into account all orders they have deployed within the `[min_lp_price,max_lp_price]` [range](./0044-LIME-lp_mechanics.md) and then calculating the volume-weighted [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) at each price level - call it instantaneous liquidity score. +This is done by taking into account all orders they have deployed within the `[min_lp_price,max_lp_price]` [range](./0044-LIME-lp_mechanics.md) and then calculating the volume-weighted [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) at each price level - call it instantaneous liquidity score. For orders outside the tightest price monitoring bounds set probability of trading to 0. -Note that parked [pegged orders](./0037-OPEG-pegged_orders.md) and not-yet-triggered [stop orders](./0014-ORDT-order_types.md) are not included. +Note that parked [pegged orders](./0037-OPEG-pegged_orders.md) and not-yet-triggered [stop orders](./0014-ORDT-order_types.md) are not included. Now calculate the total of the instantaneous liquidity scores obtained for each committed LP: @@ -203,56 +203,55 @@ The liquidity score should always be rounded to 10 decimal places to prevent spu ### Distributing fees into LP-per-market fee account -On every trade, liquidity fee should be collected immediately into the market LP fee account. -The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. +On every trade, liquidity fee should be collected immediately into the market LP fee account. +The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market LP fee account. +A network parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.calculationTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. The liquidity fees are transferred from the market LP fee account into the LP-per-market fee account, pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. -The LP parties don't control the LP-per-market fee account; the fees from there are then tranferred to the LPs' general account at the end epoch as described below. - +The LP parties don't control the LP-per-market fee account; the fees from there are then transferred to the LPs' general account at the end epoch as described below. ### Calculating SLA performance #### Measuring time spent meeting their commitment in a single epoch -During the epoch, the amount of time in nanoseconds (of Vega time) that each LP spends meeting the SLA is recorded. This can be done by maintaning a counter `s_i` as shown below: +During the epoch, the amount of time in nanoseconds (of Vega time) that each LP spends meeting the SLA is recorded. This can be done by maintaining a counter `s_i` as shown below: -* At the start of a new epoch, `s_i = 0` +- At the start of a new epoch, `s_i = 0` - * If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. + - If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -* At the start of each block generate a pseudorandom integer `k` between `1..N` (inclusive of `1` and `N`) where `N` is the number of transactions in the block (note: transactions not orders, a batch is one transaction for this purpose). +- At the start of each block generate a pseudorandom integer `k` between `1..N` (inclusive of `1` and `N`) where `N` is the number of transactions in the block (note: transactions not orders, a batch is one transaction for this purpose). Use a suitable deterministic seed to minimise the probability of an LP gaming `k` or being able to target transactions around (directly before or after) the point `k`. For example, the seed might combine the hash of all transactions in the block itself with the number of transactions `N`. Using only information from the prior block as the seed may allow exploits based on pre-generation of `k` and must be avoided. -* In each block, immediately after processing transaction `k`: +- In each block, immediately after processing transaction `k`: + + - Note that this happens _after_ iceberg orders, that need refreshing as a result of transaction `k` are refreshed. + This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. - * Note that this happens _after_ iceberg orders, that need refreshing as a result of transaction `k` are refreshed. - This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. + - If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): - * If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): + - Store the current Vega time attached to the block being processed as the time the LP began meeting their commitment. - * Store the current Vega time attached to the block being processed as the time the LP began meeting their commitment. + - If LP has stopped meeting their committed volume of notional after previously doing so: - * If LP has stopped meeting their committed volume of notional after previously doing so: + - Add the difference in nanoseconds between the current Vega time attached to the block being processed and the time the LP began meeting their commitment (stored in the step above) to `s_i`. - * Add the difference in nanoseconds between the current Vega time attached to the block being processed and the time the LP began meeting their commitment (stored in the step above) to `s_i`. - - * Store `nothing` as the time the LP began meeting their commitment, to signify the LP not meeting their commitment. + - Store `nothing` as the time the LP began meeting their commitment, to signify the LP not meeting their commitment. -* At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. +- At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. -#### Calculating the SLA performance penalty for a single epoch +#### Calculating the SLA performance penalty for a single epoch Calculate the fraction of the time the LP spent on the book: -``` +```text fraction_of_time_on_book = s_i / observed_epoch_length ``` @@ -263,55 +262,62 @@ For each LP where `fraction_of_time_on_book ≥ market.liquidity.commitmentMinTi Let $t$ be `fraction_of_time_on_book` -Let $s$ be `market.liquidity.committmentMinTimeFraction`. +Let $s$ be `market.liquidity.commitmentMinTimeFraction`. Let $c$ be `market.liquidity.slaCompetitionFactor`. -$$ +```text +$$ p_i = (1 - \frac{t - s}{1 - s}) \cdot c. $$ +``` -#### Calculating the SLA performance penalty for over hysteresis period +#### Calculating the SLA performance penalty for over hysteresis period Now, for each LP $i$ take the $p_i$ values calculated over the last `market.liqudity.performanceHysteresisEpochs - 1`, call these $p_i^1, p_i^2, ..., p_i^{n-1}$ (if all the historical ones are not yet available, take as many as there are - i.e. expanding window till you get to the full length). -Now calculate $p_i^n$ to be the arithmetic average of $p_i^k$ for $k = 1,2,...,n-1$. +Now calculate $p_i^n$ to be the arithmetic average of $p_i^k$ for $k = 1,2,...,n-1$. Finally set +```text $$ p_i^n \leftarrow \max(p_i,p_i^n). $$ +``` i.e. your penalty is the bigger of current epoch and average over the hysteresis period ### Applying LP SLA performance penalties to accrued fees -As defined above, for each LP for each epoch you have "penalty fraction" $p_i^n$ which is between `[0,1]` with `0` indicating LP has met committment 100% of the time and `1` indicating that LP was below `market.liquidity.committmentMinTimeFraction` of the time. +As defined above, for each LP for each epoch you have "penalty fraction" $p_i^n$ which is between `[0,1]` with `0` indicating LP has met commitment 100% of the time and `1` indicating that LP was below `market.liquidity.commitmentMinTimeFraction` of the time. If for all $i$ (all the LPs) have $p_i^n = 1$ then all the fees go into the market insurance pool and we stop. -Calculate +Calculate +```text $$ w_i = \frac{\text{LP-per-market fee account } i}{\sum_k \text{LP-per-market fee account } k}. -$$ +$$ +``` -For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". +For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -Transfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. -Record its balance to be $B$. +Transfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. +Record its balance to be $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. +```text $$ b_i \leftarrow \frac{b_i}{\sum_k b_k}\,. $$ +``` Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". Note that after this process completes the balance of the temporary (one per market) bonus distribution account described above **must be zero** and the account may be destroyed (and recreated again when needed). -There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's tranfer this to a fixed example. - +There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's transfer this to a fixed example. ### APIs for fee splits and payments @@ -332,11 +338,13 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If a change in the open interest causes the liquidity demand estimate to change, then fee factor is correctly recalculated. (0042-LIQF-006) - If passage of time causes the liquidity demand estimate to change, the fee factor is correctly recalculated. (0042-LIQF-007) + ### CHANGE OF NETWORK PARAMETERS TESTS - Change of network parameter `market.liquidityProvision.minLpStakeQuantumMultiple` will change the multiplier of the asset quantum that sets the minimum LP commitment amount. If `market.liquidityProvision.minLpStakeQuantumMultiple` is changed then no LP orders that have already been submitted are affected. However any new submissions or amendments must respect the new amount and those not meeting the new minimum will be rejected. (0042-LIQF-021) - Change of network parameter `market.value.windowLength` will affect equity-like share calculations from the next block. Decreasing it so that the current period is already longer then the new parameter value will end it immediately and the next period will have the length specified by the updated parameter. Increasing it will lengthen the current period up to the the length specified by the updated parameter. (0042-LIQF-022) + ### SPLITTING FEES BETWEEN liquidity providers - The examples provided result in the given outcomes. (0042-LIQF-008) @@ -346,6 +354,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) - After fee distribution, if there is a remainder in the liquidity fee account and the market is not being settled, it should be left in the liquidity fee account and carried over to the next distribution window. (0042-LIQF-032) + ### LP JOINING AND LEAVING MARKETS - An LP joining a market that is below the target stake with a higher fee bid than the current fee: their fee is used (0042-LIQF-019) @@ -361,32 +370,40 @@ There is an example [google sheet for this step](https://docs.google.com/spreads ### API -- [ ] Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) -- [ ] Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) +- Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) +- Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) + ### Distribution -- [ ] If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) +- If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) + -### successor market +### Successor market -- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-032) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-032) - If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) - If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) + ### Calculating SLA Performance -- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 1`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.5`. This will be true whether: - - Their liquidity is all provided at the start of the epoch and then none is provided for the second half (0042-LIQF-037) - - Their liquidity is provided scattered throughout the epoch (0042-LIQF-038) - -- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0`. (0042-LIQF-041) -- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0.5`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.25`. (0042-LIQF-042) + +- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 1`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.5`. This will be true whether: + + - Their liquidity is all provided at the start of the epoch and then none is provided for the second half (0042-LIQF-037) + - Their liquidity is provided scattered throughout the epoch (0042-LIQF-038) + +- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0`. (0042-LIQF-041) +- If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0.5`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.25`. (0042-LIQF-042) - When `market.liquidity.performanceHysteresisEpochs = 0`: + - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch(0042-LIQF-036) + - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch(0042-LIQF-036) + - When `market.liquidity.performanceHysteresisEpochs = n`: + - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they never meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 0` for the latest epoch a penalty rate of `1` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-040) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f26e4569c..f2bdcf84b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -1,6 +1,6 @@ # Liquidity provision mechanics -The point of liquidity provision on Vega is to incentivise people to place orders on the market that maintain liquidity on the book. +The point of liquidity provision on Vega is to incentivise people to place orders on the market that maintain liquidity on the book. This is done via a financial commitment and reward + penalty mechanics, and through the LP commitment transaction that announces that a party is entering the liquidity provision (LP) service level agreement (SLA). @@ -19,8 +19,8 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.sla.nonPerformanceBondPenaltyMax` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` and `<=1.0` with a default value of `0.5`. - `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of the LP commitment transaction. Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>=0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. -- `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liqudity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). -- `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. +- `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liquidity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). +- `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. @@ -30,18 +30,18 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. -- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. +- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. -- `market.liqudity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. +- `market.liquidity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. -- `market.liqudity.slaCompetitionFactor` - the maximum fraction of their accrued fees an LP that meets the SLA implied by `market.liquidity.committmentMinTimeFraction` will lose to LPs that achieved a higher SLA performance than them. +- `market.liquidity.slaCompetitionFactor` - the maximum fraction of their accrued fees an LP that meets the SLA implied by `market.liquidity.committmentMinTimeFraction` will lose to LPs that achieved a higher SLA performance than them. For LP reward calculations based on the SLA see the [0042-LIQF spec](./0042-LIQF-setting_fees_and_rewarding_lps.md). ## Mechanism overview -At a high level, the liqudity mechanism in Vega allows Liquidity Providers (LPs) to commit liquidity to a market and "bid" to set the liqudity fee on the market. LPs that meet this commitment are rewarded from the fee revenue. This is done by: +At a high level, the liquidity mechanism in Vega allows Liquidity Providers (LPs) to commit liquidity to a market and "bid" to set the liquidity fee on the market. LPs that meet this commitment are rewarded from the fee revenue. This is done by: - Requiring LPs to meet an SLA (i.e. % of time spent providing liquidity within the defined range) in order to be rewarded. @@ -49,7 +49,7 @@ At a high level, the liqudity mechanism in Vega allows Liquidity Providers (LPs) - Penalising LPs that commit and do not meet the SLA, to reduce the attractiveness of opportunistically going after rewards with no intention to meet the SLA in more challenging conditions, and of leeching style attacks on the rewards. -Once committed LPs attempt to meet their comitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and iceberg (or more accurately, transparent iceberg) to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. +Once committed LPs attempt to meet their commitment by placing and maintaining normal orders on the market. They may use pegged or priced limit orders, along with features like post only and iceberg (or more accurately, transparent iceberg) to control their risk. Non-persistent orders, parked pegged orders, and stop-loss orders do not count towards an LP's supplied liquidity and therefore cannot be used to meet the SLA. ## Commit liquidity network transaction @@ -73,20 +73,20 @@ Accepted if all of the following are true: When a commitment is made the liquidity commitment amount is assumed to be specified in terms of the settlement currency of the market. There is an minimum LP stake which is `market.liquidityProvision.minLpStakeQuantumMultiple x quantum` where `quantum` is specified per asset, see [asset framework spec](./0040-ASSF-asset_framework.md). -If the participant has sufficient collateral to cover their commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are committing liquidity, created as needed). +If the participant has sufficient collateral to cover their commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are committing liquidity, created as needed). For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). -Entering commitment will happen(*) at the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated). It's the prospective LP's responsibility to have sufficient balance in their general account at the epoch boundary; if not the LP commitment is cancelled. +Entering commitment will happen(*) at the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated). It's the prospective LP's responsibility to have sufficient balance in their general account at the epoch boundary; if not the LP commitment is cancelled. -(*) The expection is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. +(*) The expectation is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. -The fee for the market is only [updated at the epoch boundary using the "auction" mechanism set here](0042-LIQF-setting_fees_and_rewarding_lps.md). +The fee for the market is only [updated at the epoch boundary using the "auction" mechanism set here](0042-LIQF-setting_fees_and_rewarding_lps.md). Liquidity provider bond account: - Each active market has one bond account per liquidity provider, per settlement asset for that market. - When a liquidity provider transaction is approved, the size of their staked bond is immediately transferred from their general account to this bond account. -- A liquidity provider can only prompt a transfer of funds to or from this account by (re)submitting the LP commitment transaction: a valid transaction to create, increase, or decrease their commitment to the market. +- A liquidity provider can only prompt a transfer of funds to or from this account by (re)submitting the LP commitment transaction: a valid transaction to create, increase, or decrease their commitment to the market. - Transfers to/from this account also occur when it is used for settlement or margin shortfall, when penalties are applied, and if the account is under-collateralised because of these uses and is subsequently topped up to the commitment amount during collateral search (see below) - Collateral withdrawn from this account may only be transferred to either: - The insurance pool of the market (in event of penalties/slashing) @@ -100,11 +100,12 @@ A participant may apply to amend their commitment amount by submitting a transac `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` -The amendment is actioned in two steps. -1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. -2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. ``` +The amendment is actioned in two steps. -Commitment amendmends should be processed in the time order of their latest updates within the epoch. For example if an LP places an amendment at time `t1`, followed by LP2 placing an amendment at `t2` and the first LP amending again at `t1`, LP2's amendment will be executed first. +1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. +2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. + +Commitment amendments should be processed in the time order of their latest updates within the epoch. For example if an LP places an amendment at time `t1`, followed by LP2 placing an amendment at `t2` and the first LP amending again at `t1`, LP2's amendment will be executed first. #### Increasing commitment @@ -116,7 +117,7 @@ If they do not have sufficient collateral the transaction is rejected in entiret #### Decreasing commitment _Case:_ `proposed-commitment-variation < 0` -We to calculate how much the LP can reduce commitment without incurring a penalty. +We to calculate how much the LP can reduce commitment without incurring a penalty. To do this we first evaluate the maximum amount that the market can reduce without penalty by given the current liquidity demand in the market. `maximum-penalty-free-reduction-amount = total_stake - target_stake` @@ -129,10 +130,12 @@ where: If `-1 * proposed-commitment-variation <= maximum-penalty-free-reduction-amount` then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). If `-1 * proposed-commitment-variation > maximum-penalty-free-reduction-amount` then first establish -``` + +```text penalty-incuring-reduction-amount = -1 * proposed-commitment-variation - maximum-penalty-free-reduction-amount ``` -Transfer `maximum-penalty-free-reduction-amount` to their general account. + +Transfer `maximum-penalty-free-reduction-amount` to their general account. Now transfer `min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to their general account and transfer `market.liquidity.earlyExitPenalty x penalty-incuring-reduction-amount` to the market insurance pool. Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire `proposed-commitment-variation` as the `delta`. @@ -161,45 +164,52 @@ When calculating fees for a trade, the size of a liquidity provider’s commitme Committed Liquidity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below. The multiple is controlled by a network parameter `market.liquidity.stakeToCcyVolume`: -``` + +```text liquidity_required = stake_amount ✖️ market.liquidity.stakeToCcyVolume ``` -### Meeting the committed volume of notional +### Meeting the committed volume of notional #### During continuous trading -If there is no mid price then no LP is meeting their committed volume of notional. + +If there is no mid price then no LP is meeting their committed volume of notional. If there is mid price then we calculate the volume of notional that is in the range -``` + +```text (1.0-market.liquidity.priceRange) x mid =< price levels that count <= (1+market.liquidity.priceRange)x mid. ``` + If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. -#### During auctions +#### During auctions + We calculate the volume of notional that is in the range + +```text +(1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) =< price levels that count <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). ``` -(1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) =< price levels that count <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). -``` + If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. -Note: we don't evaluate whether LPs meet the SLA during opening auctions so there will always be a mark price. +Note: we don't evaluate whether LPs meet the SLA during opening auctions so there will always be a mark price. -### Penalty for not meeting the SLA +### Penalty for not meeting the SLA -See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. -This is available at the end of each epoch. +See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. +This is available at the end of each epoch. If, at the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. -Otherwise we calculate a penalty to be applied to the bond as follows. +Otherwise we calculate a penalty to be applied to the bond as follows. Let $t$ be `fraction_of_time_on_book` -Let $s$ be `market.liquidity.committmentMinTimeFraction`. +Let $s$ be `market.liquidity.committmentMinTimeFraction`. Let $p$ be `market.liquidity.sla.nonPerformanceBondPenaltySlope`. -Let $m$ be `market.liquidity.sla.nonPerformanceBondPenaltyMax`. +Let $m$ be `market.liquidity.sla.nonPerformanceBondPenaltyMax`. Let @@ -207,7 +217,7 @@ $$ f = \max\left[0,\min\left(m, p \cdot (1 - \frac{t}{s})\right)\right]\,. $$ -Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. +Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). ### Penalty for not supporting open positions @@ -244,12 +254,11 @@ Note: In the same way that a collateral search is initiated to attempt to top-up a trader's margin account if it drops below the _collateral search level_, the system must also attempt to top up the bond account if its balance drops below the size of the LP's commitment. -This should happen every time the network is performing a margin calculation and search. The system should prioritise topping up the margin account first, and then the bond account, if there are insufficient funds to do both. +This should happen every time the network is performing a margin calculation and search. The system should prioritise topping up the margin account first, and then the bond account, if there are insufficient funds to do both. If, at the end of an epoch (and before any LP rewards and penalties were applied), the LPs bond account isn't topped up to the level of their commitment then, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). - ## What data do we keep relating to liquidity provision? 1. List of all liquidity providers and their commitment sizes and their “equity-like share” for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) @@ -278,7 +287,7 @@ If, at the end of an epoch (and before any LP rewards and penalties were applied - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) - + - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. (0044-LIME-018) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the bond stake has been slashed to a level lower than the amendment, this slashed level will be retained (i.e. the protocol will not attempt to now increase the commitment) (0044-LIME-020) @@ -289,10 +298,9 @@ If, at the end of an epoch (and before any LP rewards and penalties were applied - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-023) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) -- +- - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - - `LP2` places a transaction to reduce their stake by `100`, + - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-025) - diff --git a/wordlist.txt b/wordlist.txt index ad2292c39..a7b63313d 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -1,6 +1,7 @@ ABCI ABCI++ ABI +actioned Allowlist allowlisted antiwhaling @@ -190,10 +191,12 @@ pre pro protobuf Pseudocode +pseudorandom pubkey rata reimplemented repo +renormalise reponse repurpose resync @@ -214,6 +217,7 @@ SHA sharded SHA3 siskas +SLA Solana src stablecoin From 184030780bbfb6b44719cc011a05d748f675fada Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 31 May 2023 17:14:01 +0100 Subject: [PATCH 088/649] fix: approbation errors --- protocol/0026-AUCT-auctions.md | 2 +- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 12 ++++++------ protocol/0044-LIME-lp_mechanics.md | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 762b1d5b4..6e09fcdc8 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -172,7 +172,7 @@ message Market { 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) - - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) + - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have - best bid; it will still open. (0026-AUCT-021) - or best ask; it will still open. (0026-AUCT-022) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index ac27b9f63..76ce9067f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -382,7 +382,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads ### Successor market - If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-032) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-048) - If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) - If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) @@ -404,14 +404,14 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - When `market.liquidity.performanceHysteresisEpochs = n`: - - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) + - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-047) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they never meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 0` for the latest epoch a penalty rate of `1` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-040) ### SLA Performance bonus transfers -- The balance of the per-market liquidity fee bonus distribution account should always be zero after bonus distribution is completed (0042-LIQF-041) -- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-042) -- With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-043) -- With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-044) +- The balance of the per-market liquidity fee bonus distribution account should always be zero after bonus distribution is completed (0042-LIQF-043) +- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) +- With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) +- With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f2bdcf84b..f5cd6d644 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -295,12 +295,12 @@ If, at the end of an epoch (and before any LP rewards and penalties were applied - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) -- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-023) +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) -- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-025) - - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` - `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-025) + `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) From a8e2583f90cb85e33ed3b3bce7792d32b42bf9dd Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Wed, 31 May 2023 18:45:25 +0100 Subject: [PATCH 089/649] feat: Update iceberg spec --- protocol/0014-ORDT-order_types.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index b871d9ba7..4c28e3164 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -117,16 +117,11 @@ That is: * As for any other order, `remaining == quantity` on entry. -* The maximum total size for all trades involving an iceberg order in any given transaction (including a batch) is the `displayed quantity` immediately prior to the trade. -(This is technically also true for a normal order, given that for non-iceberg orders `displayed quantity == remaining`.) - * When an iceberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. * Iceberg orders can trade many times without refresh, reducing `displayed quantity` each time. The order will not be refreshed after each trade while `displayed quantity ≥ minimum peak size`. -* Iceberg orders never trade more than their `displayed quantity` at the start of the transaction, as the result of any one transaction. - * When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: * The refresh happens at the end of the transaction when the order becomes eligible for refresh. @@ -140,6 +135,14 @@ The order will not be refreshed after each trade while `displayed quantity ≥ m * Once the remaining quantity is equal to the displayed quantity, no further refresh is possible. The order now behaves like a normal limit order and will leave the book if it trades away completely. +* For an incoming order with size larger than the total displayed quantity at a given price level, the following procedure should be followed: + + * The incoming order trades with all visible volume at the price level, whether an iceberg order or a vanilla limit order + + * If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. + + * If there are still remaining iceberg orders at this point, refresh their volumes and continue trading. If the incoming order uses up all iceberg orders at this level, continue with any remaining volume to the next price level. + #### Amendment @@ -218,12 +221,12 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) 6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) * If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue -7. For an iceberg order that's submitted when the market is in auction, only the displayed quantity is filled when coming out of auction (0014-ORDT-013) +7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013) #### Iceberg Order Batch Submission 1. For multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, margin calculations , order status are all correct (0014-ORDT-014) -2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book , the iceberg order does not refresh until the end of the batch after it is depleted (0014-ORDT-015) +2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015) #### Iceberg Order Submission - Negative tests @@ -251,10 +254,13 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is partially filled , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders thar are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) 3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) 4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030) -5. Submit an aggressive iceberg order for say size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (Low Priority AC) (0014-ORDT-031) -6. Submit an aggressive iceberg order for say size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (Low Priority AC)(0014-ORDT-032) +5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) +6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032) 7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) 8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue , another normal order in opposite direction , the iceberg at the back comes in front and matches either fully OR partially and gets rejected( 0014-ORDT-034) +9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) ### Snapshots @@ -265,10 +271,6 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) 2. The additional fields relating to iceberg orders should be available in the streaming api end points -### Protocol Upgrade - -1. No impact. - ### See also * [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) From 25142a1a5fb308e4d5a80359b7f5251b9ac70785 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 1 Jun 2023 10:24:32 +0100 Subject: [PATCH 090/649] chore: linting --- protocol/0014-ORDT-order_types.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 4c28e3164..8c95f4c74 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -139,7 +139,7 @@ The order now behaves like a normal limit order and will leave the book if it tr * The incoming order trades with all visible volume at the price level, whether an iceberg order or a vanilla limit order - * If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. + * If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. * If there are still remaining iceberg orders at this point, refresh their volumes and continue trading. If the incoming order uses up all iceberg orders at this level, continue with any remaining volume to the next price level. @@ -259,8 +259,8 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) 8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue , another normal order in opposite direction , the iceberg at the back comes in front and matches either fully OR partially and gets rejected( 0014-ORDT-034) 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) ### Snapshots From 2d73c836f966c6a9aafbb072bc5422ecc470b50e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 1 Jun 2023 10:28:26 +0100 Subject: [PATCH 091/649] fix: remainders --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 8c95f4c74..12fa40133 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -139,7 +139,7 @@ The order now behaves like a normal limit order and will leave the book if it tr * The incoming order trades with all visible volume at the price level, whether an iceberg order or a vanilla limit order - * If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. + * If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. If the distribution doesn't divide exactly stick the extra onto the iceberg which is first in terms of time priority. * If there are still remaining iceberg orders at this point, refresh their volumes and continue trading. If the incoming order uses up all iceberg orders at this level, continue with any remaining volume to the next price level. From bf3ff36a367f70bc2aeb29270c1900035ccd2ecc Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Thu, 1 Jun 2023 22:02:36 +0100 Subject: [PATCH 092/649] Update 0028-GOVE-governance.md --- protocol/0028-GOVE-governance.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 0211e2f78..d0f92d058 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -307,7 +307,6 @@ The proposal specifies: - `source_type`: the source account type (i.e. network treasury, market insurance pool) - `source` specifies the account to transfer from, depending on the account type: - network treasury: leave blank (only one per asset) - - network insurance pool: leave blank (only one per asset) - market insurance pool: market ID - `type`, which can be either "all or nothing" or "best effort": - all or nothing: either transfers the specified amount or does not transfer anything @@ -317,7 +316,6 @@ The proposal specifies: - `fraction_of_balance`: the maximum fraction of the source account's balance to transfer as a decimal (i.e. 0.1 = 10% of the balance) - `destination_type` specifies the account type to transfer to (reward pool, party, network insurance pool, market insurance pool) - `destination` specifies the account to transfer to, depending on the account type: - - reward pool: the reward scheme ID - party: the party's public key - network insurance pool: leave blank (there's only one per asset) - market insurance pool: market ID From ab026c0fde316e5da22618c6ddd2b0cb8beaa8b4 Mon Sep 17 00:00:00 2001 From: Paul Webb Date: Thu, 1 Jun 2023 22:06:35 +0100 Subject: [PATCH 093/649] fix: adjust --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index d0f92d058..68ee5e11d 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -316,8 +316,8 @@ The proposal specifies: - `fraction_of_balance`: the maximum fraction of the source account's balance to transfer as a decimal (i.e. 0.1 = 10% of the balance) - `destination_type` specifies the account type to transfer to (reward pool, party, network insurance pool, market insurance pool) - `destination` specifies the account to transfer to, depending on the account type: + - network treasury: leave blank (only one per asset) - party: the party's public key - - network insurance pool: leave blank (there's only one per asset) - market insurance pool: market ID - A proposal can be for a one off transfer or recurring. - If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. From 077cb7fdd347d1762090d668080040348477905c Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 2 Jun 2023 09:22:14 +0100 Subject: [PATCH 094/649] Update protocol/0014-ORDT-order_types.md Co-authored-by: wwestgarth --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 12fa40133..a24497251 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -251,7 +251,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu #### Iceberg Order Execution 1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027) -2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is partially filled , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders thar are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) +2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) 3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) 4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030) 5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) From b4d39c3a98f3cb78281e5255b2904973d69a6f39 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 2 Jun 2023 14:21:18 +0100 Subject: [PATCH 095/649] chore: Update from master (#1719) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * feat: Add new cases, mostly around eth changes during outages. A few extra cases for PUP. * chore: Linting fixes. * fix: More linting issues. * fix: spelling and AC code lint errors * fix: spelling * feat: Clarifying fees paid (or not paid) by post-only orders (#1635) * chore: remove invalid and unimplemented use cases * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport * feat: update FOK MO reduce-only * fix: Add some more cancel order ACs. * Update protocol/0033-OCAN-cancel_orders.md Co-authored-by: Tom * feat: Add a test for checking performance scores when checkpoint rest… (#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces). * feat: Add a test for checking performance scores when checkpoint rest… (#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces). * Update 0069-VCBS-validators_chosen_by_stake.md (#1653) Deleted half an AC as discussed on slack (as the number for the performance score didn't make sense here) * Amend price monitoring ACs (#1660) * refactor: update ACs * chore: tell approbation to leave me alone * chore: try again * refactor: rephrase AC * refactor: clarify * refactor: fix spelling * feat: update datanode spec with functionality to rollback node and functionality to fetch csv files containing network history (#1659) * feat: update datanode spec with functionality to rollback node and functionality to fetch csv files containing network history * fix: spell checker --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * spec: draft for time-based mempool pruning (#1645) * spec: draft for time-based mempool pruning Signed-off-by: Elias Van Ootegem * spec: spelling Signed-off-by: Elias Van Ootegem * Spelling + clarify how block height is determined Signed-off-by: Elias Van Ootegem * spec: add some additional ACs, remove mention of TxV4, clarify that transaction data includes block hash in addition to block height Signed-off-by: Elias Van Ootegem * complete acceptance criteria Signed-off-by: Elias Van Ootegem * fix typo Signed-off-by: Elias Van Ootegem --------- Signed-off-by: Elias Van Ootegem Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * re-word ac * chore: Add decision notes template (#1658) * chore: Add decision notes template Added a decision template based loosely on the [Any Decision Records](https://adr.github.io/madr/) template Also updated some MD linting to allow sibling duplicated header titles and double spacing to make reading easier. * fix: Spelling error * feat: update for distributing remainder of liq fee * fix: correct AC * refactor: address feedback * add spec for current collateral * clarify total margin available * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * add asset file * Add ACs for asset detail dialog and link up with collateral spec * add suggested sort order per account type * fix: 005 AC code link (#1671) * fix: mempool pruning with PoW only * fix: linting errors * refactor: add liquidation price estimate * refactor: add ACs * refactor: another AC * refactor: cosmetic change * Update 0045-DSRC-data_sourcing.md (#1674) * Update 0045-DSRC-data_sourcing.md * Update 0045-DSRC-data_sourcing.md * Wording of timestamp AC --------- Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Barney Mannerings * add spec for current functionality fo fills data grid * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Make notional value of feels a could * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * add clarification on user role for trades during continuos vs auction * fix: typo in ac number * feat: update typo in 0061 * feat: add explaination on ersatz validators * feat: correct typos * feat: typo * Update user-interface/7005-FILL-fills.md * add browser wallet spec as part of approbation set up * chore: fix typo and add browser specs to app.json * chore: add browser wallet to categories, hopefully in the right place * chore: Update 0033-OCAN-cancel_orders.md (#1686) * feat: update BRIE specs (#1654) * feat: update BRIE specs Signed-off-by: Jeremy Letang * chore: update spelling and linting * feat: update BRIE specs Signed-off-by: Jeremy Letang * chore: update spelling and linting * fix: spelling and lint and rebase * fix: spelling --------- Signed-off-by: Jeremy Letang Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * chore: Update cosmic elevator branch from master (#1688) * refactor: let max oi drop during auciton * fix: duplicate AC codes in 0069-VCBS (#1536) (#1537) * Update `cosmicelevator` branch from `master` branch (#1550) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update cosmicelevator branch from master to keep up-to-date (#1560) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * chore: Update cosmicelevator from master branch (#1564) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * chore: Update cosmicelevator branch from master (#1573) * docs: post only orders (#1562) * docs: Adding specs for post-only orders * Update from master (#1602) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md * Update 0069-VCBS-validators_chosen_by_stake.md Added ACs to match the implementation so its codified (i.e., if an Ersatzvalidator drops below ownstake and there's no-one there to replace it, it is not demoted to pending. * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Update acceptance criteria to correctly reflect implementation (#1549) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * fix: update epoch ACs (#1555) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update 0042, LP fee Transfer, Distribution * Add build folder to gitigore The approbation checks in `makefile` use this folder. Make sure it's not checked in. * Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Ignore dictionary Spellcheck creates a dictionary file. Ensure it isn't committed. * Un parallelise clone-sources in makefile The makefile tried to be clever and run all the remote-repo clones for Approbation checks in parallel. Due to my limited makefile skills, the check could run before a clone was finished. Run them in series instead. This also improves the output a little * Add specs param to names and codes in makefile The old behaviour (default paths) should have been deprecated ages ago, but hasn't been. This change makes it provide the same paths as the defaults. * feat: update maker fee transfer account * Update 0069-VCBS-validators_chosen_by_stake.md * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update 0048-DSRI-data_source_internal.md * fix: refactor 0069-VCBS-052 (#1570) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * fix: MD and spelling lint checks * fix: MD and spelling lint errors * fix: update wording for AC 0059-VCBS-016- (#1566) * Update 0062-SPAM-spam_protection.md (#1571) * Update 0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md (#1542) * Update 0011-NP-CLIE-client-interaction-tests.md Added ACs to test static spam protection (wallet doesn't allow you to get banned) * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update 0011-NP-CLIE-client-interaction-tests.md * chore: fix spelling and MD lint checks --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * Update 0011-NP-CLIE-client-interaction-tests.md (#1579) * refactor: clarify AC * fix: adding bound on slippage part of margin * fix: adding bound on slippage part of margin - ACs * chore: lint * chore: format * chore: add ac codes * chore: lint * feat: make it nonlinear * fix: remove obsolete ac * fix: typo * fix: typo from comments Co-authored-by: Tom * fix: code block in list formatting (#1584) * chore: Remove untestable acceptance criteria * feat: add rate limit spec * Update 0057-TRAN-transfers.md (#1588) * Update 0057-TRAN-transfers.md * Update 0057-TRAN-transfers.md * chore: add AC codes * Update 0057-TRAN-transfers.md (#1590) * Update 0069-VCBS-validators_chosen_by_stake.md Added Acs for IssueSignature * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Expand acceptance criteria to make them clear for 0011-NP-CLIE-client-interaction (#1585) * fix: Expand acceptance criteria to make them clear * chore: Fix formatting * fix: Address review comments --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> * feat: Add new PLUP AC for state-sync in protocol upgrade. * feat: add closeout API * chore: tidy up * chore: remove blank line * chore: by more specific about when a client should be banned * feat: update formula line 140 * fix: Add extra cases for various things that might be affected by validators joining and leaving. * fix: Review comments for new ACs. * fix: Satisfy the linter. * refactor: add slippage to orders * refactor: update examples * chore: fix linter issues * refactor: fix typo * refactor: formlise margin level treatment * refactor: amend/add ACs * Update 0042-LIQF-setting_fees_and_rewarding_lps.md (#1598) * Update 0042-LIQF-setting_fees_and_rewarding_lps.md * fix: linting errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: linting error * fix: MD lint and spelling * Update 0069-VCBS-validators_chosen_by_stake.md (#1604) * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * fix: MD linting and spelling errors --------- Co-authored-by: gordsport * Update 0069-VCBS-validators_chosen_by_stake.md (#1596) * Update 0069-VCBS-validators_chosen_by_stake.md * fix: spelling errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: More validator join/leave test cases involving checkpoints. (#1601) * fix: More validator join/leave test cases involving checkpoints. * fix: spelling error * fix: Update AC codes to not be duplicates. --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update make file and add approabtion to CI (#1605) * feat: update make file and add approabtion to CI * chore: add more checks and fix errors * fix: checkout PR branch * fix: get branch * fix: approbation errors --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: Tom Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett * fix: lint errors and duplicate paragraph (#1630) * fix: lint errors and duplicate paragraph * fix: MD lint error * Chore: Update cosmicelevator from master (#1646) * feat: Add new cases, mostly around eth changes during outages. A few extra cases for PUP. * chore: Linting fixes. * fix: More linting issues. * fix: spelling and AC code lint errors * fix: spelling * feat: Clarifying fees paid (or not paid) by post-only orders (#1635) * chore: remove invalid and unimplemented use cases * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport --------- Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Rado Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --------- Co-authored-by: Witold Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: Tom Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett Co-authored-by: Rado Co-authored-by: Michael * fix: fix prefix for browser wallet * chore: fixed wrong file.. * chore: now undo my formatting for the other file * chore: undo formatting change * add missing AC * add more ac * typoe * chore: add ac for the sprint * add ui specs for finding closed markets * fix number sequence * chore: add acs for market selector * chore: added ACs for transaction log * chore: removed navigation AC * add key pair ac that slipped the net via a ticket going straight to the done column * Add UI ACs for network and nodes (#1700) * Update 0002-WCON-connect_vega_wallet.md Removing all coulds, shoulds and would like tos. These are captured here and will be pulled into tickets as applicable later down the line if / when these features are implemented * Update user-interface/0002-WCON-connect_vega_wallet.md Co-authored-by: Penny Andrews <47143694+pennyandrews@users.noreply.github.com> * add settings ac * Update user-interface/1101-BWAL-browser_wallet.md * remove ac for recovery phrase and add new connection and transaction ac when not onboarded * add ac * add and increment * chore: update readme (#1709) Co-authored-by: peterbarrow <62435083+peterbarrow@users.noreply.github.com> * feat: typo * chore(trading): Add transfer ACs * chore(trading): Add transfer ACs number fix * fix(trading): Fix transfer specs ID * Fix: bring ersatz number in line with core. * increment and add ac * format * chore: withdraw minimal amount * Update 1101-BWAL-browser_wallet.md Removed: - It is visually similar to other transaction types but essentially has less of the human readable detail(s) (design note) (1101-BWAL-057) as it is a design note - When I approve a transaction I can see confirmation that the transaction has been approved (1101-BWAL-045) - separate story in backlog - When I reject a transaction I can see confirmation that the transaction has been rejected (1101-BWAL-049) - separate story in backlog * chore:update todo * amend spec numbers --------- Signed-off-by: Elias Van Ootegem Signed-off-by: Jeremy Letang Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Rado Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: Matthew Pendrey Co-authored-by: Elias Van Ootegem Co-authored-by: Charlie Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> Co-authored-by: Matthew Russell Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Barney Mannerings Co-authored-by: daro-maj <119658839+daro-maj@users.noreply.github.com> Co-authored-by: dalebennett1992 Co-authored-by: dalebennett1992 <37066267+dalebennett1992@users.noreply.github.com> Co-authored-by: Jeremy Letang Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: RomanLeca Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: Edd Co-authored-by: claudiumilea Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Penny Andrews <47143694+pennyandrews@users.noreply.github.com> Co-authored-by: Calum Pringle <46783148+ckpringle@users.noreply.github.com> Co-authored-by: peterbarrow <62435083+peterbarrow@users.noreply.github.com> Co-authored-by: Ben Wallace Co-authored-by: m.ray <16125548+MadalinaRaicu@users.noreply.github.com> Co-authored-by: Zohar Etzioni Co-authored-by: asiaznik Co-authored-by: Art Co-authored-by: Dexter Edwards --- README.md | 2 +- ...0012-NP-LIPE-liquidation-price-estimate.md | 2 +- protocol/0019-MCAL-margin_calculator.md | 23 ++-- ...042-LIQF-setting_fees_and_rewarding_lps.md | 7 +- .../0069-VCBS-validators_chosen_by_stake.md | 2 +- spellcheck.sh | 2 +- user-interface/0001-WALL-wallet.md | 27 +++-- .../0002-WCON-connect_vega_wallet.md | 16 --- user-interface/0006-NETW-network-and-nodes.md | 37 +++++- user-interface/1002-WITH-withdraw.md | 21 ++-- user-interface/1003-TRAN-transfer.md | 60 +++++++++- user-interface/1101-BWAL-browser_wallet.md | 108 +++++++++++------- user-interface/6001-MARK-find_markets.md | 41 ++++++- user-interface/README.md | 10 +- user-interface/increment.py | 38 ++++++ 15 files changed, 299 insertions(+), 97 deletions(-) create mode 100644 user-interface/increment.py diff --git a/README.md b/README.md index 79e3209c8..91897eb9c 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ This repository contains specifications and RFCs for future changes to the syste In order to ensure that there is a clear view on the specification of the protocol, both at the version in mainnet and the version being developed in testnet, the following branching is used: - `master` branch details the specification of the protocol in mainnet (from Alpha Mainnet onwards) -- `cosmicelevator` branch is the milestone grouping of features being developed AFTER Alpha Mainnet +- `cosmicelevator` branch is the milestone grouping of features being developed AFTER Alpha Mainnet. As features are deployed to mainnet by the validators the relevant spec changes will be merged into the `master` branch. - Further milestone branches will be created as development progresses and will be updated in this `README.md` To find out more see the [The specification lifecycle](WORKFLOW.md#the-specification-lifecycle) diff --git a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md index 1debadacf..39ce7906e 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -55,6 +55,6 @@ When including orders we sort the orders in the order they will get filled in (d 1. An estimate is obtained for a long position with no open orders, mark price keeps going down in small increments and the actual liquidation takes place within the estimated range. (0012-NP-LIPE-001) 1. An estimate is obtained for a short position with no open orders, mark price keeps going up in small increments and the actual liquidation takes place within the estimated range. (0012-NP-LIPE-002) 1. An estimate is obtained for a position with no open volume and a single limit buy order, after the order fills the mark price keeps going down in small increments and the actual liquidation takes place within the obtained estimated range. (0012-NP-LIPE-003) -1. An estimate is obtained for a long position with multiple limit sell order with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with sell orders is higher than that for the open volume only. As the limit orders get filled the estimated liquidation price for the (updated) open volume converges to the estimate originally obtained with open sell orders. (0012-NP-LIPE-004) +1. An estimate is obtained for a long position with multiple limit sell order with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with sell orders is lower than that for the open volume only. As the limit orders get filled the estimated liquidation price for the (updated) open volume converges to the estimate originally obtained with open sell orders. (0012-NP-LIPE-004) 1. An estimate is obtained for a short position with multiple limit sell order with the absolute value of the total remaining size of the orders less than the open volume. The estimated liquidation price with sell orders is lower than that for the open volume only. As the limit orders get filled the estimated liquidation price for the (updated) open volume converges to the estimate originally obtained with open sell orders. As the price keeps moving in small increments the liquidation happens within the originally estimated range (with sell orders) (0012-NP-LIPE-005) 1. There's no difference in the estimate for an open volume and that with `0` open volume and market order of the same size. (0012-NP-LIPE-006) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 4397d0f02..049ceaec8 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -27,11 +27,11 @@ - If a party is short `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF short = 0.1` and order book is ```book - buy 1 @ 15 000 - buy 10 @ 14 900 + buy 1 @ 15 000 + buy 10 @ 14 900 and sell 1 @ 100 000 - sell 10 @ 100 100 + sell 10 @ 100 100 ``` then the maintenance margin for the party is `15 900 x (0.25 x 1 + 0.25 x 1 x 1) + 0.1 x 1 x 15 900 = 9 540`. (0019-MCAL-011) @@ -106,8 +106,8 @@ In this simple methodology, a linearised margin formula is used to return the ma with ```formula -maintenance_margin_long - = max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) +maintenance_margin_long + = max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + max(open_volume, 0) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ]`, ``` @@ -135,7 +135,7 @@ where - **Short positions** are exited by the system considering what the volume weighted price of **buying** the size of the open short position (not riskiest short position) on the order book (i.e. by buying from the offers (asks) on the order book). If there is no open short position, the slippage per unit is zero. -If there is zero or insufficient order book volume on the relevant side of the order book to calculate the `exit_price`, then take `slippage_per_unit = +Infinity` which means that `min(slippage_volume * slippage_per_unit, mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])) = mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])` above. +If there is zero or insufficient order book volume on the relevant side of the order book to calculate the `exit_price`, then take `slippage_per_unit = +Infinity` which means that `min(slippage_volume * slippage_per_unit, mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])) = mark_price * (slippage_volume * market.maxSlippageFraction[1] + slippage_volume^2 * market.maxSlippageFraction[2])` above. ### **Step 2** @@ -144,14 +144,16 @@ If `riskiest short == 0` then `maintenance_margin_short = 0`. Else ```formula -maintenance_margin_short - = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) +maintenance_margin_short + = max(min(abs(riskiest short) * slippage_per_unit, mark_price * (abs(riskiest short) * market.maxSlippageFraction[1] + abs(slippage_volume)^2 * market.maxSlippageFraction[2])), 0) + abs(min( open_volume, 0 )) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ] + abs(sell_orders) * [ quantitative_model.risk_factors_short ] . [ Product.value(market_observable) ]` ``` where meanings of terms in Step 1 apply except for: -`slippage_per_unit = -1 * (Product.value(market_observable) - Product.value(exit_price) )` + +`slippage_per_unit = -1 * (Product.value(market_observable) - Product.value(exit_price))` + ### **Step 3** @@ -233,7 +235,7 @@ riskiest_short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 slippage_per_unit = Product.value(market_observable) - Product.value(exit_price) = Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10) = 144 - 110 = 34 -maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) +maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + max(open_volume, 0 ) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] = max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 @@ -250,6 +252,7 @@ maintenance_margin = max ( 677.6, 0) = 677.6 collateral_release_level = 677.6 * collateral_release_scaling_factor = 677.6 * 1.1 initial_margin = 677.6 * initial_margin_scaling_factor = 677.6 * 1.2 search_level = 677.6 * search_level_scaling_factor = 677.6 * 1.3 + ``` ### EXAMPLE 2 - calculating correct slippage volume diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index cc4318393..cd68cd174 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -208,6 +208,7 @@ This account is not under control of the LP party (they cannot initiate transfer A network parameter `market.liquidity.providers.fee.distributionTimeStep` will control how often fees are distributed from the LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.distributionTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. + If `market.liquidity.providers.fee.distributionTimeStep` is set to `0` then the balance is distributed either immediately upon collection or at then end of a block. The liquidity fees are distributed pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. @@ -305,11 +306,11 @@ When the time defined by `market.liquidity.providers.fee.distributionTimeStep` e ### Distribution -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the distribution step then they receive roughly 1/2 the fee income compared with the next epoch when they maintain their commitment and that sees the same trade value. (0042-LIQF-018) ### successor market -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-033) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-034) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-033) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-034) - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-035) - If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-036) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 4397a5aaa..5a2e72185 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -112,7 +112,7 @@ Note that this could become obsolete if a future version of the protocol impleme In addition to the normal validators, there is an additional set of Ersatz validators (also referred to as Standby Validators) as defined by the corresponding network parameter. These are validators that do not contribute to the chain, but are on standby to jump in if a normal validator drops off. The network will have -`n' := ceil(network.validators.multipleOfTendermintValidators x network.validators.tendermint.number)` +`n' := floor(network.validators.multipleOfTendermintValidators x network.validators.tendermint.number)` ersatz validators. The value range for the decimal `network.validators.multipleOfTendermintValidators` is `0.0` to `infinity`. diff --git a/spellcheck.sh b/spellcheck.sh index 84df29653..6113819e9 100755 --- a/spellcheck.sh +++ b/spellcheck.sh @@ -10,7 +10,7 @@ brew install aspell echo "Running the spell checker..." -pyspelling --config spellcheck.yaml +python3 -m pyspelling --config spellcheck.yaml echo "Remove dictionary binary..." diff --git a/user-interface/0001-WALL-wallet.md b/user-interface/0001-WALL-wallet.md index 186e0b992..5e7eae84b 100644 --- a/user-interface/0001-WALL-wallet.md +++ b/user-interface/0001-WALL-wallet.md @@ -1,7 +1,7 @@ # Wallet -A Vega wallet is required to prepare and submit transaction on Vega (place, cancel, orders etc). See the [wallet docs](https://docs.vega.xyz/docs/mainnet/concepts/vega-wallet) for more on how "crypto" wallets work. +A Vega wallet is required to prepare and submit transaction on Vega (place, cancel, orders etc). See the [wallet docs](https://docs.vega.xyz/docs/mainnet/concepts/vega-wallet) for more on how "crypto" wallets work. -A wallet can contain many public/private key pairs. The public part of each key pair is known the [Party](../protocol/0017-PART-party.md) sometimes just referred to as a key or public key. +A wallet can contain many public/private key pairs. The public part of each key pair is known the [Party](../protocol/0017-PART-party.md) sometimes just referred to as a key or public key. The primary job(s) of a wallet is to [sign/encrypt transaction](../protocol/0022-AUTH-auth.md) (so the network can be sure they were sent by a given party) and to broadcast these transactions to a node on the network. @@ -48,7 +48,7 @@ When a dapp requests use of a wallet, I... - I can enter wallet passphrase before wallet details are shared (assuming a password has not recently been entered)(0001-WALL-022) - I can retrospectively revoke Dapp's access to a Wallet (0001-WALL-023) -... so that I can control what public keys are shared with a dapp and what dapps can prompt me to sign transactions +... so that I can control what public keys are shared with a dapp and what dapps can prompt me to sign transactions ## Approving transactions When a dapp sends a transaction to the wallet for signing and broadcast, I... @@ -58,18 +58,25 @@ When a dapp sends a transaction to the wallet for signing and broadcast, I... ... so I can verify that the transaction being sent is the one I want -## Transactions +## Transaction log When thinking about a recent or specific transaction, I ... -- I can see a history of transactions the wallet has signed. As read from the local app (Current "session" only, as persistent data storage has other requirements (see commented out ACs)) (0001-WALL-034) -- I can see pending transactions (Transactions I have not yet confirmed/rejected) (0001-WALL-035) -- I can see transactions that were rejected by the wallet user (me) (0001-WALL-037) +- I can find a single list of all transactions, completed and ongoing, from all keys and wallets, from my current desktop session and network (0001-WALL-034) +- I can see transactions that were confirmed by the wallet user (me) (0001-WALL-035) +- I can see transactions that were rejected by the wallet user (me) (0001-WALL-036) +- If I switch network, transactions list changes to show the transactions for that network (0001-WALL-037) +- I can click a transaction in the list to see the transaction details (0001-WALL-038) +- I can see empty state when there are no transactions for this session (0001-WALL-039) -... so that I can ensure my wallet is being used appropriately and find transaction I might have missed +... so that I can ensure my wallet is being used appropriately and find transaction I made -## Transaction detail +## Transaction details when looking at a specific transaction... +- I can see details of specific transactions I opened (0001-WALL-041) +- I can find my way to the transaction on block explorer (0001-WALL-042) +- I can find my way to the complete transaction history for that key on block explorer (0001-WALL-043) + - I can see [status of broadcasted transactions](0003-WTXN-submit_vega_transaction.md#track-transaction-on-network) .. so I can find all the information about what has happened with mined and un-mined transactions @@ -81,7 +88,7 @@ When using a Vega wallet, I... - I can see full public key or be able to copy it to clipboard (0001-WALL-054) - I can change key name/alias (0001-WALL-055) -... so I can manage risk (e.g. isolate margin), mitigate the damage of a key being compromised, or use multiple trading strategies +... so I can manage risk (e.g. isolate margin), mitigate the damage of a key being compromised, or use multiple trading strategies ## Taint keys When protecting myself from use of keys that may be compromised, I.. diff --git a/user-interface/0002-WCON-connect_vega_wallet.md b/user-interface/0002-WCON-connect_vega_wallet.md index eb567b672..455ccb4c6 100644 --- a/user-interface/0002-WCON-connect_vega_wallet.md +++ b/user-interface/0002-WCON-connect_vega_wallet.md @@ -5,15 +5,10 @@ When looking to use Vega via a user interface e.g. Dapp (Decentralized web App), I... - If the app loads and already has a connection it can restore "eagerly" (without the user having to click connect) it **could** do so -- **should** see a link to get a Vega wallet (in case I don't already have one) -- **should** see a link to connect that opens up connection options -- **should** have a way to easily access help should I need to troubleshoot my connection e.g. link to the docs - **must** select a connection method / wallet type: (0002-WCON-002) - if Rest: - **must** have the option to input a non-default Wallet location (0002-WCON-003) - - **should** warn if the dapp is unable the see a wallet is running at the wallet location - **must** submit attempt to connect to wallet (0002-WCON-005) - - **could** trigger the app to open on the user's machine with a `vegawallet://` prompt - if the dapp DOES already have a permission with the wallet: **must** see that wallet is connected (0002-WCON-007) note: if the user want to connect to a different wallet to the one that they were previously connected with, they will have to hit logout. - if the app uses one key at a time: **should** show what key is active (re-use the last active key) (0002-WCON-008) @@ -21,10 +16,6 @@ When looking to use Vega via a user interface e.g. Dapp (Decentralized web App), - if the wallet does NOT have an existing permission with the wallet: **must** prompt user to check wallet app to approve the request to connect wallet: See [Connecting to Dapps](0002-WCON-connect_vega_wallet.md#connect-wallet) for what should happen in wallet app (0002-WCON-009) - if new keys are given permission: **must** show the user the keys have been approved (0002-WCON-010) - - **should** see [public key(s)](DATA-data_display.md#public-keys) - - **should** see alias(es) - - **could** see assets on key(s) - - **would like to** see positions on key(s) - if the dapp uses one key at a time: **should** prompt me to select key. See [select/switch keys](#select-and-switch-keys). (0002-WCON-014) - if user rejects connection: **must** see a message saying that the request to connect was denied (0002-WCON-015) @@ -52,7 +43,6 @@ When wishing to disconnect my wallet, I... - **must** see an option to disconnect wallet (0002-WCON-022) - **must** see confirmation that wallet has been disconnected (0002-WCON-023) -- **should** see prompt to connect a wallet, after disconnect ... so that I can protect my wallet from malicious use or select a different wallet to connect to @@ -66,14 +56,8 @@ when looking to do something with a specific key (or set of keys) from my wallet - for each key: - **must** see the first and last 6 digits of the [public key](DATA-data_display.md#public-keys). (0002-WCON-027) - - **should** be able to see the whole public key - **must** be able to copy to clipboard the whole public key (0002-WCON-029) - **must** see the key name/alias (meta data) (0002-WCON-030) - - **should** see what non-zero assets that key has - - **could** see the total asset balances (including associated) - - **would like to see** a breakdown of the accounts. See [collateral / accounts](6001-COLL-collateral.md) - - **would like to** see any active orders or positions. See [collateral / accounts](6001-COLL-collateral.md) - - **would like to** see my nominations to validators for associated tokens - **must** see the option to trigger a re-authenticate so I can use newly created keys (0002-WCON-035) diff --git a/user-interface/0006-NETW-network-and-nodes.md b/user-interface/0006-NETW-network-and-nodes.md index 50d1cfacc..e6dc3ec3c 100644 --- a/user-interface/0006-NETW-network-and-nodes.md +++ b/user-interface/0006-NETW-network-and-nodes.md @@ -1 +1,36 @@ -# Select network and nodes \ No newline at end of file +# Select network and nodes + +## Startup + +- **Must** automatically select a node from the environments network config stored in the [networks repo](https://github.com/vegaprotocol/networks) ([0006-NETW-001](#0006-NETW-001)) + +## Network switcher + +- **Must** see current network ([0006-NETW-002](#0006-NETW-002)) +- **Must** be able to change network ([0006-NETW-003](#0006-NETW-003)) + +## Node health + +- **Must** see node status + - Operational if node is less than 3 blocks behind ([0006-NETW-004](#0006-NETW-004)) + - Warning if greater than 3 blocks behind ([0006-NETW-005](#0006-NETW-005)) + - Warning if vega time is 3 seconds behind current time ([0006-NETW-006](#0006-NETW-006)) + - Prominent error if vega time is 10 seconds behind current time ([0006-NETW-007](#0006-NETW-007)) +- **Must** see current connected node ([0006-NETW-008](#0006-NETW-008)) +- **Must** see current block height ([0006-NETW-009](#0006-NETW-009)) +- **Must** see block height progressing ([0006-NETW-010](#0006-NETW-010)) +- **Must** see link to status and incidents site ([0006-NETW-011](#0006-NETW-011)) + +## Node switcher + +- **Must** be able to click on current node to open node switcher dialog ([0006-NETW-012](#0006-NETW-012)) +- In the node dialog + - **Must** must see all nodes provided by the [network config](https://github.com/vegaprotocol/networks) ([0006-NETW-013](#0006-NETW-013)) + - For each node + - **Must** see the response time of the node ([0006-NETW-014](#0006-NETW-014)) + - **Must** see the current block height ([0006-NETW-015](#0006-NETW-015)) + - **Must** see if subscriptions are working for that node ([0006-NETW-016](#0006-NETW-016)) + - **Must** be able to select and connect to any node, regardless of response time, block height or subscription status ([0006-NETW-017](#0006-NETW-017)) + - **Must** be able to select 'other' to input a node address and connect to it ([0006-NETW-018](#0006-NETW-018)) + - **Must** have disabled connect button if 'other' is selected but no url has been entered ([0006-NETW-019](#0006-NETW-019)) + - **Must** have disabled connect button if selected node is the current node ([0006-NETW-020](#0006-NETW-020)) diff --git a/user-interface/1002-WITH-withdraw.md b/user-interface/1002-WITH-withdraw.md index bd102784f..8e32188f5 100644 --- a/user-interface/1002-WITH-withdraw.md +++ b/user-interface/1002-WITH-withdraw.md @@ -1,6 +1,6 @@ # Withdraw -Withdrawing funds is a two step process. +Withdrawing funds is a two step process. First the Vega network needs to approve that the funds can be released (not required for margin on open positions or in liquidity bond etc). If they are not, a withdraw is prepared and set aside so that it can not be used for positions etc. This also define what ethereum address will be credited the funds in step 2. @@ -18,12 +18,13 @@ When wishing to withdraw some of an ERC20 asset from Vega, I... Note: It is better to encourage the completion of started withdraws as soon as possible after preparing them. This is because the validator set could theoretically change enough to make the node signatures that authorize the withdrawal invalid. -- **should** be warned that they will need to pay gas on the withdrawal before starting -- **could** show the current gas fees BEFORE preparing the withdrawal (note: shows gas estimate is a general should for all [ethereum transactions](0005-ETXN-submit_ethereum_transaction.md) but this is so a user gets to see the gas costs at step 1 assuming they will do step 2 immediately. ) +- **should** be warned that they will need to pay gas on the withdrawal before starting +- **could** show the current gas fees BEFORE preparing the withdrawal (note: shows gas estimate is a general should for all [ethereum transactions](0005-ETXN-submit_ethereum_transaction.md) but this is so a user gets to see the gas costs at step 1 assuming they will do step 2 immediately. ) Note: A user may want to delay preparing a withdrawal if gas fees on the network are particularly high at the time - **must** select the asset to withdraw (1002-WITH-001) + - **should not** see option to select assets where I a zero [total balance](9001-DATA-data_display.md#asset-balances) (note this should also avoid `Pending` assets from appearing in the list) - **must** see the general balance I have for that asset (1002-WITH-002) - **should** see balances to the full number of decimal places possible for that asset @@ -34,14 +35,19 @@ Note: A user may want to delay preparing a withdrawal if gas fees on the network - **should** have an easy option (link/button) to input the full amount in general balance - **must** be able to specify as many decimal places as the asset supports (1002-WITH-004) - **must** be warned if the amount is greater than general balance (including if the general balance amount changes while the user is looking at the form) (1002-WITH-005) + +- **must** be warned if the amount is lesser than the minimum allowed, where the minimum amount is the selected asset's quantum multiplied by the value of `spam.protection.minimumWithdrawalQuantumMultiple` network parameter (1002-WITH-026) + - **should** see a link to a faucet on the selected asset (only if there is one) - **must** specify the Ethereum address that can claim the withdrawal (e.g. where you are withdrawing too) (1002-WITH-006) + - **should** be able to easily select an Ethereum key the app is already connected to - **should** be able to withdraw to a different Ethereum key to the one the app is connected to - **should** be warned if the input does not look like an ethereum address (wrong number of characters, not starting with 0x etc) - if there is a withdraw delay on the selected asset: + - **should** see how large a withdrawal (or sum of withdrawals) needs to be to hit the `withdraw delay threshold` - **should** see what the withdraw delay is in hours and mins (if hit) - **should** see how much I have withdrawn in the last `withdraw delay period` @@ -51,14 +57,15 @@ Note: A user may want to delay preparing a withdrawal if gas fees on the network - **must** submit a withdraw [vega transaction](0003-WTXN-submit_vega_transaction.md) (1002-WITH-009) - if the preparing the withdraw on Vega fails: + - **must** be directed back to the withdraw form (containing the submitted values) and see an explanation of why the transaction failed, so I can fix and resubmit (1002-WITH-010) - if the preparing the withdraw on Vega is successful: - - **must** see that withdraw is prepared (1002-WITH-011) + - **must** see that withdraw is prepared (1002-WITH-011) - if this withdraw will not hit the withdrawal threshold: - **should** be prompted to complete the transaction on ethereum (see [complete ERC20 withdraw](#complete-erc20-withdraw-from-ethereum-bridge)) - **could** be directed to a list of incomplete withdrawals - - if this withdraw will hit withdrawal threshold: + - if this withdraw will hit withdrawal threshold: - **must** see that the withdraw has been complete and is in the list waiting for the delay to pass (1002-WITH-024) ...so that I can get the details required to release my funds from the the Ethereum ERC20 bridge. @@ -97,7 +104,7 @@ When looking to submit the Ethereum transaction to release funds from the Vega b - **must** see a link to [submit the ethereum transaction to finish withdrawal](0005-ETXN-submit_ethereum_transaction.md) (1002-WITH-019) - **could** be warned if the connected ethereum wallet is different to the one that the withdraw is going to credit (this is permitted but is a good reminder to the user about what to expect) -- if successful: +- if successful: - **must** see asset balances have been updated post withdrawal (1002-WITH-020) - **must** see the list of withdrawals (with updated status) (1002-WITH-021) - **could** see prompt to start another transaction or complete another incomplete one @@ -107,4 +114,4 @@ When looking to submit the Ethereum transaction to release funds from the Vega b - **should** see a link to docs about withdrawals for trouble shooting (e.g. if the signer set has changed significantly since the withdraw was prepared) - **should** see status of incomplete withdrawals (so I can confirm the withdraw I attempted to complete is incomplete) -... so the funds I withdrew from Vega are credited to my Ethereum key \ No newline at end of file +... so the funds I withdrew from Vega are credited to my Ethereum key diff --git a/user-interface/1003-TRAN-transfer.md b/user-interface/1003-TRAN-transfer.md index 9d49b14e6..6ffe0b04a 100644 --- a/user-interface/1003-TRAN-transfer.md +++ b/user-interface/1003-TRAN-transfer.md @@ -1 +1,59 @@ -# Transfer \ No newline at end of file +# Transfer + + +## Transfer Window +- **Must** be able to open transfer window through transfer button under key, account history page and collateral options ([1003-TRAN-001](#1003-TRAN-001)) + +- **Must** be able to close the window with the x ([1003-TRAN-002](#1003-TRAN-002)) + +- **Must** display a message showing obfuscated key that funds will be transferred from ([1003-TRAN-003](#1003-TRAN-003)) + +- **Must** each field has their label. Vega key, Asset, Amount ([1003-TRAN-004](#1003-TRAN-004)) + + +## Vega Key + +- **Must** +if the user has multiple keys they must be able to swap between dropdown and manual entry ([1003-TRAN-005](#1003-TRAN-005)) + +- **Must** +if the user has multiple keys they must be able to select from their list of keys([1003-TRAN-006](#1003-TRAN-006)) + +## Asset +- **Must** display a drop down with all assets in the portfolio ([1003-TRAN-007](#1003-TRAN-007)) + +- **Must** the holdings of each asset is displayed ([1003-TRAN-008](#1003-TRAN-008)) + +- **Must** i can select any available assets and selected asset is displayed ([1003-TRAN-009](#1003-TRAN-009)) + +- **Must** selected asset shortname is displayed in the amount field ([1003-TRAN-010](#1003-TRAN-010)) + + +## Validation +- **Must** cannot choose amount over current collateral. Message is displayed ([1003-TRAN-011](#1003-TRAN-011)) + +- **Must** display "required" message on each field if left blank when clicking button "Confirm Transfer" ([1003-TRAN-012](#1003-TRAN-012)) + +- **Must** display "Invalid vega key" message on Vega Key field if entered key doesn't pass validation([1003-TRAN-013](#1003-TRAN-013)) + +- **Must** "Value below minimum" message is shown if amount is lower than minimum([1003-TRAN-014](#1003-TRAN-014)) + + +## Transfer +- **Must** can select include transfer fee ([1003-TRAN-015](#1003-TRAN-015)) + +- **Must** display tooltip for "Include transfer fee" when hovered over.([1003-TRAN-016](#1003-TRAN-016)) + +- **Must** display tooltip for "Transfer fee when hovered over.([1003-TRAN-017](#1003-TRAN-017)) + +- **Must** display tooltip for "Amount to be transferred" when hovered over.([1003-TRAN-018](#1003-TRAN-018)) + +- **Must** display tooltip for "Total amount (with fee)" when hovered over.([1003-TRAN-019](#1003-TRAN-019)) + +- **Must** amount to be transferred and transfer fee update correctly when include transfer fee is selected ([1003-TRAN-020](#1003-TRAN-020)) + +- **Must** total amount with fee is correct with and without "Include transfer fee" selected ([1003-TRAN-021](#1003-TRAN-021)) + +- **Must** i cannot select include transfer fee unless amount is entered ([1003-TRAN-022](#1003-TRAN-022)) + +- **Must** With all fields entered correctly, clicking "confirm transfer" button will start transaction([1003-TRAN-023](#1003-TRAN-023)) \ No newline at end of file diff --git a/user-interface/1101-BWAL-browser_wallet.md b/user-interface/1101-BWAL-browser_wallet.md index e00d6c484..4418f6953 100644 --- a/user-interface/1101-BWAL-browser_wallet.md +++ b/user-interface/1101-BWAL-browser_wallet.md @@ -14,58 +14,57 @@ As a browser wallet user I want to create a password for my browser wallet app S - When I have submitted my new password, I am given some feedback that it was set successfully (1101-BWAL-008) - When I have submitted my new password, I am taken to the next step (1101-BWAL-009) - When I have submitted my new password, I can NOT go back to the previous step (1101-BWAL-010) +- After setting a password, my wallets are encrypted (1101-BWAL-011) ## Create or import wallet As a browser wallet user I want to decide whether to create a new wallet or import an existing one So that I understand my options and don't waste time creating a new wallet when I already created one elsewhere -- I can choose to create a wallet (1101-BWAL-011) -- I can choose to import an existing wallet (1101-BWAL-012) +- I can choose to create a wallet (1101-BWAL-012) +- I can choose to import an existing wallet (1101-BWAL-013) ## Create wallet and key pair As a browser wallet user When I am using the browser wallet for the first time I want to create a new wallet (and key pair) So that I can get started using Console / another Vega dapp to trade / take part in governance - -- I am provided with a recovery phrase for my new wallet that is initially hidden from view(1101-BWAL-013) -- I can see an explanation of what the recovery phrase is for and that it cannot be recovered itself (1101-BWAL-014) -- I can choose when to reveal/show the recovery phrase (1101-BWAL-015) -- I can copy the recovery phrase into my clipboard (1101-BWAL-016) -- I can verify that I understand that Vega doesn't store and therefore can't recover this recovery phrase if I lose it (1101-BWAL-017) -- I am given feedback that my wallet was successfully created (1101-BWAL-018) -- I am redirected to the next step - opt in to error reporting (1101-BWAL-019) -- The new Wallet name and key pair are auto generated in the background "Wallet" "Vega Key 1" (1101-BWAL-020) -- When I have already created a wallet, I am redirected to the landing page where I can view that wallet (rather than the onboarding flow) (1101-BWAL-021) +- I am provided with a recovery phrase for my new wallet that is initially hidden from view(1101-BWAL-014) +- I can see an explanation of what the recovery phrase is for and that it cannot be recovered itself (1101-BWAL-015) +- I can choose when to reveal/show the recovery phrase (1101-BWAL-016) +- I can copy the recovery phrase into my clipboard (1101-BWAL-017) +- I can verify that I understand that Vega doesn't store and therefore can't recover this recovery phrase if I lose it (1101-BWAL-018) +- I am given feedback that my wallet was successfully created (1101-BWAL-019) +- I am redirected to the next step - opt in to error reporting (1101-BWAL-020) +- The new Wallet name and key pair are auto generated in the background "Wallet" "Vega Key 1" (1101-BWAL-021) +- When I have already created a wallet, I am redirected to the landing page where I can view that wallet (rather than the onboarding flow) (1101-BWAL-022) ## Confirm recovery phrase As a wallet user I want to validate I have "recorded" or saved the recovery phrase accurately So that I feel secure and confident to go ahead -- I can confirm I have written down / saved my recovery phrase by entering parts of it again in the UI(1101-BWAL-022) -- There is a way to go back to see the full recovery phrase if I have written / saved it incorrectly (1101-BWAL-023) -- I can click to continue to the next step of onboarding once I've successfully entered the relevant parts of the phrase (1101-BWAL-024) -- There is a way to understand if the details I've entered are incorrect e.g. highlight in red (1101-BWAL-025) +- I can confirm I have written down / saved my recovery phrase by entering parts of it again in the UI(1101-BWAL-023) +- There is a way to go back to see the full recovery phrase if I have written / saved it incorrectly (1101-BWAL-024) +- I can click to continue to the next step of onboarding once I've successfully entered the relevant parts of the phrase (1101-BWAL-025) +- There is a way to understand if the details I've entered are incorrect e.g. highlight in red (1101-BWAL-026) ## View network connected to As a browser wallet user I want to know which vega network my browser wallet is connected to So that I know if I am on the network I expect to be, and whether I am transacting with real or fake assets -- The browser wallet defaults to use the Fairground network (1101-BWAL-026) -- I can see which vega network the browser wallet is connected to from everywhere in the app(1101-BWAL-027) +- The browser wallet defaults to use the Fairground network (1101-BWAL-027) +- I can see which vega network the browser wallet is connected to from the view wallet page(1101-BWAL-028) ## Create key pairs As a wallet user I want to be able to create multiple key pairs in my wallet So that I can use different keys for different -- I can create a new key pair from the wallet view (1101-BWAL-028) -- New key pairs are assigned a name automatically "Vega Key 1" "Vega Key 2" etc.(1101-BWAL-029) -- New key pairs are listed in order they were created - oldest first(1101-BWAL-030) +- I can create a new key pair from the wallet view (1101-BWAL-029) +- New key pairs are assigned a name automatically "Vega Key 1" "Vega Key 2" etc.(1101-BWAL-030) +- New key pairs are listed in order they were created - oldest first(1101-BWAL-031) ## Remember where I am in the onboarding flow As a browser wallet user When I have started onboarding in the browser wallet and I close the extension / browser I want to be able to reopen the extension and it remember where I was in the onboarding flow So that I don't have to start again -- I can close the extension and when I reopen it it opens on the same page / view (1101-BWAL-031) -- When I reopen the extension after last viewing the recovery phrase and hadn't yet acknowledged and moved to the next step, it opens on the recover phrase step with the recovery phrase hidden(1101-BWAL-032) +- I can close the extension and when I reopen it it opens on the same page / view (1101-BWAL-032) ## Connect all key(s) only @@ -79,40 +78,71 @@ As a wallet user I want to connect my key(s) to a dapp So that I can verify tran - There is a way to understand that i.e. this connection request gives access to ALL my keys now and in the future (1101-BWAL-038) - When I go away from the extension and come back to the connected site, the browser extension remembers the connection and does not ask me to reconnect (1101-BWAL-039) - There is a visual way to understand that a connection has been successful(1101-BWAL-040) +- If I did not have the browser wallet open when I instigated the connection request, the browser wallet "closes" after approving (connect) or rejecting (deny) the connection request (1101-BWAL-041) +- If the had the browser wallet open when I instigated the connection request, the browser wallet returns your view to where you were before the request came in (1101-BWAL-042) +- When I try to connect to the wallet I've made during onboarding but have not "completed" onboarding, I cannot see the connection request until I've completed onboarding (it is queued in the background) (1101-BWAL-043) ## Approve transaction request As a browser wallet user I want to be able to approve a transaction request So that I can verify and complete the action I am trying to make on the vega dapp I'm using -- When I view a transaction request I can choose to approve it (1101-BWAL-041) -- When I approve a transaction I can see confirmation that the transaction has been approved (1101-BWAL-042) -- When I approve a transaction the transaction gets signed and the approved status gets fed back to the dapp that requested it (1101-BWAL-043) -- When I approve a transaction after I have approved it we revert to the next transaction if there's a queue OR we revert to the key view (the front / homepage) (1101-BWAL-044) +- When I view a transaction request I can choose to approve it (1101-BWAL-044) +- When I approve a transaction the transaction gets signed and the approved status gets fed back to the dapp that requested it (1101-BWAL-045) +- When I approve a transaction after I have approved it we revert to the next transaction if there's a queue OR we revert to the key view (the front / homepage) (1101-BWAL-046) ## Reject transaction request As a browser wallet user I want to be able to reject a transaction request So that I can prevent a transaction going through that I don't recognise as mine, or have changed my mind on / identified a mistake etc. -- When I view a transaction request I can choose to reject it(1101-BWAL-045) -- When I reject a transaction I can see confirmation that the transaction has been rejected (1101-BWAL-046) -- When I reject a transaction the transaction does not get signed and the rejected status gets fed back to the dapp that requested it (1101-BWAL-047) -- When I reject a transaction after I have rejected it we revert to the next transaction if there's a queue OR we revert to the key view (start / home page) (1101-BWAL-048) +- When I view a transaction request I can choose to reject it(1101-BWAL-047) +- When I reject a transaction the transaction does not get signed and the rejected status gets fed back to the dapp that requested it (1101-BWAL-048) +- When I reject a transaction after I have rejected it we revert to the next transaction if there's a queue OR we revert to the key view (start / home page) (1101-BWAL-049) ## View trasaction request (generic) As a user I want to recognise transactions that are not orders or withdraw / transfer requests with at least the bear minimum information needed to proceed So that I can continue my task (e.g. governing, staking) -- When the dapp requests a transaction with a key we don't know about, we don't see a request in the wallet but instead send an error back to the dapp(1101-BWAL-049) -- When the dapp requests a transaction type / or includes transaction details that we don't recognise, we don't present the transaction request in the wallet but provide an error to the dapp that feeds back that the transaction can not be processed (1101-BWAL-050) -- When the user opens the extension (or it has automatically opened) they can immediately see a transaction request (1101-BWAL-051) -- If the browser extension is closed during a transaction request, the request persists (1101-BWAL-052) -- For transactions that are not orders or withdraw / transfers, there is a standard template with the minimum information required i.e. (1101-BWAL-053) -- [ ] Transaction title -- [ ] Where it is from e.g. console.vega.xyz with a favicon -- [ ] The key you are using to sign with a visual identifier -- [ ] When it was received -- [ ] Raw JSON details -- It is visually similar to other transaction types but essentially has less of the human readable detail(s) (design note) (1101-BWAL-054) +- When the dapp requests a transaction with a key we don't know about, we don't see a request in the wallet but instead send an error back to the dapp(1101-BWAL-050) +- When the dapp requests a transaction type / or includes transaction details that we don't recognise, we don't present the transaction request in the wallet but provide an error to the dapp that feeds back that the transaction can not be processed (1101-BWAL-051) +- When the user opens the extension (or it has automatically opened) they can immediately see a transaction request (1101-BWAL-052) +- If the browser extension is closed during a transaction request, the request persists (1101-BWAL-053) +- For transactions that are not orders or withdraw / transfers, there is a standard template with the minimum information required i.e. (1101-BWAL-054) + -- [ ] Transaction title + -- [ ] Where it is from e.g. console.vega.xyz with a favicon + -- [ ] The key you are using to sign with a visual identifier + -- [ ] When it was received + -- [ ] Raw JSON details - I can copy the raw json to my clipboard (1101-BWAL-055) +- When I try to submit a transaction to the wallet I've made during onboarding but have not "completed" onboarding, I cannot see the transaction request until I've completed onboarding (it is queued in the background) (1101-BWAL-056) ## Log in (next time password expires) As a wallet user I want a way to enter my password when my login has expired So that I can continue with my task -- When I have quit my browser, and then reopened, I am asked to enter my browser extension password(1101-BWAL-056) -- I am informed if I enter my password incorrectly (1101-BWAL-057) +- When I have quit my browser, and then reopened, I am asked to enter my browser extension password(1101-BWAL-057) +- I am informed if I enter my password incorrectly (1101-BWAL-058) +- When entering a correct password decrypts my wallets (1101-BWAL-059) + +## View wallet and key pairs + +As a browser wallet user I want to view my vega wallet (and key pair(s)) So that I can see that I've been successful creating the wallet / see my key ID + +- I can see a list of the keys in my wallet (1101-BWAL-060) +- I can copy the public key ID to my clipboard (1101-BWAL-061) +- I can see information of where to go to deposit and manage my assets (1101-BWAL-062) +- I can see where I am in the app when viewing my wallet and key pair(s) (1101-BWAL-063) + +## Wallet version number (Settings) + +As a wallet user I want to understand the version # I am using So that I can trouble shoot should there be any issues + +- I can see the version # of the browser extension (1101-BWAL-064) +- I can see the feedback link (1101-BWAL-065) +- I can see a lock button and when I press it I am logged out and redirected to the login page (1101-BWAL-066) + +## Coming back to the app after onboarding + +As a user I want to see my wallet / keys immediately when I open my extension (and not onboarding again) So that I don't need to repeat onboarding unnecessarily and continue my task easily... + +- There is a way to determine if user has onboarded (1101-BWAL-067) +- I want to see the previous page I was on or my wallet page by default (1101-BWAL-068) \ No newline at end of file diff --git a/user-interface/6001-MARK-find_markets.md b/user-interface/6001-MARK-find_markets.md index 6eef2ecbf..ace1dc823 100644 --- a/user-interface/6001-MARK-find_markets.md +++ b/user-interface/6001-MARK-find_markets.md @@ -1 +1,40 @@ -# Find markets \ No newline at end of file +# Find markets + +## Closed Markets + +- **Must** see market's instrument code (6001-MARK-001) +- **Must** see market's instrument name (sometimes labelled 'description') (6001-MARK-002) +- **Must** see status (6001-MARK-003) +- **Must** see the settlement date (6001-MARK-004) + - **Must** use `marketTimestamps.closed` field if market is indeed closed (6001-MARK-005) + - **Must** fallback to using the `settlement-expiry-date:` if market is not fully settled but trading is terminated (6001-MARK-006) + - **Must** indicate if the date shown is 'expected' (metadata value) or if it is the true closed datetime (`marketTimestamps.closed`) (6001-MARK-007) + - **Must** show the date formatted for the user's locale (6001-MARK-008) + - **Must** link to the trading termination oracle spec (6001-MARK-009) + - **Could** show the settlement date as words relative to now (E.G. '2 days ago') (6001-MARK-010) +- **Must** show the last best bid price (6001-MARK-011) +- **Must** show the last best offer price (6001-MARK-012) +- **Must** show the final mark price (6001-MARK-013) +- **Must** show the settlement price (6001-MARK-014) + - **Must** link to the settlement data oracle spec (6001-MARK-015) + - **Must** retrieve settlement data from corresponding oracle spec (6001-MARK-016) +- **Could** show current connected user's PNL for that market (6001-MARK-017) +- **Must** show the settlement asset (6001-MARK-018) + - **Must** be able to view full asset details (6001-MARK-019) +- **Must** provide a way to copy the market ID (6001-MARK-020) + +## Market Selector + +- **Must** see market's instrument code (6001-MARK-021) +- **Must** see market's instrument name (sometimes labelled 'description') (6001-MARK-022) +- **Must** see 24hr price change (6001-MARK-023) +- **Must** see current price (6001-MARK-024) +- **Must** price movements over last 24hr (sparkline) (6001-MARK-025) +- **Must** be linked to all markets page (6001-MARK-026) +- **Must** be able to filter by product type (6001-MARK-027) +- **Must** be able to filter by settlement asset (6001-MARK-028) +- **Must** be able to search by instrument code and instrument name (6001-MARK-029) +- **Must** be able to sort + - by top gaining market (6001-MARK-030) + - by top losing market (6001-MARK-031) + - by newest markets (opening timestamp) (6001-MARK-032) diff --git a/user-interface/README.md b/user-interface/README.md index fe6e03d80..028962890 100644 --- a/user-interface/README.md +++ b/user-interface/README.md @@ -26,13 +26,13 @@ These files contain generic user needs for interacting with wallets that are tru - `0003-WTXN` [Submit Vega transaction](0003-WTXN-submit_vega_transaction.md) - `0004-EWAL` [Connect Ethereum wallet to a Dapp](0004-EWAL-connect_ethereum_wallet.md) - `0005-ETXN` [Submit Ethereum transaction](0005-ETXN-submit_ethereum_transaction.md) -- `0006-NETW` [Network and node selection](0006-NETW-network-and-nodes.md) `TODO` +- `0006-NETW` [Network and node selection](0006-NETW-network-and-nodes.md) ## `1000` Bridges, Transfers and Vesting - `1001-DEPO` [Deposit](1001-DEPO-desposit.md) - `1002-WITH` [Withdraw](1002-WITH-withdraw.md) -- `1003-TRAN` [Transfer](1003-TRAN-transfer.md) `TODO` +- `1003-TRAN` [Transfer](1003-TRAN-transfer.md) - `1004-ASSO` [Associate governance token with a Vega key](1004-ASSO-associate.md) - `1005-VEST` [View and redeem vested tokens](1005-VEST-vesting.md) @@ -64,7 +64,7 @@ These files contain generic user needs for interacting with wallets that are tru ## `6000` Markets and analysis -- `6001-MARK` [Find markets](6001-MARK-find_markets.md) `TODO` +- `6001-MARK` [Find markets](6001-MARK-find_markets.md) - `6002-MARD` [View market specification](6002-MDET-market-details.md) `TODO` - `6003-ORDB` [Analyze Order book](6003-ORDB-order_book.md) `TODO` - `6004-PHIS` [Analyze price history](6004-PHIS-price_history.md) `TODO` @@ -72,11 +72,11 @@ These files contain generic user needs for interacting with wallets that are tru ## `7000` Collateral, Orders, Positions and Fills -- `7001-COLL` [View my collateral / accounts](7001-COLL-collateral.md) `TODO` +- `7001-COLL` [View my collateral / accounts](7001-COLL-collateral.md) - `7002-SORD` [Submit an order](7002-SORD-submit_orders.md) - `7003-MORD` [Manage my orders](7003-MORD-manage_orders.md) - `7004-POSI` [View my positions](7004-POSI-positions.md) `TODO` -- `7005-FILL` [View my trades/fills](7005-FILL-fills.md) `TODO` +- `7005-FILL` [View my trades/fills](7005-FILL-fills.md) - `7006-FEES` [View my trading fees](7006-FEES-fees.md) `TODO` ## `8000` Understand transactions and blocks diff --git a/user-interface/increment.py b/user-interface/increment.py new file mode 100644 index 000000000..fa44b9a56 --- /dev/null +++ b/user-interface/increment.py @@ -0,0 +1,38 @@ +import re + +def increment_spec_numbers(filepath, number): + with open(filepath, 'r+') as file: + content = file.read() + lines = content.splitlines() + + # Find the line containing the given number + for i, line in enumerate(lines): + match = re.search(rf'(\bBWAL-){number}\b', line) + if match: + start_index = match.start() + break + else: + print(f"Number {number} not found in the file.") + return + + # Increment the numbers from the given number onwards + for i in range(i, len(lines)): + line = lines[i] + matches = re.findall(r'(\bBWAL-)(\d{3})\b', line) + for prefix, next_number in matches: + if next_number >= number: + incremented_number = str(int(next_number) + 1).zfill(3) + line = line.replace(f'{prefix}{next_number}', f'{prefix}{incremented_number}') + lines[i] = line + + file.seek(0) + file.write('\n'.join(lines)) + file.truncate() + + print(f"Numbers starting from {number} have been incremented.") + + +# Example usage +filepath = './user-interface/1101-BWAL-browser_wallet.md' +number = '060' +increment_spec_numbers(filepath, number) From b8599455ddf1a6106acfb4f283aa1f3076167986 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 2 Jun 2023 14:43:45 +0100 Subject: [PATCH 096/649] fix: auction icebergs --- protocol/0014-ORDT-order_types.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index a24497251..ddaa36e6c 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -157,7 +157,8 @@ This is allowed because the order will lose time priority on refresh, i.e. befor * Icebergs can be entered or carried into auctions if the underlying TIF is supported. -* Icebergs can trade in the auction uncrossing up to their current `displayed quantity` as for any other transaction that would cause a trade with an iceberg order. +* Icebergs can trade in the auction uncrossing up to their full `remaining` amount as for any other transaction that would cause a trade with an iceberg order. +If the remainders of multiple icebergs sit at the same price and are not fully used up, the traded volume should be split between them pro-rata by their total total size. Any integer remainder should be allocated to the iceberg with the highest time priority. * Icebergs are refreshed after an auction uncrossing if they traded to below their `minimum peak size`, according to the same rules as for normal execution. From e6d31455a6af0b4181aba972dfb5431dcbae8cb2 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 2 Jun 2023 16:24:58 +0100 Subject: [PATCH 097/649] fix: markdown liniting and AC code duplication --- ...042-LIQF-setting_fees_and_rewarding_lps.md | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 5be0a7604..b0a854f08 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -373,14 +373,13 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) - - -### Successor market +### Successor markets - If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-048) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-048) +- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) - If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) +- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-036) ### Calculating SLA Performance @@ -396,7 +395,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - When `market.liquidity.performanceHysteresisEpochs = 0`: - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch(0042-LIQF-036) + - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - When `market.liquidity.performanceHysteresisEpochs = n`: @@ -411,11 +410,3 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) - With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) - -### Successor markets - -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-033) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-034) -- If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-035) -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-036) - From 05b8dd7adfdbcedccdd10c09292d959ff3e5610b Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 5 Jun 2023 17:09:22 +0200 Subject: [PATCH 098/649] refactor: Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f5cd6d644..7641db534 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -118,7 +118,7 @@ If they do not have sufficient collateral the transaction is rejected in entiret _Case:_ `proposed-commitment-variation < 0` We to calculate how much the LP can reduce commitment without incurring a penalty. -To do this we first evaluate the maximum amount that the market can reduce without penalty by given the current liquidity demand in the market. +To do this we first evaluate the maximum amount that the market can reduce without penalty given by the current liquidity demand in the market. `maximum-penalty-free-reduction-amount = total_stake - target_stake` From ce652e5f00da593a6665b632e6afd89edfaae4c4 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 5 Jun 2023 17:44:04 +0200 Subject: [PATCH 099/649] refactor: apply (some) suggestions from code review Co-authored-by: Barnaby M --- protocol/0014-ORDT-order_types.md | 2 +- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index ddaa36e6c..85a5b0d00 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -167,7 +167,7 @@ If the remainders of multiple icebergs sit at the same price and are not fully u * The fields `displayed quantity`, `remaining`, `quantity`, `initial peak size`, `minimum peak size`, `refresh policy` must be exposed by data node APIs in addition to all normal fields for an order. -* An iceberg order refresh must generate an event bus event. +* An iceberg order refresh must generate an event of the event bus. ### Valid order entry combinations diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index b0a854f08..e09bf6d86 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -364,7 +364,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - An LP joining a market that is above the target stake with a commitment large enough to push one of two higher bids above the target stake, and a higher fee bid than the current fee: the fee doesn't change (0042-LIQF-024) - An LP leaves a market that is above target stake when their fee bid is currently being used: fee changes to fee bid by the LP who takes their place in the bidding order (0042-LIQF-025) - An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size changes the LP that meets the target stake: fee changes to fee bid by the LP that is now at the place in the bid order to provide the target stake (0042-LIQF-026) -- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used and their commitment size doesn't the LP that meets the target stake: fee doesn't change (0042-LIQF-027) +- An LP leaves a market that is above target stake when their fee bid is lower than the one currently being used. The loss of their commitment doesn't change which LP meets the target stake: fee doesn't change (0042-LIQF-027) - An LP leaves a market that is above target stake when their fee bid is higher than the one currently being used: fee doesn't change (0042-LIQF-028) ### API From 732abe3b93d0b81f213933ad5326b20fcf30b641 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 5 Jun 2023 20:29:18 +0200 Subject: [PATCH 100/649] refactor: apply remaining suggestions from code review --- protocol/0035-LIQM-liquidity_monitoring.md | 4 ++-- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ---- protocol/0044-LIME-lp_mechanics.md | 12 ++++++------ 3 files changed, 8 insertions(+), 12 deletions(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index e4ef34d02..2101c24d9 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -39,9 +39,9 @@ If an incoming order would match orders on the book resulting in trades increasi ### Decreasing supplied stake -If the [liquidity provision transaction would decrease](./0044-LIME-lp_mechanics.md#liquidity-provider-proposes-to-amend-commitment-amount) `supplied_stake` so that liquidity auction gets triggered then a liquidity auction is triggered the next time the next time conditions for liquidity auctions are evaluated. +If the [liquidity provision transaction would decrease](./0044-LIME-lp_mechanics.md#liquidity-provider-proposes-to-amend-commitment-amount) `supplied_stake` so that liquidity auction gets triggered then a liquidity auction is triggered the next time conditions for liquidity auctions are evaluated. -If the `supplied_stake` decreases as a result of a closeout of an insolvent liquidity provider, then closeout should proceed and market should go into liquidity auction the next time the next time conditions for liquidity auctions are evaluated. +If the `supplied_stake` decreases as a result of a closeout of an insolvent liquidity provider, then closeout should proceed and market should go into liquidity auction the next time conditions for liquidity auctions are evaluated. ## Trigger for exiting the auction diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index e09bf6d86..99bebdee4 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -265,11 +265,9 @@ Let $s$ be `market.liquidity.commitmentMinTimeFraction`. Let $c$ be `market.liquidity.slaCompetitionFactor`. -```text $$ p_i = (1 - \frac{t - s}{1 - s}) \cdot c. $$ -``` #### Calculating the SLA performance penalty for over hysteresis period @@ -278,11 +276,9 @@ Now, for each LP $i$ take the $p_i$ values calculated over the last `market.liqu Now calculate $p_i^n$ to be the arithmetic average of $p_i^k$ for $k = 1,2,...,n-1$. Finally set -```text $$ p_i^n \leftarrow \max(p_i,p_i^n). $$ -``` i.e. your penalty is the bigger of current epoch and average over the hysteresis period diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 7641db534..85fe7bc11 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -30,7 +30,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. -- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often LP the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. +- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. - `market.liquidity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. @@ -136,7 +136,7 @@ penalty-incuring-reduction-amount = -1 * proposed-commitment-variation - maximum ``` Transfer `maximum-penalty-free-reduction-amount` to their general account. -Now transfer `min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to their general account and transfer `market.liquidity.earlyExitPenalty x penalty-incuring-reduction-amount` to the market insurance pool. +Now transfer `min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to their general account and transfer `market.liquidity.earlyExitPenalty x min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to the market insurance pool. Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire `proposed-commitment-variation` as the `delta`. Note that as a consequence the market may land in a liquidity auction the next time the next time conditions for liquidity auctions are evaluated (but there is no need to tie the event of LP reducing their commitment to an immediate liquidity auction evaluation). @@ -161,7 +161,7 @@ When calculating fees for a trade, the size of a liquidity provider’s commitme ### Calculating liquidity from commitment -Committed Liquidity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below. +Committed Liquidity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below on both sides of the order book. The multiple is controlled by a network parameter `market.liquidity.stakeToCcyVolume`: @@ -177,7 +177,7 @@ If there is no mid price then no LP is meeting their committed volume of notiona If there is mid price then we calculate the volume of notional that is in the range ```text -(1.0-market.liquidity.priceRange) x mid =< price levels that count <= (1+market.liquidity.priceRange)x mid. +(1.0-market.liquidity.priceRange) x mid <= price levels <= (1+market.liquidity.priceRange)x mid. ``` If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. @@ -187,7 +187,7 @@ If this is greater than or equal to `liquidity_required` then the LP is meeting We calculate the volume of notional that is in the range ```text -(1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) =< price levels that count <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). +(1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) <= price levels <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). ``` If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. @@ -261,7 +261,7 @@ If, at the end of an epoch (and before any LP rewards and penalties were applied ## What data do we keep relating to liquidity provision? -1. List of all liquidity providers and their commitment sizes and their “equity-like share” for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) +1. List of all liquidity providers and their commitment sizes, their “equity-like share” and "liquidity score" for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) 1. New account per market holding all committed liquidity provider bonds 1. Actual amount of liquidity supplied (can be calculated from order book, [see 0034-prob-weighted-liquidity-measure](./0034-PROB-prob_weighted_liquidity_measure.ipynb)) 1. Each liquidity provider's actual bond amount (i.e. the balance of their bond account) From 3823d278778e08f26fdb0677cdab92dc1367d974 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 09:03:31 +0200 Subject: [PATCH 101/649] refactor: cosmetic changes + spellcheck exclusion --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 5 ----- wordlist.txt | 1 + 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 99bebdee4..aaec07a62 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -258,7 +258,6 @@ For any LP where `fraction_of_time_on_book < market.liquidity.commitmentMinTimeF For each LP where `fraction_of_time_on_book ≥ market.liquidity.commitmentMinTimeFraction`, the SLA penalty fraction `p_i` is calculated as follows: - Let $t$ be `fraction_of_time_on_book` Let $s$ be `market.liquidity.commitmentMinTimeFraction`. @@ -290,11 +289,9 @@ If for all $i$ (all the LPs) have $p_i^n = 1$ then all the fees go into the mark Calculate -```text $$ w_i = \frac{\text{LP-per-market fee account } i}{\sum_k \text{LP-per-market fee account } k}. $$ -``` For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". @@ -302,11 +299,9 @@ Transfer all unpaid-out rewards left in LP-per-market fee accounts into a tempor Record its balance to be $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. -```text $$ b_i \leftarrow \frac{b_i}{\sum_k b_k}\,. $$ -``` Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". diff --git a/wordlist.txt b/wordlist.txt index a7b63313d..98bd9262a 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -138,6 +138,7 @@ keypair keypairs keystore KMS +leftarrow lifecycle linearised linkings From 0c1205dddbc60c2d68970f09c9ed559a7e351930 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 09:09:37 +0200 Subject: [PATCH 102/649] refactor: add pegged AC --- protocol/0014-ORDT-order_types.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 85a5b0d00..0aafb36f8 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -210,6 +210,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu * Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) * A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) * No party can submit a [network order type](#network-orders) (0014-ORDT-006) +* A pegged order (including iceberg pegged orders) never has it's price updated during the execution of an incoming aggressive order (even as price levels get consummed so that it's reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's From fc822662867583afd368cc06ad2af5dc3a6859e8 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 6 Jun 2023 09:47:56 +0100 Subject: [PATCH 103/649] feat: successor markets --- ...5-INSR-market_insurance_pool_collateral.md | 2 +- protocol/0028-GOVE-governance.md | 19 +---- protocol/0043-MKTL-market_lifecycle.md | 8 +- protocol/0081-SUCM-successor_markets.md | 82 +++++++++++++++++++ 4 files changed, 89 insertions(+), 22 deletions(-) create mode 100644 protocol/0081-SUCM-successor_markets.md diff --git a/protocol/0015-INSR-market_insurance_pool_collateral.md b/protocol/0015-INSR-market_insurance_pool_collateral.md index fc0974e2b..0531ab811 100644 --- a/protocol/0015-INSR-market_insurance_pool_collateral.md +++ b/protocol/0015-INSR-market_insurance_pool_collateral.md @@ -19,5 +19,5 @@ When a market is finalised / closed remaining funds are distributed equally amon ## Acceptance Criteria - When a market proposal gets accepted and the opening auction commences, there is an insurance account that is available for use by that market for the settlement asset of that market and its balance is zero. (0015-INSR-001) -- After the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), and `network.liquidity.successorLaunchWindowLength` has elapsed from the settlement time, the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) +- After the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), and `market.liquidity.successorLaunchWindowLength` has elapsed from the settlement time, the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) - The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 68ee5e11d..2cba0ec58 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -221,23 +221,8 @@ A proposal to create a market contains 1. a complete market specification as per the [Market Framework](./0001-MKTF-market_framework.md) that describes the market to be created. 1. an enactment time that is at least the _minimum auction duration_ after the vote closing time (see [auction spec](./0026-AUCT-auctions.md)) -1. if the market is meant to be a _successor_ of a given market then it contains the `marketID` of the market it's succeeding (parent market), a parameter called `insurancePoolFraction` which is a decimal in `[0,1]` (i.e. it can be `0` or `1` or anything in between) and certain entries in the market proposal must be identical to those of the market it's succeeding OR the proposal should simply not contain the fields that cannot be changed. -In a particular instrument, the settlement asset, margin asset, and `market.value.windowLength` must match. -The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` -or b) `settled` state but with time since settlement less than or equal `network.liquidity.successorLaunchWindowLength` -or c) `cancelled` (closed by governance) but with the closing time less than or equal `network.liquidity.successorLaunchWindowLength`. -The point of setting up a market to be successor of an existing market is to -a) allow LPs continue claim their virtual stake / equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and -b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. - -If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `network.liquidity.successorLaunchWindowLength` then the parent marketID may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). - - -Note that each market can have exactly one market as a _successor_ market. - -- if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. -- if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market no longer available". -- if there is a successor market naming a parent market and the parent terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market can again act as successor to a different market proposed by a future market proposal. +1. if the market is meant to be a _successor_ of a given market then it contains the `marketID` of the market it's succeeding (parent market), a parameter called `insurancePoolFraction` which is a decimal in `[0,1]` (i.e. it can be `0` or `1` or anything in between) and certain entries in the market proposal must be identical to those of the market it's succeeding. +See [sucessor markets spec](./0081-SUCM-successor_markets.md for more details). All _new market proposals_ initially have their validation configured by the network parameters `Governance.CreateMarket.All.*`. These may be split from `All` to subtypes in future, for instance when other market types like RFQ are created. diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 172f36a90..08c693d12 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -108,7 +108,7 @@ Auction period ends when any of the following occur: A market becomes Cancelled when a Market Proposal is successful and conditions are not met to transition the Market to the Active state during the Pending period, and the trading terminated data source input rings, see [data sourcing](./0045-DSRC-data_sourcing.md). -When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset. After `network.liquidity.successorLaunchWindowLength` has elapsed since cancellation any insurance pool balance should be transferred into the network treasury account for that asset. +When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset. After `market.liquidity.successorLaunchWindowLength` has elapsed since cancellation any insurance pool balance should be transferred into the network treasury account for that asset. Once "cancelled" there must be no open positions tracked by the protocol for the market and any open positions must have been closed including returning all margin and other related collateral if necessary and also notifying downstream event consumers that the positions are closed. Specific position related actions may be unnecessary if the cancelled state is being entered from a state in which there cannot possibly have been any open positions. All data sources that are only referenced by this market should be unregistered. @@ -218,7 +218,7 @@ Once the required data to calculate the settlement cashflows is provided by orac The positions are then closed and all orders cleared. All money held in margin accounts after final settlement is returned to traders' general accounts. [LP fees](0042-LIQF-setting_fees_and_rewarding_lps.md) that have been cumulated but not yet paid out are distributed to the market LPs as per the LP spec. -After `network.liquidity.successorLaunchWindowLength` has elapsed since the settlement time +After `market.liquidity.successorLaunchWindowLength` has elapsed since the settlement time - [Insurance pool funds](./0015-INSR-market_insurance_pool_collateral.md) are transferred to the on-chain treasury for the asset for markets that have no successor market, see [governance](./0028-GOVE-governance.md). For markets that have a named successor market the insurance pool balance is transferred to the insurance pool of the successor market. - The market can be deleted entirely at this point, from a core perspective. @@ -283,7 +283,7 @@ The market state is `trading terminated`. Parties that had open positions see settlement cash-flows happen. Margin account balances are transferred to the general account. The market state is `settled`. -After `network.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. ### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003) @@ -292,6 +292,6 @@ After `network.liquidity.successorLaunchWindowLength` has passed since market se 1. Trading terminated data source rings before the market leaves the opening auction (so market never left Pending state so far). 1. All orders should be cancelled and collateral returned to respective parties general account for the relevant asset. 1. All LP commitments should be cancelled and their bond returned to the general account for the relevant asset. -1. After `network.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +1. After `market.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md new file mode 100644 index 000000000..21e8893b5 --- /dev/null +++ b/protocol/0081-SUCM-successor_markets.md @@ -0,0 +1,82 @@ +# Sucessor markets + +## Overview + +On Vega anyone can propose a market via on-chain [governance](./0028-GOVE-governance.md). +The markets are created and in many cases terminated and setteled following the [market lifecycle](./0043-MKTL-market_lifecycle.md). +On every market liquidity is provided by various parties, liquidity providers (LPs), who [commit to provide liquidity](./0044-LIME-lp_mechanics.md) by depositing a bond / stake. +As part of this process the LPs build-up virtual stake on the market, which may be higher than the stake they committed if the market grew. +For [details of virtual stake calculation see how LPs are rewarded](./0042-LIQF-setting_fees_and_rewarding_lps.md). + +Many derivative markets would terminate and settle periodically but would be part of a sequence. +Think e.g. of a [cash-settled future](./0016-PFUT-product_builtin_future.md) written on the same uderlying that settles every three months. +Successor markets are a feature that allows this sequencing but most importantly allows LPs to keep their virtual stake built up on one market (parent) in the sequence to be transferred to the next one (sucessor). +Moreover, part of the insurance pool of a parent market can be earmarked for transfer to the successor market instead of being distributed network wide (other markets in same settlement asset, network treasury). + +## Relevant network / market parameters + +- `market.value.windowLength` is a network parameter specifying how long, after a market has settled, the LPs virtual stakes are retained and the insurance pool is left undistributed to allow a sucessor to be defined. +- `parent market Id` is part of market proposal which can optionally specify a parent market; see [governance](./0028-GOVE-governance.md). +- `insurancePoolFraction` is is part of market proposal which can optionally specify how much of the insurance pool of the parent is to be transferred to the sucessor; see [governance](./0028-GOVE-governance.md). + +## Specifying a parent market and timing details + +A market [governance] proposal for a successor market must contain all the infromation of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. +The product, settlement asset, margin asset, and `market.value.windowLength` must match but all other inputs can be different (e.g. position and price decimal places, risk mode, price monitoring, termination and settlement oracles etc.). +For [spot markets](./0080-SPOT-product_builtin_spot.md) base and quote assets must match. + +The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` +or b) `settled` state but with time since settlement less than or equal `market.liquidity.successorLaunchWindowLength` +or c) `cancelled` (closed by governance) but with the closing time less than or equal `market.liquidity.successorLaunchWindowLength`. +The point of setting up a market to be successor of an existing market is to +a) allow LPs continue claim their virtual stake / equity-like-share (ELS) by committing liquidity to the successor market during the pending period if they wish to, and +b) allow the successor market to inherit the insurance pool of the parent market. When the successor market leaves the opening auction (moves from pending to active) the amount equal to `insurancePoolFraction x parent market insurance pool balance` is transferred to the successor market insurance pool. Once the parent market moves from "trading terminated" to "settled" state, the entire remaining insurance pool of the successor market is transferred to the successor market insurance pool. + +If the parent market is `proposed` or `pending` or the opening auction ends after the settlement time / cancellation time plus `market.liquidity.successorLaunchWindowLength` then the parent marketID may no longer exist in core or there may be no virtual stake to claim (copy). In that case the successor market virtual stakes are initialised as if the market has no parent (and we set the parent market field in market data to null / empty indicating no parent market). + +Note that each market can have exactly one market as a _successor_ market. + +- if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. +- if there are two proposals naming the same parent market then whichever one gets into the *active* state first (i.e. passes governance vote and clears the opening auction) becomes the successor of the named parent; the other proposal is kept but the parent market id field is cleared and when opening auction ends no virtual stake will get carried over. +- if there is a successor market naming a parent market and the parent terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market can again act as successor to a different market proposed by a another market proposal. + +## Carrying over virtual stake + +While a successor market is in opening auction any LP party can submit liquidity commitments to it. +LP parties that exist on the parent market will get special treatment. + +At the end of opening auction, if the parent market still exists, the following will happen. +1. For each LP that exists on the parent market their virtual stake is carried over. +1. For each LP that exists on the parent market we update their virtual stake using the difference (delta) between the physical stake present on the parent market and the stake committed to the successor market using the update rule given in [the spec detailing LP rewards](./0042-LIQF-setting_fees_and_rewarding_lps.md). + +## Transferring insurance pool balance + +At the end of opening auction, if the parent market still exists, the fraction of the parent insurance pool balance given by `insurancePoolFraction` is transferred to the successor market. + +## Acceptance criteria + +### Proposals and timing + +Market proposal may specify parent market ID. If it does then: +- It must also specify insurance pool fraction (0081-SUCM-001) +- The product, settlement asset, margin asset, and `market.value.windowLength` must match between parent and successor; if not proposal is rejected (0081-SUCM-002) +- It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). + +It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). + +Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market's parent market Id field is cleared. When it clears the opening auction it gets no insurance pool from the parent and no virtual stakes get carried over (0081-SUCM-005). + +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurace pool balance. If the new market clears the opening auction before `parent settlement time + market.value.windowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). + +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurace pool balance. If the new market clears the opening auction after `parent settlement time + market.value.windowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007). + +### Virtual stake + +A new market is set with a parent market Id. On the parent there are two parties `A` and `B` with virtual stakes `v1` and `v2` and physical stakes `s1` and `s2` +If +- Both `A` and `B` submit a liquidity commitment of `s1` and `s2` to the new market before the opening auction ends. No other LP submits liquidity to the new market. Then, once the opening auction resolved the LPs `A` and `B` have virtual stakes `v1` and `v2` (0081-SUCM-020). +- As above but a `A` submits `s1` and `B` doesn't submit anything. Then `A` has virtual stake `v1` and `B` has virtual stake `0` (0081-SUCM-021). +- As above but `A` submits more than `s1`. Then `A` has virtual stake larger than `v1`. (0081-SUCM-022) + + + From 5bf981cbbfd262802e42019d06dbabe853bac43f Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 6 Jun 2023 10:58:09 +0100 Subject: [PATCH 104/649] fix: CI lint errors --- protocol/0081-SUCM-successor_markets.md | 59 +++++++++++++------------ 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 21e8893b5..c6ada2632 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -1,27 +1,27 @@ -# Sucessor markets +# Successor markets -## Overview +## Overview On Vega anyone can propose a market via on-chain [governance](./0028-GOVE-governance.md). -The markets are created and in many cases terminated and setteled following the [market lifecycle](./0043-MKTL-market_lifecycle.md). +The markets are created and in many cases terminated and settled following the [market lifecycle](./0043-MKTL-market_lifecycle.md). On every market liquidity is provided by various parties, liquidity providers (LPs), who [commit to provide liquidity](./0044-LIME-lp_mechanics.md) by depositing a bond / stake. -As part of this process the LPs build-up virtual stake on the market, which may be higher than the stake they committed if the market grew. +As part of this process the LPs build-up virtual stake on the market, which may be higher than the stake they committed if the market grew. For [details of virtual stake calculation see how LPs are rewarded](./0042-LIQF-setting_fees_and_rewarding_lps.md). -Many derivative markets would terminate and settle periodically but would be part of a sequence. -Think e.g. of a [cash-settled future](./0016-PFUT-product_builtin_future.md) written on the same uderlying that settles every three months. -Successor markets are a feature that allows this sequencing but most importantly allows LPs to keep their virtual stake built up on one market (parent) in the sequence to be transferred to the next one (sucessor). +Many derivative markets would terminate and settle periodically but would be part of a sequence. +Think e.g. of a [cash-settled future](./0016-PFUT-product_builtin_future.md) written on the same underlying that settles every three months. +Successor markets are a feature that allows this sequencing but most importantly allows LPs to keep their virtual stake built up on one market (parent) in the sequence to be transferred to the next one (successor). Moreover, part of the insurance pool of a parent market can be earmarked for transfer to the successor market instead of being distributed network wide (other markets in same settlement asset, network treasury). -## Relevant network / market parameters +## Relevant network / market parameters -- `market.value.windowLength` is a network parameter specifying how long, after a market has settled, the LPs virtual stakes are retained and the insurance pool is left undistributed to allow a sucessor to be defined. -- `parent market Id` is part of market proposal which can optionally specify a parent market; see [governance](./0028-GOVE-governance.md). -- `insurancePoolFraction` is is part of market proposal which can optionally specify how much of the insurance pool of the parent is to be transferred to the sucessor; see [governance](./0028-GOVE-governance.md). +- `market.value.windowLength` is a network parameter specifying how long, after a market has settled, the LPs virtual stakes are retained and the insurance pool is left undistributed to allow a successor to be defined. +- `parent market Id` is part of market proposal which can optionally specify a parent market; see [governance](./0028-GOVE-governance.md). +- `insurancePoolFraction` is is part of market proposal which can optionally specify how much of the insurance pool of the parent is to be transferred to the successor; see [governance](./0028-GOVE-governance.md). ## Specifying a parent market and timing details -A market [governance] proposal for a successor market must contain all the infromation of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. +A market [governance] proposal for a successor market must contain all the information of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. The product, settlement asset, margin asset, and `market.value.windowLength` must match but all other inputs can be different (e.g. position and price decimal places, risk mode, price monitoring, termination and settlement oracles etc.). For [spot markets](./0080-SPOT-product_builtin_spot.md) base and quote assets must match. @@ -37,46 +37,47 @@ If the parent market is `proposed` or `pending` or the opening auction ends afte Note that each market can have exactly one market as a _successor_ market. - if there already is a market (possibly pending, i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)), naming a parent market, then a subsequent proposal referencing that market is rejected. -- if there are two proposals naming the same parent market then whichever one gets into the *active* state first (i.e. passes governance vote and clears the opening auction) becomes the successor of the named parent; the other proposal is kept but the parent market id field is cleared and when opening auction ends no virtual stake will get carried over. +- if there are two proposals naming the same parent market then whichever one gets into the _active_ state first (i.e. passes governance vote and clears the opening auction) becomes the successor of the named parent; the other proposal is kept but the parent market id field is cleared and when opening auction ends no virtual stake will get carried over. - if there is a successor market naming a parent market and the parent terminates and settles or is cancelled by governance before the parent market (for whatever reason) then the parent market can again act as successor to a different market proposed by a another market proposal. -## Carrying over virtual stake +## Carrying over virtual stake -While a successor market is in opening auction any LP party can submit liquidity commitments to it. -LP parties that exist on the parent market will get special treatment. +While a successor market is in opening auction any LP party can submit liquidity commitments to it. +LP parties that exist on the parent market will get special treatment. -At the end of opening auction, if the parent market still exists, the following will happen. -1. For each LP that exists on the parent market their virtual stake is carried over. +At the end of opening auction, if the parent market still exists, the following will happen. + +1. For each LP that exists on the parent market their virtual stake is carried over. 1. For each LP that exists on the parent market we update their virtual stake using the difference (delta) between the physical stake present on the parent market and the stake committed to the successor market using the update rule given in [the spec detailing LP rewards](./0042-LIQF-setting_fees_and_rewarding_lps.md). ## Transferring insurance pool balance -At the end of opening auction, if the parent market still exists, the fraction of the parent insurance pool balance given by `insurancePoolFraction` is transferred to the successor market. +At the end of opening auction, if the parent market still exists, the fraction of the parent insurance pool balance given by `insurancePoolFraction` is transferred to the successor market. -## Acceptance criteria +## Acceptance criteria -### Proposals and timing +### Proposals and timing Market proposal may specify parent market ID. If it does then: + - It must also specify insurance pool fraction (0081-SUCM-001) - The product, settlement asset, margin asset, and `market.value.windowLength` must match between parent and successor; if not proposal is rejected (0081-SUCM-002) -- It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). +- It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market's parent market Id field is cleared. When it clears the opening auction it gets no insurance pool from the parent and no virtual stakes get carried over (0081-SUCM-005). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurace pool balance. If the new market clears the opening auction before `parent settlement time + market.value.windowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.value.windowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurace pool balance. If the new market clears the opening auction after `parent settlement time + market.value.windowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007). +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.value.windowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007). ### Virtual stake A new market is set with a parent market Id. On the parent there are two parties `A` and `B` with virtual stakes `v1` and `v2` and physical stakes `s1` and `s2` -If -- Both `A` and `B` submit a liquidity commitment of `s1` and `s2` to the new market before the opening auction ends. No other LP submits liquidity to the new market. Then, once the opening auction resolved the LPs `A` and `B` have virtual stakes `v1` and `v2` (0081-SUCM-020). -- As above but a `A` submits `s1` and `B` doesn't submit anything. Then `A` has virtual stake `v1` and `B` has virtual stake `0` (0081-SUCM-021). -- As above but `A` submits more than `s1`. Then `A` has virtual stake larger than `v1`. (0081-SUCM-022) - +If +- Both `A` and `B` submit a liquidity commitment of `s1` and `s2` to the new market before the opening auction ends. No other LP submits liquidity to the new market. Then, once the opening auction resolved the LPs `A` and `B` have virtual stakes `v1` and `v2` (0081-SUCM-020). +- As above but a `A` submits `s1` and `B` doesn't submit anything. Then `A` has virtual stake `v1` and `B` has virtual stake `0` (0081-SUCM-021). +- As above but `A` submits more than `s1`. Then `A` has virtual stake larger than `v1`. (0081-SUCM-022) From 0d5646e18d4387e2b3ad593395cdc03a6379618c Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 13:22:11 +0200 Subject: [PATCH 105/649] refactor: pro-rata commitment reduction --- protocol/0044-LIME-lp_mechanics.md | 45 +++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 13 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 85fe7bc11..9947c181b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -105,11 +105,12 @@ The amendment is actioned in two steps. 1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. 2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. -Commitment amendments should be processed in the time order of their latest updates within the epoch. For example if an LP places an amendment at time `t1`, followed by LP2 placing an amendment at `t2` and the first LP amending again at `t1`, LP2's amendment will be executed first. +For each party only the most recent amendement should be considered. All the amendements get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant. #### Increasing commitment _Case:_ `proposed-commitment-variation >= 0` + A liquidity provider can always increase their commitment amount as long as they have sufficient collateral in the settlement asset of the market to meet the new commitment amount. If they do not have sufficient collateral the transaction is rejected in entirety. This means that any change in fee bid is not applied and that the `old-commitment-amount` is retained. @@ -117,31 +118,49 @@ If they do not have sufficient collateral the transaction is rejected in entiret #### Decreasing commitment _Case:_ `proposed-commitment-variation < 0` -We to calculate how much the LP can reduce commitment without incurring a penalty. -To do this we first evaluate the maximum amount that the market can reduce without penalty given by the current liquidity demand in the market. -`maximum-penalty-free-reduction-amount = total_stake - target_stake` + + +At the begining of each epoch, calculate actual commitment variation for each LP as: + +$$ +\text{commitment-variation}_i=\min(-\text{proposed-commitment-variation}_i, \text{bond account balance}_i). +$$ + +Next, calculate how much the overall commitment within the market can be decreased by without incurring a penalty. +To do this we first evaluate the maximum amount that the `total_stake` can reduce by without penalty given the current liquidity demand in the market. + +`maximum-penalty-free-reduction-amount = max(0,total_stake - target_stake)` where: - `total_stake` is the sum of all stake of all liquidity providers bonded to this market. - `target_stake` is a measure of the market's current stake requirements, as per the calculation in the [target stake](./0041-TSTK-target_stake.md). -If `-1 * proposed-commitment-variation <= maximum-penalty-free-reduction-amount` then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). +Then, for each $LP_i$ we calculate the pro rata penalty-free reduction amount: +$$ +\text{maximum-penalty-free-reduction-amount}_i=\frac{\text{commitment-variation}_i}{\sum_{j}\text{commitment-variation}_j} \cdot \text{maximum-penalty-free-reduction-amount}. +$$ -If `-1 * proposed-commitment-variation > maximum-penalty-free-reduction-amount` then first establish +If $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$ then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). -```text -penalty-incuring-reduction-amount = -1 * proposed-commitment-variation - maximum-penalty-free-reduction-amount -``` +If $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ then first establish + +$$ +\text{penalty-incuring-reduction-amount}_i = \text{commitment-variation}_i - \text{maximum-penalty-free-reduction-amount}_i +$$ + +Transfer $\text{maximum-penalty-free-reduction-amount}_i$ to their general account. -Transfer `maximum-penalty-free-reduction-amount` to their general account. -Now transfer `min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to their general account and transfer `market.liquidity.earlyExitPenalty x min((1-market.liquidity.earlyExitPenalty) x penalty-incuring-reduction-amount, bond account balance remaining)` to the market insurance pool. -Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire `proposed-commitment-variation` as the `delta`. +Now transfer $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incuring-reduction-amount}_i$ to their general account and transfer $ +\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incuring-reduction-amount}_i$ +to the market insurance pool. -Note that as a consequence the market may land in a liquidity auction the next time the next time conditions for liquidity auctions are evaluated (but there is no need to tie the event of LP reducing their commitment to an immediate liquidity auction evaluation). +Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire $\text{commitment-variation}_i$ as the `delta`. +Note that as a consequence the market may land in a liquidity auction the next time conditions for liquidity auctions are evaluated (but there is no need to tie the event of LP(s) reducing their commitment to an immediate liquidity auction evaluation). + ## Fees ### Nominating and amending fee amounts From 5e38de1988a665d71ce260eb1e7f8120bd34e6dd Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 14:05:20 +0200 Subject: [PATCH 106/649] refactor: define temp account, no bond search --- protocol/0044-LIME-lp_mechanics.md | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9947c181b..159cc340b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -241,7 +241,7 @@ Moreover, as this reduced the LP stake, update the ELS as per [Calculating liqui ### Penalty for not supporting open positions -If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. +If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _temporary liquidity provider bond account_ and the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. Calculating the penalty: @@ -256,39 +256,29 @@ _Auctions:_ if this occurs at the transition from auction mode to continuous tra The network will: -1. _As part of the normal collateral "search" process:_ Access the liquidity provider's bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of the bond account will be used. Note that this means that the transfer request should include the liquidity provider's bond account in the list of accounts to search, and that the bond account would always be emptied before any insurance pool funds are used or loss socialisation occurs. +1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's temporary bond and then (if needed) the actual bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's temporary bond account and bond account in the list of accounts to search, and that these accounts would always be emptied before any insurance pool funds are used or loss socialisation occurs. -1. _If there was a shortfall and the bond account was accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. +1. _If there was a shortfall and both bond accounts were accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the temporary bond account and the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. 1. Initiate closeout of the LPs order and/or positions as normal if their margin does not meet the minimum maintenance margin level required. (NB: this should involve no change) -1. _If the liquidity provider's orders or positions were closed out, and they are therefore no longer supplying the liquidity implied by their Commitment:_ In this case the liquidity provider's Commitment size is set to zero and they are no longer a liquidity provider for fee/reward purposes, and their commitment can no longer be counted towards the supplied liquidity in the market. (From a Core perspective, it is as if the liquidity provider has exited their commitment entirely and they no longer need to be tracked as an LP.) +1. _The liquidity providers bond account balance is always it's current commitment level:_ This is strictly their "true" bond account, funds in the "temporary" bond account are not counted as their commitment (though they do get included in market's overall commitment). Since we always search the temporary bond account first their true bond account balance can only drop to zero ones the temporary account has already been drained. Once the party's "true" bond account balance drops to zero they are no longer a liquidity provider for fee/reward purposes. (From a Core perspective, it is as if the liquidity provider has exited their commitment entirely and they no longer need to be tracked as an LP.) Note: - As mentioned above, closeout should happen as per regular trader account (with the addition of cancelling the liquidity provision and the associated LP rewards & fees consequences). So, if after cancelling all open orders the party can afford to keep the open positions sufficiently collateralised they should be left open, otherwise the positions should get liquidated. -### Bond account top up by collateral search - -In the same way that a collateral search is initiated to attempt to top-up a trader's margin account if it drops below the _collateral search level_, the system must also attempt to top up the bond account if its balance drops below the size of the LP's commitment. - -This should happen every time the network is performing a margin calculation and search. The system should prioritise topping up the margin account first, and then the bond account, if there are insufficient funds to do both. - -If, at the end of an epoch (and before any LP rewards and penalties were applied), the LPs bond account isn't topped up to the level of their commitment then, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). - - ## What data do we keep relating to liquidity provision? 1. List of all liquidity providers and their commitment sizes, their “equity-like share” and "liquidity score" for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) -1. New account per market holding all committed liquidity provider bonds +1. Two new accounts (temporary bond account and bond account) per LP per market 1. Actual amount of liquidity supplied (can be calculated from order book, [see 0034-prob-weighted-liquidity-measure](./0034-PROB-prob_weighted_liquidity_measure.ipynb)) -1. Each liquidity provider's actual bond amount (i.e. the balance of their bond account) ## APIs -- Transfers to and from the bond account, new or changed commitments, and any penalties applied should all be published on the event stream +- Transfers to and from the temporary bond account and the bond account, new or changed commitments, and any penalties applied should all be published on the event stream - It should be possible to query all details of liquidity providers via an API ## Acceptance Criteria From 4afaf35e6428e9b6edd7badbf9969748fd159a0b Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 14:47:25 +0200 Subject: [PATCH 107/649] refactor: tidy-up --- glossaries/trading-and-protocol-glossary.md | 2 +- protocol/0013-ACCT-accounts.md | 2 +- .../0039-MKTD-market_depth_calculation.md | 2 - protocol/0041-TSTK-target_stake.md | 2 +- protocol/0044-LIME-lp_mechanics.md | 15 +++--- user-interface/7003-MORD-manage_orders.md | 51 +++++-------------- 6 files changed, 23 insertions(+), 51 deletions(-) diff --git a/glossaries/trading-and-protocol-glossary.md b/glossaries/trading-and-protocol-glossary.md index 28307da7f..8c587200b 100644 --- a/glossaries/trading-and-protocol-glossary.md +++ b/glossaries/trading-and-protocol-glossary.md @@ -185,7 +185,7 @@ The net riskiest composition of a trader's open positions and live orders. For ### Liquidity Providers -Liquidity providers commit a bond and place a special Liquidity Commitment that automatically maintains orders on the book for a specific market. In return, liquidity providers earn a [fee](#fees) for ensuring that markets always have open volume. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail. +Liquidity providers commit a bond which specifies their SLA obligations. In return for meeting these the liquidity providers earn a portion of the trading [fees](#fees) from the market in which they operate. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail. ## M diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 9d82ff779..b23031733 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -73,7 +73,7 @@ If there is a positive balance in an account that is being deleted, that balance ## Bond accounts -Bond accounts are opened when a party opens a [Liquidity Provision order](./0038-OLIQ-liquidity_provision_order_type.md). The bond is held by the network to ensure that the Liquidity PRovider maintains enough collateral to cover their commitment. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. +Bond accounts are opened when a party opens a [Liquidity Provision order](./0038-OLIQ-liquidity_provision_order_type.md). The bond is held by the network to ensure that the Liquidity Provider meets their SLA obligations. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. ## Insurance pools diff --git a/protocol/0039-MKTD-market_depth_calculation.md b/protocol/0039-MKTD-market_depth_calculation.md index 9271ae5ca..08b55ae43 100644 --- a/protocol/0039-MKTD-market_depth_calculation.md +++ b/protocol/0039-MKTD-market_depth_calculation.md @@ -15,8 +15,6 @@ - Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013) - Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014) - Pegged orders are part of the market depth view and should update the view when their orders are repriced (0039-MKTD-015) -- Liquidity orders are part of the market depth view and should update the view when commitment sizes change (0039-MKTD-016) -- Liquidity orders are part of the market depth view and should update the view when their reference prices move (0039-MKTD-017) - Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018) - The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index b285b2cab..3dac124d2 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -93,7 +93,7 @@ Then: the target stake value is target_stake = 0.25 * 11000 = 2750 DAI ``` -The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` indirectly controls the `total_stake` as the amount an LP is able to reduce their commitment is restricted by the `maximum_reduction_amount`. +The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` impacts the `total_stake` as reducing the commitment beyond `maximum_reduction_amount` means the LPs will be charged a penalty for doing so. ### Acceptance criteria diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 159cc340b..15d59bf70 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -119,8 +119,6 @@ If they do not have sufficient collateral the transaction is rejected in entiret _Case:_ `proposed-commitment-variation < 0` - - At the begining of each epoch, calculate actual commitment variation for each LP as: $$ @@ -134,7 +132,7 @@ To do this we first evaluate the maximum amount that the `total_stake` can reduc where: -- `total_stake` is the sum of all stake of all liquidity providers bonded to this market. +- `total_stake` is the sum of all stake of all liquidity providers bonded to this market including the amendments with positive commitment variation submitted in the previous epoch. - `target_stake` is a measure of the market's current stake requirements, as per the calculation in the [target stake](./0041-TSTK-target_stake.md). Then, for each $LP_i$ we calculate the pro rata penalty-free reduction amount: @@ -160,7 +158,6 @@ Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_r Note that as a consequence the market may land in a liquidity auction the next time conditions for liquidity auctions are evaluated (but there is no need to tie the event of LP(s) reducing their commitment to an immediate liquidity auction evaluation). - ## Fees ### Nominating and amending fee amounts @@ -241,7 +238,7 @@ Moreover, as this reduced the LP stake, update the ELS as per [Calculating liqui ### Penalty for not supporting open positions -If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _temporary liquidity provider bond account_ and the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. +If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _temporary liquidity provider bond account_ and the _liquidity provider bond account_ (accessed in that order) to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. Calculating the penalty: @@ -256,13 +253,13 @@ _Auctions:_ if this occurs at the transition from auction mode to continuous tra The network will: -1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's temporary bond and then (if needed) the actual bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's temporary bond account and bond account in the list of accounts to search, and that these accounts would always be emptied before any insurance pool funds are used or loss socialisation occurs. +1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's temporary bond and then (if needed) the actual bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's temporary bond account and true bond account in the list of accounts to search, and that these accounts would always be emptied before any insurance pool funds are used or loss socialisation occurs. -1. _If there was a shortfall and both bond accounts were accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the temporary bond account and the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. +1. _If there was a shortfall and either of the bond accounts was accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the temporary bond account and the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. 1. Initiate closeout of the LPs order and/or positions as normal if their margin does not meet the minimum maintenance margin level required. (NB: this should involve no change) -1. _The liquidity providers bond account balance is always it's current commitment level:_ This is strictly their "true" bond account, funds in the "temporary" bond account are not counted as their commitment (though they do get included in market's overall commitment). Since we always search the temporary bond account first their true bond account balance can only drop to zero ones the temporary account has already been drained. Once the party's "true" bond account balance drops to zero they are no longer a liquidity provider for fee/reward purposes. (From a Core perspective, it is as if the liquidity provider has exited their commitment entirely and they no longer need to be tracked as an LP.) +1. _The liquidity provider's bond account balance is always their current commitment level:_ This is strictly their "true" bond account, funds in the "temporary" bond account are not counted as their commitment (though they do get included in market's overall commitment). Since we always search the temporary bond account first their true bond account balance can only drop to zero once the temporary account has already been drained. Once the party's "true" bond account balance drops to zero they are no longer a liquidity provider for fee/reward purposes. (From a Core perspective, it is as if the liquidity provider has exited their commitment entirely and they no longer need to be tracked as an LP.) Note: @@ -278,7 +275,7 @@ Note: ## APIs -- Transfers to and from the temporary bond account and the bond account, new or changed commitments, and any penalties applied should all be published on the event stream +- Transfers to and from the temporary bond account and the true bond account, new or changed commitments, and any penalties applied should all be published on the event stream - It should be possible to query all details of liquidity providers via an API ## Acceptance Criteria diff --git a/user-interface/7003-MORD-manage_orders.md b/user-interface/7003-MORD-manage_orders.md index 30d58522d..7540dfee0 100644 --- a/user-interface/7003-MORD-manage_orders.md +++ b/user-interface/7003-MORD-manage_orders.md @@ -4,7 +4,7 @@ Users place orders to describe the trades they would like to make: buy or sell, Once a user has placed an order they may wish to confirm it's [status](https://docs.vega.xyz/docs/mainnet/graphql/enums/order-status) in a [list](#orders-list) of other orders. e.g. whether it has been accepted, filled, how close it is to being filled etc. Users may be interested in the price of their orders relative to the price of the market and how much of the order's size has been filled. -Orders can also be placed on behalf of a user/party via [liquidity](#liquidity-order-shapes) or [pegged](#pegged-order-shapes) order shapes. These order cannot be amended on canceled in the same way as other orders. +Orders can also be placed on behalf of a user/party via [pegged](#pegged-orders) orders. Markets also have [statuses](https://docs.vega.xyz/docs/mainnet/graphql/enums/market-state) that may affect how a user perceives the state of an order, e.g if the order was placed while in "normal" continuous trading, but the market is now in auction. @@ -53,9 +53,8 @@ When looking at a list of orders, I... - **must** see the [size](9001-DATA-data_display.md#size) of the order (7003-MORD-003) - **must** see the [direction/side](9001-DATA-data_display.md#direction--side) (Long or Short) of the order (this can be implied with a + or negative suffix on the size, + for Long, - for short) (7003-MORD-004) - **must** see [order type](9001-DATA-data_display.md#order-type) (7003-MORD-005) -- if order created by [pegged or liquidity provision shape](9001-DATA-data_display.md#order-origin): **should** see order origin - - **could** see what part of the liquidity shape or pegged order shape this relates to or it's offset+reference See [pegged orders](#pegged-order-shapes) and [liquidity provisions](#liquidity-order-shapes) shapes below. - - **could** see link to full shape +- if order created by [a pegged order](9001-DATA-data_display.md#order-origin): **should** see order origin + - **could** see it's offset+reference. See [pegged orders](#pegged-order-shapes), - **should** see how much of the order's [size](9001-DATA-data_display.md#size) has been filled e.g. if the order was for `50` but so far only 10 have traded I should see Filled = `10`. Note: this is marked as a should because in the case of Rejected order and some other scenarios it isn't relevant. - **should** see how much of the order's [size](9001-DATA-data_display.md#size) remains. @@ -70,12 +69,12 @@ When looking at a list of orders, I... - **should** see time priority (how many orders are before mine at this price) -- if the order is `Active` & **not** part of a liquidity or peg shape: **must** see an option to [amend](#amend-order---price) the individual order (7003-MORD-007) -- if the order is `Active` & is part of a liquidity or peg shape: **must** **not** see an option to amend the individual order (7003-MORD-008) - - **could** see a link to amend shape -- if the order is `Active` & **not** part of a liquidity or peg shape: **must** see an option to [cancel](#cancel-orders) the individual order -- if the order is `Active` & is part of a liquidity or peg shape: **must** **not** see an option to cancel the individual order - - **could** see a link to cancel shape +- if the order is `Active` & **not** a pegged order: **must** see an option to [amend](#amend-order---price) the individual order (7003-MORD-007) +- if the order is `Active` & is a pegged order: **must** **not** see an option to amend the resulting active order at the current price (7003-MORD-008) + - **could** see a link to amend the pegged order itself +- if the order is `Active` & **not** a pegged order: **must** see an option to [cancel](#cancel-orders) the individual order +- if the order is `Active` & is a pegged order **must** **not** see an option to cancel the individual order + - **could** see a link to cancel the pegged order ... so I can understand the state of my orders and decide what to do next ### Filters @@ -164,42 +163,20 @@ when looking at an order book, I... ... so I can see my orders in context of price history -## Pegged order shapes +## Pegged orders -When looking to understand the state of a pegged order shape... +When looking to understand the state of a pegged order... -- **should** see the whole shape of a pegged order - **must** see the reference, offset and direction for each part pegged order (7003-MORD-016) - **should** see the current price for each buy/sell - **should** see the filled/remaining for each part of the order - when order is not `Active`: **should** show the order status (perhaps instead of price) -- **should** be able to cancel the whole pegged order +- **should** be able to cancel the pegged order - **would** like to see link to edit the shape of a pegged order - **would** like to see the date submitted/updated -... so I can decide if I wish to amend or cancel my pegged order shape +... so I can decide if I wish to amend or cancel my pegged order -## Cancel Pegged order shapes +## Cancel Pegged order `TODO` - -## Liquidity order shapes - -When looking to understand the state of a liquidity provision, with a provided shape... - -- **would** like to see the liquidity commitment order status (`pending`, `active`, `parked`, `canceled` etc) -- **would** like to see the fee bid - -- **should** see the whole shape of a liquidity order -- **must** see the reference, offset and direction for each part liquidity order order (7003-MORD-017) -- **should** see the current price for each buy/sell -- when order is not `Active`: **should** show the order status (perhaps instead of price) -- **should** see link to cancel the whole liquidity order shape (see [liquidity provision](5002-LIQP-provide_liquidity.md)) -- **would** like to see link to edit the shape of a pegged order (see [liquidity provision](5002-LIQP-provide_liquidity.md)) -- **would** like to see the date submitted/updated - -... so I can decide if I wish to amend or cancel my shape - -## Cancel or amend Pegged order shapes - -See [liquidity provision](5002-LIQP-provide_liquidity.md), \ No newline at end of file From f35a834ba5a629c98ca5b466b9efe130ac707e5b Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 6 Jun 2023 14:32:13 +0100 Subject: [PATCH 108/649] Update protocol/0014-ORDT-order_types.md --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 0aafb36f8..c188c8e75 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -210,7 +210,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu * Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) * A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) * No party can submit a [network order type](#network-orders) (0014-ORDT-006) -* A pegged order (including iceberg pegged orders) never has it's price updated during the execution of an incoming aggressive order (even as price levels get consummed so that it's reference price changes after the execution). (0014-ORDT-039) +* A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consummed so that its reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's From cd0307c9840825960f0516d706a32aafc287202d Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 15:42:43 +0200 Subject: [PATCH 109/649] Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 15d59bf70..0ac134885 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -105,7 +105,7 @@ The amendment is actioned in two steps. 1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. 2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. -For each party only the most recent amendement should be considered. All the amendements get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant. +For each party only the most recent amendement should be considered. All the amendements get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant (as far as commitment reduction is concerned, it still has implications for other aspects of the mechanism). #### Increasing commitment From 5e56d3d83ca01aa41c8c44fe898242e4b3e2230f Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 6 Jun 2023 16:29:50 +0200 Subject: [PATCH 110/649] refactor: fix spelling --- protocol/0014-ORDT-order_types.md | 2 +- protocol/0044-LIME-lp_mechanics.md | 10 ++++------ wordlist.txt | 1 + 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index c188c8e75..e5d2d829c 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -210,7 +210,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu * Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) * A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) * No party can submit a [network order type](#network-orders) (0014-ORDT-006) -* A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consummed so that its reference price changes after the execution). (0014-ORDT-039) +* A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 0ac134885..bf0b2427e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -105,7 +105,7 @@ The amendment is actioned in two steps. 1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. 2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. -For each party only the most recent amendement should be considered. All the amendements get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant (as far as commitment reduction is concerned, it still has implications for other aspects of the mechanism). +For each party only the most recent amendment should be considered. All the amendments get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant (as far as commitment reduction is concerned, it still has implications for other aspects of the mechanism). #### Increasing commitment @@ -119,7 +119,7 @@ If they do not have sufficient collateral the transaction is rejected in entiret _Case:_ `proposed-commitment-variation < 0` -At the begining of each epoch, calculate actual commitment variation for each LP as: +At the beginning of each epoch, calculate actual commitment variation for each LP as: $$ \text{commitment-variation}_i=\min(-\text{proposed-commitment-variation}_i, \text{bond account balance}_i). @@ -145,14 +145,12 @@ If $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount If $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ then first establish $$ -\text{penalty-incuring-reduction-amount}_i = \text{commitment-variation}_i - \text{maximum-penalty-free-reduction-amount}_i +\text{penalty-incurring-reduction-amount}_i = \text{commitment-variation}_i - \text{maximum-penalty-free-reduction-amount}_i $$ Transfer $\text{maximum-penalty-free-reduction-amount}_i$ to their general account. -Now transfer $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incuring-reduction-amount}_i$ to their general account and transfer $ -\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incuring-reduction-amount}_i$ -to the market insurance pool. +Now transfer $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ to their general account and transfer $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ to the market insurance pool. Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire $\text{commitment-variation}_i$ as the `delta`. diff --git a/wordlist.txt b/wordlist.txt index 98bd9262a..1942a63c8 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -69,6 +69,7 @@ disincentivise DLT DPOS durations +earlyExitPenalty ECDSA EEF EIP From 9b3b89ed572218237299252df14be10bc1d42aab Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 7 Jun 2023 11:18:24 +0100 Subject: [PATCH 111/649] Update 0028-GOVE-governance.md (#1730) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 68ee5e11d..6f033f35f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -289,7 +289,7 @@ The below table shows the allowable combinations of source and destination accou | Source type | Destination type | Governance transfer permitted | | --- | --- | --- | | Party account (any type) | Any | No | -| Network treasury | Network treasury | Yes | +| Network treasury | Network treasury | No | | Network treasury | Party general account(s) | Yes | | Network treasury | Party other account types | No | | Network treasury | Market insurance pool account | Yes | From 9d6193c45c786ec6198d0fd18013b0a6abb53f9d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Wed, 7 Jun 2023 13:41:40 +0100 Subject: [PATCH 112/649] Update protocol/0081-SUCM-successor_markets.md --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index c6ada2632..fc0214931 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -79,5 +79,5 @@ A new market is set with a parent market Id. On the parent there are two parties If - Both `A` and `B` submit a liquidity commitment of `s1` and `s2` to the new market before the opening auction ends. No other LP submits liquidity to the new market. Then, once the opening auction resolved the LPs `A` and `B` have virtual stakes `v1` and `v2` (0081-SUCM-020). -- As above but a `A` submits `s1` and `B` doesn't submit anything. Then `A` has virtual stake `v1` and `B` has virtual stake `0` (0081-SUCM-021). +- As above but `A` submits `s1` and `B` doesn't submit anything. Then `A` has virtual stake `v1` and `B` has virtual stake `0` (0081-SUCM-021). - As above but `A` submits more than `s1`. Then `A` has virtual stake larger than `v1`. (0081-SUCM-022) From 3e538e142736e6afe31b0d3589928841e58470bf Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 8 Jun 2023 23:05:40 +0200 Subject: [PATCH 113/649] refactor: fix formula and clarify --- protocol/0044-LIME-lp_mechanics.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index bf0b2427e..98d9ced07 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -119,7 +119,7 @@ If they do not have sufficient collateral the transaction is rejected in entiret _Case:_ `proposed-commitment-variation < 0` -At the beginning of each epoch, calculate actual commitment variation for each LP as: +At the beginning of each epoch, calculate actual commitment variation for each LP wishing to reduce their commitment as: $$ \text{commitment-variation}_i=\min(-\text{proposed-commitment-variation}_i, \text{bond account balance}_i). @@ -136,9 +136,9 @@ where: - `target_stake` is a measure of the market's current stake requirements, as per the calculation in the [target stake](./0041-TSTK-target_stake.md). Then, for each $LP_i$ we calculate the pro rata penalty-free reduction amount: -$$ +```math \text{maximum-penalty-free-reduction-amount}_i=\frac{\text{commitment-variation}_i}{\sum_{j}\text{commitment-variation}_j} \cdot \text{maximum-penalty-free-reduction-amount}. -$$ +``` If $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$ then we're done, the LP reduced commitment, the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md). From 1601b729ba8fffb108195c6d1463fe5e3baa47a7 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 8 Jun 2023 23:11:27 +0200 Subject: [PATCH 114/649] refactor: Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 98d9ced07..cb5464bbe 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -136,6 +136,7 @@ where: - `target_stake` is a measure of the market's current stake requirements, as per the calculation in the [target stake](./0041-TSTK-target_stake.md). Then, for each $LP_i$ we calculate the pro rata penalty-free reduction amount: + ```math \text{maximum-penalty-free-reduction-amount}_i=\frac{\text{commitment-variation}_i}{\sum_{j}\text{commitment-variation}_j} \cdot \text{maximum-penalty-free-reduction-amount}. ``` From e23e50b8d33d38b13146174bca5f94b09cf69c92 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 9 Jun 2023 15:08:54 +0200 Subject: [PATCH 115/649] fix: ditch temp bond account, keep track of bond at start of epoch --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- protocol/0044-LIME-lp_mechanics.md | 17 +++++++++-------- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index aaec07a62..167f4c5de 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -51,7 +51,7 @@ In the example below there are 3 liquidity providers all bidding for their chose ### Timing market's liquidity-fee-factor changes -Once the market opens (opening auction starts) a clock starts ticking. We calculate the `[target stake]` using [target stake](./0041-TSTK-target_stake.md). The fee is continuously re-evaluated using the mechanism above. +Once the market opens (opening auction starts) a clock starts ticking. We calculate the `[target stake]` using [target stake](./0041-TSTK-target_stake.md). The fee is re-evaluated using the mechanism above at the start of each epoch using LPs commitments at start of epoch. ### APIs for fee factor calculations - what should core be exposing? diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index cb5464bbe..db736d6eb 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -169,14 +169,14 @@ The [liquidity_fee](./0029-FEES-fees.md) of a market on Vega takes as an input, ### Distributing fees between liquidity providers -When calculating fees for a trade, the size of a liquidity provider’s commitment along with when they committed and the market size are inputs that will be used to calculate how the liquidity fee is distributed between liquidity providers. See [setting fees and rewarding lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) for the calculation of the split. +When calculating fees for a trade, the size of a liquidity provider’s commitment at the start of the epoch along with when they committed and the market size are inputs that will be used to calculate how the liquidity fee is distributed between liquidity providers. See [setting fees and rewarding lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) for the calculation of the split. ## Liquidity provision and penalties ### Calculating liquidity from commitment -Committed Liquidity Providers are required to provide a multiple of their stake (supplied in the settlement currency of the market) in notional volume of orders within the range defined below on both sides of the order book. +Committed Liquidity Providers are required to provide a multiple of their stake, at the start of the epoch, (supplied in the settlement currency of the market) in notional volume of orders within the range defined below on both sides of the order book. The multiple is controlled by a network parameter `market.liquidity.stakeToCcyVolume`: @@ -213,7 +213,7 @@ Note: we don't evaluate whether LPs meet the SLA during opening auctions so ther ### Penalty for not meeting the SLA -See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. +See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. This is available at the end of each epoch. If, at the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. Otherwise we calculate a penalty to be applied to the bond as follows. @@ -237,7 +237,8 @@ Moreover, as this reduced the LP stake, update the ELS as per [Calculating liqui ### Penalty for not supporting open positions -If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _temporary liquidity provider bond account_ and the _liquidity provider bond account_ (accessed in that order) to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. +If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. +The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. Calculating the penalty: @@ -252,13 +253,13 @@ _Auctions:_ if this occurs at the transition from auction mode to continuous tra The network will: -1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's temporary bond and then (if needed) the actual bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's temporary bond account and true bond account in the list of accounts to search, and that these accounts would always be emptied before any insurance pool funds are used or loss socialisation occurs. +1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's bond account in the list of accounts to search, and that these accounts would always be emptied before any insurance pool funds are used or loss socialisation occurs. -1. _If there was a shortfall and either of the bond accounts was accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the temporary bond account and the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. +1. _If there was a shortfall and the bond account was accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the bond account and the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. 1. Initiate closeout of the LPs order and/or positions as normal if their margin does not meet the minimum maintenance margin level required. (NB: this should involve no change) -1. _The liquidity provider's bond account balance is always their current commitment level:_ This is strictly their "true" bond account, funds in the "temporary" bond account are not counted as their commitment (though they do get included in market's overall commitment). Since we always search the temporary bond account first their true bond account balance can only drop to zero once the temporary account has already been drained. Once the party's "true" bond account balance drops to zero they are no longer a liquidity provider for fee/reward purposes. (From a Core perspective, it is as if the liquidity provider has exited their commitment entirely and they no longer need to be tracked as an LP.) +1. _The liquidity provider's bond account balance is always their current commitment level:_ This is strictly their "true" bond account. Note: @@ -267,7 +268,7 @@ Note: ## What data do we keep relating to liquidity provision? -1. List of all liquidity providers and their commitment sizes, their “equity-like share” and "liquidity score" for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) +1. List of all liquidity providers and their commitment sizes (bond account balance), the commitment at the start of epoch, their “equity-like share” and "liquidity score" for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) 1. Two new accounts (temporary bond account and bond account) per LP per market 1. Actual amount of liquidity supplied (can be calculated from order book, [see 0034-prob-weighted-liquidity-measure](./0034-PROB-prob_weighted_liquidity_measure.ipynb)) From ab6dc5b77b32032d76e5c4dc7fbeda89932f2158 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 9 Jun 2023 15:17:44 +0200 Subject: [PATCH 116/649] fix: ditch temp bond account, keep track of bond at start of epoch --- protocol/0044-LIME-lp_mechanics.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index db736d6eb..c9a2d896f 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -100,10 +100,12 @@ A participant may apply to amend their commitment amount by submitting a transac `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` -The amendment is actioned in two steps. +An increase in amendment is actioned immediately but only has implications for rewards / penalties at start of the current epoch. -1) the amount is immediately transferred from the party's general account to a temporary "pending" bond account. This amount counts towards the stake committed to the market and so in particular can get the market out of liquidity auction. -2) at the beginning of the next epoch (after the rewards / penalties for present LPs - including the party that's amending - have been evaluated) the amount is transferred from the "pending" bond to the true bond account. +1) the amount is immediately transferred from the party's general account to their bond account. However we keep track of commitment at start of epoch and this is used for penalties / rewards. +2) at the beginning of the next epoch, the rewards / penalties for present LPs - including the party that's amending - are evaluated based on balance of bond account at start of epoch. + +A decrease in commitment is noted but the transfer out of the bond account is only actioned at the end of the current epoch. For each party only the most recent amendment should be considered. All the amendments get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant (as far as commitment reduction is concerned, it still has implications for other aspects of the mechanism). From 27a01a35e8497446299762b924a38608e50ca3de Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 9 Jun 2023 15:32:53 +0200 Subject: [PATCH 117/649] refactor: remove temp account leftovers --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index c9a2d896f..d336f7881 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -271,13 +271,13 @@ Note: ## What data do we keep relating to liquidity provision? 1. List of all liquidity providers and their commitment sizes (bond account balance), the commitment at the start of epoch, their “equity-like share” and "liquidity score" for each market [see 0042-setting-fees-and-rewarding-lps](./0042-LIQF-setting_fees_and_rewarding_lps.md) -1. Two new accounts (temporary bond account and bond account) per LP per market +1. New bond account per LP per market 1. Actual amount of liquidity supplied (can be calculated from order book, [see 0034-prob-weighted-liquidity-measure](./0034-PROB-prob_weighted_liquidity_measure.ipynb)) ## APIs -- Transfers to and from the temporary bond account and the true bond account, new or changed commitments, and any penalties applied should all be published on the event stream +- Transfers to and from the bond account, new or changed commitments, and any penalties applied should all be published on the event stream - It should be possible to query all details of liquidity providers via an API ## Acceptance Criteria From df5a1b947aadf5c3b646b81d06e482bdbd14dd69 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 9 Jun 2023 15:41:19 +0200 Subject: [PATCH 118/649] refactor: fix markdown linter errors --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- protocol/0044-LIME-lp_mechanics.md | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 167f4c5de..babd053c6 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -51,7 +51,7 @@ In the example below there are 3 liquidity providers all bidding for their chose ### Timing market's liquidity-fee-factor changes -Once the market opens (opening auction starts) a clock starts ticking. We calculate the `[target stake]` using [target stake](./0041-TSTK-target_stake.md). The fee is re-evaluated using the mechanism above at the start of each epoch using LPs commitments at start of epoch. +Once the market opens (opening auction starts) a clock starts ticking. We calculate the `[target stake]` using [target stake](./0041-TSTK-target_stake.md). The fee is re-evaluated using the mechanism above at the start of each epoch using LPs commitments at start of epoch. ### APIs for fee factor calculations - what should core be exposing? diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index d336f7881..a966df052 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -100,12 +100,12 @@ A participant may apply to amend their commitment amount by submitting a transac `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` -An increase in amendment is actioned immediately but only has implications for rewards / penalties at start of the current epoch. +An increase in amendment is actioned immediately but only has implications for rewards / penalties at start of the current epoch. 1) the amount is immediately transferred from the party's general account to their bond account. However we keep track of commitment at start of epoch and this is used for penalties / rewards. -2) at the beginning of the next epoch, the rewards / penalties for present LPs - including the party that's amending - are evaluated based on balance of bond account at start of epoch. +2) at the beginning of the next epoch, the rewards / penalties for present LPs - including the party that's amending - are evaluated based on balance of bond account at start of epoch. -A decrease in commitment is noted but the transfer out of the bond account is only actioned at the end of the current epoch. +A decrease in commitment is noted but the transfer out of the bond account is only actioned at the end of the current epoch. For each party only the most recent amendment should be considered. All the amendments get processed simultaneously, hence the relative arrival of amendments made by different LPs within the previous epoch is irrelevant (as far as commitment reduction is concerned, it still has implications for other aspects of the mechanism). @@ -215,7 +215,7 @@ Note: we don't evaluate whether LPs meet the SLA during opening auctions so ther ### Penalty for not meeting the SLA -See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. +See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. This is available at the end of each epoch. If, at the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. Otherwise we calculate a penalty to be applied to the bond as follows. @@ -239,7 +239,7 @@ Moreover, as this reduced the LP stake, update the ELS as per [Calculating liqui ### Penalty for not supporting open positions -If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. +If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. Calculating the penalty: @@ -261,7 +261,7 @@ The network will: 1. Initiate closeout of the LPs order and/or positions as normal if their margin does not meet the minimum maintenance margin level required. (NB: this should involve no change) -1. _The liquidity provider's bond account balance is always their current commitment level:_ This is strictly their "true" bond account. +1. _The liquidity provider's bond account balance is always their current commitment level:_ This is strictly their "true" bond account. Note: From af4c860718780cdfb6f40f5b95e2316f2db13ed3 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 12 Jun 2023 13:47:38 +0100 Subject: [PATCH 119/649] feat: add new ACs from the AC review meeting (#1754) * feat: add new ACs from the AC review meeting * fix: spelling error * fix: Apply suggestions from code review Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * fix: make AC more clear * fix: removed duplicated AC * Update protocol/0081-SUCM-successor_markets.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update protocol/0081-SUCM-successor_markets.md --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0081-SUCM-successor_markets.md | 29 ++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index fc0214931..644117135 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -54,6 +54,7 @@ At the end of opening auction, if the parent market still exists, the following At the end of opening auction, if the parent market still exists, the fraction of the parent insurance pool balance given by `insurancePoolFraction` is transferred to the successor market. + ## Acceptance criteria ### Proposals and timing @@ -70,7 +71,33 @@ Two proposals that name the same parent can be submitted. Both can be approved b A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.value.windowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.value.windowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007). +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.value.windowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) + +Successor markets can be enacted if the parent market is still in the "proposed" state. There is no virtual stake to copy over and no insurance pool balance to transfer (0081-SUCM-008) + +Successor markets can be enacted when the parent market is in opening auction (0081-SUCM-009) + +A successor market proposal can be enacted when the parent market is in one of the following states: Suspended, Active, Trading terminated or Settled (settled within the successor time window) (0081-SUCM-010) + +When a successor market is enacted (i.e. leaves the opening auction), all other related successor market proposals, in the state "pending" or "proposed", are automatically rejected. Any LP submissions associated with these proposals are cancelled, and the funds are released (0081-SUCM-011) + +With two successor markets in opening auction, that have the same parent market, and one additional market in the state "Proposed". Get one of the two markets to leave the opening auction (passage of time, LP commitment, crossing trade). The other market in auction and the proposed market should both be "Rejected" and all LP funds will be released (0081-SUCM-014) + +Propose a successor market which specifies a parent which is settled, and for which the successor time window has expired. The proposal is declined. (0081-SUCM-018) + +### APIs + +It is possible to fetch a market "parent / successor chain" containing the initial market and the full successor line (0081-SUCM-012) + +When fetching a market that is part of a "parent / successor chain", we should see both the parent and each successor `marketID` (0081-SUCM-013) + + +### Snapshots / checkpoints + +After a LNL checkpoint restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-016) + +After snapshot restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-017) + ### Virtual stake From e0b9ac5a56eeb366ddb0dbc10cc7ab93e7c45fc2 Mon Sep 17 00:00:00 2001 From: Tom Date: Mon, 12 Jun 2023 16:35:34 +0200 Subject: [PATCH 120/649] feat: add stop orders (#1735) * WIP: add stop orders to order types spec Signed-off-by: Barney Mannerings * Update 0014-ORDT-order_types.md Typo re-fix * Add spam protection to perps spec Signed-off-by: Barney Mannerings * Update trailing stops: only % distance Signed-off-by: Barney Mannerings * fix: linting * feat: Adding ACs for stop order specs * feat: Adding specification for closing stop orders when position and orders are 0 * fix: approbation and markdown linting * chore: remove todo Confirmed with Jeremy the implementation will trigger immediately - ref line 84: (TODO: confirm we do this and don't just always wait for a trade price) * fix: AC code numbering and list formatting --------- Signed-off-by: Barney Mannerings Co-authored-by: Barney Mannerings Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0014-ORDT-order_types.md | 195 ++++++++++++++++++++++-------- wordlist.txt | 2 + 2 files changed, 146 insertions(+), 51 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index e5d2d829c..f190227af 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -6,8 +6,7 @@ A market using a limit order book will permit orders of various types to be subm Notes on scope of current version of this spec: -* Includes only detailed specification for orders valid for *continuous trading*, does not specify behaviour of these order types in an auction. -* Does not include detailed specification for **stop** orders. Inclusion of stops in guide level explanation is a placeholder/indicator of future requirements. +- Includes only detailed specification for orders valid for *continuous trading*, does not specify behaviour of these order types in an auction. ## Guide-level explanation @@ -50,6 +49,57 @@ Notes on scope of current version of this spec: 1. **Reduce-Only (True/False):** Only valid for Non-Persistent orders. Cannot be True at the same time as Post-Only. If set, order will only be executed if the outcome of the trade moves the trader's position closer to 0. In addition, a Reduce-Only order will not move a position to the opposite side to the trader's current position (e.g. if short, a Reduce-Only order cannot make the trader long as a result). If submitted as IOC, where the full volume would switch sides, only the amount required to move the position to 0 will be executed. +### Stop orders + +In addition to normal immediately executing order, Vega should accept the submission of stop orders. +These differ from normal orders in that they sit off the order book until triggered, when they are entered as normal. +These are generally used to exit positions under pre-defined conditions, either as a "stop loss" order that controls the maximum losses a position may take, a "take profit" order that closes a position once a defined level of profit has been made, or both. +To prevent traders from "hiding" order book depth behind conditional orders, stop orders can only be used to close some or all of a trader's position, and therefore must be "reduce only" orders. + +A stop order submission can be made (stop loss or take profit are probably both just called a stop order internally). + +- Stop order submissions must include either a trigger price OR trailing stop distance as a % move from the reference price in addition to a normal order submission. + +- Stop order submissions must include a trigger direction. +Direction may be **rises above** or **falls below**. +**Rises above** stops trigger if the last traded price is higher than the trigger level, and **falls below** stops trigger if the last traded price is lower than the trigger level. + +- A stop trigger can have an optional expiry date/time. +If it has an expiry then it can be set either to cancel on expiry (i.e. it is deleted at that time) or trigger on expiry (i.e. the order wrapped in the submission is placed whether or not the trigger level is breached). + +- It is possible to make a single stop order submission or an OCO (One Cancels the Other) stop order submission. +An OCO contains TWO stop order submissions, and must include one in each trigger direction. +OCOs work exactly like two separate stop orders except that if one of the pair is triggered, cancelled, deleted, or rejected, the other one is automatically cancelled. +An OCO submission allows a user to have a stop loss and take profit applied to the same amount of their position without the risk of both trading and reducing their position by more than intended. + +- The stop order submission wraps a normal order submission. + +- The order within the stop order submission must be reduce only. + +- The submission is validated when it is received but does not initially interact with the order book unless it is triggered immediately (see below). + +- If and when the trigger price is breached in the specified direction the order provided in the stop order submission is created and enters the book or trades as normal, as if it was just submitted. + +- The order contained in a stop order submission is entered immediately if the trigger price is already breached on entry, except during an auction. + +- When the stop order is a trailing stop, the price at which it is triggered is calculated as the defined distance as a percentage from the highest price achieved since the order was entered if the direction is to trigger on price below the specified level, or the lowest price achieved since the order was entered if the direction is to trigger above the level. +Therefore the trigger level of a stop order moves with the market allowing the trader to lock in some amount of gains. + +- The order can't be triggered or trade at all during an auction (even if the current price would normally trigger it immediately on entry). + +- A stop order can be entered during an auction, and can then be triggered by the auction uncrossing price if the auction results in a trade, as well as any trades (including auction uncrossing trades) after that. + +- GFA is not a valid TIF for a stop order submission. + +- Spam prevention: + + - Stop orders will only be accepted from keys with either a non-zero open position or at least one active order. + + - A network parameter will control the maximum number of stop orders per party (suggested initial value: between 4 and 10). + + - If the trader's position size moves to zero exactly, and they have no open orders, all stop orders will be cancelled. + + ### Iceberg / transparent iceberg orders On centralised exchanges, icebergs are a type of order that enables a trader to make an order with a relatively small visible "display quantity" and a larger hidden total size. @@ -71,103 +121,103 @@ Iceberg orders (or in other words, transparent iceberg orders) are still helpful These terms are used to refer to fields on an order: -* `quantity` - the full initial size of the order on entry. +- `quantity` - the full initial size of the order on entry. -* `displayed quantity` - the current displayed quantity, i.e. the amount of the remaining quantity that is active on the book and can be hit. +- `displayed quantity` - the current displayed quantity, i.e. the amount of the remaining quantity that is active on the book and can be hit. Note that for a non-iceberg order, `displayed quantity == remaining`. -* `remaining` - the total quantity of the order remaining that could trade. +- `remaining` - the total quantity of the order remaining that could trade. #### Creating iceberg orders Iceberg orders are created by populating three additional fields on any valid persistent limit order: -* `initial peak size` - this specifies the amount displayed and available on the order book for a new or newly refreshed iceberg order. +- `initial peak size` - this specifies the amount displayed and available on the order book for a new or newly refreshed iceberg order. -* `minimum peak size` - this determines when an iceberg order is eligible for refresh. +- `minimum peak size` - this determines when an iceberg order is eligible for refresh. The iceberg is refreshed any time the order's displayed quantity is less than the minimum peak size. #### Validity -* The order's non-iceberg-related fields must be set so as to make a valid order. +- The order's non-iceberg-related fields must be set so as to make a valid order. -* Any persistent TIF (GTC, GTT, GFA, GFN) can be an iceberg order. +- Any persistent TIF (GTC, GTT, GFA, GFN) can be an iceberg order. -* An iceberg order may have either an ordinary or pegged limit price. +- An iceberg order may have either an ordinary or pegged limit price. Market iceberg orders are not supported, even if with a persistent TIF. -* Icebergs may be post only. +- Icebergs may be post only. -* `initial peak size` must be greater than or equal to minimum position size (i.e. minimum order size). +- `initial peak size` must be greater than or equal to minimum position size (i.e. minimum order size). -* `minimum peak size` must be `>` 0 and `≤ initial peak size` +- `minimum peak size` must be `>` 0 and `≤ initial peak size` #### Execution and subsequent refresh -* On entry, if an iceberg order is crossed with the best bid/ask, it trades first with its **full quantity**, i.e. the peak sizes do not come into play during aggressive execution. +- On entry, if an iceberg order is crossed with the best bid/ask, it trades first with its **full quantity**, i.e. the peak sizes do not come into play during aggressive execution. This is to prevent an iceberg order ever being crossed after refreshing. -* Once they enter the book passively, iceberg orders trade just like non-iceberg persistent order, as if the order entered the book with `quantity = initial peak size` on submission, and again each time they are refreshed until `remaining == 0` (or they are cancelled or expired, etc.). +- Once they enter the book passively, iceberg orders trade just like non-iceberg persistent order, as if the order entered the book with `quantity = initial peak size` on submission, and again each time they are refreshed until `remaining == 0` (or they are cancelled or expired, etc.). That is: - * On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. + - On entry, unlike normal orders, `displayed quantity` is set to `initial peak size` not `quantity`. - * As for any other order, `remaining == quantity` on entry. + - As for any other order, `remaining == quantity` on entry. -* When an iceberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. +- When an iceberg order trades, both `remaining` and `displayed quantity` are reduced by the trade size. -* Iceberg orders can trade many times without refresh, reducing `displayed quantity` each time. +- Iceberg orders can trade many times without refresh, reducing `displayed quantity` each time. The order will not be refreshed after each trade while `displayed quantity ≥ minimum peak size`. -* When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: +- When `displayed quantity < minimum peak size` and `remaining > displayed quantity` the order will be refreshed: - * The refresh happens at the end of the transaction when the order becomes eligible for refresh. + - The refresh happens at the end of the transaction when the order becomes eligible for refresh. - * On refresh `display quantity` is set to `min(remaining, initial peak size)`. + - On refresh `display quantity` is set to `min(remaining, initial peak size)`. - * A refresh simulates a cancel/replace, which means that on refresh an iceberg order will always lose time priority relative to other orders at the same price. + - A refresh simulates a cancel/replace, which means that on refresh an iceberg order will always lose time priority relative to other orders at the same price. - * If multiple iceberg orders need to be refreshed at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the iceberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). + - If multiple iceberg orders need to be refreshed at the same time, they are refreshed in the order that their eligibility for refresh was triggered, so the iceberg that dropped below its `minimum peak size` first is refreshed first (even during the same transaction the sequence of execution must be respected). -* Once the remaining quantity is equal to the displayed quantity, no further refresh is possible. +- Once the remaining quantity is equal to the displayed quantity, no further refresh is possible. The order now behaves like a normal limit order and will leave the book if it trades away completely. -* For an incoming order with size larger than the total displayed quantity at a given price level, the following procedure should be followed: - - * The incoming order trades with all visible volume at the price level, whether an iceberg order or a vanilla limit order +- For an incoming order with size larger than the total displayed quantity at a given price level, the following procedure should be followed: - * If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. If the distribution doesn't divide exactly stick the extra onto the iceberg which is first in terms of time priority. - - * If there are still remaining iceberg orders at this point, refresh their volumes and continue trading. If the incoming order uses up all iceberg orders at this level, continue with any remaining volume to the next price level. + - The incoming order trades with all visible volume at the price level, whether an iceberg order or a vanilla limit order + + - If there is still remaining volume in the order once all visible volume at the price level is used up, the remaining quantity is split between the non-visible components of all iceberg orders at this level according to their remaining volumes. For example if there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. If the distribution doesn't divide exactly stick the extra onto the iceberg which is first in terms of time priority. + + - If there are still remaining iceberg orders at this point, refresh their volumes and continue trading. If the incoming order uses up all iceberg orders at this level, continue with any remaining volume to the next price level. #### Amendment -* Amending the size of an iceberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quantity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. +- Amending the size of an iceberg order amends the total `remaining` quantity and leaves the `displayed quantity` unaffected unless the new remaining quantity is smaller than the current displayed quantity, in which case the displayed quantity is reduced to the total remaining quantity. -* Amending the size/quantity of an iceberg order does not cause it to lose time priority. +- Amending the size/quantity of an iceberg order does not cause it to lose time priority. This is because the increase applies to the `remaining` quantity and not to the `displayed quantity`. This is allowed because the order will lose time priority on refresh, i.e. before the increased quantity is available to trade. #### Auctions -* Icebergs can be entered or carried into auctions if the underlying TIF is supported. +- Icebergs can be entered or carried into auctions if the underlying TIF is supported. -* Icebergs can trade in the auction uncrossing up to their full `remaining` amount as for any other transaction that would cause a trade with an iceberg order. +- Icebergs can trade in the auction uncrossing up to their full `remaining` amount as for any other transaction that would cause a trade with an iceberg order. If the remainders of multiple icebergs sit at the same price and are not fully used up, the traded volume should be split between them pro-rata by their total total size. Any integer remainder should be allocated to the iceberg with the highest time priority. -* Icebergs are refreshed after an auction uncrossing if they traded to below their `minimum peak size`, according to the same rules as for normal execution. +- Icebergs are refreshed after an auction uncrossing if they traded to below their `minimum peak size`, according to the same rules as for normal execution. #### APIs -* The fields `displayed quantity`, `remaining`, `quantity`, `initial peak size`, `minimum peak size`, `refresh policy` must be exposed by data node APIs in addition to all normal fields for an order. +- The fields `displayed quantity`, `remaining`, `quantity`, `initial peak size`, `minimum peak size`, `refresh policy` must be exposed by data node APIs in addition to all normal fields for an order. -* An iceberg order refresh must generate an event of the event bus. +- An iceberg order refresh must generate an event of the event bus. ### Valid order entry combinations @@ -197,20 +247,20 @@ If the remainders of multiple icebergs sit at the same price and are not fully u Network orders are used during [position resolution](./0012-POSR-position_resolution.md#position-resolution-algorithm). Network orders are orders triggered by Vega to close out positions for distressed traders. -* Network orders have a counterparty of `Network` -* Network orders are a Fill Or Kill, Market orders -* Network orders cannot be submitted by any party, they are created during transaction processing. +- Network orders have a counterparty of `Network` +- Network orders are a Fill Or Kill, Market orders +- Network orders cannot be submitted by any party, they are created during transaction processing. ## Acceptance Criteria -* Immediate orders, continuous trading: - * An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) - * An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) - * An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) - * Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) - * A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) -* No party can submit a [network order type](#network-orders) (0014-ORDT-006) -* A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) +- Immediate orders, continuous trading: + - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) + - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) + - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) + - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) + - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) +- No party can submit a [network order type](#network-orders) (0014-ORDT-006) +- A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's @@ -222,7 +272,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 4. An iceberg reduce only order is rejected (0014-ORDT-010) 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) 6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) - * If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue + - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue 7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013) #### Iceberg Order Batch Submission @@ -273,6 +323,49 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) 2. The additional fields relating to iceberg orders should be available in the streaming api end points +### Stop orders + +- A stop order with reduce only set to false will be rejected. (0014-ORDT-040) +- Once triggered, a stop order is removed from the book and cannot be triggered again. (0014-ORDT-041) +- A stop order placed by a key with a zero position and no open orders will be rejected. (0014-ORDT-042) +- A stop order placed by a key with a zero position but open orders will be accepted. (0014-ORDT-043) +- Attempting to create more stop orders than is allowed by the relevant network parameter will result in the transaction failing to execute. (0014-ORDT-044) + +- A stop order wrapping a limit order will, once triggered, place the limit order as if it just arrived as an order without the stop order wrapping. (0014-ORDT-045) +- A stop order wrapping a market order will, once triggered, place the market order as if it just arrived as an order without the stop order wrapping. (0014-ORDT-046) + +- With a last traded price at 50, a stop order placed with `Rises Above` setting at 75 will be triggered by any trade at price 75 or higher. (0014-ORDT-047) +- With a last traded price at 50, a stop order placed with `Rises Above` setting at 25 will be triggered immediately (before another trade is even necessary). (0014-ORDT-048) +- With a last traded price at 50, a stop order placed with `Falls Below` setting at 25 will be triggered by any trade at price 25 or lower. (0014-ORDT-049) +- With a last traded price at 50, a stop order placed with `Falls Below` setting at 75 will be triggered immediately (before another trade is even necessary). (0014-ORDT-050) + +- With a last traded price at 50, a stop order placed with any trigger price which does not trigger immediately will trigger as soon as a trade occurs at a trigger price, and will not wait until the next mark price update to trigger. (0014-ORDT-051) +- A stop order with expiration time `T` set to expire at that time will expire at time `T` if reached without being triggered. (0014-ORDT-052) +- A stop order with expiration time `T` set to execute at that time will execute at time `T` if reached without being triggered. (0014-ORDT-053) + - If the order is triggered before reaching time `T`, the order will have been removed and will *not* trigger at time `T`. (0014-ORDT-054) + +- A stop order set to trade volume `x` with a trigger set to `Rises Above` at a given price will trigger at the first trade at or above that price. At this time the order will be placed on the book if and only if it would reduce the trader's absolute position (buying if they are short or selling if they are long) if executed (i.e. will execute as a reduce-only order). (0014-ORDT-055) +- If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056) +- If a pair of stop orders are specified as OCO with the same trigger conditions and directions, if that trigger is hit one will execute and the other will expire. The exact choice of which will execute should not be assumed by the trader. (0014-ORDT-057) +- If a pair of stop orders are specified as OCO and one triggers but is invalid at time of triggering (e.g. a buy when the trader is already long) the other will still be cancelled. (0014-ORDT-058) + +- A trailing stop order for a 5% drop placed when the price is `50`, followed by a price rise to `60` will: + - Be triggered by a fall to `57`. (0014-ORDT-059) + - Not be triggered by a fall to `58`. (0014-ORDT-060) +- A trailing stop order for a 5% rise placed when the price is `50`, followed by a drop to `40` will: + - Be triggered by a rise to `42`. (0014-ORDT-061) + - Not be triggered by a rise to `41`. (0014-ORDT-062) +- A trailing stop order for a 25% drop placed when the price is `50`, followed by a price rise to `60`, then to `50`, then another rise to `57` will: + - Be triggered by a fall to `45`. (0014-ORDT-063) + - Not be triggered by a fall to `46`. (0014-ORDT-064) + +- A stop order placed either prior to or during an auction will not execute during an auction, nor will it participate in the uncrossing. (0014-ORDT-065) +- A stop order placed either prior to or during an auction, where the uncrossing price is within the triggering range, will immediately execute following uncrossing. (0014-ORDT-066) + +- If a trader has open stop orders and their position moves to zero whilst they still have open limit orders their stop orders will remain active. (0014-ORDT-067) +- If a trader has open stop orders and their position moves to zero with no open limit orders their stop orders are cancelled. (0014-ORDT-068) + + ### See also -* [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) +- [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) diff --git a/wordlist.txt b/wordlist.txt index 1942a63c8..038713e2e 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -172,6 +172,8 @@ multisignature NFTs nonfungible OAUTH +OCO +OCOs OKR onwards OpenOracle From e17d7e76b4cb2f26d080e6190c2cae457f2b20b0 Mon Sep 17 00:00:00 2001 From: VanithaVega <135214348+VanithaVega@users.noreply.github.com> Date: Tue, 13 Jun 2023 15:56:35 +0100 Subject: [PATCH 121/649] Update 0080-SPOT-product_builtin_spot.md Changed the Network parameter to SpotMarketTradingEnabled --- protocol/0080-SPOT-product_builtin_spot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 31beee024..5245d6052 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -11,7 +11,7 @@ When trading Spot products, parties can only use assets they own - there is no l ## 2. Network Parameter -1. `spot_trading_enabled`: parameter defines whether markets using Spot products are enabled on the network. +1. `SpotMarketTradingEnabled`: parameter defines whether markets using Spot products are enabled on the network. ## 3. Liquidity Monitoring parameters From ff079704a93dee3c705759c92f27908aba9bc42a Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Wed, 14 Jun 2023 12:07:28 +0100 Subject: [PATCH 122/649] chore: add decision about market-depth with regard to iceberg orders (#1747) * chore: add decision about market-depth with regard to iceberg orders * fix: AC codes for approbation * refactor: cosmetic change * fix: MD linting and AC codes --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: Witold Co-authored-by: gordsport --- protocol/0014-ORDT-order_types.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index f190227af..a7f47ec54 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -219,6 +219,8 @@ If the remainders of multiple icebergs sit at the same price and are not fully u - An iceberg order refresh must generate an event of the event bus. +- Any API that returns information about market-depth or the orderbook volume will include an iceberg order's full volume and not just its `display quantity`. + ### Valid order entry combinations @@ -321,7 +323,8 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ### API 1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) -2. The additional fields relating to iceberg orders should be available in the streaming api end points +2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069) +3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070) ### Stop orders From 2bac2294ed2f2b5cb5bd818f86f0e6c167582b19 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 14 Jun 2023 12:48:58 +0100 Subject: [PATCH 123/649] Update 0028-GOVE-governance.md 0028-GOVE-076 (#1741) * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index a2e780a98..df1d4132b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -513,7 +513,6 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Transfer proposal submission validation - Proposals are either permitted or rejected according to the following source/destination combinations. (0028-GOVE-075) -- Transfer amount and fraction of balance are mutually exclusive and will cause the proposal to reject (0028-GOVE-076) - Invalid source and destination account types will cause the proposal to reject (0028-GOVE-077) - Source Type can be any of the predefined types in the above table (0028-GOVE-078) - Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) From f0cbd4a30b992320d0bc1c446dda8f2dd58c0ce3 Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 15 Jun 2023 11:32:15 +0100 Subject: [PATCH 124/649] chore: Remove invalid ac relating to minimum order size --- protocol/0014-ORDT-order_types.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index a7f47ec54..fba6197c8 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -287,10 +287,9 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016) 2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017) 3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018) -4. An iceberg order with initial peak size less than the minimum order size rejected with a valid error message (0014-ORDT-019) -5. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) -6. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) -7. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) +4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) +5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) +6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) #### Iceberg Order Amendment From 030aa98cdf42be99563e8bdb3e27d1929186e7ff Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 15 Jun 2023 12:51:05 +0100 Subject: [PATCH 125/649] refactor: clarify iceberg wash trading AC --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index fba6197c8..edbdfd2b9 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -310,7 +310,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu 5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) 6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032) 7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) -8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue , another normal order in opposite direction , the iceberg at the back comes in front and matches either fully OR partially and gets rejected( 0014-ORDT-034) +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034) 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) From c52e9d7dad03fbeefd92dc4ef2a8e83b155a66be Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 15 Jun 2023 15:50:30 +0100 Subject: [PATCH 126/649] chore: tidy up spec feature heading text (#1767) The feature header here mentioned that it was "post Oregon Trail". Now we have the master and feature (milestone) branches this is no longer required and clutters the real information. --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index df1d4132b..576194d71 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -265,7 +265,7 @@ Enactment of an asset modification proposal is: - For data that must be synchronised with the asset blockchain (e.g. Ethereum): _only_ the emission of a signed bundle that can be submitted to the bridge contract; the changed values [asset framework spec](./0040-ASSF-asset_framework.md) only become reflected on the Vega chain once the usual number of confirmations of the effect of this change is emitted by the bridge chain. - For any data that is stored only on the Vega chain: the data is updated once the proposal is enacted. -## 5. Transfers initiated by Governance (post Oregon trail) +## 5. Transfers initiated by Governance ### Permitted source and destination account types From 94f4a54a09aed136d0694e2f3d5131fb6e792ca9 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 9 Mar 2023 14:27:58 +0100 Subject: [PATCH 127/649] refactor: add market closure proposal --- protocol/0028-GOVE-governance.md | 42 ++++++++++++++++++++++++-- protocol/0043-MKTL-market_lifecycle.md | 27 +++++++++++++++-- 2 files changed, 65 insertions(+), 4 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 576194d71..806e59a51 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -355,7 +355,37 @@ All in memory active governance transfers must be included in the snapshot of th 4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. 5. Governance initiated transfers are subject to neither minimum transfer amounts nor to fees. -## 6. Freeform governance proposal +## 6. Change market state + +A governance proposal to change the state of the market. +Multiple concurrent proposals are allowed. If more than one gets successfully voted in the one which arrived last gets used. If a proposal has already been successful then additional market state change proposals are still allowed as long as their enactment date is no later then that of the last successful vote. + +Refer to subsections below for allowed state changes. + +### 6.1. Move market to a closed state + +Any type of market (either fixed expiry market or perpetual) can be closed via a governance vote. + +A proposal to close a market contains: + +1. an enactment time +1. final settlement price (not required for spot markets) + +Once market is closed the process cannot be reversed. + +### 6.2. Suspend the market + +This proposal puts the market into an auction mode which can only be exit with a governance proposal to unsuspend the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. + +A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. + +[Market change proposal](#market-change-proposals) voting rules apply. + +### 6.3. Unsuspend the market + +This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. + +## 7. Freeform governance proposal The aim of this is to allow community to provide votes on proposals which don't change any of the behaviour of the currently running Vega blockchain. That is to say, at enactment time, no changes are effected on the system, but the record of how token holders voted will be stored on chain. The proposal will contain only the fields common to all proposals i.e. @@ -470,7 +500,15 @@ APIs should also exist for clients to: - A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) - In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) - A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) - +- A governance proposal to close a market which doesn't specify the final settlement price gets rejected buy the markets which require it (non-spot). (0028-GOVE-108) +- When multiple market closure governance proposals are submitted and accepted then one to arrive last is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109) +- Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) +- Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) +- Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) +- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-112) +- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-113) +- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-114) +- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-115) #### Network parameter change proposals diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 08c693d12..3dedb3980 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -173,7 +173,7 @@ Suspension currently always operates as an auction call period. Depending on the ### Closed -Note, this governance action is unspecified and not MVP. +Market goes into a closed state if a [governance vote to close it](./0028-GOVE-governance.md#6-close-market) passes and its enactment date is reached. **Entry:** @@ -185,7 +185,7 @@ No exit. This is a terminal state. **Behaviour:** -- Orders may be cancelled, no new orders accepted. Something will need to be done to unwind positions. +- If market is in auction that auction gets uncrossed and any orders matched within it result in trades. All other orders get cancelled, no new orders are accepted, liquidity commitments cannot be modified, final settlement is carried out using the price supplied by the governance vote. ### Trading Terminated @@ -295,3 +295,26 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. After `market.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. + +### Market gets closed via a governance proposal (0043-MKTL-004) + +1. Once the governance proposal to close the market gets enacted any auction that the market may be in gets uncrossed and trades get generated. +1. All the other orders are cancelled and no further trades get generated. +1. Any new orders get rejected. +1. Liquidity commitments cannot be modified or cancelled. +1. Final settlement is carried out and the transfers reflect the difference in the last mark price and the final settlement price supplied by the governance proposal. +1. All the funds from market specific accounts get released to appropriate accounts. +1. Market gets deleted. + +### Market gets suspended via a governance proposal + +1. Once the governance proposal to suspend the market gets enacted the market gets immediately put into auction mode, if market was already in auction mode it remains in it. +1. No cashflows are exchanged when market has been suspended via a governance proposal. +1. Parties cannot modify their open interest +1. The prerequisite for a market to go out of auction mode is now a successful enactment of a governance proposal to unsuspend that market. + +### Market gets unsuspended via a governance proposal + +1. Once the governance proposal to unsuspend the market gets enacted the market can now leave the auction. +1. If no other auction triggers are active the market goes back into its default trading mode immediately (auction gets uncrossed and trades get generated). +1. If other auction triggers are active the market remains in auction mode until these allow it to leave it. From e4c8de65734d954cf9605123f7c96df464d22c60 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 14 Jun 2023 13:23:35 +0200 Subject: [PATCH 128/649] refactor: fix AC codes --- protocol/0028-GOVE-governance.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 806e59a51..6aa5f8122 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -505,10 +505,10 @@ APIs should also exist for clients to: - Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) - Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) - Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) -- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-112) -- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-113) -- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-114) -- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-115) +- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-113) +- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) +- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) +- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) #### Network parameter change proposals From 9ab989d8cfc7c9a13c003a549e5dde1736edfd8a Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 14 Jun 2023 13:29:37 +0200 Subject: [PATCH 129/649] chore: fix spellcheck errors --- wordlist.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/wordlist.txt b/wordlist.txt index 038713e2e..def9b185a 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -275,6 +275,9 @@ unstake unstaked unstakes unstaking +unsuspend +unsuspended +unsuspending unvested url USD From 2025f63abb474c17e957bf124f2717e54c5e2231 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Jun 2023 15:38:04 +0200 Subject: [PATCH 130/649] refactor: apply suggestions from code review Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 4 ++-- protocol/0043-MKTL-market_lifecycle.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 6aa5f8122..e833c073b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -500,8 +500,8 @@ APIs should also exist for clients to: - A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) - In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) - A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) -- A governance proposal to close a market which doesn't specify the final settlement price gets rejected buy the markets which require it (non-spot). (0028-GOVE-108) -- When multiple market closure governance proposals are submitted and accepted then one to arrive last is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109) +- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108) +- When multiple market closure governance proposals are submitted and accepted then one to be approved by governance last (i.e latest closing date and vote goes through) is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109) - Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) - Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) - Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 3dedb3980..cd946bb62 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -303,7 +303,7 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. Any new orders get rejected. 1. Liquidity commitments cannot be modified or cancelled. 1. Final settlement is carried out and the transfers reflect the difference in the last mark price and the final settlement price supplied by the governance proposal. -1. All the funds from market specific accounts get released to appropriate accounts. +1. All the funds from market specific accounts get released to appropriate accounts; the insurance pool perhaps after the delay to allow for transfer into a successor market. 1. Market gets deleted. ### Market gets suspended via a governance proposal From de0b3e6f0d7d3d566a412b15625f649f001313ff Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Jun 2023 15:53:47 +0200 Subject: [PATCH 131/649] refactor: clarify voting rules --- protocol/0028-GOVE-governance.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index e833c073b..b9406a97f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -86,6 +86,8 @@ Anyone can create a proposal if the weighting of their vote on the proposal woul In a future iteration of the governance system we may restrict proposal submission by type of proposal based on a minimum weighting. e.g: only user with a certain number or percentage of the governance asset are allowed to open a "network parameter change" proposal. +### Market change proposal + Market change proposals additionally require certain minimum [Equity-like share](0042-LIQF-setting_fees_and_rewarding_lps.md) set by `governance.proposal.updateMarket.minProposerEquityLikeShare`. So, for example, if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0.05` and a party has `equity-like share` on the market of `0.3` then they can make a market change proposal. If, on the other hand, a party has `equity-like share` of `0.03` then they cannot submit a market change proposal. @@ -141,10 +143,12 @@ Note: see below for details on minimum participation rate and minimum required m Not in scope: minimum participation of active users, i.e. 90% of the _active_ users of the vega network have to take part in the vote. Minimum participation is currently always measured against the total possible participation. +### Market change proposal outcome + For market change proposals the network will additionally calculate 1. `LP participation rate = SUM (equity-like share of all LPs who cast a vote)` (no need to divide by anything as equity-like share sums up to `1`). -1. `LP for rate = SUM (all who voted for) / LP participation rate`. +1. `LP for rate = SUM (equity-like share of all LPs who cast a for vote)) / LP participation rate`. If the market that the proposal is changing is pending (so accepted but hasn't left opening auction yet) at the vote resolution time then only token holder votes are used. @@ -360,6 +364,8 @@ All in memory active governance transfers must be included in the snapshot of th A governance proposal to change the state of the market. Multiple concurrent proposals are allowed. If more than one gets successfully voted in the one which arrived last gets used. If a proposal has already been successful then additional market state change proposals are still allowed as long as their enactment date is no later then that of the last successful vote. +Market change proposal [creation](#market-change-proposal) and [voting](#market-change-proposal-outcome) rules apply. + Refer to subsections below for allowed state changes. ### 6.1. Move market to a closed state @@ -379,7 +385,6 @@ This proposal puts the market into an auction mode which can only be exit with a A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. -[Market change proposal](#market-change-proposals) voting rules apply. ### 6.3. Unsuspend the market From 1886c400faeab5e0c3a3dcf5c24d9b49a813a784 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Jun 2023 18:04:07 +0200 Subject: [PATCH 132/649] refactor: apply suggestions from code review Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index b9406a97f..5731d1f87 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -148,7 +148,7 @@ Not in scope: minimum participation of active users, i.e. 90% of the _active_ us For market change proposals the network will additionally calculate 1. `LP participation rate = SUM (equity-like share of all LPs who cast a vote)` (no need to divide by anything as equity-like share sums up to `1`). -1. `LP for rate = SUM (equity-like share of all LPs who cast a for vote)) / LP participation rate`. +1. `LP for rate = SUM (equity-like share of all LPs who cast a for vote))`. If the market that the proposal is changing is pending (so accepted but hasn't left opening auction yet) at the vote resolution time then only token holder votes are used. From bde0cd729ad90cc36ec49ecfa8818a1e62d7567f Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Jun 2023 18:32:22 +0200 Subject: [PATCH 133/649] refactor: AND -> OR --- protocol/0028-GOVE-governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 5731d1f87..0c293d1db 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -88,8 +88,8 @@ In a future iteration of the governance system we may restrict proposal submissi ### Market change proposal -Market change proposals additionally require certain minimum [Equity-like share](0042-LIQF-setting_fees_and_rewarding_lps.md) set by `governance.proposal.updateMarket.minProposerEquityLikeShare`. -So, for example, if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0.05` and a party has `equity-like share` on the market of `0.3` then they can make a market change proposal. If, on the other hand, a party has `equity-like share` of `0.03` then they cannot submit a market change proposal. +Market change proposals can also be submitted by any party which has at least the minimum [Equity-like share](0042-LIQF-setting_fees_and_rewarding_lps.md) set by `governance.proposal.updateMarket.minProposerEquityLikeShare`. Note that such a party can submit a proposal even if it doesn't hold any amount of the governance token. +So, for example, if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0.05` and a party has `equity-like share` on the market of `0.3` and no governance tokens then they can make a market change proposal. If, on the other hand, a party has `equity-like share` of `0.03` and no governance tokens then they cannot submit a market change proposal. ### Duration of the proposal From 12b10e48e95ef0dd636ab77071fc66e00d730efa Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 15 Jun 2023 19:22:13 +0200 Subject: [PATCH 134/649] refactor: ACs or didn't happen --- protocol/0028-GOVE-governance.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 0c293d1db..765fcc3bf 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -514,6 +514,8 @@ APIs should also exist for clients to: - Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) - Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) - A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) +- Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117) +- Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118) #### Network parameter change proposals From 68ccde9204bf3e884001fcbce7fcae1e6b6f1608 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Mon, 19 Jun 2023 11:44:18 +0100 Subject: [PATCH 135/649] fix: Split ACs for some successor market cases to acknowledge the fact that they need different tests. --- protocol/0001-MKTF-market_framework.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 781ea2663..fe446eebf 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -236,4 +236,7 @@ Each market can have exactly one market as a *successor* market. - It is possible to designate a market as perpetual; this is visible via APIs in market data. 0001-MKTF-005 - A market may have a "parent" market; the parent market is visible via APIs in the form of the `marketID` of the parent market. 0001-MKTF-006 - A market may have a "successor" market; the parent market is visible via APIs in the form of the `marketID` (or `proposalID`) of the successor market. 0001-MKTF-007 -- A parent and successor markets must have the same product, settlement asset(s) and margin asset(s). 0001-MKTF-008 +- A parent and successor markets must have the same: + - product 0001-MKTF-008 + - settlement asset(s) 0001-MKTF-009 + - margin asset(s). 0001-MKTF-010 From 83d2024b9fbbc00f26f09f3cf0d55282af5eadb5 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 19 Jun 2023 16:54:13 +0100 Subject: [PATCH 136/649] fix: Remove GOVE-095 AC as it seemingly contradicts spec itself (#1770) * fix: Remove GOVE-095 AC as it seemingly contradicts spec itself * fix/update-GOVE-095 --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 765fcc3bf..7c59f45d0 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -580,7 +580,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Governance transfer enactment - For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094) -- When insufficient tokens are found in the source account at time of transfer (enactment) a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-095) +- A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095) - Transfers can occur for terminated markets (0028-GOVE-096) - Transfers cannot occur for settled markets and a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-097) - Transfers cannot occur for pending markets unless they become active on or before the enactment time of the transfer (0028-GOVE-098) From 8d6512c87ec9d1f355d2d8a4fb8c43ba10c17d0d Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 20 Jun 2023 16:30:48 +0100 Subject: [PATCH 137/649] fix: market.liquidity.successorLaunchWindowLength is used correctly and market.value.windowLength is left alone --- protocol/0081-SUCM-successor_markets.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 644117135..c16c88899 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -15,14 +15,14 @@ Moreover, part of the insurance pool of a parent market can be earmarked for tra ## Relevant network / market parameters -- `market.value.windowLength` is a network parameter specifying how long, after a market has settled, the LPs virtual stakes are retained and the insurance pool is left undistributed to allow a successor to be defined. +- `market.liquidity.successorLaunchWindowLength` is a network parameter specifying how long, after a market has settled, the LPs virtual stakes are retained and the insurance pool is left undistributed to allow a successor to be defined. - `parent market Id` is part of market proposal which can optionally specify a parent market; see [governance](./0028-GOVE-governance.md). - `insurancePoolFraction` is is part of market proposal which can optionally specify how much of the insurance pool of the parent is to be transferred to the successor; see [governance](./0028-GOVE-governance.md). ## Specifying a parent market and timing details A market [governance] proposal for a successor market must contain all the information of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. -The product, settlement asset, margin asset, and `market.value.windowLength` must match but all other inputs can be different (e.g. position and price decimal places, risk mode, price monitoring, termination and settlement oracles etc.). +The product, settlement asset, and margin asset must match but all other inputs can be different (e.g. position and price decimal places, risk mode, price monitoring, termination and settlement oracles etc.). For [spot markets](./0080-SPOT-product_builtin_spot.md) base and quote assets must match. The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` @@ -62,16 +62,16 @@ At the end of opening auction, if the parent market still exists, the fraction o Market proposal may specify parent market ID. If it does then: - It must also specify insurance pool fraction (0081-SUCM-001) -- The product, settlement asset, margin asset, and `market.value.windowLength` must match between parent and successor; if not proposal is rejected (0081-SUCM-002) +- The product, settlement asset and margin asset must match between parent and successor; if not proposal is rejected (0081-SUCM-002) - It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market's parent market Id field is cleared. When it clears the opening auction it gets no insurance pool from the parent and no virtual stakes get carried over (0081-SUCM-005). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.value.windowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.value.windowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) Successor markets can be enacted if the parent market is still in the "proposed" state. There is no virtual stake to copy over and no insurance pool balance to transfer (0081-SUCM-008) From 54cef2630a0e7adfd01ea52ab1ec3b5f6ca03cdc Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 21 Jun 2023 11:27:55 +0100 Subject: [PATCH 138/649] fix: Update protocol/0080-SPOT-product_builtin_spot.md --- protocol/0080-SPOT-product_builtin_spot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 5245d6052..c069da5eb 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -11,7 +11,7 @@ When trading Spot products, parties can only use assets they own - there is no l ## 2. Network Parameter -1. `SpotMarketTradingEnabled`: parameter defines whether markets using Spot products are enabled on the network. +1. `limits.markets.proposeSpotEnabled`: parameter defines whether markets using Spot products are enabled on the network. ## 3. Liquidity Monitoring parameters From 3eb099a550a19b604004b632f846c3c4308a1203 Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:07:32 +0300 Subject: [PATCH 139/649] Update protocol/0081-ETHD-ethereum-data-source.md --- protocol/0081-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-ETHD-ethereum-data-source.md b/protocol/0081-ETHD-ethereum-data-source.md index 6087f4a60..f87f0bd60 100644 --- a/protocol/0081-ETHD-ethereum-data-source.md +++ b/protocol/0081-ETHD-ethereum-data-source.md @@ -34,7 +34,7 @@ The event queue may evaluate filters before submitting the observation to the Ve An Ethereum oracle has as its subject a smart contract that is deployed on the Ethereum blockchain. All such contracts have an address, and an "ABI" that defines the methods an events exposed by the contract. -In order interpret the oracle specification and interact with the smart contract, both the contract address and Ethereum ABI JSON for the contract (or a subset, covering the relevant parts) must therefore be included in the oracle specification. +In order to interpret the oracle specification and interact with the smart contract, both the contract address and Ethereum ABI JSON for the contract (or a subset, covering the relevant parts) must therefore be included in the oracle specification. Event data and data returned from functions will be emitted by the Ethereum node in an ABI-encoded format. This data, including any structs should be decoded using the ABI into a JSON-like representation. From 882babed1fa9442dbf9dff235057129a3b14774c Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:07:38 +0300 Subject: [PATCH 140/649] Update protocol/0081-ETHD-ethereum-data-source.md --- protocol/0081-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-ETHD-ethereum-data-source.md b/protocol/0081-ETHD-ethereum-data-source.md index f87f0bd60..6fa38d24e 100644 --- a/protocol/0081-ETHD-ethereum-data-source.md +++ b/protocol/0081-ETHD-ethereum-data-source.md @@ -39,7 +39,7 @@ In order to interpret the oracle specification and interact with the smart contr Event data and data returned from functions will be emitted by the Ethereum node in an ABI-encoded format. This data, including any structs should be decoded using the ABI into a JSON-like representation. -Note: as with any data source containing JSON formatted (or other arbitrary structured) data, the data required by the consumer of the data source may be a fields or sub-objects (including nested fields and objects). +Note: as with any data source containing JSON formatted (or other arbitrary structured) data, the data required by the consumer of the data source may be a number of fields or sub-objects (including nested fields and objects). The data sourcing framework therefore requires functionality to apply a query/selector extract the relevant subset of the observed data and pass it to the next consumer. This would be expected to use `JSONPath`/`JSONPointer` or similar, and be applicable to any arbitrary JSON. Regardless, the specification of this functionality is out of scope for this document and the approach must be standardised across the data sourcing framework (for example, specifying the target of filters must use the same format as selecting data to pass on). From c9a2354bc977cb2e7e3d0033e9f22f431a69d194 Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:07:44 +0300 Subject: [PATCH 141/649] Update protocol/0081-ETHD-ethereum-data-source.md --- protocol/0081-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-ETHD-ethereum-data-source.md b/protocol/0081-ETHD-ethereum-data-source.md index 6fa38d24e..69a9de3c1 100644 --- a/protocol/0081-ETHD-ethereum-data-source.md +++ b/protocol/0081-ETHD-ethereum-data-source.md @@ -118,7 +118,7 @@ Select { ### External Oracles - Amendments 1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted (0081-ETHD-005) -2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted , the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-006) +2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted, the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-006) 3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-007) ### External Oracles - Deletions From 58041454ff7cc1286f58aad3fe027fa23083d5af Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Wed, 21 Jun 2023 15:08:13 +0300 Subject: [PATCH 142/649] Update protocol/0081-ETHD-ethereum-data-source.md --- protocol/0081-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-ETHD-ethereum-data-source.md b/protocol/0081-ETHD-ethereum-data-source.md index 69a9de3c1..3d31d3938 100644 --- a/protocol/0081-ETHD-ethereum-data-source.md +++ b/protocol/0081-ETHD-ethereum-data-source.md @@ -54,7 +54,7 @@ All data sourced from Ethereum should be structured as an object containing both - Ethereum block timestamp at which the data was observed/event occurred -These data can be used as the subject of filters or even extracted as the oracle data of interest. +This data can be used as the subject of filters or even extracted as the oracle data of interest. Filters on Ethereum block height, Ethereum timestamp, or Vega timestamp should be applied prior to submitting the data to the Vega chain, in addition to being re-applied when the data is confirmed on chain. This would prevent spamming the Vega chain with event data that is not relevant. From f150adf856d253b9e89bea245467b7810b180e7b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 22 Jun 2023 09:17:46 +0100 Subject: [PATCH 143/649] feat: remove redundnt network parameter --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index babd053c6..03e2829a6 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -370,7 +370,6 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-048) - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) - If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) -- If `market.liquidity.providers.fee.distributionTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-036) ### Calculating SLA Performance From 033926630fc80096e4883311f547bc7091339bf1 Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 22 Jun 2023 23:29:40 +0100 Subject: [PATCH 144/649] chore: Add more acceptance criteria for Stop Orders --- protocol/0014-ORDT-order_types.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index edbdfd2b9..06528c7fd 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -367,6 +367,25 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu - If a trader has open stop orders and their position moves to zero whilst they still have open limit orders their stop orders will remain active. (0014-ORDT-067) - If a trader has open stop orders and their position moves to zero with no open limit orders their stop orders are cancelled. (0014-ORDT-068) +- A Stop order that hasn't been triggered can be cancelled. (0014-ORDT-071) +- All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072) +- All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073) + +## Stop Orders - Negative Cases: + +- Stop orders submitted with post_only=True are rejected. (0014-ORDT-074) +- Stop orders submitted with invalid values for trigger price (0, -ve values) and trailing percentage (0, -ve values) are rejected. (0014-ORDT-075) +- Stop orders submitted with expiry in the past are rejected. (0014-ORDT-076) +- GFA Stop orders submitted are rejected. (0014-ORDT-077) +- Stop orders once triggered can not be cancelled. (0014-ORDT-078) + +## Stop Orders - Snapshots: + +- Stop orders are saved and can be restored using the snapshot and will be triggered once the trigger conditions are met. (0014-ORDT-079) + +## Stop Orders - API: + +- API end points should be available to query stop orders with all relevant fields. (0014-ORDT-080) ### See also From 8d25393ff73c0f0d50f8cc68c9ee5e2c1c1702a5 Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 22 Jun 2023 23:35:49 +0100 Subject: [PATCH 145/649] chore: Tidy up --- protocol/0014-ORDT-order_types.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 06528c7fd..3670cc84a 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -371,19 +371,19 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu - All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072) - All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073) -## Stop Orders - Negative Cases: +## Stop Orders - Negative Cases - Stop orders submitted with post_only=True are rejected. (0014-ORDT-074) -- Stop orders submitted with invalid values for trigger price (0, -ve values) and trailing percentage (0, -ve values) are rejected. (0014-ORDT-075) +- Stop orders submitted with invalid values for trigger price (0, negative values) and trailing percentage (0, negative values) are rejected. (0014-ORDT-075) - Stop orders submitted with expiry in the past are rejected. (0014-ORDT-076) - GFA Stop orders submitted are rejected. (0014-ORDT-077) - Stop orders once triggered can not be cancelled. (0014-ORDT-078) -## Stop Orders - Snapshots: +## Stop Orders - Snapshots - Stop orders are saved and can be restored using the snapshot and will be triggered once the trigger conditions are met. (0014-ORDT-079) -## Stop Orders - API: +## Stop Orders - API - API end points should be available to query stop orders with all relevant fields. (0014-ORDT-080) From a53fe74d13b018c1924eba8fd703becc23e40bf3 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Mon, 26 Jun 2023 19:23:10 +0100 Subject: [PATCH 146/649] Add ACs for Gov Transfer cancellation proposal/network history restore/split permitted combos into ACs (#1786) * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Transfer cancellation ACs * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md --- protocol/0028-GOVE-governance.md | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 7c59f45d0..2db190bd7 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -557,19 +557,22 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Transfer proposal submission validation -- Proposals are either permitted or rejected according to the following source/destination combinations. (0028-GOVE-075) -- Invalid source and destination account types will cause the proposal to reject (0028-GOVE-077) -- Source Type can be any of the predefined types in the above table (0028-GOVE-078) +- A proposal to transfer tokens between Network treasury and Party general account(s) is valid (0028-GOVE-128) +- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119) +- A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120) +- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121) +- A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122) +- Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) - Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) - Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080) -- For transfer source types of Market Insurance the source must be a valid market ID else is rejected (0028-GOVE-081) +- For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081) - Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082) - Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083) - Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084) - Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085) - Destination Type can be any of the predefined types in the above table (0028-GOVE-086) - Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087) -- Destination must be a valid Reward Scheme ID for a transfer type of Reward Pool else is rejected (0028-GOVE-088) +- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088) - Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089) - Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090) - For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091) @@ -616,4 +619,14 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Cancelling governance transfers -- Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) +- Only recurring governance transfers can be cancelled by proposing a governance transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) +- After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123) +- Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) +- Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) +- When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126) + + +##### Network History + +- A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127) + From fbcecb99f9d01dda6e0c75ae29d56ef1a92b98a5 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 27 Jun 2023 11:00:56 +0100 Subject: [PATCH 147/649] feat: add ACs for 0004-AMND --- protocol/0004-AMND-amends.md | 54 +++++++++++++++++++----------------- 1 file changed, 28 insertions(+), 26 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 6a162c945..226b27e7f 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -2,36 +2,38 @@ ## Acceptance Criteria -- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001) -- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002) -- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003) -- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004) -- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005) -- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006) -- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007) -- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008) -- The `orderID` remains the same after an amend (0004-AMND-009) -- Amends can occur in continuous trading or in an auction (0004-AMND-010) -- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011) -- All amendable fields can be amended in the same amend message (0004-AMND-012) -- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013) -- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014) -- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015) -- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016) -- A parked pegged order can be amended. (0037-OPEG-014) -- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017) -- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018) -- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019) -- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029) +- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001)(0004-SP-AMND-001) +- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002)(0004-SP-AMND-002) +- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003)(0004-SP-AMND-003) +- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004)(0004-SP-AMND-004) +- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005)(0004-SP-AMND-005) +- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006)(0004-SP-AMND-006) +- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007)(0004-SP-AMND-007) +- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008)(0004-SP-AMND-008) +- The `orderID` remains the same after an amend (0004-AMND-009)(0004-SP-AMND-009) +- Amends can occur in continuous trading or in an auction (0004-AMND-010)(0004-SP-AMND-010) +- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011)(0004-SP-AMND-011) +- All amendable fields can be amended in the same amend message (0004-AMND-012)(0004-SP-AMND-012) +- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013)(0004-SP-AMND-013) +- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014)(0004-SP-AMND-014) +- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015)(0004-SP-AMND-015) +- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016)(0004-SP-AMND-016) +- A parked pegged order can be amended. (0037-OPEG-014)(0037-SP-OPEG-014) +- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017)(0004-SP-AMND-017) +- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018)(0004-SP-AMND-018) +- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019)(0004-SP-AMND-019) +- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029)(0004-SP-AMND-029) For a party with no position on a given market: -- amending an order in a way that increases the volume sufficiently leads to margin account balance increasing (0004-AMND-021) +- Amending an order in a way that increases the volume sufficiently leads to margin account balance increasing (0004-AMND-021) +- In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-AMND-021) - Amending an order in a way that decreases the volume sufficiently leads to margin account balance decreasing (0004-AMND-022) -- It is possible to amend a fractional size order (0004-AMND-025) -- It is possible to amend a partially filled limit order (0004-AMND-026) -- It is possible to amend a versioned order (already amended several times) (0004-AMND-027) -- Attempts to amend order fields not in scope are rejected (0004-AMND-028) +- In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-AMND-022) +- It is possible to amend a fractional size order (0004-AMND-025)(0004-SP-AMND-025) +- It is possible to amend a partially filled limit order (0004-AMND-026)(0004-SP-AMND-026) +- It is possible to amend a versioned order (already amended several times) (0004-AMND-027)(0004-SP-AMND-027) +- Attempts to amend order fields not in scope are rejected (0004-AMND-028)(0004-SP-AMND-028) ## Summary From 73c1fa41430efdde6f2247c63f49bb7187ede2ab Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 27 Jun 2023 11:05:10 +0100 Subject: [PATCH 148/649] chore: update AC code --- protocol/0004-AMND-amends.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 226b27e7f..86a136a20 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -27,9 +27,9 @@ For a party with no position on a given market: - Amending an order in a way that increases the volume sufficiently leads to margin account balance increasing (0004-AMND-021) -- In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-AMND-021) +- In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-SP-AMND-021) - Amending an order in a way that decreases the volume sufficiently leads to margin account balance decreasing (0004-AMND-022) -- In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-AMND-022) +- In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-SP-AMND-022) - It is possible to amend a fractional size order (0004-AMND-025)(0004-SP-AMND-025) - It is possible to amend a partially filled limit order (0004-AMND-026)(0004-SP-AMND-026) - It is possible to amend a versioned order (already amended several times) (0004-AMND-027)(0004-SP-AMND-027) From ca2782610281389b575eb03d10d4939599002c65 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 27 Jun 2023 13:22:10 +0100 Subject: [PATCH 149/649] added ACs 27-32 --- protocol/0044-LIME-lp_mechanics.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index a966df052..8cfa392ee 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -300,15 +300,27 @@ Note: - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the bond stake has been slashed to a level lower than the amendment, this slashed level will be retained (i.e. the protocol will not attempt to now increase the commitment) (0044-LIME-020) - If a liquidity provider with an active liquidity provision at the start of an epoch amends the fee level associated to this commitment during the epoch, this change will only take effect at the end of the epoch. (0044-LIME-021) +- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to increase the bond to the new level if they do not have sufficient collateral in the settlement asset of the market to meet new commitment amount then the amendment will be rejected and old commitment amount is retained (0044-LIME-032) +- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will increase the bond to the new level if they have sufficient collateral in the settlement asset of the market to meet new commitment amount (0044-LIME-033) - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-025) -- - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) +- When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) + +**Order Types** +- Once liquidity is committed LPs can meet their commitment by placing pegged, limit, post only and iceberg (only the visible peak counts towards the commitment) orders (0044-LIME-028) +- Parked pegged and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) + +**Checkpoint** +- Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) + +**Protocol upgrade** +- After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) \ No newline at end of file From b5058c9f80ecb99e22d009d9dc1c6bd95a01c96f Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 27 Jun 2023 13:36:29 +0100 Subject: [PATCH 150/649] fix: markdown lint --- protocol/0044-LIME-lp_mechanics.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 8cfa392ee..f574ad49a 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -313,14 +313,17 @@ Note: - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) + - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) -**Order Types** +####Qualifying Order Types - Once liquidity is committed LPs can meet their commitment by placing pegged, limit, post only and iceberg (only the visible peak counts towards the commitment) orders (0044-LIME-028) - Parked pegged and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) -**Checkpoint** +####Checkpoint + - Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) -**Protocol upgrade** -- After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) \ No newline at end of file +####Protocol upgrade + +- After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) From 7762c88828079d01f8c4007a72d60415fcaed147 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 27 Jun 2023 13:47:52 +0100 Subject: [PATCH 151/649] fix: more md lint issues --- protocol/0044-LIME-lp_mechanics.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f574ad49a..da328fee1 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -316,14 +316,14 @@ Note: - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) -####Qualifying Order Types +#### Qualifying Order Types - Once liquidity is committed LPs can meet their commitment by placing pegged, limit, post only and iceberg (only the visible peak counts towards the commitment) orders (0044-LIME-028) - Parked pegged and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) -####Checkpoint +#### Checkpoint - Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) -####Protocol upgrade +#### Protocol upgrade - After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) From 34f6397b185dedae68e78958e36a14cee7db4895 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 27 Jun 2023 13:56:35 +0100 Subject: [PATCH 152/649] fix: heading levels md lint --- protocol/0044-LIME-lp_mechanics.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index da328fee1..c2fea5736 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -316,14 +316,15 @@ Note: - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) -#### Qualifying Order Types +### Qualifying Order Types + - Once liquidity is committed LPs can meet their commitment by placing pegged, limit, post only and iceberg (only the visible peak counts towards the commitment) orders (0044-LIME-028) - Parked pegged and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) -#### Checkpoint +### Checkpoint - Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) -#### Protocol upgrade +### Protocol upgrade - After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) From 06e154125f77c93aa3c1d221f37e33deda163b91 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Tue, 27 Jun 2023 15:09:04 +0100 Subject: [PATCH 153/649] Gov transfers - Snapshots, Checkpoints, PULP and other missing ACs (#1790) * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update protocol/0028-GOVE-governance.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 2db190bd7..a7e5a542f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -561,6 +561,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119) - A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120) - A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121) +- A proposal to transfer tokens between Market insurance pool account and Network treasury is valid (0028-GOVE-132) - A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122) - Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) - Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) @@ -602,11 +603,21 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Protocol Upgrade -- Transfer proposals in either a pre or post enactment state are not restored after a protocol upgrade (0028-GOVE-102) +- Transfer proposals in either a pre or post enactment state are restored after a protocol upgrade (0028-GOVE-102) +- Recurring transfers proposed before an upgrade which start before, during or after an upgrade should complete on the proposed end epoch (0028-GOVE-130) +- One off delivery transfers proposed before an upgrade which are due to start during or after an upgrade should complete either when the network is available again or at the proposed delivery date/time (0028-GOVE-131) -#### Checkpoints and Snapshots -- Active governance transfer (one-off or recurring) must be included in checkpoint and snapshot (0028-GOVE-103) +##### Checkpoints and Snapshots + +- Active or dormant governance transfer (one-off or recurring) must be included in checkpoint and where the network is down during the proposed delivery time, the transfer will occur as soon as the network is available. For recurring transfers the transfers spanning the restore will continue until the end epoch. (0028-GOVE-103) +- Active or dormant governance transfer (one-off or recurring) must be included in snapshots and data nodes which join the network will support retrieval of the transfer data (0028-GOVE-133) + + +##### One Off Delivery transfers + +If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. (0028-GOVE-129) + ##### Recurring Governance transfers @@ -629,4 +640,3 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Network History - A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127) - From cfd9ef769b9cd84680cccac70aeed167be14bdbb Mon Sep 17 00:00:00 2001 From: Elias Van Ootegem Date: Tue, 27 Jun 2023 16:40:44 +0100 Subject: [PATCH 154/649] update spec for parent in proposed state Signed-off-by: Elias Van Ootegem --- protocol/0081-SUCM-successor_markets.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index c16c88899..6f9b9de01 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -73,9 +73,9 @@ A new market proposal sets parent market Id to a market that has settled. The pa A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) -Successor markets can be enacted if the parent market is still in the "proposed" state. There is no virtual stake to copy over and no insurance pool balance to transfer (0081-SUCM-008) +Successor markets cannot be enacted if the parent market is still in the "proposed" state. (0081-SUCM-008) -Successor markets can be enacted when the parent market is in opening auction (0081-SUCM-009) +Successor markets can be enacted when the parent market is in opening auction. There is no virtual stake to copy over, and no insurance pool balance to transfer. (0081-SUCM-009) A successor market proposal can be enacted when the parent market is in one of the following states: Suspended, Active, Trading terminated or Settled (settled within the successor time window) (0081-SUCM-010) From c323d6680929afff65da0d8bfb58aa4d1aec4584 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 27 Jun 2023 16:44:51 +0100 Subject: [PATCH 155/649] fix: account type bond > bonus --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index c2fea5736..728f782c7 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -323,8 +323,8 @@ Note: ### Checkpoint -- Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) +- Snapshot for the bonus account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) ### Protocol upgrade -- After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) +- After a protocol upgrade the bonus and fee accounts and their balances are maintained (0044-LIME-031) From c852f0e08547fccd054a3c9d66a55fa30f85fabb Mon Sep 17 00:00:00 2001 From: Elias Van Ootegem Date: Tue, 27 Jun 2023 16:53:35 +0100 Subject: [PATCH 156/649] clarify behaviour for 0081-SUCM-008 Signed-off-by: Elias Van Ootegem --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 6f9b9de01..31a2d9e63 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -73,7 +73,7 @@ A new market proposal sets parent market Id to a market that has settled. The pa A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) -Successor markets cannot be enacted if the parent market is still in the "proposed" state. (0081-SUCM-008) +Successor markets cannot be enacted if the parent market is still in the "proposed" state. Successor market proposals can be submitted when the parent market is still in proposed state, but the when the voting period for the successor market ends (the successor market moves from "proposed" in to opening auction/"pending" state) when the parent market is still in "proposed" state, the successor market is rejected. (0081-SUCM-008) Successor markets can be enacted when the parent market is in opening auction. There is no virtual stake to copy over, and no insurance pool balance to transfer. (0081-SUCM-009) From 41bf336c16dd4bf6d265d4dd66513e258ca33ef7 Mon Sep 17 00:00:00 2001 From: Elias Van Ootegem Date: Tue, 27 Jun 2023 17:02:43 +0100 Subject: [PATCH 157/649] Update protocol/0081-SUCM-successor_markets.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 31a2d9e63..8d93efa1b 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -73,7 +73,7 @@ A new market proposal sets parent market Id to a market that has settled. The pa A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) -Successor markets cannot be enacted if the parent market is still in the "proposed" state. Successor market proposals can be submitted when the parent market is still in proposed state, but the when the voting period for the successor market ends (the successor market moves from "proposed" in to opening auction/"pending" state) when the parent market is still in "proposed" state, the successor market is rejected. (0081-SUCM-008) +Successor markets cannot be enacted if the parent market is still in the "proposed" state. Successor market proposals can be submitted when the parent market is still in proposed state. When the voting period for the successor market ends then either: a) the parent market is already enacted in which case the successor market moves from "proposed" in to opening auction/"pending" state. Or the parent market is still in "proposed" state in which case successor market is rejected. (0081-SUCM-008) Successor markets can be enacted when the parent market is in opening auction. There is no virtual stake to copy over, and no insurance pool balance to transfer. (0081-SUCM-009) From 874a6d0b765f488cbe78c5b9d795ea659c0bf0c5 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 28 Jun 2023 09:27:33 +0100 Subject: [PATCH 158/649] docs: added Network history AC --- protocol/0044-LIME-lp_mechanics.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 728f782c7..76ae6a969 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -328,3 +328,7 @@ Note: ### Protocol upgrade - After a protocol upgrade the bonus and fee accounts and their balances are maintained (0044-LIME-031) + +### Network history + +- A datanode restored from network history will contain any transfers created prior to the restore and these can be retrieved via APIs on the new datanode (0044-LIME-034) \ No newline at end of file From c40fead33cb9a54a0b12d9384c2f41a219a5ae00 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 28 Jun 2023 09:34:13 +0100 Subject: [PATCH 159/649] fix: type --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 76ae6a969..42ccbfb0f 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -323,7 +323,7 @@ Note: ### Checkpoint -- Snapshot for the bonus account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) +- Snapshot for the bonus account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bonus and Fee account (0044-LIME-030) ### Protocol upgrade From d9376337e8a475ace78edadb7307b784c68b979d Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 28 Jun 2023 09:35:26 +0100 Subject: [PATCH 160/649] fix: wording --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 42ccbfb0f..9d94429eb 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -323,7 +323,7 @@ Note: ### Checkpoint -- Snapshot for the bonus account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bonus and Fee account (0044-LIME-030) +- Snapshot for the Bonus account and Fee account are captured so that when a new validator node joins the network they can use the two account types Bonus and Fee account (0044-LIME-030) ### Protocol upgrade From 4381f595a98c964f51fd3cc3ac73715fe147b01b Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 28 Jun 2023 10:17:35 +0100 Subject: [PATCH 161/649] fix: eof newline --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9d94429eb..6d6d6047a 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -331,4 +331,4 @@ Note: ### Network history -- A datanode restored from network history will contain any transfers created prior to the restore and these can be retrieved via APIs on the new datanode (0044-LIME-034) \ No newline at end of file +- A datanode restored from network history will contain any transfers created prior to the restore and these can be retrieved via APIs on the new datanode (0044-LIME-034) From 51095ed4ec8a23dcb5fa9593e9271c4dbb0c986b Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 28 Jun 2023 11:14:35 +0100 Subject: [PATCH 162/649] fix: correction on amending commitment (#1796) --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 6d6d6047a..1b5acf27b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -100,7 +100,7 @@ A participant may apply to amend their commitment amount by submitting a transac `proposed-commitment-variation = new-proposed-commitment-amount - old-commitment-amount` -An increase in amendment is actioned immediately but only has implications for rewards / penalties at start of the current epoch. +An increase in amendment is actioned immediately but only has implications for rewards / penalties at start of the next epoch. 1) the amount is immediately transferred from the party's general account to their bond account. However we keep track of commitment at start of epoch and this is used for penalties / rewards. 2) at the beginning of the next epoch, the rewards / penalties for present LPs - including the party that's amending - are evaluated based on balance of bond account at start of epoch. From e1e25ff4486ba2d55a2e52d74708104a2d99dd63 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 9 Jan 2023 16:58:00 +0100 Subject: [PATCH 163/649] refactor: first stab at spec update --- protocol/0053-PERP-product_builtin_perpetual_future.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index fa1189de9..042b1ce61 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -10,6 +10,8 @@ Perpetual futures are a simple "delta one" product. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. +1. ` data_source_spec_binding`: The binding between the data source spec and the settlement data. +1. `max_settlement_gap`: value expressed in seconds which specifies the amount of time without settlement ("periodic funding") after which the market will go into protective auction and remain in that mode until settlement data is received. Validation: none required as these are validated by the asset and data source frameworks. @@ -38,6 +40,10 @@ cash_settled_perpetual_future.settlement_data(event) { } ``` +### 4.2 Protective auction + +If the amount of time in seconds since last [settlement](#41-settlement-periodic-funding) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. + ## Acceptance Criteria 1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source (0053-COSMICELEVATOR-001) From c3bab4a6fd7d56a0da3567bef3abe197e6de9524 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 16 Jan 2023 13:32:08 +0100 Subject: [PATCH 164/649] refactor: additonal changes --- ...3-PERP-product_builtin_perpetual_future.md | 42 ++++++++++++++----- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 042b1ce61..99199b356 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,14 +4,16 @@ This built-in product provides perpetual futures that are cash-settled, i.e. the [Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) -Perpetual futures are a simple "delta one" product. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenver `settlement_cue` is triggered AND the `settlement_data` is received. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. ## 1. Product parameters -1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. -1. ` data_source_spec_binding`: The binding between the data source spec and the settlement data. -1. `max_settlement_gap`: value expressed in seconds which specifies the amount of time without settlement ("periodic funding") after which the market will go into protective auction and remain in that mode until settlement data is received. +1. `settlement_cue (Data Source)`: this data is used to indicate that next periodic settlement should happen imminently. +1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. +1. `settlement_cue_auction_duration`: value expressed in seconds which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0` indicates no auction. +1. `max_settlement_gap`: value expressed in seconds which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. +1. `settlement_price_monitoring`: a boolean flag indiacating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will go thorugh the price monitoring engine and contribute to its price history as well as trigger a price monitoring auction if it falls outside the current valid price bounds. Validation: none required as these are validated by the asset and data source frameworks. @@ -30,7 +32,15 @@ cash_settled_perpetual_future.value(quote) { ## 4. Lifecycle triggers -### 4.1 Settlement ("periodic funding") +### 4.1 Periodic settlement cue + +```javascript +cash_settled_perpetual_future.settlement_cue(event) { + setWaitingForSettlementDataSince(vega.time) +} +``` + +### 4.2 Periodic settlement data received ```javascript cash_settled_perpetual_future.settlement_data(event) { @@ -40,9 +50,21 @@ cash_settled_perpetual_future.settlement_data(event) { } ``` -### 4.2 Protective auction +### 4.2.1 Periodic settlement during auction +TODO: How do we want to handle settlement event occuring during auction? Same for all auctions? +Do we just wait until the end of auction and try to use the settlement data then? If it's stale we just don't use it, uncross and carry on and count on max settlement gap logic to force the market to eventually have a periodic settlement using fresh data? + +### 4.3 Protective auctions + +In additional to protective auctions available for any market on Vega this product has protective auctions that are specific to it. + +### 4.2.1 Awaiting periodic settlement data + +An optional auction of predetermined maximum duration which gets triggered when the [settlement cue](#41-periodic-settlement-cue) data arrives and ends either upon receiving the settlement data or when the auction duration elapses. + +### 4.2.3 Max settlement gap exceeded -If the amount of time in seconds since last [settlement](#41-settlement-periodic-funding) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. +If the amount of time in seconds since last [periodic settlement](#41-settlement-periodic-funding) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. ## Acceptance Criteria @@ -51,6 +73,6 @@ If the amount of time in seconds since last [settlement](#41-settlement-periodic 1. The data source can be changed via governance (0053-COSMICELEVATOR-003) 1. It is not possible to change settlement asset via governance (0053-COSMICELEVATOR-004) 1. Mark to [market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly (0053-COSMICELEVATOR-005) -1. Settlement at each oracle event (periodic funding) works correctly (0053-COSMICELEVATOR-006) -1. Every valid lifecycle event (i.e. every oracle price update matching the data source specified) triggers a periodic funding settlement and causes settlement cashflows to be created and funds to be transferred. (0053-COSMICELEVATOR-007) -1. Directly after receipt of oracle data for periodic funding, the mark price is equal to the settlement data price provided and this is exposed on event bus and market data APIs (0053-COSMICELEVATOR-008) +1. Periodic settlement at each oracle event works correctly (0053-COSMICELEVATOR-006) +1. Every valid lifecycle event (i.e. every oracle price update matching the data source specified) triggers a periodic settlement and causes settlement cashflows to be created and funds to be transferred. (0053-COSMICELEVATOR-007) +1. Directly after receipt of oracle data for periodic settlement, the mark price is equal to the settlement data price provided and this is exposed on event bus and market data APIs (0053-COSMICELEVATOR-008) From 88f67d01be26e35f7e1631261525e8a05f781719 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 16 Jan 2023 13:36:40 +0100 Subject: [PATCH 165/649] refactor: fix linter errors --- .../0053-PERP-product_builtin_perpetual_future.md | 13 +++++++------ wordlist.txt | 1 + 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 99199b356..e6297d1d4 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,7 +4,7 @@ This built-in product provides perpetual futures that are cash-settled, i.e. the [Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenver `settlement_cue` is triggered AND the `settlement_data` is received. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered AND the `settlement_data` is received. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. ## 1. Product parameters @@ -13,7 +13,7 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_cue_auction_duration`: value expressed in seconds which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0` indicates no auction. 1. `max_settlement_gap`: value expressed in seconds which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_price_monitoring`: a boolean flag indiacating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will go thorugh the price monitoring engine and contribute to its price history as well as trigger a price monitoring auction if it falls outside the current valid price bounds. +1. `settlement_price_monitoring`: a boolean flag indicating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will go through the price monitoring engine and contribute to its price history as well as trigger a price monitoring auction if it falls outside the current valid price bounds. Validation: none required as these are validated by the asset and data source frameworks. @@ -51,20 +51,21 @@ cash_settled_perpetual_future.settlement_data(event) { ``` ### 4.2.1 Periodic settlement during auction -TODO: How do we want to handle settlement event occuring during auction? Same for all auctions? + +TODO: How do we want to handle settlement event occurring during auction? Same for all auctions? Do we just wait until the end of auction and try to use the settlement data then? If it's stale we just don't use it, uncross and carry on and count on max settlement gap logic to force the market to eventually have a periodic settlement using fresh data? ### 4.3 Protective auctions In additional to protective auctions available for any market on Vega this product has protective auctions that are specific to it. -### 4.2.1 Awaiting periodic settlement data +### 4.3.1 Awaiting periodic settlement data An optional auction of predetermined maximum duration which gets triggered when the [settlement cue](#41-periodic-settlement-cue) data arrives and ends either upon receiving the settlement data or when the auction duration elapses. -### 4.2.3 Max settlement gap exceeded +### 4.3.2 Max settlement gap exceeded -If the amount of time in seconds since last [periodic settlement](#41-settlement-periodic-funding) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. +If the amount of time in seconds since last [periodic settlement](#41-periodic-settlement-cue) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. ## Acceptance Criteria diff --git a/wordlist.txt b/wordlist.txt index def9b185a..1c25c2321 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -245,6 +245,7 @@ Tendermint testnet testnets TIF +TODO tokenholder tokenholders tradable From 8ed9a187dacb91bb44b8373b79358a6c45e08dde Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 16 Jan 2023 14:06:20 +0100 Subject: [PATCH 166/649] refactor: deunitise time --- protocol/0053-PERP-product_builtin_perpetual_future.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index e6297d1d4..451915964 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -11,8 +11,8 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. 1. `settlement_cue (Data Source)`: this data is used to indicate that next periodic settlement should happen imminently. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. -1. `settlement_cue_auction_duration`: value expressed in seconds which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0` indicates no auction. -1. `max_settlement_gap`: value expressed in seconds which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. +1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. +1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. 1. `settlement_price_monitoring`: a boolean flag indicating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will go through the price monitoring engine and contribute to its price history as well as trigger a price monitoring auction if it falls outside the current valid price bounds. Validation: none required as these are validated by the asset and data source frameworks. @@ -65,7 +65,7 @@ An optional auction of predetermined maximum duration which gets triggered when ### 4.3.2 Max settlement gap exceeded -If the amount of time in seconds since last [periodic settlement](#41-periodic-settlement-cue) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. +If the amount of time since last [periodic settlement](#41-periodic-settlement-cue) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. ## Acceptance Criteria From 0b42b0fe7c5c4b5de6705db72af630d226cbd4a1 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 20 Jan 2023 13:51:43 +0100 Subject: [PATCH 167/649] refactor: add data_ingestion_period --- protocol/0053-PERP-product_builtin_perpetual_future.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 451915964..98c7db86d 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,7 +4,7 @@ This built-in product provides perpetual futures that are cash-settled, i.e. the [Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered AND the `settlement_data` is received. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered AND the `settlement_data` is received within the specified `data_ingestion_period`. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. ## 1. Product parameters @@ -12,6 +12,7 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_cue (Data Source)`: this data is used to indicate that next periodic settlement should happen imminently. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. +1. `data_ingestion_period`: specifies the length of time window since `settlement_cue` event during which data from `settlement_data` data source will be accepted by the market. Once the first value is received no further data is accepted. 1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. 1. `settlement_price_monitoring`: a boolean flag indicating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will go through the price monitoring engine and contribute to its price history as well as trigger a price monitoring auction if it falls outside the current valid price bounds. @@ -42,6 +43,8 @@ cash_settled_perpetual_future.settlement_cue(event) { ### 4.2 Periodic settlement data received +If the periodic settlement data gets received within specified data ingestion period from the periodic settlement cue, then: + ```javascript cash_settled_perpetual_future.settlement_data(event) { cashflow = cash_settled_perpetual_future.value(event.data) - cash_settled_perpetual_future.value(market.mark_price)) From dd6ebdd657833e8aefb389f595c3f18aa1452ec1 Mon Sep 17 00:00:00 2001 From: Witold Date: Sat, 21 Jan 2023 18:03:59 +0100 Subject: [PATCH 168/649] refactor: clarify settlement during auction --- ...053-PERP-product_builtin_perpetual_future.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 98c7db86d..7967e5a80 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -1,6 +1,6 @@ # Built-in [Product](./0051-PROD-product.md): Cash Settled Perpetual Futures (CSF) -This built-in product provides perpetual futures that are cash-settled, i.e. they are margined and settled in a single asset. +This built-in product provides perpetual futures contracts that are cash-settled, i.e. they are margined and settled in a single asset, and they never expire. [Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) @@ -14,7 +14,7 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. 1. `data_ingestion_period`: specifies the length of time window since `settlement_cue` event during which data from `settlement_data` data source will be accepted by the market. Once the first value is received no further data is accepted. 1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_price_monitoring`: a boolean flag indicating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will go through the price monitoring engine and contribute to its price history as well as trigger a price monitoring auction if it falls outside the current valid price bounds. +1. `settlement_data_monitoring`: a boolean flag indicating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will be checked against the market's price monitoring engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the market the periodic settlement proceeds, otherwise the system behaves as if the data was never received. Validation: none required as these are validated by the asset and data source frameworks. @@ -43,7 +43,7 @@ cash_settled_perpetual_future.settlement_cue(event) { ### 4.2 Periodic settlement data received -If the periodic settlement data gets received within specified data ingestion period from the periodic settlement cue, then: +If the periodic settlement data gets received within specified data ingestion period from the periodic settlement cue and falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), then: ```javascript cash_settled_perpetual_future.settlement_data(event) { @@ -53,10 +53,15 @@ cash_settled_perpetual_future.settlement_data(event) { } ``` -### 4.2.1 Periodic settlement during auction +### 4.2.1 Periodic settlement during [auction](0026-AUCT-auctions.md) -TODO: How do we want to handle settlement event occurring during auction? Same for all auctions? -Do we just wait until the end of auction and try to use the settlement data then? If it's stale we just don't use it, uncross and carry on and count on max settlement gap logic to force the market to eventually have a periodic settlement using fresh data? +Periodic settlement is not allowed during the opening auction and it's extensions. +If periodic settlement data happens whilst market is in auction of any other type then: + +* uncross the auction at the received settlement price without leaving the auction mode, +* generate the trades implied by the above and update the positions, +* carry out settlement based on the updated positions, +* let the market carry on in the same auction mode it was it before the settlement data was received until relevant auction exit conditions are met and the market returns to its default trading mode. ### 4.3 Protective auctions From abefcc8113d2eea3e9cc038fa32bc7323fc3f3d9 Mon Sep 17 00:00:00 2001 From: Witold Date: Sat, 21 Jan 2023 18:30:07 +0100 Subject: [PATCH 169/649] refactor: modify time-based oracles --- protocol/0048-DSRI-data_source_internal.md | 32 ++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index ffa3333f3..eb15de8f9 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -24,13 +24,15 @@ value { type: number, value: 1400.5 } ## 1.2 Time triggered -This data source would be used to emit an event/value at/after a given Vega time (i.e. the time printed on the block). This would be used to trigger "trading terminated" for futures, for example. +### 1.2.1 One-off + +This data source would be used to emit a a single event/value at/after a given Vega time (i.e. the time printed on the block). This would be used to trigger "trading terminated" for futures, for example. This trigger will emit the contents of the specified data source (could be omitted if just triggering trading termination, or could be a value as described in 1.1, or another data source in order to implement a delay/ensure the value from the data source is not emitted before a certain time). Note that trading terminated in the futures definition uses a data source as a trigger intentionally to (a) demonstrate that this is how time based product events would work; and (b) because although the trigger MAY be time based, it could also be another data source such as a signed message oracle, if the trading terminates at an unknown time. -In future, there will be a need to support repeating time based triggers, for example every 2 days or at 04:00, 12:00 and 20:00 every day, etc. (as some products will have triggers that happen regularly). +Once the data source emits the invent it should become inactive. Pseudocode example: @@ -51,6 +53,32 @@ on: { ``` +### 1.2.2 Repeating + +A repeating time trigger will contain a collection of timestamps and frequency tuples. +For each tuple: + +- as soon as the protocol registers a time which is equal to or higher than the specified `timestamp` an event is emitted, +- each time an integer multiple of the time period specified by the`frequency` field from the `timestamp` elapses another event should get fired. + +The repeating internal time triggered oracles will be used by the [perpetual futures](protocol/0053-PERP-product_builtin_perpetual_future.md) product, hence it must be possible to set them up to model a schedule like: every day at 04:00, 12:00 and 20:00. + +```rust +on: { + { + timestamp: '202112311T04:00:00' + frequency: '24h' + }, + { + timestamp: '202112311T12:00:00' + frequency: '24h' + }, + { + timestamp: '202112311T20:00:00' + frequency: '24h' + }, +} + ## 1.3 Vega time changed This data source will emit the current Vega time *once* (and once only) whenever the Vega time changes. From 07ec6a6e368af964bdbb17125716f3c3ad5b9c17 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 23 Jan 2023 16:49:22 +0100 Subject: [PATCH 170/649] refactor: add/modify ACs --- ...3-PERP-product_builtin_perpetual_future.md | 22 +++++++++++-------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 7967e5a80..ecce74f9e 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -14,7 +14,7 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. 1. `data_ingestion_period`: specifies the length of time window since `settlement_cue` event during which data from `settlement_data` data source will be accepted by the market. Once the first value is received no further data is accepted. 1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_data_monitoring`: a boolean flag indicating if periodic settlement price should go through the [price monitoring](0032-PRIM-price_monitoring.md) logic. If set to `true` any valid `settlement_data` ingested by the market will be checked against the market's price monitoring engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the market the periodic settlement proceeds, otherwise the system behaves as if the data was never received. +1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` ingested by the market will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the market the periodic settlement proceeds, otherwise the system behaves as if the data was never received. Validation: none required as these are validated by the asset and data source frameworks. @@ -77,11 +77,15 @@ If the amount of time since last [periodic settlement](#41-periodic-settlement-c ## Acceptance Criteria -1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source (0053-COSMICELEVATOR-001) -1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega (0053-COSMICELEVATOR-002) -1. The data source can be changed via governance (0053-COSMICELEVATOR-003) -1. It is not possible to change settlement asset via governance (0053-COSMICELEVATOR-004) -1. Mark to [market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly (0053-COSMICELEVATOR-005) -1. Periodic settlement at each oracle event works correctly (0053-COSMICELEVATOR-006) -1. Every valid lifecycle event (i.e. every oracle price update matching the data source specified) triggers a periodic settlement and causes settlement cashflows to be created and funds to be transferred. (0053-COSMICELEVATOR-007) -1. Directly after receipt of oracle data for periodic settlement, the mark price is equal to the settlement data price provided and this is exposed on event bus and market data APIs (0053-COSMICELEVATOR-008) +1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source. (0053-COSMICELEVATOR-001) +1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega. (0053-COSMICELEVATOR-002) +1. The data source can be changed via governance. (0053-COSMICELEVATOR-003) +1. It is not possible to change settlement asset via governance. (0053-COSMICELEVATOR-004) +1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of periodic settlement driven by the oracle data. (0053-COSMICELEVATOR-005) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during liquidity monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during price monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction until the end (TODO: Do we want to end the auction at this point? If not do we want to allow the possibility of other settlement data coming it?). (0053-COSMICELEVATOR-010) +1. Periodic settlement causes settlement cashflows to be created, funds to be transferred and the [mark price](0021-MDAT-market_data_spec.md#market-data-fields) to be updated. (0053-COSMICELEVATOR-011) +1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received (no more than `data_ingestion_period` apart) periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) From d14705a7ab6194e54d1f98e6f9dbe876d085e1fb Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 30 Jan 2023 16:20:05 +0100 Subject: [PATCH 171/649] refactor: generalise repeating time oracle --- protocol/0048-DSRI-data_source_internal.md | 26 +++------------------- 1 file changed, 3 insertions(+), 23 deletions(-) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index eb15de8f9..09027cf09 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -55,29 +55,7 @@ on: { ### 1.2.2 Repeating -A repeating time trigger will contain a collection of timestamps and frequency tuples. -For each tuple: - -- as soon as the protocol registers a time which is equal to or higher than the specified `timestamp` an event is emitted, -- each time an integer multiple of the time period specified by the`frequency` field from the `timestamp` elapses another event should get fired. - -The repeating internal time triggered oracles will be used by the [perpetual futures](protocol/0053-PERP-product_builtin_perpetual_future.md) product, hence it must be possible to set them up to model a schedule like: every day at 04:00, 12:00 and 20:00. - -```rust -on: { - { - timestamp: '202112311T04:00:00' - frequency: '24h' - }, - { - timestamp: '202112311T12:00:00' - frequency: '24h' - }, - { - timestamp: '202112311T20:00:00' - frequency: '24h' - }, -} +The repeating internal time triggered oracles will be used by the [perpetual futures](protocol/0053-PERP-product_builtin_perpetual_future.md) product, hence it must be possible to set them up to model a schedule like: every day at 04:00, 12:00 and 20:00. It should also be possible to model a completely arbitrary time schedule with a fixed number of events (e.g. 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37). Appropriate anti-spam measures should be considered to prevent the ability to specify an internal time triggered oracle that puts exceedingly high strain on the resources. ## 1.3 Vega time changed @@ -156,3 +134,5 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time - wait to all of them to terminate successfully - assert they all settle successfully +1. The repeating internal time triggered oracle can be used to model a time schedule of the form: every day at 12:00, 15:00 and 18:00. (0048-DSRI-015) +1. The repeating internal time triggered oracle can be used to model a time schedule of the form: 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37. (0048-DSRI-016) \ No newline at end of file From 1c29ff2817b0712c3b9121fa35fe00733a3c969b Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 30 Jan 2023 16:24:53 +0100 Subject: [PATCH 172/649] refactor: accept another data point within PM --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index ecce74f9e..ccf2f4115 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -14,7 +14,7 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. 1. `data_ingestion_period`: specifies the length of time window since `settlement_cue` event during which data from `settlement_data` data source will be accepted by the market. Once the first value is received no further data is accepted. 1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` ingested by the market will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the market the periodic settlement proceeds, otherwise the system behaves as if the data was never received. +1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` ingested by the market will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the market the periodic settlement proceeds, otherwise the system behaves as if the data was never received. This implies that if the oracle serves another datapoint within the `data_ingestion_period` which falls within the price monitoring bounds it will be used the periodic settlement. Validation: none required as these are validated by the asset and data source frameworks. From 8787486889c8822f2cffaa1e765d96946d5fc12c Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 30 Jan 2023 17:11:42 +0100 Subject: [PATCH 173/649] refactor: add pseudocode --- ...3-PERP-product_builtin_perpetual_future.md | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index ccf2f4115..b73333d1e 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -18,6 +18,33 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc Validation: none required as these are validated by the asset and data source frameworks. +### Example specification + +The pseudocode below specifies a possible configuration of the built-in perpetual futures contract product. The emphasis is on modelling required properties of this product, not the exact semantics used as these will most likely differ in the implementation. + +```yaml + product: built-in perpetual futures contract + settlement_asset: XYZ + settlement_cue: + internal_time_oracle: + repeating: + - every 24h from 20230201T09:30:00 + - every 168h from 20230203T12:00:00 + settlement_data: + data_source: SignedMessage{ pubkey=0xA45e...d6 } + field: 'price' + filters: + - ticker: 'TSLA' + - timestamp: 'time >= 09:25:00' + - timestamp: 'time <= 10:05:00' + - timestamp: 'time >= 11:55:00' + - timestamp: 'time <= 12:35:00' + settlement_cue_auction_duration: "1h" + data_ingestion_period: "30min" + max_settlement_gap: "48h" + settlement_data_monitoring: true +``` + ## 2. Settlement assets 1. Returns `[cash_settled_perpetual_future.settlement_asset]` From fc1f0f0db10e06308d23d80fec584a28476f5f33 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 30 Jan 2023 17:17:50 +0100 Subject: [PATCH 174/649] refactor: add AC --- protocol/0048-DSRI-data_source_internal.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 09027cf09..0f3608b4c 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -135,4 +135,5 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna - wait to all of them to terminate successfully - assert they all settle successfully 1. The repeating internal time triggered oracle can be used to model a time schedule of the form: every day at 12:00, 15:00 and 18:00. (0048-DSRI-015) -1. The repeating internal time triggered oracle can be used to model a time schedule of the form: 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37. (0048-DSRI-016) \ No newline at end of file +1. The repeating internal time triggered oracle can be used to model a time schedule of the form: 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37. (0048-DSRI-016) +1. The repeating internal time triggered oracle with a schedule of "every day at 12:00", always sends an event as soon as the block with a timestamp with time of 12:00 or higher is received (the time the oracle sends an event doesn't drift forward even after many days). (0048-DSRI-017) \ No newline at end of file From f979ab275dd1320d5e8bc272f72fe786abe422c4 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 13 Feb 2023 14:18:26 +0100 Subject: [PATCH 175/649] refactor: expose settlement time variable --- protocol/0053-PERP-product_builtin_perpetual_future.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index b73333d1e..2f526cf0a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,12 +4,12 @@ This built-in product provides perpetual futures contracts that are cash-settled [Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered AND the `settlement_data` is received within the specified `data_ingestion_period`. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered AND the `settlement_data` is received within the specified `data_ingestion_period` and has a timestamp that lies within that time window. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. ## 1. Product parameters 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. -1. `settlement_cue (Data Source)`: this data is used to indicate that next periodic settlement should happen imminently. +1. `settlement_cue (Data Source: datetime)`: this data is used to indicate that next periodic settlement should happen imminently and specify the start of the data ingestion time window. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. 1. `data_ingestion_period`: specifies the length of time window since `settlement_cue` event during which data from `settlement_data` data source will be accepted by the market. Once the first value is received no further data is accepted. @@ -62,15 +62,17 @@ cash_settled_perpetual_future.value(quote) { ### 4.1 Periodic settlement cue +Whenever an appropriate event is received the settlement cue returns the current `vega.time` to indicate the time at which the next periodic settlement should happen if other conditions for it are met: + ```javascript cash_settled_perpetual_future.settlement_cue(event) { - setWaitingForSettlementDataSince(vega.time) + return vega.time } ``` ### 4.2 Periodic settlement data received -If the periodic settlement data gets received within specified data ingestion period from the periodic settlement cue and falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), then: +Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. If the periodic settlement data gets received within specified `data_ingestion_period` from the periodic settlement cue AND its timestamp falls within that time window AND its value falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), then: ```javascript cash_settled_perpetual_future.settlement_data(event) { From 91414802932e1a3dcd703671f51f4789592cf649 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 13 Feb 2023 14:35:07 +0100 Subject: [PATCH 176/649] refactor: fix spelling --- protocol/0048-DSRI-data_source_internal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 0f3608b4c..c37536846 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -32,7 +32,7 @@ This trigger will emit the contents of the specified data source (could be omitt Note that trading terminated in the futures definition uses a data source as a trigger intentionally to (a) demonstrate that this is how time based product events would work; and (b) because although the trigger MAY be time based, it could also be another data source such as a signed message oracle, if the trading terminates at an unknown time. -Once the data source emits the invent it should become inactive. +Once the data source emits the event it should become inactive. Pseudocode example: From dfa1d33bd3839b52fe72d871318b5aebec0b46da Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 13 Feb 2023 16:41:57 +0100 Subject: [PATCH 177/649] refactor: remove data ingestion period --- ...3-PERP-product_builtin_perpetual_future.md | 65 +++++++++---------- 1 file changed, 32 insertions(+), 33 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 2f526cf0a..93408d276 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,17 +4,16 @@ This built-in product provides perpetual futures contracts that are cash-settled [Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered AND the `settlement_data` is received within the specified `data_ingestion_period` and has a timestamp that lies within that time window. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered and the `settlement_data` is received and all its filters are satisfied. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. ## 1. Product parameters 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. -1. `settlement_cue (Data Source: datetime)`: this data is used to indicate that next periodic settlement should happen imminently and specify the start of the data ingestion time window. +1. `settlement_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. -1. `data_ingestion_period`: specifies the length of time window since `settlement_cue` event during which data from `settlement_data` data source will be accepted by the market. Once the first value is received no further data is accepted. 1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` ingested by the market will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the market the periodic settlement proceeds, otherwise the system behaves as if the data was never received. This implies that if the oracle serves another datapoint within the `data_ingestion_period` which falls within the price monitoring bounds it will be used the periodic settlement. +1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the bounds the periodic settlement proceeds, otherwise the system behaves as if the data was never received. This implies that if the oracle serves another valid datapoint which falls within the price monitoring bounds it will be used for periodic settlement. Validation: none required as these are validated by the asset and data source frameworks. @@ -23,26 +22,25 @@ Validation: none required as these are validated by the asset and data source fr The pseudocode below specifies a possible configuration of the built-in perpetual futures contract product. The emphasis is on modelling required properties of this product, not the exact semantics used as these will most likely differ in the implementation. ```yaml - product: built-in perpetual futures contract - settlement_asset: XYZ - settlement_cue: - internal_time_oracle: - repeating: - - every 24h from 20230201T09:30:00 - - every 168h from 20230203T12:00:00 - settlement_data: - data_source: SignedMessage{ pubkey=0xA45e...d6 } - field: 'price' - filters: - - ticker: 'TSLA' - - timestamp: 'time >= 09:25:00' - - timestamp: 'time <= 10:05:00' - - timestamp: 'time >= 11:55:00' - - timestamp: 'time <= 12:35:00' - settlement_cue_auction_duration: "1h" - data_ingestion_period: "30min" - max_settlement_gap: "48h" - settlement_data_monitoring: true + product: built-in perpetual futures contract + settlement_asset: XYZ + settlement_cue: + internal_time_oracle: + repeating: + - every 24h from 20230201T09:30:00 + - every 168h from 20230203T12:00:00 + settlement_data: + data_source: SignedMessage{ pubkey=0xA45e...d6 } + field: 'price' + filters: + - received: >= 'settlement_cue.time' + - received: <= 'settlement_cue.time' + "35min" + - 'timestamp': >= 'settlement_cue.time' + - 'timestamp': <= 'settlement_cue.time' + "30min" + - 'ticker': 'TSLA' + settlement_cue_auction_duration: "40min" + max_settlement_gap: "48h" + settlement_data_monitoring: true ``` ## 2. Settlement assets @@ -72,7 +70,7 @@ cash_settled_perpetual_future.settlement_cue(event) { ### 4.2 Periodic settlement data received -Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. If the periodic settlement data gets received within specified `data_ingestion_period` from the periodic settlement cue AND its timestamp falls within that time window AND its value falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), then: +Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. If must be possible to filter the data by the time it was received at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it and its value falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields) (if `settlement_data_monitoring` flag is set to `true`, otherwise any numerical value is accepted), then: ```javascript cash_settled_perpetual_future.settlement_data(event) { @@ -90,7 +88,7 @@ If periodic settlement data happens whilst market is in auction of any other typ * uncross the auction at the received settlement price without leaving the auction mode, * generate the trades implied by the above and update the positions, * carry out settlement based on the updated positions, -* let the market carry on in the same auction mode it was it before the settlement data was received until relevant auction exit conditions are met and the market returns to its default trading mode. +* let the market carry on in the same auction mode it was in before the settlement data was received until relevant auction exit conditions are met and the market returns to its default trading mode. ### 4.3 Protective auctions @@ -98,7 +96,7 @@ In additional to protective auctions available for any market on Vega this produ ### 4.3.1 Awaiting periodic settlement data -An optional auction of predetermined maximum duration which gets triggered when the [settlement cue](#41-periodic-settlement-cue) data arrives and ends either upon receiving the settlement data or when the auction duration elapses. +An optional auction of predetermined maximum duration which gets triggered when the [settlement cue](#41-periodic-settlement-cue) data arrives and ends either upon receiving a valid settlement data or when the auction duration elapses. ### 4.3.2 Max settlement gap exceeded @@ -111,10 +109,11 @@ If the amount of time since last [periodic settlement](#41-periodic-settlement-c 1. The data source can be changed via governance. (0053-COSMICELEVATOR-003) 1. It is not possible to change settlement asset via governance. (0053-COSMICELEVATOR-004) 1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of periodic settlement driven by the oracle data. (0053-COSMICELEVATOR-005) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during liquidity monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) during price monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles (no more than `data_ingestion_period` apart) with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction until the end (TODO: Do we want to end the auction at this point? If not do we want to allow the possibility of other settlement data coming it?). (0053-COSMICELEVATOR-010) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles during liquidity monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles during price monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction until the end (TODO: Do we want to end the auction at this point? If not do we want to allow the possibility of other settlement data coming it?). (0053-COSMICELEVATOR-010) 1. Periodic settlement causes settlement cashflows to be created, funds to be transferred and the [mark price](0021-MDAT-market_data_spec.md#market-data-fields) to be updated. (0053-COSMICELEVATOR-011) -1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received (no more than `data_ingestion_period` apart) periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) +1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `received` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) \ No newline at end of file From dad218246647335abb84fbda5ff388ccecdc05bb Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 8 Mar 2023 10:47:07 +0000 Subject: [PATCH 178/649] fix: dupe AC code and lint errors --- protocol/0048-DSRI-data_source_internal.md | 4 ++-- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- wordlist.txt | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index c37536846..a14d69d2c 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -134,6 +134,6 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time - wait to all of them to terminate successfully - assert they all settle successfully -1. The repeating internal time triggered oracle can be used to model a time schedule of the form: every day at 12:00, 15:00 and 18:00. (0048-DSRI-015) +1. The repeating internal time triggered oracle can be used to model a time schedule of the form: every day at 12:00, 15:00 and 18:00. (0048-DSRI-018) 1. The repeating internal time triggered oracle can be used to model a time schedule of the form: 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37. (0048-DSRI-016) -1. The repeating internal time triggered oracle with a schedule of "every day at 12:00", always sends an event as soon as the block with a timestamp with time of 12:00 or higher is received (the time the oracle sends an event doesn't drift forward even after many days). (0048-DSRI-017) \ No newline at end of file +1. The repeating internal time triggered oracle with a schedule of "every day at 12:00", always sends an event as soon as the block with a timestamp with time of 12:00 or higher is received (the time the oracle sends an event doesn't drift forward even after many days). (0048-DSRI-017) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 93408d276..b5d2fbefa 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -116,4 +116,4 @@ If the amount of time since last [periodic settlement](#41-periodic-settlement-c 1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction until the end (TODO: Do we want to end the auction at this point? If not do we want to allow the possibility of other settlement data coming it?). (0053-COSMICELEVATOR-010) 1. Periodic settlement causes settlement cashflows to be created, funds to be transferred and the [mark price](0021-MDAT-market_data_spec.md#market-data-fields) to be updated. (0053-COSMICELEVATOR-011) 1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `received` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) \ No newline at end of file +1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `received` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) diff --git a/wordlist.txt b/wordlist.txt index 1c25c2321..ffec72765 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -53,6 +53,7 @@ cumulated customised DAI datanode +datapoint datatypes datetime decentralised From 8959ff3d29b16e8e0bd2c8d288941b6748465e85 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 8 Mar 2023 16:43:13 +0100 Subject: [PATCH 179/649] refactor: clarify received timestamp --- .../0053-PERP-product_builtin_perpetual_future.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index b5d2fbefa..8942ce2eb 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -10,10 +10,10 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. 1. `settlement_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. -1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers this calculation and the transfers between parties to "true up" to the external reference price. +1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers that calculation and the transfers between parties to "true up" to the external reference price. 1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. 1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the bounds the periodic settlement proceeds, otherwise the system behaves as if the data was never received. This implies that if the oracle serves another valid datapoint which falls within the price monitoring bounds it will be used for periodic settlement. +1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the bounds the periodic settlement proceeds, otherwise the system behaves as if the data was never received. This implies that if the oracle serves another valid datapoint which falls within the price monitoring bounds then that datapoint will be used for periodic settlement. Validation: none required as these are validated by the asset and data source frameworks. @@ -33,8 +33,8 @@ The pseudocode below specifies a possible configuration of the built-in perpetua data_source: SignedMessage{ pubkey=0xA45e...d6 } field: 'price' filters: - - received: >= 'settlement_cue.time' - - received: <= 'settlement_cue.time' + "35min" + - vegaprotocol.builtin.timestamp: >= 'settlement_cue.time' + - vegaprotocol.builtin.timestamp: <= 'settlement_cue.time' + "35min" - 'timestamp': >= 'settlement_cue.time' - 'timestamp': <= 'settlement_cue.time' + "30min" - 'ticker': 'TSLA' @@ -60,17 +60,17 @@ cash_settled_perpetual_future.value(quote) { ### 4.1 Periodic settlement cue -Whenever an appropriate event is received the settlement cue returns the current `vega.time` to indicate the time at which the next periodic settlement should happen if other conditions for it are met: +Whenever an appropriate event is received the settlement cue returns the current `vegaprotocol.builtin.timestamp` to indicate the time at which the next periodic settlement should happen if other conditions for it are met: ```javascript cash_settled_perpetual_future.settlement_cue(event) { - return vega.time + return vegaprotocol.builtin.timestamp } ``` ### 4.2 Periodic settlement data received -Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. If must be possible to filter the data by the time it was received at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it and its value falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields) (if `settlement_data_monitoring` flag is set to `true`, otherwise any numerical value is accepted), then: +Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it and its value falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields) (if `settlement_data_monitoring` flag is set to `true`, otherwise any numerical value is accepted), then: ```javascript cash_settled_perpetual_future.settlement_data(event) { From 2bb184e4a597c1d7f7fa69e9cc8f9350bd3ad9b0 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 8 Mar 2023 17:25:45 +0100 Subject: [PATCH 180/649] refactor: update ACs --- protocol/0053-PERP-product_builtin_perpetual_future.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 8942ce2eb..d383890b5 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -113,7 +113,7 @@ If the amount of time since last [periodic settlement](#41-periodic-settlement-c 1. Receiving correctly formatted data from the settlement cue and settlement data oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) 1. Receiving correctly formatted data from the settlement cue and settlement data oracles during liquidity monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) 1. Receiving correctly formatted data from the settlement cue and settlement data oracles during price monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction until the end (TODO: Do we want to end the auction at this point? If not do we want to allow the possibility of other settlement data coming it?). (0053-COSMICELEVATOR-010) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction it elapses at which point the auciton uncrosses and market returns to its default trading mode (0053-COSMICELEVATOR-010) 1. Periodic settlement causes settlement cashflows to be created, funds to be transferred and the [mark price](0021-MDAT-market_data_spec.md#market-data-fields) to be updated. (0053-COSMICELEVATOR-011) 1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `received` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) From c95961591fa14e8d8d6060e492db2fb005488ff6 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 8 Mar 2023 17:35:39 +0100 Subject: [PATCH 181/649] refactor: fix spelling --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index d383890b5..52f47fd95 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -113,7 +113,7 @@ If the amount of time since last [periodic settlement](#41-periodic-settlement-c 1. Receiving correctly formatted data from the settlement cue and settlement data oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) 1. Receiving correctly formatted data from the settlement cue and settlement data oracles during liquidity monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) 1. Receiving correctly formatted data from the settlement cue and settlement data oracles during price monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction it elapses at which point the auciton uncrosses and market returns to its default trading mode (0053-COSMICELEVATOR-010) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction it elapses at which point the auction uncrosses and market returns to its default trading mode (0053-COSMICELEVATOR-010) 1. Periodic settlement causes settlement cashflows to be created, funds to be transferred and the [mark price](0021-MDAT-market_data_spec.md#market-data-fields) to be updated. (0053-COSMICELEVATOR-011) 1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) 1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) From 3b0b5d0ecf04d95bcb2eca95460eebab056be767 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 2 May 2023 00:15:08 +0200 Subject: [PATCH 182/649] refactor: add changes from last week --- ...3-PERP-product_builtin_perpetual_future.md | 110 +++++++++++------- 1 file changed, 67 insertions(+), 43 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 52f47fd95..072e0478a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -2,18 +2,18 @@ This built-in product provides perpetual futures contracts that are cash-settled, i.e. they are margined and settled in a single asset, and they never expire. -[Background reading](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures) +Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures), [2](https://arxiv.org/pdf/2212.06888.pdf). -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_cue` is triggered and the `settlement_data` is received and all its filters are satisfied. A number of protective measures can be specified for a market to deal with data scarcity in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered and data obtained from the `settlement_data_cue` and `settlement_data` oracles is used to calcualte the funding rate. ## 1. Product parameters 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. -1. `settlement_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. -1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. The receipt of this data triggers that calculation and the transfers between parties to "true up" to the external reference price. -1. `settlement_cue_auction_duration`: a time interval which specifies the duration of an auction started once settlement cue is received. The auction ends when the specified time elapses or when the settlement data is received. A value of `0s` indicates no auction. -1. `max_settlement_gap`: a time interval which specifies the amount of time without periodic settlement after which the market will go into protective auction and remain in that mode until settlement data is received. -1. `settlement_data_monitoring`: if set to `true` any valid `settlement_data` will be checked against the market's [price monitoring](0032-PRIM-price_monitoring.md) engine. Specifically, the incoming settlement data will be checked against market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields), if it falls within the bounds the periodic settlement proceeds, otherwise the system behaves as if the data was never received. This implies that if the oracle serves another valid datapoint which falls within the price monitoring bounds then that datapoint will be used for periodic settlement. +1. `settlement_schedule (Data Source: datetime)`: this data is used to indicate when the next periodic settlement should be carried out. +1. `settlement_data_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. +1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. +1. `max_settlement_schedule_gap`: a time interval which specifies the amount of time without the receipt of a valid `settlement_schedule` oracle event after which the market will go into protective auction and remain in that mode until `settlement_schedule` data is received. +1. `max_settlement_data_gap`:a time interval which specifies the amount of time without the receipt of a valid `settlement_data` oracle event after which the market will go into protective auction and remain in that mode until `settlement_data` data is received. Validation: none required as these are validated by the asset and data source frameworks. @@ -24,23 +24,26 @@ The pseudocode below specifies a possible configuration of the built-in perpetua ```yaml product: built-in perpetual futures contract settlement_asset: XYZ - settlement_cue: + settlement_schedule: internal_time_oracle: repeating: - - every 24h from 20230201T09:30:00 + - every 8h from 20230201T09:30:00 - every 168h from 20230203T12:00:00 + settlement_cue: + internal_time_oracle: + repeating: + - every 1min from 20230201T09:30:00 settlement_data: data_source: SignedMessage{ pubkey=0xA45e...d6 } field: 'price' filters: - vegaprotocol.builtin.timestamp: >= 'settlement_cue.time' - - vegaprotocol.builtin.timestamp: <= 'settlement_cue.time' + "35min" + - vegaprotocol.builtin.timestamp: <= 'settlement_cue.time' + "15s" - 'timestamp': >= 'settlement_cue.time' - - 'timestamp': <= 'settlement_cue.time' + "30min" + - 'timestamp': <= 'settlement_cue.time' + "10s" - 'ticker': 'TSLA' - settlement_cue_auction_duration: "40min" - max_settlement_gap: "48h" - settlement_data_monitoring: true + max_settlement_schedule_gap: "17h" + max_settlement_data_gap: "1h" ``` ## 2. Settlement assets @@ -60,7 +63,7 @@ cash_settled_perpetual_future.value(quote) { ### 4.1 Periodic settlement cue -Whenever an appropriate event is received the settlement cue returns the current `vegaprotocol.builtin.timestamp` to indicate the time at which the next periodic settlement should happen if other conditions for it are met: +Whenever an appropriate event is received the settlement cue returns the current `vegaprotocol.builtin.timestamp` to indicate the time around which the next periodic settlement data point is expected: ```javascript cash_settled_perpetual_future.settlement_cue(event) { @@ -68,52 +71,73 @@ cash_settled_perpetual_future.settlement_cue(event) { } ``` -### 4.2 Periodic settlement data received +### 4.2 Periodic settlement data point received -Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it and its value falls within all of market's active [price monitoring bounds](0021-MDAT-market_data_spec.md#market-data-fields) (if `settlement_data_monitoring` flag is set to `true`, otherwise any numerical value is accepted), then: +Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding rate data point. -```javascript -cash_settled_perpetual_future.settlement_data(event) { - cashflow = cash_settled_perpetual_future.value(event.data) - cash_settled_perpetual_future.value(market.mark_price)) - settle(cash_settled_perpetual_future.settlement_asset, cashflow) - setMarkPrice(event.data) +### 4.3 Mark to market settlement + +Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along the mark price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding rate data point. If no periodic settlement data has been received yet then the funding rate data point should not be created. + +### 4.4 Periodic settlement + +When the `settlement_schedule` event is received additional funding data point gets stored using the last received periodic settlement cue, current `mark_price` and the current `vegaprotocol.builtin.timestamp`. + +The next step is to calculate the periodic settlement funding rate. If there are no periodic settlement data points then the periodic settlement is skipped. Otherwise, consider all the periodic settlement data points and calculate the time-weighted average price difference as: + +```go +sd := 0 +st := 0 +for i := 0; i < len(data_points) - 1; i++ { + t := data_points[i+1].t-data_points[i].t + d := data_points[i].x - data_points[i].y + sd += d * t + st += t } +funding_rate = sd / st ``` -### 4.2.1 Periodic settlement during [auction](0026-AUCT-auctions.md) +All the funding rate data points except for the last one (it should get carried over as the first data point for the next period) can then be deleted. -Periodic settlement is not allowed during the opening auction and it's extensions. -If periodic settlement data happens whilst market is in auction of any other type then: +Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding rate}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding rate is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). + +### 4.4.1 Periodic settlement during [auction](0026-AUCT-auctions.md) -* uncross the auction at the received settlement price without leaving the auction mode, -* generate the trades implied by the above and update the positions, -* carry out settlement based on the updated positions, -* let the market carry on in the same auction mode it was in before the settlement data was received until relevant auction exit conditions are met and the market returns to its default trading mode. +Periodic settlement is not allowed during the opening auction and it's extensions. +If periodic settlement data happens whilst market is in auction of any other type then periodic settlement should be carried out as per above methodology and the market should remain in auction until it's allowed to move back into market's default trading mode. -### 4.3 Protective auctions +### 4.5 Protective auctions In additional to protective auctions available for any market on Vega this product has protective auctions that are specific to it. -### 4.3.1 Awaiting periodic settlement data +### 4.5.1 `max_settlement_schedule_gap` breached + +If the amount of time since last receipt of an event from the `settlement_schedule` oracle exceeds `max_settlement_schedule_gap` set for the market then the market goes into auction mode and remains in it until new `settlement_schedule` event is received. The process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). +The timer should be started when market leaves the opening auction and reset each time a valid event from `settlement_schedule` oracle is received. + +### 4.5.2 `max_settlement_data_gap` breached + +Likewise, of the amount of time since last receipt of a valid event from the `settlement_data` oracle exceeds `max_settlement_data_gap` set for the market then the market goes into auction mode and remains in it until a valid `settlement_data` event is received. No further periodic settlements are carried out even if `settlement_schedule` events get received, the process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). +The timer should be started when market leaves the opening auction and reset each time a valid event from `settlement_data` oracle is received. -An optional auction of predetermined maximum duration which gets triggered when the [settlement cue](#41-periodic-settlement-cue) data arrives and ends either upon receiving a valid settlement data or when the auction duration elapses. +Note that there are two separate timers, one for `max_settlement_schedule_gap` and one for `max_settlement_data_gap`. -### 4.3.2 Max settlement gap exceeded +### API considerations -If the amount of time since last [periodic settlement](#41-periodic-settlement-cue) exceeds `max_settlement_gap` set for the market then the market goes into auction mode and remains in it until new settlement data is received. Upon receiving the settlement data the auction uncrosses, positions are updated and then settled using the newly arrived data. It is possible to update the market's data source when it is in protective auction. +It should be possible to query the market for the list of current funding rate data points as well as history of calculated funding rate values. ## Acceptance Criteria 1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source. (0053-COSMICELEVATOR-001) 1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega. (0053-COSMICELEVATOR-002) -1. The data source can be changed via governance. (0053-COSMICELEVATOR-003) +1. Any of the data sources used by the product can be changed via governance. (0053-COSMICELEVATOR-003) 1. It is not possible to change settlement asset via governance. (0053-COSMICELEVATOR-004) 1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of periodic settlement driven by the oracle data. (0053-COSMICELEVATOR-005) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles during liquidity monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles during price monitoring auction results in partial uncrossing of the auction at received price and periodic settlement. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles with settlement price violating a price monitoring bound does not cause periodic settlement and the market remains in the awaiting periodic settlement data auction it elapses at which point the auction uncrosses and market returns to its default trading mode (0053-COSMICELEVATOR-010) -1. Periodic settlement causes settlement cashflows to be created, funds to be transferred and the [mark price](0021-MDAT-market_data_spec.md#market-data-fields) to be updated. (0053-COSMICELEVATOR-011) -1. Once the max settlement gap gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (0053-COSMICELEVATOR-012) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) +1. Receiving an event from the `settlement_schedule` oracle during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) +1. Receiving correctly formatted data from the settlement cue, settlement data oracles and `settlement_schedule` oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) +1. Receiving correctly formatted data from the settlement cue, settlement data and `settlement_schedule` oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) +1. Receiving correctly formatted data from the settlement cue, settlement data and `settlement_schedule` oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) +1. Once the `max_settlement_schedule_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement schedule oracle during that auction and once the new data is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_data_gap` was not triggered in the interim) (0053-COSMICELEVATOR-012) +1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_schedule_gap` was not triggered in the interim) (0053-COSMICELEVATOR-013) +1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction. Before the arrival of correctly formatted data from the settlement cue and settlement data oracles `max_settlement_schedule_gap` gets triggered. Market only out of auction once correctly formatted data from all 3 oracles (in any valid order) arrives. (0053-COSMICELEVATOR-014) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-015) From 1fa15db0e3fb146d42afd9ca120b427b59848fc9 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 2 May 2023 00:37:52 +0200 Subject: [PATCH 183/649] refactor: cosmetic changes --- ...3-PERP-product_builtin_perpetual_future.md | 45 ++++++++++--------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 072e0478a..5c0ce2685 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -1,10 +1,10 @@ -# Built-in [Product](./0051-PROD-product.md): Cash Settled Perpetual Futures (CSF) +# Built-in [Product](./0051-PROD-product.md): Cash Settled Perpetual Futures This built-in product provides perpetual futures contracts that are cash-settled, i.e. they are margined and settled in a single asset, and they never expire. Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures), [2](https://arxiv.org/pdf/2212.06888.pdf). -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered and data obtained from the `settlement_data_cue` and `settlement_data` oracles is used to calcualte the funding rate. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to conecutive `settlement_schedule` events is used to calculate the funding rate and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. ## 1. Product parameters @@ -13,13 +13,13 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_data_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. 1. `max_settlement_schedule_gap`: a time interval which specifies the amount of time without the receipt of a valid `settlement_schedule` oracle event after which the market will go into protective auction and remain in that mode until `settlement_schedule` data is received. -1. `max_settlement_data_gap`:a time interval which specifies the amount of time without the receipt of a valid `settlement_data` oracle event after which the market will go into protective auction and remain in that mode until `settlement_data` data is received. +1. `max_settlement_data_gap`:a time interval which specifies the amount of time without the receipt of a valid `settlement_data` oracle event after which the market will go into protective auction and remain in that mode until `settlement_data` event meeting its filtering requirements is received. Validation: none required as these are validated by the asset and data source frameworks. ### Example specification -The pseudocode below specifies a possible configuration of the built-in perpetual futures contract product. The emphasis is on modelling required properties of this product, not the exact semantics used as these will most likely differ in the implementation. +The pseudocode below specifies a possible configuration of the built-in perpetual futures product. The emphasis is on modelling required properties of this product, not the exact semantics used as these will most likely differ in the implementation. ```yaml product: built-in perpetual futures contract @@ -61,7 +61,7 @@ cash_settled_perpetual_future.value(quote) { ## 4. Lifecycle triggers -### 4.1 Periodic settlement cue +### 4.1. Periodic settlement cue Whenever an appropriate event is received the settlement cue returns the current `vegaprotocol.builtin.timestamp` to indicate the time around which the next periodic settlement data point is expected: @@ -71,17 +71,17 @@ cash_settled_perpetual_future.settlement_cue(event) { } ``` -### 4.2 Periodic settlement data point received +### 4.2. Periodic settlement data point received -Once the [periodic settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding rate data point. +Once the [settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding rate data point. -### 4.3 Mark to market settlement +### 4.3. Mark to market settlement -Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along the mark price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding rate data point. If no periodic settlement data has been received yet then the funding rate data point should not be created. +Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along with the price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding rate data point. If no periodic settlement data has been received yet then the funding rate data point should not be created. -### 4.4 Periodic settlement +### 4.4. Periodic settlement -When the `settlement_schedule` event is received additional funding data point gets stored using the last received periodic settlement cue, current `mark_price` and the current `vegaprotocol.builtin.timestamp`. +When the `settlement_schedule` event is received the latest funding rate data point gets repeated with the timestamp set to the current value of `vegaprotocol.builtin.timestamp`. The next step is to calculate the periodic settlement funding rate. If there are no periodic settlement data points then the periodic settlement is skipped. Otherwise, consider all the periodic settlement data points and calculate the time-weighted average price difference as: @@ -101,26 +101,26 @@ All the funding rate data points except for the last one (it should get carried Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding rate}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding rate is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). -### 4.4.1 Periodic settlement during [auction](0026-AUCT-auctions.md) +### 4.4.1. Periodic settlement during [auction](0026-AUCT-auctions.md) Periodic settlement is not allowed during the opening auction and it's extensions. If periodic settlement data happens whilst market is in auction of any other type then periodic settlement should be carried out as per above methodology and the market should remain in auction until it's allowed to move back into market's default trading mode. -### 4.5 Protective auctions +### 4.5. Protective auctions In additional to protective auctions available for any market on Vega this product has protective auctions that are specific to it. -### 4.5.1 `max_settlement_schedule_gap` breached +### 4.5.1. `max_settlement_schedule_gap` breached If the amount of time since last receipt of an event from the `settlement_schedule` oracle exceeds `max_settlement_schedule_gap` set for the market then the market goes into auction mode and remains in it until new `settlement_schedule` event is received. The process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). The timer should be started when market leaves the opening auction and reset each time a valid event from `settlement_schedule` oracle is received. -### 4.5.2 `max_settlement_data_gap` breached +### 4.5.2. `max_settlement_data_gap` breached -Likewise, of the amount of time since last receipt of a valid event from the `settlement_data` oracle exceeds `max_settlement_data_gap` set for the market then the market goes into auction mode and remains in it until a valid `settlement_data` event is received. No further periodic settlements are carried out even if `settlement_schedule` events get received, the process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). +Likewise, if the amount of time since last receipt of a valid event from the `settlement_data` oracle exceeds `max_settlement_data_gap` set for the market then the market goes into auction mode and remains in it until a valid `settlement_data` event is received. No further periodic settlements are carried out even if `settlement_schedule` events get received, the process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). The timer should be started when market leaves the opening auction and reset each time a valid event from `settlement_data` oracle is received. -Note that there are two separate timers, one for `max_settlement_schedule_gap` and one for `max_settlement_data_gap`. +Note that there are two separate timers, one for `max_settlement_schedule_gap` and one for `max_settlement_data_gap`. It is also possible for both of these triggers to be breached at the same time, if that is the case the market should only leave the auction once both of them are no longer breached (we have both an even from `settlement_schedule` oracle received less than `max_settlement_schedule_gap` ago and a valid settlement data no older than `max_settlement_data_gap`). ### API considerations @@ -131,12 +131,13 @@ It should be possible to query the market for the list of current funding rate d 1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source. (0053-COSMICELEVATOR-001) 1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega. (0053-COSMICELEVATOR-002) 1. Any of the data sources used by the product can be changed via governance. (0053-COSMICELEVATOR-003) +1. It is possible to change `max_settlement_schedule_gap` and `max_settlement_data_gap` market parameters via governance. (0053-COSMICELEVATOR-016) 1. It is not possible to change settlement asset via governance. (0053-COSMICELEVATOR-004) -1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of periodic settlement driven by the oracle data. (0053-COSMICELEVATOR-005) -1. Receiving an event from the `settlement_schedule` oracle during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) -1. Receiving correctly formatted data from the settlement cue, settlement data oracles and `settlement_schedule` oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) -1. Receiving correctly formatted data from the settlement cue, settlement data and `settlement_schedule` oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) -1. Receiving correctly formatted data from the settlement cue, settlement data and `settlement_schedule` oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) +1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of the behaviour of any of the oracles specified for the market. (0053-COSMICELEVATOR-005) +1. Receiving an event from the settlement schedule oracle during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) +1. Receiving correctly formatted data from the settlement cue, settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) +1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) +1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) 1. Once the `max_settlement_schedule_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement schedule oracle during that auction and once the new data is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_data_gap` was not triggered in the interim) (0053-COSMICELEVATOR-012) 1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_schedule_gap` was not triggered in the interim) (0053-COSMICELEVATOR-013) 1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction. Before the arrival of correctly formatted data from the settlement cue and settlement data oracles `max_settlement_schedule_gap` gets triggered. Market only out of auction once correctly formatted data from all 3 oracles (in any valid order) arrives. (0053-COSMICELEVATOR-014) From cf048ec99dbb352daa97dd503b16d14dde9f63c0 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 2 May 2023 00:43:41 +0200 Subject: [PATCH 184/649] chore: fix approbation errors --- protocol/0053-PERP-product_builtin_perpetual_future.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 5c0ce2685..cee26fb66 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -131,14 +131,14 @@ It should be possible to query the market for the list of current funding rate d 1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source. (0053-COSMICELEVATOR-001) 1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega. (0053-COSMICELEVATOR-002) 1. Any of the data sources used by the product can be changed via governance. (0053-COSMICELEVATOR-003) -1. It is possible to change `max_settlement_schedule_gap` and `max_settlement_data_gap` market parameters via governance. (0053-COSMICELEVATOR-016) 1. It is not possible to change settlement asset via governance. (0053-COSMICELEVATOR-004) 1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of the behaviour of any of the oracles specified for the market. (0053-COSMICELEVATOR-005) 1. Receiving an event from the settlement schedule oracle during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) 1. Receiving correctly formatted data from the settlement cue, settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) 1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) 1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. Once the `max_settlement_schedule_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement schedule oracle during that auction and once the new data is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_data_gap` was not triggered in the interim) (0053-COSMICELEVATOR-012) -1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_schedule_gap` was not triggered in the interim) (0053-COSMICELEVATOR-013) -1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction. Before the arrival of correctly formatted data from the settlement cue and settlement data oracles `max_settlement_schedule_gap` gets triggered. Market only out of auction once correctly formatted data from all 3 oracles (in any valid order) arrives. (0053-COSMICELEVATOR-014) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-015) +1. Once the `max_settlement_schedule_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement schedule oracle during that auction and once the new data is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_data_gap` was not triggered in the interim) (0053-COSMICELEVATOR-010) +1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_schedule_gap` was not triggered in the interim) (0053-COSMICELEVATOR-011) +1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction. Before the arrival of correctly formatted data from the settlement cue and settlement data oracles `max_settlement_schedule_gap` gets triggered. Market only out of auction once correctly formatted data from all 3 oracles (in any valid order) arrives. (0053-COSMICELEVATOR-012) +1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) +1. It is possible to change `max_settlement_schedule_gap` and `max_settlement_data_gap` market parameters via governance. (0053-COSMICELEVATOR-014) From a1e85b86856186592463d5872c0799232cd6fb6a Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 2 May 2023 00:50:25 +0200 Subject: [PATCH 185/649] chore: fix spelling --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index cee26fb66..0e4b9eb47 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,7 +4,7 @@ This built-in product provides perpetual futures contracts that are cash-settled Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures), [2](https://arxiv.org/pdf/2212.06888.pdf). -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to conecutive `settlement_schedule` events is used to calculate the funding rate and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to consecutive `settlement_schedule` events is used to calculate the funding rate and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. ## 1. Product parameters From bb52a036370dcb5a09872e31ac2736f1d5005ff1 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 22 May 2023 17:22:15 +0200 Subject: [PATCH 186/649] refactor: Update protocol/0053-PERP-product_builtin_perpetual_future.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 0e4b9eb47..5e05208b8 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -90,7 +90,7 @@ sd := 0 st := 0 for i := 0; i < len(data_points) - 1; i++ { t := data_points[i+1].t-data_points[i].t - d := data_points[i].x - data_points[i].y + d := data_points[i].x - data_points[i].y // recall that x stands for mark price and y for the external price source input sd += d * t st += t } From 2a412404a7a2e83831a0f7a34ed84fbdc4ffe513 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 28 Jun 2023 09:46:05 +0200 Subject: [PATCH 187/649] refactor: bring spec in line with research note --- ...3-PERP-product_builtin_perpetual_future.md | 37 ++++++++++++++----- wordlist.txt | 2 + 2 files changed, 29 insertions(+), 10 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 5e05208b8..80430015c 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,7 +4,9 @@ This built-in product provides perpetual futures contracts that are cash-settled Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures), [2](https://arxiv.org/pdf/2212.06888.pdf). -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to consecutive `settlement_schedule` events is used to calculate the funding rate and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. + +Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the form $G_i = frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. ## 1. Product parameters @@ -13,7 +15,8 @@ Perpetual futures are a simple "delta one" product. Mark-to-market settlement oc 1. `settlement_data_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. 1. `max_settlement_schedule_gap`: a time interval which specifies the amount of time without the receipt of a valid `settlement_schedule` oracle event after which the market will go into protective auction and remain in that mode until `settlement_schedule` data is received. -1. `max_settlement_data_gap`:a time interval which specifies the amount of time without the receipt of a valid `settlement_data` oracle event after which the market will go into protective auction and remain in that mode until `settlement_data` event meeting its filtering requirements is received. +1. `max_settlement_data_gap`: a time interval which specifies the amount of time without the receipt of a valid `settlement_data` oracle event after which the market will go into protective auction and remain in that mode until `settlement_data` event meeting its filtering requirements is received. +1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding rate liability contributes to party's margin. Validation: none required as these are validated by the asset and data source frameworks. @@ -73,17 +76,17 @@ cash_settled_perpetual_future.settlement_cue(event) { ### 4.2. Periodic settlement data point received -Once the [settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding rate data point. +Once the [settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding payment data point. ### 4.3. Mark to market settlement -Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along with the price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding rate data point. If no periodic settlement data has been received yet then the funding rate data point should not be created. +Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along with the price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding payment data point. If no periodic settlement data has been received yet then the funding payment data point should not be created. ### 4.4. Periodic settlement -When the `settlement_schedule` event is received the latest funding rate data point gets repeated with the timestamp set to the current value of `vegaprotocol.builtin.timestamp`. +When the `settlement_schedule` event is received the latest funding payment data point gets repeated with the timestamp set to the current value of `vegaprotocol.builtin.timestamp`. -The next step is to calculate the periodic settlement funding rate. If there are no periodic settlement data points then the periodic settlement is skipped. Otherwise, consider all the periodic settlement data points and calculate the time-weighted average price difference as: +The next step is to calculate the periodic settlement funding payment. If there are no periodic settlement data points then the periodic settlement is skipped. Otherwise, consider all the periodic settlement data points and calculate the time-weighted average price difference as: ```go sd := 0 @@ -94,12 +97,12 @@ for i := 0; i < len(data_points) - 1; i++ { sd += d * t st += t } -funding_rate = sd / st +funding_payment = sd / st ``` -All the funding rate data points except for the last one (it should get carried over as the first data point for the next period) can then be deleted. +All the funding payment data points except for the last one (it should get carried over as the first data point for the next period) can then be deleted. -Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding rate}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding rate is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). +Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding payment}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding payment is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). ### 4.4.1. Periodic settlement during [auction](0026-AUCT-auctions.md) @@ -122,9 +125,21 @@ The timer should be started when market leaves the opening auction and reset eac Note that there are two separate timers, one for `max_settlement_schedule_gap` and one for `max_settlement_data_gap`. It is also possible for both of these triggers to be breached at the same time, if that is the case the market should only leave the auction once both of them are no longer breached (we have both an even from `settlement_schedule` oracle received less than `max_settlement_schedule_gap` ago and a valid settlement data no older than `max_settlement_data_gap`). +### 5. Margin considerations + +To assure adequate solvency we need to include the estimate of the upcoming funding payment in maintenance margin estimate for the party. Let $t_{k-1}$ be the time of the last funding payment. Let $t$ be current time ($t < t_k$). +Calculate $G_t$ as the [funding payment](#44-periodic-settlement) between $t_k$ and $t$. +For perpetual futures markets set the maintenance margin as: + +```math +m^{\text{maint (perps)}}_t = m^{\text{maint}}_t + \text{margin funding factor} \cdot \max(0,G_t), +``` + +where $m^{\text{maint}}_t$ is the current maintenance margin as per the [margin spec](./0019-MCAL-margin_calculator.md) + ### API considerations -It should be possible to query the market for the list of current funding rate data points as well as history of calculated funding rate values. +It should be possible to query the market for the list of current funding payment data points as well as history of calculated funding payment values. ## Acceptance Criteria @@ -142,3 +157,5 @@ It should be possible to query the market for the list of current funding rate d 1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction. Before the arrival of correctly formatted data from the settlement cue and settlement data oracles `max_settlement_schedule_gap` gets triggered. Market only out of auction once correctly formatted data from all 3 oracles (in any valid order) arrives. (0053-COSMICELEVATOR-012) 1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) 1. It is possible to change `max_settlement_schedule_gap` and `max_settlement_data_gap` market parameters via governance. (0053-COSMICELEVATOR-014) +1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-COSMICELEVATOR-015) +1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-COSMICELEVATOR-016) \ No newline at end of file diff --git a/wordlist.txt b/wordlist.txt index ffec72765..0f992af07 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -153,6 +153,7 @@ LP LPs MacOS mainnet +maint malus margined margining @@ -253,6 +254,7 @@ tradable trackable Tron trustless +TWAP tx TXs quant From 46183940e3c3c29c3b2c5e9aa2c86bfc5c70a799 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 28 Jun 2023 09:52:58 +0200 Subject: [PATCH 188/649] refactor: address PR comments --- ...3-PERP-product_builtin_perpetual_future.md | 31 +++---------------- 1 file changed, 4 insertions(+), 27 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 80430015c..d247854f8 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -12,10 +12,8 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. 1. `settlement_schedule (Data Source: datetime)`: this data is used to indicate when the next periodic settlement should be carried out. -1. `settlement_data_cue (Data Source: datetime)`: this data is used to indicate the earliest time at which the next `settlement_data` should be expected. +1. `settlement_data_cue (Data Source: datetime)` (optional): if specified, this data is used to indicate the earliest time at which the next `settlement_data` should be expected. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. -1. `max_settlement_schedule_gap`: a time interval which specifies the amount of time without the receipt of a valid `settlement_schedule` oracle event after which the market will go into protective auction and remain in that mode until `settlement_schedule` data is received. -1. `max_settlement_data_gap`: a time interval which specifies the amount of time without the receipt of a valid `settlement_data` oracle event after which the market will go into protective auction and remain in that mode until `settlement_data` event meeting its filtering requirements is received. 1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding rate liability contributes to party's margin. Validation: none required as these are validated by the asset and data source frameworks. @@ -45,8 +43,6 @@ The pseudocode below specifies a possible configuration of the built-in perpetua - 'timestamp': >= 'settlement_cue.time' - 'timestamp': <= 'settlement_cue.time' + "10s" - 'ticker': 'TSLA' - max_settlement_schedule_gap: "17h" - max_settlement_data_gap: "1h" ``` ## 2. Settlement assets @@ -76,7 +72,9 @@ cash_settled_perpetual_future.settlement_cue(event) { ### 4.2. Periodic settlement data point received -Once the [settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) at and to use the time provided by the settlement cue as a variable in such filter. If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding payment data point. +If settlement cue is not specified then all the coming from the settlement data oracle gets ingested. If settlement cue is specified, then once the [settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received at (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) and to use the time provided by the settlement cue as a variable in such filter. + +If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding payment data point. ### 4.3. Mark to market settlement @@ -109,22 +107,6 @@ Last step is to calculate each party's cash flows as $-\text{open volume} * \tex Periodic settlement is not allowed during the opening auction and it's extensions. If periodic settlement data happens whilst market is in auction of any other type then periodic settlement should be carried out as per above methodology and the market should remain in auction until it's allowed to move back into market's default trading mode. -### 4.5. Protective auctions - -In additional to protective auctions available for any market on Vega this product has protective auctions that are specific to it. - -### 4.5.1. `max_settlement_schedule_gap` breached - -If the amount of time since last receipt of an event from the `settlement_schedule` oracle exceeds `max_settlement_schedule_gap` set for the market then the market goes into auction mode and remains in it until new `settlement_schedule` event is received. The process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). -The timer should be started when market leaves the opening auction and reset each time a valid event from `settlement_schedule` oracle is received. - -### 4.5.2. `max_settlement_data_gap` breached - -Likewise, if the amount of time since last receipt of a valid event from the `settlement_data` oracle exceeds `max_settlement_data_gap` set for the market then the market goes into auction mode and remains in it until a valid `settlement_data` event is received. No further periodic settlements are carried out even if `settlement_schedule` events get received, the process resumes as per the opening auction uncrossing once data is received (which may first require a governance vote changing the oracle for the market). -The timer should be started when market leaves the opening auction and reset each time a valid event from `settlement_data` oracle is received. - -Note that there are two separate timers, one for `max_settlement_schedule_gap` and one for `max_settlement_data_gap`. It is also possible for both of these triggers to be breached at the same time, if that is the case the market should only leave the auction once both of them are no longer breached (we have both an even from `settlement_schedule` oracle received less than `max_settlement_schedule_gap` ago and a valid settlement data no older than `max_settlement_data_gap`). - ### 5. Margin considerations To assure adequate solvency we need to include the estimate of the upcoming funding payment in maintenance margin estimate for the party. Let $t_{k-1}$ be the time of the last funding payment. Let $t$ be current time ($t < t_k$). @@ -152,10 +134,5 @@ It should be possible to query the market for the list of current funding paymen 1. Receiving correctly formatted data from the settlement cue, settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) 1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) 1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. Once the `max_settlement_schedule_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement schedule oracle during that auction and once the new data is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_data_gap` was not triggered in the interim) (0053-COSMICELEVATOR-010) -1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction and once the new, correctly formatted, data from both oracles is received periodic settlement is carried out and the market goes out of auction (assuming `max_settlement_schedule_gap` was not triggered in the interim) (0053-COSMICELEVATOR-011) -1. Once the `max_settlement_data_gap` gets exceeded the market goes into auction with no fixed duration. It is possible to change the settlement cue and settlement data oracles during that auction. Before the arrival of correctly formatted data from the settlement cue and settlement data oracles `max_settlement_schedule_gap` gets triggered. Market only out of auction once correctly formatted data from all 3 oracles (in any valid order) arrives. (0053-COSMICELEVATOR-012) -1. Receiving correctly formatted data from the settlement cue and settlement data oracles, but at time that violates the `vegaprotocol.builtin.timestamp` filter of the settlement data oracle does NOT result in periodic settlement. The market remains in auction mode for the entire `settlement_cue_auction_duration`, uncrosses, returns to continuous trading and does not attempt another periodic settlement until the next data is received by the settlement cue oracle (0053-COSMICELEVATOR-013) -1. It is possible to change `max_settlement_schedule_gap` and `max_settlement_data_gap` market parameters via governance. (0053-COSMICELEVATOR-014) 1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-COSMICELEVATOR-015) 1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-COSMICELEVATOR-016) \ No newline at end of file From 1e630a6cae2f5213f4062acc3dd71ab7c4b99f5e Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 28 Jun 2023 09:53:41 +0200 Subject: [PATCH 189/649] refactor: use proper AC format now --- ...3-PERP-product_builtin_perpetual_future.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index d247854f8..fbf905145 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -125,14 +125,14 @@ It should be possible to query the market for the list of current funding paymen ## Acceptance Criteria -1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source. (0053-COSMICELEVATOR-001) -1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega. (0053-COSMICELEVATOR-002) -1. Any of the data sources used by the product can be changed via governance. (0053-COSMICELEVATOR-003) -1. It is not possible to change settlement asset via governance. (0053-COSMICELEVATOR-004) -1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of the behaviour of any of the oracles specified for the market. (0053-COSMICELEVATOR-005) -1. Receiving an event from the settlement schedule oracle during the opening auction does not cause settlement. (0053-COSMICELEVATOR-006) -1. Receiving correctly formatted data from the settlement cue, settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-COSMICELEVATOR-007) -1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-COSMICELEVATOR-008) -1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-COSMICELEVATOR-009) -1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-COSMICELEVATOR-015) -1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-COSMICELEVATOR-016) \ No newline at end of file +1. Create a Cash Settled Perpetual Future with the settlement data provided by an external data source. (0053-PERP-001) +1. Create a Cash Settled Perpetual Future for any settlement asset that's configured in Vega. (0053-PERP-002) +1. Any of the data sources used by the product can be changed via governance. (0053-PERP-003) +1. It is not possible to change settlement asset via governance. (0053-PERP-004) +1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of the behaviour of any of the oracles specified for the market. (0053-PERP-005) +1. Receiving an event from the settlement schedule oracle during the opening auction does not cause settlement. (0053-PERP-006) +1. Receiving correctly formatted data from the settlement cue, settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-PERP-007) +1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-PERP-008) +1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-PERP-009) +1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) +1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) \ No newline at end of file From 49269a2a1f34b34cb3491cc6db6d05e7e036136b Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 28 Jun 2023 09:57:12 +0200 Subject: [PATCH 190/649] refactor: fix latex formatting --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index fbf905145..e8e4b5812 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -6,7 +6,7 @@ Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Pe Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. -Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the form $G_i = frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. +Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the form $G_i = \frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. ## 1. Product parameters From 52da09e052ed80fce88c24c37f32d23314615c15 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 28 Jun 2023 09:59:45 +0200 Subject: [PATCH 191/649] refactor: cosmetic changes --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index e8e4b5812..b5fb82c2a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -135,4 +135,4 @@ It should be possible to query the market for the list of current funding paymen 1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-PERP-008) 1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-PERP-009) 1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) -1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) \ No newline at end of file +1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) From 49309b5edadee72bf7a631dbb49ff7dea35f98b5 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 28 Jun 2023 10:26:58 +0200 Subject: [PATCH 192/649] refactor: remove settlement cue --- ...3-PERP-product_builtin_perpetual_future.md | 39 +++++-------------- 1 file changed, 10 insertions(+), 29 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index b5fb82c2a..0982121ff 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,7 +4,7 @@ This built-in product provides perpetual futures contracts that are cash-settled Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures), [2](https://arxiv.org/pdf/2212.06888.pdf). -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data_cue` and `settlement_data` oracles between to consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. A number of protective measures are defined to deal with data availability issues in a predefined way. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data` oracle between to consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the form $G_i = \frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. @@ -12,7 +12,6 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. 1. `settlement_schedule (Data Source: datetime)`: this data is used to indicate when the next periodic settlement should be carried out. -1. `settlement_data_cue (Data Source: datetime)` (optional): if specified, this data is used to indicate the earliest time at which the next `settlement_data` should be expected. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. 1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding rate liability contributes to party's margin. @@ -30,18 +29,12 @@ The pseudocode below specifies a possible configuration of the built-in perpetua repeating: - every 8h from 20230201T09:30:00 - every 168h from 20230203T12:00:00 - settlement_cue: - internal_time_oracle: - repeating: - - every 1min from 20230201T09:30:00 settlement_data: data_source: SignedMessage{ pubkey=0xA45e...d6 } field: 'price' filters: - - vegaprotocol.builtin.timestamp: >= 'settlement_cue.time' - - vegaprotocol.builtin.timestamp: <= 'settlement_cue.time' + "15s" - - 'timestamp': >= 'settlement_cue.time' - - 'timestamp': <= 'settlement_cue.time' + "10s" + - 'timestamp': >= vegaprotocol.builtin.timestamp + - 'timestamp': <= vegaprotocol.builtin.timestamp + "10s" - 'ticker': 'TSLA' ``` @@ -60,27 +53,15 @@ cash_settled_perpetual_future.value(quote) { ## 4. Lifecycle triggers -### 4.1. Periodic settlement cue - -Whenever an appropriate event is received the settlement cue returns the current `vegaprotocol.builtin.timestamp` to indicate the time around which the next periodic settlement data point is expected: - -```javascript -cash_settled_perpetual_future.settlement_cue(event) { - return vegaprotocol.builtin.timestamp -} -``` - -### 4.2. Periodic settlement data point received - -If settlement cue is not specified then all the coming from the settlement data oracle gets ingested. If settlement cue is specified, then once the [settlement cue](#41-periodic-settlement-cue) time is received the specified settlement data oracle gets monitored for incoming data. It must be possible to filter the data by the time it was received at (see [0048-DSRI-data_source_internal](./0048-DSRI-data_source_internal.md#13-vega-time-changed)) and to use the time provided by the settlement cue as a variable in such filter. +### 4.1. Periodic settlement data point received If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding payment data point. -### 4.3. Mark to market settlement +### 4.2. Mark to market settlement Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along with the price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding payment data point. If no periodic settlement data has been received yet then the funding payment data point should not be created. -### 4.4. Periodic settlement +### 4.3. Periodic settlement When the `settlement_schedule` event is received the latest funding payment data point gets repeated with the timestamp set to the current value of `vegaprotocol.builtin.timestamp`. @@ -102,7 +83,7 @@ All the funding payment data points except for the last one (it should get carri Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding payment}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding payment is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). -### 4.4.1. Periodic settlement during [auction](0026-AUCT-auctions.md) +### 4.3.1. Periodic settlement during [auction](0026-AUCT-auctions.md) Periodic settlement is not allowed during the opening auction and it's extensions. If periodic settlement data happens whilst market is in auction of any other type then periodic settlement should be carried out as per above methodology and the market should remain in auction until it's allowed to move back into market's default trading mode. @@ -131,8 +112,8 @@ It should be possible to query the market for the list of current funding paymen 1. It is not possible to change settlement asset via governance. (0053-PERP-004) 1. [Mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) works correctly with a predefined frequency irrespective of the behaviour of any of the oracles specified for the market. (0053-PERP-005) 1. Receiving an event from the settlement schedule oracle during the opening auction does not cause settlement. (0053-PERP-006) -1. Receiving correctly formatted data from the settlement cue, settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-PERP-007) -1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-PERP-008) -1. Receiving correctly formatted data from the settlement cue, settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-PERP-009) +1. Receiving correctly formatted data from settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-PERP-007) +1. Receiving correctly formatted data from the settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-PERP-008) +1. Receiving correctly formatted data from the settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-PERP-009) 1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) 1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) From 5c00e0ef1ead37f69bb25cd2ef7bafbfbceb49de Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 28 Jun 2023 11:49:58 +0100 Subject: [PATCH 193/649] Revert "Add network history AC 0044 sla spec" --- protocol/0044-LIME-lp_mechanics.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 1b5acf27b..0f959b393 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -323,12 +323,8 @@ Note: ### Checkpoint -- Snapshot for the Bonus account and Fee account are captured so that when a new validator node joins the network they can use the two account types Bonus and Fee account (0044-LIME-030) +- Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) ### Protocol upgrade -- After a protocol upgrade the bonus and fee accounts and their balances are maintained (0044-LIME-031) - -### Network history - -- A datanode restored from network history will contain any transfers created prior to the restore and these can be retrieved via APIs on the new datanode (0044-LIME-034) +- After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) From c17b26dc6480a169f4830f55991c060d3e0a572e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 28 Jun 2023 14:58:13 +0100 Subject: [PATCH 194/649] feat: add ACs on 08/09/011 --- protocol/0008-TRAD-trading_workflow.md | 2 +- protocol/0009-MRKP-mark_price.md | 6 +++--- .../0011-MARA-check_order_allocate_margin.md | 17 +++++++++++++++++ 3 files changed, 21 insertions(+), 4 deletions(-) diff --git a/protocol/0008-TRAD-trading_workflow.md b/protocol/0008-TRAD-trading_workflow.md index 6eb0f2ceb..2b1e22469 100644 --- a/protocol/0008-TRAD-trading_workflow.md +++ b/protocol/0008-TRAD-trading_workflow.md @@ -10,7 +10,7 @@ The order of processing of transactions happens in the order defined in the diag 1. Before a valid order is processed in any other way by Vega, the [party](./0017-PART-party.md)'s [margin levels](./0011-MARA-check_order_allocate_margin.md) are checked as though they had the order in their position, and any transfers that are needed to support that order occur. (0008-TRAD-001) 1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there will be changes in positions for one or more traders. (0008-TRAD-002) -1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003) +1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003)(0008-SP-TRAD-003) 1. Following the above 3 actions, a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is run for all parties against their most recently updated positions and Mark Price. This will result in a set of transfers between the parties' accounts and possibly may result in loss socialisation occurring if a party has insufficient collateral to cover the move. (0008-TRAD-004) 1. Following the mark to market settlement, the margin liabilities for traders are evaluated against their collateral balances. Any traders that do not have sufficient collateral to support their positions (after collateral searches have been done to their main account) will undergo position resolution. (0008-TRAD-005) 1. After position resolution has occurred, margins are recalculated and evaluated against balances for any traders that gained positions as a result of supplying liquidity on the order book to the network during position resolution. (0008-TRAD-006) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 6c2f981ea..033348a77 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -12,11 +12,11 @@ Introduce a network parameter `network.markPriceUpdateMaximumFrequency` with min Algorithm 1: -- If `network.markPriceUpdateMaximumFrequency=0s` then any transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade. (0009-MRKP-003) -- If `network.markPriceUpdateMaximumFrequency>0` then out of a sequence of transactions with the same time-stamp the last transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade but only provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last update. (0009-MRKP-007) +- If `network.markPriceUpdateMaximumFrequency=0s` then any transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade. (0009-MRKP-003)(0009-SP-MRKP-003) +- If `network.markPriceUpdateMaximumFrequency>0` then out of a sequence of transactions with the same time-stamp the last transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade but only provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last update. (0009-MRKP-007)(0009-SP-MRKP-007) - A transaction that doesn't result in a trade does not cause the mark price to change. (0009-MRKP-004) - A transaction out of a sequence of transactions with the same time stamp which isn't the last trade-causing transaction will *not* result in a mark price change. (0009-MRKP-008) -- The mark price must be using market decimal place setting (0009-MRKP-006) +- The mark price must be using market decimal place setting (0009-MRKP-006)(0009-SP-MRKP-006) ## Guide-level explanation diff --git a/protocol/0011-MARA-check_order_allocate_margin.md b/protocol/0011-MARA-check_order_allocate_margin.md index 722afe1f6..37e611bd6 100644 --- a/protocol/0011-MARA-check_order_allocate_margin.md +++ b/protocol/0011-MARA-check_order_allocate_margin.md @@ -9,10 +9,14 @@ Orders should be rejected if we can’t allocate sufficient margin. ## Acceptance criteria 1. If an order is amended such that margin requirement is increased and user has sufficient balance in the general account to top up their margin account then the amendment is executed successfully. (0011-MARA-001) +1. In Spot market, if an order is amended such that holding requirement is increased and user has sufficient balance in the general account to top up their holding account then the amendment is executed successfully. (0011-SP-MARA-001) 1. If an order is amended such that margin requirement is increased and user doesn't have sufficient balance in the general account to top up their margin account then their amend is not executed but the unamended order stays on the book. (0011-MARA-002) +1. In Spot market, if an order is amended such that holding requirement is increased and user doesn't have sufficient balance in the general account to top up their holding account then their amend is not executed but the unamended order stays on the book. (0011-SP-MARA-002) 1. Cancelling an order releases the margin amount back to user's general account, provided the user has no other orders or positions (0011-MARA-003) +In Spot markte, cancelling an order releases the holding amount back to user's general account. (0011-SP-MARA-003) 1. If an order is amended such that margin requirement is decreased then the amendment is executed successfully. (0011-MARA-004) 1. If an order is partially filled then the margin requirements are recalculated reflecting the reduced order size and new position size. (0011-MARA-005) +In Spot market, if an order is partially filled then the holding requirements are recalculated reflecting the reduced order size. (0011-SP-MARA-005) 1. If an order is partially filled and if this leads to a reduced position and reduced riskiest long / short then the margin requirements are seen to be reduced and if margin balance is above release level then the excess amount is transferred to the general account. (0011-MARA-006) 1. Margin is correctly calculated for [all order types](./0014-ORDT-order_types.md) in continuous trading: 1. Limit GTT (0011-MARA-007) @@ -27,6 +31,19 @@ Orders should be rejected if we can’t allocate sufficient margin. 1.Limit GFA (0011-MARA-015) 1.Pegged GTT (parked in auction \*) (0011-MARA-016) 1.Pegged GTC (parked in auction \* ) (0011-MARA-017) +1. In Spot market, holding in holding account is correctly calculated for [all order types](./0014-ORDT-order_types.md) in continuous trading: + 1. Limit GTT (0011-SP-MARA-007) + 1. Limit GTC (0011-SP-MARA-008) + 1. Limit GFN (0011-SP-MARA-009) + 1. Pegged GTT (0011-SP-MARA-010) + 1. Pegged GTC (0011-SP-MARA-011) + 1. Pegged GFN (0011-SP-MARA-012) +1. In Spot market, holding in holding account is correctly calculated for [all order types](./0014-ORDT-order_types.md) in auction mode: + 1.Limit GTT (0011-SP-MARA-013) + 1.Limit GTC (0011-SP-MARA-014) + 1.Limit GFA (0011-SP-MARA-015) + 1.Pegged GTT (parked in auction \*) (0011-SP-MARA-016) + 1.Pegged GTC (parked in auction \* ) (0011-SP-MARA-017) ## Pseudocode From dc6554a7eb269d8c4a0e3b60f365385c15964723 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 29 Jun 2023 09:46:55 +0100 Subject: [PATCH 195/649] Revert "Add LP mechanics ACs 27-32 - Snapshots, Checkpoints, qualifying order types and others" --- protocol/0044-LIME-lp_mechanics.md | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 0f959b393..c910f4a66 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -300,31 +300,15 @@ Note: - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the bond stake has been slashed to a level lower than the amendment, this slashed level will be retained (i.e. the protocol will not attempt to now increase the commitment) (0044-LIME-020) - If a liquidity provider with an active liquidity provision at the start of an epoch amends the fee level associated to this commitment during the epoch, this change will only take effect at the end of the epoch. (0044-LIME-021) -- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to increase the bond to the new level if they do not have sufficient collateral in the settlement asset of the market to meet new commitment amount then the amendment will be rejected and old commitment amount is retained (0044-LIME-032) -- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will increase the bond to the new level if they have sufficient collateral in the settlement asset of the market to meet new commitment amount (0044-LIME-033) - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-025) +- - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - -- When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - -### Qualifying Order Types - -- Once liquidity is committed LPs can meet their commitment by placing pegged, limit, post only and iceberg (only the visible peak counts towards the commitment) orders (0044-LIME-028) -- Parked pegged and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) - -### Checkpoint - -- Snapshot for the bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-030) - -### Protocol upgrade - -- After a protocol upgrade the bond and fee accounts and their balances are maintained (0044-LIME-031) From deced9f488665a7316e8b61cc859027f2edba2b5 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 09:57:26 +0100 Subject: [PATCH 196/649] feat: add ACs for 013014 --- protocol/0013-ACCT-accounts.md | 14 +++--- protocol/0014-ORDT-order_types.md | 74 ++++++++++++++++--------------- 2 files changed, 47 insertions(+), 41 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index b23031733..cfa64e319 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -97,21 +97,23 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### All ordinary accounts -- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001) -- Only transfer requests move money between accounts. (0013-ACCT-002) +- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001)(0013-SP-ACCT-001) +- Only transfer requests move money between accounts. (0013-ACCT-002)(0013-SP-ACCT-002) ### Party asset accounts -- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003) - - Only one general asset account exists per party per asset. (0013-ACCT-004) - - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005) - - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) +- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003)(0013-SP-ACCT-003) + - Only one general asset account exists per party per asset. (0013-ACCT-004)(0013-SP-ACCT-004) + - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005)(0013-SP-ACCT-005) + - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006)(0013-SP-ACCT-006) - [Fees earned from liquidity provision](./0044-LIME-lp_mechanics.md#fees) are paid in to this account. (0013-ACCT-011) ### Party margin accounts - Every party that submits an order on a market will have a margin account for that market created. (0013-ACCT-007) +- In Spot market, every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) - Each party should only have one margin account per market. (0013-ACCT-008) +- In Spot market, each party should only have one margin account per market. (0013-SP-ACCT-008) - Cannot have a non-zero balance on a margin account where there's no position / position size = 0 and no active orders. (0013-ACCT-009) - Cannot transfer into or out of a margin account where there's no position / position size = 0 and no active orders. (0013-ACCT-010) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 3670cc84a..a6418f378 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -256,74 +256,78 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ## Acceptance Criteria - Immediate orders, continuous trading: - - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) - - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) - - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) - - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) - - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) -- No party can submit a [network order type](#network-orders) (0014-ORDT-006) + - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001)(0014-SP-ORDT-001) + - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002)(0014-SP-ORDT-002) + - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003)(0014-SP-ORDT-003) + - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004)(0014-SP-ORDT-004) + - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005)(0014-SP-ORDT-005) +- No party can submit a [network order type](#network-orders) (0014-ORDT-006)(0014-SP-ORDT-006) - A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's #### Iceberg Order Submission -1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007) -2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008) -3. An iceberg post only order can be submitted (0014-ORDT-009) -4. An iceberg reduce only order is rejected (0014-ORDT-010) +1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007)(0014-ORDT-007) +2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008)(0014-ORDT-008) +3. An iceberg post only order can be submitted (0014-ORDT-009)(0014-ORDT-009) +4. An iceberg reduce only order is rejected (0014-ORDT-010)(0014-ORDT-010) 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) -6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) +In Spot market, for an iceberg order that is submitted with total size x and display size y the holding asset taken should be identical to a regular order of size `x` rather than one of size `y` (0014-SP-ORDT-011) +6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012)(0014-SP-ORDT-012) - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue -7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013) +7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013)(0014-SP-ORDT-013) #### Iceberg Order Batch Submission 1. For multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, margin calculations , order status are all correct (0014-ORDT-014) -2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015) +In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all correct. (0014-SP-ORDT-014) +2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015)(0014-SP-ORDT-015) #### Iceberg Order Submission - Negative tests -1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016) -2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017) -3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018) -4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) -5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) -6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) +1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016)(0014-SP-ORDT-016) +2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017)(0014-SP-ORDT-017) +3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018)(0014-SP-ORDT-018) +4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020)(0014-SP-ORDT-020) +5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021)(0014-SP-ORDT-021) +6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022)(0014-SP-ORDT-022) #### Iceberg Order Amendment -1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023) -2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024) +1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023)(0014-SP-ORDT-023) +2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024)(0014-SP-ORDT-024) 3. Amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost (0014-ORDT-025) +4. In Spot market, amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost. (0014-SP-ORDT-025) #### Iceberg Order Cancellation 1. Cancelling an iceberg order will cancel the order, remove it from the order book , release margin and update order book to reflect the change (0014-ORDT-026) +1. In Spot market, cancelling an iceberg order will cancel the order, remove it from the order book , release holding asset and update order book to reflect the change (0014-SP-ORDT-026) #### Iceberg Order Execution -1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027) -2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) -3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) -4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030) -5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) -6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032) -7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) -8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034) +1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027)(0014-SP-ORDT-027) +2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028)(0014-SP-ORDT-028) +3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029)(0014-SP-ORDT-029) +4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030)(0014-SP-ORDT-030) +5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031)(0014-SP-ORDT-031) +6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032)(0014-SP-ORDT-032) +7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033)(0014-SP-ORDT-033) +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034)( 0014-SP-ORDT-034) 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037)(0014-SP-ORDT-037) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038)(0014-SP-ORDT-038) ### Snapshots -1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035) +1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035)(0014-SP-ORDT-035) ### API -1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) -2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069) -3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070) +1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036)(0014-SP-ORDT-036) +2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069)(0014-SP-ORDT-069) +3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070)(0014-SP-ORDT-070) ### Stop orders From f51fadd4208922a0872fc4bcd3c90481527fe230 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 10:00:47 +0100 Subject: [PATCH 197/649] feat: add holding account section in 013 --- protocol/0013-ACCT-accounts.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index cfa64e319..49083d363 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -111,12 +111,16 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Party margin accounts - Every party that submits an order on a market will have a margin account for that market created. (0013-ACCT-007) -- In Spot market, every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) - Each party should only have one margin account per market. (0013-ACCT-008) - In Spot market, each party should only have one margin account per market. (0013-SP-ACCT-008) - Cannot have a non-zero balance on a margin account where there's no position / position size = 0 and no active orders. (0013-ACCT-009) - Cannot transfer into or out of a margin account where there's no position / position size = 0 and no active orders. (0013-ACCT-010) +### Party holding accounts in Spot market + +- Every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) +- Each party should only have one holding account per market. (0013-SP-ACCT-008) + ### Liquidity Provider bond accounts - A bond account holds collateral to maintain collateral for [Liquidity Providers](./0044-LIME-lp_mechanics.md). (0013-ACCT-023) From 929a9ae9d23cd9180c5ed569776bfc63aa8e5541 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 10:44:24 +0100 Subject: [PATCH 198/649] feat: add ACs for 017032 --- protocol/0017-PART-party.md | 3 ++- protocol/0032-PRIM-price_monitoring.md | 34 +++++++++++++------------- 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/protocol/0017-PART-party.md b/protocol/0017-PART-party.md index a2908e50a..6cbeabb95 100644 --- a/protocol/0017-PART-party.md +++ b/protocol/0017-PART-party.md @@ -36,7 +36,8 @@ The `network` party is a pseudo party. It is used in [position resolution](./001 ## Acceptance Criteria -1. [x] When a [standard party](#standard-party) must be uniquely identified, it must be identified by the public key of an ed25519 keypair (0017-PART-001) +1. [x] When a [standard party](#standard-party) must be uniquely identified, it must be identified by the public key of an ed25519 keypair (0017-PART-001)(0017-SP-PART-001) + Note that when and how a party can submit transactions is set out and restricted in: diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 0bbf71e76..6dfada2d0 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -109,23 +109,23 @@ to the risk model and obtains the range of valid up/down price moves per each of ## Acceptance Criteria -- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001) +- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001)(0032-SP-PRIM-001) - Non-persistent order does not result in an auction (1 out of 2 triggers breached), order gets cancelled (never makes it to the order book) -(0032-PRIM-003) -- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005) -- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006) -- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007) -- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008) -- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009) -- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010) -- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011) -- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012) -- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013) -- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014) -- Specifying a non-positive horizon results in an error. (0032-PRIM-015) -- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016) -- Specifying a non-positive auction extension results in an error. (0032-PRIM-017) +(0032-PRIM-003)(0032-SP-PRIM-003) +- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005)(0032-SP-PRIM-005) +- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006)(0032-SP-PRIM-006) +- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007)(0032-SP-PRIM-007) +- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008)(0032-SP-PRIM-008) +- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009)(0032-SP-PRIM-009) +- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010)(0032-SP-PRIM-010) +- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011)(0032-SP-PRIM-011) +- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012)(0032-SP-PRIM-012) +- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013)(0032-SP-PRIM-013) +- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014)(0032-SP-PRIM-014) +- Specifying a non-positive horizon results in an error. (0032-PRIM-015)(0032-SP-PRIM-015) +- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016)(0032-SP-PRIM-016) +- Specifying a non-positive auction extension results in an error. (0032-PRIM-017)(0032-PRIM-017) - Settlement price outside the current price monitoring bounds does not trigger an auction (0032-PRIM-018) - A network trade (during closeout) with a price outside price monitoring bounds does not trigger an auction. (0032-PRIM-019) -- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020) -- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021) +- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020)(0032-SP-PRIM-020) +- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021)(0032-SP-PRIM-021) From 4c3e9dd99ae7f5608b0dc0a74b19a2b8c01477a8 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 29 Jun 2023 11:40:59 +0100 Subject: [PATCH 199/649] feat: Update stop spec ACs (#1787) * feat: removing incorrect AC and clarifying a spec --- protocol/0014-ORDT-order_types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 3670cc84a..db76c83b4 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -71,6 +71,7 @@ If it has an expiry then it can be set either to cancel on expiry (i.e. it is de An OCO contains TWO stop order submissions, and must include one in each trigger direction. OCOs work exactly like two separate stop orders except that if one of the pair is triggered, cancelled, deleted, or rejected, the other one is automatically cancelled. An OCO submission allows a user to have a stop loss and take profit applied to the same amount of their position without the risk of both trading and reducing their position by more than intended. + - An OCO submission cannot be set to execute at expiry. - The stop order submission wraps a normal order submission. @@ -348,7 +349,6 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu - A stop order set to trade volume `x` with a trigger set to `Rises Above` at a given price will trigger at the first trade at or above that price. At this time the order will be placed on the book if and only if it would reduce the trader's absolute position (buying if they are short or selling if they are long) if executed (i.e. will execute as a reduce-only order). (0014-ORDT-055) - If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056) -- If a pair of stop orders are specified as OCO with the same trigger conditions and directions, if that trigger is hit one will execute and the other will expire. The exact choice of which will execute should not be assumed by the trader. (0014-ORDT-057) - If a pair of stop orders are specified as OCO and one triggers but is invalid at time of triggering (e.g. a buy when the trader is already long) the other will still be cancelled. (0014-ORDT-058) - A trailing stop order for a 5% drop placed when the price is `50`, followed by a price rise to `60` will: From c04ce0aa88effbe84811f7d0d950417f3f644f69 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 12:24:13 +0100 Subject: [PATCH 200/649] feat: add ACS for 020/021 --- protocol/0020-APIS-core_api.md | 28 +++++++++++++------------- protocol/0021-MDAT-market_data_spec.md | 16 +++++++-------- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/protocol/0020-APIS-core_api.md b/protocol/0020-APIS-core_api.md index d129cc0b6..4a8aa169f 100644 --- a/protocol/0020-APIS-core_api.md +++ b/protocol/0020-APIS-core_api.md @@ -62,20 +62,20 @@ On any Vega node, I can: | Requirement | Acceptance Criteria code | |-----------|:------------------------:| -| List all governance proposals via REST & GRPC |0020-APIS-001| -| List all governance proposals by a specified party via REST & GRPC |0020-APIS-002 | -| Retrieve a specific governance proposals by id via REST & GRPC |0020-APIS-003 | -| Retrieve a list of votes via REST & GRPC |0020-APIS-004| -| Retrieve the governance stake for a specified party via REST & GRPC |0020-APIS-005| -| List all markets via REST & GRPC |0020-APIS-006| -| Retrieve a specific market via REST & GRPC | 0020-APIS-007| -| Retrieve all assets via REST & GRPC | 0020-APIS-008| -| List all party IDs via REST & GRPC | 0020-APIS-009| -| List all network parameters & their current values via REST & GRPC | 0020-APIS-010| -| Retrieve the current block height REST & GRPC | 0020-APIS-011| -| Retrieve the current vega time REST & GRPC | 0020-APIS-012| -| Retrieve statistics about the network via REST & GRPC | 0020-APIS-013| -| Submit a valid transaction via REST & GRPC | 0020-APIS-014| +| List all governance proposals via REST & GRPC |0020-APIS-0010020-SP-APIS-001| +| List all governance proposals by a specified party via REST & GRPC |0020-APIS-002 0020-SP-APIS-002| +| Retrieve a specific governance proposals by id via REST & GRPC |0020-APIS-003 0020-SP-APIS-003| +| Retrieve a list of votes via REST & GRPC |0020-APIS-0040020-SP-APIS-004| +| Retrieve the governance stake for a specified party via REST & GRPC |0020-APIS-0050020-SP-APIS-005| +| List all markets via REST & GRPC |0020-APIS-0060020-SP-APIS-006| +| Retrieve a specific market via REST & GRPC | 0020-APIS-0070020-SP-APIS-007| +| Retrieve all assets via REST & GRPC | 0020-APIS-0080020-SP-APIS-008| +| List all party IDs via REST & GRPC | 0020-APIS-0090020-SP-APIS-009| +| List all network parameters & their current values via REST & GRPC | 0020-APIS-0100020-SP-APIS-010| +| Retrieve the current block height REST & GRPC | 0020-APIS-0110020-SP-APIS-011| +| Retrieve the current vega time REST & GRPC | 0020-APIS-0120020-SP-APIS-012| +| Retrieve statistics about the network via REST & GRPC | 0020-APIS-0130020-SP-APIS-013| +| Submit a valid transaction via REST & GRPC | 0020-APIS-0140020-SP-APIS-014| ## See also diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index bcf58bef0..7cff9313a 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -2,18 +2,18 @@ ## Acceptance Criteria -- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001) -- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002) -- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003) -- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004) -- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005) -- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006) -- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007) +- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001)(0021-SP-MDAT-001) +- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002)(0021-SP-MDAT-002) +- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003)(0021-SP-MDAT-003) +- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004)(0021-SP-MDAT-004) +- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005)(0021-SP-MDAT-005) +- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006)(0021-SP-MDAT-006) +- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007)(0021-SP-MDAT-007) - The Open interest returns the sum of the size for all open positions where positions size is greater than 0. (0021-MDAT-008) - The Open interest returns 0 if there are no positions on the market (0021-MDAT-009) - Pegged orders are excluded from the best static price and best static volume calculations. (0021-MDAT-010) - Dynamic orders should be ignored when calculating the static values (0021-MDAT-011) -- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012) +- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012)(0021-SP-MDAT-012) ## Summary From efed15afced3184466a206978fe06a2289959c7a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 13:28:59 +0100 Subject: [PATCH 201/649] feat: add ACs for 022/024 --- protocol/0022-AUTH-auth.md | 26 ++++++++++---------- protocol/0024-OSTA-order_status.md | 38 +++++++++++++++--------------- 2 files changed, 32 insertions(+), 32 deletions(-) diff --git a/protocol/0022-AUTH-auth.md b/protocol/0022-AUTH-auth.md index 6e9228470..0adeeaf8a 100644 --- a/protocol/0022-AUTH-auth.md +++ b/protocol/0022-AUTH-auth.md @@ -124,23 +124,23 @@ messge TransactionBundle { ### Wallet service acceptance criteria -- As a user, I can create a new account on the Wallet service (account creation requirement to be implementation details) (0022-AUTH-001) -- As a user, I can login to the Wallet service with my wallet name and password (0022-AUTH-002) -- As a user, I can logout of the Wallet service with a token given to me at login (0022-AUTH-003) -- As a user, if I'm logged in, I can create a new party (with a key pair) for for my account on the Wallet service. (0022-AUTH-004) -- As a user, if I'm logged in, I can list all my parties (and their key pairs) on the Wallet service (0022-AUTH-005) -- As a user, if I'm logged in, I can create a signature for a blob of data, using one of my parties (and its key pair). (0022-AUTH-007) +- As a user, I can create a new account on the Wallet service (account creation requirement to be implementation details) (0022-AUTH-001)(0022-SP-AUTH-001) +- As a user, I can login to the Wallet service with my wallet name and password (0022-AUTH-002)(0022-SP-AUTH-002) +- As a user, I can logout of the Wallet service with a token given to me at login (0022-AUTH-003)(0022-SP-AUTH-003) +- As a user, if I'm logged in, I can create a new party (with a key pair) for for my account on the Wallet service. (0022-AUTH-004)(0022-SP-AUTH-004) +- As a user, if I'm logged in, I can list all my parties (and their key pairs) on the Wallet service (0022-AUTH-005)(0022-SP-AUTH-005) +- As a user, if I'm logged in, I can create a signature for a blob of data, using one of my parties (and its key pair). (0022-AUTH-007)(0022-SP-AUTH-007) ### Vega network acceptance criteria -- As a user, I can send a transaction to the vega network with a signature for it. (0022-AUTH-008) -- As a vega node, I ensure that all transaction are paired with a signature. (0022-AUTH-009) +- As a user, I can send a transaction to the vega network with a signature for it. (0022-AUTH-008)(0022-SP-AUTH-008) +- As a vega node, I ensure that all transaction are paired with a signature. (0022-AUTH-009)(0022-SP-AUTH-009) - A signature is verified before the transaction is sent to the chain. - - If a signature is valid, the transaction is sent to the chain (0022-AUTH-010) - - If a signature is invalid, the transaction is not sent to the chain, an error is returned (0022-AUTH-011) - - A transaction with an invalid signature is never sent to the chain and the transaction is discarded. (0022-AUTH-013) - - A transaction with no signature is rejected (0022-AUTH-014) -- A `partyId` that is not a valid public key is inherently invalid, and should be rejected (0022-AUTH-015) + - If a signature is valid, the transaction is sent to the chain (0022-AUTH-010)(0022-SP-AUTH-010) + - If a signature is invalid, the transaction is not sent to the chain, an error is returned (0022-AUTH-011)(0022-SP-AUTH-011) + - A transaction with an invalid signature is never sent to the chain and the transaction is discarded. (0022-AUTH-013) (0022-SP-AUTH-013) + - A transaction with no signature is rejected (0022-AUTH-014)(0022-SP-AUTH-014) +- A `partyId` that is not a valid public key is inherently invalid, and should be rejected (0022-AUTH-015)(0022-SP-AUTH-015) - _Note:_ In early versions of Vega, the `partyId` was an arbitrary string. This is no longer valid, and should be rejected. This includes the [network party](./0017-PART-party.md#network-party) - that is used where transactions are generated by the system, and it should never be possible to submit a transaction as `network`. ## Future work diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index cc092cbe1..f02cb1a10 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -43,14 +43,14 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. ## Acceptance Criteria -### Fill or Or Kill (0024-OSTA-001) +### Fill or Or Kill (0024-OSTA-001)(0024-SP-OSTA-001) | Time In Force | Filled | Resulting status | |---------------|--------|------------------| | FOK | No | Stopped | | FOK | Yes | Filled | -### Immediate Or Cancel (0024-OSTA-002) +### Immediate Or Cancel (0024-OSTA-002)(0024-SP-OSTA-002) | Time In Force | Filled | Resulting status | |---------------|---------|------------------| @@ -58,7 +58,7 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. | IOC | Partial | Partially Filled | | IOC | Yes | Filled | -### Good ’Til Cancelled (0024-OSTA-003) +### Good ’Til Cancelled (0024-OSTA-003)(0024-OSP-STA-003) | Time In Force | Filled | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|-------------------|-------------------|------------------| @@ -70,7 +70,7 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. | GTC | Partial | No | Yes | Rejected | | GTC | Yes | No | No | Filled | -### Good ’Til Time (0024-OSTA-004) +### Good ’Til Time (0024-OSTA-004)(0024-SP-OSTA-004) | Time In Force | Filled | Expired | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|---------|-------------------|-------------------|------------------| @@ -89,10 +89,10 @@ Note: The last row in the table above is added for clarity. If the order was fil ### Wash trading Acceptance Criteria -- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-OSTA-005) -- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006) -- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007) -- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008) +- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-SP-OSTA-005)(0024-OSTA-005) +- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006)(0024-SP-OSTA-006) +- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007)(0024-SP-OSTA-007) +- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008)(0024-SP-OSTA-008) ### Impact of order types on settlement @@ -102,20 +102,20 @@ Note: The last row in the table above is added for clarity. If the order was fil - Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` is given if a position is closed out because they do now have enough margin to cover the position (0024-OSTA-010) - Order reason of `ORDER_ERROR_MARGIN_CHECK_FAILED` is given if a new order is placed and the user does not have enough collateral to cover the initial margin requirements (0024-OSTA-011) -- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012) -- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013) -- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014) -- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015) -- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016) -- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017) -- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018) -- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019) -- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020) +- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012)(0024-SP-OSTA-012) +- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013)(0024-SP-OSTA-013) +- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014)(0024-SP-OSTA-014) +- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015)(0024-SP-OSTA-015) +- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016)(0024-SP-OSTA-016) +- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017)(0024-SP-OSTA-017) +- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018)(0024-SP-OSTA-018) +- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019)(0024-SP-OSTA-019) +- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020)(0024-SP-OSTA-020) - Order reason of `ORDER_ERROR_MUST_BE_LIMIT_ORDER` when sending a pegged order that is not a LIMIT order (0024-OSTA-021) - Order reason of `ORDER_ERROR_MUST_BE_GTT_OR_GTC` pegged order must be either GTC or GTT (0024-OSTA-022) - Order reason of `ORDER_ERROR_WITHOUT_REFERENCE_PRICE` pegged order must have a reference field (0024-OSTA-023) - Order reason of `ORDER_ERROR_BUY_CANNOT_REFERENCE_BEST_ASK_PRICE` buy pegged order cannot reference the ask price (0024-OSTA-024) - Order reason of `ORDER_ERROR_OFFSET_MUST_BE_GREATER_THAN_ZERO` pegged order offset must be > 0 when referencing `MID` price (0024-OSTA-025) - Order reason of `ORDER_ERROR_SELL_CANNOT_REFERENCE_BEST_BID_PRICE` sell pegged order cannot reference the bid price (0024-OSTA-026) -- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027) -- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029) +- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027)(0024-SP-OSTA-027) +- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029)(0024-SP-OSTA-029) From f6c5934fe5a8ce31c56260eee09cde87052dade0 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 13:39:23 +0100 Subject: [PATCH 202/649] feat: add ACs for 025/026 --- protocol/0025-OCRE-order_submission.md | 4 +++- protocol/0026-AUCT-auctions.md | 22 +++++++++++----------- 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index 267702b2e..21df45bd0 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -37,10 +37,12 @@ Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an ## Acceptance Criteria -- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001) +- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001)(0025-SP-OCRE-001) - Margin will taken before the order is entered into the book (0025-OCRE-002) - If sufficient margin cannot be reserved, the order will have a status of `REJECTED` (0025-OCRE-003) - Fees are charged as per [0029-FEES](./0029-FEES-fees.md). +- In Spot market, holding will taken before the order is entered into the book(0025-SP-OCRE-002) + - If sufficient holding cannot be reserved, the order will have a status of `REJECTED` (0025-SP-OCRE-003) ## Future Work diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 6e09fcdc8..c3d7af9c0 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -157,24 +157,24 @@ message Market { ## Acceptance Criteria -- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003) -- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) -- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005) -- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006) -- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007) -- As an API user, I can identify: (0026-AUCT-008) +- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003)(0026-SP-AUCT-003) +- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004)(0026-SP-AUCT-004) +- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033)(0068-SP-MATC-033) +- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005)(0026-SP-AUCT-005) +- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006)(0026-SP-AUCT-006) +- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007)(0026-SP-AUCT-007) +- As an API user, I can identify: (0026-AUCT-008)(0026-SP-AUCT-008) - If a market is temporarily in an auction period - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) - 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017)(0026-SP-AUCT-017) + 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018)(0026-SP-AUCT-018) 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have - best bid; it will still open. (0026-AUCT-021) - or best ask; it will still open. (0026-AUCT-022) -- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015) -- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016) +- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015)(0026-SP-AUCT-015) +- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016)(0026-SP-AUCT-016) From 00c92d565caa056f6c5b431e45f322b3bf3069c9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 14:07:56 +0100 Subject: [PATCH 203/649] feat: add ACs for 027/028 --- protocol/0027-ASSP-asset_proposal.md | 50 +++--- protocol/0028-GOVE-governance.md | 217 +++++++++++++-------------- 2 files changed, 133 insertions(+), 134 deletions(-) diff --git a/protocol/0027-ASSP-asset_proposal.md b/protocol/0027-ASSP-asset_proposal.md index 4e22102eb..a430ff035 100644 --- a/protocol/0027-ASSP-asset_proposal.md +++ b/protocol/0027-ASSP-asset_proposal.md @@ -163,40 +163,40 @@ This must be an integer strictly greater than `0`. ### User actions -- As a user I can submit a new proposal asset to be used in vega (0027-ASSP-001) -- As a user I can vote for an asset proposal. (0027-ASSP-002) -- As a user, original submitter of the asset, I can call the node to get a signature of the asset, so I can send it to the asset bridge, and whitelist the asset. (0027-ASSP-003) -- `quantum` is a required parameter (0027-ASSP-004) +- As a user I can submit a new proposal asset to be used in vega (0027-ASSP-001)(0027-SP-ASSP-001) +- As a user I can vote for an asset proposal. (0027-ASSP-002)(0027-SP-ASSP-002) +- As a user, original submitter of the asset, I can call the node to get a signature of the asset, so I can send it to the asset bridge, and whitelist the asset. (0027-ASSP-003)(0027-SP-ASSP-003) +- `quantum` is a required parameter (0027-ASSP-004)(0027-SP-ASSP-004) ### Node actions -- As a node, when a new asset proposal is emitted, I can validate the asset with it's chain, and send the result of the validation through the chain to the other nodes (first phase proposal) (0027-ASSP-005) -- As a node, when a new asset is accepted through governance, I can sign a payload to the user so they can whitelist the asset with the bridge (0027-ASSP-006) -- As a node, I receive events from the external blockchain queue, that confirm the asset is enabled in the bridge. (0027-ASSP-007) -- As a node, when an existing asset is modified through governance changing any one of `maximumLifetimeDeposit` or `withdrawalDelayThreshold`, emit a signed a payload to the world so that they can update the corresponding parameters on the bridge (0027-ASSP-008) +- As a node, when a new asset proposal is emitted, I can validate the asset with it's chain, and send the result of the validation through the chain to the other nodes (first phase proposal) (0027-ASSP-005)(0027-SP-ASSP-005) +- As a node, when a new asset is accepted through governance, I can sign a payload to the user so they can whitelist the asset with the bridge (0027-ASSP-006)(0027-SP-ASSP-006) +- As a node, I receive events from the external blockchain queue, that confirm the asset is enabled in the bridge. (0027-ASSP-007)(0027-SP-ASSP-007) +- As a node, when an existing asset is modified through governance changing any one of `maximumLifetimeDeposit` or `withdrawalDelayThreshold`, emit a signed a payload to the world so that they can update the corresponding parameters on the bridge (0027-ASSP-008)(0027-SP-ASSP-008) ### Validation #### ERC20 Validation -- A valid contract address, which exists in ethereum and is specified in the ERC20 proposal **must** be validated as conforming as an ERC20 asset(0027-ASSP-009) -- An ERC20 proposal **must** provide a name and that name **must** exactly equal the name of the ERC20 token on the target chain (0027-ASSP-010) -- An ERC20 proposal **must** provide a code and that code **must** exactly equal the code of the ERC20 token on the target chain (0027-ASSP-011) -- An ERC20 proposal **must** provide a decimal places property and that property **must** exactly equal the decimal places property of the ERC20 token on the target chain (0027-ASSP-012) -- If the contract name or code do not match, or the contract does not exist, or is not an ERC20 contract, the proposal must be rejected and the rejection reason and error details fields should indicate which rule failed (0027-ASSP-013) -- This validation occurs according to the `validationTimestamp` field in the proposal (0027-ASSP-014) -- A new ERC20 proposal that passes node validation but is does not pass normal governance rules is rejected (0027-ASSP-015) -- A new ERC20 proposal that passes normal governance rules but fails node validation is rejected (0027-ASSP-016) -- `validationTimestamp` must occur after the governance proposal opens voting, and before it closes (0027-ASSP-017) -- `validationTimestamp` must be provided and in the future for all new ERC20 asset proposals (0027-ASSP-018) -- `quantum` must be an integer strictly greater than `0` (0027-ASSP-019) -- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-ASSP-020) +- A valid contract address, which exists in ethereum and is specified in the ERC20 proposal **must** be validated as conforming as an ERC20 asset(0027-ASSP-009)(0027-SP-ASSP-009) +- An ERC20 proposal **must** provide a name and that name **must** exactly equal the name of the ERC20 token on the target chain (0027-ASSP-010)(0027-SP-ASSP-010) +- An ERC20 proposal **must** provide a code and that code **must** exactly equal the code of the ERC20 token on the target chain (0027-ASSP-011)(0027-SP-ASSP-011) +- An ERC20 proposal **must** provide a decimal places property and that property **must** exactly equal the decimal places property of the ERC20 token on the target chain (0027-ASSP-012)(0027-SP-ASSP-012) +- If the contract name or code do not match, or the contract does not exist, or is not an ERC20 contract, the proposal must be rejected and the rejection reason and error details fields should indicate which rule failed (0027-ASSP-013)(0027-SP-ASSP-013) +- This validation occurs according to the `validationTimestamp` field in the proposal (0027-ASSP-014)(0027-SP-ASSP-014) +- A new ERC20 proposal that passes node validation but is does not pass normal governance rules is rejected (0027-ASSP-015)(0027-SP-ASSP-015) +- A new ERC20 proposal that passes normal governance rules but fails node validation is rejected (0027-ASSP-016)(0027-SP-ASSP-016) +- `validationTimestamp` must occur after the governance proposal opens voting, and before it closes (0027-ASSP-017)(0027-SP-ASSP-017) +- `validationTimestamp` must be provided and in the future for all new ERC20 asset proposals (0027-ASSP-018)(0027-SP-ASSP-018) +- `quantum` must be an integer strictly greater than `0` (0027-ASSP-019)(0027-SP-ASSP-019) +- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-ASSP-020)(0027-SP-ASSP-020) - There can be multiple concurrent proposals for the same new ERC20 asset (same means identical Ethereum address). Once the nodes agree (based on events from the external blockchain queue), that the asset is enabled on the bridge all the remaining proposals for the same asset are rejected. -(0027-COSMICELEVATOR-025) -- An invalid contract address, specified in the ERC20 proposal **must** be rejected(0027-ASSP-021) -- An valid contract address which cannot be found in ethereum, specified in the ERC20 proposal **must** be rejected(0027-ASSP-022) +(0027-COSMICELEVATOR-025)(0027-SP-COSMICELEVATOR-025) +- An invalid contract address, specified in the ERC20 proposal **must** be rejected(0027-ASSP-021)(0027-SP-ASSP-021) +- An valid contract address which cannot be found in ethereum, specified in the ERC20 proposal **must** be rejected(0027-ASSP-022)(0027-SP-ASSP-022) ### Delays and Thresholds -- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. Withdrawal in asset `X` below `t1` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t1` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-023) -- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. An asset update proposal is submitted to change these to `t2`; it passes voting and is submitted to Ethereum bridge contract. The new thresholds now apply i.e. withdrawal in asset `X` below `t2` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t2` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-024) +- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. Withdrawal in asset `X` below `t1` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t1` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-023)(0027-SP-ASSP-023) +- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. An asset update proposal is submitted to change these to `t2`; it passes voting and is submitted to Ethereum bridge contract. The new thresholds now apply i.e. withdrawal in asset `X` below `t2` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t2` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-024)(0027-SP-ASSP-024) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 2db190bd7..ca56ed074 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -447,25 +447,25 @@ APIs should also exist for clients to: ## Acceptance Criteria -- As a user, I can create a new proposal, assuming my staking balance matches or exceeds `minProposerBalance` network parameter for my proposal type (0028-GOVE-001) -- As a user, I can list the open proposals on the network (0028-GOVE-002) -- As a user, I can get a list of all proposals I voted for (0028-GOVE-003) -- As a user, I can receive notification when a new proposal is created and may require attention. (0028-GOVE-004) -- As the vega network, all votes from eligible users for an existing proposal are accepted when the proposal is still open (0028-GOVE-005) -- As the vega network, all votes received before the proposal is [active](#lifecycle-of-a-proposal), or once the proposal voting period is finished, are _rejected_ (0028-GOVE-006) -- As the vega network, once the voting period is finished, I validate the result based on the parameters of the proposal used to decide the outcome of it. (0028-GOVE-007) -- As the vega network, proposals that set enactment time before closing time are rejected as invalid (0028-GOVE-009) -- As the vega network, proposals that set closing time beyond the relevant `maxClose` parameter are rejected as invalid (0028-GOVE-010) -- As a user, I can vote for an existing proposal if I have more than the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-014) -- As a user, my vote for an existing proposal is rejected if I have less the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-015) -- As a user, my vote for an existing proposal is rejected if I have less than the relevant `minVoterBalance` governance tokens in my staking account even if I have more than `minVoterBalance` governance tokens in my general or margin accounts (0028-GOVE-016) +- As a user, I can create a new proposal, assuming my staking balance matches or exceeds `minProposerBalance` network parameter for my proposal type (0028-GOVE-001)(0028-SP-GOVE-001) +- As a user, I can list the open proposals on the network (0028-GOVE-002)(0028-SP-GOVE-002) +- As a user, I can get a list of all proposals I voted for (0028-GOVE-003)(0028-SP-GOVE-003) +- As a user, I can receive notification when a new proposal is created and may require attention. (0028-GOVE-004)(0028-SP-GOVE-004) +- As the vega network, all votes from eligible users for an existing proposal are accepted when the proposal is still open (0028-GOVE-005)(0028-SP-GOVE-005) +- As the vega network, all votes received before the proposal is [active](#lifecycle-of-a-proposal), or once the proposal voting period is finished, are _rejected_ (0028-GOVE-006)(0028-SP-GOVE-006) +- As the vega network, once the voting period is finished, I validate the result based on the parameters of the proposal used to decide the outcome of it. (0028-GOVE-007)(0028-SP-GOVE-007) +- As the vega network, proposals that set enactment time before closing time are rejected as invalid (0028-GOVE-009)(0028-SP-GOVE-009) +- As the vega network, proposals that set closing time beyond the relevant `maxClose` parameter are rejected as invalid (0028-GOVE-010)(0028-SP-GOVE-010) +- As a user, I can vote for an existing proposal if I have more than the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-014)(0028-SP-GOVE-014) +- As a user, my vote for an existing proposal is rejected if I have less the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-015)(0028-SP-GOVE-015) +- As a user, my vote for an existing proposal is rejected if I have less than the relevant `minVoterBalance` governance tokens in my staking account even if I have more than `minVoterBalance` governance tokens in my general or margin accounts (0028-GOVE-016)(0028-SP-GOVE-016) - As a user, I can vote multiple times for the same proposal if I have more than the relevant `minVoterBalance` governance tokens in my staking account - - Only my most recent vote is counted (0028-GOVE-017) -- When calculating the participation rate of a proposal, the participation rate of the votes takes into account the total supply of the governance asset. (0028-GOVE-018) -- If a new proposal is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal and can be queried via APIs separately from the general network parameters. (0028-GOVE-036) -- If a new proposal "P" is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal. If an independent network parameter change proposal is enacted changing either required participation of majority then proposal "P" uses its own values for participation and majority; not the newly enacted ones. (0028-GOVE-037) -- All proposals with a title field that is empty, or not between 1 and 100 characters, will be rejected (0028-GOVE-039) -- Reject any proposal that defines a risk parameter outside it's intended boundaries (0028-GOVE-040) + - Only my most recent vote is counted (0028-GOVE-017)(0028-SP-GOVE-017) +- When calculating the participation rate of a proposal, the participation rate of the votes takes into account the total supply of the governance asset. (0028-GOVE-018)(0028-SP-GOVE-018) +- If a new proposal is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal and can be queried via APIs separately from the general network parameters. (0028-GOVE-036)(0028-SP-GOVE-036) +- If a new proposal "P" is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal. If an independent network parameter change proposal is enacted changing either required participation of majority then proposal "P" uses its own values for participation and majority; not the newly enacted ones. (0028-GOVE-037)(0028-SP-GOVE-037) +- All proposals with a title field that is empty, or not between 1 and 100 characters, will be rejected (0028-GOVE-039)(0028-SP-GOVE-039) +- Reject any proposal that defines a risk parameter outside it's intended boundaries (0028-GOVE-040)(0028-GSP-OVE-040) - risk aversion lambda: 1e-8 <= x < 0.1 - tau: 1e-8 <= x <= 1 - mu: -1e-6 <= x <= 1e-6 @@ -476,70 +476,69 @@ APIs should also exist for clients to: #### New Asset proposals -- New asset proposals cannot be created before [`limits.assets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-063) -- An asset proposal with a negative or non-integer value supplied for asset decimal places gets rejected. (0028-GOVE-059) +- New asset proposals cannot be created before [`limits.assets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-063)(0028-SP-GOVE-063) +- An asset proposal with a negative or non-integer value supplied for asset decimal places gets rejected. (0028-GOVE-059)(0028-SP-GOVE-059) #### New Market proposals -- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-008) -- New market proposals cannot be created before [`limits.markets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-024) -- A market that has been proposed and successfully voted through doesn't leave the opening auction until the `enactment date/time` is reached and until sufficient [liquidity commitment](./0038-OLIQ-liquidity_provision_order_type.md) has been made for the market. Sufficient means that it meets all the criteria set in [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md). (0028-GOVE-025) -- A market proposal with a negative or non-integer value supplied for market decimal places gets rejected. (0028-GOVE-061) -- A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062) +- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-008)(0028-SP-GOVE-008) +- New market proposals cannot be created before [`limits.markets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-024)(0028-SP-GOVE-024) +- A market that has been proposed and successfully voted through doesn't leave the opening auction until the `enactment date/time` is reached and until sufficient [liquidity commitment](./0038-OLIQ-liquidity_provision_order_type.md) has been made for the market. Sufficient means that it meets all the criteria set in [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md). (0028-GOVE-025)(0028-SP-GOVE-025) +- A market proposal with a negative or non-integer value supplied for market decimal places gets rejected. (0028-GOVE-061)(0028-SP-GOVE-061) +- A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062)(0028-SP-GOVE-062) #### Market change proposals -- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-033) -- Verify that a market change proposal gets enacted if enough LPs participate and vote for. (0028-GOVE-027) -- Verify that a market change proposal does _not_ get enacted if enough LPs participate and vote for _BUT_ governance tokens holders participate beyond threshold and vote against (majority not reached). (0028-GOVE-032) -- Verify that an enacted market change proposal that doubles the risk model volatility sigma leads to increased margin requirement for all parties. (0028-GOVE-035) -- Verify that an enacted market which uses trading terminated key `ktt1` and settlement price key `ksp1` which is changed via governance proposal to use trading terminated key `ktt2` and settlement price key `ksp2` can terminate trading using `ktt2` but cannot terminate trading using `ktt1` and `ksp2` can submit the settlement price causing market to settle but the key `ksp1` cannot settle the market. (0028-GOVE-012) -- Verify that an enacted market change proposal that changes price monitoring bounds enters a price monitoring auction upon the _new_ bound being breached (0028-GOVE-034) -- Verify that an enacted market change proposal that reduces `market.stake.target.timeWindow` leads to a reduction in target stake if recent open interest is less than historical open interest (0028-GOVE-031) -- Attempts to update immutable market parameter(s) cause the market change proposal to be rejected with an appropriate rejection message (0028-GOVE-058) -- Verify that if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0` and if a party meets the `governance.proposal.updateMarket.minProposerBalance` threshold then said party can submit a market change proposal. (0028-GOVE-060) -- Change of the network parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` will immediately change the minimum proposer ELS for a market change proposal for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-064) -- Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065) -- Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066) -- A market that's attempting to modify any parameters on a market in `proposed` state (i.e. voting hasn't completed) will be rejected. (0028-GOVE-069) -- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) -- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) -- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) -- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108) -- When multiple market closure governance proposals are submitted and accepted then one to be approved by governance last (i.e latest closing date and vote goes through) is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109) -- Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) -- Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) -- Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) -- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-113) -- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) -- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) -- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) -- Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117) -- Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118) - +- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-033)(0028-SP-GOVE-033) +- Verify that a market change proposal gets enacted if enough LPs participate and vote for. (0028-GOVE-027)(0028-SP-GOVE-027) +- Verify that a market change proposal does _not_ get enacted if enough LPs participate and vote for _BUT_ governance tokens holders participate beyond threshold and vote against (majority not reached). (0028-GOVE-032)(0028-SP-GOVE-032) +- Verify that an enacted market change proposal that doubles the risk model volatility sigma leads to increased margin requirement for all parties. (0028-GOVE-035)(0028-SP-GOVE-035) +- Verify that an enacted market which uses trading terminated key `ktt1` and settlement price key `ksp1` which is changed via governance proposal to use trading terminated key `ktt2` and settlement price key `ksp2` can terminate trading using `ktt2` but cannot terminate trading using `ktt1` and `ksp2` can submit the settlement price causing market to settle but the key `ksp1` cannot settle the market. (0028-GOVE-012)(0028-SP-GOVE-012) +- Verify that an enacted market change proposal that changes price monitoring bounds enters a price monitoring auction upon the _new_ bound being breached (0028-GOVE-034)(0028-SP-GOVE-034) +- Verify that an enacted market change proposal that reduces `market.stake.target.timeWindow` leads to a reduction in target stake if recent open interest is less than historical open interest (0028-GOVE-031)(0028-SP-GOVE-031) +- Attempts to update immutable market parameter(s) cause the market change proposal to be rejected with an appropriate rejection message (0028-GOVE-058)(0028-SP-GOVE-058) +- Verify that if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0` and if a party meets the `governance.proposal.updateMarket.minProposerBalance` threshold then said party can submit a market change proposal. (0028-GOVE-060)(0028-SP-GOVE-060) +- Change of the network parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` will immediately change the minimum proposer ELS for a market change proposal for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-064)(0028-SP-GOVE-064) +- Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065)(0028-SP-GOVE-065) +- Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066)(0028-SP-GOVE-066) +- A market that's attempting to modify any parameters on a market in `proposed` state (i.e. voting hasn't completed) will be rejected. (0028-GOVE-069)(0028-SP-GOVE-069) +- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070)(0028-SP-GOVE-070) +- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071)(0028-SP-GOVE-071) +- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072)(0028-SP-GOVE-072) +- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108)(0028-SP-GOVE-108) +- When multiple market closure governance proposals are submitted and accepted then one to be approved by governance last (i.e latest closing date and vote goes through) is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109)(0028-SP-GOVE-109) +- Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110)(0028-SP-GOVE-110) +- Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111)(0028-SP-GOVE-111) +- Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112)(0028-SP-GOVE-112) +- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-113)(0028-SP-GOVE-113) +- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114)(0028-SP-GOVE-114) +- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115)(0028-SP-GOVE-115) +- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116)(0028-SP-GOVE-116) +- Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117)(0028-SP-GOVE-117) +- Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118)(0028-SP-GOVE-118) #### Network parameter change proposals -- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-026) -- Network parameter change proposals can only propose a change to a single parameter (0028-GOVE-013) +- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-026)(0028-SP-GOVE-026) +- Network parameter change proposals can only propose a change to a single parameter (0028-GOVE-013)(0028-GOVE-013) Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeForm`. -- Change of the network parameter `governance.proposal.*.minEnact` will immediately change the minimum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-051) -- Change of the network parameter `governance.proposal.*.maxEnact` will immediately change the maximum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-052) -- Change of the network parameter `governance.proposal.*.maxClose` will immediately change the maximum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-053) -- Change of the network parameter `governance.proposal.*.minClose` will immediately change the minimum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-054) -- Change of the network parameter `governance.proposal.*.requiredMajority` or `governance.proposal.*.requiredParticipation` will immediately change the majority (or participation) required for the proposal to pass for all proposals submitted in the future. Proposals that have already been submitted are not affected as they have their own copy of this value. (0028-GOVE-055) -- Change of the network parameter `governance.proposal.*.minVoterBalance` will immediately change the minimum governance token balance required to vote on any proposal submitted in the future. Proposals that have already been submitted are unaffected as they have their own copy of this parameter. (0028-GOVE-056) -- Change of the network parameter `governance.proposal.*.minProposerBalance` will immediately change minimum governance token balance required to submit any future proposal. Proposals that have already been submitted are unaffected . (0028-GOVE-057) +- Change of the network parameter `governance.proposal.*.minEnact` will immediately change the minimum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-051)(0028-SP-GOVE-051) +- Change of the network parameter `governance.proposal.*.maxEnact` will immediately change the maximum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-052)(0028-SP-GOVE-052) +- Change of the network parameter `governance.proposal.*.maxClose` will immediately change the maximum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-053)(0028-SP-GOVE-053) +- Change of the network parameter `governance.proposal.*.minClose` will immediately change the minimum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-054)(0028-SP-GOVE-054) +- Change of the network parameter `governance.proposal.*.requiredMajority` or `governance.proposal.*.requiredParticipation` will immediately change the majority (or participation) required for the proposal to pass for all proposals submitted in the future. Proposals that have already been submitted are not affected as they have their own copy of this value. (0028-GOVE-055)(0028-SP-GOVE-055) +- Change of the network parameter `governance.proposal.*.minVoterBalance` will immediately change the minimum governance token balance required to vote on any proposal submitted in the future. Proposals that have already been submitted are unaffected as they have their own copy of this parameter. (0028-GOVE-056)(0028-SP-GOVE-056) +- Change of the network parameter `governance.proposal.*.minProposerBalance` will immediately change minimum governance token balance required to submit any future proposal. Proposals that have already been submitted are unaffected . (0028-GOVE-057)(0028-SP-GOVE-057) #### Freeform governance proposals -- A freeform governance proposal with a description field that is empty, or not between 1 and 10,000 characters, will be rejected (0028-GOVE-019) -- A freeform governance proposal does not have an enactment period set, and after it closes no action is taken on the system (0028-GOVE-022) -- Closed freeform governance proposals can be retrieved from the API along with details of how token holders voted. (0028-GOVE-023) +- A freeform governance proposal with a description field that is empty, or not between 1 and 10,000 characters, will be rejected (0028-GOVE-019)(0028-SP-GOVE-019) +- A freeform governance proposal does not have an enactment period set, and after it closes no action is taken on the system (0028-GOVE-022)(0028-SP-GOVE-022) +- Closed freeform governance proposals can be retrieved from the API along with details of how token holders voted. (0028-GOVE-023)(0028-SP-GOVE-023) #### Concurrent governance proposals -- Approved governance proposals sharing the same enactment time should be enacted in the order the proposals were created. (0028-GOVE-067) -- Approved governance proposals sharing the same enactment time and changing the same parameter should all be applied, the oldest proposal will be applied first and the newest will be applied last, overwriting the changes made by the older proposals. (0028-GOVE-068) +- Approved governance proposals sharing the same enactment time should be enacted in the order the proposals were created. (0028-GOVE-067)(0028-SP-GOVE-067) +- Approved governance proposals sharing the same enactment time and changing the same parameter should all be applied, the oldest proposal will be applied first and the newest will be applied last, overwriting the changes made by the older proposals. (0028-GOVE-068)(0028-SP-GOVE-068) #### Governance Transfer proposals @@ -547,86 +546,86 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Proposer Requirements -- The transfer proposer must have at a staking balance which matches or exceeds `minProposerBalance` network parameter for this proposal type (0028-GOVE-073) +- The transfer proposer must have at a staking balance which matches or exceeds `minProposerBalance` network parameter for this proposal type (0028-GOVE-073)(0028-SP-GOVE-073) ##### APIs -- Governance transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074) +- Governance transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074)(0028-SP-GOVE-074) ##### Transfer proposal submission validation -- A proposal to transfer tokens between Network treasury and Party general account(s) is valid (0028-GOVE-128) -- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119) -- A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120) -- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121) -- A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122) -- Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) -- Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) -- Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080) -- For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081) -- Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082) -- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083) -- Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084) -- Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085) -- Destination Type can be any of the predefined types in the above table (0028-GOVE-086) -- Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087) -- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088) -- Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089) -- Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090) -- For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091) -- The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092) -- For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) +- A proposal to transfer tokens between Network treasury and Party general account(s) is valid (0028-GOVE-128)(0028-SP-GOVE-128) +- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119)(0028-SP-GOVE-119) +- A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120)(0028-SP-GOVE-120) +- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121)(0028-SP-GOVE-121) +- A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122)(0028-SP-GOVE-122) +- Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077)(0028-SP-GOVE-077) +- Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079)(0028-SP-GOVE-079) +- Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080)(0028-SP-GOVE-080) +- For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081)(0028-SP-GOVE-081) +- Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082)(0028-SP-GOVE-082) +- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083)(0028-SP-GOVE-083)) +- Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084)(0028-SP-GOVE-084) +- Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085)(0028-SP-GOVE-085) +- Destination Type can be any of the predefined types in the above table (0028-GOVE-086)(0028-SP-GOVE-086) +- Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087)(0028-SP-GOVE-087) +- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088)(0028SP--GOVE-088) +- Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089)(0028-SP-GOVE-089) +- Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090)(0028-SP-GOVE-090) +- For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091)(0028-SP-GOVE-091) +- The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092)(0028-SP-GOVE-092) +- For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093)(0028-SP-GOVE-093) ##### Governance transfer enactment -- For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094) -- A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095) -- Transfers can occur for terminated markets (0028-GOVE-096) -- Transfers cannot occur for settled markets and a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-097) -- Transfers cannot occur for pending markets unless they become active on or before the enactment time of the transfer (0028-GOVE-098) +- For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094)(0028-SP-GOVE-094) +- A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095)(0028-SP-GOVE-095) +- Transfers can occur for terminated markets (0028-GOVE-096) (0028-SP-GOVE-096) +- Transfers cannot occur for settled markets and a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-097)(0028-SP-GOVE-097) +- Transfers cannot occur for pending markets unless they become active on or before the enactment time of the transfer (0028-GOVE-098)(0028-SP-GOVE-098) ##### Transferred Amount -- If the type of transfer is “All or nothing” then the minimum of either `fraction_of_balance * source_balance` and the transfer amount is transfers between accounts. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-099) -- If the type of transfer is “Best effort” then the transfer amount is derived from the minimum of `proposal.fraction_of_balance * source.balance, proposal.amount, NETWORK_MAX_AMOUNT, NETWORK_MAX_FRACTION * source.balance`. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-100) +- If the type of transfer is “All or nothing” then the minimum of either `fraction_of_balance * source_balance` and the transfer amount is transfers between accounts. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-099)(0028-SP-GOVE-099) +- If the type of transfer is “Best effort” then the transfer amount is derived from the minimum of `proposal.fraction_of_balance * source.balance, proposal.amount, NETWORK_MAX_AMOUNT, NETWORK_MAX_FRACTION * source.balance`. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-100)(0028-SP-GOVE-100) ##### Transfer Fees -- No fees are incurred by the transfer and therefore the the number of tokens deducted from the source account should always equal the tokens added to the destination account (0028-GOVE-101) +- No fees are incurred by the transfer and therefore the the number of tokens deducted from the source account should always equal the tokens added to the destination account (0028-GOVE-101)(0028-SP-GOVE-101) ##### Protocol Upgrade -- Transfer proposals in either a pre or post enactment state are not restored after a protocol upgrade (0028-GOVE-102) +- Transfer proposals in either a pre or post enactment state are not restored after a protocol upgrade (0028-GOVE-102)(0028-SP-GOVE-102) #### Checkpoints and Snapshots -- Active governance transfer (one-off or recurring) must be included in checkpoint and snapshot (0028-GOVE-103) +- Active governance transfer (one-off or recurring) must be included in checkpoint and snapshot (0028-GOVE-103)(0028-SP-GOVE-103) ##### Recurring Governance transfers -- For a recurring proposal, the proposal is only active from defined start epoch and optional end epoch, the transfer will be executed every epoch while the proposal is active. (0028-GOVE-104) +- For a recurring proposal, the proposal is only active from defined start epoch and optional end epoch, the transfer will be executed every epoch while the proposal is active. (0028-GOVE-104)(0028-SP-GOVE-104) -- Enacted and active recurring governance transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105) +- Enacted and active recurring governance transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105)(0028-SP-GOVE-105) -- When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106) +- When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106)(0028-SP-GOVE-106) ##### Cancelling governance transfers -- Only recurring governance transfers can be cancelled by proposing a governance transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) -- After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123) -- Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) -- Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) -- When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126) +- Only recurring governance transfers can be cancelled by proposing a governance transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107)(0028-SP-GOVE-107) +- After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123)(0028-SP-GOVE-123) +- Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124)(0028-SP-GOVE-124) +- Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125)(0028-GSP-OVE-125) +- When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126)(0028-SP-GOVE-126) ##### Network History -- A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127) +- A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127)(0028-SP-GOVE-127) From ab5c14c80a125e766888296a9cc58fcbb2a6762a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 14:31:26 +0100 Subject: [PATCH 204/649] feat: add ACs for 029/080 --- protocol/0029-FEES-fees.md | 24 ++++++++++++++-------- protocol/0080-SPOT-product_builtin_spot.md | 20 +++++++++--------- 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 64bef4130..bbf58ff98 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -93,17 +93,23 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria -- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) +- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001)(0029-SP-FEES-001) - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) +- In Spot market, fees are debited from the general (+ holding if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-SP-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) +- In Spot market, fees are debited from the general (+ holding if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-SP-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) -- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) +- In Spot market, fees are debited from the general (+ holding if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-SP-FEES-004) +- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005)(0029-SP-FEES-005)(0029-SP-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) +- In Spot market, during auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ holding if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-SP-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) -- During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if :-) the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) -- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009) -- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010) -- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011) -- The three component fee rates (fee_factor[infrastructure, fee_factor[maker], fee_factor[liquidity] are available via an API such as the market data API or market framework. (0029-FEES-012) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014) +- In Spot market, during continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ holdingif needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) +- During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the holding account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) +- In Spot market, during auctions, if either of the two sides has insufficient balance in their general (+ holding if needed) account, the trade still goes ahead only if the holding account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) +- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009)(0029-SP-FEES-009) +- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010)(0029-SP-FEES-010) +- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011)(0029-SP-FEES-011) +- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012)(0029-SP-FEES-012) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013)(0029-SP-FEES-013) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014)(0029-SP-FEES-014) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 31beee024..1431cdaa5 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -85,33 +85,33 @@ Both buy and sell orders on a `Spot` market define a size (amount of the `base_a ### Sell Orders -For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid. +For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid.(0080-SP-FEES-001) -If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. +If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SP-FEES-002) -If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`. +If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SP-FEES-003) ### Buy Orders -As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered. +As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SP-FEES-004) #### Continuous Trading -For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor). +For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SP-FEES-005) -If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. +If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SP-FEES-006). As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SP-FEES-007). If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SP-FEES-008) #### Entering an Auction -When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled. +When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SP-AUC-001). If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SP-AUC-002). -For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction. +For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SP-AUC-003). -If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`. +If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SP-FEES-009). #### Exiting an Auction -When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order. +When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SP-AUC-004). ## 8. Auctions From c5e226653a2ca76f00e907f36d62323ed9841a20 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 29 Jun 2023 12:32:39 +0200 Subject: [PATCH 205/649] refactor: clarify spec --- protocol/0028-GOVE-governance.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index a7e5a542f..85765b2fa 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -362,7 +362,7 @@ All in memory active governance transfers must be included in the snapshot of th ## 6. Change market state A governance proposal to change the state of the market. -Multiple concurrent proposals are allowed. If more than one gets successfully voted in the one which arrived last gets used. If a proposal has already been successful then additional market state change proposals are still allowed as long as their enactment date is no later then that of the last successful vote. +Multiple concurrent proposals are allowed. Market change proposal [creation](#market-change-proposal) and [voting](#market-change-proposal-outcome) rules apply. @@ -374,10 +374,9 @@ Any type of market (either fixed expiry market or perpetual) can be closed via a A proposal to close a market contains: -1. an enactment time 1. final settlement price (not required for spot markets) -Once market is closed the process cannot be reversed. +Once market is closed the process cannot be reversed. Note that this implies that once a governance proposal to close the market has been voted in the market will definitely close at the enactment time of that vote at the latest. While the market is still open it's still possible to submit additional governance votes to close the market, however they'll only have any effect if their enactment date is prior to that of the market closure proposal which has already passed. ### 6.2. Suspend the market @@ -385,11 +384,14 @@ This proposal puts the market into an auction mode which can only be exit with a A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. +If the market is already suspended via governance when another vote gets enacted then that vote has no effect. ### 6.3. Unsuspend the market This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. +If the market is not suspended when the vote to unsuspend the market gets enacted then that vote has no effect. + ## 7. Freeform governance proposal The aim of this is to allow community to provide votes on proposals which don't change any of the behaviour of the currently running Vega blockchain. That is to say, at enactment time, no changes are effected on the system, but the record of how token holders voted will be stored on chain. The proposal will contain only the fields common to all proposals i.e. From d044216244e368b0f27af9051755dcb7ab2ace91 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 15:16:49 +0100 Subject: [PATCH 206/649] feat: add ACs for 030 --- protocol/0029-FEES-fees.md | 6 -- protocol/0030-ETHM-multisig_control_spec.md | 110 ++++++++++---------- 2 files changed, 55 insertions(+), 61 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index bbf58ff98..b08ba833c 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -95,18 +95,12 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001)(0029-SP-FEES-001) - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) -- In Spot market, fees are debited from the general (+ holding if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-SP-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) -- In Spot market, fees are debited from the general (+ holding if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-SP-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) -- In Spot market, fees are debited from the general (+ holding if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-SP-FEES-004) - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005)(0029-SP-FEES-005)(0029-SP-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) -- In Spot market, during auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ holding if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-SP-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) -- In Spot market, during continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ holdingif needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) - During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the holding account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) -- In Spot market, during auctions, if either of the two sides has insufficient balance in their general (+ holding if needed) account, the trade still goes ahead only if the holding account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) - Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009)(0029-SP-FEES-009) - A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010)(0029-SP-FEES-010) - Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011)(0029-SP-FEES-011) diff --git a/protocol/0030-ETHM-multisig_control_spec.md b/protocol/0030-ETHM-multisig_control_spec.md index 605ffa799..5769b9218 100644 --- a/protocol/0030-ETHM-multisig_control_spec.md +++ b/protocol/0030-ETHM-multisig_control_spec.md @@ -110,79 +110,79 @@ contract MultisigControl { ### MultisigControl Smart Contract - Set Threshold - - A valid signature bundle, threshold (in tenths of %), and unused nonce can be passed to `set_threshold` function to set the approval threshold in hundredths of a percent (`TODO: check this mechanism/math`) (0030-ETHM-002) - - A successful call to `set_threshold` emits `ThresholdSet` event (0030-ETHM-003) - -Subsequent calls to `get_current_threshold()` returns updated threshold value (0030-ETHM-004) - - An invalid signature passed to `set_threshold` function is rejected (0030-ETHM-005) - - A threshold passed to `set_threshold` outside of sane range is rejected (0030-ETHM-006) - - A nonce passed to `set_threshold` that has already been used is rejected (0030-ETHM-007) + - A valid signature bundle, threshold (in tenths of %), and unused nonce can be passed to `set_threshold` function to set the approval threshold in hundredths of a percent (`TODO: check this mechanism/math`) (0030-ETHM-002)(0030-SP-ETHM-002) + - A successful call to `set_threshold` emits `ThresholdSet` event (0030-ETHM-003)(0030-SP-ETHM-003) + -Subsequent calls to `get_current_threshold()` returns updated threshold value (0030-ETHM-004)(0030-SP-ETHM-004) + - An invalid signature passed to `set_threshold` function is rejected (0030-ETHM-005)(0030-SP-ETHM-005) + - A threshold passed to `set_threshold` outside of sane range is rejected (0030-ETHM-006)(0030-SP-ETHM-006) + - A nonce passed to `set_threshold` that has already been used is rejected (0030-ETHM-007)(0030-SP-ETHM-007) - Add Signer - - A valid signature bundle, non-signer ethereum address, and unused nonce can be passed to `add_signer` function to add an Ethereum address of a new signer to the list of approved signers (0030-ETHM-008) - - A successful call to `add_signer` increments signer count (0030-ETHM-009) - - A successful call to `add_signer` emits `SignerAdded` event (0030-ETHM-010) - - Subsequent calls to `is_valid_signer()` with added Ethereum address returns true until that signer is removed (0030-ETHM-011) - - An invalid signature bundle, currently approved signer address, or used nonce passed to `add_signer` is rejected (0030-ETHM-012) + - A valid signature bundle, non-signer ethereum address, and unused nonce can be passed to `add_signer` function to add an Ethereum address of a new signer to the list of approved signers (0030-ETHM-008)(0030-SP-ETHM-008) + - A successful call to `add_signer` increments signer count (0030-ETHM-009)(0030SP-ETHM-009) + - A successful call to `add_signer` emits `SignerAdded` event (0030-ETHM-010)(0030-SP-ETHM-010) + - Subsequent calls to `is_valid_signer()` with added Ethereum address returns true until that signer is removed (0030-ETHM-011)(0030-SP-ETHM-011) + - An invalid signature bundle, currently approved signer address, or used nonce passed to `add_signer` is rejected (0030-ETHM-012)(0030-SP-ETHM-012) - Remove Signer - - A valid signature bundle, current signer Ethereum address, and unused nonce can be passed to `remove_signer` to remove a currently valid signer from the list of signers (0030-ETHM-013) - - A successful call to `remove_signer` decrements signer count (0030-ETHM-014) - - A successful call to `remove_signer` emits `SignerRemoved` event (0030-ETHM-015) - - Subsequent calls to `is_valid_signer()` with removed Ethereum address returns false unless that signer is re-added (0030-ETHM-016) - - An invalid signature bundle, non current signer Ethereum address, or used nonce passed to `remove_signer` is rejected (0030-ETHM-017) + - A valid signature bundle, current signer Ethereum address, and unused nonce can be passed to `remove_signer` to remove a currently valid signer from the list of signers (0030-ETHM-013)(0030-SP-ETHM-013) + - A successful call to `remove_signer` decrements signer count (0030-ETHM-014)(0030-SP-ETHM-014) + - A successful call to `remove_signer` emits `SignerRemoved` event (0030-ETHM-015)(0030-SP-ETHM-015) + - Subsequent calls to `is_valid_signer()` with removed Ethereum address returns false unless that signer is re-added (0030-ETHM-016)(0030-SP-ETHM-016) + - An invalid signature bundle, non current signer Ethereum address, or used nonce passed to `remove_signer` is rejected (0030-ETHM-017)(0030-SP-ETHM-017) - Getters - - `get_valid_signer_count()` returns current count of valid signers (0030-ETHM-018) - - `get_current_threshold()` returns current threshold (0030-ETHM-019) - - `is_valid_signer()` returns true is signer is valid (0030-ETHM-020) - - `is_nonce_used()` returns true if nonce has been used to successfully sign something previously (0030-ETHM-021) + - `get_valid_signer_count()` returns current count of valid signers (0030-ETHM-018)(0030-SP-ETHM-018) + - `get_current_threshold()` returns current threshold (0030-ETHM-019)(0030-SP-ETHM-019) + - `is_valid_signer()` returns true is signer is valid (0030-ETHM-020)(0030-SP-ETHM-020) + - `is_nonce_used()` returns true if nonce has been used to successfully sign something previously (0030-ETHM-021)(0030-SP-ETHM-021) ### MultisigControl Consuming Smart Contract -- Consuming smart contract calls `verify_signatures` with valid signature bundle and message hash is returned true if the valid signature count is over threshold % of total signers (0030-ETHM-023) +- Consuming smart contract calls `verify_signatures` with valid signature bundle and message hash is returned true if the valid signature count is over threshold % of total signers (0030-ETHM-023)(0030-SP-ETHM-023) ### Multisig Control to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on MultisigControl and their corresponding acceptance criteria. 1. `mapping(address => bool) public signers;` - - must show "True" for each signer that is currently valid (0030-ETHM-024) - - must show "False" for non-signers (0030-ETHM-025) - - must show "False" for removed signers (0030-ETHM-026) + - must show "True" for each signer that is currently valid (0030-ETHM-024)(0030-SP-ETHM-024) + - must show "False" for non-signers (0030-ETHM-025)(0030-SP-ETHM-025) + - must show "False" for removed signers (0030-ETHM-026)(0030-SP-ETHM-026) 1. `function set_threshold(uint16 new_threshold,uint256 nonce,bytes calldata signatures)` - - must set the vote threshold if parameters and signatures valid (0030-ETHM-027) - - must fail if bad signatures (0030-ETHM-028) - - must fail if threshold zero (0030-ETHM-029) - - must fail if threshold > 1000 (0030-ETHM-030) + - must set the vote threshold if parameters and signatures valid (0030-ETHM-027)(0030-SP-ETHM-027) + - must fail if bad signatures (0030-ETHM-028)(0030-SP-ETHM-028) + - must fail if threshold zero (0030-ETHM-029)(0030-SP-ETHM-029) + - must fail if threshold > 1000 (0030-ETHM-030)(0030-SP-ETHM-030) 1. `function add_signer(address new_signer,uint256 nonce,bytes calldata signatures)` - - must add signer if parameters and signatures valid (0030-ETHM-031) - - must fail if bad signatures (0030-ETHM-032) - - must fail if already signer (0030-ETHM-033) + - must add signer if parameters and signatures valid (0030-ETHM-031)(0030-SP-ETHM-031) + - must fail if bad signatures (0030-ETHM-032)(0030-SP-ETHM-032) + - must fail if already signer (0030-ETHM-033)(0030-SP-ETHM-033) 1. `function remove_signer(address old_signer,uint256 nonce,bytes calldata signatures)` - - must remove signer if parameters and signatures valid (0030-ETHM-034) - - must fail if bad signatures (0030-ETHM-035) - - must fail if not valid signer (0030-ETHM-036) + - must remove signer if parameters and signatures valid (0030-ETHM-034)(0030-SP-ETHM-034) + - must fail if bad signatures (0030-ETHM-035)(0030-SP-ETHM-035) + - must fail if not valid signer (0030-ETHM-036)(0030-SP-ETHM-036) 1. `function burn_nonce(uint256 nonce, bytes calldata signatures)` - - must stop specific nonce from being used despite valid signatures (0030-ETHM-037) - - must fail if bad signatures (0030-ETHM-038) - - must fail if already redeemed (0030-ETHM-039) - - must fail if already burned (0030-ETHM-040) + - must stop specific nonce from being used despite valid signatures (0030-ETHM-037)(0030-SP-ETHM-037) + - must fail if bad signatures (0030-ETHM-038)(0030-SP-ETHM-038) + - must fail if already redeemed (0030-ETHM-039)(0030-SP-ETHM-039) + - must fail if already burned (0030-ETHM-040)(0030-SP-ETHM-040) 1. `function verify_signatures(bytes calldata signatures,bytes memory message,uint256 nonce)` - - must verify if signatures match message and nonce AND pass current threshold with currently valid signers (0030-ETHM-041) - - must burn nonce to prevent replay attack (0030-ETHM-042) - - must fail if bad signatures (0030-ETHM-043) - - must fail if nonce already used (0030-ETHM-044) + - must verify if signatures match message and nonce AND pass current threshold with currently valid signers (0030-ETHM-041)(0030-SP-ETHM-041) + - must burn nonce to prevent replay attack (0030-ETHM-042)(0030-SP-ETHM-042) + - must fail if bad signatures (0030-ETHM-043)(0030-SP-ETHM-043) + - must fail if nonce already used (0030-ETHM-044)(0030-SP-ETHM-044) 1. `function get_valid_signer_count() external view override returns (uint8)` - - must return current valid signer count (0030-ETHM-045) - - must change to reflect adding of a signer (0030-ETHM-046) - - must change to reflect removing of a signer (0030-ETHM-047) + - must return current valid signer count (0030-ETHM-045)(0030-SP-ETHM-045) + - must change to reflect adding of a signer (0030-ETHM-046)(0030-SP-ETHM-046) + - must change to reflect removing of a signer (0030-ETHM-047)(0030-SP-ETHM-047) 1. `function get_current_threshold() external view override returns (uint16)` - - must return current threshold (0030-ETHM-048) - - must change to reflect a change of threshold (0030-ETHM-049) + - must return current threshold (0030-ETHM-048)(0030-SP-ETHM-048) + - must change to reflect a change of threshold (0030-ETHM-049)(0030-SP-ETHM-049) 1. `function is_valid_signer(address signer_address) external view override returns (bool)` - - must return true if valid signer (0030-ETHM-050) - - must return false for non signer (0030-ETHM-051) - - must return false for removed (0030-ETHM-052) - - must change to reflect a removed signer (0030-ETHM-053) - - must change to reflect added signer (0030-ETHM-054) + - must return true if valid signer (0030-ETHM-050)(0030-SP-ETHM-050) + - must return false for non signer (0030-ETHM-051)(0030-SP-ETHM-051) + - must return false for removed (0030-ETHM-052)(0030-SP-ETHM-052) + - must change to reflect a removed signer (0030-ETHM-053)(0030-SP-ETHM-053) + - must change to reflect added signer (0030-ETHM-054)(0030-SP-ETHM-054) 1. `function is_nonce_used(uint256 nonce) external view override returns (bool)` - - must return true if nonce has been used for normal transaction (0030-ETHM-055) - - must return true if nonce burned (0030-ETHM-056) - - must return false if not seen before OR if signatures failed to go over threshold (0030-ETHM-057) + - must return true if nonce has been used for normal transaction (0030-ETHM-055)(0030-SP-ETHM-055) + - must return true if nonce burned (0030-ETHM-056)(0030-SP-ETHM-056) + - must return false if not seen before OR if signatures failed to go over threshold (0030-ETHM-057)(0030-SP-ETHM-057) From 64ec4d5ba2c9329879bc3e2846dc41e5cf3cd0c7 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 15:41:12 +0100 Subject: [PATCH 207/649] feat: add ACs for 0031/32/34/36/39/40 --- protocol/0031-ETHB-ethereum_bridge_spec.md | 144 +++++++++--------- protocol/0033-OCAN-cancel_orders.md | 18 +-- ...PROB-prob_weighted_liquidity_measure.ipynb | 18 ++- protocol/0036-BRIE-event_queue.md | 6 +- .../0039-MKTD-market_depth_calculation.md | 28 ++-- protocol/0040-ASSF-asset_framework.md | 16 +- 6 files changed, 120 insertions(+), 110 deletions(-) diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 7a88be6cf..3453d2257 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -139,123 +139,123 @@ This example connects the network to Ropsten: - ERC-20 smart contract (This can be repeated for many token standards - NFTs and crypto items will be more complex): - An Ethereum Address can call the deposit function and successfully deposit any token that is listed via `list_asset` (0031-ETHB-008) - - A deposit call with a removed token `remove_asset` is rejected (0031-COSMICELEVATOR-009) + - A deposit call with a removed token `remove_asset` is rejected (0031-COSMICELEVATOR-009)(0031-SP-COSMICELEVATOR-009) ### Withdraw - ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the withdraw function to successfully withdraw an ERC-20 asset (0031-ETHB-013) - - An invalid multisig bundle will be rejected from withdraw (0031-ETHB-014) + - A valid multisig bundle can be passed to the withdraw function to successfully withdraw an ERC-20 asset (0031-ETHB-013)(0031-SP-ETHB-013) + - An invalid multisig bundle will be rejected from withdraw (0031-ETHB-013)(0031-SP-ETHB-013) ### Allowlist a token (by eth address) - ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the `list_asset` function to successfully add a token to the allowed list (0031-ETHB-016) - - An invalid multisig bundle is rejected by the `list_asset` function (0031-ETHB-017) + - A valid multisig bundle can be passed to the `list_asset` function to successfully add a token to the allowed list (0031-ETHB-016)(0031-SP-ETHB-016) + - An invalid multisig bundle is rejected by the `list_asset` function (0031-ETHB-017)(0031-SP-ETHB-017) ### Blocklist a token (by eth address) - ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the `remove_asset` function to successfully remove a previously allow listed token (0031-COSMICELEVATOR-019) - - An invalid multisig bundle is rejected by the `remove_asset` function (0031-COSMICELEVATOR-020) + - A valid multisig bundle can be passed to the `remove_asset` function to successfully remove a previously allow listed token (0031-COSMICELEVATOR-019)(0031-SP-COSMICELEVATOR-019) + - An invalid multisig bundle is rejected by the `remove_asset` function (0031-COSMICELEVATOR-020)(0031-SP-COSMICELEVATOR-020) ### ERC20 Bridge Logic to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on `ERC20_Bridge_Logic` and their corresponding acceptance criteria. 1. `address payable public erc20_asset_pool_address;` - - must match the deployed asset pool address (0031-ETHB-018) + - must match the deployed asset pool address (0031-ETHB-018)(0031-SP-ETHB-018) 1. `function list_asset(address asset_source,bytes32 vega_asset_id,uint256 lifetime_limit,uint256 withdraw_threshold,uint256 nonce,bytes memory signatures)` - - must list asset (0031-ETHB-019) - - must not list already-listed asset (0031-ETHB-020) - - must not list if bad signatures (0031-ETHB-021) - - must not list if already listed (0031-ETHB-022) + - must list asset (0031-ETHB-019)(0031-SP-ETHB-019) + - must not list already-listed asset (0031-ETHB-020)(0031-SP-ETHB-020) + - must not list if bad signatures (0031-ETHB-021)(0031-SP-ETHB-021) + - must not list if already listed (0031-ETHB-022)(0031-SP-ETHB-022) 1. `function remove_asset(address asset_source,uint256 nonce,bytes memory signatures)` - - must remove asset (0031-ETHB-023) - - must fail if asset not listed (0031-ETHB-024) - - must fail if bad signatures (0031-ETHB-025) + - must remove asset (0031-ETHB-023)(0031-SP-ETHB-023) + - must fail if asset not listed (0031-ETHB-024)(0031-SP-ETHB-024) + - must fail if bad signatures (0031-ETHB-025)(0031-SP-ETHB-025) 1. `uint256 public default_withdraw_delay = 432000;` - - must show 432000 (0031-ETHB-026) + - must show 432000 (0031-ETHB-026)(0031-SP-ETHB-026) 1. `bool public is_stopped;` - - must be false at first (0031-ETHB-027) - - must be true after `global_stop` called (0031-ETHB-028) + - must be false at first (0031-ETHB-027)(0031-SP-ETHB-027) + - must be true after `global_stop` called (0031-ETHB-028)(0031-SP-ETHB-028) 1. `function set_asset_limits(address asset_source,uint256 lifetime_limit,uint256 threshold,uint256 nonce,bytes calldata signatures)` - - changes asset limits (0031-ETHB-029) - - must fail if bad signatures (0031-ETHB-030) - - asset must be listed (0031-ETHB-031) + - changes asset limits (0031-ETHB-029)(0031-SP-ETHB-029) + - must fail if bad signatures (0031-ETHB-030)(0031-SP-ETHB-030) + - asset must be listed (0031-ETHB-031)(0031-SP-ETHB-031) 1. `function get_asset_deposit_lifetime_limit(address asset_source)` - - must return asset lifetime limit (0031-ETHB-032) + - must return asset lifetime limit (0031-ETHB-032)(0031-ETHB-032) 1. `function get_withdraw_threshold(address asset_source)` - - must return withdraw threshold (0031-ETHB-033) + - must return withdraw threshold (0031-ETHB-033)(0031-SP-ETHB-033) 1. `function set_withdraw_delay(uint256 delay,uint256 nonce,bytes calldata signatures)` - - must set withdraw delay (0031-ETHB-034) - - must fail if bad signatures (0031-ETHB-036) + - must set withdraw delay (0031-ETHB-034)(0031-SP-ETHB-034) + - must fail if bad signatures (0031-ETHB-036)(0031-SP-ETHB-036) 1. `function global_stop(uint256 nonce, bytes calldata signatures)` - - must set `is_stopped` to `true` (0031-ETHB-037) - - must stop deposits (0031-ETHB-038) - - must stop withdrawals (0031-ETHB-039) - - must not be stopped already (0031-ETHB-040) - - must fail on bad signatures (0031-ETHB-041) + - must set `is_stopped` to `true` (0031-ETHB-037)(0031-SP-ETHB-037) + - must stop deposits (0031-ETHB-038)(0031-SP-ETHB-038) + - must stop withdrawals (0031-ETHB-039)(0031-SP-ETHB-039) + - must not be stopped already (0031-ETHB-040)(0031-SP-ETHB-040) + - must fail on bad signatures (0031-ETHB-041)(0031-SP-ETHB-041) 1. `function global_resume(uint256 nonce, bytes calldata signatures)` - - must set `is_stopped` to `false` (0031-ETHB-042) - - must resume deposits (0031-ETHB-043) - - must resume withdrawals (0031-ETHB-044) - - must already be stopped (0031-ETHB-045) - - must fail on bad signatures (0031-ETHB-046) + - must set `is_stopped` to `false` (0031-ETHB-042)(0031-SP-ETHB-042) + - must resume deposits (0031-ETHB-043)(0031-SP-ETHB-043) + - must resume withdrawals (0031-ETHB-044)(0031-SP-ETHB-044) + - must already be stopped (0031-ETHB-045)(0031-SP-ETHB-045) + - must fail on bad signatures (0031-ETHB-046)(0031-SP-ETHB-046) 1. `function exempt_depositor()` - - must exempt caller from lifetime deposits (0031-ETHB-047) - - must not be already exempt (0031-ETHB-048) + - must exempt caller from lifetime deposits (0031-ETHB-047)(0031-SP-ETHB-047) + - must not be already exempt (0031-ETHB-048)(0031-SP-ETHB-048) 1. `function revoke_exempt_depositor()` - - must revoke lifetime deposit exemption (0031-ETHB-049) - - must already be exempt (0031-ETHB-050) + - must revoke lifetime deposit exemption (0031-ETHB-049)(0031-SP-ETHB-049) + - must already be exempt (0031-ETHB-050)(0031-SP-ETHB-050) 1. `function is_exempt_depositor(address depositor) external view override returns (bool)` - - must show lifetime deposit exemption (0031-ETHB-051) + - must show lifetime deposit exemption (0031-ETHB-051)(0031-SP-ETHB-051) 1. `function withdraw_asset(address asset_source,uint256 amount,address target,uint256 creation,uint256 nonce,bytes memory signatures)` - - must withdraw asset specified (0031-ETHB-052) - - must fail on bad signatures (0031-ETHB-053) - - must fail on non-matching parameters (0031-ETHB-054) - - must fail on expired withdrawal order (0031-ETHB-082) - - must fail on delay not yet elapsed (0031-ETHB-083) + - must withdraw asset specified (0031-ETHB-052)(0031-SP-ETHB-052) + - must fail on bad signatures (0031-ETHB-053)(0031-SP-ETHB-053) + - must fail on non-matching parameters (0031-ETHB-054)(0031-SP-ETHB-054) + - must fail on expired withdrawal order (0031-ETHB-082)(0031-SP-ETHB-082) + - must fail on delay not yet elapsed (0031-ETHB-083)(0031-SP-ETHB-083) 1. `function deposit_asset(address asset_source,uint256 amount,bytes32 vega_public_key)` - - must deposit asset from user (0031-ETHB-055) - - must be listed (0031-ETHB-056) - - must be exempt or below lifetime deposit limit (0031-ETHB-057) - - must fail if over lifetime limit and not exempt (0031-ETHB-058) - - must be credited on Vega (0031-ETHB-059) + - must deposit asset from user (0031-ETHB-055)(0031-SP-ETHB-055) + - must be listed (0031-ETHB-056)(0031-SP-ETHB-056) + - must be exempt or below lifetime deposit limit (0031-ETHB-057)(0031-SP-ETHB-057) + - must fail if over lifetime limit and not exempt (0031-ETHB-058)(0031-SP-ETHB-058) + - must be credited on Vega (0031-ETHB-059)(0031-SP-ETHB-059) 1. `function is_asset_listed(address asset_source) external view override returns (bool)` - - must be true if asset is listed (0031-ETHB-060) - - must be false if asset is not listed (0031-ETHB-061) - - when true, deposits must work (0031-ETHB-062) - - when false deposits must not work (0031-ETHB-063) + - must be true if asset is listed (0031-ETHB-060)(0031-SP-ETHB-060) + - must be false if asset is not listed (0031-ETHB-061)(0031-SP-ETHB-061) + - when true, deposits must work (0031-ETHB-062)(0031-SP-ETHB-062) + - when false deposits must not work (0031-ETHB-063)(0031-SP-ETHB-063) 1. `function get_multisig_control_address() external view override returns (address)` - - must show deployed multisig address (0031-ETHB-064) + - must show deployed multisig address (0031-ETHB-064)(0031-SP-ETHB-064) 1. `function get_vega_asset_id(address asset_source) external view override returns (bytes32)` - - must return proper Vega asset ID (0031-ETHB-065) + - must return proper Vega asset ID (0031-ETHB-065)(0031-SP-ETHB-065) 1. `function get_asset_source(bytes32 vega_asset_id) external view override returns (address)` - - must return the deployed asset address from Vega asset ID (0031-ETHB-066) + - must return the deployed asset address from Vega asset ID (0031-ETHB-066)(0031-SP-ETHB-066) ### ERC-20 Asset Pool to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on ERC20_Asset_Pool and their corresponding acceptance criteria. 1. `address public multisig_control_address;` - - must show the current multisig control address (0031-ETHB-067) - - must change to reflect a successful set_multisig_control call (0031-ETHB-068) + - must show the current multisig control address (0031-ETHB-067)(0031-SP-ETHB-067) + - must change to reflect a successful set_multisig_control call (0031-ETHB-068)(0031-ESP-THB-068) 1. `address public erc20_bridge_address;` - - must show current deployed `erc20_bridge` address (0031-ETHB-069) - - must change to reflect a successful set_bridge_address call (0031-ETHB-070) + - must show current deployed `erc20_bridge` address (0031-ETHB-069)(0031-SP-ETHB-069) + - must change to reflect a successful set_bridge_address call (0031-ETHB-070)(0031-SP-ETHB-070) 1. `receive() external payable // fallback, should fail` 1. `function set_multisig_control(address new_address,uint256 nonce,bytes memory signatures)` - - must set multisig control (0031-ETHB-071) - - must be reflected in `multisig_control_address` (0031-ETHB-072) - - must fail on bad signatures (0031-ETHB-073) + - must set multisig control (0031-ETHB-071)(0031-SP-ETHB-071) + - must be reflected in `multisig_control_address` (0031-ETHB-072)(0031-SP-ETHB-072) + - must fail on bad signatures (0031-ETHB-073)(0031-SP-ETHB-073) 1. `function set_bridge_address(address new_address,uint256 nonce,bytes memory signatures)` - - must set bridge address (0031-ETHB-074) - - must be reflected in `erc20_bridge_address` (0031-ETHB-075) - - must fail on bad signatures (0031-ETHB-076) + - must set bridge address (0031-ETHB-074)(0031-SP-ETHB-074) + - must be reflected in `erc20_bridge_address` (0031-ETHB-075)(0031-SP-ETHB-075) + - must fail on bad signatures (0031-ETHB-076)(0031-SP-ETHB-076) 1. `function withdraw(address token_address,address target,uint256 amount)` - - must remit the `amount` of `token_address` to the `target` address (0031-ETHB-077) - - must be runnable from the current `erc20_bridge_address` address (0031-ETHB-078) - - must fail if ran by any other address (0031-ETHB-079) - - must work for new bridge after bridge address changed (0031-ETHB-080) - - must fail for old bridge after bridge address changed (0031-ETHB-081) + - must remit the `amount` of `token_address` to the `target` address (0031-ETHB-077)(0031-SP-ETHB-077) + - must be runnable from the current `erc20_bridge_address` address (0031-ETHB-078)(0031-SP-ETHB-078) + - must fail if ran by any other address (0031-ETHB-079)(0031-ETHB-079) + - must work for new bridge after bridge address changed (0031-ETHB-080)(0031-SP-ETHB-080) + - must fail for old bridge after bridge address changed (0031-ETHB-081)(0031-SP-ETHB-081) diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index 1a8670988..dfbd0746e 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -2,15 +2,15 @@ ## Acceptance Criteria -- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001) -- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002) -- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003) -- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004) -- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005) -- Margins must be recalculated after a cancel event (0033-OCAN-007) -- An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008) -- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009) -- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010) +- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001)(0033-SP-OCAN-001) +- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002)(0033-SP-OCAN-002) +- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003)(0033-SP-OCAN-003) +- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004)(0033-SP-OCAN-004) +- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005)(0033-SP-OCAN-005) +- Margins must be recalculated after a cancel event (0033-OCAN-007)(0033-SP-OCAN-007) +- An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008)(0033-SP-OCAN-008) +- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009)(0033-SP-OCAN-009) +- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010)(0033-SP-OCAN-010) ## Summary diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index ff4ce6c2f..b0060e382 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -1,6 +1,7 @@ { "cells": [ { + "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -29,6 +30,7 @@ ] }, { + "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -78,6 +80,7 @@ ] }, { + "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -85,25 +88,32 @@ "\n", "Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) The feature test has covered following scenarios:\n", "\n", - "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001);\n", + "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001)(0034-SP-PROB-001);\n", "\n", - "2. Probability of trading decreases away from the mid-price (0034-PROB-005).\n", + "2. Probability of trading decreases away from the mid-price (0034-PROB-005)(0034-SP-PROB-005).\n", "\n", - "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006).\n", + "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006)(0034-SP-PROB-006).\n", "\n", "\n", "\n" ] }, { + "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [] } ], "metadata": { + "kernelspec": { + "display_name": "Python 3", + "language": "python", + "name": "python3" + }, "language_info": { - "name": "python" + "name": "python", + "version": "3.8.15" }, "orig_nbformat": 4 }, diff --git a/protocol/0036-BRIE-event_queue.md b/protocol/0036-BRIE-event_queue.md index ca9c25670..b9b828911 100644 --- a/protocol/0036-BRIE-event_queue.md +++ b/protocol/0036-BRIE-event_queue.md @@ -164,17 +164,17 @@ message NodeVote { ## Acceptance Criteria -- A valid event is processed by vega (0036-BRIE-001) +- A valid event is processed by vega (0036-BRIE-001)(0036-SP-BBRIE-001) - A transaction is successfully executed on the bridge (e.g deposit) - A validator node successfully source the event and emit a chain event transaction on the vega chain - The others validators successfully validates the event on the ethereum chain and send a node vote on chain - The required amount of node votes, weighted by validator score is received - The processing of the event have effect on the network (e.g: for a deposit funds are deposited on an account) -- A valid duplicated event is processed (0036-BRIE-002) +- A valid duplicated event is processed (0036-BRIE-002)(0036-SP-BBRIE-002) - A transaction is successfully executed on the bridge (e.g deposit) and successfully processed by vega - A node sends again the chain event after sourcing it - The nodes reject this event as duplicated, nothing else happens -- A invalid event is processed (0036-BRIE-003) +- A invalid event is processed (0036-BRIE-003)(0036-SP-BBRIE-003) - A malicious node sends a chain event for a non existing transaction on the bridge - The node start validating this event on chain, but cannot find it - After a given delay this chain event is rejected, no node votes are being sent by the validators diff --git a/protocol/0039-MKTD-market_depth_calculation.md b/protocol/0039-MKTD-market_depth_calculation.md index 08b55ae43..9dcfceb58 100644 --- a/protocol/0039-MKTD-market_depth_calculation.md +++ b/protocol/0039-MKTD-market_depth_calculation.md @@ -2,21 +2,21 @@ ## Acceptance Criteria -- The market depth builder must be able to handle all available order types (0039-MKTD-001) -- Entering and leaving auctions must be handled correctly (0039-MKTD-003) -- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004) -- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005) -- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006) -- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007) -- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008) -- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009) -- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010) -- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012) -- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013) -- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014) +- The market depth builder must be able to handle all available order types (0039-MKTD-001)(0039-SP-MKTD-001) +- Entering and leaving auctions must be handled correctly (0039-MKTD-003)(0039-SP-MKTD-003) +- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004)(0039-SP-MKTD-004) +- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005)(0039-SP-MKTD-005) +- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006)(0039-SP-MKTD-006) +- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007)(0039-SP-MKTD-007) +- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008)(0039-SP-MKTD-008) +- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009)(0039-SP-MKTD-009) +- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010)(0039-SP-MKTD-010) +- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012)(0039-SP-MKTD-012) +- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013)(0039-SP-MKTD-013) +- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014)(0039-SP-MKTD-014) - Pegged orders are part of the market depth view and should update the view when their orders are repriced (0039-MKTD-015) -- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018) -- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019) +- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018)(0039-SP-MKTD-018) +- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019)(0039-SP-MKTD-019) ## Summary diff --git a/protocol/0040-ASSF-asset_framework.md b/protocol/0040-ASSF-asset_framework.md index ed2a82d75..4bcefdd5f 100644 --- a/protocol/0040-ASSF-asset_framework.md +++ b/protocol/0040-ASSF-asset_framework.md @@ -293,11 +293,11 @@ Once a withdrawal is complete and the appropriate events/transaction information For each asset class to be considered "supported" by Vega, the following must happen: -1. An asset of that class can Be voted into Vega (0040-ASSF-001) -2. An asset previously voted in can be voted out of Vega (0040-COSMICELEVATOR-002) -3. A voted-in asset can be deposited into a Vega bridge (0040-ASSF-003) -4. A properly deposited asset is credited to the appropriate user (0040-ASSF-004) -5. A withdrawal can be requested and verified by Vega validator nodes (0040-ASSF-005) -6. multisig withdrawal order signatures from Vega validator nodes can be aggregated at the request of the user (0040-ASSF-006) -7. A user can submit the withdrawal order and receive their asset (0040-ASSF-007) -8. Every asset must specify `quantum` and this must be an integer strictly greater than `0` (0040-ASSF-008) +1. An asset of that class can Be voted into Vega (0040-ASSF-001)(0040-SP-ASSF-001) +2. An asset previously voted in can be voted out of Vega (0040-COSMICELEVATOR-002)(0040-SP-COSMICELEVATOR-002) +3. A voted-in asset can be deposited into a Vega bridge (0040-ASSF-003)(0040-SP-ASSF-003) +4. A properly deposited asset is credited to the appropriate user (0040-ASSF-004)(0040-SP-ASSF-004) +5. A withdrawal can be requested and verified by Vega validator nodes (0040-ASSF-005)(0040-SP-ASSF-005) +6. multisig withdrawal order signatures from Vega validator nodes can be aggregated at the request of the user (0040-ASSF-006)(0040-SP-ASSF-006) +7. A user can submit the withdrawal order and receive their asset (0040-ASSF-007)(0040-SP-ASSF-007) +8. Every asset must specify `quantum` and this must be an integer strictly greater than `0` (0040-ASSF-008)(0040-SP-ASSF-008) From a7353bfc441e86b1c59056d09443093d8dded311 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 15:50:46 +0100 Subject: [PATCH 208/649] feat: add ACs for 0043/0045 --- protocol/0043-MKTL-market_lifecycle.md | 8 ++--- protocol/0045-DSRC-data_sourcing.md | 50 +++++++++++++------------- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index cd946bb62..97f16241d 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -243,7 +243,7 @@ After `market.liquidity.successorLaunchWindowLength` has elapsed since the settl ## Acceptance Criteria -### Market is proposed but rejected (0043-MKTL-001) +### Market is proposed but rejected (0043-MKTL-001)(0043-SP-MKTL-001) 1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. @@ -253,7 +253,7 @@ It is not possible to submit orders to the market. No parties have margin account balances that are non-zero for the market. Market state is `rejected`. -### Lifecycle happy path (0043-MKTL-002) +### Lifecycle happy path (0043-MKTL-002)(0043-SP-MKTL-002) 1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. @@ -286,7 +286,7 @@ The market state is `settled`. After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. -### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003) +### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003)(0043-SP-MKTL-003) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). 1. Trading terminated data source rings before the market leaves the opening auction (so market never left Pending state so far). @@ -296,7 +296,7 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. -### Market gets closed via a governance proposal (0043-MKTL-004) +### Market gets closed via a governance proposal (0043-MKTL-004)(0043-SP-MKTL-004) 1. Once the governance proposal to close the market gets enacted any auction that the market may be in gets uncrossed and trades get generated. 1. All the other orders are cancelled and no further trades get generated. diff --git a/protocol/0045-DSRC-data_sourcing.md b/protocol/0045-DSRC-data_sourcing.md index 3b6573ea1..a99407f9d 100644 --- a/protocol/0045-DSRC-data_sourcing.md +++ b/protocol/0045-DSRC-data_sourcing.md @@ -225,28 +225,28 @@ ethereumCall: { Vega should reject any data source tx that is not explicitly required, so this would include a tx: -1. If a data source combines a primary source (like a signed message) with a filter (for instance saying we are only interested in messages where ticker = `GBPUSD` and timestamp = `20211231T23:59:00`) then the complete data source definition defines the source and can be used to accept/reject transactions, so for an active data source is active, transactions from the same provider (pubkey, Ethereum contract/event, URL, etc.) do not form part of the defined data source. If submitted, they should be rejected where possible and must not supply data to the target for the data source if the metadata or data content itself is not selected by the source definition (e.g. because ticker and timestamp do not match a filter). (0045-DSRC-001) -1. When no reference to a data source remains in any active part of the system (for instance a non-cancelled/settled market), data source no longer needs to be tracked and can be discarded. Any transactions that would previously have matched and been selected by that data source would be rejected/ignored. (0045-DSRC-002) -1. If the same complete data source (provider and filters, etc.) is referenced in multiple places (e.g. two separate active markets) then it will remain active if any subset of those references remain active. For example 2 markets reference the same data source (full definition must match exactly) and one of those markets is closed/cancelled/settled before the other, either because some other difference in their definition or because of governance action. (0045-DSRC-003) -1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and at least one of those sources filters out a transaction but at least one other selects it (all filters match), the transaction data must still be supplied for the sources that match and must not be supplied for the sources that don't match. (0045-DSRC-004) -1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and all of the sources select it (all filters match), the transaction data must be supplied for ALL of the sources that match. (0045-DSRC-005) -1. If a data source reference is changed (e.g. via governance vote), the old source must be dropped and data/transactions matching that source must not reach the target. (0045-DSRC-006) -1. If a data source reference is changed (e.g. via governance vote), the new source must become active and data/transactions matching that source must reach the target. (0045-DSRC-007) -1. Changes in data source references (e.g. via governance vote) must allow changing between any valid data source definitions, including to a data source of a different type of data source. (0045-DSRC-008) -1. Data is not applied retrospectively, i.e. if a previous historic data point or data transaction would have matched a newly created data source, it must not be identified and applied to the new data source (and therefore need not be stored by the core), only active data and new events created after the activation of the data source would be considered for the source. (0045-DSRC-009) -1. Two data sources with the same definition that are active at the same time must always select and receive exactly the same data, in the same order. (0045-DSRC-010) -1. Rejection of data sources either before submission/sequencing as transactions or when/if data is filtered/rejected after being sequenced on chain (if this happens - it should be avoided wherever possible to prevent spam attacks and reduce network load) must either result in an event queue message, return an error to the client, or enable the rejection (or not) to be confirmed by querying a core API (e.g. the filter, selector, or type check that failed). (0045-DSRC-011) -1. It's possible to query an API and see all active data sources. (0045-DSRC-012) -1. Party submitting an oracle transaction that gets rejected (e.g. because no data source is listening for transactions from such key) can receive an error message detailing reason for rejection. (0045-DSRC-013) -1. It's possible to listen to events and see all data that is supplied across all data sources or for any specific source. (0045-DSRC-014) -1. Data node carries historic data of at least all valid data that was supplied for each data source. (0045-DSRC-015) -1. Data sources can be composed/nested arbitrarily (as long as the definition is valid), for example selecting a field on filtered data that itself was sourced by selecting a field on a message sent by a signed data source (for example this might be processing a complex object in the source data. (0045-COSMICELEVATOR-016) -1. A market proposal specifies data source where value used for settlement is integer with implied decimals; the implied decimals are included in the oracle spec; once trading terminated and settlement data is submitted the price is interpreted correctly for settlement purposes. E.g. market decimals `1`, market uses asset for settlement with `10` decimals, oracle implied decimals `5`, submitted value `10156789` interpreted as `101.56789`. In asset decimals this is `1015678900000` and this is used for settlement. (0045-DSRC-017) -1. Data source transactions can be submitted by a party with zero balance in all assets. (0045-DSRC-018) -1. After trading termination has been triggered the trading terminated data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-019) -1. After settlement data has been received and the market has settled, the settlement data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-020) -1. Where the same oracle definition is used for trading terminated and settlement, and data has been received. Trading is terminated and the market is settled with the same data event (a single message does both). The data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed. (0045-DSRC-021) -1. It should be possible to update the market termination spec from external to internal and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-022) -1. It should be possible to update the market termination spec from internal to external and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-023) -1. It should not be possible to update the market settlement data spec to change the type from an external data source to an internal Vega timestamp data source. NB: this is because the internal Vega timestamp data source does not emit a value that can be used as a price, only a date/time. (0045-DSRC-024) -1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025) +1. If a data source combines a primary source (like a signed message) with a filter (for instance saying we are only interested in messages where ticker = `GBPUSD` and timestamp = `20211231T23:59:00`) then the complete data source definition defines the source and can be used to accept/reject transactions, so for an active data source is active, transactions from the same provider (pubkey, Ethereum contract/event, URL, etc.) do not form part of the defined data source. If submitted, they should be rejected where possible and must not supply data to the target for the data source if the metadata or data content itself is not selected by the source definition (e.g. because ticker and timestamp do not match a filter). (0045-DSRC-001)(0045-SP-DSRC-001) +1. When no reference to a data source remains in any active part of the system (for instance a non-cancelled/settled market), data source no longer needs to be tracked and can be discarded. Any transactions that would previously have matched and been selected by that data source would be rejected/ignored. (0045-DSRC-002)(0045-SP-DSRC-002) +1. If the same complete data source (provider and filters, etc.) is referenced in multiple places (e.g. two separate active markets) then it will remain active if any subset of those references remain active. For example 2 markets reference the same data source (full definition must match exactly) and one of those markets is closed/cancelled/settled before the other, either because some other difference in their definition or because of governance action. (0045-DSRC-003)(0045-SP-DSRC-003) +1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and at least one of those sources filters out a transaction but at least one other selects it (all filters match), the transaction data must still be supplied for the sources that match and must not be supplied for the sources that don't match. (0045-DSRC-004)(0045-SP-DSRC-004) +1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and all of the sources select it (all filters match), the transaction data must be supplied for ALL of the sources that match. (0045-DSRC-005)(0045-SP-DSRC-005) +1. If a data source reference is changed (e.g. via governance vote), the old source must be dropped and data/transactions matching that source must not reach the target. (0045-DSRC-006)(0045-SP-DSRC-006) +1. If a data source reference is changed (e.g. via governance vote), the new source must become active and data/transactions matching that source must reach the target. (0045-DSRC-007)(0045-SP-DSRC-007) +1. Changes in data source references (e.g. via governance vote) must allow changing between any valid data source definitions, including to a data source of a different type of data source. (0045-DSRC-008)(0045-SP-DSRC-008) +1. Data is not applied retrospectively, i.e. if a previous historic data point or data transaction would have matched a newly created data source, it must not be identified and applied to the new data source (and therefore need not be stored by the core), only active data and new events created after the activation of the data source would be considered for the source. (0045-DSRC-009)(0045-SP-DSRC-009) +1. Two data sources with the same definition that are active at the same time must always select and receive exactly the same data, in the same order. (0045-DSRC-010)(0045-SP-DSRC-010) +1. Rejection of data sources either before submission/sequencing as transactions or when/if data is filtered/rejected after being sequenced on chain (if this happens - it should be avoided wherever possible to prevent spam attacks and reduce network load) must either result in an event queue message, return an error to the client, or enable the rejection (or not) to be confirmed by querying a core API (e.g. the filter, selector, or type check that failed). (0045-DSRC-011)(0045-SP-DSRC-011) +1. It's possible to query an API and see all active data sources. (0045-DSRC-012)(0045-SP-DSRC-012) +1. Party submitting an oracle transaction that gets rejected (e.g. because no data source is listening for transactions from such key) can receive an error message detailing reason for rejection. (0045-DSRC-013)(0045-SP-DSRC-013) +1. It's possible to listen to events and see all data that is supplied across all data sources or for any specific source. (0045-DSRC-014)(0045-SP-DSRC-014) +1. Data node carries historic data of at least all valid data that was supplied for each data source. (0045-DSRC-015)(0045-SP-DSRC-015) +1. Data sources can be composed/nested arbitrarily (as long as the definition is valid), for example selecting a field on filtered data that itself was sourced by selecting a field on a message sent by a signed data source (for example this might be processing a complex object in the source data). (0045-COSMICELEVATOR-016)(0045-SP-COSMICELEVATOR-016) +1. A market proposal specifies data source where value used for settlement is integer with implied decimals; the implied decimals are included in the oracle spec; once trading terminated and settlement data is submitted the price is interpreted correctly for settlement purposes. E.g. market decimals `1`, market uses asset for settlement with `10` decimals, oracle implied decimals `5`, submitted value `10156789` interpreted as `101.56789`. In asset decimals this is `1015678900000` and this is used for settlement. (0045-DSRC-017)(0045-SP-DSRC-017) +1. Data source transactions can be submitted by a party with zero balance in all assets. (0045-DSRC-018)(0045-SP-DSRC-018) +1. After trading termination has been triggered the trading terminated data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-019)(0045-SP-DSRC-019) +1. After settlement data has been received and the market has settled, the settlement data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-020)(0045-SP-DSRC-020) +1. Where the same oracle definition is used for trading terminated and settlement, and data has been received. Trading is terminated and the market is settled with the same data event (a single message does both). The data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed. (0045-DSRC-021)(0045-SP-DSRC-021) +1. It should be possible to update the market termination spec from external to internal and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-022)(0045-SP-DSRC-022) +1. It should be possible to update the market termination spec from internal to external and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-023)(0045-SP-DSRC-023) +1. It should not be possible to update the market settlement data spec to change the type from an external data source to an internal Vega timestamp data source. NB: this is because the internal Vega timestamp data source does not emit a value that can be used as a price, only a date/time. (0045-DSRC-024)(0045-SP-DSRC-024) +1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025)(0045-SP-DSRC-025) From 3f05d58fc1cbde8ffbbf36b263ccc549b43f997a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 16:09:32 +0100 Subject: [PATCH 209/649] feat: add ACs for 0046/47/48/49/50/51 --- .../0046-DSRM-data_source_signed_message.md | 34 ++++++------- protocol/0047-DSRF-data_source_filter.md | 50 +++++++++---------- protocol/0048-DSRI-data_source_internal.md | 28 +++++------ ...-TVAL-validate_transaction_preconsensus.md | 12 ++--- protocol/0050-EPOC-epochs.md | 14 +++--- protocol/0051-PROD-product.md | 6 +-- 6 files changed, 72 insertions(+), 72 deletions(-) diff --git a/protocol/0046-DSRM-data_source_signed_message.md b/protocol/0046-DSRM-data_source_signed_message.md index 5d8d2af87..a5b9cba4d 100644 --- a/protocol/0046-DSRM-data_source_signed_message.md +++ b/protocol/0046-DSRM-data_source_signed_message.md @@ -90,38 +90,38 @@ Where possible, this should be done before the transaction is included in a bloc An [instrument can be created](./0028-GOVE-governance.md) to rely on a signed message data source: -- The instrument must specify a valid signed message data source (0046-DSRM-001) -- A market proposal specifying an invalid data source will be rejected (0046-DSRM-002) - - This rejection will happen at _the [creation of the proposal](./0028-GOVE-governance.md)_ (0046-DSRM-003) +- The instrument must specify a valid signed message data source (0046-DSRM-001)(0046-SP-DSRM-001) +- A market proposal specifying an invalid data source will be rejected (0046-DSRM-002)(0046-SP-DSRM-002) + - This rejection will happen at _the [creation of the proposal](./0028-GOVE-governance.md)_ (0046-DSRM-003)(0046-SP-DSRM-003) Multiple instruments can rely on the same data source: -- Multiple instruments can settle based on the same `SubmitData` message. (0046-DSRM-004) -- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different `SubmitData` messages. (0046-DSRM-005) -- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different fields from the same `SubmitData` message. (0046-DSRM-006) +- Multiple instruments can settle based on the same `SubmitData` message. (0046-DSRM-004)(0046-SP-DSRM-004) +- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different `SubmitData` messages. (0046-DSRM-005)(0046-SP-DSRM-005) +- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different fields from the same `SubmitData` message. (0046-DSRM-006)(0046-SP-DSRM-006) `SubmitData` transactions can be submitted by any public key as long as the data included in the transaction is signed by at least one of the keys included in an active signed message data source definition: -- `SubmitData` transactions for active ([see data sourcing framework](./0045-DSRC-data_sourcing.md)) data sources will be accepted regardless of the transaction signer. (0046-DSRM-007) -- `SubmitData` transactions by inactive data sources will be rejected. (0046-DSRM-008) -- `SubmitData` transactions that are invalid will be rejected. (0046-DSRM-009) +- `SubmitData` transactions for active ([see data sourcing framework](./0045-DSRC-data_sourcing.md)) data sources will be accepted regardless of the transaction signer. (0046-DSRM-007)(0046-SP-DSRM-007) +- `SubmitData` transactions by inactive data sources will be rejected. (0046-DSRM-008)(0046-SP-DSRM-008) +- `SubmitData` transactions that are invalid will be rejected. (0046-DSRM-009)(0046-SP-DSRM-009) To be valid, a `SubmitData` transaction must: -- Contain correctly signed data from an active signed message data source, (0046-DSRM-010) -- Invalid `SubmitData` transactions must be rejected. (0046-DSRM-011) +- Contain correctly signed data from an active signed message data source, (0046-DSRM-010)(0046-SP-DSRM-010) +- Invalid `SubmitData` transactions must be rejected. (0046-DSRM-011)(0046-SP-DSRM-011) Ignore any data source tx that is not explicitly required, so this would include a tx: -- For a pubkey never used in a data source (0046-DSRM-013) -- For a data source where a filter ignores the message based on its contents (0046-DSRM-014) -- For a pubkey only used in data sources referenced by markets (or other things) that are no longer being managed by the core (i.e. once a marked is in Closed or Settled or Cancelled state according to the market framework) or before the enactment date of the market proposal (0046-DSRM-015) +- For a pubkey never used in a data source (0046-DSRM-013)(0046-SP-DSRM-013) +- For a data source where a filter ignores the message based on its contents (0046-DSRM-014)(0046-SP-DSRM-014) +- For a pubkey only used in data sources referenced by markets (or other things) that are no longer being managed by the core (i.e. once a marked is in Closed or Settled or Cancelled state according to the market framework) or before the enactment date of the market proposal (0046-DSRM-015)(0046-SP-DSRM-015) Other acceptance: -- Must work with Coinbase oracle (0046-DSRM-012) -- Ignore any `SubmitData` tx that is a duplicate (i.e. contains exactly the same data payload and is for the same data source), even if it is signed by a different signer (assuming the source has multiple configured signers) or was submitted by a different Vega key. (0046-DSRM-016) -- Messages are accepted that contain the data and the signature (conforming to the Open Oracle specification) Note: do not support (or need to) direct connections to REST APIs, Ethereum smart contracts, etc. conforming to the open oracle spec. (0046-DSRM-017) +- Must work with Coinbase oracle (0046-DSRM-012)(0046-SP-DSRM-012) +- Ignore any `SubmitData` tx that is a duplicate (i.e. contains exactly the same data payload and is for the same data source), even if it is signed by a different signer (assuming the source has multiple configured signers) or was submitted by a different Vega key. (0046-DSRM-016)(0046-SP-DSRM-016) +- Messages are accepted that contain the data and the signature (conforming to the Open Oracle specification) Note: do not support (or need to) direct connections to REST APIs, Ethereum smart contracts, etc. conforming to the open oracle spec. (0046-DSRM-017)(0046-SP-DSRM-017) ## Notes diff --git a/protocol/0047-DSRF-data_source_filter.md b/protocol/0047-DSRF-data_source_filter.md index 3028a7338..c73b2fa39 100644 --- a/protocol/0047-DSRF-data_source_filter.md +++ b/protocol/0047-DSRF-data_source_filter.md @@ -86,32 +86,32 @@ To be clear, this also means that if the input data is the wrong "shape" or type ## Acceptance criteria 1. Filters can be used with any data source provider (internal, signed message, Ethereum etc.) - 1. Create a filter for each type of source provider and ensure that only data matching the filter gets through. (0047-DSRF-001) - 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002) + 1. Create a filter for each type of source provider and ensure that only data matching the filter gets through. (0047-DSRF-001)(0047-SP-DSRF-001) + 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002)(0047-SP-DSRF-002) 1. All filter conditions are applied - 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003) - 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004) - 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01" _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041). + 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003)(0047-SP-DSRF-003) + 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004)(0047-SP-OSMICELEVATOR-004) + 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01") _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041)(0047-SP-DSRF-0041). 1. Data that is filtered out does not result in a data event but is recorded - 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005) - 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006) - 1. When data is filtered out and no event is emitted this is recorded either in logs or on the event bus (this may only happen on the receiving node if the event is a transaction that is rejected prior to being sequenced in a block). (0047-DSRF-007) + 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005)(0047-SP-DSRF-005) + 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006)(0047-SP-DSRF-006) + 1. When data is filtered out and no event is emitted this is recorded either in logs or on the event bus (this may only happen on the receiving node if the event is a transaction that is rejected prior to being sequenced in a block). (0047-DSRF-007)(0047-SP-DSRF-007) 1. Data sources are defined by the FULL definition including filters - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008)(0047-SP-DSRF-008) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009)(0047-SP-DSRF-009) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010)(0047-SP-DSRF-010) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011)(0047-SP-DSRF-011) 1. Data types and condition types - 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012) - 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013) - 1. Date + time fields can be filtered by equality (datetime matches filter data exactly). (0047-DSRF-014) - 1. Number fields can be filtered by less than (number is less than filter data). (0047-DSRF-015) - 1. Date + time fields can be filtered by less than (datetime is less than filter data). (0047-DSRF-016) - 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017) - 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018) - 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019) - 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020) - 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021) - 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022 - 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023) - 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024) + 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012)(0047-SP-DSRF-012) + 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013)(0047-DSRF-013) + 1. Date + time fields can be filtered by equality (datetime matches filter data exactly). (0047-DSRF-014)(0047-SP-DSRF-014) + 1. Number fields can be filtered by less than (number is less than filter data). (0047-DSRF-015)(0047-SP-DSRF-015) + 1. Date + time fields can be filtered by less than (datetime is less than filter data). (0047-DSRF-016)(0047-SP-DSRF-016) + 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017)(0047-SP-DSRF-017) + 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018)(0047-SP-DSRF-018) + 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019)(0047-SP-DSRF-019) + 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020)(0047-SP-DSRF-020) + 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021)(0047-SP-DSRF-021) + 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022)(0047-SP-DSRF-022) + 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023)(0047-SP-DSRF-023) + 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024)(0047-SP-DSRF-024) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index ffa3333f3..035198a01 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -102,21 +102,21 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna ## Acceptance criteria 1. A simple value data source can be provided - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001) - 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001)(0048-SP-COSMICELEVATOR-001) + 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002)(0048-SP-COSMICELEVATOR-002) 1. A time triggered value data source can be provided - 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004) - 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007) - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008) + 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009)(0048-SP-COSMICELEVATOR-009) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003)(0048-SP-COSMICELEVATOR-003) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004)(0048-SP-COSMICELEVATOR-004) + 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) (0048-SP-COSMICELEVATOR-005) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006)(0048-SP-COSMICELEVATOR-006) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007)(0048-SP-COSMICELEVATOR-007) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008)(0048-SP-COSMICELEVATOR-008) 1. A Vega time changed value data source can be provided - 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the past. The market state changes to trading terminated immediately. (0048-DSRI-012) -1. Termination oracle updated after market is terminated (0048-DSRI-015) + 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010)(0048-SP-DSRI-010) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011)(0048-SP-DSRI-011) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the past. The market state changes to trading terminated immediately. (0048-DSRI-012)(0048-SP-DSRI-012) +1. Termination oracle updated after market is terminated (0048-DSRI-015)(0048-SP-DSRI-015) - setup one market with a boolean termination - terminate the market (but do not settle it) - update the market to have a time based termination @@ -124,7 +124,7 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna - wait until the first timer to tick - send through valid settlement data - assert the the market settles successfully -1. Time based termination across multiple markets (0048-DSRI-014) +1. Time based termination across multiple markets (0048-DSRI-014)(0048-SP-DSRI-014) - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time - wait to all of them to terminate successfully - assert they all settle successfully diff --git a/protocol/0049-TVAL-validate_transaction_preconsensus.md b/protocol/0049-TVAL-validate_transaction_preconsensus.md index 85cd84999..1038bb970 100644 --- a/protocol/0049-TVAL-validate_transaction_preconsensus.md +++ b/protocol/0049-TVAL-validate_transaction_preconsensus.md @@ -28,9 +28,9 @@ Future enhancements: for each root transaction message type (e.g. `SubmitOrder`, Note that separate pre-consensus validation is carried out as part of PoW anti-spam checks, see the acceptance criteria in [PoW spec](./0072-SPPW-spam-protection-PoW.md). -1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001) -1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002) -1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-COSMICELEVATOR-003) -1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-COSMICELEVATOR-004) -1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-COSMICELEVATOR-005) -1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006) +1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001)(0049-SP-TVAL-001) +1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002)(0049-SP-TVAL-002) +1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-COSMICELEVATOR-003)(0049-SP-COSMICELEVATOR-003) +1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-COSMICELEVATOR-004)(0049-SP-COSMICELEVATOR-004) +1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-COSMICELEVATOR-005)(0049-SP-COSMICELEVATOR-005) +1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006)(0049-SP-TVAL-006) diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index 517da9c74..6bf36b971 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -199,11 +199,11 @@ All parameters that are changed through a governance vote are valid starting the Epochs change at the end of the first block that is after the epoch expiry has passed: -- Given an epoch length of `x`, with a block time arbitrary but `0050-EPOC-001) -- Given an epoch length of `x`, with a block time `x/y`, at end of block `y-1` the current epoch is `1` (0050-EPOC-002) -- Given an epoch length of `x`, with a block time of `x/y`, at end of block `y` the current epoch is `2` (0050-EPOC-003) +- Given an epoch length of `x`, with a block time arbitrary but `0050-EPOC-001)(0050-SP-EPOC-001) +- Given an epoch length of `x`, with a block time `x/y`, at end of block `y-1` the current epoch is `1` (0050-EPOC-002)(0050-SP-EPOC-002) +- Given an epoch length of `x`, with a block time of `x/y`, at end of block `y` the current epoch is `2` (0050-EPOC-003)(0050-SP-EPOC-003) -Edge case: Multiple epochs can pass within the same block (0050-EPOC-004): +Edge case: Multiple epochs can pass within the same block (0050-EPOC-004)(0050-SP-EPOC-004): - Given an epoch length of `x`, with a block time of `x*y`, at end of block 1 the current epoch is `1` - Given an epoch length of `x`, with a block time of `x*y`, at end of block `y+1` the current epoch is `y+1` @@ -211,9 +211,9 @@ Edge case: Multiple epochs can pass within the same block (0050-EPOC-005) (note: this can be tested by trying to delegate again, which will be rejected) - - `validator 1`s nominated balance is not increased in epoch 1 (0050-EPOC-006) - - `validator 1`s nominated balance is increased in the first block of epoch 2 (0050-EPOC-007) + - `party 1`s staking balanced is reduced immediately upon execution of the transaction (0050-EPOC-005)(0050-SP-EPOC-005) (note: this can be tested by trying to delegate again, which will be rejected) + - `validator 1`s nominated balance is not increased in epoch 1 (0050-EPOC-006)(0050-SP-EPOC-006) + - `validator 1`s nominated balance is increased in the first block of epoch 2 (0050-EPOC-007)(0050-SP-EPOC-007) ## See also diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index b64a11abb..a3371b421 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -119,12 +119,12 @@ APIS should be available to: Settlement assets: -- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001) -- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002) +- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001)(0051-SP-PPROD-001) +- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002)(0051-SP-PPROD-002) Product updates via governance: -- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003) +- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003)(0051-SP-PPROD-003) ## See also From ba70d5207afda703479098bd53e79e7cc01465ed Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 16:37:08 +0100 Subject: [PATCH 210/649] feat: add ACs for 0052/53/54 --- .../0052-FPOS-fractional_orders_positions.md | 4 +- protocol/0054-NETP-network_parameters.md | 10 ++-- protocol/0055-TREA-on_chain_treasury.md | 6 +-- protocol/0056-REWA-rewards_overview.md | 49 ++++++++++--------- 4 files changed, 35 insertions(+), 34 deletions(-) diff --git a/protocol/0052-FPOS-fractional_orders_positions.md b/protocol/0052-FPOS-fractional_orders_positions.md index bd78af7fb..089c393d5 100644 --- a/protocol/0052-FPOS-fractional_orders_positions.md +++ b/protocol/0052-FPOS-fractional_orders_positions.md @@ -20,8 +20,8 @@ Specs affected by this change (Note: in many cases the implementation may not ch ## Acceptance Criteria -- All proposed markets will have a decimal places property available via the API (0052-FPOS-001) -- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002) +- All proposed markets will have a decimal places property available via the API (0052-FPOS-001)(0052-SP-FPOS-001) +- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002)(0052-SP-FPOS-002) - Fees are calculated as per ([0029-FEES-013](./0029-FEES-fees.md#0029-FEES-013)) - LP order volume is implied correctly using fractional volume amounts as per ([0038-OLIQ-006](./0038-OLIQ-liquidity_provision_order_type.md#0038-OLIQ-006)) - Mark-to-market settlement happens correctly with PDP > 0 ([0003-MTMK-0015](./0003-MTMK-mark_to_market_settlement.md#0003-MTMK-015)) diff --git a/protocol/0054-NETP-network_parameters.md b/protocol/0054-NETP-network_parameters.md index 747716c29..c7960f7df 100644 --- a/protocol/0054-NETP-network_parameters.md +++ b/protocol/0054-NETP-network_parameters.md @@ -91,9 +91,9 @@ The current network parameters are specified in the code specifiying the min and ## Acceptance criteria -- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001) -- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002) +- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001)(0054-SP-NETP-001) +- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002)(0054-SP-NETP-002) - For `market.margin.scalingFactors` set in `genesis.json` or in a governance proposal we validate the format and the fact that "1.0 <= search <= initial <= release"; if these are invalid a useful error is returned. (0054-NETP-003) -- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004) -- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005) -- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006) +- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004)(0054-SP-NETP-004) +- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005)(0054-SP-NETP-005) +- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006)(0054-SP-NETP-006) diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index 965dd83f5..802d9a2bf 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -62,6 +62,6 @@ A governance proposal may be submitted to transfer funds on enactment from the o ### Post Oregon Trail - If a governance proposal for a single transfer from a network treasury account to some other account is enacted then - - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-COSMICELEVATOR-050) - - if the balance in the network treasury for the asset is greater than the amount specified in the transfer then the network treasury balance is decreased by the said amount and the destination account (party address) account is incremented by the right amount. (0055-COSMICELEVATOR-051) -- If a governance proposal for a single periodic transfer from a network treasury account to some other account is enacted then the transfers run as individual transfers as specified by the schedule / amounts until the schedule ends. (0055-COSMICELEVATOR-060) + - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-COSMICELEVATOR-050)(0055-SP-COSMICELEVATOR-050) + - if the balance in the network treasury for the asset is greater than the amount specified in the transfer then the network treasury balance is decreased by the said amount and the destination account (party address) account is incremented by the right amount. (0055-COSMICELEVATOR-051)(0055-SP-COSMICELEVATOR-051) +- If a governance proposal for a single periodic transfer from a network treasury account to some other account is enacted then the transfers run as individual transfers as specified by the schedule / amounts until the schedule ends. (0055-COSMICELEVATOR-060)(0055-SP-COSMICELEVATOR-060) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 65792570a..2a125230f 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -120,7 +120,7 @@ Reward payouts will be calculated using the decimal precision of the reward payo ## Acceptance criteria -### Funding reward accounts (0056-REWA-001) +### Funding reward accounts (0056-REWA-001)(0056-SP-REWA-001) Trading reward accounts are defined by a pair: [`payout_asset, dispatch_strategy`]. @@ -132,7 +132,7 @@ Create 3 markets settling in USDT. Wait for a new epoch to begin, in the next ep Run for another epoch with no fee generated. Expect no transfer to be made to the reward pools of the accounts. -### Funding reward accounts - with markets in scope (0056-REWA-002) +### Funding reward accounts - with markets in scope (0056-REWA-002)(0056-SP-REWA-002) There are two assets configured on the Vega chain: $VEGA and USDT. @@ -142,7 +142,7 @@ Create 3 markets settling in USDT. Wait for a new epoch to begin, in the next ep Run for another epoch with no fee generated. Expect no transfer to be made to the reward pools of the accounts. -### Distributing fees paid rewards (0056-REWA-010) +### Distributing fees paid rewards (0056-REWA-010)(0056-SP-REWA-010) #### Rationale 1 @@ -189,7 +189,7 @@ At the end of epoch 2: - `party_1` is paid `120 x 3.36 / 4.98 = 80.96.` USDC from the reward account into its USDC general account. - `party_2` is paid `120 x 1.62 / 4.98 = 39.03.` USDC from the reward account into its USDC general account. -### Distributing fees paid rewards - unfunded account (0056-REWA-011) +### Distributing fees paid rewards - unfunded account (0056-REWA-011)(0056-SP-REWA-011) #### Rationale 2 @@ -207,7 +207,7 @@ No funding done. At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, no reward is given to any participant as the reward account was not funded. -### Distributing fees paid rewards - funded account - no trading activity (0056-REWA-012) +### Distributing fees paid rewards - funded account - no trading activity (0056-REWA-012)(0056-SP-REWA-012) #### Rationale 3 @@ -231,7 +231,7 @@ Then, during epoch 3 we fund the reward accounts for the metric: Looking only at epoch 3 - as no trading activity was done, we expect the reward balances in both $VEGA and USDC for the metric to remain unchanged. -### Distributing fees paid rewards - multiple markets (0056-REWA-013) +### Distributing fees paid rewards - multiple markets (0056-REWA-013)(0056-SP-REWA-013) #### Rationale 4 @@ -270,7 +270,7 @@ The calculation of eligibility is identical to [acceptance code REWA-010](https: - `party_1` is paid `120 x 3.36 / 4.98 = 80.96.` $VEGA from the reward account into its $VEGA general account. - `party_2` is paid `120 x 1.62 / 4.98 = 39.03.` $VEGA from the reward account into its $VEGA general account. -### Distributing maker fees received rewards (0056-REWA-020) +### Distributing maker fees received rewards (0056-REWA-020)(0056-SP-REWA-020) #### Rationale 5 @@ -315,7 +315,7 @@ At the end of epoch `2` `party_0` is paid `90 x 2.8 / (2.79+2.8)` $VEGA from the At the end of epoch `2` `party_1` is paid `120 x 2.79 / (2.79+2.8)` USDC from the reward account into its `USDC` general account. At the end of epoch `2` `party_0` is paid `120 x 2.8 / (2.79+2.8)` USDC from the reward account into its `USDC` general account. -### Distributing maker fees received rewards - unfunded account (0056-REWA-021) +### Distributing maker fees received rewards - unfunded account (0056-REWA-021)(0056-SP-REWA-021) #### Rationale 6 @@ -333,7 +333,7 @@ No funding done. At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, no reward is given to any participant as the reward account was not funded. -### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-022) +### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-022)(0056-SP-REWA-022) #### Rationale 7 @@ -357,7 +357,7 @@ Then, during epoch 3 we fund the reward accounts for the metric: Looking only at epoch 3 - as no trading activity was done, we expect the reward balances in both $VEGA and USDC for the metric to remain unchanged. -### Distributing maker fees received rewards - multiple markets (0056-REWA-023) +### Distributing maker fees received rewards - multiple markets (0056-REWA-023)(0056-SP-REWA-023) #### Rationale 8 @@ -396,7 +396,7 @@ The calculation of eligibility is identical to [acceptance code REWA-020](https: - At the end of epoch `2` `party_1` is paid `120 x 2.79 / (2.79+2.8)` USDC from the reward account into its `$VEGA` general account. - At the end of epoch `2` `party_0` is paid `120 x 2.8 / (2.79+2.8)` USDC from the reward account into its `$VEGA` general account. -### Distributing LP fees received rewards (0056-REWA-030) +### Distributing LP fees received rewards (0056-REWA-030)(0056-SP-REWA-030) #### Rationale 9 @@ -422,6 +422,7 @@ At the end of epoch `2` `party_0` is paid `90` `$VEGA` from the reward account i At the end of epoch `2` `party_0` is paid `120` `USDC` from the reward account into its `USDC` general account. ### Distributing LP fees received rewards - unfunded account (0056-REWA-031) +(0056-SP-REWA-031) #### Rationale 10 @@ -439,7 +440,7 @@ No funding done. At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, no reward is given to any participant as the reward account was not funded. -### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-032) +### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-032)(0056-SP-REWA-032) #### Rationale 11 @@ -463,7 +464,7 @@ Then, during epoch 3 we fund the reward accounts for the metric: Looking only at epoch 3 - as no trading activity was done, we expect the reward balances in both $VEGA and USDC for the metric to remain unchanged. -### Distributing LP fees received - multiple markets (0056-REWA-033) +### Distributing LP fees received - multiple markets (0056-REWA-033)(0056-SP-REWA-033) #### Rationale 12 @@ -488,7 +489,7 @@ The calculation of eligibility is identical to [acceptance code REWA-030](https: - for market `ETHUSD-Jun22`: - t the end of epoch `2` `party_0` is paid `120` `USDC` from the reward account into its `USDC` general account. -### Distributing market creation rewards - no eligibility (0056-REWA-040) +### Distributing market creation rewards - no eligibility (0056-REWA-040)(0056-SP-REWA-040) #### Rationale 13 @@ -507,7 +508,7 @@ Market has been trading but not yet eligible for proposer bonus. At the end of the epoch no payout has been made for the market `ETHUSDT` and the reward account balances should remain unchanged. -### Distributing market creation rewards - eligible are paid no more than once (0056-REWA-041) +### Distributing market creation rewards - eligible are paid no more than once (0056-REWA-041)(0056-SP-REWA-041) #### Rationale 14 @@ -529,7 +530,7 @@ At the end of the epoch 2 the proposer of the market `ETHUSDT` is paid 10000 `$V At the end of epoch 3 make sure that no transfer is made to the reward account as the proposer of the market has already been paid the proposer bonus once and there are no other eligible markets. -### Distributing market creation rewards - account funded after reaching requirement (0056-REWA-042) +### Distributing market creation rewards - account funded after reaching requirement (0056-REWA-042)(0056-SP-REWA-042) #### Rationale 15 @@ -550,7 +551,7 @@ Market goes above the threshold in trading value in an epoch before the reward a At the end of epoch 3, a payout of 10000 VEGA and 20000 USDC is made for the market `ETHUSDT` to the creator's general account balance. The reward pool balance should be 0. -### Distributing market creation rewards - multiple asset rewards (0056-REWA-043) +### Distributing market creation rewards - multiple asset rewards (0056-REWA-043)(0056-SP-REWA-043) #### Rationale 16 @@ -572,7 +573,7 @@ At the end of epoch 2 1000 VEGA rewards should be distributed to the market crea Then, at the end of epoch 3, the 20000 USDC rewards should be distributed again to the market creator's general balance. The reward pool balance should be 0. -### Distributing market creation rewards - multiple asset rewards simultaneous payout (0056-REWA-045) +### Distributing market creation rewards - multiple asset rewards simultaneous payout (0056-REWA-045)(0056-SP-REWA-045) #### Rationale 17 @@ -595,7 +596,7 @@ At the end of epoch 2 the creator of `ETHUSDT` should receive both 10000 VEGA an general account. The reward pool balance should be 0. -### Distributing market creation rewards - Same asset multiple party rewards (0056-REWA-044) +### Distributing market creation rewards - Same asset multiple party rewards (0056-REWA-044)(0056-SP-REWA-044) #### Rationale 18 @@ -623,7 +624,7 @@ The reward account balance should again be empty Then, at the end of epoch 4, no further VEGA rewards should be distributed, the proposer of `ETHUSDTs` general `USDT` balance should stay at 20000. The reward account balance should still be empty, as there were no eligible markets so no transfer should occur. -### Distributing market creation rewards - Multiple markets eligible, one already paid (0056-REWA-046) +### Distributing market creation rewards - Multiple markets eligible, one already paid (0056-REWA-046)(0056-SP-REWA-046) #### Rationale 19 @@ -655,7 +656,7 @@ At the end of epoch 3, 10000 VEGA should be split between the `BTCDAI` creator a - The general account balance of the `BTCDAI` creator should be 5000. - The reward pool balance should be 0. -### Reward accounts cannot be topped up with a one-off transfer (0056-REWA-049) +### Reward accounts cannot be topped up with a one-off transfer (0056-REWA-049)(0056-SP-REWA-049) The following account types require metric-based distribution. As a one-off transfer cannot specify how it is rewarded, one-off transfers to metric-based reward pools must be **rejected**. A one-off transfer from a user to any of the following account types is rejected. No assets are transferred: @@ -665,7 +666,7 @@ A one-off transfer from a user to any of the following account types is rejected - `ACCOUNT_TYPE_REWARD_TAKER_PAID_FEES`, - `ACCOUNT_TYPE_REWARD_MARKET_PROPOSERS` -### Distributing market creation rewards - Market ineligible through metric asset (0056-REWA-048) +### Distributing market creation rewards - Market ineligible through metric asset (0056-REWA-048)(0056-SP-REWA-048) #### Rationale 20 @@ -689,7 +690,7 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to only the `ETH - The general account balance of the `BTCDAI` creator should be 0. - The reward pool balance should be 0. -### Distributing market creation rewards - Multiple markets eligible, one already paid, specified asset (0056-REWA-047) +### Distributing market creation rewards - Multiple markets eligible, one already paid, specified asset (0056-REWA-047)(0056-SP-REWA-047) #### Rationale 21 @@ -723,7 +724,7 @@ At the end of epoch 3, 10000 VEGA should be distributed split between the `BTCUS - The general account balance of the `BTCUSDT` creator should be 5000. - The reward pool balance should be 0. -### Updating the network parameter `rewards.marketCreationQuantumMultiple` (0056-REWA-050) +### Updating the network parameter `rewards.marketCreationQuantumMultiple` (0056-REWA-050)(0056-SP-REWA-050) #### Rationale 22 From 39067fbef0490f5a8db0f058cd2e18a355bcfd50 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 16:49:31 +0100 Subject: [PATCH 211/649] feat: add ACs for 0057/59/61 --- protocol/0057-TRAN-transfers.md | 47 ++++++++++--------- ...0059-STKG-simple_staking_and_delegating.md | 40 ++++++++-------- protocol/0061-REWP-pos_rewards.md | 22 ++++----- 3 files changed, 55 insertions(+), 54 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 52bf0480e..e745480a1 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -187,34 +187,34 @@ message CancelTransfer { ### One off transfer tests -- As a user I can transfer funds from a general account I control to an other party's general account. Such transfer can be immediate or delayed. (0057-TRAN-001) -- As a user I **cannot** transfer funds from a general account I control to reward account with a one-off transfer. (0057-TRAN-002) -- As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-003). -- As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-004) -- As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005) -- As a user I cannot transfer funds from accounts I own but from the type is not supported (e.g. margin, staking). (0057-TRAN-006) -- As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007) +- As a user I can transfer funds from a general account I control to an other party's general account. Such transfer can be immediate or delayed. (0057-TRAN-001)(0057-vTRAN-001) +- As a user I **cannot** transfer funds from a general account I control to reward account with a one-off transfer. (0057-TRAN-002)(0057-SP-TRAN-002) +- As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-003)(0057-SP-COSMICELEVATOR-TRAN-003). +- As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-004)(0057-SP-COSMICELEVATOR-TRAN-004) +- As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005)(0057-SP-TRAN-005) +- As a user I cannot transfer funds from accounts I own but from the type is not supported (e.g. margin, staking). (0057-TRAN-006)(0057-SP-TRAN-006) +- As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007)(0057-SP-TRAN-007) - The fee cost is correctly calculated using the network parameter - If I have enough funds to pay transfer and fees, the transfer happens. - If I do not have enough funds to pay transfer and fees, the transfer is cancelled. - The fees are being paid into the infrastructure pool -- As a user, when I initiate a delayed transfer, the funds are taken from my account immediately (0057-TRAN-008) +- As a user, when I initiate a delayed transfer, the funds are taken from my account immediately (0057-TRAN-008)(0057-SP-TRAN-008) - The funds arrive in the target account when the transaction is processed (i.e. with the correct delay), which is not before the timestamp occurs - A delayed transfer that is invalid (to an invalid account type) is rejected when it is received, and the funds are not taken from the origin account. -- The spam protection mechanics prevent me to do more than `spam.protection.maxUserTransfersPerEpoch` transfers per epoch. (0057-TRAN-009) -- A delayed one-off transfer cannot be cancelled once set-up. (0057-TRAN-010) -- A one-off transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-059) +- The spam protection mechanics prevent me to do more than `spam.protection.maxUserTransfersPerEpoch` transfers per epoch. (0057-TRAN-009)(0057-SP-TRAN-009) +- A delayed one-off transfer cannot be cancelled once set-up. (0057-TRAN-010)(0057-SP-TRAN-010) +- A one-off transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-059)(0057-SP-TRAN-059) ### Recurring transfer tests -As a user I can create a recurring transfer _which expires after a specified epoch_ (0057-TRAN-050) +As a user I can create a recurring transfer _which expires after a specified epoch_ (0057-TRAN-050)(0057-SP-RAN-050) - I specify a start and end epoch, and a factor of `1`, start epoch in the future, until the start epoch is reached no transfers are executed. - Once I reach the start epoch, the first transfer happens. - The same amount is transferred every epoch. - In the epoch after the `end epoch`, no transfers are executed. -As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-051) +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-051)(0057-SP-TRAN-051) - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed @@ -223,7 +223,7 @@ As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-052) +As a user I can create a recurring transfer that recurs forever, with the same balance transferred each time (0057-TRAN-052)(0057-SP-TRAN-052) - I specify a start and no end epoch, and a factor of `1` - Until the start epoch is reached not transfers are executed @@ -231,7 +231,7 @@ As a user I can create a recurring transfer that recurs forever, with the same b - The amount transferred every epoch is the same - The transfers happen forever -As a user I can create a recurring transfer that recurs as long as the amount is `transfer.minTransferQuantumMultiple x quantum`, with the amount transfer decreasing. (0057-TRAN-053) +As a user I can create a recurring transfer that recurs as long as the amount is `transfer.minTransferQuantumMultiple x quantum`, with the amount transfer decreasing. (0057-TRAN-053)(0057-SP-TRAN-053) - I specify a start and no end epoch, and a factor of `0.1` - Until the start epoch is reached not transfers are executed @@ -240,20 +240,20 @@ As a user I can create a recurring transfer that recurs as long as the amount is - The transfers happen as long as the amount transferred is > `transfer.minTransferQuantumMultiple x quantum`. - After a sufficiently large number of epochs the transfers stops and the recurring transfer is deleted. -As a user I can cancel a recurring transfer (0057-TRAN-054) +As a user I can cancel a recurring transfer (0057-TRAN-054)(0057-SP-TRAN-054) - I specify a start and no end epoch, and a factor of 1 - Once I reach the start epoch transfers happens. - I cancel the recurring transfer after the start epoch, before the end epoch - No transfer are executed anymore -As a user I can cancel a recurring transfer before any transfers have executed (0057-TRAN-055) +As a user I can cancel a recurring transfer before any transfers have executed (0057-TRAN-055)(0057-SP-TRAN-055) - I specify a start and no end epoch, and a factor of 1 - I cancel the transfer after the start epoch, before the end epoch - No transfer are executed at all -A user's recurring transfer is cancelled if any transfer fails due to insufficient funds (0057-TRAN-056) +A user's recurring transfer is cancelled if any transfer fails due to insufficient funds (0057-TRAN-056)(0057-SP-TRAN-056) - I specify a start and no end epoch, and a factor of 1 - Until the epoch is reached not transfers are executed @@ -262,9 +262,9 @@ A user's recurring transfer is cancelled if any transfer fails due to insufficie - The transfer is cancelled - No more transfers are executed. -A recurring transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-058) +A recurring transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-058)(0057-SP-TRAN-058) -A user's recurring transfer to a reward account does not occur if there are no parties eligible for a reward in the current epoch (0057-TRAN-057) +A user's recurring transfer to a reward account does not occur if there are no parties eligible for a reward in the current epoch (0057-TRAN-057)(0057-SP-TRAN-057) - I set up a market `ETHUSDT` settling in USDT. - The value of `marketCreationQuantumMultiple` is `10^6` and `quantum` for `USDT` is `1`. @@ -274,9 +274,10 @@ A user's recurring transfer to a reward account does not occur if there are no p - At the end of the third epoch, no transfer occurs If the network parameter `transfer.fee.factor` is modified, this modification is applied -immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062) +immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062)(0057-SP-TRAN-062) + +If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060)(0057-SP-TRAN-060) -If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060) If the network parameter `transfer.minTransferQuantumMultiple` is modified, this modification is applied -immediately on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-061) +immediately on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-061)(0057-SP-TRAN-061) diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index 3cb481662..e7226a509 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -178,34 +178,34 @@ To lock tokens, a participant must: To delegate the locked tokens, a participant must: -- Have enough tokens to satisfy the network parameter: "Minimum delegateable stake" (0059-STKG-001) -- Delegate the locked tokens to one of the eligible validators (fixed set for Alpha mainnet).(0059-STKG-002) +- Have enough tokens to satisfy the network parameter: "Minimum delegateable stake" (0059-STKG-001)(0059-SP-STKG-001) +- Delegate the locked tokens to one of the eligible validators (fixed set for Alpha mainnet).(0059-STKG-002)(0059-SP-STKG-002) These accounts will be created: -- A [staking account](./0013-ACCT-accounts.md#staking-accounts) denominated in the governance asset is created(0059-STKG-003) -- When first fees are received as a staking reward, a general account for each settlement currency (so they can receive infrastructure fee rewards) (0059-STKG-004) +- A [staking account](./0013-ACCT-accounts.md#staking-accounts) denominated in the governance asset is created(0059-STKG-003)(0059-SP-STKG-003) +- When first fees are received as a staking reward, a general account for each settlement currency (so they can receive infrastructure fee rewards) (0059-STKG-004)(0059-SP-STKG-004) - It is possible that a separate reward function will cause an account to be created for the user as a result of rewards. - Timings -- Any locked (but undelegated) tokens can be delegated at any time. (0059-STKG-005) -- The delegation only becomes valid at the next [epoch](./0050-EPOC-epochs.md), though it can be undone through undelegate. (0059-STKG-006) -- The balance of "delegateable stake" is reduced immediately (prior to it coming into effect in the next epoch) (0059-STKG-007) +- Any locked (but undelegated) tokens can be delegated at any time. (0059-STKG-005)(0059-SP-STKG-005) +- The delegation only becomes valid at the next [epoch](./0050-EPOC-epochs.md), though it can be undone through undelegate. (0059-STKG-006)(0059-SP-STKG-006) +- The balance of "delegateable stake" is reduced immediately (prior to it coming into effect in the next epoch) (0059-STKG-007)(0059-SP-STKG-007) ### Adding more stake -- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) (0059-STKG-008) -- More stake may be delegated at any time (see [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - amount refers to size by which to increment existing staked amount) (0059-STKG-009) -- Same timings apply as per staking for the first time (0059-STKG-010) +- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) (0059-STKG-008)(0059-SP-STKG-008) +- More stake may be delegated at any time (see [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - amount refers to size by which to increment existing staked amount) (0059-STKG-009)(0059-SP-STKG-009) +- Same timings apply as per staking for the first time (0059-STKG-010)(0059-SP-STKG-010) ### Removing stake -- Any stake may be withdrawn from the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) at any time (0059-STKG-011) - - Unlocking your tokens in the bridge contract will effectively "remove" them from any delegation they're doing (unless you have remaining undelegated tokens that could fulfil your delegation) (0059-STKG-012) -- Delegation may be fully or partially removed. The amount specified in the [function: Remove](./0071-STAK-erc20_governance_token_staking.md) - is the size by which the existing staked amount will be decremented (0059-STKG-013) +- Any stake may be withdrawn from the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) at any time (0059-STKG-011)(0059-SP-STKG-011) + - Unlocking your tokens in the bridge contract will effectively "remove" them from any delegation they're doing (unless you have remaining undelegated tokens that could fulfil your delegation) (0059-STKG-012)(0059-SP-STKG-012) +- Delegation may be fully or partially removed. The amount specified in the [function: Remove](./0071-STAK-erc20_governance_token_staking.md) - is the size by which the existing staked amount will be decremented (0059-STKG-013)(0059-SP-STKG-013) - Removal of delegation may happen in the following 2 ways: - - Announcing removal, but maintaining stake until last block of the current epoch. This "announced stake" may be then (re)delegated (e.g. to a different validator). (0059-STKG-014) - - Announcing removal and withdrawing stake immediately. Rewards are still collected for this stake until the end of the epoch, but they are sent to the on-chain treasury account for that asset. (0059-STKG-015) -- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that for the current epoch nomination balance we consider the minimum stake that the party had for the duration of the period evaluated (from the beginning of the epoch). Also, for next epoch's nomination balance we consider the current balance of the association. Have one party stake 100 tokens split 70-30 between two validators. With a an epoch of length 5 minutes, at the beginning of the epoch remove 50 tokens off the stake. Within 30 seconds of the confirmation of updated association, verify that the nomination balances for the current epoch and next has been removed with respect to the 70/30 split, such that it is now 35/15. (0059-STKG-016) + - Announcing removal, but maintaining stake until last block of the current epoch. This "announced stake" may be then (re)delegated (e.g. to a different validator). (0059-STKG-014)(0059-SP-STKG-014) + - Announcing removal and withdrawing stake immediately. Rewards are still collected for this stake until the end of the epoch, but they are sent to the on-chain treasury account for that asset. (0059-STKG-015)(0059-SP-STKG-015) +- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that for the current epoch nomination balance we consider the minimum stake that the party had for the duration of the period evaluated (from the beginning of the epoch). Also, for next epoch's nomination balance we consider the current balance of the association. Have one party stake 100 tokens split 70-30 between two validators. With a an epoch of length 5 minutes, at the beginning of the epoch remove 50 tokens off the stake. Within 30 seconds of the confirmation of updated association, verify that the nomination balances for the current epoch and next has been removed with respect to the 70/30 split, such that it is now 35/15. (0059-SP-STKG-016)(0059-STKG-016) ### Changing delegation @@ -216,21 +216,21 @@ These accounts will be created: ## Auto delegation scenarios -### Normal scenario auto undelegation: (0059-STKG-018) +### Normal scenario auto undelegation: (0059-STKG-018)(0059-SP-STKG-018) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 - epoch 1: party dissociated 200 VEGA - at the end of epoch 1: `party1` would have left 160 tokens nominated to validators 1-5 (for both epoch 1 and onwards - the former is important so that they don't get rewarded for 200 per validator) -### Normal scenario auto delegation: (0059-STKG-019) +### Normal scenario auto delegation: (0059-STKG-019)(0059-SP-STKG-019) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 - epoch 1: party associated 200 VEGA - end of epoch 1: there's sufficient space on each validator 1-5 to accept the delegation of 40 VEGA from `party1` and `party1` now has delegation of 240 for validators 1-5 for epoch 2. -### Edge case 1: manual delegation for party eligible for auto delegation: (0059-STKG-020) +### Edge case 1: manual delegation for party eligible for auto delegation: (0059-STKG-020)(0059-SP-STKG-020) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 @@ -239,7 +239,7 @@ These accounts will be created: - end of epoch1: party1 has 300 delegated to validator1, 200 delegated to validators 2-5 and 100 remain undelegated. - end of epoch2: the remaining associated undelegated 100 VEGA get auto-delegated and distributed such that `validator1` gets 27 (100 * 300/1100) and validators 2-5 get each 18 - and 1 token remains undelegated -### Edge case 2: manual undelegation for party eligible for auto delegation: (0059-STKG-021) +### Edge case 2: manual undelegation for party eligible for auto delegation: (0059-STKG-021)(0059-SP-STKG-021) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 diff --git a/protocol/0061-REWP-pos_rewards.md b/protocol/0061-REWP-pos_rewards.md index 608457d2d..0fc6ebd15 100644 --- a/protocol/0061-REWP-pos_rewards.md +++ b/protocol/0061-REWP-pos_rewards.md @@ -93,7 +93,7 @@ For ersatz validators, the same formula is used. ## Acceptance criteria -### Spare key on multisig (0061-REWP-001) +### Spare key on multisig (0061-REWP-001)(0061-SP-REWP-001) 1. Four or more Tendermint validators with equal own+delegated stake and some ersatz validators are running. 1. Reward pool is funded. @@ -101,12 +101,12 @@ For ersatz validators, the same formula is used. 1. One of the Tendermint validators goes offline forever and is removed from the set of Tendermint validators but their key still stays on multisig (no-one updated). 1. Epoch ends and multisig hasn't been updated. 1. Tendermint validators get no rewards. Ersatz validators still receive rewards. - - A validator with less than `minOwnStake` tokens staked to themselves will earn 0 rewards at the end of an epoch (0061-REWP-002) - - With `delegator_share` set to `0`, a validator keeps 100% of their own rewards, and a delegator receives no reward (0061-REWP-003) - - With `delegator_share` set to `1`, a validator receives no reward, and their delegators receive a proportional amount of 100% (0061-REWP-004) - - With `delegator_share` set to `0.5`, a validator keeps 50% of their own reward, and their delegators receives a proportional amount of the remaining 50% (0061-REWP-005) + - A validator with less than `minOwnStake` tokens staked to themselves will earn 0 rewards at the end of an epoch (0061-REWP-002)(0061-SP-REWP-002) + - With `delegator_share` set to `0`, a validator keeps 100% of their own rewards, and a delegator receives no reward (0061-REWP-003)(0061-SP-REWP-003) + - With `delegator_share` set to `1`, a validator receives no reward, and their delegators receive a proportional amount of 100% (0061-REWP-004)(0061-SP-REWP-004) + - With `delegator_share` set to `0.5`, a validator keeps 50% of their own reward, and their delegators receives a proportional amount of the remaining 50% (0061-REWP-005)(0061-SP-REWP-005) -### Rewards distribution corresponds to the signers on the multisig contract in the case that it hasn’t been updated after a validator set change (0061-REWP-006) +### Rewards distribution corresponds to the signers on the multisig contract in the case that it hasn’t been updated after a validator set change (0061-REWP-006)(0061-SP-REWP-006) 1. Four or more Tendermint validators with equal own+delegated stake and some ersatz validators are running. 1. There is a one-to-one correspondence between Tendermint validators' ethereum keys and keys on multisig. @@ -116,7 +116,7 @@ For ersatz validators, the same formula is used. 1. Epoch ends and multisig hasn't been updated. 1. All Tendermint validators get no rewards. Ersatz validators still receive rewards. -### Rewards from trading fees are calculated and distributed (0061-REWP-007) +### Rewards from trading fees are calculated and distributed (0061-REWP-007)(0061-SP-REWP-007) 1. Run Vega with at least 3 tendermint validator nodes and at least 5 ersatz validator nodes each with different self-stake and delegation. 1. A market is launched with settlement asset A, infrastructure fee of `0.01 = 1%`. Market leaves opening auction and at least 10 trades occur with a total traded notable for fee purposes of at least 10000000 A. @@ -126,7 +126,7 @@ For ersatz validators, the same formula is used. ### Change of network parameters -1. Change of network parameter `reward.staking.delegation.competitionLevel` will change the level of competition of the validators (influences how much stake is be needed for all validators to reach optimal revenue) at the end of the next epoch. Default value 3.1. Minimum value 1 (inclusive). (0061-REWP-008) -1. Change of network parameter `reward.staking.delegation.minimumValidatorStake` will change minimum amount required of own stake a validator has. Minimum stake applies to all validators. it’s referred to as a prerequisite to being considered a validator. Validators not met with the minimum stake will not be all thrown, and in fact unless there’s someone who can replace them no one will be kicked out. If there is an ersatz ready to replace them only one will be replaced every epoch. (0061-REWP-009) -1. Change of the network parameter `reward.staking.delegation.optstakemultiplier` is changed to 0 (the reward curve is flat for a validator that exceeds optimal stake), to 0.5 (the reward curve goes down), and 0.1 (the reward curve goes down slightly).(0061-REWP-010) -1. Change of network parameter `reward.staking.delegation.delegatorShare` to 0 (no reward for delegators, 0.99, and 0.5. The share for delegators at the end of the epochs changes accordingly. (0061-REWP-011) +1. Change of network parameter `reward.staking.delegation.competitionLevel` will change the level of competition of the validators (influences how much stake is be needed for all validators to reach optimal revenue) at the end of the next epoch. Default value 3.1. Minimum value 1 (inclusive). (0061-REWP-008)(0061-SP-REWP-008) +1. Change of network parameter `reward.staking.delegation.minimumValidatorStake` will change minimum amount required of own stake a validator has. Minimum stake applies to all validators. it’s referred to as a prerequisite to being considered a validator. Validators not met with the minimum stake will not be all thrown, and in fact unless there’s someone who can replace them no one will be kicked out. If there is an ersatz ready to replace them only one will be replaced every epoch. (0061-REWP-009)(0061-SP-REWP-009) +1. Change of the network parameter `reward.staking.delegation.optstakemultiplier` is changed to 0 (the reward curve is flat for a validator that exceeds optimal stake), to 0.5 (the reward curve goes down), and 0.1 (the reward curve goes down slightly).(0061-REWP-010)(0061-SP-REWP-010) +1. Change of network parameter `reward.staking.delegation.delegatorShare` to 0 (no reward for delegators), 0.99, and 0.5. The share for delegators at the end of the epochs changes accordingly. (0061-REWP-011)(0061-SP-REWP-011) From ccff3e6d73f66f4722762bee9b1de8e6905731c3 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 29 Jun 2023 19:59:26 +0100 Subject: [PATCH 212/649] feat: add ACs for 0062/63/64/65/66/67/68 --- protocol/0062-SPAM-spam_protection.md | 48 +++++++------- .../0063-VALK-validator_vega_master_keys.md | 26 ++++---- ...ALP-validator_performance_based_rewards.md | 14 ++-- .../0065-FTCO-floating_point_consensus.md | 8 +-- .../0066-VALW-validator_tendermint_weights.md | 18 ++--- protocol/0067-KEYS-key_management.md | 20 +++--- protocol/0068-MATC-matching_engine.md | 66 +++++++++---------- 7 files changed, 100 insertions(+), 100 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index b6209beaa..20d6b8760 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -93,29 +93,29 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - More than the allowed quota through delegation change only - More than the allowed quota through undelegation only (this might require lowering the parameter) -- More than the allowed quota through a mix, where each individual set of messages is within the quota (0062-SPAM-001) -- Delegating while having less than one vega (`10^18` of our smallest unit) (`spam.protection.delegation.min.tokens`) (0062-SPAM-002) -- Making a proposal when having less than 100.000 vega (`spam.protection.proposal.min.tokens`) (0062-SPAM-003) -- Changing the value of network parameter `spam.protection.proposal.min.tokens` will immediately change the minimum number of associated tokens needed for any kind of governance proposal. Proposals already active aren't affected.(0062-SPAM-014) -- Transactions creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) -- Transactions submitting votes by parties with less than `spam.protection.voting.min.tokens` of Vega associated are rejected. (0062-SPAM-005) -- Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006) -- Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007) -- If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008) -- It is possible for spam transactions to fill a block (0062-SPAM-010) -- Parties that continue spamming are blocked and eventually unblocked again (0062-SPAM-011) -- Any rejection due to spam protection is reported to the user upon transaction submission detailing which criteria the key exceeded / not met (0062-SPAM-013) -- If a party is banned for too many voting-rejections, it still can send trading related transactions which are not banned. (0062-SPAM-025) -- If the ban of a party ends because the banning time is up, transactions from that party are no longer rejected (0062-SPAM-015) -- If the ban of a party ends because the epoch ends, transactions from that party are no longer rejected (0062-SPAM-016) -- If a party gets banned, the ban ends due to the epoch ending, and it gets banned again at the beginning of the new epoch, the ban still lasts the entire time (or until the next epoch end), i.e., the ban-expiration timer is reset. (0062-SPAM-017) -- If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018) -- A ban only affects transactions of the type that caused the ban, i.e., a voting ban only affects further votes.(0062-SPAM-019) -- After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020) -- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) -- Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) -- Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) -- Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) -- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) +- More than the allowed quota through a mix, where each individual set of messages is within the quota (0062-SPAM-001)(0062-SP-SPAM-001) +- Delegating while having less than one vega (`10^18` of our smallest unit) (`spam.protection.delegation.min.tokens`) (0062-SPAM-002)(0062-SP-SPAM-002) +- Making a proposal when having less than 100.000 vega (`spam.protection.proposal.min.tokens`) (0062-SPAM-003)(0062-SP-SPAM-003) +- Changing the value of network parameter `spam.protection.proposal.min.tokens` will immediately change the minimum number of associated tokens needed for any kind of governance proposal. Proposals already active aren't affected.(0062-SPAM-014)(0062-SP-SPAM-014) +- Transactions creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004)(0062-SP-SPAM-004) +- Transactions submitting votes by parties with less than `spam.protection.voting.min.tokens` of Vega associated are rejected. (0062-SPAM-005)(0062-SP-SPAM-005) +- Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006)(0062-SP-SPAM-006) +- Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007)(0062-SP-SPAM-007) +- If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008)(0062-SP-SPAM-008) +- It is possible for spam transactions to fill a block (0062-SPAM-010)(0062-SP-SPAM-010) +- Parties that continue spamming are blocked and eventually unblocked again (0062-SPAM-011)(0062-SP-SPAM-011) +- Any rejection due to spam protection is reported to the user upon transaction submission detailing which criteria the key exceeded / not met (0062-SPAM-013)(0062-SP-SPAM-013) +- If a party is banned for too many voting-rejections, it still can send trading related transactions which are not banned. (0062-SPAM-025)(0062-SP-SPAM-025) +- If the ban of a party ends because the banning time is up, transactions from that party are no longer rejected (0062-SPAM-015)(0062-SP-SPAM-015) +- If the ban of a party ends because the epoch ends, transactions from that party are no longer rejected (0062-SPAM-016)(0062-SP-SPAM-016) +- If a party gets banned, the ban ends due to the epoch ending, and it gets banned again at the beginning of the new epoch, the ban still lasts the entire time (or until the next epoch end), i.e., the ban-expiration timer is reset. (0062-SPAM-017)(0062-SP-SPAM-017) +- If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018)(0062-SP-SPAM-018) +- A ban only affects transactions of the type that caused the ban, i.e., a voting ban only affects further votes.(0062-SPAM-019)(0062-SP-SPAM-019) +- After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020)(0062-SP-SPAM-020) +- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021)(0062-SP-SPAM-021) +- Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022)(0062-SP-SPAM-022) +- Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023)(0062-SP-SPAM-023) +- Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024)(0062-SP-SPAM-024) +- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001)(0062-SP-COSMICELEVATOR-001) > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. diff --git a/protocol/0063-VALK-validator_vega_master_keys.md b/protocol/0063-VALK-validator_vega_master_keys.md index 2f753a209..3c1b08858 100644 --- a/protocol/0063-VALK-validator_vega_master_keys.md +++ b/protocol/0063-VALK-validator_vega_master_keys.md @@ -34,16 +34,16 @@ The public master key has to be added to validators' identities in the genesis c ## Acceptance Criteria -- There is a function (not necessarily inside core) that takes the master key and an index and computes the corresponding hot key (0063-VALK-001) -- A transaction can be submitted to the network to initiate a Vega key rotation (0063-VALK-002) -- A transaction submitted by an old hot-key after `target_block` is not associated by the network as being from a Validator (0063-VALK-003) -- Once `target_block` has been reached the network reports the new key as the validators hot-key (0063-VALK-004) -- A key rotation submission which is not signed by the master key is rejected causing a transaction-error event that is visible by the whole network. (0063-VALK-005) -- It is possible to perform parallel key rotations rotations successfully in the same block. (0063-VALK-006) -- Once a validator hot key has been rotated all applicable rewards are correctly received. (0063-VALK-007) -- Once a validator hot key has been rotated staking and delegation to the validator works as before. (0063-VALK-008) -- Once a validator hot key has been rotated self-staking and self-delegation for the validator works as before. (0063-VALK-009) -- If several key change transactions are submitted simultaneously (i.e., a new key change is submitted before the target block of a previous one is reached, if key change message 1 has a lower sequence number and a higher/the same target block as change message 2, then the key established by message 2 is not replaced by the key from message 1. This can be done either by managing the parallel executions appropriately or by rejecting additional submissions(0063-VALK-010) -- Once the target block of a key change action us reached, all preceding keys (the original key as well as all hot keys rotated in through a key-change ,messager with a lower sequence number) are invalid. (0063-VALK-011) -- Key change message with a lower sequence number than the last one executed are rejected. (0063-VALK-012) -- Once a validator hot key has been rotated, it is possible to withdraw all rewards in the original keys account or submit a transfer to move them to the new key's account i.e the old key is still functional as a non-validator vega key. (0063-VALK-013) +- There is a function (not necessarily inside core) that takes the master key and an index and computes the corresponding hot key (0063-VALK-001)(0063-SP-VALK-001) +- A transaction can be submitted to the network to initiate a Vega key rotation (0063-VALK-002)(0063-SP-VALK-002) +- A transaction submitted by an old hot-key after `target_block` is not associated by the network as being from a Validator (0063-VALK-003)(0063-VSP-ALK-003) +- Once `target_block` has been reached the network reports the new key as the validators hot-key (0063-VALK-004)(0063-SP-VALK-004) +- A key rotation submission which is not signed by the master key is rejected causing a transaction-error event that is visible by the whole network. (0063-VALK-005)(0063-SP-VALK-005) +- It is possible to perform parallel key rotations rotations successfully in the same block. (0063-VALK-006)(0063-SP-VALK-006) +- Once a validator hot key has been rotated all applicable rewards are correctly received. (0063-VALK-007)(0063-SP-VALK-007) +- Once a validator hot key has been rotated staking and delegation to the validator works as before. (0063-VALK-008)(0063-SP-VALK-008) +- Once a validator hot key has been rotated self-staking and self-delegation for the validator works as before. (0063-VALK-009)(0063-SP-VALK-009) +- If several key change transactions are submitted simultaneously (i.e., a new key change is submitted before the target block of a previous one is reached), if key change message 1 has a lower sequence number and a higher/the same target block as change message 2, then the key established by message 2 is not replaced by the key from message 1. This can be done either by managing the parallel executions appropriately or by rejecting additional submissions(0063-VALK-010)(0063-SP-VALK-010) +- Once the target block of a key change action us reached, all preceding keys (the original key as well as all hot keys rotated in through a key-change ,messager with a lower sequence number) are invalid. (0063-VALK-011)(0063-SP-VALK-011) +- Key change message with a lower sequence number than the last one executed are rejected. (0063-VALK-012)(0063-SP-VALK-012) +- Once a validator hot key has been rotated, it is possible to withdraw all rewards in the original keys account or submit a transfer to move them to the new key's account i.e the old key is still functional as a non-validator vega key. (0063-VALK-013)(0063-SP-VALK-013) diff --git a/protocol/0064-VALP-validator_performance_based_rewards.md b/protocol/0064-VALP-validator_performance_based_rewards.md index ff169cdf3..464b6f013 100644 --- a/protocol/0064-VALP-validator_performance_based_rewards.md +++ b/protocol/0064-VALP-validator_performance_based_rewards.md @@ -54,16 +54,16 @@ The performance score should be available on all the same API endpoints as the ` ### Performance score -1. Tendermint validator with insufficient self-delegation (0064-VALP-001): +1. Tendermint validator with insufficient self-delegation (0064-VALP-001)(0064-SP-VALP-001): - Set up a network with 5 validators - Self-delegate to 4 of the nodes **more** than the minimum amount set in `reward.staking.delegation.minimumValidatorStake`. - Self-delegate to the 5th node **less** than the minimum amount. - Verify that at the beginning of the next epoch the performance score of the 5th validator is 0. -1. Tendermint validator with sufficient self-delegation (0064-VALP-002): +1. Tendermint validator with sufficient self-delegation (0064-VALP-002)(0064-SP-VALP-002): - Setup a network with 5 validators. - Self-delegate to all of them more than the minimum required. - Verify that after an epoch has passed, the performance score of all of them is close to 1. -1. Tendermint validator down (0064-VALP-003): +1. Tendermint validator down (0064-VALP-003)(0064-SP-VALP-003): - Setup a network with 5 validators. - Self-delegate to all of them more than the minimum required in `reward.staking.delegation.minimumValidatorStake` and ensure the validators self-stake is an equal amount across all. - Run the network for one epoch. @@ -71,7 +71,7 @@ The performance score should be available on all the same API endpoints as the ` - Run the network for half an epoch then shut down validator 5. - Verify that at the beginning of the next epoch the performance score for validator 5 is close to 0.5. - Verify that, with validator 5 still down for the next epoch, at the beginning of the following epoch the performance score for validator 5 is 0. -1. Non Tendermint validator (0064-VALP-004): +1. Non Tendermint validator (0064-VALP-004)(0064-SP-VALP-004): - Set the network parameter `network.validators.minimumEthereumEventsForNewValidator` to 0. - Setup a network with 5 validators and self-delegate to them. - Announce a new node to the network and self-delegate to them. @@ -80,12 +80,12 @@ The performance score should be available on all the same API endpoints as the ` - Let the network run for `numBlocks` blocks (*where `numBlocks = max(min(50, epochDurationSeconds), epochDurationSeconds x 0.01)`*) more and at the following epoch check that score is up to 0.2. Keep it running until its performance score of the joining validator reaches 1, then stop it. - Verify that for every `numBlocks` blocks (*where `numBlocks = max(min(50, epochDurationSeconds), epochDurationSeconds x 0.01)`*), the performance score should go down by 0.1 until it reaches zero. - **Note:** Every `numBlocks` the performance score should go up by 0.1. Now the performance score is only visible every epoch so depending on the ratio between `numBlocks` and epoch duration it may tick once or more per epoch. Guidance is that this test should either be parameterised or, preferably, written with a given epoch duration -1. Insufficient stake (0064-VALP-005): +1. Insufficient stake (0064-VALP-005)(0064-SP-VALP-005): - Setup a network with 5 validators, self-delegate to each more than the required minimum as set out in `reward.staking.delegation.minimumValidatorStake`. - Verify that at the beginning of the next epoch the validator has non 0 performance score, and voting power is greater than 10. - Update the network parameter `reward.staking.delegation.minimumValidatorStake` for minimum self-stake to be more than is self-delegated. - Verify that, at the beginning of the next epoch, all performance scores are 0 and voting power for all is 1 but the network keeps producing blocks and no nodes were removed from Tendermint. -1. Scores are restored after a snapshot restart (0064-VALP-006): +1. Scores are restored after a snapshot restart (0064-VALP-006)(0064-SP-VALP-006): - With a snapshot that was taken at a block-height that falls in the middle of an epoch, restart a node from that snapshot. Ensure that at the end of the epoch the node remains in consensus and has produced the correct performance scores. ## Future Stuff (in here for discussion purposes, not yet to be implemented) @@ -121,7 +121,7 @@ If we had another reward pool we could share it according to `f/n`. ## `PM5`: Validator only acts as a Tendermint leader -Finding this requires a statistic we don't have at this point (as we would like to also include messages that were sent but don't contribute to consensus anymore to avoid discriminating against geographically far away servers. Once we figured out how to do this, we can build a formula for the reward. +Finding this requires a statistic we don't have at this point (as we would like to also include messages that were sent but don't contribute to consensus anymore to avoid discriminating against geographically far away servers). Once we figured out how to do this, we can build a formula for the reward. ## `PM6`: Validator doesn't run the Vega app, just signs everything the others do diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index f068ef9a2..2186cbeed 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -84,7 +84,7 @@ This section outlines floating-point quantities `vega` currently relies on: ## Acceptance criteria -1. Floating-point values get initialised and updated correctly (0065-FTCO-001) +1. Floating-point values get initialised and updated correctly (0065-FTCO-001)(0065-SP-FTCO-001) - A market is proposed and initially it has the following default values: - Risk factors: - Short: 1.0 @@ -100,12 +100,12 @@ This section outlines floating-point quantities `vega` currently relies on: - When the time-based trigger elapses price monitoring bounds and probability of trading get recalculated. - When the market goes into liquidity monitoring auction the state variables stay the same as prior to its' start, when that auction concludes (choose a price that's not been traded at before) price monitoring bounds and probability of trading get recalculated again and the time-based trigger countdown gets reset. -1. Event announcing diverging values gets emitted (0065-FTCO-004) +1. Event announcing diverging values gets emitted (0065-FTCO-004)(0065-SP-FTCO-004) - For all the state variables nodes submit candidate values that differ by up to half the tolerance. - The event announcing the fact that at least one of the values differed gets emitted. - Since differences are within tolerance the consensus successfully chooses a consensus value and systems keeps running as expected (market goes into continuous trading mode accepts orders and generates trades). -1. Consensus failure event gets emitted (0065-FTCO-002) +1. Consensus failure event gets emitted (0065-FTCO-002)(0065-SP-FTCO-002) - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get submitted by nodes, one of the nodes submits a value that is higher than tolerance. - An appropriate event is sent to signal that at least one of the values differed. @@ -115,7 +115,7 @@ This section outlines floating-point quantities `vega` currently relies on: - Situation continues for 2 more risk factor update attempts (can be time-based or auction). - Market still runs with previously calculated risk factors, but an event informing that the market is using stale values gets emitted. -1. Market cannot leave opening auction with default values (0065-FTCO-003) +1. Market cannot leave opening auction with default values (0065-FTCO-003)(0065-SP-FTCO-003) - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get calculated (their values change from defaults). - When the opening auction sees uncrossing price for the first time (there are two overlapping orders from buy and sell side on the order book) price monitoring bounds get calculated, but probability of trading get doesn't pass consensus (all nodes submit conflicting values) diff --git a/protocol/0066-VALW-validator_tendermint_weights.md b/protocol/0066-VALW-validator_tendermint_weights.md index 29b3fc1b3..923be50f6 100644 --- a/protocol/0066-VALW-validator_tendermint_weights.md +++ b/protocol/0066-VALW-validator_tendermint_weights.md @@ -14,7 +14,7 @@ If the network has no stake at all, then all validators would have equal voting ## Acceptance criteria -### Basic sanity check (0066-VALW-001) +### Basic sanity check (0066-VALW-001)(0066-SP-VALW-001) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `2000` @@ -27,7 +27,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='2000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2066\ - Node 5 n[`stakedByOperator`]='2000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=1735 -### Non-uniform stake check (0066-VALW-002) +### Non-uniform stake check (0066-VALW-002)(0066-SP-VALW-002) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `500`. @@ -39,7 +39,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2092\ - Node 5 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2383 -### Zero stake check (0066-VALW-003) +### Zero stake check (0066-VALW-003)(0066-SP-VALW-003) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `0`. @@ -51,7 +51,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2419\ - Node 5 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' ``n_voting_power``=2741 -### Changes to delegation during the epoch are reflected in the next epoch’s voting power (0066-VALW-004) +### Changes to delegation during the epoch are reflected in the next epoch’s voting power (0066-SP-VALW-004)(0066-VALW-004) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `0`. @@ -71,7 +71,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2564\ - Node 5 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=64 -### Sanity check if everyone unstakes and undelegates (0066-VALW-005) +### Sanity check if everyone unstakes and undelegates (0066-SP-VALW-005)(0066-VALW-005) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `2000` @@ -86,7 +86,7 @@ If the network has no stake at all, then all validators would have equal voting 1. wait for 1000 blocks to pass 1. the Tendermint weights for each validator are `10` each as there is no stake in the network. -### Validator has 1000 stake but 500 delegated (0066-VALW-006) +### Validator has 1000 stake but 500 delegated (0066-VALW-006)(0066-SP-VALW-006) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `1000` @@ -99,7 +99,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2033\ - Node 5 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=1830 -### Validators without self-delegated, check (0066-VALW-007) +### Validators without self-delegated, check (0066-VALW-007)(0066-SP-VALW-007) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `0` @@ -112,7 +112,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='0' n[`stakedByDelegates`]='4000000000000000000' `n_voting_power`=3113\ - Node 5 n[`stakedByOperator`]='0' n[`stakedByDelegates`]='0' `n_voting_power`=1 -### Validators delegating to other validators (0066-VALW-008) +### Validators delegating to other validators (0066-VALW-008)(0066-SP-VALW-008) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `1000` @@ -125,7 +125,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2551\ - Node 5 n[`stakedByOperator`]='0' n[`stakedByDelegates`]='0' `n_voting_power`=1 -### Validator delegate and undelegate in the same epoch (0066-VALW-009) +### Validator delegate and undelegate in the same epoch (0066-VALW-009)(0066-SP-VALW-009) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `1000` diff --git a/protocol/0067-KEYS-key_management.md b/protocol/0067-KEYS-key_management.md index 25c520c06..dcab61f14 100644 --- a/protocol/0067-KEYS-key_management.md +++ b/protocol/0067-KEYS-key_management.md @@ -225,15 +225,15 @@ need to be hashed individually). ### Generic -1. After both a Vega and Ethereum key rotation, rewards are still produced (0067-KEYS-006) -2. After both a Vega and Ethereum key rotation the node still has the ability to self stake/delegate and delegate to other validator nodes (0067-KEYS-007) -3. After both a Vega and Ethereum key rotation the node still can generate snapshots and checkpoints and these can successfully be used for node restarts and network restoring respectively (0067-KEYS-008) -4. After both a Vega and Ethereum key rotation ensure there is no impact on node validator scores; meaning that if - the validator has been proposing blocks as expected and thus has a score close to `1` then after key rotation there is no sudden change in score. (0067-KEYS-009) - - If the validator has not been proposing blocks as expected and their score is close to `0` then after the rotation there is no sudden jump in score towards `1`. (0067-KEYS-010) +1. After both a Vega and Ethereum key rotation, rewards are still produced (0067-KEYS-006)(0067-SP-KEYS-006) +2. After both a Vega and Ethereum key rotation the node still has the ability to self stake/delegate and delegate to other validator nodes (0067-KEYS-007)(0067-SP-KEYS-007) +3. After both a Vega and Ethereum key rotation the node still can generate snapshots and checkpoints and these can successfully be used for node restarts and network restoring respectively (0067-KEYS-008)(0067-SP-KEYS-008) +4. After both a Vega and Ethereum key rotation ensure there is no impact on node validator scores; meaning that if - the validator has been proposing blocks as expected and thus has a score close to `1` then after key rotation there is no sudden change in score. (0067-KEYS-009)(0067-SP-KEYS-009) + - If the validator has not been proposing blocks as expected and their score is close to `0` then after the rotation there is no sudden jump in score towards `1`. (0067-KEYS-010)(0067-SP-KEYS-010) ### Ethereum key -1. multisig interaction (0067-KEYS-001): +1. multisig interaction (0067-KEYS-001)(0067-SP-KEYS-001): - A Vega network is running with 3 validators, `v1,v2,v3` with Ethereum keys `k1, k2, k3_old`; each with equal tendermint and multisig weight. - Validator `v3` has Ethereum multisig public key `k3_old`. They submit a transaction to replace by Ethereum multisig public key `k3_new`. - The network issues a signature bundle to update that can be submitted to the Ethereum multisig contract to update the key there. @@ -241,23 +241,23 @@ need to be hashed individually). - Vega nodes receive the event confirming the key has been updated. - Party `p` now issues a withdrawal transaction. A withdrawal bundle is created utilising `k1,k2,k3_new`. - Party `p` submits the withdrawal bundle to Ethereum; multisig contract accepts it and transfers the funds on the Ethereum chain. -1. Non-tendermint validators rotating keys does not generate signatures (0067-KEYS-003): +1. Non-tendermint validators rotating keys does not generate signatures (0067-KEYS-003)(0067-SP-KEYS-003): - A Vega network is running such there is at least 1 ersatz - Submit a transaction to rotate their Ethereum keys. - Verify that once `target_block` is reached, the data-node reports that the rotation occurred. - Verify that no signatures bundles are emitted from core to add/remove either the new key or the old key. - Repeat the above steps for a pending validator -1. Subsequent rotations cannot be submitted until the previous rotation is resolved on the contract (0067-KEYS-004): +1. Subsequent rotations cannot be submitted until the previous rotation is resolved on the contract (0067-KEYS-004)(0067-SP-KEYS-004): - Start a Vega network and pick a tendermint validator. - Submit a transaction to rotate their Ethereum key. - Verify that signatures bundles are emitted from core, but do not submit them to the multisig contract. - Submit another transactions to their rotate Ethereum keys. - Verify that the transaction fails. This is to prevent multiple valid add-signer bundles for the same validator. -1. Transaction with no proof of ownership of the new Ethereum key fails (0067-KEYS-005): +1. Transaction with no proof of ownership of the new Ethereum key fails (0067-KEYS-005)(0067-SP-KEYS-005): - Start a Vega network and pick a tendermint validator. - Submit a transaction to rotate their Ethereum keys which contains an invalid Ethereum signature. - Verify that the transaction fails. -1. Vega hot key (0067-KEYS-002): +1. Vega hot key (0067-KEYS-002)(0067-SP-KEYS-002): - There is a vega validator `v3` with master key `M` and hot key `h3_old`. See [master and hot vega keys](0063-VALK-validator_vega_master_keys.md). - A Vega network is running with 3 validators, `v1,v2,v3` using Vega hot keys `h1,h2,h3_old`. - Validator `v3` generates a new hot key `h3_new` using the master key `M`. diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index f605f1ea5..0f47d778f 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -8,13 +8,13 @@ The matching engine co-ordinates the trading of incoming orders with existing or An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001) - - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003) - - If there is no match the order will be cancelled. (0068-MATC-004) - - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001)(0068-SP-MATC-001) + - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002)(0068-SP-MATC-002) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003)(0068-SP-MATC-003) + - If there is no match the order will be cancelled. (0068-MATC-004)(0068-SP-MATC-004) + - If there is a partial match then the remaining will be cancelled. (0068-MATC-005)(0068-SP-MATC-005) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057)(0068-SP-MATC-057) - For Reduce-Only = True orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-056) @@ -27,12 +27,12 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008)(0068-SP-MATC-008) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will either be: - - Fully matched if possible to the other side of the book (0068-MATC-009) - - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) + - Fully matched if possible to the other side of the book (0068-MATC-009)(0068-SP-MATC-009) + - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010)(0068-SP-MATC-010) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039)(0068-SP-MATC-039) - For Reduce-Only = TRUE orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) @@ -45,48 +45,48 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013)(0068-SP-MATC-013) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014)(0068-SP-MATC-014) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced and placed on the book if the price is valid, except GFN which are rejected by the wallet validation layer. (0068-MATC-015) - otherwise they are parked. (0068-MATC-016) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040) - - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041) - - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040)(0068-SP-MATC-040) + - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041)(0068-SP-MATC-041) + - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042)(0068-SP-MATC-042) - A market will enter auction if the volume on either side of the book is empty. (0068-MATC-017) -- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018) -- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019) +- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018)(0068-SP-MATC-018) +- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019)(0068-SP-MATC-019) - All orders with Reduce-Only set to TRUE are rejected as invalid. (0068-MATC-054) In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): - [IOC/FOK/GFN](./0014-ORDT-order_types.md#time-in-force--validity) - - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021) + - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021)(0068-SP-MATC-021) - [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022) - - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023) - - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055) - - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) + - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022)(0068-SP-MATC-022) + - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023)(0068-SP-MATC-023) + - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055)(0068-SP-MATC-055) + - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024)(0068-SP-MATC-024) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are parked (and have their status set to PARKED). (0068-MATC-025) - - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038) + - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038)(0068-SP-MATC-038) When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): - All [PEGGED](./0014-ORDT-order_types.md#auction) orders are parked (and have their status set to PARKED). (0068-MATC-026) -- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) -- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) +- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027)(0068SP--MATC-027) +- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028)(0068-SP-MATC-028) When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auction-mode): -- The book is uncrossed. (0068-MATC-029) - - Self trading is allowed during uncrossing. (0068-MATC-030) -- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) +- The book is uncrossed. (0068-MATC-029)(0068-SP-MATC-029) + - Self trading is allowed during uncrossing. (0068-MATC-030)(0068-SP-MATC-030) +- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031)(0068-SP-MATC-031) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced where possible. (0068-MATC-032) -- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033) -- The price of any persistent order can be updated (0068-MATC-034) -- The size of any persistent order can be updated (0068-MATC-035) -- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036) -- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037) +- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033)(0068-SP-MATC-033) +- The price of any persistent order can be updated (0068-MATC-034)(0068-SP-MATC-034) +- The size of any persistent order can be updated (0068-MATC-035)(0068-SP-MATC-035) +- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036)(0068-SP-MATC-036) +- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037)(0068-SP-MATC-037) ## Summary From 581149b4fde50ef1f4c10c46c4c48e5d35037432 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 30 Jun 2023 10:18:30 +0100 Subject: [PATCH 213/649] feat: add ACs for 0069/70 --- .../0069-VCBS-validators_chosen_by_stake.md | 173 +++++++++--------- protocol/0070-MKTD-market-decimal-places.md | 16 +- 2 files changed, 94 insertions(+), 95 deletions(-) diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 5a2e72185..76d4981ed 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -161,7 +161,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). ## Acceptance criteria -### Joining / leaving VEGA chain (0069-VCBS-001) +### Joining / leaving VEGA chain (0069-VCBS-001)(0069-SP-VCBS-001) 1. A running Vega node which isn't a "pending" or "ersatz" or "validator" node already can submit a transaction to become a validator. 2. Their performance score will be calculated. See [performance score](./0064-VALP-validator_performance_based_rewards.md). @@ -174,20 +174,20 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). **Setup a network for each test** with 5 Tendermint validators and 2 ersatz validators. Verify the value of the min.validators network parameter is 5. Delegate 1000 tokens to each Tendermint validator and 500 to each ersatz validator (where minimum is defined as 500). Transfer 1000 tokens to the reward account. The test assumes that the validators are already in their state (i.e. 5 are Tendermint, 2 are ersatz). -1. Base case for Tendermint validators (0069-VCBS-005): +1. Base case for Tendermint validators (0069-VCBS-005)(0069-SP-VCBS-005): - Verify that the `stakeScore` for each of the Tendermint validators is 0.2 -1. Base case for ersatz validators (0069-VCBS-006): +1. Base case for ersatz validators (0069-VCBS-006)(0069-SP-VCBS-006): - Verify that the `stakeScore` for each of the ersatz validator is 0.5 -1. No antiwhaling for ersatz `stakeScore` (0069-VCBS-007): +1. No antiwhaling for ersatz `stakeScore` (0069-VCBS-007)(0069-SP-VCBS-007): - Delegate to one of the ersatz validators 4000 more tokens. - Run for an epoch with the new delegation (i.e. one ersatz with 500 one with 4500) and transfer 1000 tokens to the reward account. - Verify that at the end of the epoch the stake score of the validator with 4500 tokens is 0.9 and the one with 500 tokens is 0.1 -1. Antiwhaling for Tendermint validators (0069-VCBS-008): +1. Antiwhaling for Tendermint validators (0069-VCBS-008)(0069-SP-VCBS-008): - **Additional setup:** in addition to the 1000 delegated for each node, delegate 500 more to node 1. - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.competitionLevel` is set to 1 - Once it becomes active let it run for a full epoch during which transfer 1000 tokens to the reward account. - Verify that at the end of the epoch node 1 should have a stake score of 0.2 where all other nodes get stake score of 0.1818181818 -1. Full antiwhaling for Tendermint validators (0069-VCBS-009): +1. Full antiwhaling for Tendermint validators (0069-VCBS-009)(0069-SP-VCBS-009): - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.optimalStakeMultiplier` is set to 3 - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.competitionLevel` is set to 1 - **Additional setup:** in addition to the 1000 tokens delegated to each node, delegate 10000 tokens to node1 to get a total delegation of 11000 to it. @@ -196,20 +196,20 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). #### Multisig score -1. Verify that for all ersatz validators their multisig score is 1 (0069-VCBS-010) -1. Tendermint validators excess signature (0069-VCBS-011): +1. Verify that for all ersatz validators their multisig score is 1 (0069-VCBS-010)(0069-SP-VCBS-010) +1. Tendermint validators excess signature (0069-VCBS-011)(0069-SP-VCBS-011): - Setup a network with 5 Tendermint validators but with only 4 validators that have sufficient self-delegation. Call the one without enough self-delegation Bob. - Announce a new node (Alice) and self-delegate to them, allow some time to replace the validator with no self-delegation (Bob) as a Tendermint validator by Alice. Note: At this point the signature of Bob IS still on the multisig contract. - Transfer 1000 tokens to the VEGA reward account. - Verify that at the end of the epoch all of the Tendermint validators should have a multisig score = 0 since Bob is still on the contract. -1. Tendermint validators missing signature test 1 (0069-VCBS-012): +1. Tendermint validators missing signature test 1 (0069-VCBS-012)(0069-SP-VCBS-012): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners` is set to **5**. - Announce a new node and self-delegate to it 1000 tokens. - Allow some time for the performance score to be greater than 0. Note: When this happens the validator will be promoted to Tendermint validator at the beginning of the following epoch. - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Verify that the joining validator has a multisig score of 0 and therefore would not get a reward. -1. Tendermint validators missing signature test 2 (0069-VCBS-013): +1. Tendermint validators missing signature test 2 (0069-VCBS-013)(0069-SP-VCBS-013): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners` is set to 4. - Announce a new node and self-delegate to it 10000 tokens. @@ -217,7 +217,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Assert that the new validator has a score (stake score x performance score) in the top 4 - this can be verified in data node with: `rewardScore.stakeScore` x `rewardScore.performanceScore`. - Verify that the joining validator would have a multisig score of 0 and therefore would not get a reward. -1. Tendermint validators missing signature test 3 (0069-VCBS-050): +1. Tendermint validators missing signature test 3 (0069-VCBS-050)(0069-SP-VCBS-050): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners`is set to 4. - Delegate 10000 to the existing validators (can be self or party delegation) @@ -227,50 +227,50 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Assert that the new validator has a score (stake score x performance score) **NOT** in the top 4 - this can be verified in data node with: `rewardScore.stakeScore` x `rewardScore.performanceScore`. - Verify that the joining validator would have a multisig score of 1 and therefore gets a reward. -1. One of the top validators is not registered with the multisig contract (0069-VCBS-051): +1. One of the top validators is not registered with the multisig contract (0069-VCBS-051)(0069-SP-VCBS-051): - Run a Vega network where a validator joins and gets a lot delegated in order for it to become one of the top `network.validators.multisig.numberOfSigners` - Ensure its ethereum key is **NOT** put on the multisig contract. - Verify the validator has 0 for their multisig score and receives no staking reward. #### Validator Score -1. Verify that the validator score is always equal to the `stakeScore` x `perfScore` x `multisigScore` when the validator is a Tendermint validator (0069-VCBS-014) -2. Verify that the validator score is always equal to the `stakeScore` x `perfScore` when the validator is an ersatz validator (0069-VCBS-015) +1. Verify that the validator score is always equal to the `stakeScore` x `perfScore` x `multisigScore` when the validator is a Tendermint validator (0069-VCBS-014)(0069-SP-VCBS-014) +2. Verify that the validator score is always equal to the `stakeScore` x `perfScore` when the validator is an ersatz validator (0069-VCBS-015)(0069-SP-VCBS-015) #### Normalised Score -1. The sum of normalised scores must always equal 1 (0069-VCBS-016) -2. The normalised score for validator i must equal `validatorScore_{i}` / `total_validator_score`. Note: the total validator score is calculated over the relevant set separately (i.e. Tendermint and ersatz) (0069-VCBS-017) +1. The sum of normalised scores must always equal 1 (0069-VCBS-016)(0069-SP-VCBS-016) +2. The normalised score for validator i must equal `validatorScore_{i}` / `total_validator_score`. Note: the total validator score is calculated over the relevant set separately (i.e. Tendermint and ersatz) (0069-VCBS-017)(0069-SP-VCBS-017) ### Rewards split between tendermint and ersatz validators -1. Base scenario (0069-VCBS-018): +1. Base scenario (0069-VCBS-018)(0069-SP-VCBS-018): - There are no ersatz validators in the network. - Verify that, regardless of `ersatzRewardFactor` value, all rewards are being paid out to the validators as expected given the reward scores. -1. Ersatz validators where ersatz reward factor equals 0 (0069-VCBS-019): +1. Ersatz validators where ersatz reward factor equals 0 (0069-VCBS-019)(0069-SP-VCBS-019): - Ensure that the `ersatzRewardFactor` is set to 0 - Setup an ersatz validator with delegation greater than the minimum. The delegation can be equal to the delegation of the other Tendermint validators - Verify the ersatz validators and their delegators get no rewards. -1. Ersatz validators where reward factor equals 1 (0069-VCBS-020): +1. Ersatz validators where reward factor equals 1 (0069-VCBS-020)(0069-SP-VCBS-020): - Setup an ersatz validator with self and party delegation making them eligible for reward for a whole epoch. For example, such that the total delegation to each node is 1000 Vega. (3 Tendermint validators, 1 ersatz validator all having a delegation of 1000 Vega). - Make sure there is balance of 1000 Vega in the reward pool account for the epoch. - Verify the reward pool is distributed equally between the validators. -1. Ersatz validators where reward factor equals 0.5 (0069-VCBS-021): +1. Ersatz validators where reward factor equals 0.5 (0069-VCBS-021)(0069-SP-VCBS-021): - Setup an ersatz validator with self and party delegation making them eligible for reward for a whole epoch. For example, such that the total delegation to each node is 1000 Vega. (3 tendermint validators, 1 ersatz validator all having a delegation of 1000 Vega). - Make sure there is balance of 3500 Vega in the reward account for the epoch. - Verify that 3000 is distributed between the Tendermint validators and 500 is rewarded to the ersatz validator. -1. Multiple ersatz validators, reward factor equals 0.5 (0069-VCBS-022): +1. Multiple ersatz validators, reward factor equals 0.5 (0069-VCBS-022)(0069-SP-VCBS-022): - Setup a network with 3 ersatz validators, 3 Tendermint validators with arbitrary delegation, but ensuring the total delegation for each validator is greater than the minimum self-delegation. - With `total_delegations_from_all_validators = (0.5 * total_delegation_from_ersatz_validators) + total_delegation_from_tendermint_validators` - Verify the total reward given to Tendermint validators is equal to the `total_delegation_from_tendermint_validators * reward_balance` / `total_delegation_from_all_validators`. - Verify the total reward given to ersatz validators is equal to the `total_delegation_from_ersatz_validators * 0.5 * reward_balance / total_delegation_from_all_validators`. -1. Pending validators get nothing (0069-VCBS-023): +1. Pending validators get nothing (0069-VCBS-023)(0069-SP-VCBS-023): - Setup a network with 5 tendermint validators, set number of ersatz validators (through network parameter) to 0. - Delegate to each node 1000 tokens (including self-delegation). - Announce 2 new nodes, verify that they are in pending state, delegate to them 1000 tokens each. - Run the network for a full epoch with the delegation, during which transfer 1000 tokens to the reward account. - Verify that, at the end of the epoch, none of the pending validators receive a reward. -1. Pending validators do not get promoted (0069-VCBS-024): +1. Pending validators do not get promoted (0069-VCBS-024)(0069-SP-VCBS-024): - Setup a network with 5 tendermint validators, 2 ersatz validators and set number of ersatz validators (through factor) to 2. - Delegate to each node 1000 tokens (including self-delegation). - Announce 2 new nodes, verify that they are in pending state, delegate to them 1000 tokens each. @@ -281,47 +281,47 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). #### General -1. Verify that at the beginning of epoch an event is emitted for every validator known to Vega with their respective ranking scores. (0069-VCBS-025) -1. Verify the ranking score is available through the epoch/validator/`rankingScore` API in the data-node. (0069-VCBS-026) -1. Verify that the `rankingScore` is always equal to `performanceScore` x `stakeScore` x `incumbentBonus` (for tendermint validators and ersatz validators) Note: `network.validators.incumbentBonus` is a network parameter that is applied as a factor (1 + `incumbentBonus` network parameter) on `performanceScore` x `stakeScore`. (0069-VCBS-027) -1. Verify that if a node has a 0 `rankingScore` for 1e6 blocks (corresponding to around 11.5 days) it gets removed from the network and will have to be re-announced. (0069-VCBS-028) +1. Verify that at the beginning of epoch an event is emitted for every validator known to Vega with their respective ranking scores. (0069-VCBS-025)(0069-SP-VCBS-025) +1. Verify the ranking score is available through the epoch/validator/`rankingScore` API in the data-node. (0069-VCBS-026)(0069-SP-VCBS-026) +1. Verify that the `rankingScore` is always equal to `performanceScore` x `stakeScore` x `incumbentBonus` (for tendermint validators and ersatz validators) Note: `network.validators.incumbentBonus` is a network parameter that is applied as a factor (1 + `incumbentBonus` network parameter) on `performanceScore` x `stakeScore`. (0069-VCBS-027)(0069-SP-VCBS-027) +1. Verify that if a node has a 0 `rankingScore` for 1e6 blocks (corresponding to around 11.5 days) it gets removed from the network and will have to be re-announced. (0069-VCBS-028)(0069-SP-VCBS-028) ### Stake scores -1. No stake (0069-VCBS-029): +1. No stake (0069-VCBS-029)(0069-SP-VCBS-029): - Setup a network with 5 validators with no delegation - Verify that the `stakeScore` for all of validators is 0 -1. Equal stake (0069-VCBS-030): +1. Equal stake (0069-VCBS-030)(0069-SP-VCBS-030): - Setup a network with 5 validators, delegate to each of validator an equal stake - Verify that the `stakeScore` of each of them is 0.2. -1. Stake change (0069-VCBS-031): +1. Stake change (0069-VCBS-031)(0069-SP-VCBS-031): - Setup a network with 5 validators with 1000 tokens delegated to each. - Verify `stakeScore` at the end of the epoch is 0.2. - Change the stake of each validator by adding 100 * the index of the validator (i=1..5). - Verify that at the end of the epoch the `stakeScore` of each validator equals (1000 + i * 100)/5500 -1. Stake change 2 (0069-VCBS-032): +1. Stake change 2 (0069-VCBS-032)(0069-SP-VCBS-032): - Setup a network with 5 validators with 1000 tokens delegated to each - Undelegate from one validator 1000 tokens. - Verify that, at the end of the epoch, each of the 4 validators with tokens still delegated has a `stakeScore` of 0.25 and the validator with no tokens delegated has a 0 `stakeScore`. -1. Node joining (0069-VCBS-033): +1. Node joining (0069-VCBS-033)(0069-SP-VCBS-033): - Setup a network with 4 validators, each with 1000 tokens delegated. - Announce a new node and delegate it 1000 tokens - Verify that the `stakeScore` of all nodes is 0.2 at the beginning of the next epoch. Note: for the first 4 validators this is changing from 0.25 in the previous epoch to 0.2 in the next. ## Promotions/Demotions -1. Announce node (0069-VCBS-034): +1. Announce node (0069-VCBS-034)(0069-SP-VCBS-034): - Verify that a node node, once added successfully to the topology, is shown on data-node API with the status pending -1. Promote a node to become an ersatz validator (0069-VCBS-035): +1. Promote a node to become an ersatz validator (0069-VCBS-035)(0069-SP-VCBS-035): - Set up a network with no existing ersatz validators - Ensure that the number of ersatz validators allowed in the network is is greater than 0 using the network parameter `network.validators.ersatz.multipleOfTendermintValidators` - Announce a new node on the network - Verify the new node gets promoted to an ersatz validator Note: ensure there are no available slots for Tendermint validators so the new node doesn’t get promoted directly to become a Tendermint validator. -1. Demote a Tendermint validator due to lack of slots (0069-VCBS-036): +1. Demote a Tendermint validator due to lack of slots (0069-VCBS-036)(0069-SP-VCBS-036): - Setup a network with 4 Tendermint validators - Change the network parameter `network.validators.tendermint.number` to 3 Tendermint validators - Verify that the Tendermint validator with the lowest score is demoted to an ersatz validator at the beginning of the next epoch -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-062): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-062)(0069-SP-VCBS-062): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. @@ -332,20 +332,20 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that exactly one consensus forming validator with the lowest score is demoted to an ersatz validator at the beginning of the following epoch and we are running with 4 consensus (Tendermint) validators. - Ensure that the multisig is updated to those 4 validators. - Finally verify that exactly one consensus forming validator with the lowest score is demoted to an ersatz validator at the beginning of the following epoch and we are running with 3 consensus (Tendermint) validators. -1. Try to demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-063): +1. Try to demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-063)(0069-SP-VCBS-063): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. - Ensure that the threshold on the multisig is set to `900`. - Change the network parameter `network.validators.tendermint.number` to 3 Tendermint validators. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 6 consensus (Tendermint) validators. -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-064): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-064)(0069SP--VCBS-064): - Setup a network with 3 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 3 validators. - Ensure that the threshold on the multisig is set to `666`. - Change the network parameter `network.validators.tendermint.number` to 2 Tendermint validators. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 3 consensus (Tendermint) validators. -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-065): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-065)(0069-SP-VCBS-065): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. @@ -356,28 +356,28 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that exactly one consensus forming validator with the lowest score is demoted to an ersatz validator at the beginning of the following epoch and we are running with 4 consensus (Tendermint) validators. - Ensure that the multisig is *not* updated to those 4 validators, but we have the 5 validators from previous step. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 4 consensus (Tendermint) validators. -1. Demote an ersatz validator due to lack of slots (0069-VCBS-037): +1. Demote an ersatz validator due to lack of slots (0069-VCBS-037)(0069-SP-VCBS-037): - Setup a network with 4 tendermint validators, and 2 ersatz validators. - Change the ersatz network parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.25 of the Tendermint validators - Verify that the ersatz validator with the lowest score is demoted to pending at the beginning of the next epoch -1. Promotion a node to become a Tendermint validator (0069-VCBS-038): +1. Promotion a node to become a Tendermint validator (0069-VCBS-038)(0069-SP-VCBS-038): - Setup a network with 5 validators (and 5 slots for tendermint validators). - Do not self-delegate to them. - Announce a new node and self-delegate to them. - Verify that at the beginning of the next epoch one of the validators which were Tendermint validators before is chosen at random and is demoted to ersatz validator. - Verify the announced validator is promoted to be Tendermint validator with voting power = 10000. -1. Promotion + swap (0069-VCBS-039): +1. Promotion + swap (0069-VCBS-039)(0069-SP-VCBS-039): - Setup a network with 4 validators with self-delegation such that the number of Tendermint nodes (with the `network.validators.tendermint.number` parameter set to 5). - In the following epoch, remove the self-delegation from node 1, and announce 2 nodes. - During the epoch self-delegate to the two nodes. - Wait for 3 epochs to allow performance of the new nodes to be greater than 0. - Verify that, once the performance is greater than zero, the two nodes should be promoted to Tendermint validators and their voting power should be equal to their relative stake x their performance score x 10000. -1. Swap last due to performance (0069-VCBS-040): +1. Swap last due to performance (0069-VCBS-040)(0069-SP-VCBS-040): - Setup a network with 5 validators with self-delegation. - Announce a new node and self-delegate to it. - Once it gets to a performance score of 0.2, shut down two of the 5 Tendermint validators after 0.1 of the duration of the epoch, e.g. if the epoch is 5 minutes, that means after 30 seconds of the epoch they should be stopped. - Verify that at the beginning of the next epoch, expect the performance score of the two stopped validators is <= 0.1, and one of them chosen at random is demoted to ersatz validator and is replaced by the announced nodes as a Tendermint validator with voting power =~ 0.2 * `stake_of_validator` / `total_stake_network` -1. Number of slots increased (0069-VCBS-041): +1. Number of slots increased (0069-VCBS-041)(0069-SP-VCBS-041): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Announce a new node, DO NOT self-delegate to it. - Run for an epoch and assert the validator is shown as pending. @@ -385,7 +385,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that at the beginning of the next epoch the pending validator is still pending as their performance score is 0 (no self-stake). - Self-delegate to the pending validator - Verify that at the end of the epoch they are promoted to Tendermint validator. -1. Swap due to better score (0069-VCBS-042): +1. Swap due to better score (0069-VCBS-042)(0069-SP-VCBS-042): - Setup a network with 5 Tendermint validators and self-delegate 1000 tokens to each of them. - Announce a new node at the beginning of the epoch, self-delegate to them a total that is 10000 tokens. - At the beginning of the next epoch the new validator should have ranking score *equal or lower* to all of the Tendermint validators so it doesn’t get promoted. The parameter is set sufficiently high to assure this (e.g., 1.1). @@ -393,7 +393,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that at the beginning of the next epoch the announced node replaced node 1 as a Tendermint validator. - Restart node 1 again from a snapshot - Verify that node 1 is in a pending state. -1. 2 empty spots, only one available to replace (0069-VCBS-043): +1. 2 empty spots, only one available to replace (0069-VCBS-043)(0069-SP-VCBS-043): - Setup a network with 5 slots for Tendermint validators and 3 actual Tendermint validators. - Self-delegate to all of them. - Announce 2 new nodes but self-delegate only to one of them. @@ -401,7 +401,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). ### `Ownstake` Scenarios -1. `Ownstake` scenario1 (0069-VCBS-053) +1. `Ownstake` scenario1 (0069-VCBS-053)(0069-SP-VCBS-053) - Network with 3 tendermint validators and 7 ersatz validators - In the same epoch, change the network parameter `reward.staking.delegation.minimumValidatorStake` in a way that 3 tendermint validators and 3 ersatz validators drop below the `ownstake` requirement, and change the delegation so that 4 (not affected) Ersatz validators have a higher score than two (not affected) Validators. Also, give one of the Ersatz validators with insufficient `ownstake` the highest stake (delegated) of all Ersatz validators. - At the end of the epoch all validators with insufficient own stake will get a ranking score of 0. @@ -409,7 +409,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - The 3 tendermint validators would be swapped with the top 3 ersatz validators over the following 3 epochs - Also verify that the ersatz validator with the insufficient own but the most delegated stake has a ranking score of 0 and doesn't get promoted. - No validator with stake attached to them is ever completely removed -1. `Ownstake` scenario2 (0069-VCBS-073) +1. `Ownstake` scenario2 (0069-VCBS-073)(0069-SP-VCBS-073) Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -417,7 +417,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 1 ersatz validator has 6000 stake and sufficient `ownstake` - the pending validator has sufficient `ownstake` - Verify that the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. -1. `Ownstake` scenario3 (0069-VCBS-074) +1. `Ownstake` scenario3 (0069-VCBS-074)(0069-SP-VCBS-074) 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -425,7 +425,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. -1. `Ownstake` scenario4 (0069-VCBS-075) +1. `Ownstake` scenario4 (0069-VCBS-075)(0069-SP-VCBS-075) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -433,7 +433,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. -1. `Ownstake` scenario5 (0069-VCBS-076) +1. `Ownstake` scenario5 (0069-VCBS-076)(0069-SP-VCBS-076) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -443,13 +443,13 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. -1. `Ownstake` scenario6 (0069-VCBS-077) +1. `Ownstake` scenario6 (0069-VCBS-077)(0069-SP-VCBS-077) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators - Verify that one validator is replaced the following epoch, one in the epoch after -1. `Ownstake` scenario7 (0069-VCBS-078) +1. `Ownstake` scenario7 (0069-VCBS-078)(0069-SP-VCBS-078) -Verify that 2 validators are replaced, one in each epoch 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` @@ -458,7 +458,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Ersatz Rewards -1. Ersatz validator reward (0069-VCBS-061) +1. Ersatz validator reward (0069-VCBS-061)(0069-SP-VCBS-061) - Setup a network with 5 validators with the following distribution of delegation: - 10%, 10%, 10%, 10%. 60% of the total delegation of tendermint validators - Setup 5 ersatz validators each with the minimum delegation at the end of the epoch verify that the stake score of the validator with 60% of the delegation (under reward) is anti-whaled @@ -468,7 +468,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled -1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) +1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057)(0069-SP-VCBS-057) - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 - Verify that at the end of the Epoch, the Ersatz Validators get no reward - Increase the `rewardFactor` to 0.5 @@ -480,19 +480,19 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Slot Adjustments -1. Number of slots decreased (0069-VCBS-052): +1. Number of slots decreased (0069-VCBS-052)(0069-SP-VCBS-052): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Decrease the number of tendermint validators to 3. - Verify that in each of the following two epochs, the validator with the lowest score is demoted to Ersatz validator and an Ersatz validator is demoted to pending -1. Number of Ersatz validators increased (0069-VCBS-058): +1. Number of Ersatz validators increased (0069-VCBS-058)(0069-SP-VCBS-058): - Setup a network with 4 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.9 - Verify that in the following epoch, the Ersatz Validator with the highest score is promoted to Validator -1. Number of Ersatz validators decreased (0069-VCBS-054): +1. Number of Ersatz validators decreased (0069-VCBS-054)(0069-SP-VCBS-054): - Setup a network with 5 Tendermint validators, 3 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5) - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.1 - Verify that in the following to epoch, all the Ersatz Validators are demoted to pending -1. Number of Ersatz validators Erratic (0069-VCBS-055): +1. Number of Ersatz validators Erratic (0069-VCBS-055)(0069-SP-VCBS-055): - Setup a network with 5 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.9 - Verify that in the next epoch the 2 pending validators are promoted to ersatz @@ -501,51 +501,51 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Two epochs later, change `network.validators.ersatz.multipleOfTendermintValidators` to 0.5 - Verify that in the next epoch the 2 pending validators are promoted to ersatz - Verify that in the last epoch, no demotions/promotions happen and the number of Ersatz validators stays at 2 -1. Number of Ersatz Validators oddly defined (0069-VCBS-056)d +1. Number of Ersatz Validators oddly defined (0069-VCBS-056)(0069-SP-VCBS-056) - Set the factor to 0.00000000000000000000000000000000000000001 - Verify that all Validators round it the same way, and that there are no Ersatz validators - Set the factor to 3.00000000000000000000000000000000000000001 and run the network with just one tendermint (consensus) validator. - Verify that all Validators round it the same way, and that there are three Ersatz validators -1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) -1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070). Restart from checkpoint ((0069-VCBS-080)), all validator nodes are still correct. -1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) +1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069)(0069-SP-VCBS-069) +1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070)(0069-VCBS-070). Restart from checkpoint ((0069-VCBS-080)(0069-SP-VCBS-080)), all validator nodes are still correct. +1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072)(0069-SP-VCBS-072) ### Announce Node -1. Invalid announce node command (0069-VCBS-044): +1. Invalid announce node command (0069-VCBS-044)(0069-SP-VCBS-044): - Send an announce node command from a non validator node should fail -1. Valid announce node command (0069-VCBS-045): +1. Valid announce node command (0069-VCBS-045)(0069-SP-VCBS-045): - Send a valid announce node from a validator node should result in a validator update event with the details of the validator and a validator ranking event. -1. Node announces using same keys as existing node via announce node command (0069-VCBS-060): +1. Node announces using same keys as existing node via announce node command (0069-VCBS-060)(0069-SP-VCBS-060): - Should be rejected ### Checkpoints -1. Base case (0069-VCBS-046): +1. Base case (0069-VCBS-046)(0069-SP-VCBS-046): - Setup a network with 5 Tendermint validators - Take a checkpoint - Restore from checkpoint with the 5 same validators, which should pass. - Verify that after the network is restarted, the validators have voting power as per the checkpoint until the end of the epoch. -1. Base + ersatz (0069-VCBS-047): +1. Base + ersatz (0069-VCBS-047)(0069-SP-VCBS-047): - Setup a network with 5 Tendermint validators (where 5 is also the number of allowed Tendermint validators) - Announce 2 new nodes and wait for them to become ersatz validators (set the network parameter `network.validators.minimumEthereumEventsForNewValidator` to 0). - Take a checkpoint and verify it includes the ersatz validators. - Restore from the checkpoint (all nodes are running) - Verify that the validators have the voting power as per the checkpoint and that the ersatz validators are shown on data node having status ersatz. -1. Missing validators (0069-VCBS-048): +1. Missing validators (0069-VCBS-048)(0069-SP-VCBS-048): - Setup a network with 5 validators such that 3 of them have 70% of the voting power. Note: this is done by delegating 70% of the total stake to them. - Take a checkpoint - Restore from the checkpoint – starting only the 3 nodes with the 70% stake. - Verify that after the restore the network should be able to proceed generating blocks although with slower pace. -1. Missing validators stop the network (0069-VCBS-049): +1. Missing validators stop the network (0069-VCBS-049)(0069-SP-VCBS-049): - Setup a network with 5 validators with equal delegation to them. - Verify before the checkpoint that the voting power of all of them is equal. - Take a checkpoint. - Restart the network starting only 3 of the validators. - Restore from the checkpoint. - Verify the network is not able to produce blocks. -1. Checkpoints store validator changes (0069-VCBS-079): +1. Checkpoints store validator changes (0069-VCBS-079)(0069-SP-VCBS-079): - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). - Stop and relegate one of the original validators (v1) such that v6 is promoted to tendermint validator, and v7 is promoted to ersatz. - Restart v1 and announce to pending. @@ -553,7 +553,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the network - Verify that v2-v6 are tendermint validators, v7 is ersatz and v1 is pending. - Verify that all stakes and delegations are correct for each node. -1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088): +1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088)(0069-SP-VCBS-088): - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). - Take a checkpoint. - Wait until the current epoch will have expired. @@ -564,45 +564,44 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Multisig update -1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002) -1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003) -1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004) -1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) +1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002)(0069-SP-COSMICELEVATOR-002) +1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003)(0069-SP-COSMICELEVATOR-003) +1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004)(0069-SP-COSMICELEVATOR-004) +1. Can update multisig for new validator, and expect rewards (0069-VCBS-066)(0069-SP-VCBS-066) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) +1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067)(0069-SP-VCBS-067) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) -1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068)(0069-SP-VCBS-068) +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071)(0069-SP-VCBS-071) ### Re-Issuing Signature Bundles by non Validators 1. Submit two `IssueSignature` requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the result is the same. -(0069-VCBS-081) +(0069-VCBS-081)(0069-SP-VCBS-081) 1. Submit two `IssueSignature` requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. -(0069-VCBS-082) +(0069-VCBS-082)(0069-SP-VCBS-082) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. -(0069-VCBS-083) +(0069-VCBS-083)(0069-SP-VCBS-083) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys in different blocks. Verify that both get executed. -(0069-VCBS-084) +(0069-VCBS-084)(0069-SP-VCBS-084) 1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 `IssueSignature` requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one `IssueSignature` request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. -(0069-VCBS-085) +(0069-VCBS-085)(0069-SP-VCBS-085) 1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. -(0069-VCBS-086) +(0069-VCBS-086)(0069-SP-VCBS-086) 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. -(0069-VCBS-087) +(0069-VCBS-087)(0069-SP-VCBS-087) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index ce3083e23..dc2e43e33 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,11 +70,11 @@ Trades of course result in transfers. The amounts transferred (for the trade as ## Acceptance criteria - As a user, I can propose a market with a different precision than its settlement asset - - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001) - - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002) -- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003) -- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004) -- As a user I should see the market data prices using market precision. (0070-MKTD-005) -- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006) -- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007) -- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008) + - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001)(0070-SP-MKTD-001) + - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002)(0070-SP-MKTD-002) +- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003)(0070-SP-MKTD-003) +- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004)(0070-SP-MKTD-004) +- As a user I should see the market data prices using market precision. (0070-MKTD-005)(0070-SP-MKTD-005) +- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006)(0070-SP-MKTD-006) +- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007)(0070-SP-MKTD-007) +- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008)( 0070-SP-MKTD-008) From b7387740c509c045eac0ce742fc29525b8ca54a6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 30 Jun 2023 11:00:00 +0100 Subject: [PATCH 214/649] feat: add ACs for 0071/72/73/74/75/76/77 --- ...071-STAK-erc20_governance_token_staking.md | 24 ++-- protocol/0072-SPPW-spam-protection-PoW.md | 38 +++---- protocol/0073-LIMN-limited_network_life.md | 93 ++++++++-------- .../0074-BTCH-batch-market-instructions.md | 20 ++-- protocol/0075-PLUP-protocol_upgrades.md | 104 +++++++++--------- protocol/0076-DANO-data-node.md | 76 ++++++------- protocol/0077-SNAP-snapshots.md | 12 +- .../0079-TGAP-transaction_gas_and_priority.md | 6 +- 8 files changed, 187 insertions(+), 186 deletions(-) diff --git a/protocol/0071-STAK-erc20_governance_token_staking.md b/protocol/0071-STAK-erc20_governance_token_staking.md index 836b8caa6..394b3ad56 100644 --- a/protocol/0071-STAK-erc20_governance_token_staking.md +++ b/protocol/0071-STAK-erc20_governance_token_staking.md @@ -96,21 +96,21 @@ Other functionality: ### Staking Bridge Smart Contract -- Staking Bridge accepts and locks deposited VEGA tokens and emits `Stake_Deposited` event (0071-STAK-001) -- Staking Bridge allows only stakers to remove their staked tokens and emits `Stake_Removed` event (0071-STAK-002) -- Staking Bridge allows users with staked balance to transfer ownership of stake to new ethereum address that only the new address can remove (0071-STAK-003) -- Staking Bridge prohibits users from removing stake they don't own (0071-STAK-012) -- Staking Bridge prohibits users from removing stake they have transferred to other ETH address (0071-STAK-013) +- Staking Bridge accepts and locks deposited VEGA tokens and emits `Stake_Deposited` event (0071-STAK-001)(0071-SP-STAK-001) +- Staking Bridge allows only stakers to remove their staked tokens and emits `Stake_Removed` event (0071-STAK-002)(0071-SP-STAK-002) +- Staking Bridge allows users with staked balance to transfer ownership of stake to new ethereum address that only the new address can remove (0071-STAK-003)(0071-SP-STAK-003) +- Staking Bridge prohibits users from removing stake they don't own (0071-STAK-012)(0071-SP-STAK-012) +- Staking Bridge prohibits users from removing stake they have transferred to other ETH address (0071-STAK-013)(0071-SP-STAK-013) ### Vesting Smart Contract -- Vesting Contract locks vesting VEGA tokens and emits `Stake_Deposited` event (0071-STAK-005) -- Vesting Contract unlocks vesting VEGA tokens and emits `Stake_Removed` event (0071-STAK-006) -- Vesting Contract prohibits withdrawal of VEGA while that VEGA is staked (0071-STAK-007) +- Vesting Contract locks vesting VEGA tokens and emits `Stake_Deposited` event (0071-STAK-005)(0071-SP-STAK-005) +- Vesting Contract unlocks vesting VEGA tokens and emits `Stake_Removed` event (0071-STAK-006)(0071-SP-STAK-006) +- Vesting Contract prohibits withdrawal of VEGA while that VEGA is staked (0071-STAK-007)(0071-SP-STAK-007) ### Event Queue -- Event Queue sees `Stake_Deposited` event from Staking Bridge smart contract and credits target Vega user with stake (0071-STAK-008) -- Event Queue sees `Stake_Removed` event from Staking Bridge smart contract and removes stake from appropriate Vega user (0071-STAK-009) -- Event Queue sees `Stake_Deposited` event from Vesting smart contract and credits target Vega user with stake (0071-STAK-010) -- Event Queue sees `Stake_Removed` event from Vesting smart contract and removes stake from appropriate Vega user (0071-STAK-011) +- Event Queue sees `Stake_Deposited` event from Staking Bridge smart contract and credits target Vega user with stake (0071-STAK-008)(0071-SP-STAK-008) +- Event Queue sees `Stake_Removed` event from Staking Bridge smart contract and removes stake from appropriate Vega user (0071-STAK-009)(0071-SP-STAK-009) +- Event Queue sees `Stake_Deposited` event from Vesting smart contract and credits target Vega user with stake (0071-STAK-010)(0071-SP-STAK-010) +- Event Queue sees `Stake_Removed` event from Vesting smart contract and removes stake from appropriate Vega user (0071-STAK-011)(0071-SP-STAK-011) diff --git a/protocol/0072-SPPW-spam-protection-PoW.md b/protocol/0072-SPPW-spam-protection-PoW.md index 001cb67d8..eca8914e4 100644 --- a/protocol/0072-SPPW-spam-protection-PoW.md +++ b/protocol/0072-SPPW-spam-protection-PoW.md @@ -87,44 +87,44 @@ All Vega clients that submitted transactions can verify that their transaction h ## Acceptance Criteria -- A message with a missing/wrong PoW is rejected (0072-SPPW-001) -- Reusing the same PoW for several messages is detected and the messages are rejected (0072-SPPW-002) -- Linking too many transactions to the same block is detected and leads to a blocking of that account (if the increasing difficulty is turned off) (0072-SPPW-003) -- Linking too many transactions with a low difficulty level to a block is detected and leads to blocking of the account (if increasing difficulty is turned on) (0072-SPPW-004) -- Reusing a transaction identifier in a way that several transactions with the same ID end up in the same block is detected and the transactions are rejected (0072-SPPW-005) -- A blocked account is unblocked after the maximum of 1/48 of an Epoch or 30 seconds. For transactions sent in the meantime, a meaningful error message is returned. (0072-SPPW-006) -- PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-COSMICELEVATOR-007) -- For each transaction less than or equal to `spam.pow.numberOfTxPerBlock` in a block `spam.pow.difficulty` zeros are needed in the proof-of-work (0072-SPPW-008) -- For each `spam.pow.numberOfTxPerBlock` sized block of transactions greater than `spam.pow.numberOfTxPerBlock` an additional 0 is required in the proof-of-work (1 additional zero for the first batch, two additional for the second batch etc) (0072-SPPW-009) -- For a given block, a user is able to submit more than `spam.pow.numberOfTxPerBlock` transactions with only `spam.pow.difficulty` zeros by tying them to one or more historic blocks all of which are within `spam.pow.numberOfPastBlocks` blocks (0072-SPPW-010) -- Using a block older than `spam.pow.numberOfPastBlocks` blocks prior to the current block is detected the transaction is rejected (0072-SPPW-011) +- A message with a missing/wrong PoW is rejected (0072-SPPW-001)(0072-SP-SPPW-001) +- Reusing the same PoW for several messages is detected and the messages are rejected (0072-SPPW-002)(0072-SP-SPPW-002) +- Linking too many transactions to the same block is detected and leads to a blocking of that account (if the increasing difficulty is turned off) (0072-SPPW-003)(0072-SP-SPPW-003) +- Linking too many transactions with a low difficulty level to a block is detected and leads to blocking of the account (if increasing difficulty is turned on) (0072-SPPW-004)(0072-SPPW-004) +- Reusing a transaction identifier in a way that several transactions with the same ID end up in the same block is detected and the transactions are rejected (0072-SPPW-005)(0072-SPPW-005) +- A blocked account is unblocked after the maximum of 1/48 of an Epoch or 30 seconds. For transactions sent in the meantime, a meaningful error message is returned. (0072-SPPW-006)(0072-SPPW-006) +- PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-COSMICELEVATOR-007)(0072-SP-COSMICELEVATOR-007) +- For each transaction less than or equal to `spam.pow.numberOfTxPerBlock` in a block `spam.pow.difficulty` zeros are needed in the proof-of-work (0072-SPPW-008)(0072-SP-SPPW-008) +- For each `spam.pow.numberOfTxPerBlock` sized block of transactions greater than `spam.pow.numberOfTxPerBlock` an additional 0 is required in the proof-of-work (1 additional zero for the first batch, two additional for the second batch etc) (0072-SPPW-009)(0072-SP-SPPW-009) +- For a given block, a user is able to submit more than `spam.pow.numberOfTxPerBlock` transactions with only `spam.pow.difficulty` zeros by tying them to one or more historic blocks all of which are within `spam.pow.numberOfPastBlocks` blocks (0072-SPPW-010)(0072-SP-SPPW-010) +- Using a block older than `spam.pow.numberOfPastBlocks` blocks prior to the current block is detected the transaction is rejected (0072-SPPW-011)(0072-SP-SPPW-011) - The parameter `spam.pow.difficulty` is increased. Verify that - Transactions tied to such a block using the original difficulty are rejected with an error message. - - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-008) + - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-008)(0072-SP-COSMICELEVATOR-008) - The parameter `spam.pow.difficulty` is decreased. Verify that - Transactions tied to such a block using the new difficulty are not rejected. - - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-009) + - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-009)(0072-SP-COSMICELEVATOR-009) - The parameter `spam.pow.increaseDifficulty` is changed from 0 to 1. Verify that - - Transactions tied to such a block using insufficient difficulty due to the new parameter are rejected with an error message. (0072-COSMICELEVATOR-010) + - Transactions tied to such a block using insufficient difficulty due to the new parameter are rejected with an error message. (0072-COSMICELEVATOR-010)(0072-SP-COSMICELEVATOR-010) - The parameter `spam.pow.increaseDifficulty` is changed from 1 to 0. Verify that - - Transactions tied to such a block using the base difficulty are not rejected. (0072-COSMICELEVATOR-011) + - Transactions tied to such a block using the base difficulty are not rejected. (0072-COSMICELEVATOR-011)(0072-SP-COSMICELEVATOR-011) - The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that - - The new parameter is used for all blocks with a block height higher than the current one, i.e., a number of transactions that was allowed before and is no longer due to the new parameter is rejected (leaving the spam difficulty level constant) (0072-COSMICELEVATOR-012) + - The new parameter is used for all blocks with a block height higher than the current one, i.e., a number of transactions that was allowed before and is no longer due to the new parameter is rejected (leaving the spam difficulty level constant) (0072-COSMICELEVATOR-012)(0072-SP-COSMICELEVATOR-012) - The parameter `spam.pow.numberofTxPerBlock` is increased. Verify that - - If a number of transactions is submitted with the lower lever PoW that would have exceeded the `spam.pow.numberOfTXPerBlock` before the change and not after, no transaction is rejected. (0072-COSMICELEVATOR-013) + - If a number of transactions is submitted with the lower lever PoW that would have exceeded the `spam.pow.numberOfTXPerBlock` before the change and not after, no transaction is rejected. (0072-COSMICELEVATOR-013)(0072-SP-COSMICELEVATOR-013) - Repeat tests 008-013, where in the same block, - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. - - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-COSMICELEVATOR-014) + - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-COSMICELEVATOR-014)(0072-SP-COSMICELEVATOR-014) -- *Mempool pruning* Cause congestion in the mempool by submitting many transactions (perhaps from several parties). Submit a transaction `T` tied to block number `N_old`. Make sure the transactions causing congestion create sufficiently large `N_current`. At some point we'll have `N_old + spam.pow.numberOfPastBlocks < N_current` and the transaction `T` is removed from the mempool and never scheduled. (0072-SPPW-012) +- *Mempool pruning* Cause congestion in the mempool by submitting many transactions (perhaps from several parties). Submit a transaction `T` tied to block number `N_old`. Make sure the transactions causing congestion create sufficiently large `N_current`. At some point we'll have `N_old + spam.pow.numberOfPastBlocks < N_current` and the transaction `T` is removed from the mempool and never scheduled. (0072-SPPW-012)(0072-SP-SPPW-012) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 7cf68d112..4fb5d8b54 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -102,12 +102,12 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ## Acceptance criteria -- Checkpoints are created every `network.checkpoint.timeElapsedBetweenCheckpoints` period of time passes. (0073-LIMN-001) -- Checkpoint is created every time a party requests a withdrawal transaction on any chain. (0073-LIMN-002) -- We can launch a network with any valid checkpoint file. (0073-LIMN-003) -- Hash of the checkpoint file is agreed via consensus. (0073-LIMN-005) +- Checkpoints are created every `network.checkpoint.timeElapsedBetweenCheckpoints` period of time passes. (0073-LIMN-001)(0073-SP-LIMN-001) +- Checkpoint is created every time a party requests a withdrawal transaction on any chain. (0073-LIMN-002)(0073-SP-LIMN-002) +- We can launch a network with any valid checkpoint file. (0073-LIMN-003)(0073-SP-LIMN-003) +- Hash of the checkpoint file is agreed via consensus. (0073-LIMN-005)(0073-SP-LIMN-005) -### Test case 1: Withdrawal status is correctly tracked across resets (0073-LIMN-007) +### Test case 1: Withdrawal status is correctly tracked across resets (0073-LIMN-007)(0073-SP-LIMN-007) 1. A party has general account balance of 100 USD. 1. The party submits a withdrawal transaction for 100 USD. A checkpoint is immediately created. @@ -118,7 +118,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - If the Ethereum replay hasn't seen withdrawal transaction processed and the expiry time of the withdrawal hasn't passed yet. Then the party has general account balance of 0 USD. The party has "signed for withdrawal" 100. - If the Ethereum replay hasn't seen withdrawal transaction processed and the expiry time of the withdrawal has passed. Then the party has general account balance of 100 USD. -### Test case 2: Orders and positions are *not* maintained across resets, balances are and *accepted* markets are (0073-LIMN-008) +### Test case 2: Orders and positions are *not* maintained across resets, balances are and *accepted* markets are (0073-LIMN-008)(0073-SP-LIMN-008) 1. There is an asset USD and no asset proposals. 1. There is a market `id_xxx` with status active, no other markets and no market proposals. @@ -140,7 +140,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ### Test case 3: Governance proposals are maintained across resets, votes are not -#### Test case 3.1: Market is proposed, accepted, restored (0073-LIMN-009) +#### Test case 3.1: Market is proposed, accepted, restored (0073-LIMN-009)(0073-SP-LIMN-009) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -158,7 +158,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. The LP party has general account balance in USD of `9000` and bond account balance `1000` on the market `id_xxx`. 1. The other party has no open orders anywhere and general account balance in USD of `other_gen_bal + other_margin_bal`. -#### Test case 3.2: Market is proposed, voting hasn't closed, not restored (0073-LIMN-010) +#### Test case 3.2: Market is proposed, voting hasn't closed, not restored (0073-LIMN-010)(0073-SP-LIMN-010) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -172,7 +172,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is an asset USD. 1. There is no market and there are no market proposals. -#### Test case 3.3: Market is proposed, voting has closed, market rejected, proposal not restored (0073-LIMN-011) +#### Test case 3.3: Market is proposed, voting has closed, market rejected, proposal not restored (0073-LIMN-011)(0073-SP-LIMN-011) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -188,6 +188,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. The LP party has general account balance in USD of `10 000`. #### Test case 3.4: Recovery from proposed Markets with no votes, voting is open, proposal not restored (0073-LIMN-012) +(0073-SP-LIMN-012) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -200,7 +201,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is no market and there are no market proposals. 1. The LP party has general account balance in USD of `10 000`. -#### Test case 3.5: Recovery from proposed Markets with votes, voting is open, proposal not restored (0073-LIMN-013) +#### Test case 3.5: Recovery from proposed Markets with votes, voting is open, proposal not restored (0073-LIMN-013)(0073-SP-LIMN-013) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -213,7 +214,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is no market and there are no market proposals. 1. The LP party has general account balance in USD of `10 000`. -#### Test case 3.6: Market proposals ignored when restoring twice from same checkpoint (0073-LIMN-014) +#### Test case 3.6: Market proposals ignored when restoring twice from same checkpoint (0073-LIMN-014)(0073-SP-LIMN-014) 1. A party has general account balance of 100 USD. 1. The party submits a withdrawal transaction for 100 USD. A checkpoint is immediately created. @@ -225,7 +226,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is no market and there are no market proposals. 1. The party has general account balance in USD of `0` and The party has "signed for withdrawal" `100`. -### Test case 4: Party's Margin Account balance is put in to a General Account balance for that asset after a reset (0073-LIMN-016) +### Test case 4: Party's Margin Account balance is put in to a General Account balance for that asset after a reset (0073-LIMN-016)(0073-SP-LIMN-016) 1. A party has USD general account balance of 100 USD. 2. That party has USD margin account balance of 100 USD. @@ -233,7 +234,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 4. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. 5. That party has a USD general account balance of 200 USD -### Test case 5: Add or remove stake during checkpoint restart (0073-LIMN-017) +### Test case 5: Add or remove stake during checkpoint restart (0073-LIMN-017)(0073-SP-LIMN-017) 1. There is a Vega token asset. 1. There are `5` validators on the network. @@ -260,7 +261,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 #### Test case 6.2: `timeElapsedBetweenCheckpoints` set to value outside acceptable range -### Test case 11: Rewards are distributed correctly every epoch including with the use of recurring transfers (0073-LIMN-022) +### Test case 11: Rewards are distributed correctly every epoch including with the use of recurring transfers (0073-LIMN-022)(0073-SP-LIMN-022) - More than one party deposits stake onto Vega - The parties delegate stake to the validators @@ -274,11 +275,11 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ### Test case 12 -1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023) -1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024) -1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025) -1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026) -1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027) +1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023)(0073-SP-LIMN-023) +1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024)(0073-SP-LIMN-024) +1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025)(0073-SP-LIMN-025) +1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026)(0073-SP-LIMN-026) +1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027)(0073-SP-LIMN-027) 1. Propose a valid ERC-20 asset. 1. Wait for the next checkpoint, then stop the network. @@ -290,7 +291,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Withdraw funds for one of the traders. 1. Propose an update to the asset, and ensure that you can update the ERC20 bridge with the asset update and signature bundle. -### Test case 13: A market with future enactment date can become enacted after being restored from checkpoint (0073-LIMN-028) +### Test case 13: A market with future enactment date can become enacted after being restored from checkpoint (0073-LIMN-028)(0073-SP-LIMN-028) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -315,23 +316,23 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Propose, enact, trade in the market, close out distressed party so that insurance pool balance > 0, submit trading terminated. 1. System saves LNL checkpoint at a time when undistributed LP fees for the market are > 0. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029) -1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030) -1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029)(0073-SP-LIMN-029) +1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030)(0073-SP-LIMN-030) +1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031)(0073-SP-LIMN-031) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032)(0073-SP-LIMN-032) +1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033)(0073-SP-LIMN-033) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034)(0073-SP-LIMN-034) ### Test case 15: Market with trading terminated that settled is not restored, collateral moved correctly 1. Propose, enact, trade in the market, submit trading terminated and settlement data, observe final settlement cashflows for at least 2 parties. 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040) -1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041) -1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040)(0073-SP-LIMN-040) +1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041)(0073-SP-LIMN-041) +1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042)(0073-SP-LIMN-042) +1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043)(0073-SP-LIMN-043) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044)(0073-SP-LIMN-044) ### Test case 16: Markets can be settled and terminated after restore as proposed @@ -339,20 +340,20 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. 1. A party submits liquidity provision to the market, orders are submitted to the opening auction to allow uncrossing; at least two parties now have a position. -1. Submit the trading terminated transaction and settlement date transaction as set out in the proposal and observe the final settlement cashflows for the parties with positions. (0073-LIMN-050) -1. It's not possible to submit orders or LP provisions to this market). (0073-LIMN-051) +1. Submit the trading terminated transaction and settlement date transaction as set out in the proposal and observe the final settlement cashflows for the parties with positions. (0073-LIMN-050)(0073-SP-LIMN-050) +1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051)(0073-SP-LIMN-051) ### Test case 17: Markets with internal time trigger for trading terminated that rings between shutdown and restore 1. Propose, enact a market with some trading terminated given by internal time trigger. Trade in the market creating positions for at least 2 parties. 1. System saves LNL checkpoint before the trading terminated trigger rings. 1. Restart Vega, load LNL checkpoint at a time which is after trading terminated trigger should have rung. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060); if it exists it in `cancelled` state. -1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061) -1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060)(0073-SP-LIMN-060); if it exists it in `cancelled` state. +1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061)(0073-SP-LIMN-061) +1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062)(0073-SP-LIMN-062) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063)(0073-SP-LIMN-063) +1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064)(0073-SP-LIMN-064) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065)(0073-SP-LIMN-065) ### Test case 18: market definition is the same pre and post LNL restore @@ -360,10 +361,10 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - System saves LNL checkpoint. - Restart Vega, load LNL checkpoint. - The market has the same: - - risk model and parameters (0073-LIMN-070) - - price monitoring bounds (0073-LIMN-071) - - oracle settings (0073-LIMN-072) - - margin scaling factors (0073-LIMN-073) + - risk model and parameters (0073-LIMN-070)(0073-SP-LIMN-070) + - price monitoring bounds (0073-LIMN-071)(0073-SP-LIMN-071) + - oracle settings (0073-LIMN-072)(0073-SP-LIMN-072) + - margin scaling factors (0073-LIMN-073)(0073-SP-LIMN-073) ### Test case 19: Deposit tokens during checkpoint restore @@ -372,7 +373,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Stop the network. 1. Deposit tokens to a vega party via the ERC20 assert bridge. 1. Restart the vega network from the checkpoint created earlier. -1. There party's newly deposited assets are available. (0073-LIMN-074) +1. There party's newly deposited assets are available. (0073-LIMN-074)(0073-SP-LIMN-074) ### Test case 20: Multisig updates during checkpoint restart @@ -382,7 +383,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Stop the network. 1. Update the multisig contract. 1. Restart the vega network from the checkpoint created earlier. -1. Vega observes the multisig change and rewards are paid at the end of the current epoch. (0073-LIMN-075) +1. Vega observes the multisig change and rewards are paid at the end of the current epoch. (0073-LIMN-075)(0073-SP-LIMN-075) ### Test case 21: Loading from checkpoint with invalid multisig @@ -392,4 +393,4 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Stop the network. 1. Do not update the multisig contract. 1. Restart the vega network from the checkpoint created earlier. -1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076) +1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076)(0073-SP-LIMN-076) diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 31c6f3f4b..94f9f43e1 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -48,15 +48,15 @@ After entering or exiting an auction mid-batch, the full batch must be processed ## Acceptance criteria -- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001) -- Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002) -- An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003) -- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005) -- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006) In particular: +- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001)(0074-SP-BBTCH-001) +- Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002)(0074-SP-BBTCH-002) +- An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003)(0074-SP-BBTCH-003) +- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005)(0074-SP-BBTCH-005) +- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006)(0074-SP-BBTCH-006) In particular: - A batch consisting of two limit order placements C1 and C2 where the party has enough balance to place either of them individually but not both should place C1 but reject C2. - A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction and a C2 which is marked `GFN` (good for normal) should execute C1 but reject C2. -- A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007) -- Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008) -- Margin released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009) -- If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010) -- Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011) +- A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007)(0074-SP-BBTCH-007) +- Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008)(0074-SP-BBTCH-008) +- Margin released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009)(0074-SP-BBTCH-009) +- If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010)(0074-SP-BBTCH-010) +- Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011)(0074-SP-BBTCH-011) diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index d3279ccbf..9a9f5913a 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -104,70 +104,70 @@ message ProtocolUpgradeEvent { ### Invalid proposals - Rejections - A network with 5 validators -- (0075-PLUP-001) Validator proposes a protocol upgrade to an invalid [tag](https://semver.org/) - should result in an error -- (0075-PLUP-002) Validator proposes a protocol upgrade on a block height preceding the current block - should result in an error -- (0075-PLUP-003) Propose and enact a version downgrade -- (0075-PLUP-004) Non-validator attempts to propose upgrade -- (0075-PLUP-005) Ersatz validator (standby validator) attempts to propose upgrade +- (0075-PLUP-001)(0075-SP-PLUP-001) Validator proposes a protocol upgrade to an invalid [tag](https://semver.org/) - should result in an error +- (0075-PLUP-002)(0075-SP-PLUP-002) Validator proposes a protocol upgrade on a block height preceding the current block - should result in an error +- (0075-PLUP-003)(0075-SP-PLUP-003) Propose and enact a version downgrade +- (0075-PLUP-004)(0075-SP-PLUP-004) Non-validator attempts to propose upgrade +- (0075-PLUP-005)(0075-SP-PLUP-005) Ersatz validator (standby validator) attempts to propose upgrade ### Block height validation Proposal will not be accepted as valid if validator: -- (0075-PLUP-006) Proposes a negative upgrade block -- (0075-PLUP-007) Proposes a 0 upgrade block -- (0075-PLUP-008) Proposes (string/other upgrade block) -- (0075-PLUP-009) Proposes without supplying a block height +- (0075-PLUP-006)(0075-SP-PLUP-006) Proposes a negative upgrade block +- (0075-PLUP-007)(0075-SP-PLUP-007) Proposes a 0 upgrade block +- (0075-PLUP-008)(0075-SP-PLUP-008) Proposes (string/other upgrade block) +- (0075-PLUP-009)(0075-SP-PLUP-009) Proposes without supplying a block height ### VISOR -- (0075-PLUP-010) Can be seen to automatically download the tagged version proposed for install when available at the source location when file meets the format criteria defined -- (0075-PLUP-011) Visor automatically upgrades validators to proposed version if required majority has been reached +- (0075-PLUP-010)(0075-SP-PLUP-010) Can be seen to automatically download the tagged version proposed for install when available at the source location when file meets the format criteria defined +- (0075-PLUP-011)(0075-SP-PLUP-011) Visor automatically upgrades validators to proposed version if required majority has been reached ### Epochs -- ((0075-COSMICELEVATOR-012)) Proposing an upgrade block which ought to be the end of an epoch. After upgrade takes place, confirm rewards are distributed, any pending delegations take effect, and validator joining/leaving takes effect. -- (0075-PLUP-013) Propose an upgrade block which should result in a network running new code version in the same epoch. -- (0075-PLUP-014) Ensure end of epoch processes still run after restore e.g reward calculation and distributions +- ((0075-COSMICELEVATOR-012))((0075-SP-COSMICELEVATOR-012)) Proposing an upgrade block which ought to be the end of an epoch. After upgrade takes place, confirm rewards are distributed, any pending delegations take effect, and validator joining/leaving takes effect. +- (0075-PLUP-013)(0075-SP-PLUP-013) Propose an upgrade block which should result in a network running new code version in the same epoch. +- (0075-PLUP-014)(0075-SP-PLUP-014) Ensure end of epoch processes still run after restore e.g reward calculation and distributions ### Required Majority For the purposes of protocol upgrade each validator that participates in consensus has one vote. Required majority is set by `validators.vote.required network parameter`. -- (0075-PLUP-015) Counting proposal votes to check if required majority has been reached occurs when any proposed target block has been reached -- (0075-PLUP-016) Only proposals from validators participating in consensus are counted when any proposed target block has been reached. -- (0075-PLUP-017) Events are emitted for all proposals which fail to reach required majority when target block is reached -- (0075-PLUP-018) When majority reached during the process of upgrading, those validators which didn't propose will stop producing blocks -- (0075-PLUP-019) Proposals for multiple versions at same block height will be rejected if majority has not been reached, network continues with the current running version -- (0075-PLUP-020) Propose with a validator which is moved to Ersatz by the time the upgrade is enacted. If there are 5 validators, 3 vote yes, 2 vote no: One of the yes voters is kicked in favour of a new one, leaving the vote at 2-2 so the upgrade should not happen as counting votes happens at block height only -- (0075-PLUP-036) Changing `validators.vote.required` network parameter to a value above two thirds is respected. -- (0075-PLUP-037) The value of `validators.vote.required` is checked at upgrade block, i.e: vote on a proposal with all validators, then change the `validators.vote.required` network parameter before upgrade block, to a higher value, which would cause the upgrade to be rejected. Upgrade fails. +- (0075-PLUP-015)(0075-SP-PLUP-015) Counting proposal votes to check if required majority has been reached occurs when any proposed target block has been reached +- (0075-PLUP-016)(0075-SP-PLUP-016) Only proposals from validators participating in consensus are counted when any proposed target block has been reached. +- (0075-PLUP-017)(0075-SP-PLUP-017) Events are emitted for all proposals which fail to reach required majority when target block is reached +- (0075-PLUP-018)(0075-SP-PLUP-018) When majority reached during the process of upgrading, those validators which didn't propose will stop producing blocks +- (0075-PLUP-019)(0075-SP-PLUP-019) Proposals for multiple versions at same block height will be rejected if majority has not been reached, network continues with the current running version +- (0075-PLUP-020)(0075-SP-PLUP-020) Propose with a validator which is moved to Ersatz by the time the upgrade is enacted. If there are 5 validators, 3 vote yes, 2 vote no: One of the yes voters is kicked in favour of a new one, leaving the vote at 2-2 so the upgrade should not happen as counting votes happens at block height only +- (0075-PLUP-036)(0075-SP-PLUP-036) Changing `validators.vote.required` network parameter to a value above two thirds is respected. +- (0075-PLUP-037)(0075-SP-PLUP-037) The value of `validators.vote.required` is checked at upgrade block, i.e: vote on a proposal with all validators, then change the `validators.vote.required` network parameter before upgrade block, to a higher value, which would cause the upgrade to be rejected. Upgrade fails. -### Multiple proposals (0075-PLUP-021) +### Multiple proposals (0075-PLUP-021)(0075-SP-PLUP-021) - If multiple proposals are submitted from a validator before the block heights are reached then only the last proposal is considered -## Spam (0075-COSMICELEVATOR-022) +## Spam (0075-COSMICELEVATOR-022)(0075-SP-COSMICELEVATOR-022) - Excessive numbers of proposals from a single validator within an epoch should be detected and rejected - (Future requirement) ## Snapshots -- (0075-PLUP-023) Post a validator becoming a consensus-participating validator they should be immediately allowed to propose an upgrade and be included in the overall total count -- (0075-PLUP-024) Ensure that required majority is not met when enough validators join between validator proposals and target block, i.e: In a network with 5 validators, required majority is two thirds, 4 vote to upgrade, 2 more validators join before upgrade block and do not vote. Upgrade does not take place. -- (0075-PLUP-025) Node starting from snapshot which has a proposal at a given block, ensure during replay when the block height is reached a new version is loaded and also post load an upgrade takes place at target block. -- (0075-PLUP-045) Arrange a network where n nodes are required for consensus, and at least n+1 nodes in the network. Schedule a protocol upgrade where n-1 nodes automatically start on the new version after upgrade, i.e: No consensus after upgrade. Start the (n+1)th node and consensus is achieved. For the nth node, clear vega and tm, and restart the node using state-sync at the upgrade block height. All nodes produce blocks. +- (0075-PLUP-023)(0075-SP-PLUP-023) Post a validator becoming a consensus-participating validator they should be immediately allowed to propose an upgrade and be included in the overall total count +- (0075-PLUP-024)(0075-SP-PLUP-024) Ensure that required majority is not met when enough validators join between validator proposals and target block, i.e: In a network with 5 validators, required majority is two thirds, 4 vote to upgrade, 2 more validators join before upgrade block and do not vote. Upgrade does not take place. +- (0075-PLUP-025)(0075-SP-PLUP-025) Node starting from snapshot which has a proposal at a given block, ensure during replay when the block height is reached a new version is loaded and also post load an upgrade takes place at target block. +- (0075-PLUP-045)(0075-SP-PLUP-045) Arrange a network where n nodes are required for consensus, and at least n+1 nodes in the network. Schedule a protocol upgrade where n-1 nodes automatically start on the new version after upgrade, i.e: No consensus after upgrade. Start the (n+1)th node and consensus is achieved. For the nth node, clear vega and tm, and restart the node using state-sync at the upgrade block height. All nodes produce blocks. ## LNL Checkpoints -- (0075-PLUP-026) Validator proposals should not be stored in the checkpoints and restored into the network -- (0075-PLUP-027) Upgrade will not occur after a post checkpoint restore until new proposals are made and block height reached +- (0075-PLUP-026)(0075-SP-PLUP-026) Validator proposals should not be stored in the checkpoints and restored into the network +- (0075-PLUP-027)(0075-SP-PLUP-027) Upgrade will not occur after a post checkpoint restore until new proposals are made and block height reached ## API -- (0075-PLUP-028) An datanode API should be available to provide information on the upcoming confirmed proposal including total proposals/block details/versions +- (0075-PLUP-028)(0075-SP-PLUP-028) An datanode API should be available to provide information on the upcoming confirmed proposal including total proposals/block details/versions -### Successful upgrade (0075-PLUP-029) +### Successful upgrade (0075-PLUP-029)(0075-SP-PLUP-029) - A new release is made available, and is successfully deployed - Setup a network with 5 validators running version x @@ -177,39 +177,39 @@ For the purposes of protocol upgrade each validator that participates in consens ### Failing consensus -- (0075-PLUP-030) Upgrade takes place at block N. Restart with a number of validators whose voting power is <= two thirds. Restart one more validator whose voting power would take the total voting power >= two thirds, with an incorrect version. Consensus is not achieved. Now restart that validator with the correct version. Consensus is achieved. -- (0075-PLUP-031) 5 validator network. Upgrade takes places at block N. Start 3 validators immediately. Allow several seconds to pass. - no blocks producing as 3 validators do not have enough weight - need 70% weight to produce blocks. Start two remaining validators. (All validators continue to work). -- (0075-PLUP-032) Upgrade takes place, but insufficient validators are restored for 1, 5, 10, minutes. Validators which are restored immediately patiently wait for consensus to be achieved, and then blocks continue - consensus achieved +- (0075-PLUP-030)(0075-SP-PLUP-030) Upgrade takes place at block N. Restart with a number of validators whose voting power is <= two thirds. Restart one more validator whose voting power would take the total voting power >= two thirds, with an incorrect version. Consensus is not achieved. Now restart that validator with the correct version. Consensus is achieved. +- (0075-PLUP-031)(0075-SP-PLUP-031) 5 validator network. Upgrade takes places at block N. Start 3 validators immediately. Allow several seconds to pass. - no blocks producing as 3 validators do not have enough weight - need 70% weight to produce blocks. Start two remaining validators. (All validators continue to work). +- (0075-PLUP-032)(0075-SP-PLUP-032) Upgrade takes place, but insufficient validators are restored for 1, 5, 10, minutes. Validators which are restored immediately patiently wait for consensus to be achieved, and then blocks continue - consensus achieved ### Mainnet -- (0075-COSMICELEVATOR-033) Check that we can protocol upgrade a system which has been restarted from mainnet snapshots with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. -- (0075-PLUP-046) Check that we can protocol upgrade a system which has been restarted from latest mainnet checkpoint with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. +- (0075-COSMICELEVATOR-033)(0075-SP-COSMICELEVATOR-033) Check that we can protocol upgrade a system which has been restarted from mainnet snapshots with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. +- (0075-PLUP-046)(0075-SP-PLUP-046) Check that we can protocol upgrade a system which has been restarted from latest mainnet checkpoint with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. ### Overwriting transactions -- (0075-PLUP-034) A proposal made to upgrade to the currently running version will retract previous proposals. i.e: System is running version V. Make a proposal for block height H and version V + 1 and vote with all validators. Before block height H, submit a new proposal for version V and any future block height, with all validators. Upgrade proposals are retracted, and upgrade does not take place. -- (0075-PLUP-035) Rejected proposals do not overwrite previous valid upgrade proposals. +- (0075-PLUP-034)(0075-SP-PLUP-034) A proposal made to upgrade to the currently running version will retract previous proposals. i.e: System is running version V. Make a proposal for block height H and version V + 1 and vote with all validators. Before block height H, submit a new proposal for version V and any future block height, with all validators. Upgrade proposals are retracted, and upgrade does not take place. +- (0075-PLUP-035)(0075-SP-PLUP-035) Rejected proposals do not overwrite previous valid upgrade proposals. ### Data is preserved -- (0075-PLUP-038) An open market with active orders which is available prior to upgrade, is still available, active, and can be traded on, post-upgrade. -- (0075-PLUP-039) Stake available prior to upgrade is still available post upgrade. -- (0075-PLUP-040) Active and pending delegations made prior to upgrade are still active post upgrade. -- (0075-PLUP-041) A market due to expire during an upgrade will terminate and/or settle post-upgrade. -- (0075-PLUP-042) Trader balances available prior to upgrade is still available post upgrade. -- (0075-PLUP-043) Pending and active assets available prior to upgrade is still available post upgrade. -- (0075-PLUP-044) Network parameter, market and asset proposals can span a protocol upgrade. +- (0075-PLUP-038)(0075-SP-PLUP-038) An open market with active orders which is available prior to upgrade, is still available, active, and can be traded on, post-upgrade. +- (0075-PLUP-039)(0075-SP-PLUP-039) Stake available prior to upgrade is still available post upgrade. +- (0075-PLUP-040)(0075-SP-PLUP-040) Active and pending delegations made prior to upgrade are still active post upgrade. +- (0075-PLUP-041)(0075-SP-PLUP-041) A market due to expire during an upgrade will terminate and/or settle post-upgrade. +- (0075-PLUP-042)(0075-SP-PLUP-042) Trader balances available prior to upgrade is still available post upgrade. +- (0075-PLUP-043) (0075-SP-PLUP-043) Pending and active assets available prior to upgrade is still available post upgrade. +- (0075-PLUP-044)(0075-SP-PLUP-044) Network parameter, market and asset proposals can span a protocol upgrade. ### Ethereum events during outage -- (0075-PLUP-051) Deposit events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-051)(0075-SP-PLUP-051) Deposit events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Schedule an upgrade on a network that is not using visor. 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. 1. Deposit tokens via the ERC20 bridge. 1. Start the network using the upgrade binary. 1. Balance reported as added in the appropriate account(s). -- (0075-PLUP-052) Staking events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-052)(0075-SP-PLUP-052) Staking events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Ensure parties A & B have some stake, which is delegated to a/some node(s). 1. Schedule an upgrade on a network that is not using visor. 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. @@ -217,14 +217,14 @@ For the purposes of protocol upgrade each validator that participates in consens 1. Remove some (not all) stake from party B. 1. Start the network using the upgrade binary. 1. Additional stake reported for party A and auto-delegated. Stake removed for party B and delegation reduced. -- (0075-PLUP-047) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-047)(0075-SP-PLUP-047) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Arrange a network where one validator is promoted to replace another validator. Collect signatures to update the multisig contract, but do not yet update the multisig. 1. Schedule an upgrade on the network (should not be using visor). 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. 1. Update the multisig contract to reflect the correct validators. 1. Start the network using the upgrade binary. 1. At the end of the current epoch, rewards are paid out. -- (0075-PLUP-048) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-048)(0075-SP-PLUP-048) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Arrange a network where one validator is promoted to replace another validator. Collect signatures to update the multisig contract, but do not yet update the multisig. 1. Schedule an upgrade on the network (should not be using visor). 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. @@ -236,14 +236,14 @@ For the purposes of protocol upgrade each validator that participates in consens ### Transactions during upgrade -- (0075-PLUP-049) Network handles filled mempool during upgrade. +- (0075-PLUP-049)(0075-SP-PLUP-049) Network handles filled mempool during upgrade. 1. Schedule a protocol upgrade in a network with no nodes using visor. 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. 1. Start one node on the new binary. 1. Send enough transactions to the node to fill the tendermint mempool. (Expect sane rejection once mempool is full) 1. Start the other nodes on the correct upgrade binary. 1. Expect all transactions that reached the mempool without being rejected to be correctly processed over several blocks. -- (0075-PLUP-050) Transactions can be made in block immediately before protocol upgrade. +- (0075-PLUP-050)(0075-SP-PLUP-050) Transactions can be made in block immediately before protocol upgrade. 1. Schedule a protocol upgrade in a network with no nodes using visor. 1. Continuously send transactions as the upgrade block approaches. 1. When the nodes stop processing blocks for the upgrade, make a note of all transactions which reached blocks already (transactions which did not are expected to be discarded). diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 4dc6a1d2d..58b148230 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -146,64 +146,64 @@ It must be possible to add to the data node APIs that return the result of calcu ### Data synchronisation -1. To ensure no loss of historical data access; data nodes must be able to have access to and synchronise all historical data since genesis block or LNL restart (0076-COSMICELEVATOR-001) -1. To ensure that new nodes joining the network have access to all historical data; nodes must be able to have access to and synchronise all historical data across the network without having to replay the full chain (0076-DANO-003) -1. Nodes must be able to start processing new blocks having loaded the only the most recent history (0076-DANO-023) -1. Nodes that have been temporarily disconnected from the network should be able to load the missed history to get back up to the current network height (or most recently produced history) and then be able to start processing new blocks (0076-DANO-024) -1. It must be possible to fetch history from the network whilst the node processes new blocks. So for example, if setting up a new Archive node, the node can keep up to date with the network whilst retrieving history all the way back to the first block. Once this is done the node should be able to reconcile the fetched history with that produced whilst the history was being retrieved such that the node will have a full history from the first block all the way to the networks current height. (0076-DANO-025) -1. It must be possible to rollback the data-node to a previous block height and have it process events from this height onwards. The state of the datanode at the rollback height must match exactly the state of the node as it was when it originally reached the given height. (0076-DANO-039) +1. To ensure no loss of historical data access; data nodes must be able to have access to and synchronise all historical data since genesis block or LNL restart (0076-COSMICELEVATOR-001)(0076-SP-COSMICELEVATOR-001) +1. To ensure that new nodes joining the network have access to all historical data; nodes must be able to have access to and synchronise all historical data across the network without having to replay the full chain (0076-DANO-003)(0076-SP-DANO-003) +1. Nodes must be able to start processing new blocks having loaded the only the most recent history (0076-DANO-023)(0076-SP-DANO-023) +1. Nodes that have been temporarily disconnected from the network should be able to load the missed history to get back up to the current network height (or most recently produced history) and then be able to start processing new blocks (0076-DANO-024)(0076-DANOSP--024) +1. It must be possible to fetch history from the network whilst the node processes new blocks. So for example, if setting up a new Archive node, the node can keep up to date with the network whilst retrieving history all the way back to the first block. Once this is done the node should be able to reconcile the fetched history with that produced whilst the history was being retrieved such that the node will have a full history from the first block all the way to the networks current height. (0076-DANO-025)(0076-SP-DANO-025) +1. It must be possible to rollback the data-node to a previous block height and have it process events from this height onwards. The state of the datanode at the rollback height must match exactly the state of the node as it was when it originally reached the given height. (0076-DANO-039)(0076-SP-DANO-039) ### Data integrity -1. Data produced in the core snapshots aligns with the data-node data proving that what is returned by data-node matches core state at any given block height (0076-DANO-004) +1. Data produced in the core snapshots aligns with the data-node data proving that what is returned by data-node matches core state at any given block height (0076-DANO-004)(0076-SP-ANO-004) ### Data-node decentralised history -1. Historical data must be available to load into the datanode and must not be dependent on any centralised entity. (0076-DANO-005) -1. A datanode restored from decentralised history for a given block span must match exactly the state of a datanode that has the same block span of data created by consuming events. (0076-DANO-012) -1. As the network produces more blocks the data should be stored correctly in the data-node after a data-node is restored from decentralised history. For example: Start a data-node from a given history segment for a known block height, ensure the datanode continues to update from that block onwards. (0076-DANO-007). -1. It should not be necessary to restore the full history (i.e. from genesis block) to be able to process new blocks. Restoring just the most recent history segment should be sufficient for the node to process new blocks. (0076-DANO-006) -1. No data is duplicated as the core emits events when catching up to the later block height. For example: Starting a core node at block height less than the data-node block height must result in no duplicated data (0076-DANO-008) -1. Starting a core node at block height greater than the data-nodes block height must result in an error and a refusal to start (0076-DANO-014) -1. If a data-node snapshot fails during the restore the process, it should error and the node(s) won't start (0076-DANO-009) -1. When queried via the APIs a node restored from decentralised history should return identical results to a node with the same block span which has been populated by event consumption. [project front end dApps](https://github.com/vegaprotocol/frontend-monorepo/actions/workflows/generate-queries.yml). (0076-DANO-022) -1. All network history retained by a node for a given block span and type must be downloadable in CSV format. (0076-DANO-040) +1. Historical data must be available to load into the datanode and must not be dependent on any centralised entity. (0076-DANO-005)(0076-SP-DANO-005) +1. A datanode restored from decentralised history for a given block span must match exactly the state of a datanode that has the same block span of data created by consuming events. (0076-DANO-012)(0076-SP-DANO-012) +1. As the network produces more blocks the data should be stored correctly in the data-node after a data-node is restored from decentralised history. For example: Start a data-node from a given history segment for a known block height, ensure the datanode continues to update from that block onwards. (0076-DANO-007)(0076-SP-DANO-007). +1. It should not be necessary to restore the full history (i.e. from genesis block) to be able to process new blocks. Restoring just the most recent history segment should be sufficient for the node to process new blocks. (0076-DANO-006)(0076-SP-DANO-006) +1. No data is duplicated as the core emits events when catching up to the later block height. For example: Starting a core node at block height less than the data-node block height must result in no duplicated data (0076-DANO-008)(0076-SP-DANO-008) +1. Starting a core node at block height greater than the data-nodes block height must result in an error and a refusal to start (0076-DANO-014)(0076-SP-DANO-014) +1. If a data-node snapshot fails during the restore the process, it should error and the node(s) won't start (0076-DANO-009)(0076-SP-DANO-009) +1. When queried via the APIs a node restored from decentralised history should return identical results to a node with the same block span which has been populated by event consumption. [project front end dApps](https://github.com/vegaprotocol/frontend-monorepo/actions/workflows/generate-queries.yml). (0076-SP-DANO-022) +1. All network history retained by a node for a given block span and type must be downloadable in CSV format. (0076-DANO-040)(0076-SP-DANO-040) ### Data-node network determinism -1. For a given block span, a datanode history segment must be identical across all dat-nodes in the network that are using the recommended hardware and OS versions (0076-DANO-010) -1. History segments for the same block span must always match across the network, regardless of whether the producing node was itself restored from decentralised history or not. (0076-DANO-011) +1. For a given block span, a datanode history segment must be identical across all dat-nodes in the network that are using the recommended hardware and OS versions (0076-DANO-010)(0076-SP-DANO-010) +1. History segments for the same block span must always match across the network, regardless of whether the producing node was itself restored from decentralised history or not. (0076-DANO-011)(0076-SP-DANO-011) ### Schema compatibility -1. It is possible to identify if schema versions are NOT backwards compatible. Pull existing network snapshots start network, run a protocol upgrade to at later version and ensure both the core state and data-node data is correct (0076-COSMICELEVATOR-XXX) -1. Restoring a node from decentralised history should work across schema upgrade boundaries and the state of the datanode should match that of a datanode populated purely by event consumption (0076-COSMICELEVATOR-XXX) +1. It is possible to identify if schema versions are NOT backwards compatible. Pull existing network snapshots start network, run a protocol upgrade to at later version and ensure both the core state and data-node data is correct (0076-COSMICELEVATOR-XXX)(0076-SP-COSMICELEVATOR-XXX) +1. Restoring a node from decentralised history should work across schema upgrade boundaries and the state of the datanode should match that of a datanode populated purely by event consumption (0076-COSMICELEVATOR-XXX)(0076-SP-COSMICELEVATOR-XXX) ### Data Retention -1. Lite nodes should have enough state to provide the current state of: Assets, Parties, Accounts, Balances, Live Orders, Network Limits, Nodes, Delegations, Markets, Margin Levels, Network Parameters, Positions, Liquidity Provisions (0076-DANO-026) -2. Standard nodes should retain data in accordance with the configured data retention policy (0076-DANO-027) -3. Archival nodes should retain all data from the height at which they joined the network (0076-DANO-028) +1. Lite nodes should have enough state to provide the current state of: Assets, Parties, Accounts, Balances, Live Orders, Network Limits, Nodes, Delegations, Markets, Margin Levels, Network Parameters, Positions, Liquidity Provisions (0076-DANO-026)(0076-SP-DANO-026) +2. Standard nodes should retain data in accordance with the configured data retention policy (0076-DANO-027)(0076-SP-DANO-027) +3. Archival nodes should retain all data from the height at which they joined the network (0076-DANO-028)(0076-SP-DANO-028) ### API Request Rate Limiting 1. Datanode should provide an optional mechanism for limiting the average number of requests per second over on its API 2. That rate should be specified in the datanode configuration file -3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. (0076-DANO-029) -4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file (0076-DANO-030) -5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031) -6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032) -7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033) -8. If the rate of denied (due to rate limiting) requests subsequently exceed the same maximum rate/burst parameters the client should be banned (0076-DANO-034) -9. The ban denies all access to the API for a configurable length of time (0076-DANO-035) -10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036) -11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037) -12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client (0076-DANO-038) +3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. (0076-DANO-029)(0076-SP-DANO-029) +4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file (0076-DANO-030)(0076-SP-DANO-030) +5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031)(0076-SP-DANO-031) +6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032)(0076-SP-DANO-032) +7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033)(0076-SP-DANO-033) +8. If the rate of denied (due to rate limiting) requests subsequently exceed the same maximum rate/burst parameters the client should be banned (0076-DANO-034)(0076-SP-DANO-034) +9. The ban denies all access to the API for a configurable length of time (0076-DANO-035)(0076-SP-DANO-035) +10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036)(0076-SP-DANO-036) +11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037)(0076-SP-DANO-037) +12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client (0076-DANO-038)(0076-SP-DANO-038) ### General Acceptance -1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015) -1. The validator node will only accept requests for event bus subscriptions. All other API subscription requests will be invalid. (0076-DANO-016) -1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017) -1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019) -1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) +1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015)(0076-SP-DANO-015) +1. The validator node will only accept requests for event bus subscriptions. All other API subscription requests will be invalid. (0076-DANO-016)(0076-SP-DANO-016) +1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017)(0076-SP-DANO-017) +1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019)(0076-SP-DANO-019) +1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021)(0076-SP-DANO-021) diff --git a/protocol/0077-SNAP-snapshots.md b/protocol/0077-SNAP-snapshots.md index 4607b67eb..6f9620782 100644 --- a/protocol/0077-SNAP-snapshots.md +++ b/protocol/0077-SNAP-snapshots.md @@ -57,9 +57,9 @@ A bad node can swamp the network by requesting snapshots from other nodes which ## Acceptance Criteria -- A node can be started up so that it generates snapshots at given block intervals (0077-SNAP-001) -- A node will generate snapshots files on the local filesystem (most likely using GOLevelDB) (0077-SNAP-002) -- A node will have a maximum amount of snapshots file on the filesystem. Older ones will be to be removed before a new one can be created. How many snapshots we keep may be something that can be configured. (0077-SNAP-003) -- The state of a node that is started from a snapshot should be identical to a node that had reached the same block height via replay. (0077-SNAP-004) -- Post a checkpoint restore we see snapshots continuing to be produced as before and can be used to add a node to the network (0077-SNAP-005) -- With `snapshot.interval.length` set to `k` all the nodes in a network will create a snapshot at block height `k`, `2k`, `3k`, ... (0077-SNAP-006) +- A node can be started up so that it generates snapshots at given block intervals (0077-SNAP-001)(0077-SP-SNAP-001) +- A node will generate snapshots files on the local filesystem (most likely using GOLevelDB) (0077-SNAP-002)(0077-SSP-NAP-002) +- A node will have a maximum amount of snapshots file on the filesystem. Older ones will be to be removed before a new one can be created. How many snapshots we keep may be something that can be configured. (0077-SNAP-003)(0077-SP-SNAP-003) +- The state of a node that is started from a snapshot should be identical to a node that had reached the same block height via replay. (0077-SNAP-004)(0077-SP-SNAP-004) +- Post a checkpoint restore we see snapshots continuing to be produced as before and can be used to add a node to the network (0077-SNAP-005)(0077-SP-SNAP-005) +- With `snapshot.interval.length` set to `k` all the nodes in a network will create a snapshot at block height `k`, `2k`, `3k`, ... (0077-SNAP-006)(0077-SP-SNAP-006) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index 19554a206..f3a3bc430 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -106,18 +106,18 @@ There are three priority categories: ## Acceptance criteria -### Basic happy path test (0079-TGAP-001) +### Basic happy path test (0079-TGAP-001)(0079-SP-TGAP-001) 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 20`. 1. Send `100` transactions with default gas cost to a node (e.g. votes on a proposal) and observe that most block have 5 of these transactions each. -### Test max with a market (0079-TGAP-002) +### Test max with a market (0079-TGAP-002)(0079-SP-TGAP-002) 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 1`. 1. Create a market with 1 LP using 2 shape offsets on each side, just best static bid / ask on the book and 2 parties with a position. 1. Another party submits a transaction to place a limit order. A block will be created containing the transaction (even though the gas cost of a limit order is `1 + 100 x 4 + 2 + 0.1 x 6` which is well over `100`.) -### Test we don't overfill a block with a market (0079-TGAP-003) +### Test we don't overfill a block with a market (0079-TGAP-003)(0079-SP-TGAP-003) 1. Set `network.transactions.maxgasperblock = 500` and `network.transaction.defaultgas = 1`. 1. Create a market with 1 LP using 2 shape offsets on each side, just best static bid / ask on the book and 2 parties with a position. From 4de17b2185a51ad2989cac4c75488f5d4f7b2a01 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 30 Jun 2023 16:18:24 +0100 Subject: [PATCH 215/649] feat: update 0028 --- protocol/0028-GOVE-governance.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index ca56ed074..9dcf40d3a 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -560,25 +560,25 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119)(0028-SP-GOVE-119) - A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120)(0028-SP-GOVE-120) - A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121)(0028-SP-GOVE-121) +- A proposal to transfer tokens between Market insurance pool account and Network treasury is valid (0028-GOVE-132)(0028-SP-GOVE-132) - A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122)(0028-SP-GOVE-122) - Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077)(0028-SP-GOVE-077) - Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079)(0028-SP-GOVE-079) - Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080)(0028-SP-GOVE-080) - For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081)(0028-SP-GOVE-081) - Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082)(0028-SP-GOVE-082) -- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083)(0028-SP-GOVE-083)) +- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083)(0028-SP-GOVE-083) - Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084)(0028-SP-GOVE-084) - Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085)(0028-SP-GOVE-085) - Destination Type can be any of the predefined types in the above table (0028-GOVE-086)(0028-SP-GOVE-086) - Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087)(0028-SP-GOVE-087) -- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088)(0028SP--GOVE-088) +- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088)(0028-SP-GOVE-088) - Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089)(0028-SP-GOVE-089) - Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090)(0028-SP-GOVE-090) - For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091)(0028-SP-GOVE-091) - The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092)(0028-SP-GOVE-092) - For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093)(0028-SP-GOVE-093) - ##### Governance transfer enactment - For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094)(0028-SP-GOVE-094) @@ -601,11 +601,14 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Protocol Upgrade -- Transfer proposals in either a pre or post enactment state are not restored after a protocol upgrade (0028-GOVE-102)(0028-SP-GOVE-102) +- Transfer proposals in either a pre or post enactment state are restored after a protocol upgrade (0028-GOVE-102)(0028-SP-GOVE-102) +- Recurring transfers proposed before an upgrade which start before, during or after an upgrade should complete on the proposed end epoch (0028-GOVE-130)(0028-SP-GOVE-130) +- One off delivery transfers proposed before an upgrade which are due to start during or after an upgrade should complete either when the network is available again or at the proposed delivery date/time (0028-GOVE-131)(0028-SP-GOVE-131) #### Checkpoints and Snapshots -- Active governance transfer (one-off or recurring) must be included in checkpoint and snapshot (0028-GOVE-103)(0028-SP-GOVE-103) +- Active or dormant governance transfer (one-off or recurring) must be included in checkpoint and where the network is down during the proposed delivery time, the transfer will occur as soon as the network is available. For recurring transfers the transfers spanning the restore will continue until the end epoch. (0028-GOVE-103)(0028-SP-GOVE-103) +- Active or dormant governance transfer (one-off or recurring) must be included in snapshots and data nodes which join the network will support retrieval of the transfer data (0028-GOVE-133)(0028-SP-GOVE-133) ##### Recurring Governance transfers From 372236854626e5487322a77b8fe2b75d4b31c651 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 3 Jul 2023 17:24:33 +0200 Subject: [PATCH 216/649] refactor: substitute AC with slight reformulation --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 85765b2fa..85ab1ad20 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -499,7 +499,7 @@ APIs should also exist for clients to: - Verify that an enacted market change proposal that changes price monitoring bounds enters a price monitoring auction upon the _new_ bound being breached (0028-GOVE-034) - Verify that an enacted market change proposal that reduces `market.stake.target.timeWindow` leads to a reduction in target stake if recent open interest is less than historical open interest (0028-GOVE-031) - Attempts to update immutable market parameter(s) cause the market change proposal to be rejected with an appropriate rejection message (0028-GOVE-058) -- Verify that if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0` and if a party meets the `governance.proposal.updateMarket.minProposerBalance` threshold then said party can submit a market change proposal. (0028-GOVE-060) +- Verify that if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0.00001` and if a party has no equity-like share in the market, but meets the `governance.proposal.updateMarket.minProposerBalance` threshold then said party can submit a market change proposal. (0028-GOVE-134) - Change of the network parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` will immediately change the minimum proposer ELS for a market change proposal for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-064) - Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065) - Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066) From eebcef70a686f8f9d1ec8e05e44d74f559660a82 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 5 Jul 2023 09:23:51 +0200 Subject: [PATCH 217/649] refactor: governance transfer -> governance initiated transfer --- protocol/0028-GOVE-governance.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 85ab1ad20..0d85c2620 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -275,7 +275,7 @@ Enactment of an asset modification proposal is: The below table shows the allowable combinations of source and destination account types for a transfer that's initiated by a governance proposal. -| Source type | Destination type | Governance transfer permitted | +| Source type | Destination type | Governance initiated transfer permitted | | --- | --- | --- | | Party account (any type) | Any | No | | Network treasury | Network treasury | No | @@ -343,20 +343,20 @@ transfer_amount == min( ### Transfer cancellation -This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance transfer. Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal. +This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance initiated transfer. Only recurring governance initiated transfers can be cancelled via governance initiated transfer cancellation proposal. Trying to cancel any other transfer should fail upon validation of the proposal. ### Checkpoint/snapshot -Enacted and active transfers (i.e. scheduled one off governance transfers, or recurring governance transfers) must be included in LNL banking checkpoint and resume after the checkpoint restore. +Enacted and active transfers (i.e. scheduled one off governance initiated transfers, or recurring governance initiated transfers) must be included in LNL banking checkpoint and resume after the checkpoint restore. -All in memory active governance transfers must be included in the snapshot of the banking engine. +All in memory active governance initiated transfers must be included in the snapshot of the banking engine. ### Additional information 1. When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with different type (i.e. similar to one-off, and recurring of regular transfers, there are governance-one-off and governance-recurring types). At the time of enactment no amount is attached to the transfer and it will show 0. 2. When a transfer is _made_ an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. 3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. -4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. +4. Enacted governance initiated transfers are therefore available to be queried via the regular transfer API in data node. 5. Governance initiated transfers are subject to neither minimum transfer amounts nor to fees. ## 6. Change market state @@ -544,7 +544,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - Approved governance proposals sharing the same enactment time and changing the same parameter should all be applied, the oldest proposal will be applied first and the newest will be applied last, overwriting the changes made by the older proposals. (0028-GOVE-068) -#### Governance Transfer proposals +#### Governance initiated transfer proposals ##### Proposer Requirements @@ -554,7 +554,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### APIs -- Governance transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074) +- Governance initiated transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074) ##### Transfer proposal submission validation @@ -565,7 +565,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121) - A proposal to transfer tokens between Market insurance pool account and Network treasury is valid (0028-GOVE-132) - A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122) -- Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) +- Governance initiated transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) - Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) - Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080) - For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081) @@ -583,7 +583,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) -##### Governance transfer enactment +##### Governance initiated transfer enactment - For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094) - A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095) @@ -612,8 +612,8 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### Checkpoints and Snapshots -- Active or dormant governance transfer (one-off or recurring) must be included in checkpoint and where the network is down during the proposed delivery time, the transfer will occur as soon as the network is available. For recurring transfers the transfers spanning the restore will continue until the end epoch. (0028-GOVE-103) -- Active or dormant governance transfer (one-off or recurring) must be included in snapshots and data nodes which join the network will support retrieval of the transfer data (0028-GOVE-133) +- Active or dormant governance initiated transfer (one-off or recurring) must be included in checkpoint and where the network is down during the proposed delivery time, the transfer will occur as soon as the network is available. For recurring transfers the transfers spanning the restore will continue until the end epoch. (0028-GOVE-103) +- Active or dormant governance initiated transfer (one-off or recurring) must be included in snapshots and data nodes which join the network will support retrieval of the transfer data (0028-GOVE-133) ##### One Off Delivery transfers @@ -621,18 +621,18 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. (0028-GOVE-129) -##### Recurring Governance transfers +##### Recurring governance initiated transfers - For a recurring proposal, the proposal is only active from defined start epoch and optional end epoch, the transfer will be executed every epoch while the proposal is active. (0028-GOVE-104) -- Enacted and active recurring governance transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105) +- Enacted and active recurring governance initiated transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105) - When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106) -##### Cancelling governance transfers +##### Cancelling governance initiated transfers -- Only recurring governance transfers can be cancelled by proposing a governance transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) +- Only recurring governance initiated transfers can be cancelled by proposing a governance initiated transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) - After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123) - Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) - Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) From 7a9b3f2822b2a22e61df908595a02610a5de3464 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 5 Jul 2023 14:48:31 +0200 Subject: [PATCH 218/649] refactor: reword 3002-PROP-022 --- user-interface/3002-PROP-propose.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/user-interface/3002-PROP-propose.md b/user-interface/3002-PROP-propose.md index f5111308d..249c1fa9f 100644 --- a/user-interface/3002-PROP-propose.md +++ b/user-interface/3002-PROP-propose.md @@ -30,8 +30,9 @@ When making a proposal, I... - **should** see the minimum required tokens or LP vote required to make a proposal Spam protection and network parameters - if anything except market change: **must** be warned if the amount I have associated is less the the minimum required to propose for this proposal type (due to Spam protection or network parm, whichever is greater) (3002-PROP-009) - if market change: **must** be warned if the amount of tokens I have less than the minimum tokens required to propose a change (due to Spam protection or network params) (3002-PROP-020) -- if market change: **must** be warned if the amount of I have less than the minimum required equity like share to propose a change (due to Spam protection or network params) (3002-PROP-022) - **should** see the balance of associated Governance tokens +- if market change: **must** be warned if the amount equity like share I have is less than the minimum required equity like share to propose a change (due to Spam protection or network params) (3002-PROP-022) +- **should** see my equity like share in that market ### Detail on specific proposals From eee73b1571a38090885e7289fce9738b97c356e9 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 5 Jul 2023 16:06:02 +0100 Subject: [PATCH 219/649] Update ACs for proposals via governance (#1801) * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md --- protocol/0028-GOVE-governance.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 0d85c2620..cbe952fc2 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -562,12 +562,10 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - A proposal to transfer tokens between Network treasury and Party general account(s) is valid (0028-GOVE-128) - A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119) - A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120) -- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121) - A proposal to transfer tokens between Market insurance pool account and Network treasury is valid (0028-GOVE-132) - A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122) - Governance initiated transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) - Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) -- Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080) - For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081) - Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082) - Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083) @@ -577,7 +575,6 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087) - Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088) - Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089) -- Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090) - For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091) - The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092) - For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) @@ -587,9 +584,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094) - A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095) -- Transfers can occur for terminated markets (0028-GOVE-096) -- Transfers cannot occur for settled markets and a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-097) -- Transfers cannot occur for pending markets unless they become active on or before the enactment time of the transfer (0028-GOVE-098) +- Transfers can occur for pending, terminated markets, settled markets (0028-GOVE-096) ##### Transferred Amount From 71116fa9de11c8a8b2fb8dc3845f0d7dabccc82d Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 6 Jul 2023 15:54:01 +0200 Subject: [PATCH 220/649] refactor: add final funding payment --- protocol/0053-PERP-product_builtin_perpetual_future.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 0982121ff..d330647d1 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -100,6 +100,10 @@ m^{\text{maint (perps)}}_t = m^{\text{maint}}_t + \text{margin funding factor} \ where $m^{\text{maint}}_t$ is the current maintenance margin as per the [margin spec](./0019-MCAL-margin_calculator.md) +### 6. Market closure + +Should a perpetual futures market get closed using the [governance proposal](./0028-GOVE-governance.md#61-move-market-to-a-closed-state) an final funding payment should be calculated using the data available at that time and exchanged right before the final settlement using the price contained in the proposal is carried out. + ### API considerations It should be possible to query the market for the list of current funding payment data points as well as history of calculated funding payment values. From 57270760e07ec87dd6cc041f2f1cc599ad612f27 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 3 Jul 2023 17:19:54 +0100 Subject: [PATCH 221/649] feat: include new acs --- protocol/0044-LIME-lp_mechanics.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index c910f4a66..b738ab664 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -300,15 +300,35 @@ Note: - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the bond stake has been slashed to a level lower than the amendment, this slashed level will be retained (i.e. the protocol will not attempt to now increase the commitment) (0044-LIME-020) - If a liquidity provider with an active liquidity provision at the start of an epoch amends the fee level associated to this commitment during the epoch, this change will only take effect at the end of the epoch. (0044-LIME-021) +- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to increase the bond to the new level if they do not have sufficient collateral in the settlement asset of the market to meet new commitment amount then the amendment will be rejected and old commitment amount is retained (0044-LIME-030) +- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will increase the bond to the new level if they have sufficient collateral in the settlement asset of the market to meet new commitment amount (0044-LIME-031) + - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-025) -- - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) +- When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) + +### Qualifying Order Types + +- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) +- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) + +### Snapshot + +- Snapshot for the bonus account, bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-032) + +### Protocol upgrade + +- After a protocol upgrade the bonus account, bond account and fee account and their balances are maintained (0044-LIME-033) + +### Checkpoint + +- When a checkpoint is restored the bonus account, bond account and fee account are included and when so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-032) \ No newline at end of file From fdc99d4cf2819560d8f56853d3d11ad53499c270 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Mon, 3 Jul 2023 18:22:47 +0100 Subject: [PATCH 222/649] Update 0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index b738ab664..d69c15545 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -331,4 +331,12 @@ Note: ### Checkpoint -- When a checkpoint is restored the bonus account, bond account and fee account are included and when so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-032) \ No newline at end of file +- SLA bonus and fee accounts must be included in the checkpoint and where the network is down any rewards accrued or fees to be paid during the down time will be actioned when the network is available (0044-LIME-032) + +#### Network History - Data node restored from network history segments + +- A datanode restored from network history will contain any bonus and fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-032) +- +#### Network param validation + +- boundary values are respected From 5b7f5d8ad3813b069697daf430e6273883d55cc6 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 4 Jul 2023 12:01:47 +0100 Subject: [PATCH 223/649] feat: added new acs --- protocol/0044-LIME-lp_mechanics.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index d69c15545..6778909f0 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -323,20 +323,28 @@ Note: ### Snapshot -- Snapshot for the bonus account, bond account and fee account are captured so that when a new validator node joins the network they can use the two accounts types Bond and Fee account (0044-LIME-032) +- A snapshot must include the bonus accounts, fee accounts and their balances so that after a node is started using the snapshot they can retain the two accounts and their balances (0044-LIME-032) ### Protocol upgrade -- After a protocol upgrade the bonus account, bond account and fee account and their balances are maintained (0044-LIME-033) +- After a protocol upgrade the bonus accounts, fee accounts and their balances are retained (0044-LIME-032) ### Checkpoint -- SLA bonus and fee accounts must be included in the checkpoint and where the network is down any rewards accrued or fees to be paid during the down time will be actioned when the network is available (0044-LIME-032) +- Bonus and fee accounts must be included in the checkpoint and where the network is down + - Rewards accrued during the down time will be actioned when the network is available (0044-LIME-033) + - Fees to be paid during the down time will be actioned when the network is available (0044-LIME-034) #### Network History - Data node restored from network history segments - A datanode restored from network history will contain any bonus and fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-032) -- + #### Network param validation -- boundary values are respected +- Boundary values are respected for the network parameters + - `market.liquidityV2.bondPenaltyParameter` valid values: `>=0`, `<=1000` default value of `0.1` (0044-LIME-035) + - `market.liquidityV2.earlyExitPenalty` valid values: `>=0`, `<=1000` default value of `0.1` (0044-LIME-036) + - `market.liquidityV2.maximumLiquidityFeeFactorLevel` valid values: `>=0`, `<=1` default value of `1` (0044-LIME-037) + - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-038) + - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-039) + - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-040) From 188f7bf036821d125c3187d16e8821bf4b49019a Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 4 Jul 2023 12:02:02 +0100 Subject: [PATCH 224/649] feat: new ac tbd --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 03e2829a6..928df4699 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -400,3 +400,8 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) - With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) + +#### Market param validation + +- Boundary values are respected for the market parameters + - `market.liquidity.performanceHysteresisEpochs` valid values: `>=?`, `<=?` default value of `?` (0042-LIQF-050) From 4e87603254fca582a1f3c093306bdf9881bb16d3 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 4 Jul 2023 12:24:43 +0100 Subject: [PATCH 225/649] Revert "feat: new ac tbd" This reverts commit 32f422800234f83b3eb514dfbc94bafc4ad618de. --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 928df4699..03e2829a6 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -400,8 +400,3 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) - With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) - -#### Market param validation - -- Boundary values are respected for the market parameters - - `market.liquidity.performanceHysteresisEpochs` valid values: `>=?`, `<=?` default value of `?` (0042-LIQF-050) From 0dd8b4f85f0f5ec3794481be766b5fb97847ee42 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 4 Jul 2023 13:03:15 +0100 Subject: [PATCH 226/649] fix: ac numbering --- protocol/0044-LIME-lp_mechanics.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 6778909f0..90ef01c30 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -327,24 +327,24 @@ Note: ### Protocol upgrade -- After a protocol upgrade the bonus accounts, fee accounts and their balances are retained (0044-LIME-032) +- After a protocol upgrade the bonus accounts, fee accounts and their balances are retained (0044-LIME-033) ### Checkpoint -- Bonus and fee accounts must be included in the checkpoint and where the network is down - - Rewards accrued during the down time will be actioned when the network is available (0044-LIME-033) - - Fees to be paid during the down time will be actioned when the network is available (0044-LIME-034) +- Bonus and fee accounts must be included in the checkpoint and where the network is down + - Rewards accrued during the down time will be actioned when the network is available (0044-LIME-034) + - Fees to be paid during the down time will be actioned when the network is available (0044-LIME-035) #### Network History - Data node restored from network history segments -- A datanode restored from network history will contain any bonus and fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-032) - -#### Network param validation +- A datanode restored from network history will contain any bonus and fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-036) + +#### Network parameters validation - Boundary values are respected for the network parameters - - `market.liquidityV2.bondPenaltyParameter` valid values: `>=0`, `<=1000` default value of `0.1` (0044-LIME-035) - - `market.liquidityV2.earlyExitPenalty` valid values: `>=0`, `<=1000` default value of `0.1` (0044-LIME-036) - - `market.liquidityV2.maximumLiquidityFeeFactorLevel` valid values: `>=0`, `<=1` default value of `1` (0044-LIME-037) - - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-038) - - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-039) - - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-040) + - `market.liquidityV2.bondPenaltyParameter` valid values: `>=0`, `<=1000` default value of `0.1` (0044-LIME-037) + - `market.liquidityV2.earlyExitPenalty` valid values: `>=0`, `<=1000` default value of `0.1` (0044-LIME-038) + - `market.liquidityV2.maximumLiquidityFeeFactorLevel` valid values: `>=0`, `<=1` default value of `1` (0044-LIME-039) + - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) + - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) + - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) From f1af4d1e62faa6bc246fa841c9324d75d4246442 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 6 Jul 2023 18:02:04 +0100 Subject: [PATCH 227/649] refactor: update spot parameter names --- protocol/0080-SPOT-product_builtin_spot.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index c069da5eb..3a66825af 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -13,10 +13,10 @@ When trading Spot products, parties can only use assets they own - there is no l 1. `limits.markets.proposeSpotEnabled`: parameter defines whether markets using Spot products are enabled on the network. -## 3. Liquidity Monitoring parameters +## 3. Target Stake parameters 1. `time_window`: length of rolling window (in seconds) over which the maximum `total_stake` is measured. -1. `target_stake_factor`: fraction of `total_stake` to be selected as the `target_stake`. +1. `scaling_factor`: fraction of `total_stake` to be selected as the `target_stake`. ## 4. Market parameters From 763579b21cac187ded7dddd6f5596edd11b14a75 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 10 Jul 2023 10:27:10 +0200 Subject: [PATCH 228/649] Update protocol/0053-PERP-product_builtin_perpetual_future.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index d330647d1..866c66f0f 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -91,7 +91,7 @@ If periodic settlement data happens whilst market is in auction of any other typ ### 5. Margin considerations To assure adequate solvency we need to include the estimate of the upcoming funding payment in maintenance margin estimate for the party. Let $t_{k-1}$ be the time of the last funding payment. Let $t$ be current time ($t < t_k$). -Calculate $G_t$ as the [funding payment](#44-periodic-settlement) between $t_k$ and $t$. +Calculate $G_t$ as the [funding payment](#44-periodic-settlement) between $t_{k-1}$ and $t$. For perpetual futures markets set the maintenance margin as: ```math From 2f75e7cd7e6aaf1fa2ce517d49c9f21d19033b46 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 10 Jul 2023 11:12:45 +0200 Subject: [PATCH 229/649] refactor: add perps AC --- protocol/0081-SUCM-successor_markets.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 8d93efa1b..6ac79561a 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -22,7 +22,7 @@ Moreover, part of the insurance pool of a parent market can be earmarked for tra ## Specifying a parent market and timing details A market [governance] proposal for a successor market must contain all the information of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. -The product, settlement asset, and margin asset must match but all other inputs can be different (e.g. position and price decimal places, risk mode, price monitoring, termination and settlement oracles etc.). +The product, settlement asset, and margin asset must match but all other inputs can be different (e.g. position and price decimal places, risk model, price monitoring, termination and settlement oracles etc.). For [spot markets](./0080-SPOT-product_builtin_spot.md) base and quote assets must match. The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` @@ -67,6 +67,8 @@ Market proposal may specify parent market ID. If it does then: It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). +It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-015). + Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market's parent market Id field is cleared. When it clears the opening auction it gets no insurance pool from the parent and no virtual stakes get carried over (0081-SUCM-005). A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). From d6b0d186c72051d81ae45a6e72d16f42db41262b Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 10 Jul 2023 12:43:27 +0200 Subject: [PATCH 230/649] Update protocol/0081-SUCM-successor_markets.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 6ac79561a..e8a978982 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -67,7 +67,7 @@ Market proposal may specify parent market ID. If it does then: It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). -It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-015). +It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor of the aforementioned cancelled / to be cancelled with different `market_decimal_places` and `position_decimal_places`; the LPs virtual stakes are carried over (0081-SUCM-015). Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market's parent market Id field is cleared. When it clears the opening auction it gets no insurance pool from the parent and no virtual stakes get carried over (0081-SUCM-005). From e308fad19abf121f5b46f42154421f4d47b2ff5a Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 4 Jul 2023 22:55:17 +0200 Subject: [PATCH 231/649] refactor: clarify market closure mechanics --- protocol/0028-GOVE-governance.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index cbe952fc2..e952c42ec 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -378,6 +378,12 @@ A proposal to close a market contains: Once market is closed the process cannot be reversed. Note that this implies that once a governance proposal to close the market has been voted in the market will definitely close at the enactment time of that vote at the latest. While the market is still open it's still possible to submit additional governance votes to close the market, however they'll only have any effect if their enactment date is prior to that of the market closure proposal which has already passed. +If the market is in an auction of any type excluding the opening auction at the time the market closure governance proposal gets enacted, then the auction should uncross immediately, any trades resulting from it should be generated at the auction uncrossing price and then the system should proceed to close the market using the price (if applicable) provided by the proposal being enacted. If the market is in opening auction when the governance proposal to close it gets enacted then auction shouldn't uncross, market closes trivially as no trades have yet been generated. + +Attempting to enact the market closure governance proposal on a market in a `settled` [state](./0043-MKTL-market_lifecycle.md#market-status-descriptions) has no effect. When closing a market which needs the final price with a governance vote it's always the price supplied with the governance vote being enacted that gets used, even if the oracle price is available at that time. + +The state of a market successfully closed by the governance vote should be `closed`. + ### 6.2. Suspend the market This proposal puts the market into an auction mode which can only be exit with a governance proposal to unsuspend the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. @@ -518,6 +524,11 @@ APIs should also exist for clients to: - A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) - Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117) - Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118) +- Enacting a market closure governance proposal on a market which is in opening auction closes it immediately without generating any trades. (0028-GOVE-135) +- Enacting a market closure governance proposal on a market which is in auction (of any type except the opening auction) uncrosses that auction at the current uncrossing price, generates the trades and then proceeds to close it using the final price (if applicable to the market type). (0028-GOVE-136) +- Enacting a market closure governance proposal on a market that is in a settled state has no effect. (0028-GOVE-137) +- Enacting a market closure governance proposal on a market that is not in a settled state always uses the final price supplied with the proposal, even when the oracle settlement price is available at that time. (0028-GOVE-138) +- Successful enactment of a market closure proposal changes the state of the market to `closed`. (0028-GOVE-139) #### Network parameter change proposals From 034ea5a862e8301a0d59031c3bc7b6a6b52bbb2d Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 5 Jul 2023 17:00:22 +0200 Subject: [PATCH 232/649] refactor: clarify decimal places --- protocol/0028-GOVE-governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index e952c42ec..13a6c78bf 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -374,13 +374,13 @@ Any type of market (either fixed expiry market or perpetual) can be closed via a A proposal to close a market contains: -1. final settlement price (not required for spot markets) +1. final settlement price (not required for spot markets) formatted accounting for market's decimal places Once market is closed the process cannot be reversed. Note that this implies that once a governance proposal to close the market has been voted in the market will definitely close at the enactment time of that vote at the latest. While the market is still open it's still possible to submit additional governance votes to close the market, however they'll only have any effect if their enactment date is prior to that of the market closure proposal which has already passed. If the market is in an auction of any type excluding the opening auction at the time the market closure governance proposal gets enacted, then the auction should uncross immediately, any trades resulting from it should be generated at the auction uncrossing price and then the system should proceed to close the market using the price (if applicable) provided by the proposal being enacted. If the market is in opening auction when the governance proposal to close it gets enacted then auction shouldn't uncross, market closes trivially as no trades have yet been generated. -Attempting to enact the market closure governance proposal on a market in a `settled` [state](./0043-MKTL-market_lifecycle.md#market-status-descriptions) has no effect. When closing a market which needs the final price with a governance vote it's always the price supplied with the governance vote being enacted that gets used, even if the oracle price is available at that time. +Attempting to enact the market closure governance proposal on a market in a `settled` [state](./0043-MKTL-market_lifecycle.md#market-status-descriptions) has no effect. When closing a market which needs the final price with a governance vote it's always the price supplied with the governance vote being enacted that gets used, even if the oracle price is available at that time. Please note that the price supplied with the vote needs no further conversion as it's already specified in market decimal places. The state of a market successfully closed by the governance vote should be `closed`. From a1730c15faa278c3154380f6ac144513d5246ffe Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 5 Jul 2023 17:17:44 +0200 Subject: [PATCH 233/649] refactor: clarify auction uncrossing behaviour --- protocol/0028-GOVE-governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 13a6c78bf..22a22cc97 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -388,13 +388,13 @@ The state of a market successfully closed by the governance vote should be `clos This proposal puts the market into an auction mode which can only be exit with a governance proposal to unsuspend the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. -A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. +A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. Parties can submit the relevant order types just like in an other auction. If the market is already suspended via governance when another vote gets enacted then that vote has no effect. ### 6.3. Unsuspend the market -This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. +This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. When the market leaves the auction any trades resulting from it should be generated at the auction uncrossing price as is done for any other auction type. If the market is not suspended when the vote to unsuspend the market gets enacted then that vote has no effect. From 86ee5dc3121a979aac174dd70310251ee4ded294 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 6 Jul 2023 12:34:58 +0200 Subject: [PATCH 234/649] refacgtor: "unsuspend" -> resume --- protocol/0028-GOVE-governance.md | 10 +++++----- protocol/0043-MKTL-market_lifecycle.md | 6 +++--- wordlist.txt | 3 --- 3 files changed, 8 insertions(+), 11 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 22a22cc97..2215a6395 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -386,17 +386,17 @@ The state of a market successfully closed by the governance vote should be `clos ### 6.2. Suspend the market -This proposal puts the market into an auction mode which can only be exit with a governance proposal to unsuspend the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. +This proposal puts the market into an auction mode which can only be exit with a governance proposal to resume the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. Parties can submit the relevant order types just like in an other auction. If the market is already suspended via governance when another vote gets enacted then that vote has no effect. -### 6.3. Unsuspend the market +### 6.3. Resume the market This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. When the market leaves the auction any trades resulting from it should be generated at the auction uncrossing price as is done for any other auction type. -If the market is not suspended when the vote to unsuspend the market gets enacted then that vote has no effect. +If the market is not suspended when the vote to resume the market gets enacted then that vote has no effect. ## 7. Freeform governance proposal @@ -518,9 +518,9 @@ APIs should also exist for clients to: - Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) - Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) - Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) -- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-113) +- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to resume the market. (0028-GOVE-113) - Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) -- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) +- Resuming a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) - A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) - Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117) - Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index cd946bb62..4d8d8b278 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -311,10 +311,10 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. Once the governance proposal to suspend the market gets enacted the market gets immediately put into auction mode, if market was already in auction mode it remains in it. 1. No cashflows are exchanged when market has been suspended via a governance proposal. 1. Parties cannot modify their open interest -1. The prerequisite for a market to go out of auction mode is now a successful enactment of a governance proposal to unsuspend that market. +1. The prerequisite for a market to go out of auction mode is now a successful enactment of a governance proposal to resume that market. -### Market gets unsuspended via a governance proposal +### Market gets resumed via a governance proposal -1. Once the governance proposal to unsuspend the market gets enacted the market can now leave the auction. +1. Once the governance proposal to resumed the market gets enacted the market can now leave the auction. 1. If no other auction triggers are active the market goes back into its default trading mode immediately (auction gets uncrossed and trades get generated). 1. If other auction triggers are active the market remains in auction mode until these allow it to leave it. diff --git a/wordlist.txt b/wordlist.txt index 0f992af07..9a18ad2a7 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -279,9 +279,6 @@ unstake unstaked unstakes unstaking -unsuspend -unsuspended -unsuspending unvested url USD From 2c27bd3f9a2bf396986feee1df7df525f424c387 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 6 Jul 2023 15:19:50 +0200 Subject: [PATCH 235/649] refactor: add bit about perps --- protocol/0028-GOVE-governance.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 2215a6395..4dc5b3199 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -384,6 +384,8 @@ Attempting to enact the market closure governance proposal on a market in a `set The state of a market successfully closed by the governance vote should be `closed`. +Please note that certain types of markets like [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) may perform additional actions during governance closure, refer to their specs for details. + ### 6.2. Suspend the market This proposal puts the market into an auction mode which can only be exit with a governance proposal to resume the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. From 97cd0878f69237c76559f6cbbca3db16750b01ee Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 10 Jul 2023 16:15:40 +0200 Subject: [PATCH 236/649] feat: update 0081-SUCM-005 --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index e8a978982..ab323a2bc 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -69,7 +69,7 @@ It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) vi It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor of the aforementioned cancelled / to be cancelled with different `market_decimal_places` and `position_decimal_places`; the LPs virtual stakes are carried over (0081-SUCM-015). -Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market's parent market Id field is cleared. When it clears the opening auction it gets no insurance pool from the parent and no virtual stakes get carried over (0081-SUCM-005). +Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market is "Rejected" and all LP funds will be released. (0081-SUCM-005). A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). From 6334d7cf5ceb06db78085ed117e1e3413ed0f969 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 10 Jul 2023 16:31:40 +0200 Subject: [PATCH 237/649] feat: change product to product type --- protocol/0081-SUCM-successor_markets.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index ab323a2bc..728f9be77 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -22,7 +22,7 @@ Moreover, part of the insurance pool of a parent market can be earmarked for tra ## Specifying a parent market and timing details A market [governance] proposal for a successor market must contain all the information of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. -The product, settlement asset, and margin asset must match but all other inputs can be different (e.g. position and price decimal places, risk model, price monitoring, termination and settlement oracles etc.). +The product type, settlement asset, and margin asset must match but all other inputs can be different (e.g. position and price decimal places, risk model, price monitoring, termination and settlement oracles etc.). For [spot markets](./0080-SPOT-product_builtin_spot.md) base and quote assets must match. The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` @@ -62,7 +62,7 @@ At the end of opening auction, if the parent market still exists, the fraction o Market proposal may specify parent market ID. If it does then: - It must also specify insurance pool fraction (0081-SUCM-001) -- The product, settlement asset and margin asset must match between parent and successor; if not proposal is rejected (0081-SUCM-002) +- The product type, settlement asset and margin asset must match between parent and successor; if not proposal is rejected (0081-SUCM-002) - It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). From dd1e8aeb8225e30049071a7e1faa6db348ac6dbd Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 10 Jul 2023 16:35:39 +0200 Subject: [PATCH 238/649] feat: update AC 005 --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 728f9be77..ba42bca8b 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -69,7 +69,7 @@ It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) vi It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor of the aforementioned cancelled / to be cancelled with different `market_decimal_places` and `position_decimal_places`; the LPs virtual stakes are carried over (0081-SUCM-015). -Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets the share of the insurance pool and the virtual stakes get carried over. Once the first market clears the opening auction the other market is "Rejected" and all LP funds will be released. (0081-SUCM-005). +Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets a share of the insurance pool, and the virtual stakes get carried over. Once the first market clears the opening auction, the other market is "Rejected," and all assets committed into LP bond accounts will be immediately released. Orders placed into the opening auction will be canceled, and the assets held to support any party's orders will be released. (0081-SUCM-005). A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). From 33285932b948194ed3b9d9c127ebfebb46db55a0 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Mon, 10 Jul 2023 16:51:02 +0200 Subject: [PATCH 239/649] chore: typo --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index ba42bca8b..f0ad148b2 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -69,7 +69,7 @@ It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) vi It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor of the aforementioned cancelled / to be cancelled with different `market_decimal_places` and `position_decimal_places`; the LPs virtual stakes are carried over (0081-SUCM-015). -Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets a share of the insurance pool, and the virtual stakes get carried over. Once the first market clears the opening auction, the other market is "Rejected," and all assets committed into LP bond accounts will be immediately released. Orders placed into the opening auction will be canceled, and the assets held to support any party's orders will be released. (0081-SUCM-005). +Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets a share of the insurance pool, and the virtual stakes get carried over. Once the first market clears the opening auction, the other market is "Rejected," and all assets committed into LP bond accounts will be immediately released. Orders placed into the opening auction will be cancelled, and the assets held to support any party's orders will be released. (0081-SUCM-005). A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). From a4fbb40e6594bc923b2e04700a9d7fedd219a469 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 7 Jul 2023 12:51:04 +0200 Subject: [PATCH 240/649] refactor: lower bound on market data emission freq --- protocol/0009-MRKP-mark_price.md | 5 +++-- protocol/0021-MDAT-market_data_spec.md | 4 ++++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 6c2f981ea..bf507f7ac 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -8,7 +8,8 @@ Introduce a network parameter `network.markPriceUpdateMaximumFrequency` with min ## Acceptance criteria -- The mark price must be set when the market leaves opening auction (0009-MRKP-002) +- The mark price must be set when the market leaves opening auction. (0009-MRKP-002) +- Each time the mark price changes the market data event containing the new mark price should be emitted. Specifically, the mark price set after leaving each auction, every interim mark price as well as the mark price based on last trade used at market termination and the one based on oracle data used for final settlement should all be observable from market data events. (0009-MRKP-009) Algorithm 1: @@ -16,7 +17,7 @@ Algorithm 1: - If `network.markPriceUpdateMaximumFrequency>0` then out of a sequence of transactions with the same time-stamp the last transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade but only provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last update. (0009-MRKP-007) - A transaction that doesn't result in a trade does not cause the mark price to change. (0009-MRKP-004) - A transaction out of a sequence of transactions with the same time stamp which isn't the last trade-causing transaction will *not* result in a mark price change. (0009-MRKP-008) -- The mark price must be using market decimal place setting (0009-MRKP-006) +- The mark price must be using market decimal place setting. (0009-MRKP-006) ## Guide-level explanation diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index bcf58bef0..ed155e60c 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -59,6 +59,10 @@ List of market data fields to be available via the API. All these values can be - **Price monitoring bounds** one or more price monitoring bounds for the current timestamp. - **Liquidity provider fee share** share of the accrued fees each liquidity provider is eligible to. +### Market data events + +Market data events should be emitted with sufficient frequency so that each mark price change happening in the market can be captured by just observing the market data events. + ## Pseudo-code / Examples See Test cases From c35bd7a71b7e00784d4e46073f817683f90b9d9f Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 7 Jul 2023 12:47:38 +0200 Subject: [PATCH 241/649] refactor: remove LP bonus account --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 9 ++++----- protocol/0044-LIME-lp_mechanics.md | 10 +++++----- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 03e2829a6..9f03f2202 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -295,8 +295,7 @@ $$ For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -Transfer all unpaid-out rewards left in LP-per-market fee accounts into a temporary (one per market) bonus distribution account. -Record its balance to be $B$. +Record the remaining balance of market LP fee account as $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. $$ @@ -305,7 +304,7 @@ $$ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". -Note that after this process completes the balance of the temporary (one per market) bonus distribution account described above **must be zero** and the account may be destroyed (and recreated again when needed). +Note that after this process completes the balance of the market LP fee account **must be zero**. There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's transfer this to a fixed example. @@ -396,7 +395,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads ### SLA Performance bonus transfers -- The balance of the per-market liquidity fee bonus distribution account should always be zero after bonus distribution is completed (0042-LIQF-043) -- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred to the bonus account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) +- The balance of the per-market liquidity fee account should always be zero after bonus distribution is completed (0042-LIQF-043) +- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should left in the LP fee account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) - With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 90ef01c30..2a85e5121 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -319,25 +319,25 @@ Note: ### Qualifying Order Types - Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) -- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment (0044-LIME-029) +- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-029) ### Snapshot -- A snapshot must include the bonus accounts, fee accounts and their balances so that after a node is started using the snapshot they can retain the two accounts and their balances (0044-LIME-032) +- A snapshot must include the per-market LP fee accounts and their balances so that after a node is started using the snapshot it can retain the LP fee accounts and their balances for each market. (0044-LIME-032) ### Protocol upgrade -- After a protocol upgrade the bonus accounts, fee accounts and their balances are retained (0044-LIME-033) +- After a protocol upgrade the per-market LP fee accounts and their balances are retained (0044-LIME-033) ### Checkpoint -- Bonus and fee accounts must be included in the checkpoint and where the network is down +- Per-market LP fee accounts must be included in the checkpoint and where the network is down - Rewards accrued during the down time will be actioned when the network is available (0044-LIME-034) - Fees to be paid during the down time will be actioned when the network is available (0044-LIME-035) #### Network History - Data node restored from network history segments -- A datanode restored from network history will contain any bonus and fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-036) +- A datanode restored from network history will contain any per-market LP fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-036) #### Network parameters validation From ac4de0d31b4989de3effd9550e8686b9fc5cb130 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 7 Jul 2023 15:55:28 +0200 Subject: [PATCH 242/649] refactor: reword LP vs aggregate accounts --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 14 ++++++-------- protocol/0044-LIME-lp_mechanics.md | 8 ++++---- 2 files changed, 10 insertions(+), 12 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 9f03f2202..06304d1b1 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -203,13 +203,13 @@ The liquidity score should always be rounded to 10 decimal places to prevent spu ### Distributing fees into LP-per-market fee account -On every trade, liquidity fee should be collected immediately into the market LP fee account. +On every trade, liquidity fee should be collected immediately into the market's aggregate LP fee account. The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market LP fee account. +A network parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market's aggregate LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.calculationTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. -The liquidity fees are transferred from the market LP fee account into the LP-per-market fee account, pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. +The liquidity fees are transferred from the market's aggregate LP fee account into the LP-per-market fee account, pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. The LP parties don't control the LP-per-market fee account; the fees from there are then transferred to the LPs' general account at the end epoch as described below. @@ -295,7 +295,7 @@ $$ For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -Record the remaining balance of market LP fee account as $B$. +Transfer the remaining account from each LP-per-market fee account back into the market's aggregate LP fee account. Record the total inflow as a result of that operation as $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. $$ @@ -304,8 +304,6 @@ $$ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". -Note that after this process completes the balance of the market LP fee account **must be zero**. - There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's transfer this to a fixed example. @@ -395,7 +393,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads ### SLA Performance bonus transfers -- The balance of the per-market liquidity fee account should always be zero after bonus distribution is completed (0042-LIQF-043) -- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should left in the LP fee account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) +- The net inflow and outflow into and out of the market's aggregate LP fee account should be zero as a result of penalty collection and bonus distribution. (0042-LIQF-043) +- With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred back into market's aggregate LP fee account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) - With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 2a85e5121..4a2c84f79 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -323,21 +323,21 @@ Note: ### Snapshot -- A snapshot must include the per-market LP fee accounts and their balances so that after a node is started using the snapshot it can retain the LP fee accounts and their balances for each market. (0044-LIME-032) +- A snapshot must include the aggregate LP fee accounts and their balances so that after a node is started using the snapshot it can retain the aggregate LP fee accounts and their balances for each market. (0044-LIME-032) ### Protocol upgrade -- After a protocol upgrade the per-market LP fee accounts and their balances are retained (0044-LIME-033) +- After a protocol upgrade each market's aggregate LP fee accounts and their balances are retained (0044-LIME-033) ### Checkpoint -- Per-market LP fee accounts must be included in the checkpoint and where the network is down +- Each market's aggregate LP fee accounts must be included in the checkpoint and where the network is down - Rewards accrued during the down time will be actioned when the network is available (0044-LIME-034) - Fees to be paid during the down time will be actioned when the network is available (0044-LIME-035) #### Network History - Data node restored from network history segments -- A datanode restored from network history will contain any per-market LP fee accounts created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-036) +- A datanode restored from network history will contain each market's aggregate LP fee accounts which were created prior to the restore and these can be retrieved via APIs on the new datanode. (0044-LIME-036) #### Network parameters validation From e683579af995e0619c8367db16acbc4b460a5fcd Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 10 Jul 2023 17:16:12 +0200 Subject: [PATCH 243/649] refactpr: Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 06304d1b1..bef584c06 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -295,7 +295,7 @@ $$ For each LP transfer $(1-p_i^n) \times \text{ amount in LP-per-market fee account}$ to their general account with a transfer type that marks this as the "LP net liquidity fee distribution". -Transfer the remaining account from each LP-per-market fee account back into the market's aggregate LP fee account. Record the total inflow as a result of that operation as $B$. +Transfer the remaining amount from each LP-per-market fee account back into the market's aggregate LP fee account. Record the total inflow as a result of that operation as $B$. Let $b_i := (1-p_i^n) \times w_i$ and renormalise $b_i$s so that they sum up to $1$ i.e. $$ From 75403ec84081191dbfef493afa720c421915cc17 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 15:18:44 +0200 Subject: [PATCH 244/649] feat: resolve conflict --- protocol/0009-MRKP-mark_price.md | 10 +- protocol/0028-GOVE-governance.md | 283 +++++++++++++++++-------------- 2 files changed, 157 insertions(+), 136 deletions(-) diff --git a/protocol/0009-MRKP-mark_price.md b/protocol/0009-MRKP-mark_price.md index 033348a77..353389907 100644 --- a/protocol/0009-MRKP-mark_price.md +++ b/protocol/0009-MRKP-mark_price.md @@ -8,15 +8,16 @@ Introduce a network parameter `network.markPriceUpdateMaximumFrequency` with min ## Acceptance criteria -- The mark price must be set when the market leaves opening auction (0009-MRKP-002) +- The mark price must be set when the market leaves opening auction. (0009-MRKP-002) +- Each time the mark price changes the market data event containing the new mark price should be emitted. Specifically, the mark price set after leaving each auction, every interim mark price as well as the mark price based on last trade used at market termination and the one based on oracle data used for final settlement should all be observable from market data events. (0009-MRKP-009) Algorithm 1: -- If `network.markPriceUpdateMaximumFrequency=0s` then any transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade. (0009-MRKP-003)(0009-SP-MRKP-003) -- If `network.markPriceUpdateMaximumFrequency>0` then out of a sequence of transactions with the same time-stamp the last transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade but only provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last update. (0009-MRKP-007)(0009-SP-MRKP-007) +- If `network.markPriceUpdateMaximumFrequency=0s` then any transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade. (0009-MRKP-003) +- If `network.markPriceUpdateMaximumFrequency>0` then out of a sequence of transactions with the same time-stamp the last transaction that results in one or more trades causes the mark price to change to the value of the last trade and only the last trade but only provided that at least `network.markPriceUpdateMaximumFrequency` has elapsed since the last update. (0009-MRKP-007) - A transaction that doesn't result in a trade does not cause the mark price to change. (0009-MRKP-004) - A transaction out of a sequence of transactions with the same time stamp which isn't the last trade-causing transaction will *not* result in a mark price change. (0009-MRKP-008) -- The mark price must be using market decimal place setting (0009-MRKP-006)(0009-SP-MRKP-006) +- The mark price must be using market decimal place setting. (0009-MRKP-006) ## Guide-level explanation @@ -71,3 +72,4 @@ The mark price is set to the higher / lower of the last traded price, bid/offer. ### 5. Defined as part of the product The *Mark Price* may be calculated using an algorithm defined by the product -- and 'selected' by a market parameter. + diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 9dcf40d3a..c25d7e11b 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -275,7 +275,7 @@ Enactment of an asset modification proposal is: The below table shows the allowable combinations of source and destination account types for a transfer that's initiated by a governance proposal. -| Source type | Destination type | Governance transfer permitted | +| Source type | Destination type | Governance initiated transfer permitted | | --- | --- | --- | | Party account (any type) | Any | No | | Network treasury | Network treasury | No | @@ -343,26 +343,26 @@ transfer_amount == min( ### Transfer cancellation -This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance transfer. Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal. +This is done as a governance proposal. Takes a transfer ID (which is the proposal ID of the original transfer) and would cancel a recurring governance initiated transfer. Only recurring governance initiated transfers can be cancelled via governance initiated transfer cancellation proposal. Trying to cancel any other transfer should fail upon validation of the proposal. ### Checkpoint/snapshot -Enacted and active transfers (i.e. scheduled one off governance transfers, or recurring governance transfers) must be included in LNL banking checkpoint and resume after the checkpoint restore. +Enacted and active transfers (i.e. scheduled one off governance initiated transfers, or recurring governance initiated transfers) must be included in LNL banking checkpoint and resume after the checkpoint restore. -All in memory active governance transfers must be included in the snapshot of the banking engine. +All in memory active governance initiated transfers must be included in the snapshot of the banking engine. ### Additional information 1. When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with different type (i.e. similar to one-off, and recurring of regular transfers, there are governance-one-off and governance-recurring types). At the time of enactment no amount is attached to the transfer and it will show 0. 2. When a transfer is _made_ an event is emitted with the actual amount being transfers. The status of the transfer will depend on the type of the transfer. 3. When the transfer reaches a terminal state, being stopped, rejected, done, cancelled an event is emitted indicating the status. -4. Enacted governance transfers are therefore available to be queried via the regular transfer API in data node. +4. Enacted governance initiated transfers are therefore available to be queried via the regular transfer API in data node. 5. Governance initiated transfers are subject to neither minimum transfer amounts nor to fees. ## 6. Change market state A governance proposal to change the state of the market. -Multiple concurrent proposals are allowed. If more than one gets successfully voted in the one which arrived last gets used. If a proposal has already been successful then additional market state change proposals are still allowed as long as their enactment date is no later then that of the last successful vote. +Multiple concurrent proposals are allowed. Market change proposal [creation](#market-change-proposal) and [voting](#market-change-proposal-outcome) rules apply. @@ -374,21 +374,31 @@ Any type of market (either fixed expiry market or perpetual) can be closed via a A proposal to close a market contains: -1. an enactment time -1. final settlement price (not required for spot markets) +1. final settlement price (not required for spot markets) formatted accounting for market's decimal places -Once market is closed the process cannot be reversed. +Once market is closed the process cannot be reversed. Note that this implies that once a governance proposal to close the market has been voted in the market will definitely close at the enactment time of that vote at the latest. While the market is still open it's still possible to submit additional governance votes to close the market, however they'll only have any effect if their enactment date is prior to that of the market closure proposal which has already passed. + +If the market is in an auction of any type excluding the opening auction at the time the market closure governance proposal gets enacted, then the auction should uncross immediately, any trades resulting from it should be generated at the auction uncrossing price and then the system should proceed to close the market using the price (if applicable) provided by the proposal being enacted. If the market is in opening auction when the governance proposal to close it gets enacted then auction shouldn't uncross, market closes trivially as no trades have yet been generated. + +Attempting to enact the market closure governance proposal on a market in a `settled` [state](./0043-MKTL-market_lifecycle.md#market-status-descriptions) has no effect. When closing a market which needs the final price with a governance vote it's always the price supplied with the governance vote being enacted that gets used, even if the oracle price is available at that time. Please note that the price supplied with the vote needs no further conversion as it's already specified in market decimal places. + +The state of a market successfully closed by the governance vote should be `closed`. + +Please note that certain types of markets like [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) may perform additional actions during governance closure, refer to their specs for details. ### 6.2. Suspend the market -This proposal puts the market into an auction mode which can only be exit with a governance proposal to unsuspend the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. +This proposal puts the market into an auction mode which can only be exit with a governance proposal to resume the market. It can be applied to a market that's in any of the active (accepting orders) states including the opening auction. + +A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. Parties can submit the relevant order types just like in an other auction. -A market that's been suspended can't have the open volume changed or margin account balances reduced for any of the parties within the market. +If the market is already suspended via governance when another vote gets enacted then that vote has no effect. +### 6.3. Resume the market -### 6.3. Unsuspend the market +This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. When the market leaves the auction any trades resulting from it should be generated at the auction uncrossing price as is done for any other auction type. -This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. +If the market is not suspended when the vote to resume the market gets enacted then that vote has no effect. ## 7. Freeform governance proposal @@ -447,25 +457,25 @@ APIs should also exist for clients to: ## Acceptance Criteria -- As a user, I can create a new proposal, assuming my staking balance matches or exceeds `minProposerBalance` network parameter for my proposal type (0028-GOVE-001)(0028-SP-GOVE-001) -- As a user, I can list the open proposals on the network (0028-GOVE-002)(0028-SP-GOVE-002) -- As a user, I can get a list of all proposals I voted for (0028-GOVE-003)(0028-SP-GOVE-003) -- As a user, I can receive notification when a new proposal is created and may require attention. (0028-GOVE-004)(0028-SP-GOVE-004) -- As the vega network, all votes from eligible users for an existing proposal are accepted when the proposal is still open (0028-GOVE-005)(0028-SP-GOVE-005) -- As the vega network, all votes received before the proposal is [active](#lifecycle-of-a-proposal), or once the proposal voting period is finished, are _rejected_ (0028-GOVE-006)(0028-SP-GOVE-006) -- As the vega network, once the voting period is finished, I validate the result based on the parameters of the proposal used to decide the outcome of it. (0028-GOVE-007)(0028-SP-GOVE-007) -- As the vega network, proposals that set enactment time before closing time are rejected as invalid (0028-GOVE-009)(0028-SP-GOVE-009) -- As the vega network, proposals that set closing time beyond the relevant `maxClose` parameter are rejected as invalid (0028-GOVE-010)(0028-SP-GOVE-010) -- As a user, I can vote for an existing proposal if I have more than the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-014)(0028-SP-GOVE-014) -- As a user, my vote for an existing proposal is rejected if I have less the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-015)(0028-SP-GOVE-015) -- As a user, my vote for an existing proposal is rejected if I have less than the relevant `minVoterBalance` governance tokens in my staking account even if I have more than `minVoterBalance` governance tokens in my general or margin accounts (0028-GOVE-016)(0028-SP-GOVE-016) +- As a user, I can create a new proposal, assuming my staking balance matches or exceeds `minProposerBalance` network parameter for my proposal type (0028-GOVE-001) +- As a user, I can list the open proposals on the network (0028-GOVE-002) +- As a user, I can get a list of all proposals I voted for (0028-GOVE-003) +- As a user, I can receive notification when a new proposal is created and may require attention. (0028-GOVE-004) +- As the vega network, all votes from eligible users for an existing proposal are accepted when the proposal is still open (0028-GOVE-005) +- As the vega network, all votes received before the proposal is [active](#lifecycle-of-a-proposal), or once the proposal voting period is finished, are _rejected_ (0028-GOVE-006) +- As the vega network, once the voting period is finished, I validate the result based on the parameters of the proposal used to decide the outcome of it. (0028-GOVE-007) +- As the vega network, proposals that set enactment time before closing time are rejected as invalid (0028-GOVE-009) +- As the vega network, proposals that set closing time beyond the relevant `maxClose` parameter are rejected as invalid (0028-GOVE-010) +- As a user, I can vote for an existing proposal if I have more than the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-014) +- As a user, my vote for an existing proposal is rejected if I have less the relevant `minVoterBalance` governance tokens in my staking account. (0028-GOVE-015) +- As a user, my vote for an existing proposal is rejected if I have less than the relevant `minVoterBalance` governance tokens in my staking account even if I have more than `minVoterBalance` governance tokens in my general or margin accounts (0028-GOVE-016) - As a user, I can vote multiple times for the same proposal if I have more than the relevant `minVoterBalance` governance tokens in my staking account - - Only my most recent vote is counted (0028-GOVE-017)(0028-SP-GOVE-017) -- When calculating the participation rate of a proposal, the participation rate of the votes takes into account the total supply of the governance asset. (0028-GOVE-018)(0028-SP-GOVE-018) -- If a new proposal is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal and can be queried via APIs separately from the general network parameters. (0028-GOVE-036)(0028-SP-GOVE-036) -- If a new proposal "P" is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal. If an independent network parameter change proposal is enacted changing either required participation of majority then proposal "P" uses its own values for participation and majority; not the newly enacted ones. (0028-GOVE-037)(0028-SP-GOVE-037) -- All proposals with a title field that is empty, or not between 1 and 100 characters, will be rejected (0028-GOVE-039)(0028-SP-GOVE-039) -- Reject any proposal that defines a risk parameter outside it's intended boundaries (0028-GOVE-040)(0028-GSP-OVE-040) + - Only my most recent vote is counted (0028-GOVE-017) +- When calculating the participation rate of a proposal, the participation rate of the votes takes into account the total supply of the governance asset. (0028-GOVE-018) +- If a new proposal is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal and can be queried via APIs separately from the general network parameters. (0028-GOVE-036) +- If a new proposal "P" is successfully submitted to the network (passing initial validation) the required participation rate and majority for success are defined and copied to the proposal. If an independent network parameter change proposal is enacted changing either required participation of majority then proposal "P" uses its own values for participation and majority; not the newly enacted ones. (0028-GOVE-037) +- All proposals with a title field that is empty, or not between 1 and 100 characters, will be rejected (0028-GOVE-039) +- Reject any proposal that defines a risk parameter outside it's intended boundaries (0028-GOVE-040) - risk aversion lambda: 1e-8 <= x < 0.1 - tau: 1e-8 <= x <= 1 - mu: -1e-6 <= x <= 1e-6 @@ -476,159 +486,168 @@ APIs should also exist for clients to: #### New Asset proposals -- New asset proposals cannot be created before [`limits.assets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-063)(0028-SP-GOVE-063) -- An asset proposal with a negative or non-integer value supplied for asset decimal places gets rejected. (0028-GOVE-059)(0028-SP-GOVE-059) +- New asset proposals cannot be created before [`limits.assets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-063) +- An asset proposal with a negative or non-integer value supplied for asset decimal places gets rejected. (0028-GOVE-059) #### New Market proposals -- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-008)(0028-SP-GOVE-008) -- New market proposals cannot be created before [`limits.markets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-024)(0028-SP-GOVE-024) -- A market that has been proposed and successfully voted through doesn't leave the opening auction until the `enactment date/time` is reached and until sufficient [liquidity commitment](./0038-OLIQ-liquidity_provision_order_type.md) has been made for the market. Sufficient means that it meets all the criteria set in [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md). (0028-GOVE-025)(0028-SP-GOVE-025) -- A market proposal with a negative or non-integer value supplied for market decimal places gets rejected. (0028-GOVE-061)(0028-SP-GOVE-061) -- A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062)(0028-SP-GOVE-062) +- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-008) +- New market proposals cannot be created before [`limits.markets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-024) +- A market that has been proposed and successfully voted through doesn't leave the opening auction until the `enactment date/time` is reached and until sufficient [liquidity commitment](./0038-OLIQ-liquidity_provision_order_type.md) has been made for the market. Sufficient means that it meets all the criteria set in [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md). (0028-GOVE-025) +- A market proposal with a negative or non-integer value supplied for market decimal places gets rejected. (0028-GOVE-061) +- A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062) #### Market change proposals -- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-033)(0028-SP-GOVE-033) -- Verify that a market change proposal gets enacted if enough LPs participate and vote for. (0028-GOVE-027)(0028-SP-GOVE-027) -- Verify that a market change proposal does _not_ get enacted if enough LPs participate and vote for _BUT_ governance tokens holders participate beyond threshold and vote against (majority not reached). (0028-GOVE-032)(0028-SP-GOVE-032) -- Verify that an enacted market change proposal that doubles the risk model volatility sigma leads to increased margin requirement for all parties. (0028-GOVE-035)(0028-SP-GOVE-035) -- Verify that an enacted market which uses trading terminated key `ktt1` and settlement price key `ksp1` which is changed via governance proposal to use trading terminated key `ktt2` and settlement price key `ksp2` can terminate trading using `ktt2` but cannot terminate trading using `ktt1` and `ksp2` can submit the settlement price causing market to settle but the key `ksp1` cannot settle the market. (0028-GOVE-012)(0028-SP-GOVE-012) -- Verify that an enacted market change proposal that changes price monitoring bounds enters a price monitoring auction upon the _new_ bound being breached (0028-GOVE-034)(0028-SP-GOVE-034) -- Verify that an enacted market change proposal that reduces `market.stake.target.timeWindow` leads to a reduction in target stake if recent open interest is less than historical open interest (0028-GOVE-031)(0028-SP-GOVE-031) -- Attempts to update immutable market parameter(s) cause the market change proposal to be rejected with an appropriate rejection message (0028-GOVE-058)(0028-SP-GOVE-058) -- Verify that if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0` and if a party meets the `governance.proposal.updateMarket.minProposerBalance` threshold then said party can submit a market change proposal. (0028-GOVE-060)(0028-SP-GOVE-060) -- Change of the network parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` will immediately change the minimum proposer ELS for a market change proposal for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-064)(0028-SP-GOVE-064) -- Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065)(0028-SP-GOVE-065) -- Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066)(0028-SP-GOVE-066) -- A market that's attempting to modify any parameters on a market in `proposed` state (i.e. voting hasn't completed) will be rejected. (0028-GOVE-069)(0028-SP-GOVE-069) -- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070)(0028-SP-GOVE-070) -- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071)(0028-SP-GOVE-071) -- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072)(0028-SP-GOVE-072) -- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108)(0028-SP-GOVE-108) -- When multiple market closure governance proposals are submitted and accepted then one to be approved by governance last (i.e latest closing date and vote goes through) is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109)(0028-SP-GOVE-109) -- Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110)(0028-SP-GOVE-110) -- Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111)(0028-SP-GOVE-111) -- Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112)(0028-SP-GOVE-112) -- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to unsuspend the market. (0028-GOVE-113)(0028-SP-GOVE-113) -- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114)(0028-SP-GOVE-114) -- Unsuspending a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115)(0028-SP-GOVE-115) -- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116)(0028-SP-GOVE-116) -- Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117)(0028-SP-GOVE-117) -- Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118)(0028-SP-GOVE-118) +- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-033) +- Verify that a market change proposal gets enacted if enough LPs participate and vote for. (0028-GOVE-027) +- Verify that a market change proposal does _not_ get enacted if enough LPs participate and vote for _BUT_ governance tokens holders participate beyond threshold and vote against (majority not reached). (0028-GOVE-032) +- Verify that an enacted market change proposal that doubles the risk model volatility sigma leads to increased margin requirement for all parties. (0028-GOVE-035) +- Verify that an enacted market which uses trading terminated key `ktt1` and settlement price key `ksp1` which is changed via governance proposal to use trading terminated key `ktt2` and settlement price key `ksp2` can terminate trading using `ktt2` but cannot terminate trading using `ktt1` and `ksp2` can submit the settlement price causing market to settle but the key `ksp1` cannot settle the market. (0028-GOVE-012) +- Verify that an enacted market change proposal that changes price monitoring bounds enters a price monitoring auction upon the _new_ bound being breached (0028-GOVE-034) +- Verify that an enacted market change proposal that reduces `market.stake.target.timeWindow` leads to a reduction in target stake if recent open interest is less than historical open interest (0028-GOVE-031) +- Attempts to update immutable market parameter(s) cause the market change proposal to be rejected with an appropriate rejection message (0028-GOVE-058) +- Verify that if `governance.proposal.updateMarket.minProposerEquityLikeShare = 0.00001` and if a party has no equity-like share in the market, but meets the `governance.proposal.updateMarket.minProposerBalance` threshold then said party can submit a market change proposal. (0028-GOVE-134) +- Change of the network parameter `governance.proposal.updateMarket.minProposerEquityLikeShare` will immediately change the minimum proposer ELS for a market change proposal for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-064) +- Change of the network parameter `governance.proposal.updateMarket.requiredParticipationLP` will immediately change the required LP vote participation (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-065) +- Change of the network parameter `governance.proposal.updateMarket.requiredMajorityLP` will immediately change the required LP vote majority (measured in ELS) a market change proposal requires for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-066) +- A market that's attempting to modify any parameters on a market in `proposed` state (i.e. voting hasn't completed) will be rejected. (0028-GOVE-069) +- A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) +- In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) +- A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) +- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108) +- When multiple market closure governance proposals are submitted and accepted then one to be approved by governance last (i.e latest closing date and vote goes through) is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109) +- Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) +- Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) +- Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) +- Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to resume the market. (0028-GOVE-113) +- Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) +- Resuming a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) +- A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) +- Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117) +- Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118) +- Enacting a market closure governance proposal on a market which is in opening auction closes it immediately without generating any trades. (0028-GOVE-135) +- Enacting a market closure governance proposal on a market which is in auction (of any type except the opening auction) uncrosses that auction at the current uncrossing price, generates the trades and then proceeds to close it using the final price (if applicable to the market type). (0028-GOVE-136) +- Enacting a market closure governance proposal on a market that is in a settled state has no effect. (0028-GOVE-137) +- Enacting a market closure governance proposal on a market that is not in a settled state always uses the final price supplied with the proposal, even when the oracle settlement price is available at that time. (0028-GOVE-138) +- Successful enactment of a market closure proposal changes the state of the market to `closed`. (0028-GOVE-139) + #### Network parameter change proposals -- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-026)(0028-SP-GOVE-026) -- Network parameter change proposals can only propose a change to a single parameter (0028-GOVE-013)(0028-GOVE-013) +- As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-026) +- Network parameter change proposals can only propose a change to a single parameter (0028-GOVE-013) Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeForm`. -- Change of the network parameter `governance.proposal.*.minEnact` will immediately change the minimum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-051)(0028-SP-GOVE-051) -- Change of the network parameter `governance.proposal.*.maxEnact` will immediately change the maximum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-052)(0028-SP-GOVE-052) -- Change of the network parameter `governance.proposal.*.maxClose` will immediately change the maximum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-053)(0028-SP-GOVE-053) -- Change of the network parameter `governance.proposal.*.minClose` will immediately change the minimum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-054)(0028-SP-GOVE-054) -- Change of the network parameter `governance.proposal.*.requiredMajority` or `governance.proposal.*.requiredParticipation` will immediately change the majority (or participation) required for the proposal to pass for all proposals submitted in the future. Proposals that have already been submitted are not affected as they have their own copy of this value. (0028-GOVE-055)(0028-SP-GOVE-055) -- Change of the network parameter `governance.proposal.*.minVoterBalance` will immediately change the minimum governance token balance required to vote on any proposal submitted in the future. Proposals that have already been submitted are unaffected as they have their own copy of this parameter. (0028-GOVE-056)(0028-SP-GOVE-056) -- Change of the network parameter `governance.proposal.*.minProposerBalance` will immediately change minimum governance token balance required to submit any future proposal. Proposals that have already been submitted are unaffected . (0028-GOVE-057)(0028-SP-GOVE-057) +- Change of the network parameter `governance.proposal.*.minEnact` will immediately change the minimum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-051) +- Change of the network parameter `governance.proposal.*.maxEnact` will immediately change the maximum enactment time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-052) +- Change of the network parameter `governance.proposal.*.maxClose` will immediately change the maximum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-053) +- Change of the network parameter `governance.proposal.*.minClose` will immediately change the minimum vote closing time for all future proposals. Proposals that have already been submitted are not affected. (0028-GOVE-054) +- Change of the network parameter `governance.proposal.*.requiredMajority` or `governance.proposal.*.requiredParticipation` will immediately change the majority (or participation) required for the proposal to pass for all proposals submitted in the future. Proposals that have already been submitted are not affected as they have their own copy of this value. (0028-GOVE-055) +- Change of the network parameter `governance.proposal.*.minVoterBalance` will immediately change the minimum governance token balance required to vote on any proposal submitted in the future. Proposals that have already been submitted are unaffected as they have their own copy of this parameter. (0028-GOVE-056) +- Change of the network parameter `governance.proposal.*.minProposerBalance` will immediately change minimum governance token balance required to submit any future proposal. Proposals that have already been submitted are unaffected . (0028-GOVE-057) #### Freeform governance proposals -- A freeform governance proposal with a description field that is empty, or not between 1 and 10,000 characters, will be rejected (0028-GOVE-019)(0028-SP-GOVE-019) -- A freeform governance proposal does not have an enactment period set, and after it closes no action is taken on the system (0028-GOVE-022)(0028-SP-GOVE-022) -- Closed freeform governance proposals can be retrieved from the API along with details of how token holders voted. (0028-GOVE-023)(0028-SP-GOVE-023) +- A freeform governance proposal with a description field that is empty, or not between 1 and 10,000 characters, will be rejected (0028-GOVE-019) +- A freeform governance proposal does not have an enactment period set, and after it closes no action is taken on the system (0028-GOVE-022) +- Closed freeform governance proposals can be retrieved from the API along with details of how token holders voted. (0028-GOVE-023) #### Concurrent governance proposals -- Approved governance proposals sharing the same enactment time should be enacted in the order the proposals were created. (0028-GOVE-067)(0028-SP-GOVE-067) -- Approved governance proposals sharing the same enactment time and changing the same parameter should all be applied, the oldest proposal will be applied first and the newest will be applied last, overwriting the changes made by the older proposals. (0028-GOVE-068)(0028-SP-GOVE-068) +- Approved governance proposals sharing the same enactment time should be enacted in the order the proposals were created. (0028-GOVE-067) +- Approved governance proposals sharing the same enactment time and changing the same parameter should all be applied, the oldest proposal will be applied first and the newest will be applied last, overwriting the changes made by the older proposals. (0028-GOVE-068) -#### Governance Transfer proposals +#### Governance initiated transfer proposals ##### Proposer Requirements -- The transfer proposer must have at a staking balance which matches or exceeds `minProposerBalance` network parameter for this proposal type (0028-GOVE-073)(0028-SP-GOVE-073) +- The transfer proposer must have at a staking balance which matches or exceeds `minProposerBalance` network parameter for this proposal type (0028-GOVE-073) ##### APIs -- Governance transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074)(0028-SP-GOVE-074) +- Governance initiated transfer proposal and all associated data are returned via the governance APIs (0028-GOVE-074) ##### Transfer proposal submission validation -- A proposal to transfer tokens between Network treasury and Party general account(s) is valid (0028-GOVE-128)(0028-SP-GOVE-128) -- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119)(0028-SP-GOVE-119) -- A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120)(0028-SP-GOVE-120) -- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-121)(0028-SP-GOVE-121) -- A proposal to transfer tokens between Market insurance pool account and Network treasury is valid (0028-GOVE-132)(0028-SP-GOVE-132) -- A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122)(0028-SP-GOVE-122) -- Governance transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077)(0028-SP-GOVE-077) -- Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079)(0028-SP-GOVE-079) -- Source can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-080)(0028-SP-GOVE-080) -- For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081)(0028-SP-GOVE-081) -- Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082)(0028-SP-GOVE-082) -- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083)(0028-SP-GOVE-083) -- Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084)(0028-SP-GOVE-084) -- Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085)(0028-SP-GOVE-085) -- Destination Type can be any of the predefined types in the above table (0028-GOVE-086)(0028-SP-GOVE-086) -- Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087)(0028-SP-GOVE-087) -- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088)(0028-SP-GOVE-088) -- Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089)(0028-SP-GOVE-089) -- Destination can be left blank for a transfer type of Network Insurance Pool (0028-GOVE-090)(0028-SP-GOVE-090) -- For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091)(0028-SP-GOVE-091) -- The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092)(0028-SP-GOVE-092) -- For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093)(0028-SP-GOVE-093) - -##### Governance transfer enactment - -- For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094)(0028-SP-GOVE-094) -- A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095)(0028-SP-GOVE-095) -- Transfers can occur for terminated markets (0028-GOVE-096) (0028-SP-GOVE-096) -- Transfers cannot occur for settled markets and a transaction result event will show the transfer failing with an appropriate message (0028-GOVE-097)(0028-SP-GOVE-097) -- Transfers cannot occur for pending markets unless they become active on or before the enactment time of the transfer (0028-GOVE-098)(0028-SP-GOVE-098) +- A proposal to transfer tokens between Network treasury and Party general account(s) is valid (0028-GOVE-128) +- A proposal to transfer tokens between Network treasury and market insurance pool account is valid (0028-GOVE-119) +- A proposal to transfer tokens between Market insurance pool account and Party account(s) is valid (0028-GOVE-120) +- A proposal to transfer tokens between Market insurance pool account and Network treasury is valid (0028-GOVE-132) +- A proposal to transfer tokens between Market insurance pool account and Market insurance pool account is valid (0028-GOVE-122) +- Governance initiated transfer proposals with invalid source or destination account types will get rejected by the blockchain. (0028-GOVE-077) +- Source can be left blank for a transfer type of Network Treasury (0028-GOVE-079) +- For proposal source/destination types of Market Insurance the source/destination must be a valid `marketID` else the proposal is rejected by the blockchain. (0028-GOVE-081) +- Type value can only hold “all or nothing" or "best effort” (0028-GOVE-082) +- Transfer amounts will be accepted and processed in asset precision (0028-GOVE-083) +- Asset specified must be a valid asset address else proposal is rejected (0028-GOVE-084) +- Fraction of balance must be submitted as a positive (else will cause the proposal to reject) and will be processed as a fraction of the source accounts balance (0028-GOVE-085) +- Destination Type can be any of the predefined types in the above table (0028-GOVE-086) +- Source and destination type cannot be the same value else the proposal will be rejected (0028-GOVE-087) +- Transfers can be proposed between market insurance accounts but source and destination accounts cannot be the same value else the proposal will be rejected (0028-GOVE-088) +- Destination must be a valid Vega public key for a transfer type of Party else is rejected (0028-GOVE-089) +- For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091) +- The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092) +- For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) + + +##### Governance initiated transfer enactment + +- For enacted proposals a token transfer will occur at the time of enactment between the source and destination account if sufficient tokens are held in the source account. A transaction result event will show the successful transfer between two accounts (0028-GOVE-094) +- A governance approved recurring transfer will continue even if the source account balance is `0`. In such case the amount transferred will be seen to be `0`. (0028-GOVE-095) +- Transfers can occur for pending, terminated markets, settled markets (0028-GOVE-096) ##### Transferred Amount -- If the type of transfer is “All or nothing” then the minimum of either `fraction_of_balance * source_balance` and the transfer amount is transfers between accounts. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-099)(0028-SP-GOVE-099) -- If the type of transfer is “Best effort” then the transfer amount is derived from the minimum of `proposal.fraction_of_balance * source.balance, proposal.amount, NETWORK_MAX_AMOUNT, NETWORK_MAX_FRACTION * source.balance`. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-100)(0028-SP-GOVE-100) +- If the type of transfer is “All or nothing” then the minimum of either `fraction_of_balance * source_balance` and the transfer amount is transfers between accounts. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-099) +- If the type of transfer is “Best effort” then the transfer amount is derived from the minimum of `proposal.fraction_of_balance * source.balance, proposal.amount, NETWORK_MAX_AMOUNT, NETWORK_MAX_FRACTION * source.balance`. The transfer is recorded in Vega ledger movements even if the amount is derived as zero (0028-GOVE-100) ##### Transfer Fees -- No fees are incurred by the transfer and therefore the the number of tokens deducted from the source account should always equal the tokens added to the destination account (0028-GOVE-101)(0028-SP-GOVE-101) +- No fees are incurred by the transfer and therefore the the number of tokens deducted from the source account should always equal the tokens added to the destination account (0028-GOVE-101) ##### Protocol Upgrade -- Transfer proposals in either a pre or post enactment state are restored after a protocol upgrade (0028-GOVE-102)(0028-SP-GOVE-102) -- Recurring transfers proposed before an upgrade which start before, during or after an upgrade should complete on the proposed end epoch (0028-GOVE-130)(0028-SP-GOVE-130) -- One off delivery transfers proposed before an upgrade which are due to start during or after an upgrade should complete either when the network is available again or at the proposed delivery date/time (0028-GOVE-131)(0028-SP-GOVE-131) +- Transfer proposals in either a pre or post enactment state are restored after a protocol upgrade (0028-GOVE-102) +- Recurring transfers proposed before an upgrade which start before, during or after an upgrade should complete on the proposed end epoch (0028-GOVE-130) +- One off delivery transfers proposed before an upgrade which are due to start during or after an upgrade should complete either when the network is available again or at the proposed delivery date/time (0028-GOVE-131) + + +##### Checkpoints and Snapshots + +- Active or dormant governance initiated transfer (one-off or recurring) must be included in checkpoint and where the network is down during the proposed delivery time, the transfer will occur as soon as the network is available. For recurring transfers the transfers spanning the restore will continue until the end epoch. (0028-GOVE-103) +- Active or dormant governance initiated transfer (one-off or recurring) must be included in snapshots and data nodes which join the network will support retrieval of the transfer data (0028-GOVE-133) + + +##### One Off Delivery transfers -#### Checkpoints and Snapshots +If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. (0028-GOVE-129) -- Active or dormant governance transfer (one-off or recurring) must be included in checkpoint and where the network is down during the proposed delivery time, the transfer will occur as soon as the network is available. For recurring transfers the transfers spanning the restore will continue until the end epoch. (0028-GOVE-103)(0028-SP-GOVE-103) -- Active or dormant governance transfer (one-off or recurring) must be included in snapshots and data nodes which join the network will support retrieval of the transfer data (0028-GOVE-133)(0028-SP-GOVE-133) -##### Recurring Governance transfers +##### Recurring governance initiated transfers -- For a recurring proposal, the proposal is only active from defined start epoch and optional end epoch, the transfer will be executed every epoch while the proposal is active. (0028-GOVE-104)(0028-SP-GOVE-104) +- For a recurring proposal, the proposal is only active from defined start epoch and optional end epoch, the transfer will be executed every epoch while the proposal is active. (0028-GOVE-104) -- Enacted and active recurring governance transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105)(0028-SP-GOVE-105) +- Enacted and active recurring governance initiated transfers must be included in LNL banking checkpoint and resume after the checkpoint restore.(0028-GOVE-105) -- When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106)(0028-SP-GOVE-106) +- When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106) -##### Cancelling governance transfers +##### Cancelling governance initiated transfers -- Only recurring governance transfers can be cancelled by proposing a governance transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107)(0028-SP-GOVE-107) -- After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123)(0028-SP-GOVE-123) -- Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124)(0028-SP-GOVE-124) -- Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125)(0028-GSP-OVE-125) -- When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126)(0028-SP-GOVE-126) +- Only recurring governance initiated transfers can be cancelled by proposing a governance initiated transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) +- After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123) +- Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) +- Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) +- When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126) ##### Network History -- A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127)(0028-SP-GOVE-127) +- A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127) From 195b194e7a11e0761e8de0ef26b061860dd9920f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 15:57:58 +0200 Subject: [PATCH 245/649] feat: address comments from Charlie --- protocol/0011-MARA-check_order_allocate_margin.md | 2 +- protocol/0013-ACCT-accounts.md | 1 + protocol/0033-OCAN-cancel_orders.md | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0011-MARA-check_order_allocate_margin.md b/protocol/0011-MARA-check_order_allocate_margin.md index 37e611bd6..f80c99285 100644 --- a/protocol/0011-MARA-check_order_allocate_margin.md +++ b/protocol/0011-MARA-check_order_allocate_margin.md @@ -13,7 +13,7 @@ Orders should be rejected if we can’t allocate sufficient margin. 1. If an order is amended such that margin requirement is increased and user doesn't have sufficient balance in the general account to top up their margin account then their amend is not executed but the unamended order stays on the book. (0011-MARA-002) 1. In Spot market, if an order is amended such that holding requirement is increased and user doesn't have sufficient balance in the general account to top up their holding account then their amend is not executed but the unamended order stays on the book. (0011-SP-MARA-002) 1. Cancelling an order releases the margin amount back to user's general account, provided the user has no other orders or positions (0011-MARA-003) -In Spot markte, cancelling an order releases the holding amount back to user's general account. (0011-SP-MARA-003) +In Spot market, cancelling an order releases the holding amount back to user's general account. (0011-SP-MARA-003) 1. If an order is amended such that margin requirement is decreased then the amendment is executed successfully. (0011-MARA-004) 1. If an order is partially filled then the margin requirements are recalculated reflecting the reduced order size and new position size. (0011-MARA-005) In Spot market, if an order is partially filled then the holding requirements are recalculated reflecting the reduced order size. (0011-SP-MARA-005) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 49083d363..1dae7e1e1 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -145,3 +145,4 @@ One key difference with staking accounts is that the collateral is not held in a - The balance can only be delegated to Validators (0013-ACCT-015) - The balance cannot be traded, or used as margin, or transferred, or withdrawn (0013-ACCT-016) - Delegated stake remains in the trader's staking account (0013-ACCT-017) + diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index dfbd0746e..434b42679 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -86,3 +86,4 @@ Cancelling an order triggers a margin recalculation for a party. This is true fo - Insert a single order from 2 different traders and cancel one via `partyID` - Insert a single order from 2 different traders and cancel one via `marketID+partyID` and `MarketID` - Insert an order which is not for auction and enter into an auction to force the order to be parked. Cancel the order using all three methods and validate the order is cancelled. + From 9dd6a7ecac2ab6db858bd7500747de57abdca819 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 17:18:01 +0200 Subject: [PATCH 246/649] feat: update market life cycle for spot --- protocol/0017-PART-party.md | 2 +- protocol/0029-FEES-fees.md | 2 +- protocol/0043-MKTL-market_lifecycle.md | 37 +++++++++++++++++-- .../0079-TGAP-transaction_gas_and_priority.md | 2 +- 4 files changed, 37 insertions(+), 6 deletions(-) diff --git a/protocol/0017-PART-party.md b/protocol/0017-PART-party.md index 6cbeabb95..d8a1f800f 100644 --- a/protocol/0017-PART-party.md +++ b/protocol/0017-PART-party.md @@ -36,7 +36,7 @@ The `network` party is a pseudo party. It is used in [position resolution](./001 ## Acceptance Criteria -1. [x] When a [standard party](#standard-party) must be uniquely identified, it must be identified by the public key of an ed25519 keypair (0017-PART-001)(0017-SP-PART-001) +1. [x] When a [standard party](#standard-party) must be uniquely identified, it must be identified by the public key of an ed25519 keypair (0017-PART-001) Note that when and how a party can submit transactions is set out and restricted in: diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index b08ba833c..77d7d6714 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -105,5 +105,5 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010)(0029-SP-FEES-010) - Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011)(0029-SP-FEES-011) - The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012)(0029-SP-FEES-012) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013)(0029-SP-FEES-013) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013)(0029-SP-FEES-013) - A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014)(0029-SP-FEES-014) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 973b89350..e7dcb2bf7 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -253,7 +253,7 @@ It is not possible to submit orders to the market. No parties have margin account balances that are non-zero for the market. Market state is `rejected`. -### Lifecycle happy path (0043-MKTL-002)(0043-SP-MKTL-002) +### Lifecycle happy path (0043-MKTL-002) 1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. @@ -285,8 +285,22 @@ Margin account balances are transferred to the general account. The market state is `settled`. After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +### Lifecycle happy path in Spot market (0043-SP-MKTL-002) -### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003)(0043-SP-MKTL-003) +1. Market `m1` is proposed. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). +Market state is `proposed`. +The LP bond of the party that proposed the market is transferred from general to bond account. +1. Market `m1` is accepted and enters opening auction. +Market state is `pending`. +1. Parties place orders and at least one trade happens in continuous trading mode. +Market state is `active`. +1. Parties place orders so that a [price monitoring auction is triggered](0032-PRIM-price_monitoring.md). +Market state is `suspended`. +1. Price monitoring auction ends and the market is in continuous trading again. +The market state is `active`. +1. When a new governance proposal for "closing" the Spot market, then market state is `trading terminated`. + +### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). 1. Trading terminated data source rings before the market leaves the opening auction (so market never left Pending state so far). @@ -296,7 +310,15 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. -### Market gets closed via a governance proposal (0043-MKTL-004)(0043-SP-MKTL-004) +### Market (Spot) never leaves opening auction, market cancelled by governance proposal(0043-SP-MKTL-003) + +1. A market is proposed, approved by governance process and enters the opening auction (Pending state). +1. Market cancelled before the market leaves the opening auction (so market never left Pending state so far). +1. All orders should be cancelled and holdings returned to respective parties general account for the relevant asset. +1. All LP commitments should be cancelled and their bond returned to the general account for the relevant asset. +1. The market state is set to cancelled. + +### Market gets closed via a governance proposal (0043-MKTL-004) 1. Once the governance proposal to close the market gets enacted any auction that the market may be in gets uncrossed and trades get generated. 1. All the other orders are cancelled and no further trades get generated. @@ -306,6 +328,15 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. All the funds from market specific accounts get released to appropriate accounts; the insurance pool perhaps after the delay to allow for transfer into a successor market. 1. Market gets deleted. +### Market (Spot) gets closed via a governance proposal (0043-SP-MKTL-004) + +1. Once the governance proposal to close the market gets enacted any auction that the market may be in gets uncrossed and trades get generated. +1. All the other orders are cancelled and no further trades get generated. +1. Any new orders get rejected. +1. Liquidity commitments cannot be modified or cancelled. +1. All the funds from market specific accounts get released to appropriate accounts. +1. Market gets deleted. + ### Market gets suspended via a governance proposal 1. Once the governance proposal to suspend the market gets enacted the market gets immediately put into auction mode, if market was already in auction mode it remains in it. diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index f3a3bc430..a3b357310 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -106,7 +106,7 @@ There are three priority categories: ## Acceptance criteria -### Basic happy path test (0079-TGAP-001)(0079-SP-TGAP-001) +### Basic happy path test (0079-TGAP-001) 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 20`. 1. Send `100` transactions with default gas cost to a node (e.g. votes on a proposal) and observe that most block have 5 of these transactions each. From 74603d10a57f173a628c71dfd69d2d83db5da61a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 17:38:48 +0200 Subject: [PATCH 247/649] feat: address comments --- protocol/0057-TRAN-transfers.md | 4 +- protocol/0073-LIMN-limited_network_life.md | 48 ++++++++++++++-------- 2 files changed, 33 insertions(+), 19 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index e745480a1..2a099f142 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -192,7 +192,9 @@ message CancelTransfer { - As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-003)(0057-SP-COSMICELEVATOR-TRAN-003). - As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-004)(0057-SP-COSMICELEVATOR-TRAN-004) - As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005)(0057-SP-TRAN-005) -- As a user I cannot transfer funds from accounts I own but from the type is not supported (e.g. margin, staking). (0057-TRAN-006)(0057-SP-TRAN-006) +- As a user I cannot transfer funds from accounts I own but from the type is not supported: + - for accounts created in a futures market, bond and margin (0057-TRAN-006) + - for accounts created in a spot market, bond and holding (0057-SP-TRAN-006) - As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007)(0057-SP-TRAN-007) - The fee cost is correctly calculated using the network parameter - If I have enough funds to pay transfer and fees, the transfer happens. diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 4fb5d8b54..e6454816f 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -102,10 +102,10 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ## Acceptance criteria -- Checkpoints are created every `network.checkpoint.timeElapsedBetweenCheckpoints` period of time passes. (0073-LIMN-001)(0073-SP-LIMN-001) -- Checkpoint is created every time a party requests a withdrawal transaction on any chain. (0073-LIMN-002)(0073-SP-LIMN-002) -- We can launch a network with any valid checkpoint file. (0073-LIMN-003)(0073-SP-LIMN-003) -- Hash of the checkpoint file is agreed via consensus. (0073-LIMN-005)(0073-SP-LIMN-005) +- Checkpoints are created every `network.checkpoint.timeElapsedBetweenCheckpoints` period of time passes. (0073-LIMN-001) +- Checkpoint is created every time a party requests a withdrawal transaction on any chain. (0073-LIMN-002) +- We can launch a network with any valid checkpoint file. (0073-LIMN-003) +- Hash of the checkpoint file is agreed via consensus. (0073-LIMN-005) ### Test case 1: Withdrawal status is correctly tracked across resets (0073-LIMN-007)(0073-SP-LIMN-007) @@ -226,7 +226,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is no market and there are no market proposals. 1. The party has general account balance in USD of `0` and The party has "signed for withdrawal" `100`. -### Test case 4: Party's Margin Account balance is put in to a General Account balance for that asset after a reset (0073-LIMN-016)(0073-SP-LIMN-016) +### Test case 4a: Party's Margin Account balance is put in to a General Account balance for that asset after a reset (0073-LIMN-016) 1. A party has USD general account balance of 100 USD. 2. That party has USD margin account balance of 100 USD. @@ -234,6 +234,14 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 4. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. 5. That party has a USD general account balance of 200 USD +### Test case 4b: In Spot market, party's Holding Account balance is put in to a General Account balance for that asset after a reset (0073-SP-LIMN-016) + +1. A party has USD general account balance of 100 USD. +2. That party has USD holding account balance of 50 USD. +3. The network is shut down. +4. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. +5. That party has a USD general account balance of 150 USD + ### Test case 5: Add or remove stake during checkpoint restart (0073-LIMN-017)(0073-SP-LIMN-017) 1. There is a Vega token asset. @@ -261,7 +269,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 #### Test case 6.2: `timeElapsedBetweenCheckpoints` set to value outside acceptable range -### Test case 11: Rewards are distributed correctly every epoch including with the use of recurring transfers (0073-LIMN-022)(0073-SP-LIMN-022) +### Test case 11: Rewards are distributed correctly every epoch including with the use of recurring transfers (0073-LIMN-022) - More than one party deposits stake onto Vega - The parties delegate stake to the validators @@ -275,9 +283,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ### Test case 12 -1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023)(0073-SP-LIMN-023) -1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024)(0073-SP-LIMN-024) -1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025)(0073-SP-LIMN-025) +1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023) +1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024) +1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025) 1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026)(0073-SP-LIMN-026) 1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027)(0073-SP-LIMN-027) @@ -317,8 +325,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. System saves LNL checkpoint at a time when undistributed LP fees for the market are > 0. 1. Restart Vega, load LNL checkpoint. 1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029)(0073-SP-LIMN-029) -1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030)(0073-SP-LIMN-030) -1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031)(0073-SP-LIMN-031) +1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030) +1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031) +1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-SP-LIMN-031) 1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032)(0073-SP-LIMN-032) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033)(0073-SP-LIMN-033) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034)(0073-SP-LIMN-034) @@ -330,8 +339,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Restart Vega, load LNL checkpoint. 1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040)(0073-SP-LIMN-040) 1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041)(0073-SP-LIMN-041) -1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042)(0073-SP-LIMN-042) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043)(0073-SP-LIMN-043) +1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) +1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-SP-LIMN-042) +1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044)(0073-SP-LIMN-044) ### Test case 16: Markets can be settled and terminated after restore as proposed @@ -340,7 +350,8 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. 1. A party submits liquidity provision to the market, orders are submitted to the opening auction to allow uncrossing; at least two parties now have a position. -1. Submit the trading terminated transaction and settlement date transaction as set out in the proposal and observe the final settlement cashflows for the parties with positions. (0073-LIMN-050)(0073-SP-LIMN-050) +1. Submit the trading terminated transaction and settlement date transaction as set out in the proposal and observe the final settlement cashflows for the parties with positions. (0073-LIMN-050) +1. In Spot market, market can be closed after a restore. (0073-SP-LIMN-050) 1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051)(0073-SP-LIMN-051) ### Test case 17: Markets with internal time trigger for trading terminated that rings between shutdown and restore @@ -350,9 +361,10 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Restart Vega, load LNL checkpoint at a time which is after trading terminated trigger should have rung. 1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060)(0073-SP-LIMN-060); if it exists it in `cancelled` state. 1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061)(0073-SP-LIMN-061) -1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062)(0073-SP-LIMN-062) +1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062) +1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-SP-LIMN-062) 1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063)(0073-SP-LIMN-063) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064)(0073-SP-LIMN-064) +1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065)(0073-SP-LIMN-065) ### Test case 18: market definition is the same pre and post LNL restore @@ -383,7 +395,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Stop the network. 1. Update the multisig contract. 1. Restart the vega network from the checkpoint created earlier. -1. Vega observes the multisig change and rewards are paid at the end of the current epoch. (0073-LIMN-075)(0073-SP-LIMN-075) +1. Vega observes the multisig change and rewards are paid at the end of the current epoch. (0073-LIMN-075) ### Test case 21: Loading from checkpoint with invalid multisig @@ -393,4 +405,4 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Stop the network. 1. Do not update the multisig contract. 1. Restart the vega network from the checkpoint created earlier. -1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076)(0073-SP-LIMN-076) +1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076) From 23c042a97b8061bd5529286e18f397a098ef0abe Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 17:41:59 +0200 Subject: [PATCH 248/649] feat: remove SP AC from 46/47/48 --- .../0046-DSRM-data_source_signed_message.md | 35 +++---- protocol/0047-DSRF-data_source_filter.md | 97 ++++++++++--------- protocol/0048-DSRI-data_source_internal.md | 83 ++++++++-------- 3 files changed, 109 insertions(+), 106 deletions(-) diff --git a/protocol/0046-DSRM-data_source_signed_message.md b/protocol/0046-DSRM-data_source_signed_message.md index a5b9cba4d..239c2cce9 100644 --- a/protocol/0046-DSRM-data_source_signed_message.md +++ b/protocol/0046-DSRM-data_source_signed_message.md @@ -90,38 +90,38 @@ Where possible, this should be done before the transaction is included in a bloc An [instrument can be created](./0028-GOVE-governance.md) to rely on a signed message data source: -- The instrument must specify a valid signed message data source (0046-DSRM-001)(0046-SP-DSRM-001) -- A market proposal specifying an invalid data source will be rejected (0046-DSRM-002)(0046-SP-DSRM-002) - - This rejection will happen at _the [creation of the proposal](./0028-GOVE-governance.md)_ (0046-DSRM-003)(0046-SP-DSRM-003) +- The instrument must specify a valid signed message data source (0046-DSRM-001) +- A market proposal specifying an invalid data source will be rejected (0046-DSRM-002) + - This rejection will happen at _the [creation of the proposal](./0028-GOVE-governance.md)_ (0046-DSRM-003) Multiple instruments can rely on the same data source: -- Multiple instruments can settle based on the same `SubmitData` message. (0046-DSRM-004)(0046-SP-DSRM-004) -- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different `SubmitData` messages. (0046-DSRM-005)(0046-SP-DSRM-005) -- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different fields from the same `SubmitData` message. (0046-DSRM-006)(0046-SP-DSRM-006) +- Multiple instruments can settle based on the same `SubmitData` message. (0046-DSRM-004) +- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different `SubmitData` messages. (0046-DSRM-005) +- Multiple products can [filter](./0047-DSRF-data_source_filter.md) the same data source differently and settle based on different fields from the same `SubmitData` message. (0046-DSRM-006) `SubmitData` transactions can be submitted by any public key as long as the data included in the transaction is signed by at least one of the keys included in an active signed message data source definition: -- `SubmitData` transactions for active ([see data sourcing framework](./0045-DSRC-data_sourcing.md)) data sources will be accepted regardless of the transaction signer. (0046-DSRM-007)(0046-SP-DSRM-007) -- `SubmitData` transactions by inactive data sources will be rejected. (0046-DSRM-008)(0046-SP-DSRM-008) -- `SubmitData` transactions that are invalid will be rejected. (0046-DSRM-009)(0046-SP-DSRM-009) +- `SubmitData` transactions for active ([see data sourcing framework](./0045-DSRC-data_sourcing.md)) data sources will be accepted regardless of the transaction signer. (0046-DSRM-007) +- `SubmitData` transactions by inactive data sources will be rejected. (0046-DSRM-008) +- `SubmitData` transactions that are invalid will be rejected. (0046-DSRM-009) To be valid, a `SubmitData` transaction must: -- Contain correctly signed data from an active signed message data source, (0046-DSRM-010)(0046-SP-DSRM-010) -- Invalid `SubmitData` transactions must be rejected. (0046-DSRM-011)(0046-SP-DSRM-011) +- Contain correctly signed data from an active signed message data source, (0046-DSRM-010) +- Invalid `SubmitData` transactions must be rejected. (0046-DSRM-011) Ignore any data source tx that is not explicitly required, so this would include a tx: -- For a pubkey never used in a data source (0046-DSRM-013)(0046-SP-DSRM-013) -- For a data source where a filter ignores the message based on its contents (0046-DSRM-014)(0046-SP-DSRM-014) -- For a pubkey only used in data sources referenced by markets (or other things) that are no longer being managed by the core (i.e. once a marked is in Closed or Settled or Cancelled state according to the market framework) or before the enactment date of the market proposal (0046-DSRM-015)(0046-SP-DSRM-015) +- For a pubkey never used in a data source (0046-DSRM-013) +- For a data source where a filter ignores the message based on its contents (0046-DSRM-014) +- For a pubkey only used in data sources referenced by markets (or other things) that are no longer being managed by the core (i.e. once a marked is in Closed or Settled or Cancelled state according to the market framework) or before the enactment date of the market proposal (0046-DSRM-015) Other acceptance: -- Must work with Coinbase oracle (0046-DSRM-012)(0046-SP-DSRM-012) -- Ignore any `SubmitData` tx that is a duplicate (i.e. contains exactly the same data payload and is for the same data source), even if it is signed by a different signer (assuming the source has multiple configured signers) or was submitted by a different Vega key. (0046-DSRM-016)(0046-SP-DSRM-016) -- Messages are accepted that contain the data and the signature (conforming to the Open Oracle specification) Note: do not support (or need to) direct connections to REST APIs, Ethereum smart contracts, etc. conforming to the open oracle spec. (0046-DSRM-017)(0046-SP-DSRM-017) +- Must work with Coinbase oracle (0046-DSRM-012) +- Ignore any `SubmitData` tx that is a duplicate (i.e. contains exactly the same data payload and is for the same data source), even if it is signed by a different signer (assuming the source has multiple configured signers) or was submitted by a different Vega key. (0046-DSRM-016) +- Messages are accepted that contain the data and the signature (conforming to the Open Oracle specification) Note: do not support (or need to) direct connections to REST APIs, Ethereum smart contracts, etc. conforming to the open oracle spec. (0046-DSRM-017) ## Notes @@ -131,3 +131,4 @@ Other acceptance: - There is no explicit block list for unreliable signed message data sources or malicious public keys or addresses (signers). - There is no API required for signed message data sources except for the APIs defined for all data sources in the data sourcing framework spec. - There is no requirement for a party operating a signed message data source (i.e. the holder of the private key) to hold any collateral or any of the governance asset. + diff --git a/protocol/0047-DSRF-data_source_filter.md b/protocol/0047-DSRF-data_source_filter.md index c73b2fa39..affa0a25c 100644 --- a/protocol/0047-DSRF-data_source_filter.md +++ b/protocol/0047-DSRF-data_source_filter.md @@ -9,30 +9,30 @@ For example, a [signed message](./0046-DSRM-data_source_signed_message.md) data ```proto DATA_SOURCE = SignedMessage{ pubkey=0xA45e...d6 }, gives: - { ticker: 'TSLA', timestamp: '2021-12-31T00:00:00Z', price: 420.69} - { ticker: 'BTCUSD', timestamp: '2021-12-31T00:00:00Z', price: 42069.303} - { ticker: 'ETHGAS', timestamp: '2021-12-31T00:00:00Z', price: 100.1} - ... - { ticker: 'TSLA', timestamp: '2021-12-31T01:00:00Z', price: 469.20} - { ticker: 'BTCUSD', timestamp: '2021-12-31T01:00:00Z', price: 52069.42} - { ticker: 'ETHGAS', timestamp: '2021-12-31T01:00:00Z', price: 101.0} - ... - { ticker: 'TSLA', timestamp: '2021-12-31T02:00:00Z', price: 440.20} - { ticker: 'BTCUSD', timestamp: '2021-12-31T02:00:00Z', price: 501.666} - { ticker: 'ETHGAS', timestamp: '2021-12-31T02:00:00Z', price: 90.92} - ... and so on ... + { ticker: 'TSLA', timestamp: '2021-12-31T00:00:00Z', price: 420.69} + { ticker: 'BTCUSD', timestamp: '2021-12-31T00:00:00Z', price: 42069.303} + { ticker: 'ETHGAS', timestamp: '2021-12-31T00:00:00Z', price: 100.1} + ... + { ticker: 'TSLA', timestamp: '2021-12-31T01:00:00Z', price: 469.20} + { ticker: 'BTCUSD', timestamp: '2021-12-31T01:00:00Z', price: 52069.42} + { ticker: 'ETHGAS', timestamp: '2021-12-31T01:00:00Z', price: 101.0} + ... + { ticker: 'TSLA', timestamp: '2021-12-31T02:00:00Z', price: 440.20} + { ticker: 'BTCUSD', timestamp: '2021-12-31T02:00:00Z', price: 501.666} + { ticker: 'ETHGAS', timestamp: '2021-12-31T02:00:00Z', price: 90.92} + ... and so on ... ``` In order to use messages from this signer as, for example, the settlement trigger and data for a [futures](./0016-PFUT-product_builtin_future.md) market, Vega needs a way to define a data source that will trigger settlement when a price is received for the correct underlying and the right expiry timestamp. For example: ```proto DATA_SOURCE = Filter { data=SignedMessage{ pubkey=0xA45e...d6 }, filters=[ - Equal { key='ticker', value='TSLA' }, - Equal { key='timestamp', value='2021-12-31T23:59:59Z' } + Equal { key='ticker', value='TSLA' }, + Equal { key='timestamp', value='2021-12-31T23:59:59Z' } ]} gives: - { ticker: 'TSLA', timestamp: '2021-12-31T23:59:59Z', price: 694.20 } + { ticker: 'TSLA', timestamp: '2021-12-31T23:59:59Z', price: 694.20 } ``` Unlike the first example, this would be useful for trigger final settlement of a futures market. @@ -41,14 +41,14 @@ Note that to extract the price value, this would need to be wrapped in a 'select ```proto DATA_SOURCE = select { - field: 'price' - data: filter { - data: SignedMessage{ pubkey=0xA45e...d6 }, - filters: [ - equal { key: 'ticker', value: 'TSLA' }, - equal { key: 'timestamp', value: '2021-12-31T23:59:59Z' } - ] - } + field: 'price' + data: filter { + data: SignedMessage{ pubkey=0xA45e...d6 }, + filters: [ + equal { key: 'ticker', value: 'TSLA' }, + equal { key: 'timestamp', value: '2021-12-31T23:59:59Z' } + ] + } } gives: 694.20 @@ -86,32 +86,33 @@ To be clear, this also means that if the input data is the wrong "shape" or type ## Acceptance criteria 1. Filters can be used with any data source provider (internal, signed message, Ethereum etc.) - 1. Create a filter for each type of source provider and ensure that only data matching the filter gets through. (0047-DSRF-001)(0047-SP-DSRF-001) - 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002)(0047-SP-DSRF-002) + 1. Create a filter for each type of source provider and ensure that only data matching the filter gets through. (0047-DSRF-001) + 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002) 1. All filter conditions are applied - 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003)(0047-SP-DSRF-003) - 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004)(0047-SP-OSMICELEVATOR-004) - 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01") _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041)(0047-SP-DSRF-0041). + 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003) + 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004) + 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01" _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041). 1. Data that is filtered out does not result in a data event but is recorded - 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005)(0047-SP-DSRF-005) - 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006)(0047-SP-DSRF-006) - 1. When data is filtered out and no event is emitted this is recorded either in logs or on the event bus (this may only happen on the receiving node if the event is a transaction that is rejected prior to being sequenced in a block). (0047-DSRF-007)(0047-SP-DSRF-007) + 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005) + 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006) + 1. When data is filtered out and no event is emitted this is recorded either in logs or on the event bus (this may only happen on the receiving node if the event is a transaction that is rejected prior to being sequenced in a block). (0047-DSRF-007) 1. Data sources are defined by the FULL definition including filters - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008)(0047-SP-DSRF-008) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009)(0047-SP-DSRF-009) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010)(0047-SP-DSRF-010) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011)(0047-SP-DSRF-011) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011) 1. Data types and condition types - 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012)(0047-SP-DSRF-012) - 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013)(0047-DSRF-013) - 1. Date + time fields can be filtered by equality (datetime matches filter data exactly). (0047-DSRF-014)(0047-SP-DSRF-014) - 1. Number fields can be filtered by less than (number is less than filter data). (0047-DSRF-015)(0047-SP-DSRF-015) - 1. Date + time fields can be filtered by less than (datetime is less than filter data). (0047-DSRF-016)(0047-SP-DSRF-016) - 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017)(0047-SP-DSRF-017) - 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018)(0047-SP-DSRF-018) - 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019)(0047-SP-DSRF-019) - 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020)(0047-SP-DSRF-020) - 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021)(0047-SP-DSRF-021) - 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022)(0047-SP-DSRF-022) - 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023)(0047-SP-DSRF-023) - 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024)(0047-SP-DSRF-024) + 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012) + 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013) + 1. Date + time fields can be filtered by equality (datetime matches filter data exactly). (0047-DSRF-014) + 1. Number fields can be filtered by less than (number is less than filter data). (0047-DSRF-015) + 1. Date + time fields can be filtered by less than (datetime is less than filter data). (0047-DSRF-016) + 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017) + 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018) + 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019) + 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020) + 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021) + 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022 + 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023) + 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024) + diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 4711dbf8a..855f601e4 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -38,8 +38,8 @@ Pseudocode example: ```rust on: { - timestamp: '20210401T09:00:00' - data: value { type: number, value: 420.69 } + timestamp: '20210401T09:00:00' + data: value { type: number, value: 420.69 } } ``` @@ -48,7 +48,7 @@ Pseudocode example: (no data, just used to trigger event like trading terminated ```rust on: { - timestamp: '202112311T23:59:59' + timestamp: '202112311T23:59:59' } ``` @@ -73,10 +73,10 @@ Pseudocode example: (with filter - i.e. for trading terminated trigger) ```rust filter { - data: vegaprotocol.builtin.timestamp, - filters: [ - greaterOrEqual { key: 'timestamp', value: '2023-12-31T23:55:00Z' } - ] + data: vegaprotocol.builtin.timestamp, + filters: [ + greaterOrEqual { key: 'timestamp', value: '2023-12-31T23:55:00Z' } + ] } ``` @@ -91,16 +91,16 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna ```proto “oracleSpecForTradingTermination”:{ filters”:[ - { - “key”:{ - “name”:“vegaprotocol.builtin.timestamp”, - “type”:“TYPE_TIMESTAMP” - }, - “conditions”:[{ - “operator”:“OPERATOR_GREATER_THAN_OR_EQUAL”, - “value”:“1650447351" - }] - } + { + “key”:{ + “name”:“vegaprotocol.builtin.timestamp”, + “type”:“TYPE_TIMESTAMP” + }, + “conditions”:[{ + “operator”:“OPERATOR_GREATER_THAN_OR_EQUAL”, + “value”:“1650447351" + }] + } ] } ``` @@ -108,32 +108,33 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna ## Acceptance criteria 1. A simple value data source can be provided - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001)(0048-SP-COSMICELEVATOR-001) - 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002)(0048-SP-COSMICELEVATOR-002) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001) + 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002) 1. A time triggered value data source can be provided - 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009)(0048-SP-COSMICELEVATOR-009) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003)(0048-SP-COSMICELEVATOR-003) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004)(0048-SP-COSMICELEVATOR-004) - 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) (0048-SP-COSMICELEVATOR-005) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006)(0048-SP-COSMICELEVATOR-006) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007)(0048-SP-COSMICELEVATOR-007) - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008)(0048-SP-COSMICELEVATOR-008) + 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004) + 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008) 1. A Vega time changed value data source can be provided - 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010)(0048-SP-DSRI-010) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011)(0048-SP-DSRI-011) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the past. The market state changes to trading terminated immediately. (0048-DSRI-012)(0048-SP-DSRI-012) -1. Termination oracle updated after market is terminated (0048-DSRI-015)(0048-SP-DSRI-015) - - setup one market with a boolean termination - - terminate the market (but do not settle it) - - update the market to have a time based termination - - update the market to have an earlier time based termination - - wait until the first timer to tick - - send through valid settlement data - - assert the the market settles successfully -1. Time based termination across multiple markets (0048-DSRI-014)(0048-SP-DSRI-014) - - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time - - wait to all of them to terminate successfully - - assert they all settle successfully + 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the past. The market state changes to trading terminated immediately. (0048-DSRI-012) +1. Termination oracle updated after market is terminated (0048-DSRI-015) + - setup one market with a boolean termination + - terminate the market (but do not settle it) + - update the market to have a time based termination + - update the market to have an earlier time based termination + - wait until the first timer to tick + - send through valid settlement data + - assert the the market settles successfully +1. Time based termination across multiple markets (0048-DSRI-014) + - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time + - wait to all of them to terminate successfully + - assert they all settle successfully 1. The repeating internal time triggered oracle can be used to model a time schedule of the form: every day at 12:00, 15:00 and 18:00. (0048-DSRI-018) 1. The repeating internal time triggered oracle can be used to model a time schedule of the form: 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37. (0048-DSRI-016) 1. The repeating internal time triggered oracle with a schedule of "every day at 12:00", always sends an event as soon as the block with a timestamp with time of 12:00 or higher is received (the time the oracle sends an event doesn't drift forward even after many days). (0048-DSRI-017) + From 191dfc39a86679800c4636991fa381689ffc09df Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Tue, 11 Jul 2023 17:43:07 +0200 Subject: [PATCH 249/649] feat: Update 0074 Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> --- protocol/0074-BTCH-batch-market-instructions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 94f9f43e1..38b1cd135 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -57,6 +57,6 @@ After entering or exiting an auction mid-batch, the full batch must be processed - A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction and a C2 which is marked `GFN` (good for normal) should execute C1 but reject C2. - A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007)(0074-SP-BBTCH-007) - Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008)(0074-SP-BBTCH-008) -- Margin released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009)(0074-SP-BBTCH-009) +- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009)(0074-SP-BBTCH-009) - If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010)(0074-SP-BBTCH-010) - Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011)(0074-SP-BBTCH-011) From d87e6de8cf99eb9b25bb80a3fb0b75fa98356696 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:13:50 +0200 Subject: [PATCH 250/649] feat: update 0073 --- protocol/0073-LIMN-limited_network_life.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index e6454816f..3e54a5327 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -406,3 +406,4 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Do not update the multisig contract. 1. Restart the vega network from the checkpoint created earlier. 1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076) + From 15e4fe6edd48ada587dd45225106e2be8010d24f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:15:21 +0200 Subject: [PATCH 251/649] feat: remove Spot from 0055 --- protocol/0055-TREA-on_chain_treasury.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index 802d9a2bf..332c563e6 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -62,6 +62,7 @@ A governance proposal may be submitted to transfer funds on enactment from the o ### Post Oregon Trail - If a governance proposal for a single transfer from a network treasury account to some other account is enacted then - - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-COSMICELEVATOR-050)(0055-SP-COSMICELEVATOR-050) - - if the balance in the network treasury for the asset is greater than the amount specified in the transfer then the network treasury balance is decreased by the said amount and the destination account (party address) account is incremented by the right amount. (0055-COSMICELEVATOR-051)(0055-SP-COSMICELEVATOR-051) -- If a governance proposal for a single periodic transfer from a network treasury account to some other account is enacted then the transfers run as individual transfers as specified by the schedule / amounts until the schedule ends. (0055-COSMICELEVATOR-060)(0055-SP-COSMICELEVATOR-060) + - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-COSMICELEVATOR-050) + - if the balance in the network treasury for the asset is greater than the amount specified in the transfer then the network treasury balance is decreased by the said amount and the destination account (party address) account is incremented by the right amount. (0055-COSMICELEVATOR-051) +- If a governance proposal for a single periodic transfer from a network treasury account to some other account is enacted then the transfers run as individual transfers as specified by the schedule / amounts until the schedule ends. (0055-COSMICELEVATOR-060) + From 0f11752244284daa7a18d2bc20b4dc72e7e31a43 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:37:54 +0200 Subject: [PATCH 252/649] feat: remove spot from 0020 --- protocol/0020-APIS-core_api.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/protocol/0020-APIS-core_api.md b/protocol/0020-APIS-core_api.md index 4a8aa169f..965d907c3 100644 --- a/protocol/0020-APIS-core_api.md +++ b/protocol/0020-APIS-core_api.md @@ -62,20 +62,20 @@ On any Vega node, I can: | Requirement | Acceptance Criteria code | |-----------|:------------------------:| -| List all governance proposals via REST & GRPC |0020-APIS-0010020-SP-APIS-001| -| List all governance proposals by a specified party via REST & GRPC |0020-APIS-002 0020-SP-APIS-002| -| Retrieve a specific governance proposals by id via REST & GRPC |0020-APIS-003 0020-SP-APIS-003| -| Retrieve a list of votes via REST & GRPC |0020-APIS-0040020-SP-APIS-004| -| Retrieve the governance stake for a specified party via REST & GRPC |0020-APIS-0050020-SP-APIS-005| -| List all markets via REST & GRPC |0020-APIS-0060020-SP-APIS-006| -| Retrieve a specific market via REST & GRPC | 0020-APIS-0070020-SP-APIS-007| -| Retrieve all assets via REST & GRPC | 0020-APIS-0080020-SP-APIS-008| -| List all party IDs via REST & GRPC | 0020-APIS-0090020-SP-APIS-009| -| List all network parameters & their current values via REST & GRPC | 0020-APIS-0100020-SP-APIS-010| -| Retrieve the current block height REST & GRPC | 0020-APIS-0110020-SP-APIS-011| -| Retrieve the current vega time REST & GRPC | 0020-APIS-0120020-SP-APIS-012| -| Retrieve statistics about the network via REST & GRPC | 0020-APIS-0130020-SP-APIS-013| -| Submit a valid transaction via REST & GRPC | 0020-APIS-0140020-SP-APIS-014| +| List all governance proposals via REST & GRPC |0020-APIS-001| +| List all governance proposals by a specified party via REST & GRPC |0020-APIS-002 +| Retrieve a specific governance proposals by id via REST & GRPC |0020-APIS-003 | +| Retrieve a list of votes via REST & GRPC |0020-APIS-004| +| Retrieve the governance stake for a specified party via REST & GRPC |0020-APIS-005| +| List all markets via REST & GRPC |0020-APIS-006| +| Retrieve a specific market via REST & GRPC | 0020-APIS-007| +| Retrieve all assets via REST & GRPC | 0020-APIS-008| +| List all party IDs via REST & GRPC | 0020-APIS-009| +| List all network parameters & their current values via REST & GRPC | 0020-APIS-010| +| Retrieve the current block height REST & GRPC | 0020-APIS-011| +| Retrieve the current vega time REST & GRPC | 0020-APIS-012| +| Retrieve statistics about the network via REST & GRPC | 0020-APIS-013| +| Submit a valid transaction via REST & GRPC | 0020-APIS-014| ## See also From 3008070f42340eb9c88843dd021adb679faeab74 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:43:37 +0200 Subject: [PATCH 253/649] feat: remove spot from 0027 --- protocol/0027-ASSP-asset_proposal.md | 83 ++++++++++++++-------------- 1 file changed, 42 insertions(+), 41 deletions(-) diff --git a/protocol/0027-ASSP-asset_proposal.md b/protocol/0027-ASSP-asset_proposal.md index a430ff035..159c5d745 100644 --- a/protocol/0027-ASSP-asset_proposal.md +++ b/protocol/0027-ASSP-asset_proposal.md @@ -74,9 +74,9 @@ Contracts that do not meet this guarantee are not suitable as a basis for Vega b ```proto message ERC20 { - // contract address of an ERC20 token - string contractAddress = 1; - string maximumLifetimeDeposit = 2; // note that e.g: 100000 in here will be interpreted against the asset decimals + // contract address of an ERC20 token + string contractAddress = 1; + string maximumLifetimeDeposit = 2; // note that e.g: 100000 in here will be interpreted against the asset decimals string withdrawalDelayThreshold = 3; // this is will be interpreted against the asset decimals } @@ -90,10 +90,10 @@ message AssetSource { string name = 4; oneof source { - // vega internal assets - BuiltinAsset builtinAsset = 100; - // foreign chains assets - ERC20 erc20 = 200; + // vega internal assets + BuiltinAsset builtinAsset = 100; + // foreign chains assets + ERC20 erc20 = 200; } } @@ -135,9 +135,9 @@ message ProposalTerms { UpdateMarket updateMarket = 101; NewMarket newMarket = 102; UpdateNetwork updateNetwork = 103; - // new field: - NewAsset = newAsset = 104; - UpdateAsset = updateAsset = 105; + // new field: + NewAsset = newAsset = 104; + UpdateAsset = updateAsset = 105; }; } ``` @@ -146,12 +146,12 @@ message ProposalTerms { ```json { - "newAsset": { - "changes": { - "contractAddress": "0xsomething" - }, - "quantum": "10000000" // if the asset supports 5 decimals = 100.00000 - } + "newAsset": { + "changes": { + "contractAddress": "0xsomething" + }, + "quantum": "10000000" // if the asset supports 5 decimals = 100.00000 + } } ``` @@ -163,40 +163,41 @@ This must be an integer strictly greater than `0`. ### User actions -- As a user I can submit a new proposal asset to be used in vega (0027-ASSP-001)(0027-SP-ASSP-001) -- As a user I can vote for an asset proposal. (0027-ASSP-002)(0027-SP-ASSP-002) -- As a user, original submitter of the asset, I can call the node to get a signature of the asset, so I can send it to the asset bridge, and whitelist the asset. (0027-ASSP-003)(0027-SP-ASSP-003) -- `quantum` is a required parameter (0027-ASSP-004)(0027-SP-ASSP-004) +- As a user I can submit a new proposal asset to be used in vega (0027-ASSP-001) +- As a user I can vote for an asset proposal. (0027-ASSP-002) +- As a user, original submitter of the asset, I can call the node to get a signature of the asset, so I can send it to the asset bridge, and whitelist the asset. (0027-ASSP-003) +- `quantum` is a required parameter (0027-ASSP-004) ### Node actions -- As a node, when a new asset proposal is emitted, I can validate the asset with it's chain, and send the result of the validation through the chain to the other nodes (first phase proposal) (0027-ASSP-005)(0027-SP-ASSP-005) -- As a node, when a new asset is accepted through governance, I can sign a payload to the user so they can whitelist the asset with the bridge (0027-ASSP-006)(0027-SP-ASSP-006) -- As a node, I receive events from the external blockchain queue, that confirm the asset is enabled in the bridge. (0027-ASSP-007)(0027-SP-ASSP-007) -- As a node, when an existing asset is modified through governance changing any one of `maximumLifetimeDeposit` or `withdrawalDelayThreshold`, emit a signed a payload to the world so that they can update the corresponding parameters on the bridge (0027-ASSP-008)(0027-SP-ASSP-008) +- As a node, when a new asset proposal is emitted, I can validate the asset with it's chain, and send the result of the validation through the chain to the other nodes (first phase proposal) (0027-ASSP-005) +- As a node, when a new asset is accepted through governance, I can sign a payload to the user so they can whitelist the asset with the bridge (0027-ASSP-006) +- As a node, I receive events from the external blockchain queue, that confirm the asset is enabled in the bridge. (0027-ASSP-007) +- As a node, when an existing asset is modified through governance changing any one of `maximumLifetimeDeposit` or `withdrawalDelayThreshold`, emit a signed a payload to the world so that they can update the corresponding parameters on the bridge (0027-ASSP-008) ### Validation #### ERC20 Validation -- A valid contract address, which exists in ethereum and is specified in the ERC20 proposal **must** be validated as conforming as an ERC20 asset(0027-ASSP-009)(0027-SP-ASSP-009) -- An ERC20 proposal **must** provide a name and that name **must** exactly equal the name of the ERC20 token on the target chain (0027-ASSP-010)(0027-SP-ASSP-010) -- An ERC20 proposal **must** provide a code and that code **must** exactly equal the code of the ERC20 token on the target chain (0027-ASSP-011)(0027-SP-ASSP-011) -- An ERC20 proposal **must** provide a decimal places property and that property **must** exactly equal the decimal places property of the ERC20 token on the target chain (0027-ASSP-012)(0027-SP-ASSP-012) -- If the contract name or code do not match, or the contract does not exist, or is not an ERC20 contract, the proposal must be rejected and the rejection reason and error details fields should indicate which rule failed (0027-ASSP-013)(0027-SP-ASSP-013) -- This validation occurs according to the `validationTimestamp` field in the proposal (0027-ASSP-014)(0027-SP-ASSP-014) -- A new ERC20 proposal that passes node validation but is does not pass normal governance rules is rejected (0027-ASSP-015)(0027-SP-ASSP-015) -- A new ERC20 proposal that passes normal governance rules but fails node validation is rejected (0027-ASSP-016)(0027-SP-ASSP-016) -- `validationTimestamp` must occur after the governance proposal opens voting, and before it closes (0027-ASSP-017)(0027-SP-ASSP-017) -- `validationTimestamp` must be provided and in the future for all new ERC20 asset proposals (0027-ASSP-018)(0027-SP-ASSP-018) -- `quantum` must be an integer strictly greater than `0` (0027-ASSP-019)(0027-SP-ASSP-019) -- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-ASSP-020)(0027-SP-ASSP-020) +- A valid contract address, which exists in ethereum and is specified in the ERC20 proposal **must** be validated as conforming as an ERC20 asset(0027-ASSP-009) +- An ERC20 proposal **must** provide a name and that name **must** exactly equal the name of the ERC20 token on the target chain (0027-ASSP-010) +- An ERC20 proposal **must** provide a code and that code **must** exactly equal the code of the ERC20 token on the target chain (0027-ASSP-011) +- An ERC20 proposal **must** provide a decimal places property and that property **must** exactly equal the decimal places property of the ERC20 token on the target chain (0027-ASSP-012) +- If the contract name or code do not match, or the contract does not exist, or is not an ERC20 contract, the proposal must be rejected and the rejection reason and error details fields should indicate which rule failed (0027-ASSP-013) +- This validation occurs according to the `validationTimestamp` field in the proposal (0027-ASSP-014) +- A new ERC20 proposal that passes node validation but is does not pass normal governance rules is rejected (0027-ASSP-015) +- A new ERC20 proposal that passes normal governance rules but fails node validation is rejected (0027-ASSP-016) +- `validationTimestamp` must occur after the governance proposal opens voting, and before it closes (0027-ASSP-017) +- `validationTimestamp` must be provided and in the future for all new ERC20 asset proposals (0027-ASSP-018) +- `quantum` must be an integer strictly greater than `0` (0027-ASSP-019) +- If there is a proposal for some ERC20 asset already present then another proposal for the same ERC20 asset will be rejected. (0027-ASSP-020) - There can be multiple concurrent proposals for the same new ERC20 asset (same means identical Ethereum address). Once the nodes agree (based on events from the external blockchain queue), that the asset is enabled on the bridge all the remaining proposals for the same asset are rejected. -(0027-COSMICELEVATOR-025)(0027-SP-COSMICELEVATOR-025) -- An invalid contract address, specified in the ERC20 proposal **must** be rejected(0027-ASSP-021)(0027-SP-ASSP-021) -- An valid contract address which cannot be found in ethereum, specified in the ERC20 proposal **must** be rejected(0027-ASSP-022)(0027-SP-ASSP-022) +(0027-COSMICELEVATOR-025) +- An invalid contract address, specified in the ERC20 proposal **must** be rejected(0027-ASSP-021) +- An valid contract address which cannot be found in ethereum, specified in the ERC20 proposal **must** be rejected(0027-ASSP-022) ### Delays and Thresholds -- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. Withdrawal in asset `X` below `t1` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t1` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-023)(0027-SP-ASSP-023) -- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. An asset update proposal is submitted to change these to `t2`; it passes voting and is submitted to Ethereum bridge contract. The new thresholds now apply i.e. withdrawal in asset `X` below `t2` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t2` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-024)(0027-SP-ASSP-024) +- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. Withdrawal in asset `X` below `t1` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t1` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-023) +- There is an asset `X` on vega / bridge with withdrawal delay threshold `t1`. An asset update proposal is submitted to change these to `t2`; it passes voting and is submitted to Ethereum bridge contract. The new thresholds now apply i.e. withdrawal in asset `X` below `t2` has no delay i.e. can be finalised on Ethereum as soon as the withdrawal bundle is received. A withdrawal in asset `X` with amount greater than or equal to `t2` will be rejected by the bridge before time `bundle creation + delay` but can be finalised after `delay` time passes from bundle creation. Here `delay` is the global bridge delay parameter. (0027-ASSP-024) + From f2c1136cbd317d682920a638c6580896b06d4e29 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:56:33 +0200 Subject: [PATCH 254/649] feat: update 0029-FEES-008 --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 77d7d6714..833498ad6 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -100,7 +100,7 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005)(0029-SP-FEES-005)(0029-SP-FEES-005) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) -- During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the holding account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) +- During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) - Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009)(0029-SP-FEES-009) - A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010)(0029-SP-FEES-010) - Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011)(0029-SP-FEES-011) From 9c89573e94d837e488e588292d0f70a2dcc47f61 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:57:40 +0200 Subject: [PATCH 255/649] feat: remove spot from 0031 --- protocol/0031-ETHB-ethereum_bridge_spec.md | 144 ++++++++++----------- 1 file changed, 72 insertions(+), 72 deletions(-) diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 3453d2257..7a88be6cf 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -139,123 +139,123 @@ This example connects the network to Ropsten: - ERC-20 smart contract (This can be repeated for many token standards - NFTs and crypto items will be more complex): - An Ethereum Address can call the deposit function and successfully deposit any token that is listed via `list_asset` (0031-ETHB-008) - - A deposit call with a removed token `remove_asset` is rejected (0031-COSMICELEVATOR-009)(0031-SP-COSMICELEVATOR-009) + - A deposit call with a removed token `remove_asset` is rejected (0031-COSMICELEVATOR-009) ### Withdraw - ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the withdraw function to successfully withdraw an ERC-20 asset (0031-ETHB-013)(0031-SP-ETHB-013) - - An invalid multisig bundle will be rejected from withdraw (0031-ETHB-013)(0031-SP-ETHB-013) + - A valid multisig bundle can be passed to the withdraw function to successfully withdraw an ERC-20 asset (0031-ETHB-013) + - An invalid multisig bundle will be rejected from withdraw (0031-ETHB-014) ### Allowlist a token (by eth address) - ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the `list_asset` function to successfully add a token to the allowed list (0031-ETHB-016)(0031-SP-ETHB-016) - - An invalid multisig bundle is rejected by the `list_asset` function (0031-ETHB-017)(0031-SP-ETHB-017) + - A valid multisig bundle can be passed to the `list_asset` function to successfully add a token to the allowed list (0031-ETHB-016) + - An invalid multisig bundle is rejected by the `list_asset` function (0031-ETHB-017) ### Blocklist a token (by eth address) - ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the `remove_asset` function to successfully remove a previously allow listed token (0031-COSMICELEVATOR-019)(0031-SP-COSMICELEVATOR-019) - - An invalid multisig bundle is rejected by the `remove_asset` function (0031-COSMICELEVATOR-020)(0031-SP-COSMICELEVATOR-020) + - A valid multisig bundle can be passed to the `remove_asset` function to successfully remove a previously allow listed token (0031-COSMICELEVATOR-019) + - An invalid multisig bundle is rejected by the `remove_asset` function (0031-COSMICELEVATOR-020) ### ERC20 Bridge Logic to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on `ERC20_Bridge_Logic` and their corresponding acceptance criteria. 1. `address payable public erc20_asset_pool_address;` - - must match the deployed asset pool address (0031-ETHB-018)(0031-SP-ETHB-018) + - must match the deployed asset pool address (0031-ETHB-018) 1. `function list_asset(address asset_source,bytes32 vega_asset_id,uint256 lifetime_limit,uint256 withdraw_threshold,uint256 nonce,bytes memory signatures)` - - must list asset (0031-ETHB-019)(0031-SP-ETHB-019) - - must not list already-listed asset (0031-ETHB-020)(0031-SP-ETHB-020) - - must not list if bad signatures (0031-ETHB-021)(0031-SP-ETHB-021) - - must not list if already listed (0031-ETHB-022)(0031-SP-ETHB-022) + - must list asset (0031-ETHB-019) + - must not list already-listed asset (0031-ETHB-020) + - must not list if bad signatures (0031-ETHB-021) + - must not list if already listed (0031-ETHB-022) 1. `function remove_asset(address asset_source,uint256 nonce,bytes memory signatures)` - - must remove asset (0031-ETHB-023)(0031-SP-ETHB-023) - - must fail if asset not listed (0031-ETHB-024)(0031-SP-ETHB-024) - - must fail if bad signatures (0031-ETHB-025)(0031-SP-ETHB-025) + - must remove asset (0031-ETHB-023) + - must fail if asset not listed (0031-ETHB-024) + - must fail if bad signatures (0031-ETHB-025) 1. `uint256 public default_withdraw_delay = 432000;` - - must show 432000 (0031-ETHB-026)(0031-SP-ETHB-026) + - must show 432000 (0031-ETHB-026) 1. `bool public is_stopped;` - - must be false at first (0031-ETHB-027)(0031-SP-ETHB-027) - - must be true after `global_stop` called (0031-ETHB-028)(0031-SP-ETHB-028) + - must be false at first (0031-ETHB-027) + - must be true after `global_stop` called (0031-ETHB-028) 1. `function set_asset_limits(address asset_source,uint256 lifetime_limit,uint256 threshold,uint256 nonce,bytes calldata signatures)` - - changes asset limits (0031-ETHB-029)(0031-SP-ETHB-029) - - must fail if bad signatures (0031-ETHB-030)(0031-SP-ETHB-030) - - asset must be listed (0031-ETHB-031)(0031-SP-ETHB-031) + - changes asset limits (0031-ETHB-029) + - must fail if bad signatures (0031-ETHB-030) + - asset must be listed (0031-ETHB-031) 1. `function get_asset_deposit_lifetime_limit(address asset_source)` - - must return asset lifetime limit (0031-ETHB-032)(0031-ETHB-032) + - must return asset lifetime limit (0031-ETHB-032) 1. `function get_withdraw_threshold(address asset_source)` - - must return withdraw threshold (0031-ETHB-033)(0031-SP-ETHB-033) + - must return withdraw threshold (0031-ETHB-033) 1. `function set_withdraw_delay(uint256 delay,uint256 nonce,bytes calldata signatures)` - - must set withdraw delay (0031-ETHB-034)(0031-SP-ETHB-034) - - must fail if bad signatures (0031-ETHB-036)(0031-SP-ETHB-036) + - must set withdraw delay (0031-ETHB-034) + - must fail if bad signatures (0031-ETHB-036) 1. `function global_stop(uint256 nonce, bytes calldata signatures)` - - must set `is_stopped` to `true` (0031-ETHB-037)(0031-SP-ETHB-037) - - must stop deposits (0031-ETHB-038)(0031-SP-ETHB-038) - - must stop withdrawals (0031-ETHB-039)(0031-SP-ETHB-039) - - must not be stopped already (0031-ETHB-040)(0031-SP-ETHB-040) - - must fail on bad signatures (0031-ETHB-041)(0031-SP-ETHB-041) + - must set `is_stopped` to `true` (0031-ETHB-037) + - must stop deposits (0031-ETHB-038) + - must stop withdrawals (0031-ETHB-039) + - must not be stopped already (0031-ETHB-040) + - must fail on bad signatures (0031-ETHB-041) 1. `function global_resume(uint256 nonce, bytes calldata signatures)` - - must set `is_stopped` to `false` (0031-ETHB-042)(0031-SP-ETHB-042) - - must resume deposits (0031-ETHB-043)(0031-SP-ETHB-043) - - must resume withdrawals (0031-ETHB-044)(0031-SP-ETHB-044) - - must already be stopped (0031-ETHB-045)(0031-SP-ETHB-045) - - must fail on bad signatures (0031-ETHB-046)(0031-SP-ETHB-046) + - must set `is_stopped` to `false` (0031-ETHB-042) + - must resume deposits (0031-ETHB-043) + - must resume withdrawals (0031-ETHB-044) + - must already be stopped (0031-ETHB-045) + - must fail on bad signatures (0031-ETHB-046) 1. `function exempt_depositor()` - - must exempt caller from lifetime deposits (0031-ETHB-047)(0031-SP-ETHB-047) - - must not be already exempt (0031-ETHB-048)(0031-SP-ETHB-048) + - must exempt caller from lifetime deposits (0031-ETHB-047) + - must not be already exempt (0031-ETHB-048) 1. `function revoke_exempt_depositor()` - - must revoke lifetime deposit exemption (0031-ETHB-049)(0031-SP-ETHB-049) - - must already be exempt (0031-ETHB-050)(0031-SP-ETHB-050) + - must revoke lifetime deposit exemption (0031-ETHB-049) + - must already be exempt (0031-ETHB-050) 1. `function is_exempt_depositor(address depositor) external view override returns (bool)` - - must show lifetime deposit exemption (0031-ETHB-051)(0031-SP-ETHB-051) + - must show lifetime deposit exemption (0031-ETHB-051) 1. `function withdraw_asset(address asset_source,uint256 amount,address target,uint256 creation,uint256 nonce,bytes memory signatures)` - - must withdraw asset specified (0031-ETHB-052)(0031-SP-ETHB-052) - - must fail on bad signatures (0031-ETHB-053)(0031-SP-ETHB-053) - - must fail on non-matching parameters (0031-ETHB-054)(0031-SP-ETHB-054) - - must fail on expired withdrawal order (0031-ETHB-082)(0031-SP-ETHB-082) - - must fail on delay not yet elapsed (0031-ETHB-083)(0031-SP-ETHB-083) + - must withdraw asset specified (0031-ETHB-052) + - must fail on bad signatures (0031-ETHB-053) + - must fail on non-matching parameters (0031-ETHB-054) + - must fail on expired withdrawal order (0031-ETHB-082) + - must fail on delay not yet elapsed (0031-ETHB-083) 1. `function deposit_asset(address asset_source,uint256 amount,bytes32 vega_public_key)` - - must deposit asset from user (0031-ETHB-055)(0031-SP-ETHB-055) - - must be listed (0031-ETHB-056)(0031-SP-ETHB-056) - - must be exempt or below lifetime deposit limit (0031-ETHB-057)(0031-SP-ETHB-057) - - must fail if over lifetime limit and not exempt (0031-ETHB-058)(0031-SP-ETHB-058) - - must be credited on Vega (0031-ETHB-059)(0031-SP-ETHB-059) + - must deposit asset from user (0031-ETHB-055) + - must be listed (0031-ETHB-056) + - must be exempt or below lifetime deposit limit (0031-ETHB-057) + - must fail if over lifetime limit and not exempt (0031-ETHB-058) + - must be credited on Vega (0031-ETHB-059) 1. `function is_asset_listed(address asset_source) external view override returns (bool)` - - must be true if asset is listed (0031-ETHB-060)(0031-SP-ETHB-060) - - must be false if asset is not listed (0031-ETHB-061)(0031-SP-ETHB-061) - - when true, deposits must work (0031-ETHB-062)(0031-SP-ETHB-062) - - when false deposits must not work (0031-ETHB-063)(0031-SP-ETHB-063) + - must be true if asset is listed (0031-ETHB-060) + - must be false if asset is not listed (0031-ETHB-061) + - when true, deposits must work (0031-ETHB-062) + - when false deposits must not work (0031-ETHB-063) 1. `function get_multisig_control_address() external view override returns (address)` - - must show deployed multisig address (0031-ETHB-064)(0031-SP-ETHB-064) + - must show deployed multisig address (0031-ETHB-064) 1. `function get_vega_asset_id(address asset_source) external view override returns (bytes32)` - - must return proper Vega asset ID (0031-ETHB-065)(0031-SP-ETHB-065) + - must return proper Vega asset ID (0031-ETHB-065) 1. `function get_asset_source(bytes32 vega_asset_id) external view override returns (address)` - - must return the deployed asset address from Vega asset ID (0031-ETHB-066)(0031-SP-ETHB-066) + - must return the deployed asset address from Vega asset ID (0031-ETHB-066) ### ERC-20 Asset Pool to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on ERC20_Asset_Pool and their corresponding acceptance criteria. 1. `address public multisig_control_address;` - - must show the current multisig control address (0031-ETHB-067)(0031-SP-ETHB-067) - - must change to reflect a successful set_multisig_control call (0031-ETHB-068)(0031-ESP-THB-068) + - must show the current multisig control address (0031-ETHB-067) + - must change to reflect a successful set_multisig_control call (0031-ETHB-068) 1. `address public erc20_bridge_address;` - - must show current deployed `erc20_bridge` address (0031-ETHB-069)(0031-SP-ETHB-069) - - must change to reflect a successful set_bridge_address call (0031-ETHB-070)(0031-SP-ETHB-070) + - must show current deployed `erc20_bridge` address (0031-ETHB-069) + - must change to reflect a successful set_bridge_address call (0031-ETHB-070) 1. `receive() external payable // fallback, should fail` 1. `function set_multisig_control(address new_address,uint256 nonce,bytes memory signatures)` - - must set multisig control (0031-ETHB-071)(0031-SP-ETHB-071) - - must be reflected in `multisig_control_address` (0031-ETHB-072)(0031-SP-ETHB-072) - - must fail on bad signatures (0031-ETHB-073)(0031-SP-ETHB-073) + - must set multisig control (0031-ETHB-071) + - must be reflected in `multisig_control_address` (0031-ETHB-072) + - must fail on bad signatures (0031-ETHB-073) 1. `function set_bridge_address(address new_address,uint256 nonce,bytes memory signatures)` - - must set bridge address (0031-ETHB-074)(0031-SP-ETHB-074) - - must be reflected in `erc20_bridge_address` (0031-ETHB-075)(0031-SP-ETHB-075) - - must fail on bad signatures (0031-ETHB-076)(0031-SP-ETHB-076) + - must set bridge address (0031-ETHB-074) + - must be reflected in `erc20_bridge_address` (0031-ETHB-075) + - must fail on bad signatures (0031-ETHB-076) 1. `function withdraw(address token_address,address target,uint256 amount)` - - must remit the `amount` of `token_address` to the `target` address (0031-ETHB-077)(0031-SP-ETHB-077) - - must be runnable from the current `erc20_bridge_address` address (0031-ETHB-078)(0031-SP-ETHB-078) - - must fail if ran by any other address (0031-ETHB-079)(0031-ETHB-079) - - must work for new bridge after bridge address changed (0031-ETHB-080)(0031-SP-ETHB-080) - - must fail for old bridge after bridge address changed (0031-ETHB-081)(0031-SP-ETHB-081) + - must remit the `amount` of `token_address` to the `target` address (0031-ETHB-077) + - must be runnable from the current `erc20_bridge_address` address (0031-ETHB-078) + - must fail if ran by any other address (0031-ETHB-079) + - must work for new bridge after bridge address changed (0031-ETHB-080) + - must fail for old bridge after bridge address changed (0031-ETHB-081) From 41e7a93aeafbaade2efcbe74d23cc8dc4ea2f964 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 18:59:14 +0200 Subject: [PATCH 256/649] feat: remove spot from 0030 --- protocol/0030-ETHM-multisig_control_spec.md | 110 ++++++++++---------- 1 file changed, 55 insertions(+), 55 deletions(-) diff --git a/protocol/0030-ETHM-multisig_control_spec.md b/protocol/0030-ETHM-multisig_control_spec.md index 5769b9218..605ffa799 100644 --- a/protocol/0030-ETHM-multisig_control_spec.md +++ b/protocol/0030-ETHM-multisig_control_spec.md @@ -110,79 +110,79 @@ contract MultisigControl { ### MultisigControl Smart Contract - Set Threshold - - A valid signature bundle, threshold (in tenths of %), and unused nonce can be passed to `set_threshold` function to set the approval threshold in hundredths of a percent (`TODO: check this mechanism/math`) (0030-ETHM-002)(0030-SP-ETHM-002) - - A successful call to `set_threshold` emits `ThresholdSet` event (0030-ETHM-003)(0030-SP-ETHM-003) - -Subsequent calls to `get_current_threshold()` returns updated threshold value (0030-ETHM-004)(0030-SP-ETHM-004) - - An invalid signature passed to `set_threshold` function is rejected (0030-ETHM-005)(0030-SP-ETHM-005) - - A threshold passed to `set_threshold` outside of sane range is rejected (0030-ETHM-006)(0030-SP-ETHM-006) - - A nonce passed to `set_threshold` that has already been used is rejected (0030-ETHM-007)(0030-SP-ETHM-007) + - A valid signature bundle, threshold (in tenths of %), and unused nonce can be passed to `set_threshold` function to set the approval threshold in hundredths of a percent (`TODO: check this mechanism/math`) (0030-ETHM-002) + - A successful call to `set_threshold` emits `ThresholdSet` event (0030-ETHM-003) + -Subsequent calls to `get_current_threshold()` returns updated threshold value (0030-ETHM-004) + - An invalid signature passed to `set_threshold` function is rejected (0030-ETHM-005) + - A threshold passed to `set_threshold` outside of sane range is rejected (0030-ETHM-006) + - A nonce passed to `set_threshold` that has already been used is rejected (0030-ETHM-007) - Add Signer - - A valid signature bundle, non-signer ethereum address, and unused nonce can be passed to `add_signer` function to add an Ethereum address of a new signer to the list of approved signers (0030-ETHM-008)(0030-SP-ETHM-008) - - A successful call to `add_signer` increments signer count (0030-ETHM-009)(0030SP-ETHM-009) - - A successful call to `add_signer` emits `SignerAdded` event (0030-ETHM-010)(0030-SP-ETHM-010) - - Subsequent calls to `is_valid_signer()` with added Ethereum address returns true until that signer is removed (0030-ETHM-011)(0030-SP-ETHM-011) - - An invalid signature bundle, currently approved signer address, or used nonce passed to `add_signer` is rejected (0030-ETHM-012)(0030-SP-ETHM-012) + - A valid signature bundle, non-signer ethereum address, and unused nonce can be passed to `add_signer` function to add an Ethereum address of a new signer to the list of approved signers (0030-ETHM-008) + - A successful call to `add_signer` increments signer count (0030-ETHM-009) + - A successful call to `add_signer` emits `SignerAdded` event (0030-ETHM-010) + - Subsequent calls to `is_valid_signer()` with added Ethereum address returns true until that signer is removed (0030-ETHM-011) + - An invalid signature bundle, currently approved signer address, or used nonce passed to `add_signer` is rejected (0030-ETHM-012) - Remove Signer - - A valid signature bundle, current signer Ethereum address, and unused nonce can be passed to `remove_signer` to remove a currently valid signer from the list of signers (0030-ETHM-013)(0030-SP-ETHM-013) - - A successful call to `remove_signer` decrements signer count (0030-ETHM-014)(0030-SP-ETHM-014) - - A successful call to `remove_signer` emits `SignerRemoved` event (0030-ETHM-015)(0030-SP-ETHM-015) - - Subsequent calls to `is_valid_signer()` with removed Ethereum address returns false unless that signer is re-added (0030-ETHM-016)(0030-SP-ETHM-016) - - An invalid signature bundle, non current signer Ethereum address, or used nonce passed to `remove_signer` is rejected (0030-ETHM-017)(0030-SP-ETHM-017) + - A valid signature bundle, current signer Ethereum address, and unused nonce can be passed to `remove_signer` to remove a currently valid signer from the list of signers (0030-ETHM-013) + - A successful call to `remove_signer` decrements signer count (0030-ETHM-014) + - A successful call to `remove_signer` emits `SignerRemoved` event (0030-ETHM-015) + - Subsequent calls to `is_valid_signer()` with removed Ethereum address returns false unless that signer is re-added (0030-ETHM-016) + - An invalid signature bundle, non current signer Ethereum address, or used nonce passed to `remove_signer` is rejected (0030-ETHM-017) - Getters - - `get_valid_signer_count()` returns current count of valid signers (0030-ETHM-018)(0030-SP-ETHM-018) - - `get_current_threshold()` returns current threshold (0030-ETHM-019)(0030-SP-ETHM-019) - - `is_valid_signer()` returns true is signer is valid (0030-ETHM-020)(0030-SP-ETHM-020) - - `is_nonce_used()` returns true if nonce has been used to successfully sign something previously (0030-ETHM-021)(0030-SP-ETHM-021) + - `get_valid_signer_count()` returns current count of valid signers (0030-ETHM-018) + - `get_current_threshold()` returns current threshold (0030-ETHM-019) + - `is_valid_signer()` returns true is signer is valid (0030-ETHM-020) + - `is_nonce_used()` returns true if nonce has been used to successfully sign something previously (0030-ETHM-021) ### MultisigControl Consuming Smart Contract -- Consuming smart contract calls `verify_signatures` with valid signature bundle and message hash is returned true if the valid signature count is over threshold % of total signers (0030-ETHM-023)(0030-SP-ETHM-023) +- Consuming smart contract calls `verify_signatures` with valid signature bundle and message hash is returned true if the valid signature count is over threshold % of total signers (0030-ETHM-023) ### Multisig Control to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on MultisigControl and their corresponding acceptance criteria. 1. `mapping(address => bool) public signers;` - - must show "True" for each signer that is currently valid (0030-ETHM-024)(0030-SP-ETHM-024) - - must show "False" for non-signers (0030-ETHM-025)(0030-SP-ETHM-025) - - must show "False" for removed signers (0030-ETHM-026)(0030-SP-ETHM-026) + - must show "True" for each signer that is currently valid (0030-ETHM-024) + - must show "False" for non-signers (0030-ETHM-025) + - must show "False" for removed signers (0030-ETHM-026) 1. `function set_threshold(uint16 new_threshold,uint256 nonce,bytes calldata signatures)` - - must set the vote threshold if parameters and signatures valid (0030-ETHM-027)(0030-SP-ETHM-027) - - must fail if bad signatures (0030-ETHM-028)(0030-SP-ETHM-028) - - must fail if threshold zero (0030-ETHM-029)(0030-SP-ETHM-029) - - must fail if threshold > 1000 (0030-ETHM-030)(0030-SP-ETHM-030) + - must set the vote threshold if parameters and signatures valid (0030-ETHM-027) + - must fail if bad signatures (0030-ETHM-028) + - must fail if threshold zero (0030-ETHM-029) + - must fail if threshold > 1000 (0030-ETHM-030) 1. `function add_signer(address new_signer,uint256 nonce,bytes calldata signatures)` - - must add signer if parameters and signatures valid (0030-ETHM-031)(0030-SP-ETHM-031) - - must fail if bad signatures (0030-ETHM-032)(0030-SP-ETHM-032) - - must fail if already signer (0030-ETHM-033)(0030-SP-ETHM-033) + - must add signer if parameters and signatures valid (0030-ETHM-031) + - must fail if bad signatures (0030-ETHM-032) + - must fail if already signer (0030-ETHM-033) 1. `function remove_signer(address old_signer,uint256 nonce,bytes calldata signatures)` - - must remove signer if parameters and signatures valid (0030-ETHM-034)(0030-SP-ETHM-034) - - must fail if bad signatures (0030-ETHM-035)(0030-SP-ETHM-035) - - must fail if not valid signer (0030-ETHM-036)(0030-SP-ETHM-036) + - must remove signer if parameters and signatures valid (0030-ETHM-034) + - must fail if bad signatures (0030-ETHM-035) + - must fail if not valid signer (0030-ETHM-036) 1. `function burn_nonce(uint256 nonce, bytes calldata signatures)` - - must stop specific nonce from being used despite valid signatures (0030-ETHM-037)(0030-SP-ETHM-037) - - must fail if bad signatures (0030-ETHM-038)(0030-SP-ETHM-038) - - must fail if already redeemed (0030-ETHM-039)(0030-SP-ETHM-039) - - must fail if already burned (0030-ETHM-040)(0030-SP-ETHM-040) + - must stop specific nonce from being used despite valid signatures (0030-ETHM-037) + - must fail if bad signatures (0030-ETHM-038) + - must fail if already redeemed (0030-ETHM-039) + - must fail if already burned (0030-ETHM-040) 1. `function verify_signatures(bytes calldata signatures,bytes memory message,uint256 nonce)` - - must verify if signatures match message and nonce AND pass current threshold with currently valid signers (0030-ETHM-041)(0030-SP-ETHM-041) - - must burn nonce to prevent replay attack (0030-ETHM-042)(0030-SP-ETHM-042) - - must fail if bad signatures (0030-ETHM-043)(0030-SP-ETHM-043) - - must fail if nonce already used (0030-ETHM-044)(0030-SP-ETHM-044) + - must verify if signatures match message and nonce AND pass current threshold with currently valid signers (0030-ETHM-041) + - must burn nonce to prevent replay attack (0030-ETHM-042) + - must fail if bad signatures (0030-ETHM-043) + - must fail if nonce already used (0030-ETHM-044) 1. `function get_valid_signer_count() external view override returns (uint8)` - - must return current valid signer count (0030-ETHM-045)(0030-SP-ETHM-045) - - must change to reflect adding of a signer (0030-ETHM-046)(0030-SP-ETHM-046) - - must change to reflect removing of a signer (0030-ETHM-047)(0030-SP-ETHM-047) + - must return current valid signer count (0030-ETHM-045) + - must change to reflect adding of a signer (0030-ETHM-046) + - must change to reflect removing of a signer (0030-ETHM-047) 1. `function get_current_threshold() external view override returns (uint16)` - - must return current threshold (0030-ETHM-048)(0030-SP-ETHM-048) - - must change to reflect a change of threshold (0030-ETHM-049)(0030-SP-ETHM-049) + - must return current threshold (0030-ETHM-048) + - must change to reflect a change of threshold (0030-ETHM-049) 1. `function is_valid_signer(address signer_address) external view override returns (bool)` - - must return true if valid signer (0030-ETHM-050)(0030-SP-ETHM-050) - - must return false for non signer (0030-ETHM-051)(0030-SP-ETHM-051) - - must return false for removed (0030-ETHM-052)(0030-SP-ETHM-052) - - must change to reflect a removed signer (0030-ETHM-053)(0030-SP-ETHM-053) - - must change to reflect added signer (0030-ETHM-054)(0030-SP-ETHM-054) + - must return true if valid signer (0030-ETHM-050) + - must return false for non signer (0030-ETHM-051) + - must return false for removed (0030-ETHM-052) + - must change to reflect a removed signer (0030-ETHM-053) + - must change to reflect added signer (0030-ETHM-054) 1. `function is_nonce_used(uint256 nonce) external view override returns (bool)` - - must return true if nonce has been used for normal transaction (0030-ETHM-055)(0030-SP-ETHM-055) - - must return true if nonce burned (0030-ETHM-056)(0030-SP-ETHM-056) - - must return false if not seen before OR if signatures failed to go over threshold (0030-ETHM-057)(0030-SP-ETHM-057) + - must return true if nonce has been used for normal transaction (0030-ETHM-055) + - must return true if nonce burned (0030-ETHM-056) + - must return false if not seen before OR if signatures failed to go over threshold (0030-ETHM-057) From 1bdaaff5eb57f42420e5f2c1e8a304532bccfda6 Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Tue, 11 Jul 2023 18:06:53 +0100 Subject: [PATCH 257/649] feat: Remove reduce-only requirement from stop orders --- protocol/0014-ORDT-order_types.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index db76c83b4..d7fbb9615 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -54,7 +54,7 @@ Notes on scope of current version of this spec: In addition to normal immediately executing order, Vega should accept the submission of stop orders. These differ from normal orders in that they sit off the order book until triggered, when they are entered as normal. These are generally used to exit positions under pre-defined conditions, either as a "stop loss" order that controls the maximum losses a position may take, a "take profit" order that closes a position once a defined level of profit has been made, or both. -To prevent traders from "hiding" order book depth behind conditional orders, stop orders can only be used to close some or all of a trader's position, and therefore must be "reduce only" orders. + A stop order submission can be made (stop loss or take profit are probably both just called a stop order internally). @@ -75,8 +75,6 @@ An OCO submission allows a user to have a stop loss and take profit applied to t - The stop order submission wraps a normal order submission. -- The order within the stop order submission must be reduce only. - - The submission is validated when it is received but does not initially interact with the order book unless it is triggered immediately (see below). - If and when the trigger price is breached in the specified direction the order provided in the stop order submission is created and enters the book or trades as normal, as if it was just submitted. @@ -328,7 +326,6 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ### Stop orders -- A stop order with reduce only set to false will be rejected. (0014-ORDT-040) - Once triggered, a stop order is removed from the book and cannot be triggered again. (0014-ORDT-041) - A stop order placed by a key with a zero position and no open orders will be rejected. (0014-ORDT-042) - A stop order placed by a key with a zero position but open orders will be accepted. (0014-ORDT-043) @@ -347,7 +344,7 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu - A stop order with expiration time `T` set to execute at that time will execute at time `T` if reached without being triggered. (0014-ORDT-053) - If the order is triggered before reaching time `T`, the order will have been removed and will *not* trigger at time `T`. (0014-ORDT-054) -- A stop order set to trade volume `x` with a trigger set to `Rises Above` at a given price will trigger at the first trade at or above that price. At this time the order will be placed on the book if and only if it would reduce the trader's absolute position (buying if they are short or selling if they are long) if executed (i.e. will execute as a reduce-only order). (0014-ORDT-055) +- A stop order set to trade volume `x` with a trigger set to `Rises Above` at a given price will trigger at the first trade at or above that price. (0014-ORDT-055) - If a pair of stop orders are specified as OCO, one being triggered also removes the other from the book. (0014-ORDT-056) - If a pair of stop orders are specified as OCO and one triggers but is invalid at time of triggering (e.g. a buy when the trader is already long) the other will still be cancelled. (0014-ORDT-058) From 253868e9424b85132e4221e5bbfcc55208ff0ad1 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Tue, 11 Jul 2023 19:07:31 +0200 Subject: [PATCH 258/649] fix: add intra-block SLA sampling --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 6 ++---- protocol/0044-LIME-lp_mechanics.md | 1 + 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index bef584c06..7ab017d9c 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -223,10 +223,7 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP - If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -- At the start of each block generate a pseudorandom integer `k` between `1..N` (inclusive of `1` and `N`) where `N` is the number of transactions in the block (note: transactions not orders, a batch is one transaction for this purpose). -Use a suitable deterministic seed to minimise the probability of an LP gaming `k` or being able to target transactions around (directly before or after) the point `k`. -For example, the seed might combine the hash of all transactions in the block itself with the number of transactions `N`. -Using only information from the prior block as the seed may allow exploits based on pre-generation of `k` and must be avoided. +- At start of block, set `k` to `0` and then after every `market.liquidity.sla.evalEveryNumOfTransactions` transactions have been processed set `k` to the transaction number of the just processed transaction. - In each block, immediately after processing transaction `k`: @@ -245,6 +242,7 @@ Using only information from the prior block as the seed may allow exploits based - At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. +Note that because vega time won't be progressing intra-block the above mechanism should ensure that `s_i` gets incremented only if the LP was meeting their commitment at every point this was checked within the block. #### Calculating the SLA performance penalty for a single epoch diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 4a2c84f79..75da682c5 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,6 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. +- `market.liquidity.sla.evalEveryNumOfTransactions` sets how many transactions in a block are processed before each party that's committed to providing liquidty is evaluated for meeting (or not) their commitment. ### Market parameters From ff890c6b1c2e925dc282efe3354502d3e1155c4f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 19:08:44 +0200 Subject: [PATCH 259/649] feat: remove spot --- protocol/0022-AUTH-auth.md | 26 +++++----- protocol/0040-ASSF-asset_framework.md | 16 +++---- protocol/0050-EPOC-epochs.md | 14 +++--- protocol/0061-REWP-pos_rewards.md | 22 ++++----- protocol/0062-SPAM-spam_protection.md | 48 +++++++++---------- .../0063-VALK-validator_vega_master_keys.md | 26 +++++----- ...ALP-validator_performance_based_rewards.md | 12 ++--- .../0066-VALW-validator_tendermint_weights.md | 18 +++---- 8 files changed, 91 insertions(+), 91 deletions(-) diff --git a/protocol/0022-AUTH-auth.md b/protocol/0022-AUTH-auth.md index 0adeeaf8a..8fe30b25f 100644 --- a/protocol/0022-AUTH-auth.md +++ b/protocol/0022-AUTH-auth.md @@ -124,23 +124,23 @@ messge TransactionBundle { ### Wallet service acceptance criteria -- As a user, I can create a new account on the Wallet service (account creation requirement to be implementation details) (0022-AUTH-001)(0022-SP-AUTH-001) -- As a user, I can login to the Wallet service with my wallet name and password (0022-AUTH-002)(0022-SP-AUTH-002) -- As a user, I can logout of the Wallet service with a token given to me at login (0022-AUTH-003)(0022-SP-AUTH-003) -- As a user, if I'm logged in, I can create a new party (with a key pair) for for my account on the Wallet service. (0022-AUTH-004)(0022-SP-AUTH-004) -- As a user, if I'm logged in, I can list all my parties (and their key pairs) on the Wallet service (0022-AUTH-005)(0022-SP-AUTH-005) -- As a user, if I'm logged in, I can create a signature for a blob of data, using one of my parties (and its key pair). (0022-AUTH-007)(0022-SP-AUTH-007) +- As a user, I can create a new account on the Wallet service (account creation requirement to be implementation details) (0022-AUTH-001) +- As a user, I can login to the Wallet service with my wallet name and password (0022-AUTH-002) +- As a user, I can logout of the Wallet service with a token given to me at login (0022-AUTH-003) +- As a user, if I'm logged in, I can create a new party (with a key pair) for for my account on the Wallet service. (0022-AUTH-004) +- As a user, if I'm logged in, I can list all my parties (and their key pairs) on the Wallet service (0022-AUTH-005) +- As a user, if I'm logged in, I can create a signature for a blob of data, using one of my parties (and its key pair). (0022-AUTH-007) ### Vega network acceptance criteria -- As a user, I can send a transaction to the vega network with a signature for it. (0022-AUTH-008)(0022-SP-AUTH-008) -- As a vega node, I ensure that all transaction are paired with a signature. (0022-AUTH-009)(0022-SP-AUTH-009) +- As a user, I can send a transaction to the vega network with a signature for it. (0022-AUTH-008) +- As a vega node, I ensure that all transaction are paired with a signature. (0022-AUTH-009) - A signature is verified before the transaction is sent to the chain. - - If a signature is valid, the transaction is sent to the chain (0022-AUTH-010)(0022-SP-AUTH-010) - - If a signature is invalid, the transaction is not sent to the chain, an error is returned (0022-AUTH-011)(0022-SP-AUTH-011) - - A transaction with an invalid signature is never sent to the chain and the transaction is discarded. (0022-AUTH-013) (0022-SP-AUTH-013) - - A transaction with no signature is rejected (0022-AUTH-014)(0022-SP-AUTH-014) -- A `partyId` that is not a valid public key is inherently invalid, and should be rejected (0022-AUTH-015)(0022-SP-AUTH-015) + - If a signature is valid, the transaction is sent to the chain (0022-AUTH-010) + - If a signature is invalid, the transaction is not sent to the chain, an error is returned (0022-AUTH-011) + - A transaction with an invalid signature is never sent to the chain and the transaction is discarded. (0022-AUTH-013) + - A transaction with no signature is rejected (0022-AUTH-014) +- A `partyId` that is not a valid public key is inherently invalid, and should be rejected (0022-AUTH-015) - _Note:_ In early versions of Vega, the `partyId` was an arbitrary string. This is no longer valid, and should be rejected. This includes the [network party](./0017-PART-party.md#network-party) - that is used where transactions are generated by the system, and it should never be possible to submit a transaction as `network`. ## Future work diff --git a/protocol/0040-ASSF-asset_framework.md b/protocol/0040-ASSF-asset_framework.md index 4bcefdd5f..ed2a82d75 100644 --- a/protocol/0040-ASSF-asset_framework.md +++ b/protocol/0040-ASSF-asset_framework.md @@ -293,11 +293,11 @@ Once a withdrawal is complete and the appropriate events/transaction information For each asset class to be considered "supported" by Vega, the following must happen: -1. An asset of that class can Be voted into Vega (0040-ASSF-001)(0040-SP-ASSF-001) -2. An asset previously voted in can be voted out of Vega (0040-COSMICELEVATOR-002)(0040-SP-COSMICELEVATOR-002) -3. A voted-in asset can be deposited into a Vega bridge (0040-ASSF-003)(0040-SP-ASSF-003) -4. A properly deposited asset is credited to the appropriate user (0040-ASSF-004)(0040-SP-ASSF-004) -5. A withdrawal can be requested and verified by Vega validator nodes (0040-ASSF-005)(0040-SP-ASSF-005) -6. multisig withdrawal order signatures from Vega validator nodes can be aggregated at the request of the user (0040-ASSF-006)(0040-SP-ASSF-006) -7. A user can submit the withdrawal order and receive their asset (0040-ASSF-007)(0040-SP-ASSF-007) -8. Every asset must specify `quantum` and this must be an integer strictly greater than `0` (0040-ASSF-008)(0040-SP-ASSF-008) +1. An asset of that class can Be voted into Vega (0040-ASSF-001) +2. An asset previously voted in can be voted out of Vega (0040-COSMICELEVATOR-002) +3. A voted-in asset can be deposited into a Vega bridge (0040-ASSF-003) +4. A properly deposited asset is credited to the appropriate user (0040-ASSF-004) +5. A withdrawal can be requested and verified by Vega validator nodes (0040-ASSF-005) +6. multisig withdrawal order signatures from Vega validator nodes can be aggregated at the request of the user (0040-ASSF-006) +7. A user can submit the withdrawal order and receive their asset (0040-ASSF-007) +8. Every asset must specify `quantum` and this must be an integer strictly greater than `0` (0040-ASSF-008) diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index 6bf36b971..e25d2b106 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -199,11 +199,11 @@ All parameters that are changed through a governance vote are valid starting the Epochs change at the end of the first block that is after the epoch expiry has passed: -- Given an epoch length of `x`, with a block time arbitrary but `0050-EPOC-001)(0050-SP-EPOC-001) -- Given an epoch length of `x`, with a block time `x/y`, at end of block `y-1` the current epoch is `1` (0050-EPOC-002)(0050-SP-EPOC-002) -- Given an epoch length of `x`, with a block time of `x/y`, at end of block `y` the current epoch is `2` (0050-EPOC-003)(0050-SP-EPOC-003) +- Given an epoch length of `x`, with a block time arbitrary but `0050-EPOC-001) +- Given an epoch length of `x`, with a block time `x/y`, at end of block `y-1` the current epoch is `1` (0050-EPOC-002) +- Given an epoch length of `x`, with a block time of `x/y`, at end of block `y` the current epoch is `2` (0050-EPOC-003) -Edge case: Multiple epochs can pass within the same block (0050-EPOC-004)(0050-SP-EPOC-004): +Edge case: Multiple epochs can pass within the same block (0050-EPOC-004): - Given an epoch length of `x`, with a block time of `x*y`, at end of block 1 the current epoch is `1` - Given an epoch length of `x`, with a block time of `x*y`, at end of block `y+1` the current epoch is `y+1` @@ -211,9 +211,9 @@ Edge case: Multiple epochs can pass within the same block (0050-EPOC-005)(0050-SP-EPOC-005) (note: this can be tested by trying to delegate again, which will be rejected) - - `validator 1`s nominated balance is not increased in epoch 1 (0050-EPOC-006)(0050-SP-EPOC-006) - - `validator 1`s nominated balance is increased in the first block of epoch 2 (0050-EPOC-007)(0050-SP-EPOC-007) + - `party 1`s staking balanced is reduced immediately upon execution of the transaction (0050-EPOC-005)(note: this can be tested by trying to delegate again, which will be rejected) + - `validator 1`s nominated balance is not increased in epoch 1 (0050-EPOC-006) + - `validator 1`s nominated balance is increased in the first block of epoch 2 (0050-EPOC-007) ## See also diff --git a/protocol/0061-REWP-pos_rewards.md b/protocol/0061-REWP-pos_rewards.md index 0fc6ebd15..9c78a5cbf 100644 --- a/protocol/0061-REWP-pos_rewards.md +++ b/protocol/0061-REWP-pos_rewards.md @@ -93,7 +93,7 @@ For ersatz validators, the same formula is used. ## Acceptance criteria -### Spare key on multisig (0061-REWP-001)(0061-SP-REWP-001) +### Spare key on multisig (0061-REWP-001) 1. Four or more Tendermint validators with equal own+delegated stake and some ersatz validators are running. 1. Reward pool is funded. @@ -101,12 +101,12 @@ For ersatz validators, the same formula is used. 1. One of the Tendermint validators goes offline forever and is removed from the set of Tendermint validators but their key still stays on multisig (no-one updated). 1. Epoch ends and multisig hasn't been updated. 1. Tendermint validators get no rewards. Ersatz validators still receive rewards. - - A validator with less than `minOwnStake` tokens staked to themselves will earn 0 rewards at the end of an epoch (0061-REWP-002)(0061-SP-REWP-002) - - With `delegator_share` set to `0`, a validator keeps 100% of their own rewards, and a delegator receives no reward (0061-REWP-003)(0061-SP-REWP-003) - - With `delegator_share` set to `1`, a validator receives no reward, and their delegators receive a proportional amount of 100% (0061-REWP-004)(0061-SP-REWP-004) - - With `delegator_share` set to `0.5`, a validator keeps 50% of their own reward, and their delegators receives a proportional amount of the remaining 50% (0061-REWP-005)(0061-SP-REWP-005) + - A validator with less than `minOwnStake` tokens staked to themselves will earn 0 rewards at the end of an epoch (0061-REWP-002) + - With `delegator_share` set to `0`, a validator keeps 100% of their own rewards, and a delegator receives no reward (0061-REWP-003) + - With `delegator_share` set to `1`, a validator receives no reward, and their delegators receive a proportional amount of 100% (0061-REWP-004) + - With `delegator_share` set to `0.5`, a validator keeps 50% of their own reward, and their delegators receives a proportional amount of the remaining 50% (0061-REWP-005) -### Rewards distribution corresponds to the signers on the multisig contract in the case that it hasn’t been updated after a validator set change (0061-REWP-006)(0061-SP-REWP-006) +### Rewards distribution corresponds to the signers on the multisig contract in the case that it hasn’t been updated after a validator set change (0061-REWP-006) 1. Four or more Tendermint validators with equal own+delegated stake and some ersatz validators are running. 1. There is a one-to-one correspondence between Tendermint validators' ethereum keys and keys on multisig. @@ -116,7 +116,7 @@ For ersatz validators, the same formula is used. 1. Epoch ends and multisig hasn't been updated. 1. All Tendermint validators get no rewards. Ersatz validators still receive rewards. -### Rewards from trading fees are calculated and distributed (0061-REWP-007)(0061-SP-REWP-007) +### Rewards from trading fees are calculated and distributed (0061-REWP-007) 1. Run Vega with at least 3 tendermint validator nodes and at least 5 ersatz validator nodes each with different self-stake and delegation. 1. A market is launched with settlement asset A, infrastructure fee of `0.01 = 1%`. Market leaves opening auction and at least 10 trades occur with a total traded notable for fee purposes of at least 10000000 A. @@ -126,7 +126,7 @@ For ersatz validators, the same formula is used. ### Change of network parameters -1. Change of network parameter `reward.staking.delegation.competitionLevel` will change the level of competition of the validators (influences how much stake is be needed for all validators to reach optimal revenue) at the end of the next epoch. Default value 3.1. Minimum value 1 (inclusive). (0061-REWP-008)(0061-SP-REWP-008) -1. Change of network parameter `reward.staking.delegation.minimumValidatorStake` will change minimum amount required of own stake a validator has. Minimum stake applies to all validators. it’s referred to as a prerequisite to being considered a validator. Validators not met with the minimum stake will not be all thrown, and in fact unless there’s someone who can replace them no one will be kicked out. If there is an ersatz ready to replace them only one will be replaced every epoch. (0061-REWP-009)(0061-SP-REWP-009) -1. Change of the network parameter `reward.staking.delegation.optstakemultiplier` is changed to 0 (the reward curve is flat for a validator that exceeds optimal stake), to 0.5 (the reward curve goes down), and 0.1 (the reward curve goes down slightly).(0061-REWP-010)(0061-SP-REWP-010) -1. Change of network parameter `reward.staking.delegation.delegatorShare` to 0 (no reward for delegators), 0.99, and 0.5. The share for delegators at the end of the epochs changes accordingly. (0061-REWP-011)(0061-SP-REWP-011) +1. Change of network parameter `reward.staking.delegation.competitionLevel` will change the level of competition of the validators (influences how much stake is be needed for all validators to reach optimal revenue) at the end of the next epoch. Default value 3.1. Minimum value 1 (inclusive). (0061-REWP-008) +1. Change of network parameter `reward.staking.delegation.minimumValidatorStake` will change minimum amount required of own stake a validator has. Minimum stake applies to all validators. it’s referred to as a prerequisite to being considered a validator. Validators not met with the minimum stake will not be all thrown, and in fact unless there’s someone who can replace them no one will be kicked out. If there is an ersatz ready to replace them only one will be replaced every epoch. (0061-REWP-009) +1. Change of the network parameter `reward.staking.delegation.optstakemultiplier` is changed to 0 (the reward curve is flat for a validator that exceeds optimal stake), to 0.5 (the reward curve goes down), and 0.1 (the reward curve goes down slightly).(0061-REWP-010) +1. Change of network parameter `reward.staking.delegation.delegatorShare` to 0 (no reward for delegators), 0.99, and 0.5. The share for delegators at the end of the epochs changes accordingly. (0061-REWP-011) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 20d6b8760..b6209beaa 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -93,29 +93,29 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - More than the allowed quota through delegation change only - More than the allowed quota through undelegation only (this might require lowering the parameter) -- More than the allowed quota through a mix, where each individual set of messages is within the quota (0062-SPAM-001)(0062-SP-SPAM-001) -- Delegating while having less than one vega (`10^18` of our smallest unit) (`spam.protection.delegation.min.tokens`) (0062-SPAM-002)(0062-SP-SPAM-002) -- Making a proposal when having less than 100.000 vega (`spam.protection.proposal.min.tokens`) (0062-SPAM-003)(0062-SP-SPAM-003) -- Changing the value of network parameter `spam.protection.proposal.min.tokens` will immediately change the minimum number of associated tokens needed for any kind of governance proposal. Proposals already active aren't affected.(0062-SPAM-014)(0062-SP-SPAM-014) -- Transactions creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004)(0062-SP-SPAM-004) -- Transactions submitting votes by parties with less than `spam.protection.voting.min.tokens` of Vega associated are rejected. (0062-SPAM-005)(0062-SP-SPAM-005) -- Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006)(0062-SP-SPAM-006) -- Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007)(0062-SP-SPAM-007) -- If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008)(0062-SP-SPAM-008) -- It is possible for spam transactions to fill a block (0062-SPAM-010)(0062-SP-SPAM-010) -- Parties that continue spamming are blocked and eventually unblocked again (0062-SPAM-011)(0062-SP-SPAM-011) -- Any rejection due to spam protection is reported to the user upon transaction submission detailing which criteria the key exceeded / not met (0062-SPAM-013)(0062-SP-SPAM-013) -- If a party is banned for too many voting-rejections, it still can send trading related transactions which are not banned. (0062-SPAM-025)(0062-SP-SPAM-025) -- If the ban of a party ends because the banning time is up, transactions from that party are no longer rejected (0062-SPAM-015)(0062-SP-SPAM-015) -- If the ban of a party ends because the epoch ends, transactions from that party are no longer rejected (0062-SPAM-016)(0062-SP-SPAM-016) -- If a party gets banned, the ban ends due to the epoch ending, and it gets banned again at the beginning of the new epoch, the ban still lasts the entire time (or until the next epoch end), i.e., the ban-expiration timer is reset. (0062-SPAM-017)(0062-SP-SPAM-017) -- If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018)(0062-SP-SPAM-018) -- A ban only affects transactions of the type that caused the ban, i.e., a voting ban only affects further votes.(0062-SPAM-019)(0062-SP-SPAM-019) -- After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020)(0062-SP-SPAM-020) -- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021)(0062-SP-SPAM-021) -- Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022)(0062-SP-SPAM-022) -- Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023)(0062-SP-SPAM-023) -- Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024)(0062-SP-SPAM-024) -- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001)(0062-SP-COSMICELEVATOR-001) +- More than the allowed quota through a mix, where each individual set of messages is within the quota (0062-SPAM-001) +- Delegating while having less than one vega (`10^18` of our smallest unit) (`spam.protection.delegation.min.tokens`) (0062-SPAM-002) +- Making a proposal when having less than 100.000 vega (`spam.protection.proposal.min.tokens`) (0062-SPAM-003) +- Changing the value of network parameter `spam.protection.proposal.min.tokens` will immediately change the minimum number of associated tokens needed for any kind of governance proposal. Proposals already active aren't affected.(0062-SPAM-014) +- Transactions creating more than `spam.protection.max.proposals` proposals in one epoch are rejected. (0062-SPAM-004) +- Transactions submitting votes by parties with less than `spam.protection.voting.min.tokens` of Vega associated are rejected. (0062-SPAM-005) +- Transactions submitting a vote more than `spam.protection.max.votes` times on any one proposal are rejected. (0062-SPAM-006) +- Above thresholds are exceeded in one block, leading to a post-block-rejection (0062-SPAM-007) +- If 50% of a parties votes/transactions are post-block-rejected, it is blocked for 4 Epochs and unblocked afterwards again (0062-SPAM-008) +- It is possible for spam transactions to fill a block (0062-SPAM-010) +- Parties that continue spamming are blocked and eventually unblocked again (0062-SPAM-011) +- Any rejection due to spam protection is reported to the user upon transaction submission detailing which criteria the key exceeded / not met (0062-SPAM-013) +- If a party is banned for too many voting-rejections, it still can send trading related transactions which are not banned. (0062-SPAM-025) +- If the ban of a party ends because the banning time is up, transactions from that party are no longer rejected (0062-SPAM-015) +- If the ban of a party ends because the epoch ends, transactions from that party are no longer rejected (0062-SPAM-016) +- If a party gets banned, the ban ends due to the epoch ending, and it gets banned again at the beginning of the new epoch, the ban still lasts the entire time (or until the next epoch end), i.e., the ban-expiration timer is reset. (0062-SPAM-017) +- If a party gets banned several times during an epoch, all banns last for the defined time or until the epoch ends (try with at least three banns) (0062-SPAM-018) +- A ban only affects transactions of the type that caused the ban, i.e., a voting ban only affects further votes.(0062-SPAM-019) +- After having been banned for too many votes and unbanned, with the maximum number of votes in that epoch exceeded, any additional votes are rejected without a new ban. (0062-SPAM-020) +- Try to create a withdrawal bundle for an amount smaller than defined by `spam.protection.minimumWithdrawalQuantumMultiple x quantum` and verify that it is rejected (0062-SPAM-021) +- Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) +- Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) +- Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) +- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. diff --git a/protocol/0063-VALK-validator_vega_master_keys.md b/protocol/0063-VALK-validator_vega_master_keys.md index 3c1b08858..2082626d7 100644 --- a/protocol/0063-VALK-validator_vega_master_keys.md +++ b/protocol/0063-VALK-validator_vega_master_keys.md @@ -34,16 +34,16 @@ The public master key has to be added to validators' identities in the genesis c ## Acceptance Criteria -- There is a function (not necessarily inside core) that takes the master key and an index and computes the corresponding hot key (0063-VALK-001)(0063-SP-VALK-001) -- A transaction can be submitted to the network to initiate a Vega key rotation (0063-VALK-002)(0063-SP-VALK-002) -- A transaction submitted by an old hot-key after `target_block` is not associated by the network as being from a Validator (0063-VALK-003)(0063-VSP-ALK-003) -- Once `target_block` has been reached the network reports the new key as the validators hot-key (0063-VALK-004)(0063-SP-VALK-004) -- A key rotation submission which is not signed by the master key is rejected causing a transaction-error event that is visible by the whole network. (0063-VALK-005)(0063-SP-VALK-005) -- It is possible to perform parallel key rotations rotations successfully in the same block. (0063-VALK-006)(0063-SP-VALK-006) -- Once a validator hot key has been rotated all applicable rewards are correctly received. (0063-VALK-007)(0063-SP-VALK-007) -- Once a validator hot key has been rotated staking and delegation to the validator works as before. (0063-VALK-008)(0063-SP-VALK-008) -- Once a validator hot key has been rotated self-staking and self-delegation for the validator works as before. (0063-VALK-009)(0063-SP-VALK-009) -- If several key change transactions are submitted simultaneously (i.e., a new key change is submitted before the target block of a previous one is reached), if key change message 1 has a lower sequence number and a higher/the same target block as change message 2, then the key established by message 2 is not replaced by the key from message 1. This can be done either by managing the parallel executions appropriately or by rejecting additional submissions(0063-VALK-010)(0063-SP-VALK-010) -- Once the target block of a key change action us reached, all preceding keys (the original key as well as all hot keys rotated in through a key-change ,messager with a lower sequence number) are invalid. (0063-VALK-011)(0063-SP-VALK-011) -- Key change message with a lower sequence number than the last one executed are rejected. (0063-VALK-012)(0063-SP-VALK-012) -- Once a validator hot key has been rotated, it is possible to withdraw all rewards in the original keys account or submit a transfer to move them to the new key's account i.e the old key is still functional as a non-validator vega key. (0063-VALK-013)(0063-SP-VALK-013) +- There is a function (not necessarily inside core) that takes the master key and an index and computes the corresponding hot key (0063-VALK-001) +- A transaction can be submitted to the network to initiate a Vega key rotation (0063-VALK-002) +- A transaction submitted by an old hot-key after `target_block` is not associated by the network as being from a Validator (0063-VALK-003) +- Once `target_block` has been reached the network reports the new key as the validators hot-key (0063-VALK-004) +- A key rotation submission which is not signed by the master key is rejected causing a transaction-error event that is visible by the whole network. (0063-VALK-005) +- It is possible to perform parallel key rotations rotations successfully in the same block. (0063-VALK-006) +- Once a validator hot key has been rotated all applicable rewards are correctly received. (0063-VALK-007) +- Once a validator hot key has been rotated staking and delegation to the validator works as before. (0063-VALK-008) +- Once a validator hot key has been rotated self-staking and self-delegation for the validator works as before. (0063-VALK-009) +- If several key change transactions are submitted simultaneously (i.e., a new key change is submitted before the target block of a previous one is reached), if key change message 1 has a lower sequence number and a higher/the same target block as change message 2, then the key established by message 2 is not replaced by the key from message 1. This can be done either by managing the parallel executions appropriately or by rejecting additional submissions(0063-VALK-010) +- Once the target block of a key change action us reached, all preceding keys (the original key as well as all hot keys rotated in through a key-change ,messager with a lower sequence number) are invalid. (0063-VALK-011) +- Key change message with a lower sequence number than the last one executed are rejected. (0063-VALK-012) +- Once a validator hot key has been rotated, it is possible to withdraw all rewards in the original keys account or submit a transfer to move them to the new key's account i.e the old key is still functional as a non-validator vega key. (0063-VALK-013) diff --git a/protocol/0064-VALP-validator_performance_based_rewards.md b/protocol/0064-VALP-validator_performance_based_rewards.md index 464b6f013..e3fc1bd14 100644 --- a/protocol/0064-VALP-validator_performance_based_rewards.md +++ b/protocol/0064-VALP-validator_performance_based_rewards.md @@ -54,16 +54,16 @@ The performance score should be available on all the same API endpoints as the ` ### Performance score -1. Tendermint validator with insufficient self-delegation (0064-VALP-001)(0064-SP-VALP-001): +1. Tendermint validator with insufficient self-delegation (0064-VALP-001): - Set up a network with 5 validators - Self-delegate to 4 of the nodes **more** than the minimum amount set in `reward.staking.delegation.minimumValidatorStake`. - Self-delegate to the 5th node **less** than the minimum amount. - Verify that at the beginning of the next epoch the performance score of the 5th validator is 0. -1. Tendermint validator with sufficient self-delegation (0064-VALP-002)(0064-SP-VALP-002): +1. Tendermint validator with sufficient self-delegation (0064-VALP-002): - Setup a network with 5 validators. - Self-delegate to all of them more than the minimum required. - Verify that after an epoch has passed, the performance score of all of them is close to 1. -1. Tendermint validator down (0064-VALP-003)(0064-SP-VALP-003): +1. Tendermint validator down (0064-VALP-003): - Setup a network with 5 validators. - Self-delegate to all of them more than the minimum required in `reward.staking.delegation.minimumValidatorStake` and ensure the validators self-stake is an equal amount across all. - Run the network for one epoch. @@ -71,7 +71,7 @@ The performance score should be available on all the same API endpoints as the ` - Run the network for half an epoch then shut down validator 5. - Verify that at the beginning of the next epoch the performance score for validator 5 is close to 0.5. - Verify that, with validator 5 still down for the next epoch, at the beginning of the following epoch the performance score for validator 5 is 0. -1. Non Tendermint validator (0064-VALP-004)(0064-SP-VALP-004): +1. Non Tendermint validator (0064-VALP-004): - Set the network parameter `network.validators.minimumEthereumEventsForNewValidator` to 0. - Setup a network with 5 validators and self-delegate to them. - Announce a new node to the network and self-delegate to them. @@ -80,12 +80,12 @@ The performance score should be available on all the same API endpoints as the ` - Let the network run for `numBlocks` blocks (*where `numBlocks = max(min(50, epochDurationSeconds), epochDurationSeconds x 0.01)`*) more and at the following epoch check that score is up to 0.2. Keep it running until its performance score of the joining validator reaches 1, then stop it. - Verify that for every `numBlocks` blocks (*where `numBlocks = max(min(50, epochDurationSeconds), epochDurationSeconds x 0.01)`*), the performance score should go down by 0.1 until it reaches zero. - **Note:** Every `numBlocks` the performance score should go up by 0.1. Now the performance score is only visible every epoch so depending on the ratio between `numBlocks` and epoch duration it may tick once or more per epoch. Guidance is that this test should either be parameterised or, preferably, written with a given epoch duration -1. Insufficient stake (0064-VALP-005)(0064-SP-VALP-005): +1. Insufficient stake (0064-VALP-005): - Setup a network with 5 validators, self-delegate to each more than the required minimum as set out in `reward.staking.delegation.minimumValidatorStake`. - Verify that at the beginning of the next epoch the validator has non 0 performance score, and voting power is greater than 10. - Update the network parameter `reward.staking.delegation.minimumValidatorStake` for minimum self-stake to be more than is self-delegated. - Verify that, at the beginning of the next epoch, all performance scores are 0 and voting power for all is 1 but the network keeps producing blocks and no nodes were removed from Tendermint. -1. Scores are restored after a snapshot restart (0064-VALP-006)(0064-SP-VALP-006): +1. Scores are restored after a snapshot restart (0064-VALP-006): - With a snapshot that was taken at a block-height that falls in the middle of an epoch, restart a node from that snapshot. Ensure that at the end of the epoch the node remains in consensus and has produced the correct performance scores. ## Future Stuff (in here for discussion purposes, not yet to be implemented) diff --git a/protocol/0066-VALW-validator_tendermint_weights.md b/protocol/0066-VALW-validator_tendermint_weights.md index 923be50f6..c48207e58 100644 --- a/protocol/0066-VALW-validator_tendermint_weights.md +++ b/protocol/0066-VALW-validator_tendermint_weights.md @@ -14,7 +14,7 @@ If the network has no stake at all, then all validators would have equal voting ## Acceptance criteria -### Basic sanity check (0066-VALW-001)(0066-SP-VALW-001) +### Basic sanity check (0066-VALW-001) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `2000` @@ -27,7 +27,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='2000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2066\ - Node 5 n[`stakedByOperator`]='2000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=1735 -### Non-uniform stake check (0066-VALW-002)(0066-SP-VALW-002) +### Non-uniform stake check (0066-VALW-002) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `500`. @@ -39,7 +39,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2092\ - Node 5 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2383 -### Zero stake check (0066-VALW-003)(0066-SP-VALW-003) +### Zero stake check (0066-VALW-003) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `0`. @@ -51,7 +51,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2419\ - Node 5 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' ``n_voting_power``=2741 -### Changes to delegation during the epoch are reflected in the next epoch’s voting power (0066-SP-VALW-004)(0066-VALW-004) +### Changes to delegation during the epoch are reflected in the next epoch’s voting power (0066-SP-VALW-004) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `0`. @@ -71,7 +71,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2564\ - Node 5 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=64 -### Sanity check if everyone unstakes and undelegates (0066-SP-VALW-005)(0066-VALW-005) +### Sanity check if everyone unstakes and undelegates (0066-SP-VALW-005) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `2000` @@ -86,7 +86,7 @@ If the network has no stake at all, then all validators would have equal voting 1. wait for 1000 blocks to pass 1. the Tendermint weights for each validator are `10` each as there is no stake in the network. -### Validator has 1000 stake but 500 delegated (0066-VALW-006)(0066-SP-VALW-006) +### Validator has 1000 stake but 500 delegated (0066-VALW-006) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `1000` @@ -99,7 +99,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2033\ - Node 5 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=1830 -### Validators without self-delegated, check (0066-VALW-007)(0066-SP-VALW-007) +### Validators without self-delegated, check (0066-VALW-007) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `0` @@ -112,7 +112,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='0' n[`stakedByDelegates`]='4000000000000000000' `n_voting_power`=3113\ - Node 5 n[`stakedByOperator`]='0' n[`stakedByDelegates`]='0' `n_voting_power`=1 -### Validators delegating to other validators (0066-VALW-008)(0066-SP-VALW-008) +### Validators delegating to other validators (0066-VALW-008) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `1000` @@ -125,7 +125,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2551\ - Node 5 n[`stakedByOperator`]='0' n[`stakedByDelegates`]='0' `n_voting_power`=1 -### Validator delegate and undelegate in the same epoch (0066-VALW-009)(0066-SP-VALW-009) +### Validator delegate and undelegate in the same epoch (0066-VALW-009) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `1000` From 91d570f29da1ecf1e812e4f61486ae82384e9203 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 19:25:49 +0200 Subject: [PATCH 260/649] feat: remove spot 75/76/77 --- protocol/0075-PLUP-protocol_upgrades.md | 105 ++++++++++++------------ protocol/0076-DANO-data-node.md | 77 ++++++++--------- protocol/0077-SNAP-snapshots.md | 13 +-- 3 files changed, 99 insertions(+), 96 deletions(-) diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index 9a9f5913a..aff401dd5 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -104,70 +104,70 @@ message ProtocolUpgradeEvent { ### Invalid proposals - Rejections - A network with 5 validators -- (0075-PLUP-001)(0075-SP-PLUP-001) Validator proposes a protocol upgrade to an invalid [tag](https://semver.org/) - should result in an error -- (0075-PLUP-002)(0075-SP-PLUP-002) Validator proposes a protocol upgrade on a block height preceding the current block - should result in an error -- (0075-PLUP-003)(0075-SP-PLUP-003) Propose and enact a version downgrade -- (0075-PLUP-004)(0075-SP-PLUP-004) Non-validator attempts to propose upgrade -- (0075-PLUP-005)(0075-SP-PLUP-005) Ersatz validator (standby validator) attempts to propose upgrade +- (0075-PLUP-001) Validator proposes a protocol upgrade to an invalid [tag](https://semver.org/) - should result in an error +- (0075-PLUP-002) Validator proposes a protocol upgrade on a block height preceding the current block - should result in an error +- (0075-PLUP-003) Propose and enact a version downgrade +- (0075-PLUP-004) Non-validator attempts to propose upgrade +- (0075-PLUP-005) Ersatz validator (standby validator) attempts to propose upgrade ### Block height validation Proposal will not be accepted as valid if validator: -- (0075-PLUP-006)(0075-SP-PLUP-006) Proposes a negative upgrade block -- (0075-PLUP-007)(0075-SP-PLUP-007) Proposes a 0 upgrade block -- (0075-PLUP-008)(0075-SP-PLUP-008) Proposes (string/other upgrade block) -- (0075-PLUP-009)(0075-SP-PLUP-009) Proposes without supplying a block height +- (0075-PLUP-006) Proposes a negative upgrade block +- (0075-PLUP-007) Proposes a 0 upgrade block +- (0075-PLUP-008) Proposes (string/other upgrade block) +- (0075-PLUP-009) Proposes without supplying a block height ### VISOR -- (0075-PLUP-010)(0075-SP-PLUP-010) Can be seen to automatically download the tagged version proposed for install when available at the source location when file meets the format criteria defined -- (0075-PLUP-011)(0075-SP-PLUP-011) Visor automatically upgrades validators to proposed version if required majority has been reached +- (0075-PLUP-010) Can be seen to automatically download the tagged version proposed for install when available at the source location when file meets the format criteria defined +- (0075-PLUP-011) Visor automatically upgrades validators to proposed version if required majority has been reached ### Epochs -- ((0075-COSMICELEVATOR-012))((0075-SP-COSMICELEVATOR-012)) Proposing an upgrade block which ought to be the end of an epoch. After upgrade takes place, confirm rewards are distributed, any pending delegations take effect, and validator joining/leaving takes effect. -- (0075-PLUP-013)(0075-SP-PLUP-013) Propose an upgrade block which should result in a network running new code version in the same epoch. -- (0075-PLUP-014)(0075-SP-PLUP-014) Ensure end of epoch processes still run after restore e.g reward calculation and distributions +- ((0075-COSMICELEVATOR-012)) Proposing an upgrade block which ought to be the end of an epoch. After upgrade takes place, confirm rewards are distributed, any pending delegations take effect, and validator joining/leaving takes effect. +- (0075-PLUP-013) Propose an upgrade block which should result in a network running new code version in the same epoch. +- (0075-PLUP-014) Ensure end of epoch processes still run after restore e.g reward calculation and distributions ### Required Majority For the purposes of protocol upgrade each validator that participates in consensus has one vote. Required majority is set by `validators.vote.required network parameter`. -- (0075-PLUP-015)(0075-SP-PLUP-015) Counting proposal votes to check if required majority has been reached occurs when any proposed target block has been reached -- (0075-PLUP-016)(0075-SP-PLUP-016) Only proposals from validators participating in consensus are counted when any proposed target block has been reached. -- (0075-PLUP-017)(0075-SP-PLUP-017) Events are emitted for all proposals which fail to reach required majority when target block is reached -- (0075-PLUP-018)(0075-SP-PLUP-018) When majority reached during the process of upgrading, those validators which didn't propose will stop producing blocks -- (0075-PLUP-019)(0075-SP-PLUP-019) Proposals for multiple versions at same block height will be rejected if majority has not been reached, network continues with the current running version -- (0075-PLUP-020)(0075-SP-PLUP-020) Propose with a validator which is moved to Ersatz by the time the upgrade is enacted. If there are 5 validators, 3 vote yes, 2 vote no: One of the yes voters is kicked in favour of a new one, leaving the vote at 2-2 so the upgrade should not happen as counting votes happens at block height only -- (0075-PLUP-036)(0075-SP-PLUP-036) Changing `validators.vote.required` network parameter to a value above two thirds is respected. -- (0075-PLUP-037)(0075-SP-PLUP-037) The value of `validators.vote.required` is checked at upgrade block, i.e: vote on a proposal with all validators, then change the `validators.vote.required` network parameter before upgrade block, to a higher value, which would cause the upgrade to be rejected. Upgrade fails. +- (0075-PLUP-015) Counting proposal votes to check if required majority has been reached occurs when any proposed target block has been reached +- (0075-PLUP-016) Only proposals from validators participating in consensus are counted when any proposed target block has been reached. +- (0075-PLUP-017) Events are emitted for all proposals which fail to reach required majority when target block is reached +- (0075-PLUP-018) When majority reached during the process of upgrading, those validators which didn't propose will stop producing blocks +- (0075-PLUP-019) Proposals for multiple versions at same block height will be rejected if majority has not been reached, network continues with the current running version +- (0075-PLUP-020) Propose with a validator which is moved to Ersatz by the time the upgrade is enacted. If there are 5 validators, 3 vote yes, 2 vote no: One of the yes voters is kicked in favour of a new one, leaving the vote at 2-2 so the upgrade should not happen as counting votes happens at block height only +- (0075-PLUP-036) Changing `validators.vote.required` network parameter to a value above two thirds is respected. +- (0075-PLUP-037) The value of `validators.vote.required` is checked at upgrade block, i.e: vote on a proposal with all validators, then change the `validators.vote.required` network parameter before upgrade block, to a higher value, which would cause the upgrade to be rejected. Upgrade fails. -### Multiple proposals (0075-PLUP-021)(0075-SP-PLUP-021) +### Multiple proposals (0075-PLUP-021) - If multiple proposals are submitted from a validator before the block heights are reached then only the last proposal is considered -## Spam (0075-COSMICELEVATOR-022)(0075-SP-COSMICELEVATOR-022) +## Spam (0075-COSMICELEVATOR-022) - Excessive numbers of proposals from a single validator within an epoch should be detected and rejected - (Future requirement) ## Snapshots -- (0075-PLUP-023)(0075-SP-PLUP-023) Post a validator becoming a consensus-participating validator they should be immediately allowed to propose an upgrade and be included in the overall total count -- (0075-PLUP-024)(0075-SP-PLUP-024) Ensure that required majority is not met when enough validators join between validator proposals and target block, i.e: In a network with 5 validators, required majority is two thirds, 4 vote to upgrade, 2 more validators join before upgrade block and do not vote. Upgrade does not take place. -- (0075-PLUP-025)(0075-SP-PLUP-025) Node starting from snapshot which has a proposal at a given block, ensure during replay when the block height is reached a new version is loaded and also post load an upgrade takes place at target block. -- (0075-PLUP-045)(0075-SP-PLUP-045) Arrange a network where n nodes are required for consensus, and at least n+1 nodes in the network. Schedule a protocol upgrade where n-1 nodes automatically start on the new version after upgrade, i.e: No consensus after upgrade. Start the (n+1)th node and consensus is achieved. For the nth node, clear vega and tm, and restart the node using state-sync at the upgrade block height. All nodes produce blocks. +- (0075-PLUP-023) Post a validator becoming a consensus-participating validator they should be immediately allowed to propose an upgrade and be included in the overall total count +- (0075-PLUP-024) Ensure that required majority is not met when enough validators join between validator proposals and target block, i.e: In a network with 5 validators, required majority is two thirds, 4 vote to upgrade, 2 more validators join before upgrade block and do not vote. Upgrade does not take place. +- (0075-PLUP-025) Node starting from snapshot which has a proposal at a given block, ensure during replay when the block height is reached a new version is loaded and also post load an upgrade takes place at target block. +- (0075-PLUP-045) Arrange a network where n nodes are required for consensus, and at least n+1 nodes in the network. Schedule a protocol upgrade where n-1 nodes automatically start on the new version after upgrade, i.e: No consensus after upgrade. Start the (n+1)th node and consensus is achieved. For the nth node, clear vega and tm, and restart the node using state-sync at the upgrade block height. All nodes produce blocks. ## LNL Checkpoints -- (0075-PLUP-026)(0075-SP-PLUP-026) Validator proposals should not be stored in the checkpoints and restored into the network -- (0075-PLUP-027)(0075-SP-PLUP-027) Upgrade will not occur after a post checkpoint restore until new proposals are made and block height reached +- (0075-PLUP-026) Validator proposals should not be stored in the checkpoints and restored into the network +- (0075-PLUP-027) Upgrade will not occur after a post checkpoint restore until new proposals are made and block height reached ## API -- (0075-PLUP-028)(0075-SP-PLUP-028) An datanode API should be available to provide information on the upcoming confirmed proposal including total proposals/block details/versions +- (0075-PLUP-028) An datanode API should be available to provide information on the upcoming confirmed proposal including total proposals/block details/versions -### Successful upgrade (0075-PLUP-029)(0075-SP-PLUP-029) +### Successful upgrade (0075-PLUP-029) - A new release is made available, and is successfully deployed - Setup a network with 5 validators running version x @@ -177,39 +177,39 @@ For the purposes of protocol upgrade each validator that participates in consens ### Failing consensus -- (0075-PLUP-030)(0075-SP-PLUP-030) Upgrade takes place at block N. Restart with a number of validators whose voting power is <= two thirds. Restart one more validator whose voting power would take the total voting power >= two thirds, with an incorrect version. Consensus is not achieved. Now restart that validator with the correct version. Consensus is achieved. -- (0075-PLUP-031)(0075-SP-PLUP-031) 5 validator network. Upgrade takes places at block N. Start 3 validators immediately. Allow several seconds to pass. - no blocks producing as 3 validators do not have enough weight - need 70% weight to produce blocks. Start two remaining validators. (All validators continue to work). -- (0075-PLUP-032)(0075-SP-PLUP-032) Upgrade takes place, but insufficient validators are restored for 1, 5, 10, minutes. Validators which are restored immediately patiently wait for consensus to be achieved, and then blocks continue - consensus achieved +- (0075-PLUP-030) Upgrade takes place at block N. Restart with a number of validators whose voting power is <= two thirds. Restart one more validator whose voting power would take the total voting power >= two thirds, with an incorrect version. Consensus is not achieved. Now restart that validator with the correct version. Consensus is achieved. +- (0075-PLUP-031) 5 validator network. Upgrade takes places at block N. Start 3 validators immediately. Allow several seconds to pass. - no blocks producing as 3 validators do not have enough weight - need 70% weight to produce blocks. Start two remaining validators. (All validators continue to work). +- (0075-PLUP-032) Upgrade takes place, but insufficient validators are restored for 1, 5, 10, minutes. Validators which are restored immediately patiently wait for consensus to be achieved, and then blocks continue - consensus achieved ### Mainnet -- (0075-COSMICELEVATOR-033)(0075-SP-COSMICELEVATOR-033) Check that we can protocol upgrade a system which has been restarted from mainnet snapshots with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. -- (0075-PLUP-046)(0075-SP-PLUP-046) Check that we can protocol upgrade a system which has been restarted from latest mainnet checkpoint with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. +- (0075-COSMICELEVATOR-033) Check that we can protocol upgrade a system which has been restarted from mainnet snapshots with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. +- (0075-PLUP-046) Check that we can protocol upgrade a system which has been restarted from latest mainnet checkpoint with current mainnet version, to next intended release version. Check all data available pre-upgrade is still available. ### Overwriting transactions -- (0075-PLUP-034)(0075-SP-PLUP-034) A proposal made to upgrade to the currently running version will retract previous proposals. i.e: System is running version V. Make a proposal for block height H and version V + 1 and vote with all validators. Before block height H, submit a new proposal for version V and any future block height, with all validators. Upgrade proposals are retracted, and upgrade does not take place. -- (0075-PLUP-035)(0075-SP-PLUP-035) Rejected proposals do not overwrite previous valid upgrade proposals. +- (0075-PLUP-034) A proposal made to upgrade to the currently running version will retract previous proposals. i.e: System is running version V. Make a proposal for block height H and version V + 1 and vote with all validators. Before block height H, submit a new proposal for version V and any future block height, with all validators. Upgrade proposals are retracted, and upgrade does not take place. +- (0075-PLUP-035) Rejected proposals do not overwrite previous valid upgrade proposals. ### Data is preserved -- (0075-PLUP-038)(0075-SP-PLUP-038) An open market with active orders which is available prior to upgrade, is still available, active, and can be traded on, post-upgrade. -- (0075-PLUP-039)(0075-SP-PLUP-039) Stake available prior to upgrade is still available post upgrade. -- (0075-PLUP-040)(0075-SP-PLUP-040) Active and pending delegations made prior to upgrade are still active post upgrade. -- (0075-PLUP-041)(0075-SP-PLUP-041) A market due to expire during an upgrade will terminate and/or settle post-upgrade. -- (0075-PLUP-042)(0075-SP-PLUP-042) Trader balances available prior to upgrade is still available post upgrade. -- (0075-PLUP-043) (0075-SP-PLUP-043) Pending and active assets available prior to upgrade is still available post upgrade. -- (0075-PLUP-044)(0075-SP-PLUP-044) Network parameter, market and asset proposals can span a protocol upgrade. +- (0075-PLUP-038) An open market with active orders which is available prior to upgrade, is still available, active, and can be traded on, post-upgrade. +- (0075-PLUP-039) Stake available prior to upgrade is still available post upgrade. +- (0075-PLUP-040) Active and pending delegations made prior to upgrade are still active post upgrade. +- (0075-PLUP-041) A market due to expire during an upgrade will terminate and/or settle post-upgrade. +- (0075-PLUP-042) Trader balances available prior to upgrade is still available post upgrade. +- (0075-PLUP-043) Pending and active assets available prior to upgrade is still available post upgrade. +- (0075-PLUP-044) Network parameter, market and asset proposals can span a protocol upgrade. ### Ethereum events during outage -- (0075-PLUP-051)(0075-SP-PLUP-051) Deposit events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-051) Deposit events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Schedule an upgrade on a network that is not using visor. 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. 1. Deposit tokens via the ERC20 bridge. 1. Start the network using the upgrade binary. 1. Balance reported as added in the appropriate account(s). -- (0075-PLUP-052)(0075-SP-PLUP-052) Staking events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-052) Staking events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Ensure parties A & B have some stake, which is delegated to a/some node(s). 1. Schedule an upgrade on a network that is not using visor. 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. @@ -217,14 +217,14 @@ For the purposes of protocol upgrade each validator that participates in consens 1. Remove some (not all) stake from party B. 1. Start the network using the upgrade binary. 1. Additional stake reported for party A and auto-delegated. Stake removed for party B and delegation reduced. -- (0075-PLUP-047)(0075-SP-PLUP-047) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-047) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Arrange a network where one validator is promoted to replace another validator. Collect signatures to update the multisig contract, but do not yet update the multisig. 1. Schedule an upgrade on the network (should not be using visor). 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. 1. Update the multisig contract to reflect the correct validators. 1. Start the network using the upgrade binary. 1. At the end of the current epoch, rewards are paid out. -- (0075-PLUP-048)(0075-SP-PLUP-048) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. +- (0075-PLUP-048) Multisig events that take place during protocol upgrade are registered by the network once the upgrade is complete. 1. Arrange a network where one validator is promoted to replace another validator. Collect signatures to update the multisig contract, but do not yet update the multisig. 1. Schedule an upgrade on the network (should not be using visor). 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. @@ -236,17 +236,18 @@ For the purposes of protocol upgrade each validator that participates in consens ### Transactions during upgrade -- (0075-PLUP-049)(0075-SP-PLUP-049) Network handles filled mempool during upgrade. +- (0075-PLUP-049) Network handles filled mempool during upgrade. 1. Schedule a protocol upgrade in a network with no nodes using visor. 1. When the nodes stop processing blocks for the upgrade, shut down the nodes. 1. Start one node on the new binary. 1. Send enough transactions to the node to fill the tendermint mempool. (Expect sane rejection once mempool is full) 1. Start the other nodes on the correct upgrade binary. 1. Expect all transactions that reached the mempool without being rejected to be correctly processed over several blocks. -- (0075-PLUP-050)(0075-SP-PLUP-050) Transactions can be made in block immediately before protocol upgrade. +- (0075-PLUP-050) Transactions can be made in block immediately before protocol upgrade. 1. Schedule a protocol upgrade in a network with no nodes using visor. 1. Continuously send transactions as the upgrade block approaches. 1. When the nodes stop processing blocks for the upgrade, make a note of all transactions which reached blocks already (transactions which did not are expected to be discarded). 1. Shut down the nodes. 1. Start all nodes on the new binary. 1. Expect all transactions that reached blocks prior to upgrade to have taken effect. None of the other transactions did. + diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 58b148230..03f863784 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -146,64 +146,65 @@ It must be possible to add to the data node APIs that return the result of calcu ### Data synchronisation -1. To ensure no loss of historical data access; data nodes must be able to have access to and synchronise all historical data since genesis block or LNL restart (0076-COSMICELEVATOR-001)(0076-SP-COSMICELEVATOR-001) -1. To ensure that new nodes joining the network have access to all historical data; nodes must be able to have access to and synchronise all historical data across the network without having to replay the full chain (0076-DANO-003)(0076-SP-DANO-003) -1. Nodes must be able to start processing new blocks having loaded the only the most recent history (0076-DANO-023)(0076-SP-DANO-023) -1. Nodes that have been temporarily disconnected from the network should be able to load the missed history to get back up to the current network height (or most recently produced history) and then be able to start processing new blocks (0076-DANO-024)(0076-DANOSP--024) -1. It must be possible to fetch history from the network whilst the node processes new blocks. So for example, if setting up a new Archive node, the node can keep up to date with the network whilst retrieving history all the way back to the first block. Once this is done the node should be able to reconcile the fetched history with that produced whilst the history was being retrieved such that the node will have a full history from the first block all the way to the networks current height. (0076-DANO-025)(0076-SP-DANO-025) -1. It must be possible to rollback the data-node to a previous block height and have it process events from this height onwards. The state of the datanode at the rollback height must match exactly the state of the node as it was when it originally reached the given height. (0076-DANO-039)(0076-SP-DANO-039) +1. To ensure no loss of historical data access; data nodes must be able to have access to and synchronise all historical data since genesis block or LNL restart (0076-COSMICELEVATOR-001) +1. To ensure that new nodes joining the network have access to all historical data; nodes must be able to have access to and synchronise all historical data across the network without having to replay the full chain (0076-DANO-003) +1. Nodes must be able to start processing new blocks having loaded the only the most recent history (0076-DANO-023) +1. Nodes that have been temporarily disconnected from the network should be able to load the missed history to get back up to the current network height (or most recently produced history) and then be able to start processing new blocks (0076-DANO-024) +1. It must be possible to fetch history from the network whilst the node processes new blocks. So for example, if setting up a new Archive node, the node can keep up to date with the network whilst retrieving history all the way back to the first block. Once this is done the node should be able to reconcile the fetched history with that produced whilst the history was being retrieved such that the node will have a full history from the first block all the way to the networks current height. (0076-DANO-025) +1. It must be possible to rollback the data-node to a previous block height and have it process events from this height onwards. The state of the datanode at the rollback height must match exactly the state of the node as it was when it originally reached the given height. (0076-DANO-039) ### Data integrity -1. Data produced in the core snapshots aligns with the data-node data proving that what is returned by data-node matches core state at any given block height (0076-DANO-004)(0076-SP-ANO-004) +1. Data produced in the core snapshots aligns with the data-node data proving that what is returned by data-node matches core state at any given block height (0076-DANO-004) ### Data-node decentralised history -1. Historical data must be available to load into the datanode and must not be dependent on any centralised entity. (0076-DANO-005)(0076-SP-DANO-005) -1. A datanode restored from decentralised history for a given block span must match exactly the state of a datanode that has the same block span of data created by consuming events. (0076-DANO-012)(0076-SP-DANO-012) -1. As the network produces more blocks the data should be stored correctly in the data-node after a data-node is restored from decentralised history. For example: Start a data-node from a given history segment for a known block height, ensure the datanode continues to update from that block onwards. (0076-DANO-007)(0076-SP-DANO-007). -1. It should not be necessary to restore the full history (i.e. from genesis block) to be able to process new blocks. Restoring just the most recent history segment should be sufficient for the node to process new blocks. (0076-DANO-006)(0076-SP-DANO-006) -1. No data is duplicated as the core emits events when catching up to the later block height. For example: Starting a core node at block height less than the data-node block height must result in no duplicated data (0076-DANO-008)(0076-SP-DANO-008) -1. Starting a core node at block height greater than the data-nodes block height must result in an error and a refusal to start (0076-DANO-014)(0076-SP-DANO-014) -1. If a data-node snapshot fails during the restore the process, it should error and the node(s) won't start (0076-DANO-009)(0076-SP-DANO-009) -1. When queried via the APIs a node restored from decentralised history should return identical results to a node with the same block span which has been populated by event consumption. [project front end dApps](https://github.com/vegaprotocol/frontend-monorepo/actions/workflows/generate-queries.yml). (0076-SP-DANO-022) -1. All network history retained by a node for a given block span and type must be downloadable in CSV format. (0076-DANO-040)(0076-SP-DANO-040) +1. Historical data must be available to load into the datanode and must not be dependent on any centralised entity. (0076-DANO-005) +1. A datanode restored from decentralised history for a given block span must match exactly the state of a datanode that has the same block span of data created by consuming events. (0076-DANO-012) +1. As the network produces more blocks the data should be stored correctly in the data-node after a data-node is restored from decentralised history. For example: Start a data-node from a given history segment for a known block height, ensure the datanode continues to update from that block onwards. (0076-DANO-007). +1. It should not be necessary to restore the full history (i.e. from genesis block) to be able to process new blocks. Restoring just the most recent history segment should be sufficient for the node to process new blocks. (0076-DANO-006) +1. No data is duplicated as the core emits events when catching up to the later block height. For example: Starting a core node at block height less than the data-node block height must result in no duplicated data (0076-DANO-008) +1. Starting a core node at block height greater than the data-nodes block height must result in an error and a refusal to start (0076-DANO-014) +1. If a data-node snapshot fails during the restore the process, it should error and the node(s) won't start (0076-DANO-009) +1. When queried via the APIs a node restored from decentralised history should return identical results to a node with the same block span which has been populated by event consumption. [project front end dApps](https://github.com/vegaprotocol/frontend-monorepo/actions/workflows/generate-queries.yml). (0076-DANO-022) +1. All network history retained by a node for a given block span and type must be downloadable in CSV format. (0076-DANO-040) ### Data-node network determinism -1. For a given block span, a datanode history segment must be identical across all dat-nodes in the network that are using the recommended hardware and OS versions (0076-DANO-010)(0076-SP-DANO-010) -1. History segments for the same block span must always match across the network, regardless of whether the producing node was itself restored from decentralised history or not. (0076-DANO-011)(0076-SP-DANO-011) +1. For a given block span, a datanode history segment must be identical across all dat-nodes in the network that are using the recommended hardware and OS versions (0076-DANO-010) +1. History segments for the same block span must always match across the network, regardless of whether the producing node was itself restored from decentralised history or not. (0076-DANO-011) ### Schema compatibility -1. It is possible to identify if schema versions are NOT backwards compatible. Pull existing network snapshots start network, run a protocol upgrade to at later version and ensure both the core state and data-node data is correct (0076-COSMICELEVATOR-XXX)(0076-SP-COSMICELEVATOR-XXX) -1. Restoring a node from decentralised history should work across schema upgrade boundaries and the state of the datanode should match that of a datanode populated purely by event consumption (0076-COSMICELEVATOR-XXX)(0076-SP-COSMICELEVATOR-XXX) +1. It is possible to identify if schema versions are NOT backwards compatible. Pull existing network snapshots start network, run a protocol upgrade to at later version and ensure both the core state and data-node data is correct (0076-COSMICELEVATOR-XXX) +1. Restoring a node from decentralised history should work across schema upgrade boundaries and the state of the datanode should match that of a datanode populated purely by event consumption (0076-COSMICELEVATOR-XXX) ### Data Retention -1. Lite nodes should have enough state to provide the current state of: Assets, Parties, Accounts, Balances, Live Orders, Network Limits, Nodes, Delegations, Markets, Margin Levels, Network Parameters, Positions, Liquidity Provisions (0076-DANO-026)(0076-SP-DANO-026) -2. Standard nodes should retain data in accordance with the configured data retention policy (0076-DANO-027)(0076-SP-DANO-027) -3. Archival nodes should retain all data from the height at which they joined the network (0076-DANO-028)(0076-SP-DANO-028) +1. Lite nodes should have enough state to provide the current state of: Assets, Parties, Accounts, Balances, Live Orders, Network Limits, Nodes, Delegations, Markets, Margin Levels, Network Parameters, Positions, Liquidity Provisions (0076-DANO-026) +2. Standard nodes should retain data in accordance with the configured data retention policy (0076-DANO-027) +3. Archival nodes should retain all data from the height at which they joined the network (0076-DANO-028) ### API Request Rate Limiting 1. Datanode should provide an optional mechanism for limiting the average number of requests per second over on its API 2. That rate should be specified in the datanode configuration file -3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. (0076-DANO-029)(0076-SP-DANO-029) -4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file (0076-DANO-030)(0076-SP-DANO-030) -5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031)(0076-SP-DANO-031) -6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032)(0076-SP-DANO-032) -7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033)(0076-SP-DANO-033) -8. If the rate of denied (due to rate limiting) requests subsequently exceed the same maximum rate/burst parameters the client should be banned (0076-DANO-034)(0076-SP-DANO-034) -9. The ban denies all access to the API for a configurable length of time (0076-DANO-035)(0076-SP-DANO-035) -10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036)(0076-SP-DANO-036) -11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037)(0076-SP-DANO-037) -12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client (0076-DANO-038)(0076-SP-DANO-038) +3. A client may, over a short period of time, make requests at a greater frequency than the limit as long as the average rate over a longer period of time is not exceeded. (0076-DANO-029) +4. The extent to which clients may of 'burst' requests should also be capped and specified in the datanode configuration file (0076-DANO-030) +5. Limits should be enforced on a per-client basis. Source IP address is a sufficient discriminator (0076-DANO-031) +6. Headers or metadata should be included in each API response indicating to the client what the limits are, and how close they currently are to exceeding them (0076-DANO-032) +7. If limits are exceeded an API appropriate error response should be returned, containing similar headers or metadata (0076-DANO-033) +8. If the rate of denied (due to rate limiting) requests subsequently exceed the same maximum rate/burst parameters the client should be banned (0076-DANO-034) +9. The ban denies all access to the API for a configurable length of time (0076-DANO-035) +10. For that time, any requests will receive an API appropriate error response indicating that they are banned (0076-DANO-036) +11. The rate limit for the GraphQL API should be configurable separately from the gRPC API and it's REST wrapper since a single GraphQL request can trigger many internal gRPC requests (0076-DANO-037) +12. Where one API makes use of another (e.g. GraphQL making use of gRPC), rate limits should be enforced only once, on the side that faces the client (0076-DANO-038) ### General Acceptance -1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015)(0076-SP-DANO-015) -1. The validator node will only accept requests for event bus subscriptions. All other API subscription requests will be invalid. (0076-DANO-016)(0076-SP-DANO-016) -1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017)(0076-SP-DANO-017) -1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019)(0076-SP-DANO-019) -1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021)(0076-SP-DANO-021) +1. The DataNode must be able to handle brief network outages and disconnects from the vega node (0076-DANO-015) +1. The validator node will only accept requests for event bus subscriptions. All other API subscription requests will be invalid. (0076-DANO-016) +1. The event bus stream is available from validators, non validators and the DataNode (0076-DANO-017) +1. If a DataNode loses connection to a Vega node if will attempt to reconnect and if the cached data received from the Vega node is enough to continue working it can resume being a DataNode. (0076-DANO-019) +1. The DataNode must provide its current block height and vega time on responses to client requests so the client can determine whether or not the data is stale. (0076-DANO-021) + diff --git a/protocol/0077-SNAP-snapshots.md b/protocol/0077-SNAP-snapshots.md index 6f9620782..bb6034e3a 100644 --- a/protocol/0077-SNAP-snapshots.md +++ b/protocol/0077-SNAP-snapshots.md @@ -57,9 +57,10 @@ A bad node can swamp the network by requesting snapshots from other nodes which ## Acceptance Criteria -- A node can be started up so that it generates snapshots at given block intervals (0077-SNAP-001)(0077-SP-SNAP-001) -- A node will generate snapshots files on the local filesystem (most likely using GOLevelDB) (0077-SNAP-002)(0077-SSP-NAP-002) -- A node will have a maximum amount of snapshots file on the filesystem. Older ones will be to be removed before a new one can be created. How many snapshots we keep may be something that can be configured. (0077-SNAP-003)(0077-SP-SNAP-003) -- The state of a node that is started from a snapshot should be identical to a node that had reached the same block height via replay. (0077-SNAP-004)(0077-SP-SNAP-004) -- Post a checkpoint restore we see snapshots continuing to be produced as before and can be used to add a node to the network (0077-SNAP-005)(0077-SP-SNAP-005) -- With `snapshot.interval.length` set to `k` all the nodes in a network will create a snapshot at block height `k`, `2k`, `3k`, ... (0077-SNAP-006)(0077-SP-SNAP-006) +- A node can be started up so that it generates snapshots at given block intervals (0077-SNAP-001) +- A node will generate snapshots files on the local filesystem (most likely using GOLevelDB) (0077-SNAP-002) +- A node will have a maximum amount of snapshots file on the filesystem. Older ones will be to be removed before a new one can be created. How many snapshots we keep may be something that can be configured. (0077-SNAP-003) +- The state of a node that is started from a snapshot should be identical to a node that had reached the same block height via replay. (0077-SNAP-004) +- Post a checkpoint restore we see snapshots continuing to be produced as before and can be used to add a node to the network (0077-SNAP-005) +- With `snapshot.interval.length` set to `k` all the nodes in a network will create a snapshot at block height `k`, `2k`, `3k`, ... (0077-SNAP-006) + From 9cf5812b56f0f8be0c90982cd20e20729baabb96 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 19:30:03 +0200 Subject: [PATCH 261/649] feat: update 0057 --- protocol/0057-TRAN-transfers.md | 45 ++++++++++++++++----------------- 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 2a099f142..ec2d5f603 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -187,36 +187,36 @@ message CancelTransfer { ### One off transfer tests -- As a user I can transfer funds from a general account I control to an other party's general account. Such transfer can be immediate or delayed. (0057-TRAN-001)(0057-vTRAN-001) -- As a user I **cannot** transfer funds from a general account I control to reward account with a one-off transfer. (0057-TRAN-002)(0057-SP-TRAN-002) -- As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-003)(0057-SP-COSMICELEVATOR-TRAN-003). -- As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-004)(0057-SP-COSMICELEVATOR-TRAN-004) -- As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005)(0057-SP-TRAN-005) +- As a user I can transfer funds from a general account I control to an other party's general account. Such transfer can be immediate or delayed. (0057-TRAN-001) +- As a user I **cannot** transfer funds from a general account I control to reward account with a one-off transfer. (0057-TRAN-002) +- As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-003). +- As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-004) +- As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005) - As a user I cannot transfer funds from accounts I own but from the type is not supported: - for accounts created in a futures market, bond and margin (0057-TRAN-006) - for accounts created in a spot market, bond and holding (0057-SP-TRAN-006) -- As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007)(0057-SP-TRAN-007) +- As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007) - The fee cost is correctly calculated using the network parameter - If I have enough funds to pay transfer and fees, the transfer happens. - If I do not have enough funds to pay transfer and fees, the transfer is cancelled. - The fees are being paid into the infrastructure pool -- As a user, when I initiate a delayed transfer, the funds are taken from my account immediately (0057-TRAN-008)(0057-SP-TRAN-008) +- As a user, when I initiate a delayed transfer, the funds are taken from my account immediately (0057-TRAN-008) - The funds arrive in the target account when the transaction is processed (i.e. with the correct delay), which is not before the timestamp occurs - A delayed transfer that is invalid (to an invalid account type) is rejected when it is received, and the funds are not taken from the origin account. -- The spam protection mechanics prevent me to do more than `spam.protection.maxUserTransfersPerEpoch` transfers per epoch. (0057-TRAN-009)(0057-SP-TRAN-009) -- A delayed one-off transfer cannot be cancelled once set-up. (0057-TRAN-010)(0057-SP-TRAN-010) -- A one-off transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-059)(0057-SP-TRAN-059) +- The spam protection mechanics prevent me to do more than `spam.protection.maxUserTransfersPerEpoch` transfers per epoch. (0057-TRAN-009) +- A delayed one-off transfer cannot be cancelled once set-up. (0057-TRAN-010) +- A one-off transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-059) ### Recurring transfer tests -As a user I can create a recurring transfer _which expires after a specified epoch_ (0057-TRAN-050)(0057-SP-RAN-050) +As a user I can create a recurring transfer _which expires after a specified epoch_ (0057-TRAN-050) - I specify a start and end epoch, and a factor of `1`, start epoch in the future, until the start epoch is reached no transfers are executed. - Once I reach the start epoch, the first transfer happens. - The same amount is transferred every epoch. - In the epoch after the `end epoch`, no transfers are executed. -As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-051)(0057-SP-TRAN-051) +As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-051) - I specify a start and end epoch, and a factor of `0.7` - Until the start epoch is reached not transfers are executed @@ -225,7 +225,7 @@ As a user I can create a recurring transfer _that decreases over time_ (0057-TRAN-052)(0057-SP-TRAN-052) +As a user I can create a recurring transfer that recurs forever, with the same balance transferred each time (0057-TRAN-052) - I specify a start and no end epoch, and a factor of `1` - Until the start epoch is reached not transfers are executed @@ -233,7 +233,7 @@ As a user I can create a recurring transfer that recurs forever, with the same b - The amount transferred every epoch is the same - The transfers happen forever -As a user I can create a recurring transfer that recurs as long as the amount is `transfer.minTransferQuantumMultiple x quantum`, with the amount transfer decreasing. (0057-TRAN-053)(0057-SP-TRAN-053) +As a user I can create a recurring transfer that recurs as long as the amount is `transfer.minTransferQuantumMultiple x quantum`, with the amount transfer decreasing. (0057-TRAN-053) - I specify a start and no end epoch, and a factor of `0.1` - Until the start epoch is reached not transfers are executed @@ -242,20 +242,20 @@ As a user I can create a recurring transfer that recurs as long as the amount is - The transfers happen as long as the amount transferred is > `transfer.minTransferQuantumMultiple x quantum`. - After a sufficiently large number of epochs the transfers stops and the recurring transfer is deleted. -As a user I can cancel a recurring transfer (0057-TRAN-054)(0057-SP-TRAN-054) +As a user I can cancel a recurring transfer (0057-TRAN-054) - I specify a start and no end epoch, and a factor of 1 - Once I reach the start epoch transfers happens. - I cancel the recurring transfer after the start epoch, before the end epoch - No transfer are executed anymore -As a user I can cancel a recurring transfer before any transfers have executed (0057-TRAN-055)(0057-SP-TRAN-055) +As a user I can cancel a recurring transfer before any transfers have executed (0057-TRAN-055) - I specify a start and no end epoch, and a factor of 1 - I cancel the transfer after the start epoch, before the end epoch - No transfer are executed at all -A user's recurring transfer is cancelled if any transfer fails due to insufficient funds (0057-TRAN-056)(0057-SP-TRAN-056) +A user's recurring transfer is cancelled if any transfer fails due to insufficient funds (0057-TRAN-056) - I specify a start and no end epoch, and a factor of 1 - Until the epoch is reached not transfers are executed @@ -264,9 +264,9 @@ A user's recurring transfer is cancelled if any transfer fails due to insufficie - The transfer is cancelled - No more transfers are executed. -A recurring transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-058)(0057-SP-TRAN-058) +A recurring transfer `to` a non-`000000000...0`, and an account type that a party cannot have, must be rejected (0057-TRAN-058) -A user's recurring transfer to a reward account does not occur if there are no parties eligible for a reward in the current epoch (0057-TRAN-057)(0057-SP-TRAN-057) +A user's recurring transfer to a reward account does not occur if there are no parties eligible for a reward in the current epoch (0057-TRAN-057) - I set up a market `ETHUSDT` settling in USDT. - The value of `marketCreationQuantumMultiple` is `10^6` and `quantum` for `USDT` is `1`. @@ -276,10 +276,9 @@ A user's recurring transfer to a reward account does not occur if there are no p - At the end of the third epoch, no transfer occurs If the network parameter `transfer.fee.factor` is modified, this modification is applied -immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062)(0057-SP-TRAN-062) - -If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060)(0057-SP-TRAN-060) +immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-062) +If the network parameter `spam.protection.maxUserTransfersPerEpoch` is modified, this modification is applied immediately, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. In the case of a decrease, existing recurring transfers are not cancelled. (0057-TRAN-060) If the network parameter `transfer.minTransferQuantumMultiple` is modified, this modification is applied -immediately on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-061)(0057-SP-TRAN-061) +immediately on, i.e., transfers are accepted/rejected according to the new parameter. This holds for both increase and decrease. (0057-TRAN-061) From fa4e767b6e5a053790943519077fbca76d56d308 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 19:37:37 +0200 Subject: [PATCH 262/649] feat: remove spot --- ...0059-STKG-simple_staking_and_delegating.md | 40 +++++++++---------- protocol/0067-KEYS-key_management.md | 20 +++++----- ...071-STAK-erc20_governance_token_staking.md | 24 +++++------ protocol/0072-SPPW-spam-protection-PoW.md | 34 ++++++++-------- 4 files changed, 59 insertions(+), 59 deletions(-) diff --git a/protocol/0059-STKG-simple_staking_and_delegating.md b/protocol/0059-STKG-simple_staking_and_delegating.md index e7226a509..3cb481662 100644 --- a/protocol/0059-STKG-simple_staking_and_delegating.md +++ b/protocol/0059-STKG-simple_staking_and_delegating.md @@ -178,34 +178,34 @@ To lock tokens, a participant must: To delegate the locked tokens, a participant must: -- Have enough tokens to satisfy the network parameter: "Minimum delegateable stake" (0059-STKG-001)(0059-SP-STKG-001) -- Delegate the locked tokens to one of the eligible validators (fixed set for Alpha mainnet).(0059-STKG-002)(0059-SP-STKG-002) +- Have enough tokens to satisfy the network parameter: "Minimum delegateable stake" (0059-STKG-001) +- Delegate the locked tokens to one of the eligible validators (fixed set for Alpha mainnet).(0059-STKG-002) These accounts will be created: -- A [staking account](./0013-ACCT-accounts.md#staking-accounts) denominated in the governance asset is created(0059-STKG-003)(0059-SP-STKG-003) -- When first fees are received as a staking reward, a general account for each settlement currency (so they can receive infrastructure fee rewards) (0059-STKG-004)(0059-SP-STKG-004) +- A [staking account](./0013-ACCT-accounts.md#staking-accounts) denominated in the governance asset is created(0059-STKG-003) +- When first fees are received as a staking reward, a general account for each settlement currency (so they can receive infrastructure fee rewards) (0059-STKG-004) - It is possible that a separate reward function will cause an account to be created for the user as a result of rewards. - Timings -- Any locked (but undelegated) tokens can be delegated at any time. (0059-STKG-005)(0059-SP-STKG-005) -- The delegation only becomes valid at the next [epoch](./0050-EPOC-epochs.md), though it can be undone through undelegate. (0059-STKG-006)(0059-SP-STKG-006) -- The balance of "delegateable stake" is reduced immediately (prior to it coming into effect in the next epoch) (0059-STKG-007)(0059-SP-STKG-007) +- Any locked (but undelegated) tokens can be delegated at any time. (0059-STKG-005) +- The delegation only becomes valid at the next [epoch](./0050-EPOC-epochs.md), though it can be undone through undelegate. (0059-STKG-006) +- The balance of "delegateable stake" is reduced immediately (prior to it coming into effect in the next epoch) (0059-STKG-007) ### Adding more stake -- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) (0059-STKG-008)(0059-SP-STKG-008) -- More stake may be delegated at any time (see [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - amount refers to size by which to increment existing staked amount) (0059-STKG-009)(0059-SP-STKG-009) -- Same timings apply as per staking for the first time (0059-STKG-010)(0059-SP-STKG-010) +- More tokens may be locked at any time on the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) (0059-STKG-008) +- More stake may be delegated at any time (see [function: Stake](./0071-STAK-erc20_governance_token_staking.md) - amount refers to size by which to increment existing staked amount) (0059-STKG-009) +- Same timings apply as per staking for the first time (0059-STKG-010) ### Removing stake -- Any stake may be withdrawn from the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) at any time (0059-STKG-011)(0059-SP-STKG-011) - - Unlocking your tokens in the bridge contract will effectively "remove" them from any delegation they're doing (unless you have remaining undelegated tokens that could fulfil your delegation) (0059-STKG-012)(0059-SP-STKG-012) -- Delegation may be fully or partially removed. The amount specified in the [function: Remove](./0071-STAK-erc20_governance_token_staking.md) - is the size by which the existing staked amount will be decremented (0059-STKG-013)(0059-SP-STKG-013) +- Any stake may be withdrawn from the [Vega staking bridge contract](./0071-STAK-erc20_governance_token_staking.md) at any time (0059-STKG-011) + - Unlocking your tokens in the bridge contract will effectively "remove" them from any delegation they're doing (unless you have remaining undelegated tokens that could fulfil your delegation) (0059-STKG-012) +- Delegation may be fully or partially removed. The amount specified in the [function: Remove](./0071-STAK-erc20_governance_token_staking.md) - is the size by which the existing staked amount will be decremented (0059-STKG-013) - Removal of delegation may happen in the following 2 ways: - - Announcing removal, but maintaining stake until last block of the current epoch. This "announced stake" may be then (re)delegated (e.g. to a different validator). (0059-STKG-014)(0059-SP-STKG-014) - - Announcing removal and withdrawing stake immediately. Rewards are still collected for this stake until the end of the epoch, but they are sent to the on-chain treasury account for that asset. (0059-STKG-015)(0059-SP-STKG-015) -- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that for the current epoch nomination balance we consider the minimum stake that the party had for the duration of the period evaluated (from the beginning of the epoch). Also, for next epoch's nomination balance we consider the current balance of the association. Have one party stake 100 tokens split 70-30 between two validators. With a an epoch of length 5 minutes, at the beginning of the epoch remove 50 tokens off the stake. Within 30 seconds of the confirmation of updated association, verify that the nomination balances for the current epoch and next has been removed with respect to the 70/30 split, such that it is now 35/15. (0059-SP-STKG-016)(0059-STKG-016) + - Announcing removal, but maintaining stake until last block of the current epoch. This "announced stake" may be then (re)delegated (e.g. to a different validator). (0059-STKG-014) + - Announcing removal and withdrawing stake immediately. Rewards are still collected for this stake until the end of the epoch, but they are sent to the on-chain treasury account for that asset. (0059-STKG-015) +- Every 30 seconds (and at the end of an epoch) the associated stake is reconciled against the current nomination to ensure that the total nomination is not exceeding the total association. In case it does we proportionally un-nominate from the validators until the nomination is not exceeding the association. It's worth mentioning that for the current epoch nomination balance we consider the minimum stake that the party had for the duration of the period evaluated (from the beginning of the epoch). Also, for next epoch's nomination balance we consider the current balance of the association. Have one party stake 100 tokens split 70-30 between two validators. With a an epoch of length 5 minutes, at the beginning of the epoch remove 50 tokens off the stake. Within 30 seconds of the confirmation of updated association, verify that the nomination balances for the current epoch and next has been removed with respect to the 70/30 split, such that it is now 35/15. (0059-STKG-016) ### Changing delegation @@ -216,21 +216,21 @@ These accounts will be created: ## Auto delegation scenarios -### Normal scenario auto undelegation: (0059-STKG-018)(0059-SP-STKG-018) +### Normal scenario auto undelegation: (0059-STKG-018) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 - epoch 1: party dissociated 200 VEGA - at the end of epoch 1: `party1` would have left 160 tokens nominated to validators 1-5 (for both epoch 1 and onwards - the former is important so that they don't get rewarded for 200 per validator) -### Normal scenario auto delegation: (0059-STKG-019)(0059-SP-STKG-019) +### Normal scenario auto delegation: (0059-STKG-019) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 - epoch 1: party associated 200 VEGA - end of epoch 1: there's sufficient space on each validator 1-5 to accept the delegation of 40 VEGA from `party1` and `party1` now has delegation of 240 for validators 1-5 for epoch 2. -### Edge case 1: manual delegation for party eligible for auto delegation: (0059-STKG-020)(0059-SP-STKG-020) +### Edge case 1: manual delegation for party eligible for auto delegation: (0059-STKG-020) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 @@ -239,7 +239,7 @@ These accounts will be created: - end of epoch1: party1 has 300 delegated to validator1, 200 delegated to validators 2-5 and 100 remain undelegated. - end of epoch2: the remaining associated undelegated 100 VEGA get auto-delegated and distributed such that `validator1` gets 27 (100 * 300/1100) and validators 2-5 get each 18 - and 1 token remains undelegated -### Edge case 2: manual undelegation for party eligible for auto delegation: (0059-STKG-021)(0059-SP-STKG-021) +### Edge case 2: manual undelegation for party eligible for auto delegation: (0059-STKG-021) - epoch 0: party associated 1000 VEGA - epoch 0: party nominated 200 VEGA to validators 1-5 diff --git a/protocol/0067-KEYS-key_management.md b/protocol/0067-KEYS-key_management.md index dcab61f14..25c520c06 100644 --- a/protocol/0067-KEYS-key_management.md +++ b/protocol/0067-KEYS-key_management.md @@ -225,15 +225,15 @@ need to be hashed individually). ### Generic -1. After both a Vega and Ethereum key rotation, rewards are still produced (0067-KEYS-006)(0067-SP-KEYS-006) -2. After both a Vega and Ethereum key rotation the node still has the ability to self stake/delegate and delegate to other validator nodes (0067-KEYS-007)(0067-SP-KEYS-007) -3. After both a Vega and Ethereum key rotation the node still can generate snapshots and checkpoints and these can successfully be used for node restarts and network restoring respectively (0067-KEYS-008)(0067-SP-KEYS-008) -4. After both a Vega and Ethereum key rotation ensure there is no impact on node validator scores; meaning that if - the validator has been proposing blocks as expected and thus has a score close to `1` then after key rotation there is no sudden change in score. (0067-KEYS-009)(0067-SP-KEYS-009) - - If the validator has not been proposing blocks as expected and their score is close to `0` then after the rotation there is no sudden jump in score towards `1`. (0067-KEYS-010)(0067-SP-KEYS-010) +1. After both a Vega and Ethereum key rotation, rewards are still produced (0067-KEYS-006) +2. After both a Vega and Ethereum key rotation the node still has the ability to self stake/delegate and delegate to other validator nodes (0067-KEYS-007) +3. After both a Vega and Ethereum key rotation the node still can generate snapshots and checkpoints and these can successfully be used for node restarts and network restoring respectively (0067-KEYS-008) +4. After both a Vega and Ethereum key rotation ensure there is no impact on node validator scores; meaning that if - the validator has been proposing blocks as expected and thus has a score close to `1` then after key rotation there is no sudden change in score. (0067-KEYS-009) + - If the validator has not been proposing blocks as expected and their score is close to `0` then after the rotation there is no sudden jump in score towards `1`. (0067-KEYS-010) ### Ethereum key -1. multisig interaction (0067-KEYS-001)(0067-SP-KEYS-001): +1. multisig interaction (0067-KEYS-001): - A Vega network is running with 3 validators, `v1,v2,v3` with Ethereum keys `k1, k2, k3_old`; each with equal tendermint and multisig weight. - Validator `v3` has Ethereum multisig public key `k3_old`. They submit a transaction to replace by Ethereum multisig public key `k3_new`. - The network issues a signature bundle to update that can be submitted to the Ethereum multisig contract to update the key there. @@ -241,23 +241,23 @@ need to be hashed individually). - Vega nodes receive the event confirming the key has been updated. - Party `p` now issues a withdrawal transaction. A withdrawal bundle is created utilising `k1,k2,k3_new`. - Party `p` submits the withdrawal bundle to Ethereum; multisig contract accepts it and transfers the funds on the Ethereum chain. -1. Non-tendermint validators rotating keys does not generate signatures (0067-KEYS-003)(0067-SP-KEYS-003): +1. Non-tendermint validators rotating keys does not generate signatures (0067-KEYS-003): - A Vega network is running such there is at least 1 ersatz - Submit a transaction to rotate their Ethereum keys. - Verify that once `target_block` is reached, the data-node reports that the rotation occurred. - Verify that no signatures bundles are emitted from core to add/remove either the new key or the old key. - Repeat the above steps for a pending validator -1. Subsequent rotations cannot be submitted until the previous rotation is resolved on the contract (0067-KEYS-004)(0067-SP-KEYS-004): +1. Subsequent rotations cannot be submitted until the previous rotation is resolved on the contract (0067-KEYS-004): - Start a Vega network and pick a tendermint validator. - Submit a transaction to rotate their Ethereum key. - Verify that signatures bundles are emitted from core, but do not submit them to the multisig contract. - Submit another transactions to their rotate Ethereum keys. - Verify that the transaction fails. This is to prevent multiple valid add-signer bundles for the same validator. -1. Transaction with no proof of ownership of the new Ethereum key fails (0067-KEYS-005)(0067-SP-KEYS-005): +1. Transaction with no proof of ownership of the new Ethereum key fails (0067-KEYS-005): - Start a Vega network and pick a tendermint validator. - Submit a transaction to rotate their Ethereum keys which contains an invalid Ethereum signature. - Verify that the transaction fails. -1. Vega hot key (0067-KEYS-002)(0067-SP-KEYS-002): +1. Vega hot key (0067-KEYS-002): - There is a vega validator `v3` with master key `M` and hot key `h3_old`. See [master and hot vega keys](0063-VALK-validator_vega_master_keys.md). - A Vega network is running with 3 validators, `v1,v2,v3` using Vega hot keys `h1,h2,h3_old`. - Validator `v3` generates a new hot key `h3_new` using the master key `M`. diff --git a/protocol/0071-STAK-erc20_governance_token_staking.md b/protocol/0071-STAK-erc20_governance_token_staking.md index 394b3ad56..836b8caa6 100644 --- a/protocol/0071-STAK-erc20_governance_token_staking.md +++ b/protocol/0071-STAK-erc20_governance_token_staking.md @@ -96,21 +96,21 @@ Other functionality: ### Staking Bridge Smart Contract -- Staking Bridge accepts and locks deposited VEGA tokens and emits `Stake_Deposited` event (0071-STAK-001)(0071-SP-STAK-001) -- Staking Bridge allows only stakers to remove their staked tokens and emits `Stake_Removed` event (0071-STAK-002)(0071-SP-STAK-002) -- Staking Bridge allows users with staked balance to transfer ownership of stake to new ethereum address that only the new address can remove (0071-STAK-003)(0071-SP-STAK-003) -- Staking Bridge prohibits users from removing stake they don't own (0071-STAK-012)(0071-SP-STAK-012) -- Staking Bridge prohibits users from removing stake they have transferred to other ETH address (0071-STAK-013)(0071-SP-STAK-013) +- Staking Bridge accepts and locks deposited VEGA tokens and emits `Stake_Deposited` event (0071-STAK-001) +- Staking Bridge allows only stakers to remove their staked tokens and emits `Stake_Removed` event (0071-STAK-002) +- Staking Bridge allows users with staked balance to transfer ownership of stake to new ethereum address that only the new address can remove (0071-STAK-003) +- Staking Bridge prohibits users from removing stake they don't own (0071-STAK-012) +- Staking Bridge prohibits users from removing stake they have transferred to other ETH address (0071-STAK-013) ### Vesting Smart Contract -- Vesting Contract locks vesting VEGA tokens and emits `Stake_Deposited` event (0071-STAK-005)(0071-SP-STAK-005) -- Vesting Contract unlocks vesting VEGA tokens and emits `Stake_Removed` event (0071-STAK-006)(0071-SP-STAK-006) -- Vesting Contract prohibits withdrawal of VEGA while that VEGA is staked (0071-STAK-007)(0071-SP-STAK-007) +- Vesting Contract locks vesting VEGA tokens and emits `Stake_Deposited` event (0071-STAK-005) +- Vesting Contract unlocks vesting VEGA tokens and emits `Stake_Removed` event (0071-STAK-006) +- Vesting Contract prohibits withdrawal of VEGA while that VEGA is staked (0071-STAK-007) ### Event Queue -- Event Queue sees `Stake_Deposited` event from Staking Bridge smart contract and credits target Vega user with stake (0071-STAK-008)(0071-SP-STAK-008) -- Event Queue sees `Stake_Removed` event from Staking Bridge smart contract and removes stake from appropriate Vega user (0071-STAK-009)(0071-SP-STAK-009) -- Event Queue sees `Stake_Deposited` event from Vesting smart contract and credits target Vega user with stake (0071-STAK-010)(0071-SP-STAK-010) -- Event Queue sees `Stake_Removed` event from Vesting smart contract and removes stake from appropriate Vega user (0071-STAK-011)(0071-SP-STAK-011) +- Event Queue sees `Stake_Deposited` event from Staking Bridge smart contract and credits target Vega user with stake (0071-STAK-008) +- Event Queue sees `Stake_Removed` event from Staking Bridge smart contract and removes stake from appropriate Vega user (0071-STAK-009) +- Event Queue sees `Stake_Deposited` event from Vesting smart contract and credits target Vega user with stake (0071-STAK-010) +- Event Queue sees `Stake_Removed` event from Vesting smart contract and removes stake from appropriate Vega user (0071-STAK-011) diff --git a/protocol/0072-SPPW-spam-protection-PoW.md b/protocol/0072-SPPW-spam-protection-PoW.md index eca8914e4..b1400b561 100644 --- a/protocol/0072-SPPW-spam-protection-PoW.md +++ b/protocol/0072-SPPW-spam-protection-PoW.md @@ -87,44 +87,44 @@ All Vega clients that submitted transactions can verify that their transaction h ## Acceptance Criteria -- A message with a missing/wrong PoW is rejected (0072-SPPW-001)(0072-SP-SPPW-001) -- Reusing the same PoW for several messages is detected and the messages are rejected (0072-SPPW-002)(0072-SP-SPPW-002) -- Linking too many transactions to the same block is detected and leads to a blocking of that account (if the increasing difficulty is turned off) (0072-SPPW-003)(0072-SP-SPPW-003) +- A message with a missing/wrong PoW is rejected (0072-SPPW-001) +- Reusing the same PoW for several messages is detected and the messages are rejected (0072-SPPW-002) +- Linking too many transactions to the same block is detected and leads to a blocking of that account (if the increasing difficulty is turned off) (0072-SPPW-003) - Linking too many transactions with a low difficulty level to a block is detected and leads to blocking of the account (if increasing difficulty is turned on) (0072-SPPW-004)(0072-SPPW-004) - Reusing a transaction identifier in a way that several transactions with the same ID end up in the same block is detected and the transactions are rejected (0072-SPPW-005)(0072-SPPW-005) -- A blocked account is unblocked after the maximum of 1/48 of an Epoch or 30 seconds. For transactions sent in the meantime, a meaningful error message is returned. (0072-SPPW-006)(0072-SPPW-006) -- PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-COSMICELEVATOR-007)(0072-SP-COSMICELEVATOR-007) -- For each transaction less than or equal to `spam.pow.numberOfTxPerBlock` in a block `spam.pow.difficulty` zeros are needed in the proof-of-work (0072-SPPW-008)(0072-SP-SPPW-008) -- For each `spam.pow.numberOfTxPerBlock` sized block of transactions greater than `spam.pow.numberOfTxPerBlock` an additional 0 is required in the proof-of-work (1 additional zero for the first batch, two additional for the second batch etc) (0072-SPPW-009)(0072-SP-SPPW-009) -- For a given block, a user is able to submit more than `spam.pow.numberOfTxPerBlock` transactions with only `spam.pow.difficulty` zeros by tying them to one or more historic blocks all of which are within `spam.pow.numberOfPastBlocks` blocks (0072-SPPW-010)(0072-SP-SPPW-010) -- Using a block older than `spam.pow.numberOfPastBlocks` blocks prior to the current block is detected the transaction is rejected (0072-SPPW-011)(0072-SP-SPPW-011) +- A blocked account is unblocked after the maximum of 1/48 of an Epoch or 30 seconds. For transactions sent in the meantime, a meaningful error message is returned. (0072-SPPW-006) +- PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-COSMICELEVATOR-007) +- For each transaction less than or equal to `spam.pow.numberOfTxPerBlock` in a block `spam.pow.difficulty` zeros are needed in the proof-of-work (0072-SPPW-008) +- For each `spam.pow.numberOfTxPerBlock` sized block of transactions greater than `spam.pow.numberOfTxPerBlock` an additional 0 is required in the proof-of-work (1 additional zero for the first batch, two additional for the second batch etc) (0072-SPPW-009) +- For a given block, a user is able to submit more than `spam.pow.numberOfTxPerBlock` transactions with only `spam.pow.difficulty` zeros by tying them to one or more historic blocks all of which are within `spam.pow.numberOfPastBlocks` blocks (0072-SPPW-010) +- Using a block older than `spam.pow.numberOfPastBlocks` blocks prior to the current block is detected the transaction is rejected (0072-SPPW-011) - The parameter `spam.pow.difficulty` is increased. Verify that - Transactions tied to such a block using the original difficulty are rejected with an error message. - - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-008)(0072-SP-COSMICELEVATOR-008) + - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-008) - The parameter `spam.pow.difficulty` is decreased. Verify that - Transactions tied to such a block using the new difficulty are not rejected. - - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-009)(0072-SP-COSMICELEVATOR-009) + - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-009) - The parameter `spam.pow.increaseDifficulty` is changed from 0 to 1. Verify that - - Transactions tied to such a block using insufficient difficulty due to the new parameter are rejected with an error message. (0072-COSMICELEVATOR-010)(0072-SP-COSMICELEVATOR-010) + - Transactions tied to such a block using insufficient difficulty due to the new parameter are rejected with an error message. (0072-COSMICELEVATOR-010) - The parameter `spam.pow.increaseDifficulty` is changed from 1 to 0. Verify that - - Transactions tied to such a block using the base difficulty are not rejected. (0072-COSMICELEVATOR-011)(0072-SP-COSMICELEVATOR-011) + - Transactions tied to such a block using the base difficulty are not rejected. (0072-COSMICELEVATOR-011) - The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that - - The new parameter is used for all blocks with a block height higher than the current one, i.e., a number of transactions that was allowed before and is no longer due to the new parameter is rejected (leaving the spam difficulty level constant) (0072-COSMICELEVATOR-012)(0072-SP-COSMICELEVATOR-012) + - The new parameter is used for all blocks with a block height higher than the current one, i.e., a number of transactions that was allowed before and is no longer due to the new parameter is rejected (leaving the spam difficulty level constant) (0072-COSMICELEVATOR-012) - The parameter `spam.pow.numberofTxPerBlock` is increased. Verify that - - If a number of transactions is submitted with the lower lever PoW that would have exceeded the `spam.pow.numberOfTXPerBlock` before the change and not after, no transaction is rejected. (0072-COSMICELEVATOR-013)(0072-SP-COSMICELEVATOR-013) + - If a number of transactions is submitted with the lower lever PoW that would have exceeded the `spam.pow.numberOfTXPerBlock` before the change and not after, no transaction is rejected. (0072-COSMICELEVATOR-013) - Repeat tests 008-013, where in the same block, - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. - - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-COSMICELEVATOR-014)(0072-SP-COSMICELEVATOR-014) + - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-COSMICELEVATOR-014) -- *Mempool pruning* Cause congestion in the mempool by submitting many transactions (perhaps from several parties). Submit a transaction `T` tied to block number `N_old`. Make sure the transactions causing congestion create sufficiently large `N_current`. At some point we'll have `N_old + spam.pow.numberOfPastBlocks < N_current` and the transaction `T` is removed from the mempool and never scheduled. (0072-SPPW-012)(0072-SP-SPPW-012) +- *Mempool pruning* Cause congestion in the mempool by submitting many transactions (perhaps from several parties). Submit a transaction `T` tied to block number `N_old`. Make sure the transactions causing congestion create sufficiently large `N_current`. At some point we'll have `N_old + spam.pow.numberOfPastBlocks < N_current` and the transaction `T` is removed from the mempool and never scheduled. (0072-SPPW-012) From 719f76a156d970be67cd8229991ed154b98f4715 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 11 Jul 2023 19:49:49 +0200 Subject: [PATCH 263/649] feat: address comments --- protocol/0045-DSRC-data_sourcing.md | 50 +++++++++---------- protocol/0072-SPPW-spam-protection-PoW.md | 4 +- protocol/0073-LIMN-limited_network_life.md | 31 +++++++++--- .../0074-BTCH-batch-market-instructions.md | 2 +- 4 files changed, 52 insertions(+), 35 deletions(-) diff --git a/protocol/0045-DSRC-data_sourcing.md b/protocol/0045-DSRC-data_sourcing.md index a99407f9d..e8b0d01e2 100644 --- a/protocol/0045-DSRC-data_sourcing.md +++ b/protocol/0045-DSRC-data_sourcing.md @@ -225,28 +225,28 @@ ethereumCall: { Vega should reject any data source tx that is not explicitly required, so this would include a tx: -1. If a data source combines a primary source (like a signed message) with a filter (for instance saying we are only interested in messages where ticker = `GBPUSD` and timestamp = `20211231T23:59:00`) then the complete data source definition defines the source and can be used to accept/reject transactions, so for an active data source is active, transactions from the same provider (pubkey, Ethereum contract/event, URL, etc.) do not form part of the defined data source. If submitted, they should be rejected where possible and must not supply data to the target for the data source if the metadata or data content itself is not selected by the source definition (e.g. because ticker and timestamp do not match a filter). (0045-DSRC-001)(0045-SP-DSRC-001) -1. When no reference to a data source remains in any active part of the system (for instance a non-cancelled/settled market), data source no longer needs to be tracked and can be discarded. Any transactions that would previously have matched and been selected by that data source would be rejected/ignored. (0045-DSRC-002)(0045-SP-DSRC-002) -1. If the same complete data source (provider and filters, etc.) is referenced in multiple places (e.g. two separate active markets) then it will remain active if any subset of those references remain active. For example 2 markets reference the same data source (full definition must match exactly) and one of those markets is closed/cancelled/settled before the other, either because some other difference in their definition or because of governance action. (0045-DSRC-003)(0045-SP-DSRC-003) -1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and at least one of those sources filters out a transaction but at least one other selects it (all filters match), the transaction data must still be supplied for the sources that match and must not be supplied for the sources that don't match. (0045-DSRC-004)(0045-SP-DSRC-004) -1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and all of the sources select it (all filters match), the transaction data must be supplied for ALL of the sources that match. (0045-DSRC-005)(0045-SP-DSRC-005) -1. If a data source reference is changed (e.g. via governance vote), the old source must be dropped and data/transactions matching that source must not reach the target. (0045-DSRC-006)(0045-SP-DSRC-006) -1. If a data source reference is changed (e.g. via governance vote), the new source must become active and data/transactions matching that source must reach the target. (0045-DSRC-007)(0045-SP-DSRC-007) -1. Changes in data source references (e.g. via governance vote) must allow changing between any valid data source definitions, including to a data source of a different type of data source. (0045-DSRC-008)(0045-SP-DSRC-008) -1. Data is not applied retrospectively, i.e. if a previous historic data point or data transaction would have matched a newly created data source, it must not be identified and applied to the new data source (and therefore need not be stored by the core), only active data and new events created after the activation of the data source would be considered for the source. (0045-DSRC-009)(0045-SP-DSRC-009) -1. Two data sources with the same definition that are active at the same time must always select and receive exactly the same data, in the same order. (0045-DSRC-010)(0045-SP-DSRC-010) -1. Rejection of data sources either before submission/sequencing as transactions or when/if data is filtered/rejected after being sequenced on chain (if this happens - it should be avoided wherever possible to prevent spam attacks and reduce network load) must either result in an event queue message, return an error to the client, or enable the rejection (or not) to be confirmed by querying a core API (e.g. the filter, selector, or type check that failed). (0045-DSRC-011)(0045-SP-DSRC-011) -1. It's possible to query an API and see all active data sources. (0045-DSRC-012)(0045-SP-DSRC-012) -1. Party submitting an oracle transaction that gets rejected (e.g. because no data source is listening for transactions from such key) can receive an error message detailing reason for rejection. (0045-DSRC-013)(0045-SP-DSRC-013) -1. It's possible to listen to events and see all data that is supplied across all data sources or for any specific source. (0045-DSRC-014)(0045-SP-DSRC-014) -1. Data node carries historic data of at least all valid data that was supplied for each data source. (0045-DSRC-015)(0045-SP-DSRC-015) -1. Data sources can be composed/nested arbitrarily (as long as the definition is valid), for example selecting a field on filtered data that itself was sourced by selecting a field on a message sent by a signed data source (for example this might be processing a complex object in the source data). (0045-COSMICELEVATOR-016)(0045-SP-COSMICELEVATOR-016) -1. A market proposal specifies data source where value used for settlement is integer with implied decimals; the implied decimals are included in the oracle spec; once trading terminated and settlement data is submitted the price is interpreted correctly for settlement purposes. E.g. market decimals `1`, market uses asset for settlement with `10` decimals, oracle implied decimals `5`, submitted value `10156789` interpreted as `101.56789`. In asset decimals this is `1015678900000` and this is used for settlement. (0045-DSRC-017)(0045-SP-DSRC-017) -1. Data source transactions can be submitted by a party with zero balance in all assets. (0045-DSRC-018)(0045-SP-DSRC-018) -1. After trading termination has been triggered the trading terminated data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-019)(0045-SP-DSRC-019) -1. After settlement data has been received and the market has settled, the settlement data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-020)(0045-SP-DSRC-020) -1. Where the same oracle definition is used for trading terminated and settlement, and data has been received. Trading is terminated and the market is settled with the same data event (a single message does both). The data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed. (0045-DSRC-021)(0045-SP-DSRC-021) -1. It should be possible to update the market termination spec from external to internal and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-022)(0045-SP-DSRC-022) -1. It should be possible to update the market termination spec from internal to external and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-023)(0045-SP-DSRC-023) -1. It should not be possible to update the market settlement data spec to change the type from an external data source to an internal Vega timestamp data source. NB: this is because the internal Vega timestamp data source does not emit a value that can be used as a price, only a date/time. (0045-DSRC-024)(0045-SP-DSRC-024) -1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025)(0045-SP-DSRC-025) +1. If a data source combines a primary source (like a signed message) with a filter (for instance saying we are only interested in messages where ticker = `GBPUSD` and timestamp = `20211231T23:59:00`) then the complete data source definition defines the source and can be used to accept/reject transactions, so for an active data source is active, transactions from the same provider (pubkey, Ethereum contract/event, URL, etc.) do not form part of the defined data source. If submitted, they should be rejected where possible and must not supply data to the target for the data source if the metadata or data content itself is not selected by the source definition (e.g. because ticker and timestamp do not match a filter). (0045-DSRC-001) +1. When no reference to a data source remains in any active part of the system (for instance a non-cancelled/settled market), data source no longer needs to be tracked and can be discarded. Any transactions that would previously have matched and been selected by that data source would be rejected/ignored. (0045-DSRC-002) +1. If the same complete data source (provider and filters, etc.) is referenced in multiple places (e.g. two separate active markets) then it will remain active if any subset of those references remain active. For example 2 markets reference the same data source (full definition must match exactly) and one of those markets is closed/cancelled/settled before the other, either because some other difference in their definition or because of governance action. (0045-DSRC-003) +1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and at least one of those sources filters out a transaction but at least one other selects it (all filters match), the transaction data must still be supplied for the sources that match and must not be supplied for the sources that don't match. (0045-DSRC-004) +1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and all of the sources select it (all filters match), the transaction data must be supplied for ALL of the sources that match. (0045-DSRC-005) +1. If a data source reference is changed (e.g. via governance vote), the old source must be dropped and data/transactions matching that source must not reach the target. (0045-DSRC-006) +1. If a data source reference is changed (e.g. via governance vote), the new source must become active and data/transactions matching that source must reach the target. (0045-DSRC-007) +1. Changes in data source references (e.g. via governance vote) must allow changing between any valid data source definitions, including to a data source of a different type of data source. (0045-DSRC-008) +1. Data is not applied retrospectively, i.e. if a previous historic data point or data transaction would have matched a newly created data source, it must not be identified and applied to the new data source (and therefore need not be stored by the core), only active data and new events created after the activation of the data source would be considered for the source. (0045-DSRC-009) +1. Two data sources with the same definition that are active at the same time must always select and receive exactly the same data, in the same order. (0045-DSRC-010) +1. Rejection of data sources either before submission/sequencing as transactions or when/if data is filtered/rejected after being sequenced on chain (if this happens - it should be avoided wherever possible to prevent spam attacks and reduce network load) must either result in an event queue message, return an error to the client, or enable the rejection (or not) to be confirmed by querying a core API (e.g. the filter, selector, or type check that failed). (0045-DSRC-011) +1. It's possible to query an API and see all active data sources. (0045-DSRC-012) +1. Party submitting an oracle transaction that gets rejected (e.g. because no data source is listening for transactions from such key) can receive an error message detailing reason for rejection. (0045-DSRC-013) +1. It's possible to listen to events and see all data that is supplied across all data sources or for any specific source. (0045-DSRC-014) +1. Data node carries historic data of at least all valid data that was supplied for each data source. (0045-DSRC-015) +1. Data sources can be composed/nested arbitrarily (as long as the definition is valid), for example selecting a field on filtered data that itself was sourced by selecting a field on a message sent by a signed data source (for example this might be processing a complex object in the source data). (0045-COSMICELEVATOR-016) +1. A market proposal specifies data source where value used for settlement is integer with implied decimals; the implied decimals are included in the oracle spec; once trading terminated and settlement data is submitted the price is interpreted correctly for settlement purposes. E.g. market decimals `1`, market uses asset for settlement with `10` decimals, oracle implied decimals `5`, submitted value `10156789` interpreted as `101.56789`. In asset decimals this is `1015678900000` and this is used for settlement. (0045-DSRC-017) +1. Data source transactions can be submitted by a party with zero balance in all assets. (0045-DSRC-018) +1. After trading termination has been triggered the trading terminated data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-019) +1. After settlement data has been received and the market has settled, the settlement data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-020) +1. Where the same oracle definition is used for trading terminated and settlement, and data has been received. Trading is terminated and the market is settled with the same data event (a single message does both). The data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed. (0045-DSRC-021) +1. It should be possible to update the market termination spec from external to internal and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-022) +1. It should be possible to update the market termination spec from internal to external and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-023) +1. It should not be possible to update the market settlement data spec to change the type from an external data source to an internal Vega timestamp data source. NB: this is because the internal Vega timestamp data source does not emit a value that can be used as a price, only a date/time. (0045-DSRC-024) +1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025) \ No newline at end of file diff --git a/protocol/0072-SPPW-spam-protection-PoW.md b/protocol/0072-SPPW-spam-protection-PoW.md index b1400b561..001cb67d8 100644 --- a/protocol/0072-SPPW-spam-protection-PoW.md +++ b/protocol/0072-SPPW-spam-protection-PoW.md @@ -90,8 +90,8 @@ All Vega clients that submitted transactions can verify that their transaction h - A message with a missing/wrong PoW is rejected (0072-SPPW-001) - Reusing the same PoW for several messages is detected and the messages are rejected (0072-SPPW-002) - Linking too many transactions to the same block is detected and leads to a blocking of that account (if the increasing difficulty is turned off) (0072-SPPW-003) -- Linking too many transactions with a low difficulty level to a block is detected and leads to blocking of the account (if increasing difficulty is turned on) (0072-SPPW-004)(0072-SPPW-004) -- Reusing a transaction identifier in a way that several transactions with the same ID end up in the same block is detected and the transactions are rejected (0072-SPPW-005)(0072-SPPW-005) +- Linking too many transactions with a low difficulty level to a block is detected and leads to blocking of the account (if increasing difficulty is turned on) (0072-SPPW-004) +- Reusing a transaction identifier in a way that several transactions with the same ID end up in the same block is detected and the transactions are rejected (0072-SPPW-005) - A blocked account is unblocked after the maximum of 1/48 of an Epoch or 30 seconds. For transactions sent in the meantime, a meaningful error message is returned. (0072-SPPW-006) - PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-COSMICELEVATOR-007) - For each transaction less than or equal to `spam.pow.numberOfTxPerBlock` in a block `spam.pow.difficulty` zeros are needed in the proof-of-work (0072-SPPW-008) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 3e54a5327..1178e92aa 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -140,7 +140,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ### Test case 3: Governance proposals are maintained across resets, votes are not -#### Test case 3.1: Market is proposed, accepted, restored (0073-LIMN-009)(0073-SP-LIMN-009) +#### Test case 3.1: Market is proposed, accepted, restored (0073-LIMN-009) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -158,6 +158,24 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. The LP party has general account balance in USD of `9000` and bond account balance `1000` on the market `id_xxx`. 1. The other party has no open orders anywhere and general account balance in USD of `other_gen_bal + other_margin_bal`. +#### Test case 3.1: Spot market is proposed, accepted, restored (0073-SP-LIMN-009) + +1. There is an asset USD and no asset proposals. +1. There are no markets and no market proposals. +1. There is a party a party called `LP party` with general balance of 10 000 USD. +1. A market is proposed by a party called `LP party` and has enactment date 1 year in the future. The market has id `id_xxx`. +1. `LP party` commits a stake of 1000 USD to `id_xxx`. +1. Other parties vote on the market and the proposal is accepted (passes rules for vote majority and participation). The market has id `id_xxx`. +1. The market is in `pending` state, see [market lifecycle](../protocol/0043-MKTL-market_lifecycle.md). +1. Another party places a limit sell order on the market and has `other_gen_bal`, holding balance `other_hold_bal`. +1. Enough time passes so a checkpoint is created and no party submitted any withdrawal transactions throughout. +1. The network is shut down. +1. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. +1. There is an asset USD. +1. There is a market with `id_xxx` with all the same parameters as the accepted proposal had. +1. The LP party has general account balance in USD of `9000` and bond account balance `1000` on the market `id_xxx`. +1. The other party has no open orders anywhere and general account balance in USD of `other_gen_bal + other_hold_bal`. + #### Test case 3.2: Market is proposed, voting hasn't closed, not restored (0073-LIMN-010)(0073-SP-LIMN-010) 1. There is an asset USD and no asset proposals. @@ -242,8 +260,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 4. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. 5. That party has a USD general account balance of 150 USD -### Test case 5: Add or remove stake during checkpoint restart (0073-LIMN-017)(0073-SP-LIMN-017) - +### Test case 5: Add or remove stake during checkpoint restart (0073-LIMN-017) 1. There is a Vega token asset. 1. There are `5` validators on the network. 1. Each validator party `validator_party_1`,...,`validator_party_5` has `1000` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core. @@ -287,7 +304,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024) 1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025) 1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026)(0073-SP-LIMN-026) -1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027)(0073-SP-LIMN-027) +1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027) 1. Propose a valid ERC-20 asset. 1. Wait for the next checkpoint, then stop the network. @@ -329,7 +346,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031) 1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-SP-LIMN-031) 1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032)(0073-SP-LIMN-032) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033)(0073-SP-LIMN-033) +1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034)(0073-SP-LIMN-034) ### Test case 15: Market with trading terminated that settled is not restored, collateral moved correctly @@ -338,7 +355,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. 1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040)(0073-SP-LIMN-040) -1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041)(0073-SP-LIMN-041) +1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-SP-LIMN-042) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043) @@ -376,7 +393,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - risk model and parameters (0073-LIMN-070)(0073-SP-LIMN-070) - price monitoring bounds (0073-LIMN-071)(0073-SP-LIMN-071) - oracle settings (0073-LIMN-072)(0073-SP-LIMN-072) - - margin scaling factors (0073-LIMN-073)(0073-SP-LIMN-073) + - margin scaling factors (0073-LIMN-073) ### Test case 19: Deposit tokens during checkpoint restore diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 38b1cd135..4c9681173 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -58,5 +58,5 @@ After entering or exiting an auction mid-batch, the full batch must be processed - A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007)(0074-SP-BBTCH-007) - Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008)(0074-SP-BBTCH-008) - Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009)(0074-SP-BBTCH-009) -- If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010)(0074-SP-BBTCH-010) +- If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010) - Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011)(0074-SP-BBTCH-011) From e4b052174d74cba5dc1bf4096847e972a0d2c772 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 11 Jul 2023 13:00:21 +0200 Subject: [PATCH 264/649] refactor: consider separate timestamps --- ...3-PERP-product_builtin_perpetual_future.md | 107 +++++++++++++++--- 1 file changed, 90 insertions(+), 17 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 866c66f0f..9e9a7da2a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -13,7 +13,7 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. 1. `settlement_schedule (Data Source: datetime)`: this data is used to indicate when the next periodic settlement should be carried out. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. -1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding rate liability contributes to party's margin. +1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding payment liability contributes to party's margin. Validation: none required as these are validated by the asset and data source frameworks. @@ -31,11 +31,14 @@ The pseudocode below specifies a possible configuration of the built-in perpetua - every 168h from 20230203T12:00:00 settlement_data: data_source: SignedMessage{ pubkey=0xA45e...d6 } - field: 'price' filters: - 'timestamp': >= vegaprotocol.builtin.timestamp - 'timestamp': <= vegaprotocol.builtin.timestamp + "10s" - 'ticker': 'TSLA' + price: + field: 'price' + timestamp: + field: 'timestamp' ``` ## 2. Settlement assets @@ -53,33 +56,102 @@ cash_settled_perpetual_future.value(quote) { ## 4. Lifecycle triggers +No data relating to periodic settlement gets stored by the market prior to a successful uncrossing of the opening auction. Once the auction uncrosses an internal `funding_period_start` field gets populated with the current vega time (`vegaprotocol.builtin.timestamp`) + ### 4.1. Periodic settlement data point received -If the periodic settlement data received satisfies all the filters that have been specified for it then that data point (`y`) along with the current `mark_price` (`x`) for the market and the current `vegaprotocol.builtin.timestamp` (`t`) gets stored as the funding payment data point. +If the periodic settlement data received satisfies all the filters that have been specified for it then a data point containing price (`s`) along with timestamp (`t`) gets stored as the oracle data point within the market. Note that both the price and timestamp should come from the same oracle. The implementation has to allow specifying the following types of timestamps: + +- a field on the oracle payload, +- a timestamp from the oracle's blockchain, +- an internal vega time. ### 4.2. Mark to market settlement -Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of the last periodic settlement data point received along with the price used for MTM settlement and the current `vegaprotocol.builtin.timestamp` gets stored as the funding payment data point. If no periodic settlement data has been received yet then the funding payment data point should not be created. +Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is carried out the value of mark price (`f`) and the current `vegaprotocol.builtin.timestamp` gets stored as an internal data point within the market. ### 4.3. Periodic settlement -When the `settlement_schedule` event is received the latest funding payment data point gets repeated with the timestamp set to the current value of `vegaprotocol.builtin.timestamp`. +When the `settlement_schedule` event is received we need to calculated the funding payment. Store the current vega time as `funding_period_end`. + +If there are no oracle data points with a timestamp less than `funding_period_end` available then funding payment is skipped and `funding_period_start` gets overwritten with `funding_period_end`. + +If such points available then the calculations discussed in the following subsections get executed and funding payments get exchanged. + +#### TWAP spot price calculation + +Traverse all the available oracle data point tuples `(s,t)` and calculate the time-weighted average spot price (`s_twap`) as: + +```go +var previous_point +sum_product := 0 + +for p := range oracle_data_points { + if p.t <= funding_period_start { + previous_point = p + continue + } + if p.t >= funding_period_end { + break + } + if previous_point != nil { + sum_product += previous_point*(p.t-max(funding_period_start,previous_point.t)) + } + previous_point = p +} + +sum_product += previous_point.s*(funding_period_end-max(funding_period_start,previous_point.t)) +s_twap = sum_product / (funding_period_end - max(funding_period_start, oracle_data_points[0].t)) +``` -The next step is to calculate the periodic settlement funding payment. If there are no periodic settlement data points then the periodic settlement is skipped. Otherwise, consider all the periodic settlement data points and calculate the time-weighted average price difference as: +Only the oracle data point with largest timestamp that's less than or equal to `funding_period_end` (and any data points with larger timestamps) need to be kept from that point on. + +#### TWAP mark price calculation + +Traverse all the available internal data point tuples `(f,t)` and calculated the time-weighted average mark price (`f_twap`) as: ```go -sd := 0 -st := 0 -for i := 0; i < len(data_points) - 1; i++ { - t := data_points[i+1].t-data_points[i].t - d := data_points[i].x - data_points[i].y // recall that x stands for mark price and y for the external price source input - sd += d * t - st += t +var previous_point +sum_product := 0 + +for p := range internal_data_points { + if p.t <= funding_period_start { + previous_point = p + continue + } + if previous_point != nil { + sum_product += previous_point*(p.t-max(funding_period_start,previous_point.t)) + } + previous_point = p } -funding_payment = sd / st + +sum_product += previous_point.f*(funding_period_end-max(funding_period_start,previous_point.t)) +f_twap = sum_product / (funding_period_end - max(funding_period_start, internal_data_points[0].t)) ``` -All the funding payment data points except for the last one (it should get carried over as the first data point for the next period) can then be deleted. +Only the internal data point with largest timestamp needs to be kept from that point on. + +#### Funding payment calculation + +The next step is to calculate the periodic settlement funding payment + +```go +funding_payment = f_twap - s_twap +``` + +#### Funding rate calculation + +While not needed for calculation of cashflows to be exchanged by market participants, the funding rate is useful for tracking market's relation to the underlying spot market over time. + +Funding rate should be calculated as: + +```go +funding_rate = (f_twap - s_twap) / s_twap +``` + +and emitted as an event. + +#### Exchanging funding payments between parties Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding payment}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding payment is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). @@ -119,5 +191,6 @@ It should be possible to query the market for the list of current funding paymen 1. Receiving correctly formatted data from settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-PERP-007) 1. Receiving correctly formatted data from the settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-PERP-008) 1. Receiving correctly formatted data from the settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-PERP-009) -1. When the funding rate is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) -1. When the funding rate is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) +1. When the funding payment is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) +1. When the funding payment is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) +1. An event containing funding rate should be emitted each time the funding payment is calculated (0053-PERP-017) From 2f9294dc46decf4bbf6d9152b7ce2a73bbcb8fef Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 12 Jul 2023 09:50:51 +0100 Subject: [PATCH 265/649] fix: rename file and AC codes to unique number 0082 --- ...e.md => 0082-ETHD-ethereum-data-source.md} | 90 +++++++++---------- 1 file changed, 45 insertions(+), 45 deletions(-) rename protocol/{0081-ETHD-ethereum-data-source.md => 0082-ETHD-ethereum-data-source.md} (77%) diff --git a/protocol/0081-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md similarity index 77% rename from protocol/0081-ETHD-ethereum-data-source.md rename to protocol/0082-ETHD-ethereum-data-source.md index 3d31d3938..49287e2d0 100644 --- a/protocol/0081-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -110,84 +110,84 @@ Select { ### External Oracles - Creation -1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) (0081-ETHD-001) -2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment (0081-ETHD-002) -3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message (0081-ETHD-003) -4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) (0081-ETHD-004) +1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) (0082-ETHD-001) +2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment (0082-ETHD-002) +3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message (0082-ETHD-003) +4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) (0082-ETHD-004) ### External Oracles - Amendments -1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted (0081-ETHD-005) -2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted, the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-006) -3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0081-ETHD-007) +1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted (0082-ETHD-005) +2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted, the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0082-ETHD-006) +3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0082-ETHD-007) ### External Oracles - Deletions -1. Ability to delete a data source if and only if the data source is NOT used by any active markets (0081-ETHD-008) -2. Should NOT be able to delete a data source if its being actively used by a market (0081-ETHD-009) -3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source (0081-ETHD-010) +1. Ability to delete a data source if and only if the data source is NOT used by any active markets (0082-ETHD-008) +2. Should NOT be able to delete a data source if its being actively used by a market (0082-ETHD-009) +3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source (0082-ETHD-010) ### External Oracles - Validations -1. Validate if the smart contract address is valid (0081-ETHD-011) -2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 (0081-ETHD-012) -3. Validations for min / max frequency of listening for events / read a smart contract (0081-ETHD-013) -4. Create a new market with an inactive external oracle data source, system should throw an error (0081-ETHD-014) -5. Validations to be applied - need to be expanded (0081-ETHD-015) -6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event (0081-ETHD-016) +1. Validate if the smart contract address is valid (0082-ETHD-011) +2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 (0082-ETHD-012) +3. Validations for min / max frequency of listening for events / read a smart contract (0082-ETHD-013) +4. Create a new market with an inactive external oracle data source, system should throw an error (0082-ETHD-014) +5. Validations to be applied - need to be expanded (0082-ETHD-015) +6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event (0082-ETHD-016) ### New Network parameters -1. Test min / max values / validations for any new network parameters that are added (0081-ETHD-017) -2. Test the impact / behaviour of the system, after the changes to the new network parameters are enacted (0081-ETHD-018) +1. Test min / max values / validations for any new network parameters that are added (0082-ETHD-017) +2. Test the impact / behaviour of the system, after the changes to the new network parameters are enacted (0082-ETHD-018) ### Negative Tests -1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) (0081-ETHD-019) -2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value (0081-ETHD-020) -3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this (0081-ETHD-021) -4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0081-ETHD-022) -5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0081-ETHD-023) -6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting (0081-ETHD-024) +1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) (0082-ETHD-019) +2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value (0082-ETHD-020) +3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this (0082-ETHD-021) +4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-022) +5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-023) +6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting (0082-ETHD-024) ### API -1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0081-ETHD-025) -2. Ability to query historic data sent by an oracle data source (0081-ETHD-026) +1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0082-ETHD-025) +2. Ability to query historic data sent by an oracle data source (0082-ETHD-026) ### Non Functional -1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out (0081-ETHD-027) -2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0081-ETHD-028) -3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0081-ETHD-029) -4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0081-ETHD-030) -5. SPAM rules if any defined should be tested for (0081-ETHD-031) -6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly (0081-ETHD-032) -7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market (0081-ETHD-033) +1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out (0082-ETHD-027) +2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-ETHD-028) +3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-ETHD-029) +4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0082-ETHD-030) +5. SPAM rules if any defined should be tested for (0082-ETHD-031) +6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly (0082-ETHD-032) +7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market (0082-ETHD-033) ### Usage -1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles (0081-ETHD-034) -2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0081-ETHD-035) -3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market (0081-ETHD-036) -4. Data sourcing should be completely decoupled from data filtering (0081-ETHD-037) +1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles (0082-ETHD-034) +2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-035) +3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market (0082-ETHD-036) +4. Data sourcing should be completely decoupled from data filtering (0082-ETHD-037) ### Checkpoints -1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints (0081-ETHD-038) -2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0081-ETHD-039) +1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints (0082-ETHD-038) +2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0082-ETHD-039) ### Snapshots -1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots (0081-ETHD-040) -2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0081-ETHD-041) +1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots (0082-ETHD-040) +2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0082-ETHD-041) ### Protocol Upgrade -1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade (0081-ETHD-042) -2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade (0081-ETHD-043) -3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config (0081-ETHD-044) +1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade (0082-ETHD-042) +2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade (0082-ETHD-043) +3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config (0082-ETHD-044) ### Regression -1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one (0081-ETHD-045) +1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one (0082-ETHD-045) From 6248fc93b52a84d8e199285672efadd02d78821f Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 12 Jul 2023 11:01:30 +0100 Subject: [PATCH 266/649] fix: broken internal link (#1789) The numbering has changed breaking the inter-spec link - this fixes it Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 4dc5b3199..5ace558f9 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -396,7 +396,7 @@ If the market is already suspended via governance when another vote gets enacted ### 6.3. Resume the market -This proposal removes the restrictions put in place by a successful [market suspension proposal](#61-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. When the market leaves the auction any trades resulting from it should be generated at the auction uncrossing price as is done for any other auction type. +This proposal removes the restrictions put in place by a successful [market suspension proposal](#62-suspend-the-market). Note that this does not necessarily mean the market that's in auction mode should leave it immediately, as other auction triggers may still be active. If the market is not suspended when the vote to resume the market gets enacted then that vote has no effect. From 2fa49dcd3f1d90e03b269544cfdff25b51de2c19 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 3 Jul 2023 23:27:19 +0200 Subject: [PATCH 267/649] refactor: LP limit out, stop limit in --- .../0079-TGAP-transaction_gas_and_priority.md | 29 ++++++++++--------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index 19554a206..3a412504a 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -33,7 +33,7 @@ Variables needed: - `network.transactions.maxgasperblock` - `maxGas` - number of price levels on the order book taken, this can count just static volume or static plus dynamic(*) - `levels` - number of pegged orders - `pegs` -- number of LP shape levels on the market - `shapes` (this means that if LP A has 3 pegs on buy and 2 on sell and LP B has 1 buy peg and 4 sell pegs and they're the only LPs then this value is 10 ) +- number of stop orders on the market - `stops` - number of positions on the market - `positions` (*) update after implementation @@ -41,16 +41,16 @@ Variables needed: Constants needed: - `peg cost factor = 50` non-negative decimal -- `LP shape cost factor = 100` non-negative decimal -- `position factor = 1` non-negative integer -- `level factor = 0.1` non-negative integer +- `stop cost factor = 0.2` non-negative decimal +- `position factor = 1` non-negative decimal +- `level factor = 0.1` non-negative decimal - `batchFactor = 0.5` decimal between `0.1 and 0.9`. ### Any type of limit or market order ```go gasOrder = network.transaction.defaultgas + peg cost factor x pegs - + LP shape cost factor x shapes + + stop cost factor x stops + position factor x positions + level factor x levels gas = min((maxGas/minBlockCapacity)-1,gasOrder) @@ -60,7 +60,7 @@ gas = min((maxGas/minBlockCapacity)-1,gasOrder) ```go gasCancel = network.transaction.defaultgas + peg cost factor x pegs - + LP shape cost factor x shapes + + stop cost factor x stop orders + level factor x levels gas = min((maxGas/minBlockCapacity)-1,gasCancel) ``` @@ -87,7 +87,7 @@ gas = min((maxGas/minBlockCapacity)-1,batchGas) ```go gasOliq = network.transaction.defaultgas + peg cost factor x pegs - + LP shape cost factor x shapes + + stop cost factor x stop orders + position factor x positions + level factor x levels gas = min((maxGas/minBlockCapacity)-1,gasOliq) @@ -111,14 +111,17 @@ There are three priority categories: 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 20`. 1. Send `100` transactions with default gas cost to a node (e.g. votes on a proposal) and observe that most block have 5 of these transactions each. -### Test max with a market (0079-TGAP-002) +### Test max with a market (0079-TGAP-004) 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 1`. -1. Create a market with 1 LP using 2 shape offsets on each side, just best static bid / ask on the book and 2 parties with a position. -1. Another party submits a transaction to place a limit order. A block will be created containing the transaction (even though the gas cost of a limit order is `1 + 100 x 4 + 2 + 0.1 x 6` which is well over `100`.) +1. Create a market with 1 LP +1. Place 2 matching orders, 1 buy order below the matching price and 1 sell order above the matching price. Uncross the opening auction. +1. Place 3 pegged orders with different non-zero offsets. +1. Another party submits a transaction to place a limit order. A block will be created containing the transaction (even though the gas cost of a limit order is `1 + 50 x 3 + 2 x 1 + 0.1 x 5` which is well over `100`.) -### Test we don't overfill a block with a market (0079-TGAP-003) +### Test we don't overfill a block with a market (0079-TGAP-005) 1. Set `network.transactions.maxgasperblock = 500` and `network.transaction.defaultgas = 1`. -1. Create a market with 1 LP using 2 shape offsets on each side, just best static bid / ask on the book and 2 parties with a position. -1. Another party submits 10 transaction to place 10 limit order. A separate party submits `100` transactions with default gas cost. Block will be created but each only containing one limit order placement transaction and including some number of vote transactions. +1. Place 2 matching orders, 1 buy order below the matching price and 1 sell order above the matching price. Uncross the opening auction. +1. Place 3 pegged orders with different non-zero offsets. +1. Another party submits 10 transaction to place 10 limit order. A separate party submits `100` transactions with default gas cost. Blocks will be created but each only containing one limit order placement transaction and including some number of vote transactions. From da4be2676d9c3ec6aac9fc556877ecbe4ad66025 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 6 Jul 2023 16:21:53 +0200 Subject: [PATCH 268/649] refactor: rewording around stop orders --- protocol/0079-TGAP-transaction_gas_and_priority.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index 3a412504a..6e32aa2c4 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -60,7 +60,7 @@ gas = min((maxGas/minBlockCapacity)-1,gasOrder) ```go gasCancel = network.transaction.defaultgas + peg cost factor x pegs - + stop cost factor x stop orders + + stop cost factor x stops + level factor x levels gas = min((maxGas/minBlockCapacity)-1,gasCancel) ``` @@ -77,7 +77,7 @@ Here `gasBatch` is 1. plus the full cost of the first amendment at `gasOrder` 1. plus `batchFactor` sum of all subsequent amendments added together (each costing `gasOrder`) 1. plus the full cost of the first limit order at `gasOrder` -1. plus `batchFactor` sum of all subsequent limit orders added together (each costing `gasOrder`) +1. plus `batchFactor` sum of all subsequent submissions added together (each costing `gasOrder`) ```go gas = min((maxGas/minBlockCapacity)-1,batchGas) From e40724e5889329c7dbbe20454c8ef2b9430e9483 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 11 Jul 2023 00:00:43 +0200 Subject: [PATCH 269/649] refactor: further eradicate LP orders from specs --- protocol/0078-NWLI-network_wide_limits.md | 17 ----------------- .../0079-TGAP-transaction_gas_and_priority.md | 14 ++------------ 2 files changed, 2 insertions(+), 29 deletions(-) diff --git a/protocol/0078-NWLI-network_wide_limits.md b/protocol/0078-NWLI-network_wide_limits.md index 4dbdb0de6..d0b80f3aa 100644 --- a/protocol/0078-NWLI-network_wide_limits.md +++ b/protocol/0078-NWLI-network_wide_limits.md @@ -15,16 +15,6 @@ If it gets decreased below the current total number of pegged orders across all [Liquidity provision orders](./0038-OLIQ-liquidity_provision_order_type.md) do not get counted towards the limit. -## LP order shapes - -Each [LP order shape](./0038-OLIQ-liquidity_provision_order_type.md#how-they-are-submitted) has a limit of entries (offsets) driven by `market.liquidityProvision.shapes.maxSize`. -Default value: `5`. - -### Change of `market.liquidityProvision.shapes.maxSize` network parameter - -If the network parameter gets increased via a governance vote no further actions are needed. -If it gets decreased below the current total number of pegged orders across all active markets then no further actions are needed. Specifically: all existing LP orders remain unaffected, but any new LP orders need to respect it. - ## Acceptance Criteria ### Pegged order tests @@ -33,10 +23,3 @@ If it gets decreased below the current total number of pegged orders across all - Attempt to place a pegged order by a new party in a new market when the number of pegged orders on the book is equal to `limits.markets.maxPeggedOrders` results in a rejection. Error message attributes the rejection to the limit. (0078-NWLI-002) - Lowering `limits.markets.maxPeggedOrders` to the number number of pegged orders on the book minus 2 results in no changes to the order book composition. Once 2 of the orders get filled and 1 gets cancelled in one market it is possible to successfully submit one additional pegged order in any of the active markets. (0078-NWLI-003) - When the limit is reached [API](./0020-APIS-core_api.md#network-wide-limits) correctly indicates that. (0078-NWLI-004) - -### LP order shape tests - -- Submitting a [liquidity provision order](./0038-OLIQ-liquidity_provision_order_type.md) with 5 buy shapes and 5 sell shapes proceeds without any errors and liquidity provision becomes active. (0078-NWLI-005) -- Submitting a liquidity provision order with 6 buy shapes and 5 sell shapes results in a failure. Error message attributes the rejection to the limit. (0078-NWLI-006) -- Submitting a liquidity provision order with 5 buy shapes and 6 sell shapes results in a failure. Error message attributes the rejection to the limit. (0078-NWLI-007) -- Lowering the `market.liquidityProvision.shapes.maxSize` network parameter doesn't affect the existing orders, but a new LP order that exceeds it gets rejected. (0078-NWLI-008) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index 6e32aa2c4..96caf3450 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -46,7 +46,7 @@ Constants needed: - `level factor = 0.1` non-negative decimal - `batchFactor = 0.5` decimal between `0.1 and 0.9`. -### Any type of limit or market order +### Any type of limit or market order, or liquidity provision transaction ```go gasOrder = network.transaction.defaultgas + peg cost factor x pegs @@ -56,7 +56,7 @@ gasOrder = network.transaction.defaultgas + peg cost factor x pegs gas = min((maxGas/minBlockCapacity)-1,gasOrder) ``` -### Cancellation of any single order +### Cancellation of any single order or liquidity provision transaction ```go gasCancel = network.transaction.defaultgas + peg cost factor x pegs @@ -83,16 +83,6 @@ Here `gasBatch` is gas = min((maxGas/minBlockCapacity)-1,batchGas) ``` -### LP provision, new or amendment or cancellation - -```go -gasOliq = network.transaction.defaultgas + peg cost factor x pegs - + stop cost factor x stop orders - + position factor x positions - + level factor x levels -gas = min((maxGas/minBlockCapacity)-1,gasOliq) -``` - ## Transaction priorities Transactions with higher priorities that are present in the mempool will get placed into a block before transactions with lower priority are considered. From 5080b9dda37f65b4e4f244edfb74825c1dc279ea Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Wed, 12 Jul 2023 11:39:25 +0100 Subject: [PATCH 270/649] New successor acs (#1807) * test: Add more ACs to successor markets spec around data node APIs, proposals, network history and protocol upgrade. * fix: MD linting --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0081-SUCM-successor_markets.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index f0ad148b2..52601b57d 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -77,6 +77,8 @@ A new market proposal sets parent market Id to a market that has settled. The pa Successor markets cannot be enacted if the parent market is still in the "proposed" state. Successor market proposals can be submitted when the parent market is still in proposed state. When the voting period for the successor market ends then either: a) the parent market is already enacted in which case the successor market moves from "proposed" in to opening auction/"pending" state. Or the parent market is still in "proposed" state in which case successor market is rejected. (0081-SUCM-008) +Successor markets which are proposed whilst the parent is also still in a "proposed" state, will be rejected if the parent is rejected. (0081-SUCM-027) + Successor markets can be enacted when the parent market is in opening auction. There is no virtual stake to copy over, and no insurance pool balance to transfer. (0081-SUCM-009) A successor market proposal can be enacted when the parent market is in one of the following states: Suspended, Active, Trading terminated or Settled (settled within the successor time window) (0081-SUCM-010) @@ -89,17 +91,25 @@ Propose a successor market which specifies a parent which is settled, and for wh ### APIs -It is possible to fetch a market "parent / successor chain" containing the initial market and the full successor line (0081-SUCM-012) +It is possible to fetch a market "parent / successor chain" containing the initial market and the full successor line via: + +- GRPC (0081-SUCM-012) +- GraphQL (0081-SUCM-023) +- REST (0081-SUCM-024) When fetching a market that is part of a "parent / successor chain", we should see both the parent and each successor `marketID` (0081-SUCM-013) -### Snapshots / checkpoints +### Snapshots / checkpoints / Protocol Upgrade / Network History After a LNL checkpoint restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-016) After snapshot restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-017) +A market which has expired before a protocol upgrade is still eligible to be used as a successor market after the upgrade, if it is inside the successor time window (0081-SUCM-025) + +A data node restored from network history includes the full succession chain for a market. (0081-SUCM-026) + ### Virtual stake From 10312917cdb7ea482709950d829efca37791f961 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 12 Jul 2023 13:38:04 +0200 Subject: [PATCH 271/649] Fix/sla details on where penalties go (#1793) * fix: clarify that spot doesn't have insurance pool and where penalties go * fix: duplicated AC code * fix: remove duplicated AC dupe AC: In the case of spot markets it will be transferred into the network treasury for the asset * fix: more duplicate ACs * fix: AC code errors --------- Co-authored-by: gordsport --- protocol/0044-LIME-lp_mechanics.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 4a2c84f79..1d2af929a 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -89,7 +89,7 @@ Liquidity provider bond account: - A liquidity provider can only prompt a transfer of funds to or from this account by (re)submitting the LP commitment transaction: a valid transaction to create, increase, or decrease their commitment to the market. - Transfers to/from this account also occur when it is used for settlement or margin shortfall, when penalties are applied, and if the account is under-collateralised because of these uses and is subsequently topped up to the commitment amount during collateral search (see below) - Collateral withdrawn from this account may only be transferred to either: - - The insurance pool of the market (in event of penalties/slashing) + - The insurance pool of the market for markets trading on margin or the network treasury for the asset (for spot markets) (in event of penalties/slashing) - The liquidity provider's margin account or the network's settlement account/other participant's margin accounts (during a margin search and mark to market settlement) in the event that they have zero balance in their general account. - The liquidity provider's general account (in event of liquidity provider reducing their commitment) @@ -154,6 +154,7 @@ $$ Transfer $\text{maximum-penalty-free-reduction-amount}_i$ to their general account. Now transfer $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ to their general account and transfer $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ to the market insurance pool. +Note that in the case of spot market or any market that isn't running an insurance pool the transfer should go into the network treasury for the asset. Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire $\text{commitment-variation}_i$ as the `delta`. @@ -235,12 +236,14 @@ f = \max\left[0,\min\left(m, p \cdot (1 - \frac{t}{s})\right)\right]\,. $$ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. +For spot markets, the transfer is to go into the network treasury account for the asset. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). ### Penalty for not supporting open positions If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. +In the case of spot markets the transfer goes into the network treasury account for the asset. Calculating the penalty: @@ -293,8 +296,11 @@ Note: - If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.committmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) +and in the case of spot markets into the network treasury for the asset (0044-LIME-048) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) +and in the case of spot markets into the network treasury for the asset (0044-LIME-046) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) +and in the case of spot markets into the network treasury for the asset (0044-LIME-047) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. (0044-LIME-018) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) @@ -306,10 +312,17 @@ Note: - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) +In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-045) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) +- In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-044) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-025) -- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: + +In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-043) + + +- For a futures market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: + - `LP1` places a transaction to reduce their stake by `30` - `LP2` places a transaction to reduce their stake by `100`, - `LP1` places a transaction to update their reduction to `100` From 33c6cdfd12b821c7e0c3d86220d0f98c2cec1024 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 12 Jul 2023 13:40:34 +0200 Subject: [PATCH 272/649] feat: address comments --- protocol/0013-ACCT-accounts.md | 3 +-- protocol/0033-OCAN-cancel_orders.md | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 1dae7e1e1..763ba4e52 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -112,14 +112,13 @@ Note that it *is* possible to have markets in the governance asset, in which cas - Every party that submits an order on a market will have a margin account for that market created. (0013-ACCT-007) - Each party should only have one margin account per market. (0013-ACCT-008) -- In Spot market, each party should only have one margin account per market. (0013-SP-ACCT-008) - Cannot have a non-zero balance on a margin account where there's no position / position size = 0 and no active orders. (0013-ACCT-009) - Cannot transfer into or out of a margin account where there's no position / position size = 0 and no active orders. (0013-ACCT-010) ### Party holding accounts in Spot market - Every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) -- Each party should only have one holding account per market. (0013-SP-ACCT-008) +- Each party should only have two holding accounts per market: one for the the base_asset and one for the quote_asset. (0013-SP-ACCT-008) ### Liquidity Provider bond accounts diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index 434b42679..324e01aa9 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -7,8 +7,8 @@ - All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003)(0033-SP-OCAN-003) - Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004)(0033-SP-OCAN-004) - A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005)(0033-SP-OCAN-005) -- Margins must be recalculated after a cancel event (0033-OCAN-007)(0033-SP-OCAN-007) -- An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008)(0033-SP-OCAN-008) +- Margins must be recalculated after a cancel event (0033-OCAN-007) +- An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008) - Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009)(0033-SP-OCAN-009) - Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010)(0033-SP-OCAN-010) From 46826ef59bc636c8ef99593bbef323f1e684e8bc Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 12 Jul 2023 13:41:57 +0200 Subject: [PATCH 273/649] feat: resolve conflict --- protocol/0079-TGAP-transaction_gas_and_priority.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index a3b357310..4580dcd1e 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -122,3 +122,4 @@ There are three priority categories: 1. Set `network.transactions.maxgasperblock = 500` and `network.transaction.defaultgas = 1`. 1. Create a market with 1 LP using 2 shape offsets on each side, just best static bid / ask on the book and 2 parties with a position. 1. Another party submits 10 transaction to place 10 limit order. A separate party submits `100` transactions with default gas cost. Block will be created but each only containing one limit order placement transaction and including some number of vote transactions. + From a43163b1146e09be2bfc8d2bf816fc65ed74618d Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Wed, 12 Jul 2023 12:58:45 +0100 Subject: [PATCH 274/649] Small changes to various specs (#1808) * remove outdated info, replace 'rings' terminology * replace "governance transfer" term * replace sequence with lineage, in line with what's in the code --- protocol/0028-GOVE-governance.md | 2 +- protocol/0043-MKTL-market_lifecycle.md | 7 +++---- protocol/0055-TREA-on_chain_treasury.md | 9 ++++----- protocol/0073-LIMN-limited_network_life.md | 4 ++-- protocol/0081-SUCM-successor_markets.md | 4 ++-- 5 files changed, 12 insertions(+), 14 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 5ace558f9..684beb06f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -275,7 +275,7 @@ Enactment of an asset modification proposal is: The below table shows the allowable combinations of source and destination account types for a transfer that's initiated by a governance proposal. -| Source type | Destination type | Governance initiated transfer permitted | +| Source type | Destination type | Transfer permitted | | --- | --- | --- | | Party account (any type) | Any | No | | Network treasury | Network treasury | No | diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 4d8d8b278..85f867653 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -106,8 +106,7 @@ Auction period ends when any of the following occur: ### Cancelled -A market becomes Cancelled when a Market Proposal is successful and conditions are not met to transition the Market to the Active state during the Pending period, -and the trading terminated data source input rings, see [data sourcing](./0045-DSRC-data_sourcing.md). +A market becomes Cancelled when a Market Proposal is successful and conditions are not met to transition the Market to the Active state during the Pending period, and the trading terminated data source input is triggered, see [data sourcing](./0045-DSRC-data_sourcing.md). When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset. After `market.liquidity.successorLaunchWindowLength` has elapsed since cancellation any insurance pool balance should be transferred into the network treasury account for that asset. Once "cancelled" there must be no open positions tracked by the protocol for the market and any open positions must have been closed including returning all margin and other related collateral if necessary and also notifying downstream event consumers that the positions are closed. Specific position related actions may be unnecessary if the cancelled state is being entered from a state in which there cannot possibly have been any open positions. @@ -286,10 +285,10 @@ The market state is `settled`. After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. -### Market never leaves opening auction, trading terminated trigger rings, market cancelled (0043-MKTL-003) +### Market never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-003) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). -1. Trading terminated data source rings before the market leaves the opening auction (so market never left Pending state so far). +1. Trading terminated data source triggers before the market leaves the opening auction (so market never left Pending state so far). 1. All orders should be cancelled and collateral returned to respective parties general account for the relevant asset. 1. All LP commitments should be cancelled and their bond returned to the general account for the relevant asset. 1. After `market.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index 965dd83f5..911907d0c 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -7,7 +7,6 @@ The funds in the network treasury are spent by being transferred to another acco These transfers may be to a party general account, reward pool account, or insurance pool account for a market. There is no requirement or expectation of symmetry between funds flowing into the Network Treasury and funds flowing out. For example, the treasury account may be seeded by funds held by the team or investors, or through the issuance of tokens at various irregular points in time, and these funds may then be allocated to incentives/rewards, grants, etc. on a different schedule. -Note that governance initiated transfers are not in scope for Oregon trail and as such at the moment funds can only flow into network treasure but cannot flow out ;-). ## Funding @@ -20,9 +19,9 @@ The funds, if available would be transferred instantly and irrevocably to the ne - Transfer from protocol mechanics: there may be a protocol feature such as the charging of fees or handling of expired insurance pool balances that specifies the Network Treasury as destination in a transfer. (Charging of fees is placeholder, currently not to be implemented.) -- Transfer by governance: a [governance proposal](./0028-GOVE-governance.md) can be submitted to transfer funds from a market's insurance pool into the on chain treasury account for the asset. (not required for Oregon Trail as transfer by governance is not in scope) +- Transfer by governance: a [governance proposal](./0028-GOVE-governance.md) can be submitted to transfer funds from a market's insurance pool into the on chain treasury account for the asset. -- Transfer transaction: a transaction submitted to the network may request to transfer funds from the general account for an asset, controlled by the owner’s private key, to the Network Treasury. (see [transfers spec](????.md)) +- Transfer transaction: a transaction submitted to the network may request to transfer funds from the general account for an asset, controlled by the owner’s private key, to the Network Treasury. (see [transfers spec](./0057-TRAN-transfers.md)) ### Funding by deposit @@ -37,7 +36,7 @@ In future a fee factor (controlled by governance) may be added to allow the trea In future a tax rate and/or inflation rate (controlled by governance) may be used to allow funding the network treasury with governance tokens. This would either involve transferring a fraction of each staked user's tokens to the network treasury per epoch (it is implied that this fraction would be a significantly lower value than the other assets they receive in fees), or periodic issuance of new tokens into the treasury (this would not be possible before the inflation cut-off date in the token contract). -### Direct allocation by governance (not for Oregon trail) +### Direct allocation by governance A governance proposal may be submitted to transfer funds on enactment from the on-chain treasury to certain account types. Please see [the governance spec](./0028-GOVE-governance.md) for a description of this. @@ -59,7 +58,7 @@ A governance proposal may be submitted to transfer funds on enactment from the o - The Network Treasury accounts API returns the correct balance for the new account (0055-TREA-007) - The network treasury account balances [are restored after a network restart](./0073-LIMN-limited_network_life.md) (0055-TREA-010) -### Post Oregon Trail +### Cosmic Elevator - If a governance proposal for a single transfer from a network treasury account to some other account is enacted then - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-COSMICELEVATOR-050) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 7cf68d112..baa4f8ddf 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -342,10 +342,10 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Submit the trading terminated transaction and settlement date transaction as set out in the proposal and observe the final settlement cashflows for the parties with positions. (0073-LIMN-050) 1. It's not possible to submit orders or LP provisions to this market). (0073-LIMN-051) -### Test case 17: Markets with internal time trigger for trading terminated that rings between shutdown and restore +### Test case 17: Markets with internal time trigger for trading terminated that fires between shutdown and restore 1. Propose, enact a market with some trading terminated given by internal time trigger. Trade in the market creating positions for at least 2 parties. -1. System saves LNL checkpoint before the trading terminated trigger rings. +1. System saves LNL checkpoint before the trading terminated trigger is set off. 1. Restart Vega, load LNL checkpoint at a time which is after trading terminated trigger should have rung. 1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060); if it exists it in `cancelled` state. 1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 52601b57d..990dcc4c8 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -8,9 +8,9 @@ On every market liquidity is provided by various parties, liquidity providers (L As part of this process the LPs build-up virtual stake on the market, which may be higher than the stake they committed if the market grew. For [details of virtual stake calculation see how LPs are rewarded](./0042-LIQF-setting_fees_and_rewarding_lps.md). -Many derivative markets would terminate and settle periodically but would be part of a sequence. +Many derivative markets would terminate and settle periodically but would be part of a lineage. Think e.g. of a [cash-settled future](./0016-PFUT-product_builtin_future.md) written on the same underlying that settles every three months. -Successor markets are a feature that allows this sequencing but most importantly allows LPs to keep their virtual stake built up on one market (parent) in the sequence to be transferred to the next one (successor). +Successor markets are a feature that allows for markets to have a lineage, but most importantly allows LPs to keep their virtual stake built up on one market (parent) in the lineage to be transferred to the next one (successor). Moreover, part of the insurance pool of a parent market can be earmarked for transfer to the successor market instead of being distributed network wide (other markets in same settlement asset, network treasury). ## Relevant network / market parameters From f0920779de3fb71e5f732eb42cdd0a6a945ddbc2 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 12 Jul 2023 14:08:57 +0100 Subject: [PATCH 275/649] fix: linting and AC codes --- protocol/0020-APIS-core_api.md | 2 +- protocol/0022-AUTH-auth.md | 2 +- protocol/0045-DSRC-data_sourcing.md | 4 +- protocol/0047-DSRF-data_source_filter.md | 37 ++++---- protocol/0048-DSRI-data_source_internal.md | 45 +++++---- protocol/0056-REWA-rewards_overview.md | 102 +++++++++++++++------ protocol/0073-LIMN-limited_network_life.md | 56 ++++++----- 7 files changed, 151 insertions(+), 97 deletions(-) diff --git a/protocol/0020-APIS-core_api.md b/protocol/0020-APIS-core_api.md index 965d907c3..c29a57d09 100644 --- a/protocol/0020-APIS-core_api.md +++ b/protocol/0020-APIS-core_api.md @@ -63,7 +63,7 @@ On any Vega node, I can: | Requirement | Acceptance Criteria code | |-----------|:------------------------:| | List all governance proposals via REST & GRPC |0020-APIS-001| -| List all governance proposals by a specified party via REST & GRPC |0020-APIS-002 +| List all governance proposals by a specified party via REST & GRPC |0020-APIS-002 | Retrieve a specific governance proposals by id via REST & GRPC |0020-APIS-003 | | Retrieve a list of votes via REST & GRPC |0020-APIS-004| | Retrieve the governance stake for a specified party via REST & GRPC |0020-APIS-005| diff --git a/protocol/0022-AUTH-auth.md b/protocol/0022-AUTH-auth.md index 8fe30b25f..6e9228470 100644 --- a/protocol/0022-AUTH-auth.md +++ b/protocol/0022-AUTH-auth.md @@ -138,7 +138,7 @@ messge TransactionBundle { - A signature is verified before the transaction is sent to the chain. - If a signature is valid, the transaction is sent to the chain (0022-AUTH-010) - If a signature is invalid, the transaction is not sent to the chain, an error is returned (0022-AUTH-011) - - A transaction with an invalid signature is never sent to the chain and the transaction is discarded. (0022-AUTH-013) + - A transaction with an invalid signature is never sent to the chain and the transaction is discarded. (0022-AUTH-013) - A transaction with no signature is rejected (0022-AUTH-014) - A `partyId` that is not a valid public key is inherently invalid, and should be rejected (0022-AUTH-015) - _Note:_ In early versions of Vega, the `partyId` was an arbitrary string. This is no longer valid, and should be rejected. This includes the [network party](./0017-PART-party.md#network-party) - that is used where transactions are generated by the system, and it should never be possible to submit a transaction as `network`. diff --git a/protocol/0045-DSRC-data_sourcing.md b/protocol/0045-DSRC-data_sourcing.md index e8b0d01e2..b11ef91c4 100644 --- a/protocol/0045-DSRC-data_sourcing.md +++ b/protocol/0045-DSRC-data_sourcing.md @@ -229,7 +229,7 @@ Vega should reject any data source tx that is not explicitly required, so this w 1. When no reference to a data source remains in any active part of the system (for instance a non-cancelled/settled market), data source no longer needs to be tracked and can be discarded. Any transactions that would previously have matched and been selected by that data source would be rejected/ignored. (0045-DSRC-002) 1. If the same complete data source (provider and filters, etc.) is referenced in multiple places (e.g. two separate active markets) then it will remain active if any subset of those references remain active. For example 2 markets reference the same data source (full definition must match exactly) and one of those markets is closed/cancelled/settled before the other, either because some other difference in their definition or because of governance action. (0045-DSRC-003) 1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and at least one of those sources filters out a transaction but at least one other selects it (all filters match), the transaction data must still be supplied for the sources that match and must not be supplied for the sources that don't match. (0045-DSRC-004) -1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and all of the sources select it (all filters match), the transaction data must be supplied for ALL of the sources that match. (0045-DSRC-005) +1. If multiple data sources share common roots (e.g. the same provider - pubkey etc. but different filters) and all of the sources select it (all filters match), the transaction data must be supplied for ALL of the sources that match. (0045-DSRC-005) 1. If a data source reference is changed (e.g. via governance vote), the old source must be dropped and data/transactions matching that source must not reach the target. (0045-DSRC-006) 1. If a data source reference is changed (e.g. via governance vote), the new source must become active and data/transactions matching that source must reach the target. (0045-DSRC-007) 1. Changes in data source references (e.g. via governance vote) must allow changing between any valid data source definitions, including to a data source of a different type of data source. (0045-DSRC-008) @@ -249,4 +249,4 @@ Vega should reject any data source tx that is not explicitly required, so this w 1. It should be possible to update the market termination spec from external to internal and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-022) 1. It should be possible to update the market termination spec from internal to external and prove that the original termination key and filter no longer supports termination and that the updated market termination key and filter supports termination. This should apply to filter key types Timestamp/Boolean and Integer. (0045-DSRC-023) 1. It should not be possible to update the market settlement data spec to change the type from an external data source to an internal Vega timestamp data source. NB: this is because the internal Vega timestamp data source does not emit a value that can be used as a price, only a date/time. (0045-DSRC-024) -1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025) \ No newline at end of file +1. When using the update market transaction to switch between oracle types the protocol should identify invalid supplied combinations of data source data and reject the transaction via an appropriate message either within the rejected proposal or via the wallet response. (0045-DSRC-025) diff --git a/protocol/0047-DSRF-data_source_filter.md b/protocol/0047-DSRF-data_source_filter.md index affa0a25c..9c486dd02 100644 --- a/protocol/0047-DSRF-data_source_filter.md +++ b/protocol/0047-DSRF-data_source_filter.md @@ -86,33 +86,32 @@ To be clear, this also means that if the input data is the wrong "shape" or type ## Acceptance criteria 1. Filters can be used with any data source provider (internal, signed message, Ethereum etc.) - 1. Create a filter for each type of source provider and ensure that only data matching the filter gets through. (0047-DSRF-001) - 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002) + 1. Create a filter for each type of source provider and ensure that only data matching the filter gets through. (0047-DSRF-001) + 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002) 1. All filter conditions are applied - 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003) - 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004) - 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01" _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041). + 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003) + 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004) + 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01" _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041). 1. Data that is filtered out does not result in a data event but is recorded - 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005) - 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006) - 1. When data is filtered out and no event is emitted this is recorded either in logs or on the event bus (this may only happen on the receiving node if the event is a transaction that is rejected prior to being sequenced in a block). (0047-DSRF-007) + 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005) + 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006) + 1. When data is filtered out and no event is emitted this is recorded either in logs or on the event bus (this may only happen on the receiving node if the event is a transaction that is rejected prior to being sequenced in a block). (0047-DSRF-007) 1. Data sources are defined by the FULL definition including filters - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009) 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010) 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011) 1. Data types and condition types - 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012) - 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013) - 1. Date + time fields can be filtered by equality (datetime matches filter data exactly). (0047-DSRF-014) - 1. Number fields can be filtered by less than (number is less than filter data). (0047-DSRF-015) - 1. Date + time fields can be filtered by less than (datetime is less than filter data). (0047-DSRF-016) - 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017) - 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018) - 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019) + 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012) + 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013) + 1. Date + time fields can be filtered by equality (datetime matches filter data exactly). (0047-DSRF-014) + 1. Number fields can be filtered by less than (number is less than filter data). (0047-DSRF-015) + 1. Date + time fields can be filtered by less than (datetime is less than filter data). (0047-DSRF-016) + 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017) + 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018) + 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019) 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020) 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021) 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023) 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024) - diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 855f601e4..039e042d7 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -108,33 +108,32 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna ## Acceptance criteria 1. A simple value data source can be provided - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001) - 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001) + 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002) 1. A time triggered value data source can be provided - 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004) - 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007) - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008) + 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004) + 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008) 1. A Vega time changed value data source can be provided - 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the past. The market state changes to trading terminated immediately. (0048-DSRI-012) + 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the past. The market state changes to trading terminated immediately. (0048-DSRI-012) 1. Termination oracle updated after market is terminated (0048-DSRI-015) - - setup one market with a boolean termination - - terminate the market (but do not settle it) - - update the market to have a time based termination - - update the market to have an earlier time based termination - - wait until the first timer to tick - - send through valid settlement data - - assert the the market settles successfully + - setup one market with a boolean termination + - terminate the market (but do not settle it) + - update the market to have a time based termination + - update the market to have an earlier time based termination + - wait until the first timer to tick + - send through valid settlement data + - assert the the market settles successfully 1. Time based termination across multiple markets (0048-DSRI-014) - - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time - - wait to all of them to terminate successfully - - assert they all settle successfully + - setup 3 markets, all with time based termination with identical signer details, two with the same time, one with a later time + - wait to all of them to terminate successfully + - assert they all settle successfully 1. The repeating internal time triggered oracle can be used to model a time schedule of the form: every day at 12:00, 15:00 and 18:00. (0048-DSRI-018) 1. The repeating internal time triggered oracle can be used to model a time schedule of the form: 01/02/2023 08:52, 11/03/2023 15:45, 20/04/2023 21:37. (0048-DSRI-016) 1. The repeating internal time triggered oracle with a schedule of "every day at 12:00", always sends an event as soon as the block with a timestamp with time of 12:00 or higher is received (the time the oracle sends an event doesn't drift forward even after many days). (0048-DSRI-017) - diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 2a125230f..a3a44831b 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -120,7 +120,9 @@ Reward payouts will be calculated using the decimal precision of the reward payo ## Acceptance criteria -### Funding reward accounts (0056-REWA-001)(0056-SP-REWA-001) +### Funding reward accounts (0056-REWA-001) + +for product spot: (0056-REWA-062) Trading reward accounts are defined by a pair: [`payout_asset, dispatch_strategy`]. @@ -132,7 +134,9 @@ Create 3 markets settling in USDT. Wait for a new epoch to begin, in the next ep Run for another epoch with no fee generated. Expect no transfer to be made to the reward pools of the accounts. -### Funding reward accounts - with markets in scope (0056-REWA-002)(0056-SP-REWA-002) +### Funding reward accounts - with markets in scope (0056-REWA-002) + +for product spot: (0056-REWA-061) There are two assets configured on the Vega chain: $VEGA and USDT. @@ -142,7 +146,9 @@ Create 3 markets settling in USDT. Wait for a new epoch to begin, in the next ep Run for another epoch with no fee generated. Expect no transfer to be made to the reward pools of the accounts. -### Distributing fees paid rewards (0056-REWA-010)(0056-SP-REWA-010) +### Distributing fees paid rewards (0056-REWA-010) + +for product spot: (0056-REWA-060) #### Rationale 1 @@ -189,7 +195,9 @@ At the end of epoch 2: - `party_1` is paid `120 x 3.36 / 4.98 = 80.96.` USDC from the reward account into its USDC general account. - `party_2` is paid `120 x 1.62 / 4.98 = 39.03.` USDC from the reward account into its USDC general account. -### Distributing fees paid rewards - unfunded account (0056-REWA-011)(0056-SP-REWA-011) +### Distributing fees paid rewards - unfunded account (0056-REWA-011) + +for product spot: (0056-REWA-059) #### Rationale 2 @@ -207,7 +215,9 @@ No funding done. At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, no reward is given to any participant as the reward account was not funded. -### Distributing fees paid rewards - funded account - no trading activity (0056-REWA-012)(0056-SP-REWA-012) +### Distributing fees paid rewards - funded account - no trading activity (0056-REWA-012) + +for product spot: (0056-REWA-058) #### Rationale 3 @@ -231,7 +241,9 @@ Then, during epoch 3 we fund the reward accounts for the metric: Looking only at epoch 3 - as no trading activity was done, we expect the reward balances in both $VEGA and USDC for the metric to remain unchanged. -### Distributing fees paid rewards - multiple markets (0056-REWA-013)(0056-SP-REWA-013) +### Distributing fees paid rewards - multiple markets (0056-REWA-013) + +for product spot: (0056-REWA-057) #### Rationale 4 @@ -270,7 +282,9 @@ The calculation of eligibility is identical to [acceptance code REWA-010](https: - `party_1` is paid `120 x 3.36 / 4.98 = 80.96.` $VEGA from the reward account into its $VEGA general account. - `party_2` is paid `120 x 1.62 / 4.98 = 39.03.` $VEGA from the reward account into its $VEGA general account. -### Distributing maker fees received rewards (0056-REWA-020)(0056-SP-REWA-020) +### Distributing maker fees received rewards (0056-REWA-020) + +for product spot: (0056-REWA-056) #### Rationale 5 @@ -315,7 +329,9 @@ At the end of epoch `2` `party_0` is paid `90 x 2.8 / (2.79+2.8)` $VEGA from the At the end of epoch `2` `party_1` is paid `120 x 2.79 / (2.79+2.8)` USDC from the reward account into its `USDC` general account. At the end of epoch `2` `party_0` is paid `120 x 2.8 / (2.79+2.8)` USDC from the reward account into its `USDC` general account. -### Distributing maker fees received rewards - unfunded account (0056-REWA-021)(0056-SP-REWA-021) +### Distributing maker fees received rewards - unfunded account (0056-REWA-021) + +for product spot: (0056-REWA-055) #### Rationale 6 @@ -333,7 +349,9 @@ No funding done. At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, no reward is given to any participant as the reward account was not funded. -### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-022)(0056-SP-REWA-022) +### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-022) + +for product spot: (0056-REWA-054) #### Rationale 7 @@ -357,7 +375,9 @@ Then, during epoch 3 we fund the reward accounts for the metric: Looking only at epoch 3 - as no trading activity was done, we expect the reward balances in both $VEGA and USDC for the metric to remain unchanged. -### Distributing maker fees received rewards - multiple markets (0056-REWA-023)(0056-SP-REWA-023) +### Distributing maker fees received rewards - multiple markets (0056-REWA-023) + +for product spot: (0056-REWA-053) #### Rationale 8 @@ -396,7 +416,9 @@ The calculation of eligibility is identical to [acceptance code REWA-020](https: - At the end of epoch `2` `party_1` is paid `120 x 2.79 / (2.79+2.8)` USDC from the reward account into its `$VEGA` general account. - At the end of epoch `2` `party_0` is paid `120 x 2.8 / (2.79+2.8)` USDC from the reward account into its `$VEGA` general account. -### Distributing LP fees received rewards (0056-REWA-030)(0056-SP-REWA-030) +### Distributing LP fees received rewards (0056-REWA-030) + +for product spot: (0056-REWA-052) #### Rationale 9 @@ -422,7 +444,9 @@ At the end of epoch `2` `party_0` is paid `90` `$VEGA` from the reward account i At the end of epoch `2` `party_0` is paid `120` `USDC` from the reward account into its `USDC` general account. ### Distributing LP fees received rewards - unfunded account (0056-REWA-031) -(0056-SP-REWA-031) + +for product spot: +(0056-REWA-051) #### Rationale 10 @@ -440,7 +464,9 @@ No funding done. At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, no reward is given to any participant as the reward account was not funded. -### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-032)(0056-SP-REWA-032) +### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-032) + +for product spot: (0056-REWA-063) #### Rationale 11 @@ -464,7 +490,9 @@ Then, during epoch 3 we fund the reward accounts for the metric: Looking only at epoch 3 - as no trading activity was done, we expect the reward balances in both $VEGA and USDC for the metric to remain unchanged. -### Distributing LP fees received - multiple markets (0056-REWA-033)(0056-SP-REWA-033) +### Distributing LP fees received - multiple markets (0056-REWA-033) + +for product spot: (0056-REWA-064) #### Rationale 12 @@ -489,7 +517,9 @@ The calculation of eligibility is identical to [acceptance code REWA-030](https: - for market `ETHUSD-Jun22`: - t the end of epoch `2` `party_0` is paid `120` `USDC` from the reward account into its `USDC` general account. -### Distributing market creation rewards - no eligibility (0056-REWA-040)(0056-SP-REWA-040) +### Distributing market creation rewards - no eligibility (0056-REWA-040) + +for product spot: (0056-REWA-065) #### Rationale 13 @@ -508,7 +538,9 @@ Market has been trading but not yet eligible for proposer bonus. At the end of the epoch no payout has been made for the market `ETHUSDT` and the reward account balances should remain unchanged. -### Distributing market creation rewards - eligible are paid no more than once (0056-REWA-041)(0056-SP-REWA-041) +### Distributing market creation rewards - eligible are paid no more than once (0056-REWA-041) + +for product spot: (0056-REWA-066) #### Rationale 14 @@ -530,7 +562,9 @@ At the end of the epoch 2 the proposer of the market `ETHUSDT` is paid 10000 `$V At the end of epoch 3 make sure that no transfer is made to the reward account as the proposer of the market has already been paid the proposer bonus once and there are no other eligible markets. -### Distributing market creation rewards - account funded after reaching requirement (0056-REWA-042)(0056-SP-REWA-042) +### Distributing market creation rewards - account funded after reaching requirement (0056-REWA-042) + +for product spot: (0056-REWA-067) #### Rationale 15 @@ -551,7 +585,9 @@ Market goes above the threshold in trading value in an epoch before the reward a At the end of epoch 3, a payout of 10000 VEGA and 20000 USDC is made for the market `ETHUSDT` to the creator's general account balance. The reward pool balance should be 0. -### Distributing market creation rewards - multiple asset rewards (0056-REWA-043)(0056-SP-REWA-043) +### Distributing market creation rewards - multiple asset rewards (0056-REWA-043) + +for product spot: (0056-REWA-068) #### Rationale 16 @@ -573,7 +609,9 @@ At the end of epoch 2 1000 VEGA rewards should be distributed to the market crea Then, at the end of epoch 3, the 20000 USDC rewards should be distributed again to the market creator's general balance. The reward pool balance should be 0. -### Distributing market creation rewards - multiple asset rewards simultaneous payout (0056-REWA-045)(0056-SP-REWA-045) +### Distributing market creation rewards - multiple asset rewards simultaneous payout (0056-REWA-045) + +for product spot: (0056-REWA-069) #### Rationale 17 @@ -596,7 +634,9 @@ At the end of epoch 2 the creator of `ETHUSDT` should receive both 10000 VEGA an general account. The reward pool balance should be 0. -### Distributing market creation rewards - Same asset multiple party rewards (0056-REWA-044)(0056-SP-REWA-044) +### Distributing market creation rewards - Same asset multiple party rewards (0056-REWA-044) + +for product spot: (0056-REWA-070) #### Rationale 18 @@ -624,7 +664,9 @@ The reward account balance should again be empty Then, at the end of epoch 4, no further VEGA rewards should be distributed, the proposer of `ETHUSDTs` general `USDT` balance should stay at 20000. The reward account balance should still be empty, as there were no eligible markets so no transfer should occur. -### Distributing market creation rewards - Multiple markets eligible, one already paid (0056-REWA-046)(0056-SP-REWA-046) +### Distributing market creation rewards - Multiple markets eligible, one already paid (0056-REWA-046) + +for product spot: (0056-REWA-071) #### Rationale 19 @@ -656,7 +698,9 @@ At the end of epoch 3, 10000 VEGA should be split between the `BTCDAI` creator a - The general account balance of the `BTCDAI` creator should be 5000. - The reward pool balance should be 0. -### Reward accounts cannot be topped up with a one-off transfer (0056-REWA-049)(0056-SP-REWA-049) +### Reward accounts cannot be topped up with a one-off transfer (0056-REWA-049) + +for product spot: (0056-REWA-072) The following account types require metric-based distribution. As a one-off transfer cannot specify how it is rewarded, one-off transfers to metric-based reward pools must be **rejected**. A one-off transfer from a user to any of the following account types is rejected. No assets are transferred: @@ -666,7 +710,9 @@ A one-off transfer from a user to any of the following account types is rejected - `ACCOUNT_TYPE_REWARD_TAKER_PAID_FEES`, - `ACCOUNT_TYPE_REWARD_MARKET_PROPOSERS` -### Distributing market creation rewards - Market ineligible through metric asset (0056-REWA-048)(0056-SP-REWA-048) +### Distributing market creation rewards - Market ineligible through metric asset (0056-REWA-048) + +for product spot: (0056-REWA-073) #### Rationale 20 @@ -690,7 +736,9 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to only the `ETH - The general account balance of the `BTCDAI` creator should be 0. - The reward pool balance should be 0. -### Distributing market creation rewards - Multiple markets eligible, one already paid, specified asset (0056-REWA-047)(0056-SP-REWA-047) +### Distributing market creation rewards - Multiple markets eligible, one already paid, specified asset (0056-REWA-047) + +for product spot: (0056-REWA-074) #### Rationale 21 @@ -724,7 +772,9 @@ At the end of epoch 3, 10000 VEGA should be distributed split between the `BTCUS - The general account balance of the `BTCUSDT` creator should be 5000. - The reward pool balance should be 0. -### Updating the network parameter `rewards.marketCreationQuantumMultiple` (0056-REWA-050)(0056-SP-REWA-050) +### Updating the network parameter `rewards.marketCreationQuantumMultiple` (0056-REWA-050) + +for product spot: (0056-REWA-075) #### Rationale 22 @@ -739,7 +789,7 @@ immediately and the new value used at the end of the epoch to decide if market c - Transfer 10000 $VEGA to `ETHUSDT | market creation | $VEGA` - During epoch 1 start trading such that traded value for fee purposes in USDT is less than 10^6 but greater than 10^5 - During epoch 2 update the value of `marketCreationQuantumMultiple` via governance to `10^5`. - + #### Expectation 22 At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` creator. diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 1178e92aa..36db3b54f 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -206,7 +206,8 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. The LP party has general account balance in USD of `10 000`. #### Test case 3.4: Recovery from proposed Markets with no votes, voting is open, proposal not restored (0073-LIMN-012) -(0073-SP-LIMN-012) + +for product spot: (0073-LIMN-077) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -219,7 +220,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is no market and there are no market proposals. 1. The LP party has general account balance in USD of `10 000`. -#### Test case 3.5: Recovery from proposed Markets with votes, voting is open, proposal not restored (0073-LIMN-013)(0073-SP-LIMN-013) +#### Test case 3.5: Recovery from proposed Markets with votes, voting is open, proposal not restored (0073-LIMN-013) + +for product spot: (0073-LIMN-078) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -232,7 +235,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is no market and there are no market proposals. 1. The LP party has general account balance in USD of `10 000`. -#### Test case 3.6: Market proposals ignored when restoring twice from same checkpoint (0073-LIMN-014)(0073-SP-LIMN-014) +#### Test case 3.6: Market proposals ignored when restoring twice from same checkpoint (0073-LIMN-014) + +for product spot: (0073-LIMN-079) 1. A party has general account balance of 100 USD. 1. The party submits a withdrawal transaction for 100 USD. A checkpoint is immediately created. @@ -252,7 +257,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 4. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. 5. That party has a USD general account balance of 200 USD -### Test case 4b: In Spot market, party's Holding Account balance is put in to a General Account balance for that asset after a reset (0073-SP-LIMN-016) +### Test case 4b: In Spot market, party's Holding Account balance is put in to a General Account balance for that asset after a reset (0073-LIMN-080) 1. A party has USD general account balance of 100 USD. 2. That party has USD holding account balance of 50 USD. @@ -303,7 +308,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023) 1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024) 1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025) -1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026)(0073-SP-LIMN-026) +1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026) for product spot: (0073-LIMN-081) 1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027) 1. Propose a valid ERC-20 asset. @@ -316,7 +321,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Withdraw funds for one of the traders. 1. Propose an update to the asset, and ensure that you can update the ERC20 bridge with the asset update and signature bundle. -### Test case 13: A market with future enactment date can become enacted after being restored from checkpoint (0073-LIMN-028)(0073-SP-LIMN-028) +### Test case 13: A market with future enactment date can become enacted after being restored from checkpoint (0073-LIMN-028) + +for product spot: (0073-LIMN-082) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -341,25 +348,25 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Propose, enact, trade in the market, close out distressed party so that insurance pool balance > 0, submit trading terminated. 1. System saves LNL checkpoint at a time when undistributed LP fees for the market are > 0. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029)(0073-SP-LIMN-029) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029) for product spot: (0073-LIMN-083) 1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031) -1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-SP-LIMN-031) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032)(0073-SP-LIMN-032) +1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-LIMN-084) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032) for product spot: (0073-LIMN-085) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034)(0073-SP-LIMN-034) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034) for product spot: (0073-LIMN-086) ### Test case 15: Market with trading terminated that settled is not restored, collateral moved correctly 1. Propose, enact, trade in the market, submit trading terminated and settlement data, observe final settlement cashflows for at least 2 parties. 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040)(0073-SP-LIMN-040) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040) for product spot: (0073-LIMN-087) 1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) -1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-SP-LIMN-042) +1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-088) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044)(0073-SP-LIMN-044) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044) for product spot: (0073-LIMN-089) ### Test case 16: Markets can be settled and terminated after restore as proposed @@ -368,21 +375,21 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Restart Vega, load LNL checkpoint. 1. A party submits liquidity provision to the market, orders are submitted to the opening auction to allow uncrossing; at least two parties now have a position. 1. Submit the trading terminated transaction and settlement date transaction as set out in the proposal and observe the final settlement cashflows for the parties with positions. (0073-LIMN-050) -1. In Spot market, market can be closed after a restore. (0073-SP-LIMN-050) -1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051)(0073-SP-LIMN-051) +1. In Spot market, market can be closed after a restore. (0073-LIMN-090) +1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051) for product spot: (0073-LIMN-091) ### Test case 17: Markets with internal time trigger for trading terminated that rings between shutdown and restore 1. Propose, enact a market with some trading terminated given by internal time trigger. Trade in the market creating positions for at least 2 parties. 1. System saves LNL checkpoint before the trading terminated trigger rings. 1. Restart Vega, load LNL checkpoint at a time which is after trading terminated trigger should have rung. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060)(0073-SP-LIMN-060); if it exists it in `cancelled` state. -1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061)(0073-SP-LIMN-061) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060) for product spot: (0073-LIMN-092); if it exists it in `cancelled` state. +1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061) for product spot: (0073-LIMN-093) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062) -1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-SP-LIMN-062) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063)(0073-SP-LIMN-063) +1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-094) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063) for product spot: (0073-LIMN-095) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065)(0073-SP-LIMN-065) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065) for product spot: (0073-LIMN-096) ### Test case 18: market definition is the same pre and post LNL restore @@ -390,9 +397,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - System saves LNL checkpoint. - Restart Vega, load LNL checkpoint. - The market has the same: - - risk model and parameters (0073-LIMN-070)(0073-SP-LIMN-070) - - price monitoring bounds (0073-LIMN-071)(0073-SP-LIMN-071) - - oracle settings (0073-LIMN-072)(0073-SP-LIMN-072) + - risk model and parameters (0073-LIMN-070) for product spot: (0073-LIMN-097) + - price monitoring bounds (0073-LIMN-071) for product spot: (0073-LIMN-098) + - oracle settings (0073-LIMN-072) for product spot: (0073-LIMN-099) - margin scaling factors (0073-LIMN-073) ### Test case 19: Deposit tokens during checkpoint restore @@ -402,7 +409,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Stop the network. 1. Deposit tokens to a vega party via the ERC20 assert bridge. 1. Restart the vega network from the checkpoint created earlier. -1. There party's newly deposited assets are available. (0073-LIMN-074)(0073-SP-LIMN-074) +1. There party's newly deposited assets are available. (0073-LIMN-074) for product spot: (0073-LIMN-100) ### Test case 20: Multisig updates during checkpoint restart @@ -423,4 +430,3 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. Do not update the multisig contract. 1. Restart the vega network from the checkpoint created earlier. 1. Vega observes the incorrect multisig, and rewards are not paid at the end of the current epoch. (0073-LIMN-076) - From f80fef5516e07e820c2dfa69d9f80ca338093c84 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 12 Jul 2023 16:50:31 +0200 Subject: [PATCH 276/649] feat: address comments --- protocol/0013-ACCT-accounts.md | 2 +- protocol/0073-LIMN-limited_network_life.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 763ba4e52..d28ab0074 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -105,7 +105,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas - Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003)(0013-SP-ACCT-003) - Only one general asset account exists per party per asset. (0013-ACCT-004)(0013-SP-ACCT-004) - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005)(0013-SP-ACCT-005) - - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006)(0013-SP-ACCT-006) + - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) - [Fees earned from liquidity provision](./0044-LIME-lp_mechanics.md#fees) are paid in to this account. (0013-ACCT-011) ### Party margin accounts diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 36db3b54f..8461a7246 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -118,7 +118,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - If the Ethereum replay hasn't seen withdrawal transaction processed and the expiry time of the withdrawal hasn't passed yet. Then the party has general account balance of 0 USD. The party has "signed for withdrawal" 100. - If the Ethereum replay hasn't seen withdrawal transaction processed and the expiry time of the withdrawal has passed. Then the party has general account balance of 100 USD. -### Test case 2: Orders and positions are *not* maintained across resets, balances are and *accepted* markets are (0073-LIMN-008)(0073-SP-LIMN-008) +### Test case 2: Orders and positions are *not* maintained across resets, balances are and *accepted* markets are (0073-LIMN-008) 1. There is an asset USD and no asset proposals. 1. There is a market `id_xxx` with status active, no other markets and no market proposals. From 5a39f9634caf16355354ffe0496c7b31e5c53fa2 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 12 Jul 2023 16:09:06 +0100 Subject: [PATCH 277/649] chore: first bacth of updated AC codes for spot --- protocol/0004-AMND-amends.md | 54 +++++++++---------- protocol/0008-TRAD-trading_workflow.md | 2 +- .../0011-MARA-check_order_allocate_margin.md | 30 +++++------ protocol/0013-ACCT-accounts.md | 17 +++--- protocol/0014-ORDT-order_types.md | 44 +++++++-------- protocol/0037-OPEG-pegged_orders.md | 2 +- protocol/0047-DSRF-data_source_filter.md | 14 ++--- protocol/0073-LIMN-limited_network_life.md | 1 + 8 files changed, 82 insertions(+), 82 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 86a136a20..659c658e8 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -2,38 +2,38 @@ ## Acceptance Criteria -- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001)(0004-SP-AMND-001) -- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002)(0004-SP-AMND-002) -- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003)(0004-SP-AMND-003) -- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004)(0004-SP-AMND-004) -- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005)(0004-SP-AMND-005) -- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006)(0004-SP-AMND-006) -- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007)(0004-SP-AMND-007) -- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008)(0004-SP-AMND-008) -- The `orderID` remains the same after an amend (0004-AMND-009)(0004-SP-AMND-009) -- Amends can occur in continuous trading or in an auction (0004-AMND-010)(0004-SP-AMND-010) -- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011)(0004-SP-AMND-011) -- All amendable fields can be amended in the same amend message (0004-AMND-012)(0004-SP-AMND-012) -- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013)(0004-SP-AMND-013) -- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014)(0004-SP-AMND-014) -- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015)(0004-SP-AMND-015) -- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016)(0004-SP-AMND-016) -- A parked pegged order can be amended. (0037-OPEG-014)(0037-SP-OPEG-014) -- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017)(0004-SP-AMND-017) -- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018)(0004-SP-AMND-018) -- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019)(0004-SP-AMND-019) -- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029)(0004-SP-AMND-029) +- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001) for product spot: (0004-AMND-030) +- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002) for product spot: (0004-AMND-031) +- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003) for product spot: (0004-AMND-032) +- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004) for product spot: (0004-AMND-032) +- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005) for product spot: (0004-AMND-033) +- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006) for product spot: (0004-AMND-034) +- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007) for product spot: (0004-AMND-035) +- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008) for product spot: (0004-AMND-036) +- The `orderID` remains the same after an amend (0004-AMND-009) for product spot: (0004-AMND-037) +- Amends can occur in continuous trading or in an auction (0004-AMND-010) for product spot: (0004-AMND-038) +- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011) for product spot: (0004-AMND-039) +- All amendable fields can be amended in the same amend message (0004-AMND-012) for product spot: (0004-AMND-040) +- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013) for product spot: (0004-AMND-041) +- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014) for product spot: (0004-AMND-042) +- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015) for product spot: (0004-AMND-043) +- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016) for product spot: (0004-AMND-044) +- A parked pegged order can be amended. (0037-OPEG-014) for product spot: (0037-OPEG-019) +- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017) for product spot: (0004-AMND-045) +- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018) for product spot: (0004-AMND-046) +- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019) for product spot: (0004-AMND-047) +- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029) for product spot: (0004-AMND-048) For a party with no position on a given market: - Amending an order in a way that increases the volume sufficiently leads to margin account balance increasing (0004-AMND-021) -- In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-SP-AMND-021) +- In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-AMND-049) - Amending an order in a way that decreases the volume sufficiently leads to margin account balance decreasing (0004-AMND-022) -- In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-SP-AMND-022) -- It is possible to amend a fractional size order (0004-AMND-025)(0004-SP-AMND-025) -- It is possible to amend a partially filled limit order (0004-AMND-026)(0004-SP-AMND-026) -- It is possible to amend a versioned order (already amended several times) (0004-AMND-027)(0004-SP-AMND-027) -- Attempts to amend order fields not in scope are rejected (0004-AMND-028)(0004-SP-AMND-028) +- In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-AMND-050) +- It is possible to amend a fractional size order (0004-AMND-025) for product spot: (0004-AMND-051) +- It is possible to amend a partially filled limit order (0004-AMND-026) for product spot: (0004-AMND-052) +- It is possible to amend a versioned order (already amended several times) (0004-AMND-027) for product spot: (0004-AMND-053) +- Attempts to amend order fields not in scope are rejected (0004-AMND-028) for product spot: (0004-AMND-054) ## Summary diff --git a/protocol/0008-TRAD-trading_workflow.md b/protocol/0008-TRAD-trading_workflow.md index 2b1e22469..b54705e52 100644 --- a/protocol/0008-TRAD-trading_workflow.md +++ b/protocol/0008-TRAD-trading_workflow.md @@ -10,7 +10,7 @@ The order of processing of transactions happens in the order defined in the diag 1. Before a valid order is processed in any other way by Vega, the [party](./0017-PART-party.md)'s [margin levels](./0011-MARA-check_order_allocate_margin.md) are checked as though they had the order in their position, and any transfers that are needed to support that order occur. (0008-TRAD-001) 1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there will be changes in positions for one or more traders. (0008-TRAD-002) -1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003)(0008-SP-TRAD-003) +1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003) for product spot: (0008-TRAD-008) 1. Following the above 3 actions, a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is run for all parties against their most recently updated positions and Mark Price. This will result in a set of transfers between the parties' accounts and possibly may result in loss socialisation occurring if a party has insufficient collateral to cover the move. (0008-TRAD-004) 1. Following the mark to market settlement, the margin liabilities for traders are evaluated against their collateral balances. Any traders that do not have sufficient collateral to support their positions (after collateral searches have been done to their main account) will undergo position resolution. (0008-TRAD-005) 1. After position resolution has occurred, margins are recalculated and evaluated against balances for any traders that gained positions as a result of supplying liquidity on the order book to the network during position resolution. (0008-TRAD-006) diff --git a/protocol/0011-MARA-check_order_allocate_margin.md b/protocol/0011-MARA-check_order_allocate_margin.md index f80c99285..a4cb68573 100644 --- a/protocol/0011-MARA-check_order_allocate_margin.md +++ b/protocol/0011-MARA-check_order_allocate_margin.md @@ -9,14 +9,14 @@ Orders should be rejected if we can’t allocate sufficient margin. ## Acceptance criteria 1. If an order is amended such that margin requirement is increased and user has sufficient balance in the general account to top up their margin account then the amendment is executed successfully. (0011-MARA-001) -1. In Spot market, if an order is amended such that holding requirement is increased and user has sufficient balance in the general account to top up their holding account then the amendment is executed successfully. (0011-SP-MARA-001) +1. In Spot market, if an order is amended such that holding requirement is increased and user has sufficient balance in the general account to top up their holding account then the amendment is executed successfully. (0011-MARA-018) 1. If an order is amended such that margin requirement is increased and user doesn't have sufficient balance in the general account to top up their margin account then their amend is not executed but the unamended order stays on the book. (0011-MARA-002) -1. In Spot market, if an order is amended such that holding requirement is increased and user doesn't have sufficient balance in the general account to top up their holding account then their amend is not executed but the unamended order stays on the book. (0011-SP-MARA-002) +1. In Spot market, if an order is amended such that holding requirement is increased and user doesn't have sufficient balance in the general account to top up their holding account then their amend is not executed but the unamended order stays on the book. (0011-MARA-019) 1. Cancelling an order releases the margin amount back to user's general account, provided the user has no other orders or positions (0011-MARA-003) -In Spot market, cancelling an order releases the holding amount back to user's general account. (0011-SP-MARA-003) +In Spot market, cancelling an order releases the holding amount back to user's general account. (0011-MARA-020) 1. If an order is amended such that margin requirement is decreased then the amendment is executed successfully. (0011-MARA-004) 1. If an order is partially filled then the margin requirements are recalculated reflecting the reduced order size and new position size. (0011-MARA-005) -In Spot market, if an order is partially filled then the holding requirements are recalculated reflecting the reduced order size. (0011-SP-MARA-005) +In Spot market, if an order is partially filled then the holding requirements are recalculated reflecting the reduced order size. (0011-MARA-021) 1. If an order is partially filled and if this leads to a reduced position and reduced riskiest long / short then the margin requirements are seen to be reduced and if margin balance is above release level then the excess amount is transferred to the general account. (0011-MARA-006) 1. Margin is correctly calculated for [all order types](./0014-ORDT-order_types.md) in continuous trading: 1. Limit GTT (0011-MARA-007) @@ -32,18 +32,18 @@ In Spot market, if an order is partially filled then the holding requirements ar 1.Pegged GTT (parked in auction \*) (0011-MARA-016) 1.Pegged GTC (parked in auction \* ) (0011-MARA-017) 1. In Spot market, holding in holding account is correctly calculated for [all order types](./0014-ORDT-order_types.md) in continuous trading: - 1. Limit GTT (0011-SP-MARA-007) - 1. Limit GTC (0011-SP-MARA-008) - 1. Limit GFN (0011-SP-MARA-009) - 1. Pegged GTT (0011-SP-MARA-010) - 1. Pegged GTC (0011-SP-MARA-011) - 1. Pegged GFN (0011-SP-MARA-012) + 1. Limit GTT (0011-MARA-022) + 1. Limit GTC (0011-MARA-023) + 1. Limit GFN (0011-MARA-024) + 1. Pegged GTT (0011-MARA-025) + 1. Pegged GTC (0011-MARA-026) + 1. Pegged GFN (0011-MARA-027) 1. In Spot market, holding in holding account is correctly calculated for [all order types](./0014-ORDT-order_types.md) in auction mode: - 1.Limit GTT (0011-SP-MARA-013) - 1.Limit GTC (0011-SP-MARA-014) - 1.Limit GFA (0011-SP-MARA-015) - 1.Pegged GTT (parked in auction \*) (0011-SP-MARA-016) - 1.Pegged GTC (parked in auction \* ) (0011-SP-MARA-017) + 1.Limit GTT (0011-MARA-028) + 1.Limit GTC (0011-MARA-029) + 1.Limit GFA (0011-MARA-030) + 1.Pegged GTT (parked in auction \*) (0011-MARA-031) + 1.Pegged GTC (parked in auction \* ) (0011-MARA-032) ## Pseudocode diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 763ba4e52..7ff69f282 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -97,15 +97,15 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### All ordinary accounts -- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001)(0013-SP-ACCT-001) -- Only transfer requests move money between accounts. (0013-ACCT-002)(0013-SP-ACCT-002) +- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001) for product spot: (0013-ACCT-024) +- Only transfer requests move money between accounts. (0013-ACCT-002) for product spot: (0013-ACCT-025) ### Party asset accounts -- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003)(0013-SP-ACCT-003) - - Only one general asset account exists per party per asset. (0013-ACCT-004)(0013-SP-ACCT-004) - - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005)(0013-SP-ACCT-005) - - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006)(0013-SP-ACCT-006) +- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003) for product spot: (0013-ACCT-026) + - Only one general asset account exists per party per asset. (0013-ACCT-004) for product spot: (0013-ACCT-027) + - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005) for product spot: (0013-ACCT-028) + - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) for product spot: (0013-ACCT-029) - [Fees earned from liquidity provision](./0044-LIME-lp_mechanics.md#fees) are paid in to this account. (0013-ACCT-011) ### Party margin accounts @@ -117,8 +117,8 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Party holding accounts in Spot market -- Every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) -- Each party should only have two holding accounts per market: one for the the base_asset and one for the quote_asset. (0013-SP-ACCT-008) +- Every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) +- Each party should only have two holding accounts per market: one for the the base_asset and one for the quote_asset. (0013-ACCT-031) ### Liquidity Provider bond accounts @@ -144,4 +144,3 @@ One key difference with staking accounts is that the collateral is not held in a - The balance can only be delegated to Validators (0013-ACCT-015) - The balance cannot be traded, or used as margin, or transferred, or withdrawn (0013-ACCT-016) - Delegated stake remains in the trader's staking account (0013-ACCT-017) - diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 460bcb003..0b8511ef6 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -255,46 +255,46 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ## Acceptance Criteria - Immediate orders, continuous trading: - - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001)(0014-SP-ORDT-001) - - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002)(0014-SP-ORDT-002) - - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003)(0014-SP-ORDT-003) - - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004)(0014-SP-ORDT-004) - - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005)(0014-SP-ORDT-005) -- No party can submit a [network order type](#network-orders) (0014-ORDT-006)(0014-SP-ORDT-006) + - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) for product spot: (0014-ORDT-081) + - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) for product spot: (0014-ORDT-082) + - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) for product spot: (0014-ORDT-083) + - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) for product spot: (0014-ORDT-084) + - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) for product spot: (0014-ORDT-085) +- No party can submit a [network order type](#network-orders) (0014-ORDT-006) for product spot: (0014-ORDT-086) - A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's #### Iceberg Order Submission -1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007)(0014-ORDT-007) -2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008)(0014-ORDT-008) -3. An iceberg post only order can be submitted (0014-ORDT-009)(0014-ORDT-009) -4. An iceberg reduce only order is rejected (0014-ORDT-010)(0014-ORDT-010) +1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007) for product spot: (0014-ORDT-087) +2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008) for product spot: (0014-ORDT-088) +3. An iceberg post only order can be submitted (0014-ORDT-009) for product spot: (0014-ORDT-089) +4. An iceberg reduce only order is rejected (0014-ORDT-010) for product spot: (0014-ORDT-090) 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) -In Spot market, for an iceberg order that is submitted with total size x and display size y the holding asset taken should be identical to a regular order of size `x` rather than one of size `y` (0014-SP-ORDT-011) -6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012)(0014-SP-ORDT-012) +In Spot market, for an iceberg order that is submitted with total size x and display size y the holding asset taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-091) +6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) for product spot: (0014-ORDT-092) - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue -7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013)(0014-SP-ORDT-013) +7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013) for product spot: (0014-ORDT-093) #### Iceberg Order Batch Submission 1. For multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, margin calculations , order status are all correct (0014-ORDT-014) -In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all correct. (0014-SP-ORDT-014) -2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015)(0014-SP-ORDT-015) +In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all correct. (0014-ORDT-094) +2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015) for product spot: (0014-ORDT-095) #### Iceberg Order Submission - Negative tests -1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016)(0014-SP-ORDT-016) -2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017)(0014-SP-ORDT-017) -3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018)(0014-SP-ORDT-018) -4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020)(0014-SP-ORDT-020) -5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021)(0014-SP-ORDT-021) -6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022)(0014-SP-ORDT-022) +1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016) for product spot: (0014-ORDT-096) +2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017) for product spot: (0014-ORDT-097) +3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018) for product spot: (0014-ORDT-098) +4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) for product spot: (0014-ORDT-099) +5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) for product spot: (0014-ORDT-100) +6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) for product spot: (0014-ORDT-100) #### Iceberg Order Amendment -1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023)(0014-SP-ORDT-023) +1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023) for product spot: (0014-ORDT-101) 2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024)(0014-SP-ORDT-024) 3. Amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost (0014-ORDT-025) 4. In Spot market, amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost. (0014-SP-ORDT-025) diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index b8968f4ec..cf9c050fd 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -15,7 +15,7 @@ - If the midprice is calculated to be a fraction (e.g. 102.5), it should be rounded up for a buy and rounded down for a sell. (0037-OPEG-011) - The order version is not updated during a repricing (0037-OPEG-012) - Pegged orders are included in the calculation of the BEST_BID, BEST_ASK and MID prices but excluded from BEST_STATIC_BID, BEST_STATIC_ASK and STATIC_MID (0037-OPEG-013) -- A parked pegged order can be amended. (0037-OPEG-014) +- A parked pegged order can be amended. (0037-OPEG-014) for product spot: (0037-OPEG-019) - A pegged order with an offset which would cause it to be priced <= 0 is parked. (0037-OPEG-017) - An active pegged order can be amended. (0037-OPEG-016) - A transaction submitting a pegged order with negative offset fails with an error explaining the cause was negative offset. (0037-OPEG-018) diff --git a/protocol/0047-DSRF-data_source_filter.md b/protocol/0047-DSRF-data_source_filter.md index 9c486dd02..d85e3e7cf 100644 --- a/protocol/0047-DSRF-data_source_filter.md +++ b/protocol/0047-DSRF-data_source_filter.md @@ -99,8 +99,8 @@ To be clear, this also means that if the input data is the wrong "shape" or type 1. Data sources are defined by the FULL definition including filters 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters then data filtered out by one source can still be received by another, and vice versa. (0047-DSRF-008) 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that passes through and is emitted by both data sources results in a separate event/emission for each that references the appropriate source in each case. (0047-DSRF-009) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010) - 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) then any data that is filtered out by both data sources results in a separate log/event for each that references the appropriate source in each case. (0047-DSRF-010) + 1. If two data sources originate from the same data point (transaction, event, etc.) and provider (`SignedMessage` signer group, internal market/object, etc.) but have different filters or other properties (i.e. they are not exactly the same definition) and the data is filtered out by one and emitted/passes through the other, then both the filtering out and the emission of the data are recorded in logs/events that reference the appropriate source. (0047-DSRF-011) 1. Data types and condition types 1. Text fields can be filtered by equality (text matches filter data exactly). (0047-DSRF-012) 1. Number fields can be filtered by equality (number matches filter data exactly). (0047-DSRF-013) @@ -110,8 +110,8 @@ To be clear, this also means that if the input data is the wrong "shape" or type 1. Number fields can be filtered by less than or equal (number is less than or equal to filter data). (0047-DSRF-017) 1. Date + time fields can be filtered by less than or equal (datetime is less than or equal to filter data). (0047-DSRF-018) 1. Number fields can be filtered by greater than (number is greater than filter data). (0047-DSRF-019) - 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020) - 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021) - 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022 - 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023) - 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024) + 1. Date + time fields can be filtered by greater than (datetime is greater than filter data). (0047-DSRF-020) + 1. Number fields can be filtered by greater than or equal (number is greater than or equal to filter data). (0047-DSRF-021) + 1. Date + time fields can be filtered by greater than or equal (datetime is greater than or equal to filter data). (0047-DSRF-022 + 1. Oracle data filters can be combined together using AND operation (0047-DSRF-023) + 1. Filtering should cause the transaction containing the data source definition to be rejected when using filters which are deemed out scope (0047-DSRF-024) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 36db3b54f..160c8ad40 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -266,6 +266,7 @@ for product spot: (0073-LIMN-0790073-LIMN-017) + 1. There is a Vega token asset. 1. There are `5` validators on the network. 1. Each validator party `validator_party_1`,...,`validator_party_5` has `1000` Vega tokens locked on the staking Ethereum bridge and this is reflected in Vega core. From 0f9c78732e2bfbc35f3886501bd9828233e36f54 Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 12 Jul 2023 16:16:36 +0100 Subject: [PATCH 278/649] chore: update the first batch of spot AC codes --- protocol/0014-ORDT-order_types.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 0b8511ef6..6c10799d8 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -295,20 +295,20 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with #### Iceberg Order Amendment 1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023) for product spot: (0014-ORDT-101) -2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024)(0014-SP-ORDT-024) +2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024) for product spot: (0014-ORDT-102) 3. Amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost (0014-ORDT-025) -4. In Spot market, amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost. (0014-SP-ORDT-025) +4. In Spot market, amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost. (0014-ORDT-103) #### Iceberg Order Cancellation 1. Cancelling an iceberg order will cancel the order, remove it from the order book , release margin and update order book to reflect the change (0014-ORDT-026) -1. In Spot market, cancelling an iceberg order will cancel the order, remove it from the order book , release holding asset and update order book to reflect the change (0014-SP-ORDT-026) +1. In Spot market, cancelling an iceberg order will cancel the order, remove it from the order book , release holding asset and update order book to reflect the change (0014-ORDT-104) #### Iceberg Order Execution -1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027)(0014-SP-ORDT-027) -2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028)(0014-SP-ORDT-028) -3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029)(0014-SP-ORDT-029) +1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027) for product spot: (0014-ORDT-105) +2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) for product spot: (0014-ORDT-106) +3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) for product spot: (0014-ORDT-107) 4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030)(0014-SP-ORDT-030) 5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031)(0014-SP-ORDT-031) 6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032)(0014-SP-ORDT-032) From 462c4236bc8d7400570197bbcbd5e581976094ef Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 13 Jul 2023 10:51:03 +0100 Subject: [PATCH 279/649] fix: spot AC codes --- protocol/0013-ACCT-accounts.md | 2 +- protocol/0014-ORDT-order_types.md | 22 +-- protocol/0021-MDAT-market_data_spec.md | 16 +- protocol/0024-OSTA-order_status.md | 46 +++-- protocol/0025-OCRE-order_submission.md | 6 +- protocol/0026-AUCT-auctions.md | 22 +-- protocol/0029-FEES-fees.md | 16 +- protocol/0032-PRIM-price_monitoring.md | 34 ++-- protocol/0033-OCAN-cancel_orders.md | 15 +- ...PROB-prob_weighted_liquidity_measure.ipynb | 6 +- protocol/0036-BRIE-event_queue.md | 6 +- .../0039-MKTD-market_depth_calculation.md | 28 +-- protocol/0043-MKTL-market_lifecycle.md | 10 +- ...-TVAL-validate_transaction_preconsensus.md | 12 +- protocol/0051-PROD-product.md | 6 +- .../0052-FPOS-fractional_orders_positions.md | 4 +- protocol/0054-NETP-network_parameters.md | 10 +- protocol/0057-TRAN-transfers.md | 2 +- .../0065-FTCO-floating_point_consensus.md | 8 +- .../0066-VALW-validator_tendermint_weights.md | 4 +- protocol/0068-MATC-matching_engine.md | 66 +++---- .../0069-VCBS-validators_chosen_by_stake.md | 175 +++++++++--------- protocol/0070-MKTD-market-decimal-places.md | 16 +- protocol/0073-LIMN-limited_network_life.md | 14 +- .../0074-BTCH-batch-market-instructions.md | 18 +- .../0079-TGAP-transaction_gas_and_priority.md | 8 +- protocol/0080-SPOT-product_builtin_spot.md | 22 +-- 27 files changed, 308 insertions(+), 286 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 7ff69f282..4583dcf3d 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -117,7 +117,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Party holding accounts in Spot market -- Every party that submits an order on a market will have a holding account for that market created. (0013-SP-ACCT-007) +- Every party that submits an order on a market will have a holding account for that market created. (0013-ACCT-030) - Each party should only have two holding accounts per market: one for the the base_asset and one for the quote_asset. (0013-ACCT-031) ### Liquidity Provider bond accounts diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 6c10799d8..0bd918558 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -309,24 +309,24 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with 1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027) for product spot: (0014-ORDT-105) 2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) for product spot: (0014-ORDT-106) 3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) for product spot: (0014-ORDT-107) -4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030)(0014-SP-ORDT-030) -5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031)(0014-SP-ORDT-031) -6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032)(0014-SP-ORDT-032) -7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033)(0014-SP-ORDT-033) -8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034)( 0014-SP-ORDT-034) +4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030) for product spot: (0014-ORDT-108) +5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) for product spot: (0014-ORDT-109) +6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032) for product spot: (0014-ORDT-110) +7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) for product spot: (0014-ORDT-111) +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034)( 0014-ORDT-111) 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037)(0014-SP-ORDT-037) - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038)(0014-SP-ORDT-038) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) for product spot: (0014-ORDT-112) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) for product spot: (0014-ORDT-113) ### Snapshots -1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035)(0014-SP-ORDT-035) +1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035) for product spot: (0014-ORDT-114) ### API -1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036)(0014-SP-ORDT-036) -2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069)(0014-SP-ORDT-069) -3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070)(0014-SP-ORDT-070) +1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) for product spot: (0014-ORDT-115) +2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069) for product spot: (0014-ORDT-116) +3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070) for product spot: (0014-ORDT-117) ### Stop orders diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index 67cb28c1d..4f3e76eea 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -2,18 +2,18 @@ ## Acceptance Criteria -- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001)(0021-SP-MDAT-001) -- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002)(0021-SP-MDAT-002) -- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003)(0021-SP-MDAT-003) -- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004)(0021-SP-MDAT-004) -- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005)(0021-SP-MDAT-005) -- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006)(0021-SP-MDAT-006) -- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007)(0021-SP-MDAT-007) +- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001) for product spot: (0021-MDAT-013) +- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002) for product spot: (0021-MDAT-014) +- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003) for product spot: (0021-MDAT-015) +- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004) for product spot: (0021-MDAT-016) +- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005) for product spot: (0021-MDAT-017) +- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006) for product spot: (0021-MDAT-018) +- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007) for product spot: (0021-MDAT-019) - The Open interest returns the sum of the size for all open positions where positions size is greater than 0. (0021-MDAT-008) - The Open interest returns 0 if there are no positions on the market (0021-MDAT-009) - Pegged orders are excluded from the best static price and best static volume calculations. (0021-MDAT-010) - Dynamic orders should be ignored when calculating the static values (0021-MDAT-011) -- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012)(0021-SP-MDAT-012) +- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012) for product spot: (0021-MDAT-010) ## Summary diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index f02cb1a10..b07215002 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -43,14 +43,18 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. ## Acceptance Criteria -### Fill or Or Kill (0024-OSTA-001)(0024-SP-OSTA-001) +### Fill or Or Kill (0024-OSTA-001) + +for product spot: (0024-OSTA-030) | Time In Force | Filled | Resulting status | |---------------|--------|------------------| | FOK | No | Stopped | | FOK | Yes | Filled | -### Immediate Or Cancel (0024-OSTA-002)(0024-SP-OSTA-002) +### Immediate Or Cancel (0024-OSTA-002) + +for product spot: (0024-OSTA-031) | Time In Force | Filled | Resulting status | |---------------|---------|------------------| @@ -58,7 +62,9 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. | IOC | Partial | Partially Filled | | IOC | Yes | Filled | -### Good ’Til Cancelled (0024-OSTA-003)(0024-OSP-STA-003) +### Good ’Til Cancelled (0024-OSTA-003) + +for product spot: (0024-OSTA-032) | Time In Force | Filled | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|-------------------|-------------------|------------------| @@ -70,7 +76,9 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. | GTC | Partial | No | Yes | Rejected | | GTC | Yes | No | No | Filled | -### Good ’Til Time (0024-OSTA-004)(0024-SP-OSTA-004) +### Good ’Til Time (0024-OSTA-004) + +for product spot: (0024-OSTA-033) | Time In Force | Filled | Expired | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|---------|-------------------|-------------------|------------------| @@ -89,10 +97,10 @@ Note: The last row in the table above is added for clarity. If the order was fil ### Wash trading Acceptance Criteria -- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-SP-OSTA-005)(0024-OSTA-005) -- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006)(0024-SP-OSTA-006) -- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007)(0024-SP-OSTA-007) -- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008)(0024-SP-OSTA-008) +- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-OSTA-005) for product spot: (0024-OSTA-034) +- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006) for product spot: (0024-OSTA-035) +- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007) for product spot: (0024-OSTA-036) +- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008) for product spot: (0024-OSTA-037) ### Impact of order types on settlement @@ -102,20 +110,20 @@ Note: The last row in the table above is added for clarity. If the order was fil - Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` is given if a position is closed out because they do now have enough margin to cover the position (0024-OSTA-010) - Order reason of `ORDER_ERROR_MARGIN_CHECK_FAILED` is given if a new order is placed and the user does not have enough collateral to cover the initial margin requirements (0024-OSTA-011) -- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012)(0024-SP-OSTA-012) -- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013)(0024-SP-OSTA-013) -- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014)(0024-SP-OSTA-014) -- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015)(0024-SP-OSTA-015) -- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016)(0024-SP-OSTA-016) -- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017)(0024-SP-OSTA-017) -- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018)(0024-SP-OSTA-018) -- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019)(0024-SP-OSTA-019) -- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020)(0024-SP-OSTA-020) +- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012) for product spot: (0024-OSTA-038) +- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013) for product spot: (0024-OSTA-039) +- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014) for product spot: (0024-OSTA-040) +- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015) for product spot: (0024-OSTA-041) +- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016) for product spot: (0024-OSTA-042) +- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017)for product spot: (0024-OSTA-043) +- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018) for product spot: (0024-OSTA-044) +- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019) for product spot: (0024-OSTA-045) +- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020) for product spot: (0024-OSTA-046) - Order reason of `ORDER_ERROR_MUST_BE_LIMIT_ORDER` when sending a pegged order that is not a LIMIT order (0024-OSTA-021) - Order reason of `ORDER_ERROR_MUST_BE_GTT_OR_GTC` pegged order must be either GTC or GTT (0024-OSTA-022) - Order reason of `ORDER_ERROR_WITHOUT_REFERENCE_PRICE` pegged order must have a reference field (0024-OSTA-023) - Order reason of `ORDER_ERROR_BUY_CANNOT_REFERENCE_BEST_ASK_PRICE` buy pegged order cannot reference the ask price (0024-OSTA-024) - Order reason of `ORDER_ERROR_OFFSET_MUST_BE_GREATER_THAN_ZERO` pegged order offset must be > 0 when referencing `MID` price (0024-OSTA-025) - Order reason of `ORDER_ERROR_SELL_CANNOT_REFERENCE_BEST_BID_PRICE` sell pegged order cannot reference the bid price (0024-OSTA-026) -- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027)(0024-SP-OSTA-027) -- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029)(0024-SP-OSTA-029) +- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027) for product spot: (0024-OSTA-047) +- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029) for product spot: (0024-OSTA-048) diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index 21df45bd0..9f8ed801f 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -37,12 +37,12 @@ Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an ## Acceptance Criteria -- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001)(0025-SP-OCRE-001) +- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001) for product spot: (0025-OCRE-004) - Margin will taken before the order is entered into the book (0025-OCRE-002) - If sufficient margin cannot be reserved, the order will have a status of `REJECTED` (0025-OCRE-003) - Fees are charged as per [0029-FEES](./0029-FEES-fees.md). -- In Spot market, holding will taken before the order is entered into the book(0025-SP-OCRE-002) - - If sufficient holding cannot be reserved, the order will have a status of `REJECTED` (0025-SP-OCRE-003) +- In Spot market, holding will taken before the order is entered into the book(0025-OCRE-005) + - If sufficient holding cannot be reserved, the order will have a status of `REJECTED` (0025-OCRE-006) ## Future Work diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index c3d7af9c0..197662c83 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -157,24 +157,24 @@ message Market { ## Acceptance Criteria -- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003)(0026-SP-AUCT-003) -- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004)(0026-SP-AUCT-004) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033)(0068-SP-MATC-033) -- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005)(0026-SP-AUCT-005) -- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006)(0026-SP-AUCT-006) -- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007)(0026-SP-AUCT-007) -- As an API user, I can identify: (0026-AUCT-008)(0026-SP-AUCT-008) +- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003) for product spot: (0026-AUCT-023) +- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004) for product spot: (0026-AUCT-024) +- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) for product spot: (0068-MATC-060) +- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005)for product spot:(0026-AUCT-025) +- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006) for product spot: (0026-AUCT-026) +- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007) for product spot: (0026-AUCT-027) +- As an API user, I can identify: (0026-AUCT-008) for product spot: (0026-AUCT-028) - If a market is temporarily in an auction period - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017)(0026-SP-AUCT-017) - 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018)(0026-SP-AUCT-018) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) for product spot: (0026-AUCT-029) + 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) for product spot: (0026-AUCT-030) 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have - best bid; it will still open. (0026-AUCT-021) - or best ask; it will still open. (0026-AUCT-022) -- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015)(0026-SP-AUCT-015) -- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016)(0026-SP-AUCT-016) +- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015) for product spot: (0026-AUCT-031) +- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016) for product spot: (0026-AUCT-032) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 833498ad6..9537b2e6e 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -93,17 +93,17 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria -- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001)(0029-SP-FEES-001) +- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) for product spot: (0029-FEES-015) - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) -- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005)(0029-SP-FEES-005)(0029-SP-FEES-005) +- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) for product spot: (0029-FEES-016) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) - During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) -- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009)(0029-SP-FEES-009) -- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010)(0029-SP-FEES-010) -- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011)(0029-SP-FEES-011) -- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012)(0029-SP-FEES-012) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013)(0029-SP-FEES-013) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014)(0029-SP-FEES-014) +- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009) for product spot: (0029-FEES-017) +- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010) for product spot: (0029-FEES-018) +- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011) for product spot: (0029-FEES-019) +- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012) for product spot: (0029-FEES-020) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013) for product spot: (0029-FEES-021) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014) for product spot: (0029-FEES-022) diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 6dfada2d0..e74b9ed4a 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -109,23 +109,23 @@ to the risk model and obtains the range of valid up/down price moves per each of ## Acceptance Criteria -- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001)(0032-SP-PRIM-001) +- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001) for product spot: (0032-PRIM-022) - Non-persistent order does not result in an auction (1 out of 2 triggers breached), order gets cancelled (never makes it to the order book) -(0032-PRIM-003)(0032-SP-PRIM-003) -- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005)(0032-SP-PRIM-005) -- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006)(0032-SP-PRIM-006) -- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007)(0032-SP-PRIM-007) -- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008)(0032-SP-PRIM-008) -- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009)(0032-SP-PRIM-009) -- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010)(0032-SP-PRIM-010) -- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011)(0032-SP-PRIM-011) -- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012)(0032-SP-PRIM-012) -- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013)(0032-SP-PRIM-013) -- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014)(0032-SP-PRIM-014) -- Specifying a non-positive horizon results in an error. (0032-PRIM-015)(0032-SP-PRIM-015) -- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016)(0032-SP-PRIM-016) -- Specifying a non-positive auction extension results in an error. (0032-PRIM-017)(0032-PRIM-017) +(0032-PRIM-003) for product spot: (0032-PRIM-023) +- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005) for product spot: (0032-PRIM-024) +- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006) for product spot: (0032-PRIM-025) +- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007) for product spot: (0032-PRIM-026) +- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008) for product spot: (0032-PRIM-027) +- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009) for product spot: (0032-PRIM-028) +- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010) for product spot: (0032-PRIM-029) +- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011) for product spot: (0032-PRIM-030) +- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012) for product spot: (0032-PRIM-031) +- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013) for product spot: (0032-PRIM-032) +- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014) for product spot: (0032-PRIM-033) +- Specifying a non-positive horizon results in an error. (0032-PRIM-015) for product spot: (0032-PRIM-034) +- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016) for product spot: (0032-PRIM-035) +- Specifying a non-positive auction extension results in an error. (0032-PRIM-017) for product spot: (0032-PRIM-036) - Settlement price outside the current price monitoring bounds does not trigger an auction (0032-PRIM-018) - A network trade (during closeout) with a price outside price monitoring bounds does not trigger an auction. (0032-PRIM-019) -- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020)(0032-SP-PRIM-020) -- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021)(0032-SP-PRIM-021) +- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020) for product spot: (0032-PRIM-037) +- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021) for product spot: (0032-PRIM-038) diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index 324e01aa9..0dddb6ce9 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -2,15 +2,15 @@ ## Acceptance Criteria -- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001)(0033-SP-OCAN-001) -- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002)(0033-SP-OCAN-002) -- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003)(0033-SP-OCAN-003) -- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004)(0033-SP-OCAN-004) -- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005)(0033-SP-OCAN-005) +- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001) for product spot: (0033-OCAN-011) +- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002) for product spot: (0033-OCAN-012) +- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003) for product spot: (0033-OCAN-013) +- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004) for product spot: (0033-OCAN-014) +- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005) for product spot: (0033-OCAN-015) - Margins must be recalculated after a cancel event (0033-OCAN-007) - An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008) -- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009)(0033-SP-OCAN-009) -- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010)(0033-SP-OCAN-010) +- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009) for product spot: (0033-OCAN-016) +- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010) for product spot: (0033-OCAN-017) ## Summary @@ -86,4 +86,3 @@ Cancelling an order triggers a margin recalculation for a party. This is true fo - Insert a single order from 2 different traders and cancel one via `partyID` - Insert a single order from 2 different traders and cancel one via `marketID+partyID` and `MarketID` - Insert an order which is not for auction and enter into an auction to force the order to be parked. Cancel the order using all three methods and validate the order is cancelled. - diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index b0060e382..d429e034a 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -88,11 +88,11 @@ "\n", "Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) The feature test has covered following scenarios:\n", "\n", - "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001)(0034-SP-PROB-001);\n", + "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001) for product spot: (0034-PROB-007);\n", "\n", - "2. Probability of trading decreases away from the mid-price (0034-PROB-005)(0034-SP-PROB-005).\n", + "2. Probability of trading decreases away from the mid-price (0034-PROB-005) for product spot: (0034-PROB-008).\n", "\n", - "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006)(0034-SP-PROB-006).\n", + "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006) for product spot: (0034-PROB-009).\n", "\n", "\n", "\n" diff --git a/protocol/0036-BRIE-event_queue.md b/protocol/0036-BRIE-event_queue.md index b9b828911..d7211c7be 100644 --- a/protocol/0036-BRIE-event_queue.md +++ b/protocol/0036-BRIE-event_queue.md @@ -164,17 +164,17 @@ message NodeVote { ## Acceptance Criteria -- A valid event is processed by vega (0036-BRIE-001)(0036-SP-BBRIE-001) +- A valid event is processed by vega (0036-BRIE-001) for product spot: (0036-BBRIE-004) - A transaction is successfully executed on the bridge (e.g deposit) - A validator node successfully source the event and emit a chain event transaction on the vega chain - The others validators successfully validates the event on the ethereum chain and send a node vote on chain - The required amount of node votes, weighted by validator score is received - The processing of the event have effect on the network (e.g: for a deposit funds are deposited on an account) -- A valid duplicated event is processed (0036-BRIE-002)(0036-SP-BBRIE-002) +- A valid duplicated event is processed (0036-BRIE-002) for product spot: (0036-BRIE-005) - A transaction is successfully executed on the bridge (e.g deposit) and successfully processed by vega - A node sends again the chain event after sourcing it - The nodes reject this event as duplicated, nothing else happens -- A invalid event is processed (0036-BRIE-003)(0036-SP-BBRIE-003) +- A invalid event is processed (0036-BRIE-003) for product spot: (0036-BRIE-006) - A malicious node sends a chain event for a non existing transaction on the bridge - The node start validating this event on chain, but cannot find it - After a given delay this chain event is rejected, no node votes are being sent by the validators diff --git a/protocol/0039-MKTD-market_depth_calculation.md b/protocol/0039-MKTD-market_depth_calculation.md index 9dcfceb58..9e7d3b327 100644 --- a/protocol/0039-MKTD-market_depth_calculation.md +++ b/protocol/0039-MKTD-market_depth_calculation.md @@ -2,21 +2,21 @@ ## Acceptance Criteria -- The market depth builder must be able to handle all available order types (0039-MKTD-001)(0039-SP-MKTD-001) -- Entering and leaving auctions must be handled correctly (0039-MKTD-003)(0039-SP-MKTD-003) -- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004)(0039-SP-MKTD-004) -- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005)(0039-SP-MKTD-005) -- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006)(0039-SP-MKTD-006) -- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007)(0039-SP-MKTD-007) -- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008)(0039-SP-MKTD-008) -- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009)(0039-SP-MKTD-009) -- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010)(0039-SP-MKTD-010) -- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012)(0039-SP-MKTD-012) -- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013)(0039-SP-MKTD-013) -- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014)(0039-SP-MKTD-014) +- The market depth builder must be able to handle all available order types (0039-MKTD-001) for product spot: (0039-MKTD-020) +- Entering and leaving auctions must be handled correctly (0039-MKTD-003) for product spot: (0039-MKTD-021) +- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004) for product spot: (0039-MKTD-022) +- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005) for product spot: (0039-MKTD-023) +- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006) for product spot: (0039-MKTD-0024) +- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007) for product spot: (0039-MKTD-025) +- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008) for product spot: (0039-MKTD-026) +- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009) for product spot: (0039-MKTD-027) +- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010) for product spot: (0039-MKTD-028) +- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012) for product spot: (0039-MKTD-029) +- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013) for product spot: (0039-MKTD-030) +- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014) for product spot: (0039-MKTD-030) - Pegged orders are part of the market depth view and should update the view when their orders are repriced (0039-MKTD-015) -- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018)(0039-SP-MKTD-018) -- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019)(0039-SP-MKTD-019) +- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018) for product spot: (0039-MKTD-031) +- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019) for product spot: (0039-MKTD-032) ## Summary diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 82156dc15..788dbf431 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -242,7 +242,9 @@ After `market.liquidity.successorLaunchWindowLength` has elapsed since the settl ## Acceptance Criteria -### Market is proposed but rejected (0043-MKTL-001)(0043-SP-MKTL-001) +### Market is proposed but rejected (0043-MKTL-001) + +also for for product spot: (0043-MKTL-005) 1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. @@ -284,7 +286,7 @@ Margin account balances are transferred to the general account. The market state is `settled`. After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. -### Lifecycle happy path in Spot market (0043-SP-MKTL-002) +### Lifecycle happy path in Spot market (0043-MKTL-006) 1. Market `m1` is proposed. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. @@ -309,7 +311,7 @@ The market state is `active`. 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. -### Market (Spot) never leaves opening auction, market cancelled by governance proposal(0043-SP-MKTL-003) +### Market (Spot) never leaves opening auction, market cancelled by governance proposal(0043-MKTL-007) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). 1. Market cancelled before the market leaves the opening auction (so market never left Pending state so far). @@ -327,7 +329,7 @@ The market state is `active`. 1. All the funds from market specific accounts get released to appropriate accounts; the insurance pool perhaps after the delay to allow for transfer into a successor market. 1. Market gets deleted. -### Market (Spot) gets closed via a governance proposal (0043-SP-MKTL-004) +### Market (Spot) gets closed via a governance proposal (0043-MKTL-008) 1. Once the governance proposal to close the market gets enacted any auction that the market may be in gets uncrossed and trades get generated. 1. All the other orders are cancelled and no further trades get generated. diff --git a/protocol/0049-TVAL-validate_transaction_preconsensus.md b/protocol/0049-TVAL-validate_transaction_preconsensus.md index 1038bb970..78cd8050e 100644 --- a/protocol/0049-TVAL-validate_transaction_preconsensus.md +++ b/protocol/0049-TVAL-validate_transaction_preconsensus.md @@ -28,9 +28,9 @@ Future enhancements: for each root transaction message type (e.g. `SubmitOrder`, Note that separate pre-consensus validation is carried out as part of PoW anti-spam checks, see the acceptance criteria in [PoW spec](./0072-SPPW-spam-protection-PoW.md). -1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001)(0049-SP-TVAL-001) -1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002)(0049-SP-TVAL-002) -1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-COSMICELEVATOR-003)(0049-SP-COSMICELEVATOR-003) -1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-COSMICELEVATOR-004)(0049-SP-COSMICELEVATOR-004) -1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-COSMICELEVATOR-005)(0049-SP-COSMICELEVATOR-005) -1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006)(0049-SP-TVAL-006) +1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001) for product spot: (0049-TVAL-007) +1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002) for product spot: (0049-TVAL-008) +1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-TVAL-003) for product spot: (0049TVAL-009) +1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-TVAL-004) for product spot: (0049-TVAL-010) +1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-TVAL-005) for product spot: (0049-TVAL-011) +1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006) for product spot: (0049-TVAL-012) diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index a3371b421..da1cd540a 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -119,12 +119,12 @@ APIS should be available to: Settlement assets: -- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001)(0051-SP-PPROD-001) -- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002)(0051-SP-PPROD-002) +- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001) for product spot: (0051-PROD-004) +- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002) for product spot: (0051-PROD-005) Product updates via governance: -- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003)(0051-SP-PPROD-003) +- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003) for product spot: (0051-PROD-006) ## See also diff --git a/protocol/0052-FPOS-fractional_orders_positions.md b/protocol/0052-FPOS-fractional_orders_positions.md index 089c393d5..14eb674a4 100644 --- a/protocol/0052-FPOS-fractional_orders_positions.md +++ b/protocol/0052-FPOS-fractional_orders_positions.md @@ -20,8 +20,8 @@ Specs affected by this change (Note: in many cases the implementation may not ch ## Acceptance Criteria -- All proposed markets will have a decimal places property available via the API (0052-FPOS-001)(0052-SP-FPOS-001) -- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002)(0052-SP-FPOS-002) +- All proposed markets will have a decimal places property available via the API (0052-FPOS-001) for product spot: (0052-FPOS-003) +- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002) for product spot: (0052-FPOS-004) - Fees are calculated as per ([0029-FEES-013](./0029-FEES-fees.md#0029-FEES-013)) - LP order volume is implied correctly using fractional volume amounts as per ([0038-OLIQ-006](./0038-OLIQ-liquidity_provision_order_type.md#0038-OLIQ-006)) - Mark-to-market settlement happens correctly with PDP > 0 ([0003-MTMK-0015](./0003-MTMK-mark_to_market_settlement.md#0003-MTMK-015)) diff --git a/protocol/0054-NETP-network_parameters.md b/protocol/0054-NETP-network_parameters.md index c7960f7df..742cebfe5 100644 --- a/protocol/0054-NETP-network_parameters.md +++ b/protocol/0054-NETP-network_parameters.md @@ -91,9 +91,9 @@ The current network parameters are specified in the code specifiying the min and ## Acceptance criteria -- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001)(0054-SP-NETP-001) -- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002)(0054-SP-NETP-002) +- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001) for product spot: (0054-NETP-007) +- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002) for product spot: (0054-NETP-008) - For `market.margin.scalingFactors` set in `genesis.json` or in a governance proposal we validate the format and the fact that "1.0 <= search <= initial <= release"; if these are invalid a useful error is returned. (0054-NETP-003) -- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004)(0054-SP-NETP-004) -- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005)(0054-SP-NETP-005) -- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006)(0054-SP-NETP-006) +- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004) for product spot: (0054-NETP-009) +- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005) for product spot: (0054-NETP-010) +- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006)for product spot: (0054-NETP-011) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index ec2d5f603..67d7d2d95 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -194,7 +194,7 @@ message CancelTransfer { - As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005) - As a user I cannot transfer funds from accounts I own but from the type is not supported: - for accounts created in a futures market, bond and margin (0057-TRAN-006) - - for accounts created in a spot market, bond and holding (0057-SP-TRAN-006) + - for accounts created in a spot market, bond and holding (0057-TRAN-063) - As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007) - The fee cost is correctly calculated using the network parameter - If I have enough funds to pay transfer and fees, the transfer happens. diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index 2186cbeed..83c443371 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -84,7 +84,7 @@ This section outlines floating-point quantities `vega` currently relies on: ## Acceptance criteria -1. Floating-point values get initialised and updated correctly (0065-FTCO-001)(0065-SP-FTCO-001) +1. Floating-point values get initialised and updated correctly (0065-FTCO-001) for product spot: (0065-FTCO-005) - A market is proposed and initially it has the following default values: - Risk factors: - Short: 1.0 @@ -100,12 +100,12 @@ This section outlines floating-point quantities `vega` currently relies on: - When the time-based trigger elapses price monitoring bounds and probability of trading get recalculated. - When the market goes into liquidity monitoring auction the state variables stay the same as prior to its' start, when that auction concludes (choose a price that's not been traded at before) price monitoring bounds and probability of trading get recalculated again and the time-based trigger countdown gets reset. -1. Event announcing diverging values gets emitted (0065-FTCO-004)(0065-SP-FTCO-004) +1. Event announcing diverging values gets emitted (0065-FTCO-004) for product spot: (0065-FTCO-006) - For all the state variables nodes submit candidate values that differ by up to half the tolerance. - The event announcing the fact that at least one of the values differed gets emitted. - Since differences are within tolerance the consensus successfully chooses a consensus value and systems keeps running as expected (market goes into continuous trading mode accepts orders and generates trades). -1. Consensus failure event gets emitted (0065-FTCO-002)(0065-SP-FTCO-002) +1. Consensus failure event gets emitted (0065-FTCO-002) for product spot: (0065-FTCO-007) - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get submitted by nodes, one of the nodes submits a value that is higher than tolerance. - An appropriate event is sent to signal that at least one of the values differed. @@ -115,7 +115,7 @@ This section outlines floating-point quantities `vega` currently relies on: - Situation continues for 2 more risk factor update attempts (can be time-based or auction). - Market still runs with previously calculated risk factors, but an event informing that the market is using stale values gets emitted. -1. Market cannot leave opening auction with default values (0065-FTCO-003)(0065-SP-FTCO-003) +1. Market cannot leave opening auction with default values (0065-FTCO-003) for product spot: (0065-FTCO-008) - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get calculated (their values change from defaults). - When the opening auction sees uncrossing price for the first time (there are two overlapping orders from buy and sell side on the order book) price monitoring bounds get calculated, but probability of trading get doesn't pass consensus (all nodes submit conflicting values) diff --git a/protocol/0066-VALW-validator_tendermint_weights.md b/protocol/0066-VALW-validator_tendermint_weights.md index c48207e58..29b3fc1b3 100644 --- a/protocol/0066-VALW-validator_tendermint_weights.md +++ b/protocol/0066-VALW-validator_tendermint_weights.md @@ -51,7 +51,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2419\ - Node 5 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' ``n_voting_power``=2741 -### Changes to delegation during the epoch are reflected in the next epoch’s voting power (0066-SP-VALW-004) +### Changes to delegation during the epoch are reflected in the next epoch’s voting power (0066-VALW-004) 1. set up a network with 5 validators 1. give the first `4` validators `1000` of self-stake each. Give the last validator `0`. @@ -71,7 +71,7 @@ If the network has no stake at all, then all validators would have equal voting - Node 4 n[`stakedByOperator`]='1000000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=2564\ - Node 5 n[`stakedByOperator`]='500000000000000000000' n[`stakedByDelegates`]='0' `n_voting_power`=64 -### Sanity check if everyone unstakes and undelegates (0066-SP-VALW-005) +### Sanity check if everyone unstakes and undelegates (0066-VALW-005) 1. set up a network with 5 validators 1. give each of the validators the following number of self-staked tokens: `2000` diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 0f47d778f..825b46693 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -8,13 +8,13 @@ The matching engine co-ordinates the trading of incoming orders with existing or An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001)(0068-SP-MATC-001) - - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002)(0068-SP-MATC-002) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003)(0068-SP-MATC-003) - - If there is no match the order will be cancelled. (0068-MATC-004)(0068-SP-MATC-004) - - If there is a partial match then the remaining will be cancelled. (0068-MATC-005)(0068-SP-MATC-005) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001) for product spot: (0068-MATC-061) + - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002) for product spot: (0068-MATC-062) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003) for product spot: (0068-MATC-063) + - If there is no match the order will be cancelled. (0068-MATC-004) for product spot: (0068-MATC-064) + - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) for product spot: (0068-MATC-065) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057)(0068-SP-MATC-057) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057) for product spot: (0068-MATC-066) - For Reduce-Only = True orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-056) @@ -27,12 +27,12 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008)(0068-SP-MATC-008) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008) for product spot: (0068-MATC-067) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will either be: - - Fully matched if possible to the other side of the book (0068-MATC-009)(0068-SP-MATC-009) - - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010)(0068-SP-MATC-010) + - Fully matched if possible to the other side of the book (0068-MATC-009) for product spot: (0068-MATC-068) + - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) for product spot: (0068-MATC-069) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039)(0068-SP-MATC-039) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039) for product spot: (0068-MATC-070) - For Reduce-Only = TRUE orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) @@ -45,48 +45,48 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013)(0068-SP-MATC-013) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014)(0068-SP-MATC-014) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013) for product spot: (0068-MATC-071) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014) for product spot: (0068-MATC-072) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced and placed on the book if the price is valid, except GFN which are rejected by the wallet validation layer. (0068-MATC-015) - otherwise they are parked. (0068-MATC-016) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040)(0068-SP-MATC-040) - - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041)(0068-SP-MATC-041) - - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042)(0068-SP-MATC-042) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040) for product spot: (0068-MATC-073) + - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041) for product spot: (0068-MATC-074) + - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042) for product spot: (0068-MATC-075) - A market will enter auction if the volume on either side of the book is empty. (0068-MATC-017) -- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018)(0068-SP-MATC-018) -- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019)(0068-SP-MATC-019) +- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018) for product spot: (0068-MATC-076) +- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019) for product spot: (0068-MATC-077) - All orders with Reduce-Only set to TRUE are rejected as invalid. (0068-MATC-054) In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): - [IOC/FOK/GFN](./0014-ORDT-order_types.md#time-in-force--validity) - - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021)(0068-SP-MATC-021) + - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021) for product spot: (0068-MATC-078) - [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022)(0068-SP-MATC-022) - - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023)(0068-SP-MATC-023) - - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055)(0068-SP-MATC-055) - - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024)(0068-SP-MATC-024) + - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022) for product spot: (0068-MATC-079) + - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023) for product spot: (0068-MATC-080) + - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055) for product spot: (0068-MATC-081) + - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) for product spot: (0068-MATC-082) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are parked (and have their status set to PARKED). (0068-MATC-025) - - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038)(0068-SP-MATC-038) + - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038) for product spot: (0068-MATC-083) When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): - All [PEGGED](./0014-ORDT-order_types.md#auction) orders are parked (and have their status set to PARKED). (0068-MATC-026) -- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027)(0068SP--MATC-027) -- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028)(0068-SP-MATC-028) +- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) for product spot: (0068-MATC-084) +- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) for product spot: (0068-MATC-085) When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auction-mode): -- The book is uncrossed. (0068-MATC-029)(0068-SP-MATC-029) - - Self trading is allowed during uncrossing. (0068-MATC-030)(0068-SP-MATC-030) -- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031)(0068-SP-MATC-031) +- The book is uncrossed. (0068-MATC-029) for product spot: (0068-MATC-086) + - Self trading is allowed during uncrossing. (0068-MATC-030) for product spot: (0068-MATC-087) +- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) for product spot: (0068-MATC-088) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced where possible. (0068-MATC-032) -- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033)(0068-SP-MATC-033) -- The price of any persistent order can be updated (0068-MATC-034)(0068-SP-MATC-034) -- The size of any persistent order can be updated (0068-MATC-035)(0068-SP-MATC-035) -- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036)(0068-SP-MATC-036) -- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037)(0068-SP-MATC-037) +- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033) for product spot: (0068-MATC-060) +- The price of any persistent order can be updated (0068-MATC-034) for product spot: (0068-MATC-089) +- The size of any persistent order can be updated (0068-MATC-035) for product spot: (0068-MATC-090) +- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036) for product spot: (0068-MATC-090) +- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037) for product spot: (0068-MATC-091) ## Summary diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 76d4981ed..c11c2e571 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -161,7 +161,9 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). ## Acceptance criteria -### Joining / leaving VEGA chain (0069-VCBS-001)(0069-SP-VCBS-001) +### Joining / leaving VEGA chain (0069-VCBS-001) + +for product spot: (0069-VCBS-089) 1. A running Vega node which isn't a "pending" or "ersatz" or "validator" node already can submit a transaction to become a validator. 2. Their performance score will be calculated. See [performance score](./0064-VALP-validator_performance_based_rewards.md). @@ -174,20 +176,20 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). **Setup a network for each test** with 5 Tendermint validators and 2 ersatz validators. Verify the value of the min.validators network parameter is 5. Delegate 1000 tokens to each Tendermint validator and 500 to each ersatz validator (where minimum is defined as 500). Transfer 1000 tokens to the reward account. The test assumes that the validators are already in their state (i.e. 5 are Tendermint, 2 are ersatz). -1. Base case for Tendermint validators (0069-VCBS-005)(0069-SP-VCBS-005): +1. Base case for Tendermint validators (0069-VCBS-005) for product spot: (0069-VCBS-090): - Verify that the `stakeScore` for each of the Tendermint validators is 0.2 -1. Base case for ersatz validators (0069-VCBS-006)(0069-SP-VCBS-006): +1. Base case for ersatz validators (0069-VCBS-006) for product spot: (0069-VCBS-091): - Verify that the `stakeScore` for each of the ersatz validator is 0.5 -1. No antiwhaling for ersatz `stakeScore` (0069-VCBS-007)(0069-SP-VCBS-007): +1. No antiwhaling for ersatz `stakeScore` (0069-VCBS-007) for product spot: (0069-VCBS-092): - Delegate to one of the ersatz validators 4000 more tokens. - Run for an epoch with the new delegation (i.e. one ersatz with 500 one with 4500) and transfer 1000 tokens to the reward account. - Verify that at the end of the epoch the stake score of the validator with 4500 tokens is 0.9 and the one with 500 tokens is 0.1 -1. Antiwhaling for Tendermint validators (0069-VCBS-008)(0069-SP-VCBS-008): +1. Antiwhaling for Tendermint validators (0069-VCBS-008) for product spot: (0069-VCBS-093): - **Additional setup:** in addition to the 1000 delegated for each node, delegate 500 more to node 1. - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.competitionLevel` is set to 1 - Once it becomes active let it run for a full epoch during which transfer 1000 tokens to the reward account. - Verify that at the end of the epoch node 1 should have a stake score of 0.2 where all other nodes get stake score of 0.1818181818 -1. Full antiwhaling for Tendermint validators (0069-VCBS-009)(0069-SP-VCBS-009): +1. Full antiwhaling for Tendermint validators (0069-VCBS-009) for product spot: (0069-VCBS-094): - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.optimalStakeMultiplier` is set to 3 - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.competitionLevel` is set to 1 - **Additional setup:** in addition to the 1000 tokens delegated to each node, delegate 10000 tokens to node1 to get a total delegation of 11000 to it. @@ -196,20 +198,20 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). #### Multisig score -1. Verify that for all ersatz validators their multisig score is 1 (0069-VCBS-010)(0069-SP-VCBS-010) -1. Tendermint validators excess signature (0069-VCBS-011)(0069-SP-VCBS-011): +1. Verify that for all ersatz validators their multisig score is 1 (0069-VCBS-010) for product spot: (0069-VCBS-095) +1. Tendermint validators excess signature (0069-VCBS-011) for product spot: (0069-VCBS-096): - Setup a network with 5 Tendermint validators but with only 4 validators that have sufficient self-delegation. Call the one without enough self-delegation Bob. - Announce a new node (Alice) and self-delegate to them, allow some time to replace the validator with no self-delegation (Bob) as a Tendermint validator by Alice. Note: At this point the signature of Bob IS still on the multisig contract. - Transfer 1000 tokens to the VEGA reward account. - Verify that at the end of the epoch all of the Tendermint validators should have a multisig score = 0 since Bob is still on the contract. -1. Tendermint validators missing signature test 1 (0069-VCBS-012)(0069-SP-VCBS-012): +1. Tendermint validators missing signature test 1 (0069-VCBS-012) for product spot: (0069-VCBS-097): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners` is set to **5**. - Announce a new node and self-delegate to it 1000 tokens. - Allow some time for the performance score to be greater than 0. Note: When this happens the validator will be promoted to Tendermint validator at the beginning of the following epoch. - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Verify that the joining validator has a multisig score of 0 and therefore would not get a reward. -1. Tendermint validators missing signature test 2 (0069-VCBS-013)(0069-SP-VCBS-013): +1. Tendermint validators missing signature test 2 (0069-VCBS-013) for product spot: (0069-VCBS-098): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners` is set to 4. - Announce a new node and self-delegate to it 10000 tokens. @@ -217,7 +219,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Assert that the new validator has a score (stake score x performance score) in the top 4 - this can be verified in data node with: `rewardScore.stakeScore` x `rewardScore.performanceScore`. - Verify that the joining validator would have a multisig score of 0 and therefore would not get a reward. -1. Tendermint validators missing signature test 3 (0069-VCBS-050)(0069-SP-VCBS-050): +1. Tendermint validators missing signature test 3 (0069-VCBS-050) for product spot: (0069-VCBS-099): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners`is set to 4. - Delegate 10000 to the existing validators (can be self or party delegation) @@ -227,50 +229,50 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Assert that the new validator has a score (stake score x performance score) **NOT** in the top 4 - this can be verified in data node with: `rewardScore.stakeScore` x `rewardScore.performanceScore`. - Verify that the joining validator would have a multisig score of 1 and therefore gets a reward. -1. One of the top validators is not registered with the multisig contract (0069-VCBS-051)(0069-SP-VCBS-051): +1. One of the top validators is not registered with the multisig contract (0069-VCBS-051) for product spot: (0069-VCBS-100): - Run a Vega network where a validator joins and gets a lot delegated in order for it to become one of the top `network.validators.multisig.numberOfSigners` - Ensure its ethereum key is **NOT** put on the multisig contract. - Verify the validator has 0 for their multisig score and receives no staking reward. #### Validator Score -1. Verify that the validator score is always equal to the `stakeScore` x `perfScore` x `multisigScore` when the validator is a Tendermint validator (0069-VCBS-014)(0069-SP-VCBS-014) -2. Verify that the validator score is always equal to the `stakeScore` x `perfScore` when the validator is an ersatz validator (0069-VCBS-015)(0069-SP-VCBS-015) +1. Verify that the validator score is always equal to the `stakeScore` x `perfScore` x `multisigScore` when the validator is a Tendermint validator (0069-VCBS-014) for product spot: (0069-VCBS-101) +2. Verify that the validator score is always equal to the `stakeScore` x `perfScore` when the validator is an ersatz validator (0069-VCBS-015) for product spot: (0069-VCBS-102) #### Normalised Score -1. The sum of normalised scores must always equal 1 (0069-VCBS-016)(0069-SP-VCBS-016) -2. The normalised score for validator i must equal `validatorScore_{i}` / `total_validator_score`. Note: the total validator score is calculated over the relevant set separately (i.e. Tendermint and ersatz) (0069-VCBS-017)(0069-SP-VCBS-017) +1. The sum of normalised scores must always equal 1 (0069-VCBS-016) for product spot: (0069-VCBS-103) +2. The normalised score for validator i must equal `validatorScore_{i}` / `total_validator_score`. Note: the total validator score is calculated over the relevant set separately (i.e. Tendermint and ersatz) (0069-VCBS-017) for product spot: (0069-VCBS-104) ### Rewards split between tendermint and ersatz validators -1. Base scenario (0069-VCBS-018)(0069-SP-VCBS-018): +1. Base scenario (0069-VCBS-018) for product spot: (0069-VCBS-105): - There are no ersatz validators in the network. - Verify that, regardless of `ersatzRewardFactor` value, all rewards are being paid out to the validators as expected given the reward scores. -1. Ersatz validators where ersatz reward factor equals 0 (0069-VCBS-019)(0069-SP-VCBS-019): +1. Ersatz validators where ersatz reward factor equals 0 (0069-VCBS-019) for product spot: (0069-VCBS-106): - Ensure that the `ersatzRewardFactor` is set to 0 - Setup an ersatz validator with delegation greater than the minimum. The delegation can be equal to the delegation of the other Tendermint validators - Verify the ersatz validators and their delegators get no rewards. -1. Ersatz validators where reward factor equals 1 (0069-VCBS-020)(0069-SP-VCBS-020): +1. Ersatz validators where reward factor equals 1 (0069-VCBS-020) for product spot: (0069-VCBS-107): - Setup an ersatz validator with self and party delegation making them eligible for reward for a whole epoch. For example, such that the total delegation to each node is 1000 Vega. (3 Tendermint validators, 1 ersatz validator all having a delegation of 1000 Vega). - Make sure there is balance of 1000 Vega in the reward pool account for the epoch. - Verify the reward pool is distributed equally between the validators. -1. Ersatz validators where reward factor equals 0.5 (0069-VCBS-021)(0069-SP-VCBS-021): +1. Ersatz validators where reward factor equals 0.5 (0069-VCBS-021) for product spot: (0069-VCBS-108): - Setup an ersatz validator with self and party delegation making them eligible for reward for a whole epoch. For example, such that the total delegation to each node is 1000 Vega. (3 tendermint validators, 1 ersatz validator all having a delegation of 1000 Vega). - Make sure there is balance of 3500 Vega in the reward account for the epoch. - Verify that 3000 is distributed between the Tendermint validators and 500 is rewarded to the ersatz validator. -1. Multiple ersatz validators, reward factor equals 0.5 (0069-VCBS-022)(0069-SP-VCBS-022): +1. Multiple ersatz validators, reward factor equals 0.5 (0069-VCBS-022) for product spot: (0069-VCBS-109): - Setup a network with 3 ersatz validators, 3 Tendermint validators with arbitrary delegation, but ensuring the total delegation for each validator is greater than the minimum self-delegation. - With `total_delegations_from_all_validators = (0.5 * total_delegation_from_ersatz_validators) + total_delegation_from_tendermint_validators` - Verify the total reward given to Tendermint validators is equal to the `total_delegation_from_tendermint_validators * reward_balance` / `total_delegation_from_all_validators`. - Verify the total reward given to ersatz validators is equal to the `total_delegation_from_ersatz_validators * 0.5 * reward_balance / total_delegation_from_all_validators`. -1. Pending validators get nothing (0069-VCBS-023)(0069-SP-VCBS-023): +1. Pending validators get nothing (0069-VCBS-023) for product spot: (0069-VCBS-110): - Setup a network with 5 tendermint validators, set number of ersatz validators (through network parameter) to 0. - Delegate to each node 1000 tokens (including self-delegation). - Announce 2 new nodes, verify that they are in pending state, delegate to them 1000 tokens each. - Run the network for a full epoch with the delegation, during which transfer 1000 tokens to the reward account. - Verify that, at the end of the epoch, none of the pending validators receive a reward. -1. Pending validators do not get promoted (0069-VCBS-024)(0069-SP-VCBS-024): +1. Pending validators do not get promoted (0069-VCBS-024) for product spot: (0069-VCBS-111): - Setup a network with 5 tendermint validators, 2 ersatz validators and set number of ersatz validators (through factor) to 2. - Delegate to each node 1000 tokens (including self-delegation). - Announce 2 new nodes, verify that they are in pending state, delegate to them 1000 tokens each. @@ -281,47 +283,47 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). #### General -1. Verify that at the beginning of epoch an event is emitted for every validator known to Vega with their respective ranking scores. (0069-VCBS-025)(0069-SP-VCBS-025) -1. Verify the ranking score is available through the epoch/validator/`rankingScore` API in the data-node. (0069-VCBS-026)(0069-SP-VCBS-026) -1. Verify that the `rankingScore` is always equal to `performanceScore` x `stakeScore` x `incumbentBonus` (for tendermint validators and ersatz validators) Note: `network.validators.incumbentBonus` is a network parameter that is applied as a factor (1 + `incumbentBonus` network parameter) on `performanceScore` x `stakeScore`. (0069-VCBS-027)(0069-SP-VCBS-027) -1. Verify that if a node has a 0 `rankingScore` for 1e6 blocks (corresponding to around 11.5 days) it gets removed from the network and will have to be re-announced. (0069-VCBS-028)(0069-SP-VCBS-028) +1. Verify that at the beginning of epoch an event is emitted for every validator known to Vega with their respective ranking scores. (0069-VCBS-025) for product spot: (0069-VCBS-112) +1. Verify the ranking score is available through the epoch/validator/`rankingScore` API in the data-node. (0069-VCBS-026) for product spot: (0069-VCBS-113) +1. Verify that the `rankingScore` is always equal to `performanceScore` x `stakeScore` x `incumbentBonus` (for tendermint validators and ersatz validators) Note: `network.validators.incumbentBonus` is a network parameter that is applied as a factor (1 + `incumbentBonus` network parameter) on `performanceScore` x `stakeScore`. (0069-VCBS-027) for product spot: (0069-VCBS-114) +1. Verify that if a node has a 0 `rankingScore` for 1e6 blocks (corresponding to around 11.5 days) it gets removed from the network and will have to be re-announced. (0069-VCBS-028) for product spot: (0069-VCBS-115) ### Stake scores -1. No stake (0069-VCBS-029)(0069-SP-VCBS-029): +1. No stake (0069-VCBS-029) for product spot: (0069-VCBS-116): - Setup a network with 5 validators with no delegation - Verify that the `stakeScore` for all of validators is 0 -1. Equal stake (0069-VCBS-030)(0069-SP-VCBS-030): +1. Equal stake (0069-VCBS-030) for product spot: (0069-VCBS-117): - Setup a network with 5 validators, delegate to each of validator an equal stake - Verify that the `stakeScore` of each of them is 0.2. -1. Stake change (0069-VCBS-031)(0069-SP-VCBS-031): +1. Stake change (0069-VCBS-031) for product spot: (0069-VCBS-118): - Setup a network with 5 validators with 1000 tokens delegated to each. - Verify `stakeScore` at the end of the epoch is 0.2. - Change the stake of each validator by adding 100 * the index of the validator (i=1..5). - Verify that at the end of the epoch the `stakeScore` of each validator equals (1000 + i * 100)/5500 -1. Stake change 2 (0069-VCBS-032)(0069-SP-VCBS-032): +1. Stake change 2 (0069-VCBS-032) for product spot: (0069-VCBS-119): - Setup a network with 5 validators with 1000 tokens delegated to each - Undelegate from one validator 1000 tokens. - Verify that, at the end of the epoch, each of the 4 validators with tokens still delegated has a `stakeScore` of 0.25 and the validator with no tokens delegated has a 0 `stakeScore`. -1. Node joining (0069-VCBS-033)(0069-SP-VCBS-033): +1. Node joining (0069-VCBS-033) for product spot: (0069-VCBS-120): - Setup a network with 4 validators, each with 1000 tokens delegated. - Announce a new node and delegate it 1000 tokens - Verify that the `stakeScore` of all nodes is 0.2 at the beginning of the next epoch. Note: for the first 4 validators this is changing from 0.25 in the previous epoch to 0.2 in the next. ## Promotions/Demotions -1. Announce node (0069-VCBS-034)(0069-SP-VCBS-034): +1. Announce node (0069-VCBS-034) for product spot: (0069-VCBS-121): - Verify that a node node, once added successfully to the topology, is shown on data-node API with the status pending -1. Promote a node to become an ersatz validator (0069-VCBS-035)(0069-SP-VCBS-035): +1. Promote a node to become an ersatz validator (0069-VCBS-035) for product spot: (0069-VCBS-122): - Set up a network with no existing ersatz validators - Ensure that the number of ersatz validators allowed in the network is is greater than 0 using the network parameter `network.validators.ersatz.multipleOfTendermintValidators` - Announce a new node on the network - Verify the new node gets promoted to an ersatz validator Note: ensure there are no available slots for Tendermint validators so the new node doesn’t get promoted directly to become a Tendermint validator. -1. Demote a Tendermint validator due to lack of slots (0069-VCBS-036)(0069-SP-VCBS-036): +1. Demote a Tendermint validator due to lack of slots (0069-VCBS-036) for product spot: (0069-VCBS-123): - Setup a network with 4 Tendermint validators - Change the network parameter `network.validators.tendermint.number` to 3 Tendermint validators - Verify that the Tendermint validator with the lowest score is demoted to an ersatz validator at the beginning of the next epoch -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-062)(0069-SP-VCBS-062): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-062) for product spot: (0069-VCBS-124): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. @@ -332,20 +334,20 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that exactly one consensus forming validator with the lowest score is demoted to an ersatz validator at the beginning of the following epoch and we are running with 4 consensus (Tendermint) validators. - Ensure that the multisig is updated to those 4 validators. - Finally verify that exactly one consensus forming validator with the lowest score is demoted to an ersatz validator at the beginning of the following epoch and we are running with 3 consensus (Tendermint) validators. -1. Try to demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-063)(0069-SP-VCBS-063): +1. Try to demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-063) for product spot: (0069-VCBS-125): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. - Ensure that the threshold on the multisig is set to `900`. - Change the network parameter `network.validators.tendermint.number` to 3 Tendermint validators. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 6 consensus (Tendermint) validators. -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-064)(0069SP--VCBS-064): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-064) for product spot: (0069-VCBS-126): - Setup a network with 3 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 3 validators. - Ensure that the threshold on the multisig is set to `666`. - Change the network parameter `network.validators.tendermint.number` to 2 Tendermint validators. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 3 consensus (Tendermint) validators. -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-065)(0069-SP-VCBS-065): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-065) for product spot: (0069-VCBS-127): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. @@ -356,28 +358,28 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that exactly one consensus forming validator with the lowest score is demoted to an ersatz validator at the beginning of the following epoch and we are running with 4 consensus (Tendermint) validators. - Ensure that the multisig is *not* updated to those 4 validators, but we have the 5 validators from previous step. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 4 consensus (Tendermint) validators. -1. Demote an ersatz validator due to lack of slots (0069-VCBS-037)(0069-SP-VCBS-037): +1. Demote an ersatz validator due to lack of slots (0069-VCBS-037) for product spot: (0069-VCBS-128): - Setup a network with 4 tendermint validators, and 2 ersatz validators. - Change the ersatz network parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.25 of the Tendermint validators - Verify that the ersatz validator with the lowest score is demoted to pending at the beginning of the next epoch -1. Promotion a node to become a Tendermint validator (0069-VCBS-038)(0069-SP-VCBS-038): +1. Promotion a node to become a Tendermint validator (0069-VCBS-038) for product spot: (0069-VCBS-129): - Setup a network with 5 validators (and 5 slots for tendermint validators). - Do not self-delegate to them. - Announce a new node and self-delegate to them. - Verify that at the beginning of the next epoch one of the validators which were Tendermint validators before is chosen at random and is demoted to ersatz validator. - Verify the announced validator is promoted to be Tendermint validator with voting power = 10000. -1. Promotion + swap (0069-VCBS-039)(0069-SP-VCBS-039): +1. Promotion + swap (0069-VCBS-039) for product spot: (0069-VCBS-130): - Setup a network with 4 validators with self-delegation such that the number of Tendermint nodes (with the `network.validators.tendermint.number` parameter set to 5). - In the following epoch, remove the self-delegation from node 1, and announce 2 nodes. - During the epoch self-delegate to the two nodes. - Wait for 3 epochs to allow performance of the new nodes to be greater than 0. - Verify that, once the performance is greater than zero, the two nodes should be promoted to Tendermint validators and their voting power should be equal to their relative stake x their performance score x 10000. -1. Swap last due to performance (0069-VCBS-040)(0069-SP-VCBS-040): +1. Swap last due to performance (0069-VCBS-040) for product spot: (0069-VCBS-131): - Setup a network with 5 validators with self-delegation. - Announce a new node and self-delegate to it. - Once it gets to a performance score of 0.2, shut down two of the 5 Tendermint validators after 0.1 of the duration of the epoch, e.g. if the epoch is 5 minutes, that means after 30 seconds of the epoch they should be stopped. - Verify that at the beginning of the next epoch, expect the performance score of the two stopped validators is <= 0.1, and one of them chosen at random is demoted to ersatz validator and is replaced by the announced nodes as a Tendermint validator with voting power =~ 0.2 * `stake_of_validator` / `total_stake_network` -1. Number of slots increased (0069-VCBS-041)(0069-SP-VCBS-041): +1. Number of slots increased (0069-VCBS-041) for product spot: (0069-VCBS-132): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Announce a new node, DO NOT self-delegate to it. - Run for an epoch and assert the validator is shown as pending. @@ -385,7 +387,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that at the beginning of the next epoch the pending validator is still pending as their performance score is 0 (no self-stake). - Self-delegate to the pending validator - Verify that at the end of the epoch they are promoted to Tendermint validator. -1. Swap due to better score (0069-VCBS-042)(0069-SP-VCBS-042): +1. Swap due to better score (0069-VCBS-042) for product spot: (0069-VCBS-133): - Setup a network with 5 Tendermint validators and self-delegate 1000 tokens to each of them. - Announce a new node at the beginning of the epoch, self-delegate to them a total that is 10000 tokens. - At the beginning of the next epoch the new validator should have ranking score *equal or lower* to all of the Tendermint validators so it doesn’t get promoted. The parameter is set sufficiently high to assure this (e.g., 1.1). @@ -393,7 +395,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - Verify that at the beginning of the next epoch the announced node replaced node 1 as a Tendermint validator. - Restart node 1 again from a snapshot - Verify that node 1 is in a pending state. -1. 2 empty spots, only one available to replace (0069-VCBS-043)(0069-SP-VCBS-043): +1. 2 empty spots, only one available to replace (0069-VCBS-043) for product spot: (0069-VCBS-134): - Setup a network with 5 slots for Tendermint validators and 3 actual Tendermint validators. - Self-delegate to all of them. - Announce 2 new nodes but self-delegate only to one of them. @@ -401,7 +403,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). ### `Ownstake` Scenarios -1. `Ownstake` scenario1 (0069-VCBS-053)(0069-SP-VCBS-053) +1. `Ownstake` scenario1 (0069-VCBS-053) for product spot: (0069-VCBS-135) - Network with 3 tendermint validators and 7 ersatz validators - In the same epoch, change the network parameter `reward.staking.delegation.minimumValidatorStake` in a way that 3 tendermint validators and 3 ersatz validators drop below the `ownstake` requirement, and change the delegation so that 4 (not affected) Ersatz validators have a higher score than two (not affected) Validators. Also, give one of the Ersatz validators with insufficient `ownstake` the highest stake (delegated) of all Ersatz validators. - At the end of the epoch all validators with insufficient own stake will get a ranking score of 0. @@ -409,7 +411,7 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). - The 3 tendermint validators would be swapped with the top 3 ersatz validators over the following 3 epochs - Also verify that the ersatz validator with the insufficient own but the most delegated stake has a ranking score of 0 and doesn't get promoted. - No validator with stake attached to them is ever completely removed -1. `Ownstake` scenario2 (0069-VCBS-073)(0069-SP-VCBS-073) +1. `Ownstake` scenario2 (0069-VCBS-073) for product spot: (0069-VCBS-136) Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -417,7 +419,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 1 ersatz validator has 6000 stake and sufficient `ownstake` - the pending validator has sufficient `ownstake` - Verify that the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. -1. `Ownstake` scenario3 (0069-VCBS-074)(0069-SP-VCBS-074) +1. `Ownstake` scenario3 (0069-VCBS-074) for product spot: (0069-VCBS-137) 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -425,7 +427,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. -1. `Ownstake` scenario4 (0069-VCBS-075)(0069-SP-VCBS-075) +1. `Ownstake` scenario4 (0069-VCBS-075) for product spot: (0069-VCBS-138) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -433,7 +435,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. -1. `Ownstake` scenario5 (0069-VCBS-076)(0069-SP-VCBS-076) +1. `Ownstake` scenario5 (0069-VCBS-076) for product spot: (0069-VCBS-139) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -443,13 +445,13 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. -1. `Ownstake` scenario6 (0069-VCBS-077)(0069-SP-VCBS-077) +1. `Ownstake` scenario6 (0069-VCBS-077) for product spot: (0069-VCBS-140) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators - Verify that one validator is replaced the following epoch, one in the epoch after -1. `Ownstake` scenario7 (0069-VCBS-078)(0069-SP-VCBS-078) +1. `Ownstake` scenario7 (0069-VCBS-078) for product spot: (0069-VCBS-141) -Verify that 2 validators are replaced, one in each epoch 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` @@ -458,7 +460,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Ersatz Rewards -1. Ersatz validator reward (0069-VCBS-061)(0069-SP-VCBS-061) +1. Ersatz validator reward (0069-VCBS-061) for product spot: (0069-VCBS-142) - Setup a network with 5 validators with the following distribution of delegation: - 10%, 10%, 10%, 10%. 60% of the total delegation of tendermint validators - Setup 5 ersatz validators each with the minimum delegation at the end of the epoch verify that the stake score of the validator with 60% of the delegation (under reward) is anti-whaled @@ -468,7 +470,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled -1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057)(0069-SP-VCBS-057) +1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) for product spot: (0069-VCBS-143) - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 - Verify that at the end of the Epoch, the Ersatz Validators get no reward - Increase the `rewardFactor` to 0.5 @@ -480,19 +482,19 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Slot Adjustments -1. Number of slots decreased (0069-VCBS-052)(0069-SP-VCBS-052): +1. Number of slots decreased (0069-VCBS-052) for product spot: (0069-VCBS-144): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Decrease the number of tendermint validators to 3. - Verify that in each of the following two epochs, the validator with the lowest score is demoted to Ersatz validator and an Ersatz validator is demoted to pending -1. Number of Ersatz validators increased (0069-VCBS-058)(0069-SP-VCBS-058): +1. Number of Ersatz validators increased (0069-VCBS-058) for product spot: (0069-VCBS-145): - Setup a network with 4 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.9 - Verify that in the following epoch, the Ersatz Validator with the highest score is promoted to Validator -1. Number of Ersatz validators decreased (0069-VCBS-054)(0069-SP-VCBS-054): +1. Number of Ersatz validators decreased (0069-VCBS-054) for product spot: (0069-VCBS-146): - Setup a network with 5 Tendermint validators, 3 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5) - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.1 - Verify that in the following to epoch, all the Ersatz Validators are demoted to pending -1. Number of Ersatz validators Erratic (0069-VCBS-055)(0069-SP-VCBS-055): +1. Number of Ersatz validators Erratic (0069-VCBS-055) for product spot: (0069-VCBS-147): - Setup a network with 5 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.9 - Verify that in the next epoch the 2 pending validators are promoted to ersatz @@ -501,51 +503,52 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Two epochs later, change `network.validators.ersatz.multipleOfTendermintValidators` to 0.5 - Verify that in the next epoch the 2 pending validators are promoted to ersatz - Verify that in the last epoch, no demotions/promotions happen and the number of Ersatz validators stays at 2 -1. Number of Ersatz Validators oddly defined (0069-VCBS-056)(0069-SP-VCBS-056) +1. Number of Ersatz Validators oddly defined (0069-VCBS-056) for product spot: (0069-VCBS-148) - Set the factor to 0.00000000000000000000000000000000000000001 - Verify that all Validators round it the same way, and that there are no Ersatz validators - Set the factor to 3.00000000000000000000000000000000000000001 and run the network with just one tendermint (consensus) validator. - Verify that all Validators round it the same way, and that there are three Ersatz validators -1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069)(0069-SP-VCBS-069) -1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070)(0069-VCBS-070). Restart from checkpoint ((0069-VCBS-080)(0069-SP-VCBS-080)), all validator nodes are still correct. -1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072)(0069-SP-VCBS-072) +1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) for product spot: (0069-VCBS-149) +1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070) for product spot: (0069-VCBS-150). + 1. Restart from checkpoint ((0069-VCBS-080) for product spot: (0069-VCBS-151)), all validator nodes are still correct. +1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) for product spot: (0069-VCBS-152) ### Announce Node -1. Invalid announce node command (0069-VCBS-044)(0069-SP-VCBS-044): +1. Invalid announce node command (0069-VCBS-044) for product spot: (0069-VCBS-153): - Send an announce node command from a non validator node should fail -1. Valid announce node command (0069-VCBS-045)(0069-SP-VCBS-045): +1. Valid announce node command (0069-VCBS-045) for product spot: (0069-VCBS-156): - Send a valid announce node from a validator node should result in a validator update event with the details of the validator and a validator ranking event. -1. Node announces using same keys as existing node via announce node command (0069-VCBS-060)(0069-SP-VCBS-060): +1. Node announces using same keys as existing node via announce node command (0069-VCBS-060) for product spot: (0069-VCBS-157): - Should be rejected ### Checkpoints -1. Base case (0069-VCBS-046)(0069-SP-VCBS-046): +1. Base case (0069-VCBS-046) for product spot: (0069-VCBS-158): - Setup a network with 5 Tendermint validators - Take a checkpoint - Restore from checkpoint with the 5 same validators, which should pass. - Verify that after the network is restarted, the validators have voting power as per the checkpoint until the end of the epoch. -1. Base + ersatz (0069-VCBS-047)(0069-SP-VCBS-047): +1. Base + ersatz (0069-VCBS-047) for product spot: (0069-VCBS-159): - Setup a network with 5 Tendermint validators (where 5 is also the number of allowed Tendermint validators) - Announce 2 new nodes and wait for them to become ersatz validators (set the network parameter `network.validators.minimumEthereumEventsForNewValidator` to 0). - Take a checkpoint and verify it includes the ersatz validators. - Restore from the checkpoint (all nodes are running) - Verify that the validators have the voting power as per the checkpoint and that the ersatz validators are shown on data node having status ersatz. -1. Missing validators (0069-VCBS-048)(0069-SP-VCBS-048): +1. Missing validators (0069-VCBS-048) for product spot: (0069-VCBS-160): - Setup a network with 5 validators such that 3 of them have 70% of the voting power. Note: this is done by delegating 70% of the total stake to them. - Take a checkpoint - Restore from the checkpoint – starting only the 3 nodes with the 70% stake. - Verify that after the restore the network should be able to proceed generating blocks although with slower pace. -1. Missing validators stop the network (0069-VCBS-049)(0069-SP-VCBS-049): +1. Missing validators stop the network (0069-VCBS-049) for product spot: (0069-VCBS-161): - Setup a network with 5 validators with equal delegation to them. - Verify before the checkpoint that the voting power of all of them is equal. - Take a checkpoint. - Restart the network starting only 3 of the validators. - Restore from the checkpoint. - Verify the network is not able to produce blocks. -1. Checkpoints store validator changes (0069-VCBS-079)(0069-SP-VCBS-079): +1. Checkpoints store validator changes (0069-VCBS-079) for product spot: (0069-VCBS-162): - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). - Stop and relegate one of the original validators (v1) such that v6 is promoted to tendermint validator, and v7 is promoted to ersatz. - Restart v1 and announce to pending. @@ -553,7 +556,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the network - Verify that v2-v6 are tendermint validators, v7 is ersatz and v1 is pending. - Verify that all stakes and delegations are correct for each node. -1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088)(0069-SP-VCBS-088): +1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088) for product spot: (0069-VCBS-163): - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). - Take a checkpoint. - Wait until the current epoch will have expired. @@ -564,44 +567,44 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Multisig update -1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002)(0069-SP-COSMICELEVATOR-002) -1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003)(0069-SP-COSMICELEVATOR-003) -1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004)(0069-SP-COSMICELEVATOR-004) -1. Can update multisig for new validator, and expect rewards (0069-VCBS-066)(0069-SP-VCBS-066) +1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-VCBS-002) for product spot: (0069-VCBS-164) +1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-VCBS-003) for product spot: (0069-VCBS-165) +1. It is possible to submit a transaction to update the weights. (0069-VCBS-004) for product spot: (0069-VCBS-165) +1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) for product spot: (0069-VCBS-166) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067)(0069-SP-VCBS-067) +1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) for product spot: (0069-VCBS-167) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068)(0069-SP-VCBS-068) -1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071)(0069-SP-VCBS-071) +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) for product spot: (0069-VCBS-168) +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) for product spot: (0069-VCBS-169) ### Re-Issuing Signature Bundles by non Validators 1. Submit two `IssueSignature` requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the result is the same. -(0069-VCBS-081)(0069-SP-VCBS-081) +(0069-VCBS-081) for product spot: (0069-VCBS-170) 1. Submit two `IssueSignature` requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. -(0069-VCBS-082)(0069-SP-VCBS-082) +(0069-VCBS-082) for product spot: (0069-VCBS-171) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. -(0069-VCBS-083)(0069-SP-VCBS-083) +(0069-VCBS-083) for product spot: (0069-VCBS-172) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys in different blocks. Verify that both get executed. -(0069-VCBS-084)(0069-SP-VCBS-084) +(0069-VCBS-084) for product spot: (0069-VCBS-173) 1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 `IssueSignature` requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one `IssueSignature` request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. -(0069-VCBS-085)(0069-SP-VCBS-085) +(0069-VCBS-085) for product spot: (0069-VCBS-174) 1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. -(0069-VCBS-086)(0069-SP-VCBS-086) +(0069-VCBS-086) for product spot: (0069-VCBS-175) 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. -(0069-VCBS-087)(0069-SP-VCBS-087) +(0069-VCBS-087) for product spot: (0069-VCBS-176) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index dc2e43e33..a3f634617 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,11 +70,11 @@ Trades of course result in transfers. The amounts transferred (for the trade as ## Acceptance criteria - As a user, I can propose a market with a different precision than its settlement asset - - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001)(0070-SP-MKTD-001) - - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002)(0070-SP-MKTD-002) -- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003)(0070-SP-MKTD-003) -- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004)(0070-SP-MKTD-004) -- As a user I should see the market data prices using market precision. (0070-MKTD-005)(0070-SP-MKTD-005) -- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006)(0070-SP-MKTD-006) -- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007)(0070-SP-MKTD-007) -- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008)( 0070-SP-MKTD-008) + - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001) for product spot: (0070-MKTD-008) + - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002) for product spot: (0070-MKTD-009) +- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003) for product spot: (0070-MKTD-010) +- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004) for product spot: (0070-MKTD-011) +- As a user I should see the market data prices using market precision. (0070-MKTD-005) for product spot: (0070-MKTD-012) +- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006) for product spot: (0070-MKTD-013) +- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007) for product spot: (0070-MKTD-014) +- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008) for product spot: ( 0070-MKTD-015) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 1659a3f62..a14166916 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -107,7 +107,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 - We can launch a network with any valid checkpoint file. (0073-LIMN-003) - Hash of the checkpoint file is agreed via consensus. (0073-LIMN-005) -### Test case 1: Withdrawal status is correctly tracked across resets (0073-LIMN-007)(0073-SP-LIMN-007) +### Test case 1: Withdrawal status is correctly tracked across resets (0073-LIMN-007) + +for product spot: (0073-LIMN-101) 1. A party has general account balance of 100 USD. 1. The party submits a withdrawal transaction for 100 USD. A checkpoint is immediately created. @@ -158,7 +160,7 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. The LP party has general account balance in USD of `9000` and bond account balance `1000` on the market `id_xxx`. 1. The other party has no open orders anywhere and general account balance in USD of `other_gen_bal + other_margin_bal`. -#### Test case 3.1: Spot market is proposed, accepted, restored (0073-SP-LIMN-009) +#### Test case 3.1: Spot market is proposed, accepted, restored (0073-LIMN-102) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -176,7 +178,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. The LP party has general account balance in USD of `9000` and bond account balance `1000` on the market `id_xxx`. 1. The other party has no open orders anywhere and general account balance in USD of `other_gen_bal + other_hold_bal`. -#### Test case 3.2: Market is proposed, voting hasn't closed, not restored (0073-LIMN-010)(0073-SP-LIMN-010) +#### Test case 3.2: Market is proposed, voting hasn't closed, not restored (0073-LIMN-010) + +for product spot: (0073-LIMN-103) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -190,7 +194,9 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 1. There is an asset USD. 1. There is no market and there are no market proposals. -#### Test case 3.3: Market is proposed, voting has closed, market rejected, proposal not restored (0073-LIMN-011)(0073-SP-LIMN-011) +#### Test case 3.3: Market is proposed, voting has closed, market rejected, proposal not restored (0073-LIMN-011) + +for product spot:(0073-LIMN-104) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 4c9681173..a8e2530d8 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -48,15 +48,15 @@ After entering or exiting an auction mid-batch, the full batch must be processed ## Acceptance criteria -- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001)(0074-SP-BBTCH-001) -- Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002)(0074-SP-BBTCH-002) -- An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003)(0074-SP-BBTCH-003) -- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005)(0074-SP-BBTCH-005) -- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006)(0074-SP-BBTCH-006) In particular: +- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001) for product spot: (0074-BTCH-012) +- Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002) for product spot: (0074-BTCH-013) +- An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003) for product spot: (0074-BTCH-014) +- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005) for product spot: (0074-BTCH-015) +- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006) for product spot: (0074-BTCH-016) In particular: - A batch consisting of two limit order placements C1 and C2 where the party has enough balance to place either of them individually but not both should place C1 but reject C2. - A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction and a C2 which is marked `GFN` (good for normal) should execute C1 but reject C2. -- A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007)(0074-SP-BBTCH-007) -- Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008)(0074-SP-BBTCH-008) -- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009)(0074-SP-BBTCH-009) +- A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007) for product spot: (0074-BTCH-017) +- Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008) for product spot: (0074-BTCH-018) +- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009) for product spot: (0074-BTCH-019) - If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010) -- Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011)(0074-SP-BBTCH-011) +- Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011) for product spot: (0074-BTCH-020) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index 014b4e806..843992ed8 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -102,7 +102,9 @@ There are three priority categories: 1. Send `100` transactions with default gas cost to a node (e.g. votes on a proposal) and observe that most block have 5 of these transactions each. -### Test max with a market (0079-TGAP-004)(0079-SP-TGAP-004) +### Test max with a market (0079-TGAP-004) + +for product spot: (0079-TGAP-006) 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 1`. 1. Create a market with 1 LP @@ -111,7 +113,9 @@ There are three priority categories: 1. Another party submits a transaction to place a limit order. A block will be created containing the transaction (even though the gas cost of a limit order is `1 + 50 x 3 + 2 x 1 + 0.1 x 5` which is well over `100`.) -### Test we don't overfill a block with a market (0079-TGAP-005)(0079-SP-TGAP-005) +### Test we don't overfill a block with a market (0079-TGAP-005) + +for product spot: (0079-TGAP-007) 1. Set `network.transactions.maxgasperblock = 500` and `network.transaction.defaultgas = 1`. 1. Place 2 matching orders, 1 buy order below the matching price and 1 sell order above the matching price. Uncross the opening auction. diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index f0bfc7660..15c37e4ac 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -40,7 +40,7 @@ A liquidity provision submitted to a `Spot` market specifies a single commitment Example `LiquidityProvisionSubmission` command to an ETH/DAI market: submission = { - "liquidityProvisionSubmission": + "liquidityProvisionSubmission": { marketId: "abcdefghiklkmnopqrstuvwxyz", fee: "0.01", @@ -85,33 +85,33 @@ Both buy and sell orders on a `Spot` market define a size (amount of the `base_a ### Sell Orders -For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid.(0080-SP-FEES-001) +For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid.(0080-SPOT-008) -If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SP-FEES-002) +If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-009) -If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SP-FEES-003) +If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SPOT-010) ### Buy Orders -As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SP-FEES-004) +As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) #### Continuous Trading -For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SP-FEES-005) +For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) -If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SP-FEES-006). As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SP-FEES-007). If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SP-FEES-008) +If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SPOT-013). As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SPOT-014). If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) #### Entering an Auction -When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SP-AUC-001). If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SP-AUC-002). +When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SPOT-016). If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). -For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SP-AUC-003). +For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SPOT-018). -If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SP-FEES-009). +If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SPOT-019). #### Exiting an Auction -When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SP-AUC-004). +When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SPOT-020). ## 8. Auctions From 420a8223875237463e31d976a6dcde70ac1c5ed9 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 13 Jul 2023 11:53:42 +0100 Subject: [PATCH 280/649] fix: approbation code fails --- protocol/0004-AMND-amends.md | 2 +- protocol/0008-TRAD-trading_workflow.md | 2 +- protocol/0014-ORDT-order_types.md | 4 +-- protocol/0021-MDAT-market_data_spec.md | 2 +- protocol/0036-BRIE-event_queue.md | 9 +++-- .../0039-MKTD-market_depth_calculation.md | 4 +-- ...-TVAL-validate_transaction_preconsensus.md | 18 ++++++---- protocol/0056-REWA-rewards_overview.md | 36 +++++++++---------- protocol/0068-MATC-matching_engine.md | 4 +-- protocol/0070-MKTD-market-decimal-places.md | 2 +- 10 files changed, 46 insertions(+), 37 deletions(-) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 659c658e8..adbf1ce39 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -5,7 +5,7 @@ - Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001) for product spot: (0004-AMND-030) - Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002) for product spot: (0004-AMND-031) - Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003) for product spot: (0004-AMND-032) -- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004) for product spot: (0004-AMND-032) +- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004) for product spot: (0004-AMND-055) - Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005) for product spot: (0004-AMND-033) - Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006) for product spot: (0004-AMND-034) - Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007) for product spot: (0004-AMND-035) diff --git a/protocol/0008-TRAD-trading_workflow.md b/protocol/0008-TRAD-trading_workflow.md index b54705e52..dbab4143a 100644 --- a/protocol/0008-TRAD-trading_workflow.md +++ b/protocol/0008-TRAD-trading_workflow.md @@ -10,7 +10,7 @@ The order of processing of transactions happens in the order defined in the diag 1. Before a valid order is processed in any other way by Vega, the [party](./0017-PART-party.md)'s [margin levels](./0011-MARA-check_order_allocate_margin.md) are checked as though they had the order in their position, and any transfers that are needed to support that order occur. (0008-TRAD-001) 1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there will be changes in positions for one or more traders. (0008-TRAD-002) -1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003) for product spot: (0008-TRAD-008) +1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003) for product spot: (0008-TRAD-008) 1. Following the above 3 actions, a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is run for all parties against their most recently updated positions and Mark Price. This will result in a set of transfers between the parties' accounts and possibly may result in loss socialisation occurring if a party has insufficient collateral to cover the move. (0008-TRAD-004) 1. Following the mark to market settlement, the margin liabilities for traders are evaluated against their collateral balances. Any traders that do not have sufficient collateral to support their positions (after collateral searches have been done to their main account) will undergo position resolution. (0008-TRAD-005) 1. After position resolution has occurred, margins are recalculated and evaluated against balances for any traders that gained positions as a result of supplying liquidity on the order book to the network during position resolution. (0008-TRAD-006) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 0bd918558..abcc5a364 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -290,7 +290,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with 3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018) for product spot: (0014-ORDT-098) 4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) for product spot: (0014-ORDT-099) 5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) for product spot: (0014-ORDT-100) -6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) for product spot: (0014-ORDT-100) +6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) for product spot: (0014-ORDT-119) #### Iceberg Order Amendment @@ -313,7 +313,7 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with 5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) for product spot: (0014-ORDT-109) 6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032) for product spot: (0014-ORDT-110) 7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) for product spot: (0014-ORDT-111) -8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034)( 0014-ORDT-111) +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034) for product spot: ( 0014-ORDT-118) 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) for product spot: (0014-ORDT-112) 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) for product spot: (0014-ORDT-113) diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index 4f3e76eea..072c5a4c0 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -13,7 +13,7 @@ - The Open interest returns 0 if there are no positions on the market (0021-MDAT-009) - Pegged orders are excluded from the best static price and best static volume calculations. (0021-MDAT-010) - Dynamic orders should be ignored when calculating the static values (0021-MDAT-011) -- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012) for product spot: (0021-MDAT-010) +- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012) for product spot: (0021-MDAT-020) ## Summary diff --git a/protocol/0036-BRIE-event_queue.md b/protocol/0036-BRIE-event_queue.md index d7211c7be..9d2032bc8 100644 --- a/protocol/0036-BRIE-event_queue.md +++ b/protocol/0036-BRIE-event_queue.md @@ -164,17 +164,20 @@ message NodeVote { ## Acceptance Criteria -- A valid event is processed by vega (0036-BRIE-001) for product spot: (0036-BBRIE-004) +- A valid event is processed by vega (0036-BRIE-001) + - for product spot: (0036-BRIE-004) - A transaction is successfully executed on the bridge (e.g deposit) - A validator node successfully source the event and emit a chain event transaction on the vega chain - The others validators successfully validates the event on the ethereum chain and send a node vote on chain - The required amount of node votes, weighted by validator score is received - The processing of the event have effect on the network (e.g: for a deposit funds are deposited on an account) -- A valid duplicated event is processed (0036-BRIE-002) for product spot: (0036-BRIE-005) +- A valid duplicated event is processed (0036-BRIE-002) + - for product spot: (0036-BRIE-005) - A transaction is successfully executed on the bridge (e.g deposit) and successfully processed by vega - A node sends again the chain event after sourcing it - The nodes reject this event as duplicated, nothing else happens -- A invalid event is processed (0036-BRIE-003) for product spot: (0036-BRIE-006) +- A invalid event is processed (0036-BRIE-003) + - for product spot: (0036-BRIE-006) - A malicious node sends a chain event for a non existing transaction on the bridge - The node start validating this event on chain, but cannot find it - After a given delay this chain event is rejected, no node votes are being sent by the validators diff --git a/protocol/0039-MKTD-market_depth_calculation.md b/protocol/0039-MKTD-market_depth_calculation.md index 9e7d3b327..bfe30113f 100644 --- a/protocol/0039-MKTD-market_depth_calculation.md +++ b/protocol/0039-MKTD-market_depth_calculation.md @@ -6,14 +6,14 @@ - Entering and leaving auctions must be handled correctly (0039-MKTD-003) for product spot: (0039-MKTD-021) - All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004) for product spot: (0039-MKTD-022) - Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005) for product spot: (0039-MKTD-023) -- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006) for product spot: (0039-MKTD-0024) +- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006) for product spot: (0039-MKTD-024) - Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007) for product spot: (0039-MKTD-025) - A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008) for product spot: (0039-MKTD-026) - Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009) for product spot: (0039-MKTD-027) - Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010) for product spot: (0039-MKTD-028) - Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012) for product spot: (0039-MKTD-029) - Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013) for product spot: (0039-MKTD-030) -- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014) for product spot: (0039-MKTD-030) +- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014) for product spot: (0039-MKTD-033) - Pegged orders are part of the market depth view and should update the view when their orders are repriced (0039-MKTD-015) - Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018) for product spot: (0039-MKTD-031) - The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019) for product spot: (0039-MKTD-032) diff --git a/protocol/0049-TVAL-validate_transaction_preconsensus.md b/protocol/0049-TVAL-validate_transaction_preconsensus.md index 78cd8050e..608c065a2 100644 --- a/protocol/0049-TVAL-validate_transaction_preconsensus.md +++ b/protocol/0049-TVAL-validate_transaction_preconsensus.md @@ -28,9 +28,15 @@ Future enhancements: for each root transaction message type (e.g. `SubmitOrder`, Note that separate pre-consensus validation is carried out as part of PoW anti-spam checks, see the acceptance criteria in [PoW spec](./0072-SPPW-spam-protection-PoW.md). -1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001) for product spot: (0049-TVAL-007) -1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002) for product spot: (0049-TVAL-008) -1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-TVAL-003) for product spot: (0049TVAL-009) -1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-TVAL-004) for product spot: (0049-TVAL-010) -1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-TVAL-005) for product spot: (0049-TVAL-011) -1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006) for product spot: (0049-TVAL-012) +1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001) + 1. for product spot: (0049-TVAL-007) +1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002) + 1. for product spot: (0049-TVAL-008) +1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-TVAL-003) + 1. for product spot: (0049-TVAL-009) +1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-TVAL-004) + 1. for product spot: (0049-TVAL-010) +1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-TVAL-005) + 1. for product spot: (0049-TVAL-011) +1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006) + 1. for product spot: (0049-TVAL-012) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index a3a44831b..df0e7a5cf 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -201,11 +201,11 @@ for product spot: (0056-REWA-0590056-REWA-0550068-MATC-001) for product spot: (0068-MATC-061) - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002) for product spot: (0068-MATC-062) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003) for product spot: (0068-MATC-063) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003) for product spot: (0068-MATC-063) - If there is no match the order will be cancelled. (0068-MATC-004) for product spot: (0068-MATC-064) - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) for product spot: (0068-MATC-065) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) @@ -85,7 +85,7 @@ When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auc - Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033) for product spot: (0068-MATC-060) - The price of any persistent order can be updated (0068-MATC-034) for product spot: (0068-MATC-089) - The size of any persistent order can be updated (0068-MATC-035) for product spot: (0068-MATC-090) -- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036) for product spot: (0068-MATC-090) +- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036) for product spot: (0068-MATC-092) - An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037) for product spot: (0068-MATC-091) ## Summary diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index a3f634617..8d227dbc1 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,7 +70,7 @@ Trades of course result in transfers. The amounts transferred (for the trade as ## Acceptance criteria - As a user, I can propose a market with a different precision than its settlement asset - - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001) for product spot: (0070-MKTD-008) + - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001) for product spot: (0070-MKTD-016) - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002) for product spot: (0070-MKTD-009) - As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003) for product spot: (0070-MKTD-010) - As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004) for product spot: (0070-MKTD-011) From d6fd88dccc6360fef064997508c2f5d5e74204b0 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 13 Jul 2023 12:01:22 +0100 Subject: [PATCH 281/649] fix: last approbation error codes --- protocol/0056-REWA-rewards_overview.md | 2 +- protocol/0069-VCBS-validators_chosen_by_stake.md | 6 +++--- protocol/0073-LIMN-limited_network_life.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index df0e7a5cf..edc794678 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -197,7 +197,7 @@ At the end of epoch 2: ### Distributing fees paid rewards - unfunded account (0056-REWA-011) -for product spot: (0056-REWA-059) +for product spot: (0056-REWA-059) #### Rationale 2 diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index c11c2e571..6416d5145 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -219,7 +219,7 @@ for product spot: (0069-VCBS-0890069-VCBS-050) for product spot: (0069-VCBS-099): +1. Tendermint validators missing signature test 3 (0069-VCBS-050) for product spot: (0069-VCBS-099): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners`is set to 4. - Delegate 10000 to the existing validators (can be self or party delegation) @@ -427,7 +427,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. -1. `Ownstake` scenario4 (0069-VCBS-075) for product spot: (0069-VCBS-138) +1. `Ownstake` scenario4 (0069-VCBS-075) for product spot: (0069-VCBS-138) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -569,7 +569,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid 1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-VCBS-002) for product spot: (0069-VCBS-164) 1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-VCBS-003) for product spot: (0069-VCBS-165) -1. It is possible to submit a transaction to update the weights. (0069-VCBS-004) for product spot: (0069-VCBS-165) +1. It is possible to submit a transaction to update the weights. (0069-VCBS-004) for product spot: (0069-VCBS-177) 1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) for product spot: (0069-VCBS-166) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index a14166916..0aafe9448 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -160,7 +160,7 @@ for product spot: (0073-LIMN-1010073-LIMN-102) +#### Test case 3.1: Spot market is proposed, accepted, restored (0073-LIMN-102) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. From 62bc0d711626ea033cfab0a93aa228c98b20ac34 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 13 Jul 2023 14:42:04 +0200 Subject: [PATCH 282/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: Tom --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 75da682c5..751a59a36 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,7 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. -- `market.liquidity.sla.evalEveryNumOfTransactions` sets how many transactions in a block are processed before each party that's committed to providing liquidty is evaluated for meeting (or not) their commitment. +- `market.liquidity.sla.evalEveryNumOfTransactions` sets how many transactions in a block are processed before each party that's committed to providing liquidity is evaluated for meeting (or not) their commitment. ### Market parameters From 1dc6063816ecdbe26cd9ba3778de34ccb537b481 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 13 Jul 2023 14:54:31 +0200 Subject: [PATCH 283/649] fix: add intra-block SLA sampling --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 7ab017d9c..4eeb1118f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -223,18 +223,21 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP - If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -- At start of block, set `k` to `0` and then after every `market.liquidity.sla.evalEveryNumOfTransactions` transactions have been processed set `k` to the transaction number of the just processed transaction. +- At start of block, set `block_sla_met = true` and `k` to `0` and then after every `market.liquidity.sla.evalEveryNumOfTransactions` transactions have been processed set `k` to the transaction number of the just processed transaction. - In each block, immediately after processing transaction `k`: - Note that this happens _after_ iceberg orders, that need refreshing as a result of transaction `k` are refreshed. This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. - - If LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): + - if an LP is *not* meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") set `block_sla_met = false` + +- At the end of each block: + - If `block_sla_met = true` and if an LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): - Store the current Vega time attached to the block being processed as the time the LP began meeting their commitment. - - If LP has stopped meeting their committed volume of notional after previously doing so: + - If `block_sla_met = false ` and an LP has stopped meeting their committed volume of notional after previously doing so: - Add the difference in nanoseconds between the current Vega time attached to the block being processed and the time the LP began meeting their commitment (stored in the step above) to `s_i`. From 45b216bc1a81cef612f872bd959a0c89241bef16 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 13 Jul 2023 16:27:24 +0200 Subject: [PATCH 284/649] feat: update ACs for holding accounts --- protocol/0013-ACCT-accounts.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 4583dcf3d..fdf0379ce 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -102,10 +102,10 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Party asset accounts -- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003) for product spot: (0013-ACCT-026) - - Only one general asset account exists per party per asset. (0013-ACCT-004) for product spot: (0013-ACCT-027) - - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005) for product spot: (0013-ACCT-028) - - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) for product spot: (0013-ACCT-029) +- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003) + - Only one general asset account exists per party per asset. (0013-ACCT-004) + - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005) + - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) - [Fees earned from liquidity provision](./0044-LIME-lp_mechanics.md#fees) are paid in to this account. (0013-ACCT-011) ### Party margin accounts @@ -117,7 +117,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Party holding accounts in Spot market -- Every party that submits an order on a market will have a holding account for that market created. (0013-ACCT-030) +- Every party that submits an order on a Spot market will have a holding account created for the relevant market asset pair. (0013-ACCT-030) - Each party should only have two holding accounts per market: one for the the base_asset and one for the quote_asset. (0013-ACCT-031) ### Liquidity Provider bond accounts From e1388698607ce12a5db22b9d558f6f7fbc064d72 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 13 Jul 2023 16:31:41 +0200 Subject: [PATCH 285/649] feat: remove spot from spec 36/69 --- protocol/0036-BRIE-event_queue.md | 3 - .../0069-VCBS-validators_chosen_by_stake.md | 175 +++++++++--------- 2 files changed, 87 insertions(+), 91 deletions(-) diff --git a/protocol/0036-BRIE-event_queue.md b/protocol/0036-BRIE-event_queue.md index 9d2032bc8..ca9c25670 100644 --- a/protocol/0036-BRIE-event_queue.md +++ b/protocol/0036-BRIE-event_queue.md @@ -165,19 +165,16 @@ message NodeVote { ## Acceptance Criteria - A valid event is processed by vega (0036-BRIE-001) - - for product spot: (0036-BRIE-004) - A transaction is successfully executed on the bridge (e.g deposit) - A validator node successfully source the event and emit a chain event transaction on the vega chain - The others validators successfully validates the event on the ethereum chain and send a node vote on chain - The required amount of node votes, weighted by validator score is received - The processing of the event have effect on the network (e.g: for a deposit funds are deposited on an account) - A valid duplicated event is processed (0036-BRIE-002) - - for product spot: (0036-BRIE-005) - A transaction is successfully executed on the bridge (e.g deposit) and successfully processed by vega - A node sends again the chain event after sourcing it - The nodes reject this event as duplicated, nothing else happens - A invalid event is processed (0036-BRIE-003) - - for product spot: (0036-BRIE-006) - A malicious node sends a chain event for a non existing transaction on the bridge - The node start validating this event on chain, but cannot find it - After a given delay this chain event is rejected, no node votes are being sent by the validators diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 6416d5145..47eb23108 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -163,8 +163,6 @@ See [limited network life spec](./0073-LIMN-limited_network_life.md). ### Joining / leaving VEGA chain (0069-VCBS-001) -for product spot: (0069-VCBS-089) - 1. A running Vega node which isn't a "pending" or "ersatz" or "validator" node already can submit a transaction to become a validator. 2. Their performance score will be calculated. See [performance score](./0064-VALP-validator_performance_based_rewards.md). 3. If they meet the Ethereum verification criteria and have enough stake they will become part of the validator set at the start of next epoch. See about [verifying ethereum integration](#verifying-ethereum-and-later-other-chain-integration). @@ -176,20 +174,20 @@ for product spot: (0069-VCBS-0890069-VCBS-005) for product spot: (0069-VCBS-090): +1. Base case for Tendermint validators (0069-VCBS-005): - Verify that the `stakeScore` for each of the Tendermint validators is 0.2 -1. Base case for ersatz validators (0069-VCBS-006) for product spot: (0069-VCBS-091): +1. Base case for ersatz validators (0069-VCBS-006): - Verify that the `stakeScore` for each of the ersatz validator is 0.5 -1. No antiwhaling for ersatz `stakeScore` (0069-VCBS-007) for product spot: (0069-VCBS-092): +1. No antiwhaling for ersatz `stakeScore` (0069-VCBS-007): - Delegate to one of the ersatz validators 4000 more tokens. - Run for an epoch with the new delegation (i.e. one ersatz with 500 one with 4500) and transfer 1000 tokens to the reward account. - Verify that at the end of the epoch the stake score of the validator with 4500 tokens is 0.9 and the one with 500 tokens is 0.1 -1. Antiwhaling for Tendermint validators (0069-VCBS-008) for product spot: (0069-VCBS-093): +1. Antiwhaling for Tendermint validators (0069-VCBS-008): - **Additional setup:** in addition to the 1000 delegated for each node, delegate 500 more to node 1. - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.competitionLevel` is set to 1 - Once it becomes active let it run for a full epoch during which transfer 1000 tokens to the reward account. - Verify that at the end of the epoch node 1 should have a stake score of 0.2 where all other nodes get stake score of 0.1818181818 -1. Full antiwhaling for Tendermint validators (0069-VCBS-009) for product spot: (0069-VCBS-094): +1. Full antiwhaling for Tendermint validators (0069-VCBS-009): - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.optimalStakeMultiplier` is set to 3 - **Additional setup:** ensure that the network parameter for `reward.staking.delegation.competitionLevel` is set to 1 - **Additional setup:** in addition to the 1000 tokens delegated to each node, delegate 10000 tokens to node1 to get a total delegation of 11000 to it. @@ -198,20 +196,20 @@ for product spot: (0069-VCBS-0890069-VCBS-010) for product spot: (0069-VCBS-095) -1. Tendermint validators excess signature (0069-VCBS-011) for product spot: (0069-VCBS-096): +1. Verify that for all ersatz validators their multisig score is 1 (0069-VCBS-010) +1. Tendermint validators excess signature (0069-VCBS-011): - Setup a network with 5 Tendermint validators but with only 4 validators that have sufficient self-delegation. Call the one without enough self-delegation Bob. - Announce a new node (Alice) and self-delegate to them, allow some time to replace the validator with no self-delegation (Bob) as a Tendermint validator by Alice. Note: At this point the signature of Bob IS still on the multisig contract. - Transfer 1000 tokens to the VEGA reward account. - Verify that at the end of the epoch all of the Tendermint validators should have a multisig score = 0 since Bob is still on the contract. -1. Tendermint validators missing signature test 1 (0069-VCBS-012) for product spot: (0069-VCBS-097): +1. Tendermint validators missing signature test 1 (0069-VCBS-012): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners` is set to **5**. - Announce a new node and self-delegate to it 1000 tokens. - Allow some time for the performance score to be greater than 0. Note: When this happens the validator will be promoted to Tendermint validator at the beginning of the following epoch. - When the validator has been promoted to a Tendermint validator, transfer 1000 tokens to the reward account. - Verify that the joining validator has a multisig score of 0 and therefore would not get a reward. -1. Tendermint validators missing signature test 2 (0069-VCBS-013) for product spot: (0069-VCBS-098): +1. Tendermint validators missing signature test 2 (0069-VCBS-013): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners` is set to 4. - Announce a new node and self-delegate to it 10000 tokens. @@ -219,7 +217,7 @@ for product spot: (0069-VCBS-0890069-VCBS-050) for product spot: (0069-VCBS-099): +1. Tendermint validators missing signature test 3 (0069-VCBS-050): - Setup a network with 4 Tendermint validators with self-delegation and number of Tendermint validators network parameter set to 5. - **Additional setup:** ensure that the network parameter `network.validators.multisig.numberOfSigners`is set to 4. - Delegate 10000 to the existing validators (can be self or party delegation) @@ -229,50 +227,50 @@ for product spot: (0069-VCBS-0890069-VCBS-051) for product spot: (0069-VCBS-100): +1. One of the top validators is not registered with the multisig contract (0069-VCBS-051): - Run a Vega network where a validator joins and gets a lot delegated in order for it to become one of the top `network.validators.multisig.numberOfSigners` - Ensure its ethereum key is **NOT** put on the multisig contract. - Verify the validator has 0 for their multisig score and receives no staking reward. #### Validator Score -1. Verify that the validator score is always equal to the `stakeScore` x `perfScore` x `multisigScore` when the validator is a Tendermint validator (0069-VCBS-014) for product spot: (0069-VCBS-101) -2. Verify that the validator score is always equal to the `stakeScore` x `perfScore` when the validator is an ersatz validator (0069-VCBS-015) for product spot: (0069-VCBS-102) +1. Verify that the validator score is always equal to the `stakeScore` x `perfScore` x `multisigScore` when the validator is a Tendermint validator (0069-VCBS-014) +2. Verify that the validator score is always equal to the `stakeScore` x `perfScore` when the validator is an ersatz validator (0069-VCBS-015) #### Normalised Score -1. The sum of normalised scores must always equal 1 (0069-VCBS-016) for product spot: (0069-VCBS-103) -2. The normalised score for validator i must equal `validatorScore_{i}` / `total_validator_score`. Note: the total validator score is calculated over the relevant set separately (i.e. Tendermint and ersatz) (0069-VCBS-017) for product spot: (0069-VCBS-104) +1. The sum of normalised scores must always equal 1 (0069-VCBS-016) +2. The normalised score for validator i must equal `validatorScore_{i}` / `total_validator_score`. Note: the total validator score is calculated over the relevant set separately (i.e. Tendermint and ersatz) (0069-VCBS-017) ### Rewards split between tendermint and ersatz validators -1. Base scenario (0069-VCBS-018) for product spot: (0069-VCBS-105): +1. Base scenario (0069-VCBS-018): - There are no ersatz validators in the network. - Verify that, regardless of `ersatzRewardFactor` value, all rewards are being paid out to the validators as expected given the reward scores. -1. Ersatz validators where ersatz reward factor equals 0 (0069-VCBS-019) for product spot: (0069-VCBS-106): +1. Ersatz validators where ersatz reward factor equals 0 (0069-VCBS-019): - Ensure that the `ersatzRewardFactor` is set to 0 - Setup an ersatz validator with delegation greater than the minimum. The delegation can be equal to the delegation of the other Tendermint validators - Verify the ersatz validators and their delegators get no rewards. -1. Ersatz validators where reward factor equals 1 (0069-VCBS-020) for product spot: (0069-VCBS-107): +1. Ersatz validators where reward factor equals 1 (0069-VCBS-020): - Setup an ersatz validator with self and party delegation making them eligible for reward for a whole epoch. For example, such that the total delegation to each node is 1000 Vega. (3 Tendermint validators, 1 ersatz validator all having a delegation of 1000 Vega). - Make sure there is balance of 1000 Vega in the reward pool account for the epoch. - Verify the reward pool is distributed equally between the validators. -1. Ersatz validators where reward factor equals 0.5 (0069-VCBS-021) for product spot: (0069-VCBS-108): +1. Ersatz validators where reward factor equals 0.5 (0069-VCBS-021): - Setup an ersatz validator with self and party delegation making them eligible for reward for a whole epoch. For example, such that the total delegation to each node is 1000 Vega. (3 tendermint validators, 1 ersatz validator all having a delegation of 1000 Vega). - Make sure there is balance of 3500 Vega in the reward account for the epoch. - Verify that 3000 is distributed between the Tendermint validators and 500 is rewarded to the ersatz validator. -1. Multiple ersatz validators, reward factor equals 0.5 (0069-VCBS-022) for product spot: (0069-VCBS-109): +1. Multiple ersatz validators, reward factor equals 0.5 (0069-VCBS-022): - Setup a network with 3 ersatz validators, 3 Tendermint validators with arbitrary delegation, but ensuring the total delegation for each validator is greater than the minimum self-delegation. - With `total_delegations_from_all_validators = (0.5 * total_delegation_from_ersatz_validators) + total_delegation_from_tendermint_validators` - Verify the total reward given to Tendermint validators is equal to the `total_delegation_from_tendermint_validators * reward_balance` / `total_delegation_from_all_validators`. - Verify the total reward given to ersatz validators is equal to the `total_delegation_from_ersatz_validators * 0.5 * reward_balance / total_delegation_from_all_validators`. -1. Pending validators get nothing (0069-VCBS-023) for product spot: (0069-VCBS-110): +1. Pending validators get nothing (0069-VCBS-023): - Setup a network with 5 tendermint validators, set number of ersatz validators (through network parameter) to 0. - Delegate to each node 1000 tokens (including self-delegation). - Announce 2 new nodes, verify that they are in pending state, delegate to them 1000 tokens each. - Run the network for a full epoch with the delegation, during which transfer 1000 tokens to the reward account. - Verify that, at the end of the epoch, none of the pending validators receive a reward. -1. Pending validators do not get promoted (0069-VCBS-024) for product spot: (0069-VCBS-111): +1. Pending validators do not get promoted (0069-VCBS-024): - Setup a network with 5 tendermint validators, 2 ersatz validators and set number of ersatz validators (through factor) to 2. - Delegate to each node 1000 tokens (including self-delegation). - Announce 2 new nodes, verify that they are in pending state, delegate to them 1000 tokens each. @@ -283,47 +281,47 @@ for product spot: (0069-VCBS-0890069-VCBS-025) for product spot: (0069-VCBS-112) -1. Verify the ranking score is available through the epoch/validator/`rankingScore` API in the data-node. (0069-VCBS-026) for product spot: (0069-VCBS-113) -1. Verify that the `rankingScore` is always equal to `performanceScore` x `stakeScore` x `incumbentBonus` (for tendermint validators and ersatz validators) Note: `network.validators.incumbentBonus` is a network parameter that is applied as a factor (1 + `incumbentBonus` network parameter) on `performanceScore` x `stakeScore`. (0069-VCBS-027) for product spot: (0069-VCBS-114) -1. Verify that if a node has a 0 `rankingScore` for 1e6 blocks (corresponding to around 11.5 days) it gets removed from the network and will have to be re-announced. (0069-VCBS-028) for product spot: (0069-VCBS-115) +1. Verify that at the beginning of epoch an event is emitted for every validator known to Vega with their respective ranking scores. (0069-VCBS-025) +1. Verify the ranking score is available through the epoch/validator/`rankingScore` API in the data-node. (0069-VCBS-026) +1. Verify that the `rankingScore` is always equal to `performanceScore` x `stakeScore` x `incumbentBonus` (for tendermint validators and ersatz validators) Note: `network.validators.incumbentBonus` is a network parameter that is applied as a factor (1 + `incumbentBonus` network parameter) on `performanceScore` x `stakeScore`. (0069-VCBS-027) +1. Verify that if a node has a 0 `rankingScore` for 1e6 blocks (corresponding to around 11.5 days) it gets removed from the network and will have to be re-announced. (0069-VCBS-028) ### Stake scores -1. No stake (0069-VCBS-029) for product spot: (0069-VCBS-116): +1. No stake (0069-VCBS-029): - Setup a network with 5 validators with no delegation - Verify that the `stakeScore` for all of validators is 0 -1. Equal stake (0069-VCBS-030) for product spot: (0069-VCBS-117): +1. Equal stake (0069-VCBS-030): - Setup a network with 5 validators, delegate to each of validator an equal stake - Verify that the `stakeScore` of each of them is 0.2. -1. Stake change (0069-VCBS-031) for product spot: (0069-VCBS-118): +1. Stake change (0069-VCBS-031): - Setup a network with 5 validators with 1000 tokens delegated to each. - Verify `stakeScore` at the end of the epoch is 0.2. - Change the stake of each validator by adding 100 * the index of the validator (i=1..5). - Verify that at the end of the epoch the `stakeScore` of each validator equals (1000 + i * 100)/5500 -1. Stake change 2 (0069-VCBS-032) for product spot: (0069-VCBS-119): +1. Stake change 2 (0069-VCBS-032): - Setup a network with 5 validators with 1000 tokens delegated to each - Undelegate from one validator 1000 tokens. - Verify that, at the end of the epoch, each of the 4 validators with tokens still delegated has a `stakeScore` of 0.25 and the validator with no tokens delegated has a 0 `stakeScore`. -1. Node joining (0069-VCBS-033) for product spot: (0069-VCBS-120): +1. Node joining (0069-VCBS-033): - Setup a network with 4 validators, each with 1000 tokens delegated. - Announce a new node and delegate it 1000 tokens - Verify that the `stakeScore` of all nodes is 0.2 at the beginning of the next epoch. Note: for the first 4 validators this is changing from 0.25 in the previous epoch to 0.2 in the next. ## Promotions/Demotions -1. Announce node (0069-VCBS-034) for product spot: (0069-VCBS-121): +1. Announce node (0069-VCBS-034): - Verify that a node node, once added successfully to the topology, is shown on data-node API with the status pending -1. Promote a node to become an ersatz validator (0069-VCBS-035) for product spot: (0069-VCBS-122): +1. Promote a node to become an ersatz validator (0069-VCBS-035): - Set up a network with no existing ersatz validators - Ensure that the number of ersatz validators allowed in the network is is greater than 0 using the network parameter `network.validators.ersatz.multipleOfTendermintValidators` - Announce a new node on the network - Verify the new node gets promoted to an ersatz validator Note: ensure there are no available slots for Tendermint validators so the new node doesn’t get promoted directly to become a Tendermint validator. -1. Demote a Tendermint validator due to lack of slots (0069-VCBS-036) for product spot: (0069-VCBS-123): +1. Demote a Tendermint validator due to lack of slots (0069-VCBS-036): - Setup a network with 4 Tendermint validators - Change the network parameter `network.validators.tendermint.number` to 3 Tendermint validators - Verify that the Tendermint validator with the lowest score is demoted to an ersatz validator at the beginning of the next epoch -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-062) for product spot: (0069-VCBS-124): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-062): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. @@ -334,20 +332,20 @@ for product spot: (0069-VCBS-0890069-VCBS-063) for product spot: (0069-VCBS-125): +1. Try to demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-063): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. - Ensure that the threshold on the multisig is set to `900`. - Change the network parameter `network.validators.tendermint.number` to 3 Tendermint validators. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 6 consensus (Tendermint) validators. -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-064) for product spot: (0069-VCBS-126): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-064): - Setup a network with 3 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 3 validators. - Ensure that the threshold on the multisig is set to `666`. - Change the network parameter `network.validators.tendermint.number` to 2 Tendermint validators. - Verify that no consensus forming validator is removed at the start of the next epoch and we are running with 3 consensus (Tendermint) validators. -1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-065) for product spot: (0069-VCBS-127): +1. Demote a number of consensus forming (Tendermint) validators due to lack of slots (0069-VCBS-065): - Run with `network.validators.ersatz.multipleOfTendermintValidators = 1` - Setup a network with 6 consensus forming (Tendermint) validators - Ensure that the multisig is updated to those 6 validators. @@ -358,28 +356,28 @@ for product spot: (0069-VCBS-0890069-VCBS-037) for product spot: (0069-VCBS-128): +1. Demote an ersatz validator due to lack of slots (0069-VCBS-037): - Setup a network with 4 tendermint validators, and 2 ersatz validators. - Change the ersatz network parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.25 of the Tendermint validators - Verify that the ersatz validator with the lowest score is demoted to pending at the beginning of the next epoch -1. Promotion a node to become a Tendermint validator (0069-VCBS-038) for product spot: (0069-VCBS-129): +1. Promotion a node to become a Tendermint validator (0069-VCBS-038): - Setup a network with 5 validators (and 5 slots for tendermint validators). - Do not self-delegate to them. - Announce a new node and self-delegate to them. - Verify that at the beginning of the next epoch one of the validators which were Tendermint validators before is chosen at random and is demoted to ersatz validator. - Verify the announced validator is promoted to be Tendermint validator with voting power = 10000. -1. Promotion + swap (0069-VCBS-039) for product spot: (0069-VCBS-130): +1. Promotion + swap (0069-VCBS-039): - Setup a network with 4 validators with self-delegation such that the number of Tendermint nodes (with the `network.validators.tendermint.number` parameter set to 5). - In the following epoch, remove the self-delegation from node 1, and announce 2 nodes. - During the epoch self-delegate to the two nodes. - Wait for 3 epochs to allow performance of the new nodes to be greater than 0. - Verify that, once the performance is greater than zero, the two nodes should be promoted to Tendermint validators and their voting power should be equal to their relative stake x their performance score x 10000. -1. Swap last due to performance (0069-VCBS-040) for product spot: (0069-VCBS-131): +1. Swap last due to performance (0069-VCBS-040): - Setup a network with 5 validators with self-delegation. - Announce a new node and self-delegate to it. - Once it gets to a performance score of 0.2, shut down two of the 5 Tendermint validators after 0.1 of the duration of the epoch, e.g. if the epoch is 5 minutes, that means after 30 seconds of the epoch they should be stopped. - Verify that at the beginning of the next epoch, expect the performance score of the two stopped validators is <= 0.1, and one of them chosen at random is demoted to ersatz validator and is replaced by the announced nodes as a Tendermint validator with voting power =~ 0.2 * `stake_of_validator` / `total_stake_network` -1. Number of slots increased (0069-VCBS-041) for product spot: (0069-VCBS-132): +1. Number of slots increased (0069-VCBS-041): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Announce a new node, DO NOT self-delegate to it. - Run for an epoch and assert the validator is shown as pending. @@ -387,7 +385,7 @@ for product spot: (0069-VCBS-0890069-VCBS-042) for product spot: (0069-VCBS-133): +1. Swap due to better score (0069-VCBS-042): - Setup a network with 5 Tendermint validators and self-delegate 1000 tokens to each of them. - Announce a new node at the beginning of the epoch, self-delegate to them a total that is 10000 tokens. - At the beginning of the next epoch the new validator should have ranking score *equal or lower* to all of the Tendermint validators so it doesn’t get promoted. The parameter is set sufficiently high to assure this (e.g., 1.1). @@ -395,7 +393,7 @@ for product spot: (0069-VCBS-0890069-VCBS-043) for product spot: (0069-VCBS-134): +1. 2 empty spots, only one available to replace (0069-VCBS-043): - Setup a network with 5 slots for Tendermint validators and 3 actual Tendermint validators. - Self-delegate to all of them. - Announce 2 new nodes but self-delegate only to one of them. @@ -403,7 +401,7 @@ for product spot: (0069-VCBS-0890069-VCBS-053) for product spot: (0069-VCBS-135) +1. `Ownstake` scenario1 (0069-VCBS-053) - Network with 3 tendermint validators and 7 ersatz validators - In the same epoch, change the network parameter `reward.staking.delegation.minimumValidatorStake` in a way that 3 tendermint validators and 3 ersatz validators drop below the `ownstake` requirement, and change the delegation so that 4 (not affected) Ersatz validators have a higher score than two (not affected) Validators. Also, give one of the Ersatz validators with insufficient `ownstake` the highest stake (delegated) of all Ersatz validators. - At the end of the epoch all validators with insufficient own stake will get a ranking score of 0. @@ -411,7 +409,7 @@ for product spot: (0069-VCBS-0890069-VCBS-073) for product spot: (0069-VCBS-136) +1. `Ownstake` scenario2 (0069-VCBS-073) Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -419,7 +417,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 1 ersatz validator has 6000 stake and sufficient `ownstake` - the pending validator has sufficient `ownstake` - Verify that the first ersatz validator is removed (marked as pending in the epoch change and then removed due to continuous insufficient `ownstake`), and one validator with insufficient `ownstake` is replaced by the other ersatz validator. -1. `Ownstake` scenario3 (0069-VCBS-074) for product spot: (0069-VCBS-137) +1. `Ownstake` scenario3 (0069-VCBS-074) 1. Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -427,7 +425,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - the pending validator has sufficient `ownstake` - Verify that at the epoch change, the validator with insufficient `ownstake` is replaced; in the next epoch, the second validator with the lowest score is replaced, and the validator that was demoted to ersatz validator due to insufficient `ownstake` is removed (stops being listed as an ersatz validator). - Verify that the validator that dropped below `ownstake` is not demoted and removed at the same epoch change. -1. `Ownstake` scenario4 (0069-VCBS-075) for product spot: (0069-VCBS-138) +1. `Ownstake` scenario4 (0069-VCBS-075) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - one ersatz validator gets the highest delegated stake, but insufficient `ownstake` (delegates: 10000) - 2 validators drop below `ownstake`, but have relative high delegated stake (7000) @@ -435,7 +433,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - 1 ersatz validator has 6000 stake and sufficient `ownstake` - Verify that the the first ersatz validator is not removed, and one validator with insufficient `ownstake` is replaced by the other ersatz validator. - Add a new pending validator with enough `ownstake`; verify that it replaces the ersatz validator that had insufficient `ownstake`. -1. `Ownstake` scenario5 (0069-VCBS-076) for product spot: (0069-VCBS-139) +1. `Ownstake` scenario5 (0069-VCBS-076) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators, no pending validator). In one epoch, - 1 validator drops below `ownstake`, but has relative high delegated stake (7000) - 2 validators drop to the lowest delegated stake (1000 and 1500, respectively) @@ -445,13 +443,13 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Reduce the `ownstake` of both ersatz validators to 0. Verify that both ersatz validators are now removed, and that the tendermint validator still stays a tendermint validator (let this run for at least 2 epochs). - Reduce the `ownstake` of another tendermint validator to 0. Verify that that tendermint validator is demoted, and the other one with insufficient `ownstake` is not. -1. `Ownstake` scenario6 (0069-VCBS-077) for product spot: (0069-VCBS-140) +1. `Ownstake` scenario6 (0069-VCBS-077) 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` - All ersatz validators have sufficient `ownstake`, but lower stake than the validators - Verify that one validator is replaced the following epoch, one in the epoch after -1. `Ownstake` scenario7 (0069-VCBS-078) for product spot: (0069-VCBS-141) +1. `Ownstake` scenario7 (0069-VCBS-078) -Verify that 2 validators are replaced, one in each epoch 1. Setup a network with 5 nodes (3 validators, 2 ersatz validators). In one epoch, - All validators drop below `ownstake` @@ -460,7 +458,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Ersatz Rewards -1. Ersatz validator reward (0069-VCBS-061) for product spot: (0069-VCBS-142) +1. Ersatz validator reward (0069-VCBS-061) - Setup a network with 5 validators with the following distribution of delegation: - 10%, 10%, 10%, 10%. 60% of the total delegation of tendermint validators - Setup 5 ersatz validators each with the minimum delegation at the end of the epoch verify that the stake score of the validator with 60% of the delegation (under reward) is anti-whaled @@ -470,7 +468,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the validator, run until the end of the epoch - Verify that this validator is paid reward as ersatz validator and that their stake score under reward is anti-whaled -1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) for product spot: (0069-VCBS-143) +1. Change `network.validators.ersatz.rewardFactor` (0069-VCBS-057) - Setup a network with 5 Tendermint validators, 3 Ersatz Validators, `network.validators.ersatz.rewardfactor` = 0 - Verify that at the end of the Epoch, the Ersatz Validators get no reward - Increase the `rewardFactor` to 0.5 @@ -482,19 +480,19 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Slot Adjustments -1. Number of slots decreased (0069-VCBS-052) for product spot: (0069-VCBS-144): +1. Number of slots decreased (0069-VCBS-052): - Setup a network with 5 Tendermint validators, self-delegate to them (set the parameter `network.validators.tendermint.number` to 5, set the `network.validators.ersatz.multipleOfTendermintValidators` parameter to 0 so there are no ersatz validators allowed). - Decrease the number of tendermint validators to 3. - Verify that in each of the following two epochs, the validator with the lowest score is demoted to Ersatz validator and an Ersatz validator is demoted to pending -1. Number of Ersatz validators increased (0069-VCBS-058) for product spot: (0069-VCBS-145): +1. Number of Ersatz validators increased (0069-VCBS-058): - Setup a network with 4 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.9 - Verify that in the following epoch, the Ersatz Validator with the highest score is promoted to Validator -1. Number of Ersatz validators decreased (0069-VCBS-054) for product spot: (0069-VCBS-146): +1. Number of Ersatz validators decreased (0069-VCBS-054): - Setup a network with 5 Tendermint validators, 3 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5) - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.1 - Verify that in the following to epoch, all the Ersatz Validators are demoted to pending -1. Number of Ersatz validators Erratic (0069-VCBS-055) for product spot: (0069-VCBS-147): +1. Number of Ersatz validators Erratic (0069-VCBS-055): - Setup a network with 5 Tendermint validators, 2 Ersatz Validators (`network.validators.ersatz.multipleOfTendermintValidators` = 0.5), and 2 pending validators - Change the parameter `network.validators.ersatz.multipleOfTendermintValidators` to 0.9 - Verify that in the next epoch the 2 pending validators are promoted to ersatz @@ -503,52 +501,51 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Two epochs later, change `network.validators.ersatz.multipleOfTendermintValidators` to 0.5 - Verify that in the next epoch the 2 pending validators are promoted to ersatz - Verify that in the last epoch, no demotions/promotions happen and the number of Ersatz validators stays at 2 -1. Number of Ersatz Validators oddly defined (0069-VCBS-056) for product spot: (0069-VCBS-148) +1. Number of Ersatz Validators oddly defined (0069-VCBS-056)d - Set the factor to 0.00000000000000000000000000000000000000001 - Verify that all Validators round it the same way, and that there are no Ersatz validators - Set the factor to 3.00000000000000000000000000000000000000001 and run the network with just one tendermint (consensus) validator. - Verify that all Validators round it the same way, and that there are three Ersatz validators -1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) for product spot: (0069-VCBS-149) -1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070) for product spot: (0069-VCBS-150). - 1. Restart from checkpoint ((0069-VCBS-080) for product spot: (0069-VCBS-151)), all validator nodes are still correct. -1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) for product spot: (0069-VCBS-152) +1. Demote one of the original validators and replace with a new validator. Update the multisig to include the new validator. Ensure multisig threshold is set to '999' (require all signatures). Attempt a withdrawal. (0069-VCBS-069) +1. On a network with n original validators, gradually replace (via demotion of existing node and promotion of a new node) and stop all of the original validators. (Original nodes not even participating as ersatz or pending). Ensure that consensus continues, and that asset withdrawals are possible. (0069-VCBS-070). Restart from checkpoint ((0069-VCBS-080)), all validator nodes are still correct. +1. Ensure multisig threshold is set to '666'. Request an asset withdrawal (but do not yet exercise this in the er20 bridge). Demote one of the original validators and replace with a new validator. Update the multisig. Attempt to enact the withdrawal on the erc20 bridge. Funds are received by the party on eth chain, and are no longer present in vega chain account(s). (0069-VCBS-072) ### Announce Node -1. Invalid announce node command (0069-VCBS-044) for product spot: (0069-VCBS-153): +1. Invalid announce node command (0069-VCBS-044): - Send an announce node command from a non validator node should fail -1. Valid announce node command (0069-VCBS-045) for product spot: (0069-VCBS-156): +1. Valid announce node command (0069-VCBS-045): - Send a valid announce node from a validator node should result in a validator update event with the details of the validator and a validator ranking event. -1. Node announces using same keys as existing node via announce node command (0069-VCBS-060) for product spot: (0069-VCBS-157): +1. Node announces using same keys as existing node via announce node command (0069-VCBS-060): - Should be rejected ### Checkpoints -1. Base case (0069-VCBS-046) for product spot: (0069-VCBS-158): +1. Base case (0069-VCBS-046): - Setup a network with 5 Tendermint validators - Take a checkpoint - Restore from checkpoint with the 5 same validators, which should pass. - Verify that after the network is restarted, the validators have voting power as per the checkpoint until the end of the epoch. -1. Base + ersatz (0069-VCBS-047) for product spot: (0069-VCBS-159): +1. Base + ersatz (0069-VCBS-047): - Setup a network with 5 Tendermint validators (where 5 is also the number of allowed Tendermint validators) - Announce 2 new nodes and wait for them to become ersatz validators (set the network parameter `network.validators.minimumEthereumEventsForNewValidator` to 0). - Take a checkpoint and verify it includes the ersatz validators. - Restore from the checkpoint (all nodes are running) - Verify that the validators have the voting power as per the checkpoint and that the ersatz validators are shown on data node having status ersatz. -1. Missing validators (0069-VCBS-048) for product spot: (0069-VCBS-160): +1. Missing validators (0069-VCBS-048): - Setup a network with 5 validators such that 3 of them have 70% of the voting power. Note: this is done by delegating 70% of the total stake to them. - Take a checkpoint - Restore from the checkpoint – starting only the 3 nodes with the 70% stake. - Verify that after the restore the network should be able to proceed generating blocks although with slower pace. -1. Missing validators stop the network (0069-VCBS-049) for product spot: (0069-VCBS-161): +1. Missing validators stop the network (0069-VCBS-049): - Setup a network with 5 validators with equal delegation to them. - Verify before the checkpoint that the voting power of all of them is equal. - Take a checkpoint. - Restart the network starting only 3 of the validators. - Restore from the checkpoint. - Verify the network is not able to produce blocks. -1. Checkpoints store validator changes (0069-VCBS-079) for product spot: (0069-VCBS-162): +1. Checkpoints store validator changes (0069-VCBS-079): - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). - Stop and relegate one of the original validators (v1) such that v6 is promoted to tendermint validator, and v7 is promoted to ersatz. - Restart v1 and announce to pending. @@ -556,7 +553,7 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid - Restart the network - Verify that v2-v6 are tendermint validators, v7 is ersatz and v1 is pending. - Verify that all stakes and delegations are correct for each node. -1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088) for product spot: (0069-VCBS-163): +1. Validator, ersatz and pending node scores for current epoch are persisted in checkpoints (0069-VCBS-088): - Setup a network with 5 validators with non-equal delegation (v1-v5), 1 ersatz validator (v6) and 1 pending validator (v7). - Take a checkpoint. - Wait until the current epoch will have expired. @@ -567,44 +564,46 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Multisig update -1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-VCBS-002) for product spot: (0069-VCBS-164) -1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-VCBS-003) for product spot: (0069-VCBS-165) -1. It is possible to submit a transaction to update the weights. (0069-VCBS-004) for product spot: (0069-VCBS-177) -1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) for product spot: (0069-VCBS-166) +1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002) +1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003) +1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004) +1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) for product spot: (0069-VCBS-167) +1. No rewards paid out if multisig not updated. Rewards continued when fixed. (0069-VCBS-067) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. + - Arrange for one of the validators to be demoted and the ersatz validator to be promoted. - Verify that no rewards are paid out on the first epoch. - Update the multisig contract by removing the demoted validator, and adding the new tendermint validator. - Verify that rewards are paid out at the end of the epoch. -1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) for product spot: (0069-VCBS-168) -1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) for product spot: (0069-VCBS-169) +1. Any vega key with number of governance tokens more than or equal to `spam.protection.minMultisigUpdates` or a vega key that belongs to a validator can submit a request to the vega network to obtain the signature bundle that would update the ethereum multisig signers to be the ethereum keys of the current consensus (tendermint) validators up to `network.validators.multisig.numberOfSigners`. This request can only be submitted once per epoch per vega key. Once multisig uses weights it will also include the correct weights. (0069-VCBS-068) +1. Replace a validator with a new node via promotion/demotion. Ensure that rewards are paid out at the end of the epoch if the multisig is updated to match the new validator. (0069-VCBS-071) ### Re-Issuing Signature Bundles by non Validators 1. Submit two `IssueSignature` requests from the same Vega-Key (but for different bundles) for the same block. Verify that only one of the requests is executed, but both pass consensus. (Note: This AC may need replacement with the new Tendermint API). Repeat this test for in the next epoch and verify that the result is the same. -(0069-VCBS-081) for product spot: (0069-VCBS-170) +(0069-VCBS-081) 1. Submit two `IssueSignature` requests from the same Vega Key (but for different bundles) so that they are proposed for different blocks. Verify that the second one does not make it through consensus, but gets rejected earlier. Repeat this rest in the next epoch and verify that the result is the same. -(0069-VCBS-082) for product spot: (0069-VCBS-171) +(0069-VCBS-082) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys, in a way that they end up in the same block. Verify that both get executed. -(0069-VCBS-083) for product spot: (0069-VCBS-172) +(0069-VCBS-083) 1. Submit two `IssueSignature` requests for the same bundle from different Vega keys in different blocks. Verify that both get executed. -(0069-VCBS-084) for product spot: (0069-VCBS-173) +(0069-VCBS-084) 1. Take three Vega keys V1, V2 and V3. Submit for the same bundle in the same block 2 `IssueSignature` requests from V1 and one from V2. Verify that all three pass consensus, and that one request from V1 and one from V2 are executed. In a following block, submit one `IssueSignature` request from V1 and V2 each, and 2 from V3. Verify that the ones from V1 and V2 are rejected pre-consensus, both from V3 pass consensus, and one from V3 is executed. -(0069-VCBS-085) for product spot: (0069-VCBS-174) +(0069-VCBS-085) 1. Issue a request from a Vega key with a wrong signature. Verify that it is rejected pre-consensus. Issue a correct request from that key in a following block and verify that it is correctly executed. -(0069-VCBS-086) for product spot: (0069-VCBS-175) +(0069-VCBS-086) 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. -(0069-VCBS-087) for product spot: (0069-VCBS-176) +(0069-VCBS-087) + From 9d3e6971783c66b844a4be22674644ffebf5adba Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 13 Jul 2023 17:19:21 +0200 Subject: [PATCH 286/649] fix: add intra-block SLA sampling --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 17 ++++------------- protocol/0044-LIME-lp_mechanics.md | 1 - 2 files changed, 4 insertions(+), 14 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 4eeb1118f..4d0a71951 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -223,24 +223,15 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP - If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -- At start of block, set `block_sla_met = true` and `k` to `0` and then after every `market.liquidity.sla.evalEveryNumOfTransactions` transactions have been processed set `k` to the transaction number of the just processed transaction. - -- In each block, immediately after processing transaction `k`: - - - Note that this happens _after_ iceberg orders, that need refreshing as a result of transaction `k` are refreshed. - This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. - - - if an LP is *not* meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") set `block_sla_met = false` +- At start of block, for LP `i`, reset the running minimim valid volume an LP is providing and across the block keep updating the minimum volume that the LP is providing that is [within the valid range](./0044-LIME-lp_mechanics.md) (section "Meeting the committed volume of notional"). +- Note that the volume check must only happen _after_ iceberg orders, that need refreshing as a result of a transaction are refreshed. This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. - At the end of each block: - - If `block_sla_met = true` and if an LP has started meeting their [committed volume of notional](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): - + - If an LP has started meeting their [committed volume of notional based on the minimum volume recorded during the block](./0044-LIME-lp_mechanics.md) (section "Calculating liquidity from commitment") after previously not doing so (i.e. `nothing` is stored as the time the LP began meeting their commitment): - Store the current Vega time attached to the block being processed as the time the LP began meeting their commitment. - - If `block_sla_met = false ` and an LP has stopped meeting their committed volume of notional after previously doing so: - + - If an LP has stopped meeting their committed volume of notional after previously doing so: - Add the difference in nanoseconds between the current Vega time attached to the block being processed and the time the LP began meeting their commitment (stored in the step above) to `s_i`. - - Store `nothing` as the time the LP began meeting their commitment, to signify the LP not meeting their commitment. - At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 751a59a36..4a2c84f79 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,7 +23,6 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. -- `market.liquidity.sla.evalEveryNumOfTransactions` sets how many transactions in a block are processed before each party that's committed to providing liquidity is evaluated for meeting (or not) their commitment. ### Market parameters From 5f8ed1a13fdeebb6196f2fd945582f6ba755c754 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 13 Jul 2023 17:20:18 +0200 Subject: [PATCH 287/649] fix: add intra-block SLA sampling --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 4d0a71951..45b3b2691 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -223,7 +223,7 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP - If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -- At start of block, for LP `i`, reset the running minimim valid volume an LP is providing and across the block keep updating the minimum volume that the LP is providing that is [within the valid range](./0044-LIME-lp_mechanics.md) (section "Meeting the committed volume of notional"). +- At start of block, for LP `i`, first reset the running minimim valid volume an LP is providing and across the block and then keep updating the minimum volume that the LP is providing that is [within the valid range](./0044-LIME-lp_mechanics.md) (section "Meeting the committed volume of notional"). - Note that the volume check must only happen _after_ iceberg orders, that need refreshing as a result of a transaction are refreshed. This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. - At the end of each block: From af98527f1ef67d10565a142bbf65239915c21c25 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 13 Jul 2023 18:11:36 +0200 Subject: [PATCH 288/649] feat: update ACs for spec 0080 --- protocol/0080-SPOT-product_builtin_spot.md | 38 ++++++++++++++-------- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 15c37e4ac..d5f3a0ed7 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -85,33 +85,32 @@ Both buy and sell orders on a `Spot` market define a size (amount of the `base_a ### Sell Orders -For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid.(0080-SPOT-008) +For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid. -If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-009) +If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. -If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SPOT-010) +If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`. ### Buy Orders -As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) +As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered. #### Continuous Trading -For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) +For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor). -If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SPOT-013). As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SPOT-014). If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) +If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. #### Entering an Auction -When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SPOT-016). If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). +When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled. +For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction. -For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SPOT-018). - -If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SPOT-019). +If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`. #### Exiting an Auction -When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SPOT-020). +When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order. ## 8. Auctions @@ -125,6 +124,19 @@ Price-monitoring auctions are still required and should be implemented following 1. It is not possible to change the `quote_asset` via governance (0080-SPOT-002) 1. It is not possible to change the `base_asset` via governance (0080-SPOT-003) 1. A `Spot` market can be closed through governance (0080-SPOT-004) -1. Parties are unable to place orders they do not have the necessary funds for (0080-SPOT-005) 1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-SPOT-006) -1. Market liquidity fees are calculated correctly (0080-SPOT-007) +1. If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`.(0080-SPOT-009) +1. As "sell" orders require a party to hold a sufficient amount of the `base_asset` to fulfil the size of the order, the individual cases where fees can be incurred do not need to be considered as if a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SPOT-010) +1. As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) +1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) +1. If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SPOT-013). +1. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SPOT-014). +1. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) +1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SPOT-016). +1. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). +1. For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SPOT-018). +1. If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SPOT-019). +1. When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SPOT-020). + + + From 28246ae8b54b27e41d0ccc7e2a0fb726a6b17be7 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 14 Jul 2023 08:09:38 +0100 Subject: [PATCH 289/649] Update git hub actions action permissions (#1830) --- .github/workflows/add_issue_new_projects.yml | 2 +- .github/workflows/add_pr_new_projects.yml | 2 +- .github/workflows/quality_check.yml | 12 ++++++------ .../0053-PERP-product_builtin_perpetual_future.md | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/.github/workflows/add_issue_new_projects.yml b/.github/workflows/add_issue_new_projects.yml index 6fb940774..366c5dac1 100644 --- a/.github/workflows/add_issue_new_projects.yml +++ b/.github/workflows/add_issue_new_projects.yml @@ -8,7 +8,7 @@ name: "Add Issues To Project Board" types: - opened env: - GH_TOKEN: ${{ secrets.GH_NEW_CARD_TO_PROJECT }} + GH_TOKEN: ${{ secrets.PROJECT_MANAGE_ACTION }} PROJECT_ID: ${{ secrets.PROTOCOL_DESIGN_PROJECT_ID }} ISSUE_ID: ${{ github.event.issue.node_id }} USER: ${{ github.actor }} diff --git a/.github/workflows/add_pr_new_projects.yml b/.github/workflows/add_pr_new_projects.yml index 9557154a3..414147e66 100644 --- a/.github/workflows/add_pr_new_projects.yml +++ b/.github/workflows/add_pr_new_projects.yml @@ -8,7 +8,7 @@ name: "Add IPRs To Project Board" types: - opened env: - GH_TOKEN: ${{ secrets.GH_NEW_CARD_TO_PROJECT }} + GH_TOKEN: ${{ secrets.PROJECT_MANAGE_ACTION }} PROJECT_ID: ${{ secrets.PROTOCOL_DESIGN_PROJECT_ID }} PR_ID: ${{ github.event.pull_request.node_id }} USER: ${{ github.actor }} diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index d90c2e85a..2ac04678c 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -19,7 +19,7 @@ jobs: runs-on: ubuntu-latest steps: - name: "Check out" - uses: actions/checkout@v3 + uses: actions/checkout@v3.5.3 - name: "Run Yamllint" uses: ibiqlik/action-yamllint@v3.1.1 @@ -31,10 +31,10 @@ jobs: runs-on: ubuntu-latest steps: - name: "Check out" - uses: actions/checkout@v3 + uses: actions/checkout@v3.5.3 - name: "Run PySpelling" - uses: rojopolis/spellcheck-github-actions@0.24.0 + uses: rojopolis/spellcheck-github-actions@0.33.1 with: task_name: Markdown @@ -43,10 +43,10 @@ jobs: runs-on: ubuntu-latest steps: - name: "Check out" - uses: actions/checkout@v3 + uses: actions/checkout@v3.5.3 - name: "Run Markdownlint" - uses: nosborn/github-action-markdown-cli@v3.1.0 + uses: nosborn/github-action-markdown-cli@v3.3.0 with: files: . config_file: .github/workflows/config/markdownlint.json @@ -57,7 +57,7 @@ jobs: runs-on: ubuntu-latest steps: - name: "Check out" - uses: actions/checkout@v3 + uses: actions/checkout@v3.5.3 - name: "Run Check AC codes" run: | diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 9e9a7da2a..799143c1d 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -31,7 +31,7 @@ The pseudocode below specifies a possible configuration of the built-in perpetua - every 168h from 20230203T12:00:00 settlement_data: data_source: SignedMessage{ pubkey=0xA45e...d6 } - filters: + filters: - 'timestamp': >= vegaprotocol.builtin.timestamp - 'timestamp': <= vegaprotocol.builtin.timestamp + "10s" - 'ticker': 'TSLA' @@ -163,7 +163,7 @@ If periodic settlement data happens whilst market is in auction of any other typ ### 5. Margin considerations To assure adequate solvency we need to include the estimate of the upcoming funding payment in maintenance margin estimate for the party. Let $t_{k-1}$ be the time of the last funding payment. Let $t$ be current time ($t < t_k$). -Calculate $G_t$ as the [funding payment](#44-periodic-settlement) between $t_{k-1}$ and $t$. +Calculate $G_t$ as the [funding payment](#43-periodic-settlement) between $t_{k-1}$ and $t$. For perpetual futures markets set the maintenance margin as: ```math From 47d77ea034a40339153038067ccb27625f78ead4 Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 14 Jul 2023 09:25:50 +0100 Subject: [PATCH 290/649] fix: markdown linting --- protocol/0013-ACCT-accounts.md | 8 ++++---- protocol/0080-SPOT-product_builtin_spot.md | 11 ++++------- 2 files changed, 8 insertions(+), 11 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index fdf0379ce..fb106ac90 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -102,10 +102,10 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Party asset accounts -- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003) - - Only one general asset account exists per party per asset. (0013-ACCT-004) - - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005) - - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) +- Every party that deposits an asset on Vega will have an asset account created for that asset. (0013-ACCT-003) + - Only one general asset account exists per party per asset. (0013-ACCT-004) + - When a party deposits collateral onto Vega, the asset account will increase in balance by the same amount. (0013-ACCT-005) + - When a party withdraws collateral onto Vega, the asset account for that asset will decrease in balance by the same amount. (0013-ACCT-006) - [Fees earned from liquidity provision](./0044-LIME-lp_mechanics.md#fees) are paid in to this account. (0013-ACCT-011) ### Party margin accounts diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index d5f3a0ed7..a54a9314e 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -129,14 +129,11 @@ Price-monitoring auctions are still required and should be implemented following 1. As "sell" orders require a party to hold a sufficient amount of the `base_asset` to fulfil the size of the order, the individual cases where fees can be incurred do not need to be considered as if a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SPOT-010) 1. As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) 1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) -1. If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SPOT-013). -1. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SPOT-014). -1. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) -1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SPOT-016). +1. If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SPOT-013). +1. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SPOT-014). +1. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) +1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SPOT-016). 1. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). 1. For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SPOT-018). 1. If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SPOT-019). 1. When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SPOT-020). - - - From 768a821cf41c7c60ba791ede283d5d52967be221 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 14 Jul 2023 11:15:57 +0200 Subject: [PATCH 291/649] fix: add intra-block SLA sampling --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 45b3b2691..9666b1258 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -223,7 +223,7 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP - If the LP is meeting their commitment, store the Vega time of the start of the epoch as the time the LP began meeting their commitment, otherwise store `nothing`. -- At start of block, for LP `i`, first reset the running minimim valid volume an LP is providing and across the block and then keep updating the minimum volume that the LP is providing that is [within the valid range](./0044-LIME-lp_mechanics.md) (section "Meeting the committed volume of notional"). +- At start of block, for LP `i`, first reset the running minimum valid volume an LP is providing and across the block and then keep updating the minimum volume that the LP is providing that is [within the valid range](./0044-LIME-lp_mechanics.md) (section "Meeting the committed volume of notional"). - Note that the volume check must only happen _after_ iceberg orders, that need refreshing as a result of a transaction are refreshed. This means that while an iceberg order has sufficient `remaining` quantity, it will **never** be considered to be contributing less than its `minimum peak size`. - At the end of each block: @@ -236,7 +236,7 @@ During the epoch, the amount of time in nanoseconds (of Vega time) that each LP - At the end of the epoch, calculate the actual observed epoch length `observed_epoch_length` = the difference in nanoseconds between the Vega time at the start of the epoch and the Vega time at the end of the epoch. -Note that because vega time won't be progressing intra-block the above mechanism should ensure that `s_i` gets incremented only if the LP was meeting their commitment at every point this was checked within the block. +Note that because vega time won't be progressing inside a block the above mechanism should ensure that `s_i` gets incremented only if the LP was meeting their commitment at every point this was checked within the block. #### Calculating the SLA performance penalty for a single epoch From 264273c355ecb5ca396e01a69d18449b1d3bb93c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 14 Jul 2023 11:24:48 +0200 Subject: [PATCH 292/649] feat: update AC 0026-AUCT-029 --- protocol/0026-AUCT-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 197662c83..b277c8004 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -168,7 +168,7 @@ message Market { - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) for product spot: (0026-AUCT-029) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) for product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) for product spot: (0026-AUCT-030) 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) From 2d37fe6c1cebbb57ecc262bd6e24ebeac3b4e99a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 14 Jul 2023 11:33:27 +0200 Subject: [PATCH 293/649] chore: tidy up --- protocol/0080-SPOT-product_builtin_spot.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index a54a9314e..355458bfe 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -125,15 +125,15 @@ Price-monitoring auctions are still required and should be implemented following 1. It is not possible to change the `base_asset` via governance (0080-SPOT-003) 1. A `Spot` market can be closed through governance (0080-SPOT-004) 1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-SPOT-006) -1. If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`.(0080-SPOT-009) -1. As "sell" orders require a party to hold a sufficient amount of the `base_asset` to fulfil the size of the order, the individual cases where fees can be incurred do not need to be considered as if a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`.(0080-SPOT-010) +1. If a "sell" order does not trade immediately (or only trades in part), an amount of the base_asset should be transferred to a holding_account to cover the remaining size of the order for the base_asset.(0080-SPOT-009) +1. Since "sell" orders require a party to hold a sufficient amount of the base_asset to fulfill the order size, it is unnecessary to consider individual cases where fees may be incurred. If a "sell" order incurs fees through trading (i.e., by being the aggressor or trading in an auction), the required amount of the quote_asset to cover the fees will be deducted from the party's total quote_asset amount resulting from the sale of the base_asset.(0080-SPOT-010) 1. As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) 1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) -1. If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`(0080-SPOT-013). -1. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees(0080-SPOT-014). +1.If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). +1. Since the order can no longer be the aggressor during continuous trading, there is no longer a requirement to hold funds to cover fees.(0080-SPOT-014). 1. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) -1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction(0080-SPOT-016). +1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties' general_account to their respective holding_account to cover any potential fees resulting from the order trading in the auction.(0080-SPOT-016). 1. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). -1. For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction(0080-SPOT-018). -1. If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`(0080-SPOT-019). -1. When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order(0080-SPOT-020). +1. For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the quote_asset to cover the order size, as well as any potential fees that may be incurred due to the order trading in the auction.(0080-SPOT-018). +1. If the fee rates change for any reason within an auction, the amount required to cover fees must be recalculated, and the necessary amount should be transferred to or released from the holding_account.(0080-SPOT-019). +1. When exiting an auction, for any orders that are still open, the funds held in the parties' holding_account to cover potential fees can be released to their respective general_account, so that the remaining amount in the holding_account is only sufficient to cover the value of the order.(0080-SPOT-020). From d7014cdd9b9e6e053e88b3ce27cc94c121772273 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 14 Jul 2023 11:55:10 +0200 Subject: [PATCH 294/649] chore: typo --- protocol/0080-SPOT-product_builtin_spot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 355458bfe..b5a9c67d6 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -126,7 +126,7 @@ Price-monitoring auctions are still required and should be implemented following 1. A `Spot` market can be closed through governance (0080-SPOT-004) 1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-SPOT-006) 1. If a "sell" order does not trade immediately (or only trades in part), an amount of the base_asset should be transferred to a holding_account to cover the remaining size of the order for the base_asset.(0080-SPOT-009) -1. Since "sell" orders require a party to hold a sufficient amount of the base_asset to fulfill the order size, it is unnecessary to consider individual cases where fees may be incurred. If a "sell" order incurs fees through trading (i.e., by being the aggressor or trading in an auction), the required amount of the quote_asset to cover the fees will be deducted from the party's total quote_asset amount resulting from the sale of the base_asset.(0080-SPOT-010) +1. Since "sell" orders require a party to hold a sufficient amount of the base_asset to fulfil the order size, it is unnecessary to consider individual cases where fees may be incurred. If a "sell" order incurs fees through trading (i.e., by being the aggressor or trading in an auction), the required amount of the quote_asset to cover the fees will be deducted from the party's total quote_asset amount resulting from the sale of the base_asset.(0080-SPOT-010) 1. As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) 1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) 1.If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). From 2a6e53a67c71d826f2bbc2a73999ff933993385c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 14 Jul 2023 12:00:56 +0200 Subject: [PATCH 295/649] feat: update 0080 --- protocol/0080-SPOT-product_builtin_spot.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index b5a9c67d6..665d9453c 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -126,12 +126,11 @@ Price-monitoring auctions are still required and should be implemented following 1. A `Spot` market can be closed through governance (0080-SPOT-004) 1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-SPOT-006) 1. If a "sell" order does not trade immediately (or only trades in part), an amount of the base_asset should be transferred to a holding_account to cover the remaining size of the order for the base_asset.(0080-SPOT-009) -1. Since "sell" orders require a party to hold a sufficient amount of the base_asset to fulfil the order size, it is unnecessary to consider individual cases where fees may be incurred. If a "sell" order incurs fees through trading (i.e., by being the aggressor or trading in an auction), the required amount of the quote_asset to cover the fees will be deducted from the party's total quote_asset amount resulting from the sale of the base_asset.(0080-SPOT-010) -1. As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered.(0080-SPOT-011) +1. If a "sell" order incurs fees through trading, the required amount of the quote_asset to cover the fees will be deducted from the total quote_asset resulting from the sale of the base_asset.(0080-SPOT-010) 1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) 1.If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). -1. Since the order can no longer be the aggressor during continuous trading, there is no longer a requirement to hold funds to cover fees.(0080-SPOT-014). -1. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) +1. If the order is cancelled, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) +1. If the order's size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) 1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties' general_account to their respective holding_account to cover any potential fees resulting from the order trading in the auction.(0080-SPOT-016). 1. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). 1. For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the quote_asset to cover the order size, as well as any potential fees that may be incurred due to the order trading in the auction.(0080-SPOT-018). From 6992c7fe855d862f8c4f923e19324e65040c4e94 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 14 Jul 2023 12:04:34 +0200 Subject: [PATCH 296/649] feat: update duplicated AC --- protocol/0080-SPOT-product_builtin_spot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 665d9453c..128be213a 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -129,7 +129,7 @@ Price-monitoring auctions are still required and should be implemented following 1. If a "sell" order incurs fees through trading, the required amount of the quote_asset to cover the fees will be deducted from the total quote_asset resulting from the sale of the base_asset.(0080-SPOT-010) 1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) 1.If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). -1. If the order is cancelled, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) +1. If the order is cancelled, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-007) 1. If the order's size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) 1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties' general_account to their respective holding_account to cover any potential fees resulting from the order trading in the auction.(0080-SPOT-016). 1. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). From 1fa0fa11952db6b652b031ab3fb8abc8f6b33e02 Mon Sep 17 00:00:00 2001 From: Edd Date: Fri, 14 Jul 2023 11:29:53 +0100 Subject: [PATCH 297/649] Add features.json (#1831) * add acs to features mapping file * Update protocol/features.json Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Neaten up Address feedback --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/features.json | 44 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 protocol/features.json diff --git a/protocol/features.json b/protocol/features.json new file mode 100644 index 000000000..a3a1caae5 --- /dev/null +++ b/protocol/features.json @@ -0,0 +1,44 @@ +{ + "Governance Transfers": { + "milestone": "deployment-1", + "acs": [ "0028-GOVE-073", "0028-GOVE-074", "0028-GOVE-128", "0028-GOVE-119", "0028-GOVE-120", "0028-GOVE-132", "0028-GOVE-122", "0028-GOVE-077", "0028-GOVE-079", "0028-GOVE-081", "0028-GOVE-082", "0028-GOVE-083", "0028-GOVE-084", "0028-GOVE-085", "0028-GOVE-086", "0028-GOVE-087", "0028-GOVE-088", "0028-GOVE-089", "0028-GOVE-091", "0028-GOVE-092", "0028-GOVE-094", "0028-GOVE-095", "0028-GOVE-096", "0028-GOVE-099", "0028-GOVE-100", "0028-GOVE-101", "0028-GOVE-102", "0028-GOVE-130", "0028-GOVE-131", "0028-GOVE-103", "0028-GOVE-133", "0028-GOVE-129", "0028-GOVE-104", "0028-GOVE-105", "0028-GOVE-106", "0028-GOVE-107", "0028-GOVE-123", "0028-GOVE-124", "0028-GOVE-125", "0028-GOVE-126", "0028-GOVE-127" ] + }, + "Iceberg Orders": { + "milestone": "deployment-1", + "acs": ["0014-ORDT-039", "0014-ORDT-007", "0014-ORDT-008", "0014-ORDT-009", "0014-ORDT-010", "0014-ORDT-011", "0014-ORDT-012", "0014-ORDT-013", "0014-ORDT-014", "0014-ORDT-015", "0014-ORDT-016", "0014-ORDT-017", "0014-ORDT-018", "0014-ORDT-020", "0014-ORDT-021", "0014-ORDT-022", "0014-ORDT-023", "0014-ORDT-024", "0014-ORDT-025", "0014-ORDT-026", "0014-ORDT-027", "0014-ORDT-028", "0014-ORDT-029", "0014-ORDT-030", "0014-ORDT-031", "0014-ORDT-032", "0014-ORDT-033", "0014-ORDT-034", "0014-ORDT-037", "0014-ORDT-038", "0014-ORDT-035", "0014-ORDT-036", "0014-ORDT-069", "0014-ORDT-070" + ] + }, + "Stop Orders": { + "milestone": "deployment-1", + "acs": ["0014-ORDT-040", "0014-ORDT-041", "0014-ORDT-042", "0014-ORDT-043", "0014-ORDT-044", "0014-ORDT-045", "0014-ORDT-046", "0014-ORDT-047", "0014-ORDT-048", "0014-ORDT-049", "0014-ORDT-050", "0014-ORDT-051", "0014-ORDT-052", "0014-ORDT-053", "0014-ORDT-054", "0014-ORDT-055", "0014-ORDT-056", "0014-ORDT-058", "0014-ORDT-059", "0014-ORDT-060", "0014-ORDT-061", "0014-ORDT-062", "0014-ORDT-063", "0014-ORDT-064", "0014-ORDT-065", "0014-ORDT-066", "0014-ORDT-067", "0014-ORDT-068", "0014-ORDT-071", "0014-ORDT-072", "0014-ORDT-073", "0014-ORDT-074", "0014-ORDT-075", "0014-ORDT-076", "0014-ORDT-077", "0014-ORDT-078", "0014-ORDT-079", "0014-ORDT-080", "0079-TGAP-004", "0079-TGAP-005" + ] + }, + "Successor Markets": { + "milestone": "deployment-1", + "acs": ["0001-MKTF-006", "0001-MKTF-007", "0001-MKTF-008", "0001-MKTF-009", "0001-MKTF-010", "0028-GOVE-071", "0028-GOVE-072", "0028-GOVE-093", "0042-LIQF-031", "0042-LIQF-048", "0042-LIQF-033", "0042-LIQF-034", "0081-SUCM-001", "0081-SUCM-002", "0081-SUCM-003", "0081-SUCM-005", "0081-SUCM-006", "0081-SUCM-007", "0081-SUCM-008", "0081-SUCM-027", "0081-SUCM-009", "0081-SUCM-010", "0081-SUCM-011", "0081-SUCM-014", "0081-SUCM-018", "0081-SUCM-012", "0081-SUCM-023", "0081-SUCM-024", "0081-SUCM-013", "0081-SUCM-016", "0081-SUCM-017", "0081-SUCM-025", "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", "0081-SUCM-022" + ] + }, + "Perps": { + "milestone": "deployment-2", + "acs": ["0001-MKTF-005", "0053-PERP-001", "0053-PERP-002", "0053-PERP-003", "0053-PERP-004", "0053-PERP-005", "0053-PERP-006", "0053-PERP-007", "0053-PERP-008", "0053-PERP-009", "0053-PERP-015", "0053-PERP-016", "0053-PERP-017" + ] + }, + "Spot": { + "milestone": "deployment-2", + "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-026", "0013-ACCT-027", "0013-ACCT-028", "0013-ACCT-029", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0036-BRIE-004", "0036-BRIE-005", "0036-BRIE-006", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0069-VCBS-089", "0069-VCBS-090", "0069-VCBS-091", "0069-VCBS-092", "0069-VCBS-093", "0069-VCBS-094", "0069-VCBS-095", "0069-VCBS-096", "0069-VCBS-097", "0069-VCBS-098", "0069-VCBS-099", "0069-VCBS-100", "0069-VCBS-101", "0069-VCBS-102", "0069-VCBS-103", "0069-VCBS-104", "0069-VCBS-105", "0069-VCBS-106", "0069-VCBS-107", "0069-VCBS-108", "0069-VCBS-109", "0069-VCBS-110", "0069-VCBS-111", "0069-VCBS-112", "0069-VCBS-113", "0069-VCBS-114", "0069-VCBS-115", "0069-VCBS-116", "0069-VCBS-117", "0069-VCBS-118", "0069-VCBS-119", "0069-VCBS-120", "0069-VCBS-121", "0069-VCBS-122", "0069-VCBS-123", "0069-VCBS-124", "0069-VCBS-125", "0069-VCBS-126", "0069-VCBS-127", "0069-VCBS-128", "0069-VCBS-129", "0069-VCBS-130", "0069-VCBS-131", "0069-VCBS-132", "0069-VCBS-133", "0069-VCBS-134", "0069-VCBS-135", "0069-VCBS-136", "0069-VCBS-137", "0069-VCBS-138", "0069-VCBS-139", "0069-VCBS-140", "0069-VCBS-141", "0069-VCBS-142", "0069-VCBS-143", "0069-VCBS-144", "0069-VCBS-145", "0069-VCBS-146", "0069-VCBS-147", "0069-VCBS-148", "0069-VCBS-149", "0069-VCBS-150", "0069-VCBS-151", "0069-VCBS-152", "0069-VCBS-153", "0069-VCBS-154", "0069-VCBS-155", "0069-VCBS-156", "0069-VCBS-157", "0069-VCBS-158", "0069-VCBS-159", "0069-VCBS-160", "0069-VCBS-161", "0069-VCBS-162", "0069-VCBS-163", "0069-VCBS-164", "0069-VCBS-165", "0069-VCBS-166", "0069-VCBS-167", "0069-VCBS-168", "0069-VCBS-169", "0069-VCBS-170", "0069-VCBS-171", "0069-VCBS-172", "0069-VCBS-173", "0069-VCBS-174", "0069-VCBS-175", "0069-VCBS-176", "0069-VCBS-177", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-013", "0074-BTCH-014", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-017", "0074-BTCH-018", "0074-BTCH-019", "0074-BTCH-020", "0079-TGAP-006", "0079-TGAP-007" + ] + }, + "Ethereum Oracles": { + "milestone": "deployment-2", + "acs": ["0081-ETHD-001","0081-ETHD-002","0081-ETHD-003","0081-ETHD-004","0081-ETHD-005","0081-ETHD-006","0081-ETHD-007","0081-ETHD-008","0081-ETHD-009","0081-ETHD-010","0081-ETHD-011","0081-ETHD-012","0081-ETHD-013","0081-ETHD-014","0081-ETHD-015","0081-ETHD-016","0081-ETHD-017","0081-ETHD-018","0081-ETHD-019","0081-ETHD-020","0081-ETHD-021","0081-ETHD-022","0081-ETHD-023","0081-ETHD-024","0081-ETHD-025","0081-ETHD-026","0081-ETHD-027","0081-ETHD-028","0081-ETHD-029","0081-ETHD-030","0081-ETHD-031","0081-ETHD-032","0081-ETHD-033","0081-ETHD-034","0081-ETHD-035","0081-ETHD-036","0081-ETHD-037","0081-ETHD-038","0081-ETHD-039","0081-ETHD-040","0081-ETHD-041","0081-ETHD-042","0081-ETHD-043","0081-ETHD-044","0081-ETHD-045"] + }, + "SLA": { + "milestone": "deployment-2", + "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" + ] + }, + "Unknown": { + "milestone": "unknown", + "acs": [] + } +} From ce7c884a2cb2b3fcdd5c2c81ce3dc0f8c2ad7516 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 14 Jul 2023 12:07:38 +0100 Subject: [PATCH 298/649] fix: lint --- protocol/0044-LIME-lp_mechanics.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 1d2af929a..84b0a5065 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -306,9 +306,10 @@ and in the case of spot markets into the network treasury for the asset (0044-LIME-019) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the bond stake has been slashed to a level lower than the amendment, this slashed level will be retained (i.e. the protocol will not attempt to now increase the commitment) (0044-LIME-020) - If a liquidity provider with an active liquidity provision at the start of an epoch amends the fee level associated to this commitment during the epoch, this change will only take effect at the end of the epoch. (0044-LIME-021) -- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to increase the bond to the new level if they do not have sufficient collateral in the settlement asset of the market to meet new commitment amount then the amendment will be rejected and old commitment amount is retained (0044-LIME-030) -- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will increase the bond to the new level if they have sufficient collateral in the settlement asset of the market to meet new commitment amount (0044-LIME-031) - +- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the amended committed level will take affect immediately and the protocol will attempt to increase the bond to the new level if they do not have sufficient collateral in the settlement asset of the market to meet new commitment amount then the amendment will be rejected and old commitment amount is retained (0044-LIME-030) +- If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the amended committed level will take affect immediately and + - the protocol will increase the bond to the new level if they have sufficient collateral in the settlement asset of the market to meet new commitment amount (0044-LIME-031) + - at the end of the current epoch rewards / penalties are evaluated based on the balance of the bond account at start of epoch (0044-LIME-045) - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) @@ -328,6 +329,11 @@ In the case of spot markets it will be transferred into the network treasury for - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) +- For a market that is in opening auction and LP has committed provision: + - LP can increase their provision and it will take affect immediately (0044-LIME-046) + - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-047) + - LP cannot cancel their commitment but instead submit governace vote to cancel the market (0044-LIME-048) + - If multiple LPs committed provision then an LP can cancel their commitment by decreasing to `0` commitment without incurring penalties (0044-LIME-049) ### Qualifying Order Types From 4dfc4af367c73537c63232b47b4274c29d125b65 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 14 Jul 2023 12:11:43 +0100 Subject: [PATCH 299/649] fix: Duplicate AC codes --- protocol/0044-LIME-lp_mechanics.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 84b0a5065..41c3e21fb 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -309,7 +309,7 @@ and in the case of spot markets into the network treasury for the asset (0044-LIME-030) - If a liquidity provider with an active liquidity provision at the start of an epoch increases their liquidity provision staked commitment during the epoch, the amended committed level will take affect immediately and - the protocol will increase the bond to the new level if they have sufficient collateral in the settlement asset of the market to meet new commitment amount (0044-LIME-031) - - at the end of the current epoch rewards / penalties are evaluated based on the balance of the bond account at start of epoch (0044-LIME-045) + - at the end of the current epoch rewards / penalties are evaluated based on the balance of the bond account at start of epoch (0044-LIME-049) - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) @@ -330,10 +330,10 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed provision: - - LP can increase their provision and it will take affect immediately (0044-LIME-046) - - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-047) - - LP cannot cancel their commitment but instead submit governace vote to cancel the market (0044-LIME-048) - - If multiple LPs committed provision then an LP can cancel their commitment by decreasing to `0` commitment without incurring penalties (0044-LIME-049) + - LP can increase their provision and it will take affect immediately (0044-LIME-050) + - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) + - LP cannot cancel their commitment but instead submit governace vote to cancel the market (0044-LIME-052) + - If multiple LPs committed provision then an LP can cancel their commitment by decreasing to `0` commitment without incurring penalties (0044-LIME-053) ### Qualifying Order Types From aeb738d497c190fb7f8aab231cd5ee0b85146367 Mon Sep 17 00:00:00 2001 From: Witold Date: Thu, 13 Jul 2023 19:25:22 +0200 Subject: [PATCH 300/649] refactor: clamp it real good --- .../0053-PERP-product_builtin_perpetual_future.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 799143c1d..b372d071a 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -6,7 +6,7 @@ Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Pe Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data` oracle between to consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. -Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the form $G_i = \frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. +Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the basic form $G_i = \frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. An optional interest rate and clamp function are included in the funding rate calculation, see the [funding payment calculation](#funding-payment-calculation) section for details. ## 1. Product parameters @@ -14,8 +14,11 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 1. `settlement_schedule (Data Source: datetime)`: this data is used to indicate when the next periodic settlement should be carried out. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. 1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding payment liability contributes to party's margin. +1. `interest_rate`: a continuously compounded interest rate used in funding rate calculation. +1. `clamp_lower_bound`: a lower bound for the clamp function used as part of the funding rate calculation. +1. `clamp_upper_bound`: an lower bound for the clamp function used as part of the funding rate calculation. -Validation: none required as these are validated by the asset and data source frameworks. +Validation: `clamp_upper_bound` >= `clamp_lower_bound`. ### Example specification @@ -133,10 +136,11 @@ Only the internal data point with largest timestamp needs to be kept from that p #### Funding payment calculation -The next step is to calculate the periodic settlement funding payment +The next step is to calculate the periodic settlement funding payment. We allow the optional interest rate and clamp component, where $\text{clamp}(a,b;x)=min(b,max(a, x))$. The funding payment then takes the form: ```go -funding_payment = f_twap - s_twap +delta_t = funding_period_end - max(funding_period_start, internal_data_points[0].t) +funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower_bound*s_twap, exp(interest_rate*delta_t)*s_twap-f_twap)) ``` #### Funding rate calculation From 31ff14f09fb657bd95dee3d08da4aa558ed904e6 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 14 Jul 2023 13:37:36 +0200 Subject: [PATCH 301/649] refactor: linearise exponent --- protocol/0053-PERP-product_builtin_perpetual_future.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index b372d071a..0da09a634 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -140,9 +140,11 @@ The next step is to calculate the periodic settlement funding payment. We allow ```go delta_t = funding_period_end - max(funding_period_start, internal_data_points[0].t) -funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower_bound*s_twap, exp(interest_rate*delta_t)*s_twap-f_twap)) +funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower_bound*s_twap, (1 + delta_t * interest_rate)*s_twap-f_twap)) ``` +where `(1 + delta_t * interest_rate)` is the linearisation of `exp(delta_t*interest_rate)`. + #### Funding rate calculation While not needed for calculation of cashflows to be exchanged by market participants, the funding rate is useful for tracking market's relation to the underlying spot market over time. From f90f2c8932475e5438ca16c360b9d5efbe27d2da Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 14 Jul 2023 12:40:43 +0100 Subject: [PATCH 302/649] fix: spelling --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 41c3e21fb..5c5a342a1 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -332,7 +332,7 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in opening auction and LP has committed provision: - LP can increase their provision and it will take affect immediately (0044-LIME-050) - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) - - LP cannot cancel their commitment but instead submit governace vote to cancel the market (0044-LIME-052) + - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) - If multiple LPs committed provision then an LP can cancel their commitment by decreasing to `0` commitment without incurring penalties (0044-LIME-053) ### Qualifying Order Types From 6478e3943d0d412e5800fb74dc009f25ef24ebe9 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 14 Jul 2023 14:21:58 +0200 Subject: [PATCH 303/649] chore: fix spelling --- wordlist.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/wordlist.txt b/wordlist.txt index 9a18ad2a7..db3dccd70 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -142,6 +142,7 @@ keystore KMS leftarrow lifecycle +linearisation linearised linkings linux From 5961475372afaad91e1f93bf04de3bdb17b84912 Mon Sep 17 00:00:00 2001 From: AnExsomnis Date: Fri, 14 Jul 2023 16:11:16 +0300 Subject: [PATCH 304/649] fix: correct ACs --- protocol/0082-ETHD-ethereum-data-source.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 49287e2d0..198460c84 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -110,8 +110,8 @@ Select { ### External Oracles - Creation -1. Create ethereum oracles based on calling a read method of a smart contract (Phase 2 - oracle based on listening for events) (0082-ETHD-001) -2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment (0082-ETHD-002) +1. Using the existing ways to create or update a market via governance proposals, define data sources for settlement and termination as the result of calling a read method of a smart contract on ethereum network. (Phase 2 of this step would be defining an oracle that is based on listening for events on ethereum network) (0082-ETHD-001) +2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment (0082-ETHD-002) 3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message (0082-ETHD-003) 4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) (0082-ETHD-004) @@ -123,8 +123,8 @@ Select { ### External Oracles - Deletions -1. Ability to delete a data source if and only if the data source is NOT used by any active markets (0082-ETHD-008) -2. Should NOT be able to delete a data source if its being actively used by a market (0082-ETHD-009) +1. Aligned with the existing logic, when no market listens to a data source, whatever that source is, it is automatically disregarded / deleted from the engine. Same applies for ethereum oracles (0082-ETHD-008) +2. When ethereum oracle is referenced / used by an existing market, it should not be deleted (0082-ETHD-009) 3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source (0082-ETHD-010) ### External Oracles - Validations @@ -132,14 +132,13 @@ Select { 1. Validate if the smart contract address is valid (0082-ETHD-011) 2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 (0082-ETHD-012) 3. Validations for min / max frequency of listening for events / read a smart contract (0082-ETHD-013) -4. Create a new market with an inactive external oracle data source, system should throw an error (0082-ETHD-014) -5. Validations to be applied - need to be expanded (0082-ETHD-015) -6. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event (0082-ETHD-016) +4. When a proposal that uses ethereum oracles, defines incorrect data (contract address, ABI) the system should throw an error and the proposal should not pass validation (0082-ETHD-014) +5. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event (0082-ETHD-016) ### New Network parameters 1. Test min / max values / validations for any new network parameters that are added (0082-ETHD-017) -2. Test the impact / behaviour of the system, after the changes to the new network parameters are enacted (0082-ETHD-018) +2. Test the successful disabling / enabling of ethereum oracles when the new network parameter "ethereum.oracles.enabled" is set to false or true repsectively (0082-ETHD-018) ### Negative Tests @@ -147,7 +146,7 @@ Select { 2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value (0082-ETHD-020) 3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this (0082-ETHD-021) 4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-022) -5. Create an oracle source that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-023) +5. Create an oracle that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-023) 6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting (0082-ETHD-024) ### API @@ -163,13 +162,12 @@ Select { 4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0082-ETHD-030) 5. SPAM rules if any defined should be tested for (0082-ETHD-031) 6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly (0082-ETHD-032) -7. Any active data sources that aren't used by any markets should not source data until they are being actively used by a market (0082-ETHD-033) ### Usage -1. It should be possible to use only ethereum oracle data sources or internal data sources or use a combination of both types of oracles (0082-ETHD-034) +1. It should be possible to use only ethereum oracle data sources in a market proposal, or create any combination with any of the other types of currently existing external or internal data sources (0082-ETHD-034) 2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-035) -3. Create a market to use an external data source to terminate a market and an internal / manual oracle to settle the market (0082-ETHD-036) +3. Create a market to use an external data source to terminate a market and a manual oracle to settle the market (0082-ETHD-036) 4. Data sourcing should be completely decoupled from data filtering (0082-ETHD-037) ### Checkpoints From 63553b11f7678982a44bd13f8613a7aac20dd302 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Mon, 17 Jul 2023 13:27:27 +0100 Subject: [PATCH 305/649] Update 0028-GOVE-governance.md (#1836) * Update 0028-GOVE-governance.md * Update 0028-GOVE-governance.md --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 684beb06f..ba000af2f 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -642,7 +642,7 @@ If the proposal is one off it can define a time for delivery. Whenever the block - Only recurring governance initiated transfers can be cancelled by proposing a governance initiated transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) - After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123) -- Using a governance proposal to cancel, attempts to cancel a recurring transfer which has yet to start or has completed will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) +- Recurring transfers can be cancelled only after the transfer proposal reached an enacted state. Attempts to cancel before the recurring transfer proposal has enacted will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) - Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) - When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126) From 5faee0210c4aa9510aad999100c2f498c7130274 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 17 Jul 2023 14:26:14 +0100 Subject: [PATCH 306/649] fix: corrected cancel case and added spot acs --- protocol/0044-LIME-lp_mechanics.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 5c5a342a1..a18a84a1e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -330,10 +330,10 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed provision: - - LP can increase their provision and it will take affect immediately (0044-LIME-050) - - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) - - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) - - If multiple LPs committed provision then an LP can cancel their commitment by decreasing to `0` commitment without incurring penalties (0044-LIME-053) + - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spots (0044-LIME-054) + - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spots (0044-LIME-055) + - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) + - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) ### Qualifying Order Types From f60555be6647675f2aee1352a086b865a666a792 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 17 Jul 2023 14:28:50 +0100 Subject: [PATCH 307/649] fix: remove double space --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index a18a84a1e..8245aa8fd 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -330,7 +330,7 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed provision: - - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spots (0044-LIME-054) + - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spots (0044-LIME-054) - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spots (0044-LIME-055) - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) From 1409dc6052525435df6fb307da45e6b8f9d6cc6a Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 17 Jul 2023 14:29:20 +0100 Subject: [PATCH 308/649] fix: more double space to remove --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 8245aa8fd..f970c7f71 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -332,8 +332,8 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in opening auction and LP has committed provision: - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spots (0044-LIME-054) - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spots (0044-LIME-055) - - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) - - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) + - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) + - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) ### Qualifying Order Types From 3c06dd71521f59b93d42b61b8be32145ce9bea78 Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Mon, 17 Jul 2023 18:04:44 +0300 Subject: [PATCH 309/649] fix: fix spelling error --- protocol/0082-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 198460c84..35168f8a8 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -138,7 +138,7 @@ Select { ### New Network parameters 1. Test min / max values / validations for any new network parameters that are added (0082-ETHD-017) -2. Test the successful disabling / enabling of ethereum oracles when the new network parameter "ethereum.oracles.enabled" is set to false or true repsectively (0082-ETHD-018) +2. Test the successful disabling / enabling of ethereum oracles when the new network parameter "ethereum.oracles.enabled" is set to false or true respectively (0082-ETHD-018) ### Negative Tests From fbf3b9800fe7ebf4ef0dc08021b005b18699e631 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 17 Jul 2023 16:41:55 +0100 Subject: [PATCH 310/649] chore: update spot ACs after 1st QA review (#1835) This PR updates the spot ACs in both the specs and the feature.json file --- protocol/0074-BTCH-batch-market-instructions.md | 10 +++++----- protocol/0080-SPOT-product_builtin_spot.md | 2 +- protocol/features.json | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index a8e2530d8..ea74ace4b 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -49,14 +49,14 @@ After entering or exiting an auction mid-batch, the full batch must be processed ## Acceptance criteria - Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001) for product spot: (0074-BTCH-012) -- Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002) for product spot: (0074-BTCH-013) -- An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003) for product spot: (0074-BTCH-014) +- Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002) +- An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003) - If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005) for product spot: (0074-BTCH-015) - An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006) for product spot: (0074-BTCH-016) In particular: - A batch consisting of two limit order placements C1 and C2 where the party has enough balance to place either of them individually but not both should place C1 but reject C2. - A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction and a C2 which is marked `GFN` (good for normal) should execute C1 but reject C2. -- A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007) for product spot: (0074-BTCH-017) -- Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008) for product spot: (0074-BTCH-018) +- A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007) +- Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008) - Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009) for product spot: (0074-BTCH-019) - If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010) -- Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011) for product spot: (0074-BTCH-020) +- Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011) diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md index 128be213a..255177db5 100644 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ b/protocol/0080-SPOT-product_builtin_spot.md @@ -128,7 +128,7 @@ Price-monitoring auctions are still required and should be implemented following 1. If a "sell" order does not trade immediately (or only trades in part), an amount of the base_asset should be transferred to a holding_account to cover the remaining size of the order for the base_asset.(0080-SPOT-009) 1. If a "sell" order incurs fees through trading, the required amount of the quote_asset to cover the fees will be deducted from the total quote_asset resulting from the sale of the base_asset.(0080-SPOT-010) 1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) -1.If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). +1. If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). 1. If the order is cancelled, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-007) 1. If the order's size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) 1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties' general_account to their respective holding_account to cover any potential fees resulting from the order trading in the auction.(0080-SPOT-016). diff --git a/protocol/features.json b/protocol/features.json index a3a1caae5..7cebaf652 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -25,7 +25,7 @@ }, "Spot": { "milestone": "deployment-2", - "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-026", "0013-ACCT-027", "0013-ACCT-028", "0013-ACCT-029", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0036-BRIE-004", "0036-BRIE-005", "0036-BRIE-006", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0069-VCBS-089", "0069-VCBS-090", "0069-VCBS-091", "0069-VCBS-092", "0069-VCBS-093", "0069-VCBS-094", "0069-VCBS-095", "0069-VCBS-096", "0069-VCBS-097", "0069-VCBS-098", "0069-VCBS-099", "0069-VCBS-100", "0069-VCBS-101", "0069-VCBS-102", "0069-VCBS-103", "0069-VCBS-104", "0069-VCBS-105", "0069-VCBS-106", "0069-VCBS-107", "0069-VCBS-108", "0069-VCBS-109", "0069-VCBS-110", "0069-VCBS-111", "0069-VCBS-112", "0069-VCBS-113", "0069-VCBS-114", "0069-VCBS-115", "0069-VCBS-116", "0069-VCBS-117", "0069-VCBS-118", "0069-VCBS-119", "0069-VCBS-120", "0069-VCBS-121", "0069-VCBS-122", "0069-VCBS-123", "0069-VCBS-124", "0069-VCBS-125", "0069-VCBS-126", "0069-VCBS-127", "0069-VCBS-128", "0069-VCBS-129", "0069-VCBS-130", "0069-VCBS-131", "0069-VCBS-132", "0069-VCBS-133", "0069-VCBS-134", "0069-VCBS-135", "0069-VCBS-136", "0069-VCBS-137", "0069-VCBS-138", "0069-VCBS-139", "0069-VCBS-140", "0069-VCBS-141", "0069-VCBS-142", "0069-VCBS-143", "0069-VCBS-144", "0069-VCBS-145", "0069-VCBS-146", "0069-VCBS-147", "0069-VCBS-148", "0069-VCBS-149", "0069-VCBS-150", "0069-VCBS-151", "0069-VCBS-152", "0069-VCBS-153", "0069-VCBS-154", "0069-VCBS-155", "0069-VCBS-156", "0069-VCBS-157", "0069-VCBS-158", "0069-VCBS-159", "0069-VCBS-160", "0069-VCBS-161", "0069-VCBS-162", "0069-VCBS-163", "0069-VCBS-164", "0069-VCBS-165", "0069-VCBS-166", "0069-VCBS-167", "0069-VCBS-168", "0069-VCBS-169", "0069-VCBS-170", "0069-VCBS-171", "0069-VCBS-172", "0069-VCBS-173", "0069-VCBS-174", "0069-VCBS-175", "0069-VCBS-176", "0069-VCBS-177", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-013", "0074-BTCH-014", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-017", "0074-BTCH-018", "0074-BTCH-019", "0074-BTCH-020", "0079-TGAP-006", "0079-TGAP-007" + "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-019", "0079-TGAP-006", "0079-TGAP-007" ] }, "Ethereum Oracles": { From b01651228721d246b1c3cd87ef5b36fea101d9a9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 18 Jul 2023 09:49:39 +0100 Subject: [PATCH 311/649] feat: update name of scaling factor --- protocol/0041-TSTK-target_stake.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index 3dac124d2..40e683d21 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -72,7 +72,7 @@ Example 3: if `market.stake.target.scalingFactor = 10`, `rf = 0.004` and `max_oi See [spot market spec](0080-SPOT-product_builtin_spot.md).3600s -The target stake of a market is calculated as a fraction of the maximum `total_stake` over a rolling time window. The fraction is controlled by the parameter `consensus_factor` and the length of the window is controlled by the parameter `time_window`. +The target stake of a market is calculated as a fraction of the maximum `total_stake` over a rolling time window. The fraction is controlled by the parameter `scaling_factor` and the length of the window is controlled by the parameter `time_window`. ```pseudo e.g. From d936ad92125119f88abc2f4feab1771303b715d5 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 18 Jul 2023 11:16:13 +0100 Subject: [PATCH 312/649] fix: remove spot ac 0026-AUCT-030 --- protocol/0026-AUCT-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index b277c8004..a5d441370 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -169,7 +169,7 @@ message Market { - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) for product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) - 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) for product spot: (0026-AUCT-030) + 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) From 3758b747378f1dc4eeac60e50fd08e644117919e Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 18 Jul 2023 13:18:20 +0200 Subject: [PATCH 313/649] refactor: add validation --- protocol/0053-PERP-product_builtin_perpetual_future.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 0da09a634..835fa9dbd 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -13,12 +13,18 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 1. `settlement_asset (Settlement Asset)`: this is used to specify the single asset that an instrument using this product settles in. 1. `settlement_schedule (Data Source: datetime)`: this data is used to indicate when the next periodic settlement should be carried out. 1. `settlement_data (Data Source: number)`: this data is used by the product to calculate periodic settlement cashflows. -1. `margin_funding_factor`: a parameter in the range $[0, 1]$ controlling how much the upcoming funding payment liability contributes to party's margin. +1. `margin_funding_factor`: a parameter controlling how much the upcoming funding payment liability contributes to party's margin. 1. `interest_rate`: a continuously compounded interest rate used in funding rate calculation. 1. `clamp_lower_bound`: a lower bound for the clamp function used as part of the funding rate calculation. 1. `clamp_upper_bound`: an lower bound for the clamp function used as part of the funding rate calculation. -Validation: `clamp_upper_bound` >= `clamp_lower_bound`. +Validation: + +- `margin_funding_factor` in range `[0,1]`, +- `interest_rate` in range `[-1,1]`, +- `clamp_lower_bound` in range `[-1,1]`, +- `clamp_upper_bound` in range `[-1,1]`, +- `clamp_upper_bound` >= `clamp_lower_bound`. ### Example specification From 38656d4f4d5c9eaa8816627119028aac576c39c5 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 18 Jul 2023 15:33:25 +0200 Subject: [PATCH 314/649] refactor: clarify transfers to do with rewards --- protocol/0028-GOVE-governance.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index ba000af2f..9758b44e9 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -282,10 +282,12 @@ The below table shows the allowable combinations of source and destination accou | Network treasury | Party general account(s) | Yes | | Network treasury | Party other account types | No | | Network treasury | Market insurance pool account | Yes | +| Network treasury | Reward account | Yes | | Network treasury | Any other account | No | | Market insurance pool account | Party account(s) | Yes | | Market insurance pool account | Network treasury | Yes | | Market insurance pool account | Market insurance pool account | Yes | +| Market insurance pool account | Reward account | Yes | | Market insurance pool account | Any other account | No | | Any other account | Any | No | @@ -627,7 +629,9 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### One Off Delivery transfers If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. (0028-GOVE-129) - +It is possible to submit a one off governance transfer proposal from network treasury into any reward account (including staking rewards). (0028-GOVE-140) +It is possible to submit a one off governance transfer proposal from market's insurance pool into any reward account (including staking rewards). (0028-GOVE-141) +It is NOT possible to submit a governance proposal where the source account is the reward account. (0028-GOVE-144) ##### Recurring governance initiated transfers @@ -637,6 +641,8 @@ If the proposal is one off it can define a time for delivery. Whenever the block - When a transfer gets enacted it emits transfer event similar to regular transfer events from regular transfers, however with governance-recurring types. At the time of enactment no amount is attached to the transfer and it will show 0.(0028-GOVE-106) +- It is possible to submit a recurring governance transfer proposal from network treasury into any reward account (including staking rewards). (0028-GOVE-142) +- It is possible to submit a recurring governance transfer proposal from market's insurance pool into any reward account (including staking rewards). (0028-GOVE-143) ##### Cancelling governance initiated transfers From 7d720962ae0cda0c6b143e4c9f658840104b7f01 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 18 Jul 2023 15:41:18 +0200 Subject: [PATCH 315/649] refactor: fix typo --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 835fa9dbd..ec716e8d6 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -16,7 +16,7 @@ Unlike traditional futures contracts, the perpetual futures never expire. Withou 1. `margin_funding_factor`: a parameter controlling how much the upcoming funding payment liability contributes to party's margin. 1. `interest_rate`: a continuously compounded interest rate used in funding rate calculation. 1. `clamp_lower_bound`: a lower bound for the clamp function used as part of the funding rate calculation. -1. `clamp_upper_bound`: an lower bound for the clamp function used as part of the funding rate calculation. +1. `clamp_upper_bound`: an upper bound for the clamp function used as part of the funding rate calculation. Validation: From 859948ba9c3214d4707a8cd13841808f7da6d3cd Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 12:01:29 +0100 Subject: [PATCH 316/649] fix: wording provision > liquidity Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f970c7f71..066a1e98e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -329,7 +329,7 @@ In the case of spot markets it will be transferred into the network treasury for - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) -- For a market that is in opening auction and LP has committed provision: +- For a market that is in opening auction and LP has committed liquidity: - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spots (0044-LIME-054) - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spots (0044-LIME-055) - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) From 839797a53b910240eebbd3f7209f6c1cb387bfd3 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 12:02:08 +0100 Subject: [PATCH 317/649] fix: wording to singular Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 066a1e98e..045d76af0 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -330,7 +330,7 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spots (0044-LIME-054) + - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spot (0044-LIME-054) - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spots (0044-LIME-055) - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) From 8b44961a880fd96525dfe7dda4bc6cde5390923e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 12:02:20 +0100 Subject: [PATCH 318/649] fix: wording to singular Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 045d76af0..db0d6e775 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -331,7 +331,7 @@ In the case of spot markets it will be transferred into the network treasury for - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spot (0044-LIME-054) - - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spots (0044-LIME-055) + - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) From cf0204358e1a3fe2e730f20eb690af0b406fd168 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 12:27:19 +0100 Subject: [PATCH 319/649] fix: addressed comments --- protocol/0044-LIME-lp_mechanics.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index db0d6e775..8d13b68ca 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -330,10 +330,11 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - - LP can increase their provision and it will take affect immediately (0044-LIME-050) for spot (0044-LIME-054) - - LP can decrease their provision and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) - - LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) - - If multiple LPs committed provision then an LP can cancel their commitment without incurring penalties (0044-LIME-053) for spots (0044-LIME-057) + - LP can increase their commitment and it will take affect immediately (0044-LIME-050) for spot (0044-LIME-054) + - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) + - LP can cancel their commitment without incurring penalties (0044-LIME-053) +- For a market that is in continuous trading and a single LP has committed liquidity: + - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) ### Qualifying Order Types From cb98317c49d594bfb6c3e850ef4d2fa848d6c39a Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 12:28:08 +0100 Subject: [PATCH 320/649] fix: spot singular --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 8d13b68ca..3eed49259 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -334,7 +334,7 @@ In the case of spot markets it will be transferred into the network treasury for - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spots (0044-LIME-056) + - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spot (0044-LIME-056) ### Qualifying Order Types From 22e5b9ed7c571a8047c2cb62bc35702dcf76b4cd Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 13:05:34 +0100 Subject: [PATCH 321/649] feat: ordered spec 0044 acs and added new ones --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index a3a1caae5..e8863b485 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -25,7 +25,7 @@ }, "Spot": { "milestone": "deployment-2", - "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-026", "0013-ACCT-027", "0013-ACCT-028", "0013-ACCT-029", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0036-BRIE-004", "0036-BRIE-005", "0036-BRIE-006", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0069-VCBS-089", "0069-VCBS-090", "0069-VCBS-091", "0069-VCBS-092", "0069-VCBS-093", "0069-VCBS-094", "0069-VCBS-095", "0069-VCBS-096", "0069-VCBS-097", "0069-VCBS-098", "0069-VCBS-099", "0069-VCBS-100", "0069-VCBS-101", "0069-VCBS-102", "0069-VCBS-103", "0069-VCBS-104", "0069-VCBS-105", "0069-VCBS-106", "0069-VCBS-107", "0069-VCBS-108", "0069-VCBS-109", "0069-VCBS-110", "0069-VCBS-111", "0069-VCBS-112", "0069-VCBS-113", "0069-VCBS-114", "0069-VCBS-115", "0069-VCBS-116", "0069-VCBS-117", "0069-VCBS-118", "0069-VCBS-119", "0069-VCBS-120", "0069-VCBS-121", "0069-VCBS-122", "0069-VCBS-123", "0069-VCBS-124", "0069-VCBS-125", "0069-VCBS-126", "0069-VCBS-127", "0069-VCBS-128", "0069-VCBS-129", "0069-VCBS-130", "0069-VCBS-131", "0069-VCBS-132", "0069-VCBS-133", "0069-VCBS-134", "0069-VCBS-135", "0069-VCBS-136", "0069-VCBS-137", "0069-VCBS-138", "0069-VCBS-139", "0069-VCBS-140", "0069-VCBS-141", "0069-VCBS-142", "0069-VCBS-143", "0069-VCBS-144", "0069-VCBS-145", "0069-VCBS-146", "0069-VCBS-147", "0069-VCBS-148", "0069-VCBS-149", "0069-VCBS-150", "0069-VCBS-151", "0069-VCBS-152", "0069-VCBS-153", "0069-VCBS-154", "0069-VCBS-155", "0069-VCBS-156", "0069-VCBS-157", "0069-VCBS-158", "0069-VCBS-159", "0069-VCBS-160", "0069-VCBS-161", "0069-VCBS-162", "0069-VCBS-163", "0069-VCBS-164", "0069-VCBS-165", "0069-VCBS-166", "0069-VCBS-167", "0069-VCBS-168", "0069-VCBS-169", "0069-VCBS-170", "0069-VCBS-171", "0069-VCBS-172", "0069-VCBS-173", "0069-VCBS-174", "0069-VCBS-175", "0069-VCBS-176", "0069-VCBS-177", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-013", "0074-BTCH-014", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-017", "0074-BTCH-018", "0074-BTCH-019", "0074-BTCH-020", "0079-TGAP-006", "0079-TGAP-007" + "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-026", "0013-ACCT-027", "0013-ACCT-028", "0013-ACCT-029", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0036-BRIE-004", "0036-BRIE-005", "0036-BRIE-006", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0069-VCBS-089", "0069-VCBS-090", "0069-VCBS-091", "0069-VCBS-092", "0069-VCBS-093", "0069-VCBS-094", "0069-VCBS-095", "0069-VCBS-096", "0069-VCBS-097", "0069-VCBS-098", "0069-VCBS-099", "0069-VCBS-100", "0069-VCBS-101", "0069-VCBS-102", "0069-VCBS-103", "0069-VCBS-104", "0069-VCBS-105", "0069-VCBS-106", "0069-VCBS-107", "0069-VCBS-108", "0069-VCBS-109", "0069-VCBS-110", "0069-VCBS-111", "0069-VCBS-112", "0069-VCBS-113", "0069-VCBS-114", "0069-VCBS-115", "0069-VCBS-116", "0069-VCBS-117", "0069-VCBS-118", "0069-VCBS-119", "0069-VCBS-120", "0069-VCBS-121", "0069-VCBS-122", "0069-VCBS-123", "0069-VCBS-124", "0069-VCBS-125", "0069-VCBS-126", "0069-VCBS-127", "0069-VCBS-128", "0069-VCBS-129", "0069-VCBS-130", "0069-VCBS-131", "0069-VCBS-132", "0069-VCBS-133", "0069-VCBS-134", "0069-VCBS-135", "0069-VCBS-136", "0069-VCBS-137", "0069-VCBS-138", "0069-VCBS-139", "0069-VCBS-140", "0069-VCBS-141", "0069-VCBS-142", "0069-VCBS-143", "0069-VCBS-144", "0069-VCBS-145", "0069-VCBS-146", "0069-VCBS-147", "0069-VCBS-148", "0069-VCBS-149", "0069-VCBS-150", "0069-VCBS-151", "0069-VCBS-152", "0069-VCBS-153", "0069-VCBS-154", "0069-VCBS-155", "0069-VCBS-156", "0069-VCBS-157", "0069-VCBS-158", "0069-VCBS-159", "0069-VCBS-160", "0069-VCBS-161", "0069-VCBS-162", "0069-VCBS-163", "0069-VCBS-164", "0069-VCBS-165", "0069-VCBS-166", "0069-VCBS-167", "0069-VCBS-168", "0069-VCBS-169", "0069-VCBS-170", "0069-VCBS-171", "0069-VCBS-172", "0069-VCBS-173", "0069-VCBS-174", "0069-VCBS-175", "0069-VCBS-176", "0069-VCBS-177", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-013", "0074-BTCH-014", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-017", "0074-BTCH-018", "0074-BTCH-019", "0074-BTCH-020", "0079-TGAP-006", "0079-TGAP-007" ] }, "Ethereum Oracles": { @@ -34,7 +34,7 @@ }, "SLA": { "milestone": "deployment-2", - "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" + "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-022", "0044-LIME-023", "0044-LIME-024", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-030", "0044-LIME-031", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-050", "0044-LIME-051", "0044-LIME-052", "0044-LIME-053", "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" ] }, "Unknown": { From 9014c333b7a51c2d32cfe2be68e1e3a9d523ec1f Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 13:10:02 +0100 Subject: [PATCH 322/649] Revert "feat: ordered spec 0044 acs and added new ones" This reverts commit 22e5b9ed7c571a8047c2cb62bc35702dcf76b4cd. --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index e8863b485..a3a1caae5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -25,7 +25,7 @@ }, "Spot": { "milestone": "deployment-2", - "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-026", "0013-ACCT-027", "0013-ACCT-028", "0013-ACCT-029", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0036-BRIE-004", "0036-BRIE-005", "0036-BRIE-006", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0069-VCBS-089", "0069-VCBS-090", "0069-VCBS-091", "0069-VCBS-092", "0069-VCBS-093", "0069-VCBS-094", "0069-VCBS-095", "0069-VCBS-096", "0069-VCBS-097", "0069-VCBS-098", "0069-VCBS-099", "0069-VCBS-100", "0069-VCBS-101", "0069-VCBS-102", "0069-VCBS-103", "0069-VCBS-104", "0069-VCBS-105", "0069-VCBS-106", "0069-VCBS-107", "0069-VCBS-108", "0069-VCBS-109", "0069-VCBS-110", "0069-VCBS-111", "0069-VCBS-112", "0069-VCBS-113", "0069-VCBS-114", "0069-VCBS-115", "0069-VCBS-116", "0069-VCBS-117", "0069-VCBS-118", "0069-VCBS-119", "0069-VCBS-120", "0069-VCBS-121", "0069-VCBS-122", "0069-VCBS-123", "0069-VCBS-124", "0069-VCBS-125", "0069-VCBS-126", "0069-VCBS-127", "0069-VCBS-128", "0069-VCBS-129", "0069-VCBS-130", "0069-VCBS-131", "0069-VCBS-132", "0069-VCBS-133", "0069-VCBS-134", "0069-VCBS-135", "0069-VCBS-136", "0069-VCBS-137", "0069-VCBS-138", "0069-VCBS-139", "0069-VCBS-140", "0069-VCBS-141", "0069-VCBS-142", "0069-VCBS-143", "0069-VCBS-144", "0069-VCBS-145", "0069-VCBS-146", "0069-VCBS-147", "0069-VCBS-148", "0069-VCBS-149", "0069-VCBS-150", "0069-VCBS-151", "0069-VCBS-152", "0069-VCBS-153", "0069-VCBS-154", "0069-VCBS-155", "0069-VCBS-156", "0069-VCBS-157", "0069-VCBS-158", "0069-VCBS-159", "0069-VCBS-160", "0069-VCBS-161", "0069-VCBS-162", "0069-VCBS-163", "0069-VCBS-164", "0069-VCBS-165", "0069-VCBS-166", "0069-VCBS-167", "0069-VCBS-168", "0069-VCBS-169", "0069-VCBS-170", "0069-VCBS-171", "0069-VCBS-172", "0069-VCBS-173", "0069-VCBS-174", "0069-VCBS-175", "0069-VCBS-176", "0069-VCBS-177", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-013", "0074-BTCH-014", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-017", "0074-BTCH-018", "0074-BTCH-019", "0074-BTCH-020", "0079-TGAP-006", "0079-TGAP-007" + "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-026", "0013-ACCT-027", "0013-ACCT-028", "0013-ACCT-029", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0036-BRIE-004", "0036-BRIE-005", "0036-BRIE-006", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0069-VCBS-089", "0069-VCBS-090", "0069-VCBS-091", "0069-VCBS-092", "0069-VCBS-093", "0069-VCBS-094", "0069-VCBS-095", "0069-VCBS-096", "0069-VCBS-097", "0069-VCBS-098", "0069-VCBS-099", "0069-VCBS-100", "0069-VCBS-101", "0069-VCBS-102", "0069-VCBS-103", "0069-VCBS-104", "0069-VCBS-105", "0069-VCBS-106", "0069-VCBS-107", "0069-VCBS-108", "0069-VCBS-109", "0069-VCBS-110", "0069-VCBS-111", "0069-VCBS-112", "0069-VCBS-113", "0069-VCBS-114", "0069-VCBS-115", "0069-VCBS-116", "0069-VCBS-117", "0069-VCBS-118", "0069-VCBS-119", "0069-VCBS-120", "0069-VCBS-121", "0069-VCBS-122", "0069-VCBS-123", "0069-VCBS-124", "0069-VCBS-125", "0069-VCBS-126", "0069-VCBS-127", "0069-VCBS-128", "0069-VCBS-129", "0069-VCBS-130", "0069-VCBS-131", "0069-VCBS-132", "0069-VCBS-133", "0069-VCBS-134", "0069-VCBS-135", "0069-VCBS-136", "0069-VCBS-137", "0069-VCBS-138", "0069-VCBS-139", "0069-VCBS-140", "0069-VCBS-141", "0069-VCBS-142", "0069-VCBS-143", "0069-VCBS-144", "0069-VCBS-145", "0069-VCBS-146", "0069-VCBS-147", "0069-VCBS-148", "0069-VCBS-149", "0069-VCBS-150", "0069-VCBS-151", "0069-VCBS-152", "0069-VCBS-153", "0069-VCBS-154", "0069-VCBS-155", "0069-VCBS-156", "0069-VCBS-157", "0069-VCBS-158", "0069-VCBS-159", "0069-VCBS-160", "0069-VCBS-161", "0069-VCBS-162", "0069-VCBS-163", "0069-VCBS-164", "0069-VCBS-165", "0069-VCBS-166", "0069-VCBS-167", "0069-VCBS-168", "0069-VCBS-169", "0069-VCBS-170", "0069-VCBS-171", "0069-VCBS-172", "0069-VCBS-173", "0069-VCBS-174", "0069-VCBS-175", "0069-VCBS-176", "0069-VCBS-177", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-013", "0074-BTCH-014", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-017", "0074-BTCH-018", "0074-BTCH-019", "0074-BTCH-020", "0079-TGAP-006", "0079-TGAP-007" ] }, "Ethereum Oracles": { @@ -34,7 +34,7 @@ }, "SLA": { "milestone": "deployment-2", - "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-022", "0044-LIME-023", "0044-LIME-024", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-030", "0044-LIME-031", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-050", "0044-LIME-051", "0044-LIME-052", "0044-LIME-053", "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" + "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" ] }, "Unknown": { From f78aae4a5ce5495d8ebe2ecfcbd8598557ce8027 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 19 Jul 2023 13:13:49 +0100 Subject: [PATCH 323/649] feat: added new acs to sla --- protocol/features.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 7cebaf652..de8caf947 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -34,7 +34,7 @@ }, "SLA": { "milestone": "deployment-2", - "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" + "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-050", "0044-LIME-051", "0044-LIME-052", "0044-LIME-053", "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" ] }, "Unknown": { From dea3925399bf43618f75207e101f636277d58ffe Mon Sep 17 00:00:00 2001 From: gordsport Date: Tue, 18 Jul 2023 23:23:00 +0100 Subject: [PATCH 324/649] Update features.json Updates the features.json up to the merged PR: #1845 18th July 2023 --- protocol/features.json | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 7cebaf652..35c0ccd75 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,12 +1,11 @@ { "Governance Transfers": { "milestone": "deployment-1", - "acs": [ "0028-GOVE-073", "0028-GOVE-074", "0028-GOVE-128", "0028-GOVE-119", "0028-GOVE-120", "0028-GOVE-132", "0028-GOVE-122", "0028-GOVE-077", "0028-GOVE-079", "0028-GOVE-081", "0028-GOVE-082", "0028-GOVE-083", "0028-GOVE-084", "0028-GOVE-085", "0028-GOVE-086", "0028-GOVE-087", "0028-GOVE-088", "0028-GOVE-089", "0028-GOVE-091", "0028-GOVE-092", "0028-GOVE-094", "0028-GOVE-095", "0028-GOVE-096", "0028-GOVE-099", "0028-GOVE-100", "0028-GOVE-101", "0028-GOVE-102", "0028-GOVE-130", "0028-GOVE-131", "0028-GOVE-103", "0028-GOVE-133", "0028-GOVE-129", "0028-GOVE-104", "0028-GOVE-105", "0028-GOVE-106", "0028-GOVE-107", "0028-GOVE-123", "0028-GOVE-124", "0028-GOVE-125", "0028-GOVE-126", "0028-GOVE-127" ] + "acs": [ "0028-GOVE-073", "0028-GOVE-074", "0028-GOVE-128", "0028-GOVE-119", "0028-GOVE-120", "0028-GOVE-132", "0028-GOVE-122", "0028-GOVE-077", "0028-GOVE-079", "0028-GOVE-081", "0028-GOVE-082", "0028-GOVE-083", "0028-GOVE-084", "0028-GOVE-085", "0028-GOVE-086", "0028-GOVE-087", "0028-GOVE-088", "0028-GOVE-089", "0028-GOVE-091", "0028-GOVE-092", "0028-GOVE-094", "0028-GOVE-095", "0028-GOVE-096", "0028-GOVE-099", "0028-GOVE-100", "0028-GOVE-101", "0028-GOVE-102", "0028-GOVE-130", "0028-GOVE-131", "0028-GOVE-103", "0028-GOVE-133", "0028-GOVE-129", "0028-GOVE-104", "0028-GOVE-105", "0028-GOVE-106", "0028-GOVE-107", "0028-GOVE-123", "0028-GOVE-124", "0028-GOVE-125", "0028-GOVE-126", "0028-GOVE-127", "0028-GOVE-140", "0028-GOVE-141", "0028-GOVE-144", "0028-GOVE-142", "0028-GOVE-144"] }, "Iceberg Orders": { "milestone": "deployment-1", - "acs": ["0014-ORDT-039", "0014-ORDT-007", "0014-ORDT-008", "0014-ORDT-009", "0014-ORDT-010", "0014-ORDT-011", "0014-ORDT-012", "0014-ORDT-013", "0014-ORDT-014", "0014-ORDT-015", "0014-ORDT-016", "0014-ORDT-017", "0014-ORDT-018", "0014-ORDT-020", "0014-ORDT-021", "0014-ORDT-022", "0014-ORDT-023", "0014-ORDT-024", "0014-ORDT-025", "0014-ORDT-026", "0014-ORDT-027", "0014-ORDT-028", "0014-ORDT-029", "0014-ORDT-030", "0014-ORDT-031", "0014-ORDT-032", "0014-ORDT-033", "0014-ORDT-034", "0014-ORDT-037", "0014-ORDT-038", "0014-ORDT-035", "0014-ORDT-036", "0014-ORDT-069", "0014-ORDT-070" - ] + "acs": ["0014-ORDT-039", "0014-ORDT-007", "0014-ORDT-008", "0014-ORDT-009", "0014-ORDT-010", "0014-ORDT-011", "0014-ORDT-012", "0014-ORDT-013", "0014-ORDT-014", "0014-ORDT-015", "0014-ORDT-016", "0014-ORDT-017", "0014-ORDT-018", "0014-ORDT-020", "0014-ORDT-021", "0014-ORDT-022", "0014-ORDT-023", "0014-ORDT-024", "0014-ORDT-025", "0014-ORDT-026", "0014-ORDT-027", "0014-ORDT-028", "0014-ORDT-029", "0014-ORDT-030", "0014-ORDT-031", "0014-ORDT-032", "0014-ORDT-033", "0014-ORDT-034", "0014-ORDT-037", "0014-ORDT-038", "0014-ORDT-035", "0014-ORDT-036", "0014-ORDT-069", "0014-ORDT-070"] }, "Stop Orders": { "milestone": "deployment-1", @@ -25,16 +24,16 @@ }, "Spot": { "milestone": "deployment-2", - "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-030", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-019", "0079-TGAP-006", "0079-TGAP-007" + "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-019", "0079-TGAP-006", "0079-TGAP-007" ] }, "Ethereum Oracles": { "milestone": "deployment-2", - "acs": ["0081-ETHD-001","0081-ETHD-002","0081-ETHD-003","0081-ETHD-004","0081-ETHD-005","0081-ETHD-006","0081-ETHD-007","0081-ETHD-008","0081-ETHD-009","0081-ETHD-010","0081-ETHD-011","0081-ETHD-012","0081-ETHD-013","0081-ETHD-014","0081-ETHD-015","0081-ETHD-016","0081-ETHD-017","0081-ETHD-018","0081-ETHD-019","0081-ETHD-020","0081-ETHD-021","0081-ETHD-022","0081-ETHD-023","0081-ETHD-024","0081-ETHD-025","0081-ETHD-026","0081-ETHD-027","0081-ETHD-028","0081-ETHD-029","0081-ETHD-030","0081-ETHD-031","0081-ETHD-032","0081-ETHD-033","0081-ETHD-034","0081-ETHD-035","0081-ETHD-036","0081-ETHD-037","0081-ETHD-038","0081-ETHD-039","0081-ETHD-040","0081-ETHD-041","0081-ETHD-042","0081-ETHD-043","0081-ETHD-044","0081-ETHD-045"] + "acs": ["0082-ETHD-001","0082-ETHD-002","0082-ETHD-003","0082-ETHD-004","0082-ETHD-005","0082-ETHD-006","0082-ETHD-007","0082-ETHD-008","0082-ETHD-009","0082-ETHD-010","0082-ETHD-011","0082-ETHD-012","0082-ETHD-013","0082-ETHD-014","0082-ETHD-015","0082-ETHD-016","0082-ETHD-017","0082-ETHD-018","0082-ETHD-019","0082-ETHD-020","0082-ETHD-021","0082-ETHD-022","0082-ETHD-023","0082-ETHD-024","0082-ETHD-025","0082-ETHD-026","0082-ETHD-027","0082-ETHD-028","0082-ETHD-029","0082-ETHD-030","0082-ETHD-031","0082-ETHD-032","0082-ETHD-033","0082-ETHD-034","0082-ETHD-035","0082-ETHD-036","0082-ETHD-037","0082-ETHD-038","0082-ETHD-039","0082-ETHD-040","0082-ETHD-041","0082-ETHD-042","0082-ETHD-043","0082-ETHD-044","0082-ETHD-045"] }, "SLA": { "milestone": "deployment-2", - "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" + "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0044-LIME-050", "0044-LIME-051", "0044-LIME-052", "0044-LIME-053", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-049", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" ] }, "Unknown": { From dddaad6cd5aa0e400257d6bf8be867f49599c868 Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 20 Jul 2023 14:11:48 +0100 Subject: [PATCH 325/649] fix icebergs --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 35c0ccd75..0d2d5b7b7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,7 +1,7 @@ { "Governance Transfers": { "milestone": "deployment-1", - "acs": [ "0028-GOVE-073", "0028-GOVE-074", "0028-GOVE-128", "0028-GOVE-119", "0028-GOVE-120", "0028-GOVE-132", "0028-GOVE-122", "0028-GOVE-077", "0028-GOVE-079", "0028-GOVE-081", "0028-GOVE-082", "0028-GOVE-083", "0028-GOVE-084", "0028-GOVE-085", "0028-GOVE-086", "0028-GOVE-087", "0028-GOVE-088", "0028-GOVE-089", "0028-GOVE-091", "0028-GOVE-092", "0028-GOVE-094", "0028-GOVE-095", "0028-GOVE-096", "0028-GOVE-099", "0028-GOVE-100", "0028-GOVE-101", "0028-GOVE-102", "0028-GOVE-130", "0028-GOVE-131", "0028-GOVE-103", "0028-GOVE-133", "0028-GOVE-129", "0028-GOVE-104", "0028-GOVE-105", "0028-GOVE-106", "0028-GOVE-107", "0028-GOVE-123", "0028-GOVE-124", "0028-GOVE-125", "0028-GOVE-126", "0028-GOVE-127", "0028-GOVE-140", "0028-GOVE-141", "0028-GOVE-144", "0028-GOVE-142", "0028-GOVE-144"] + "acs": [ "0028-GOVE-073", "0028-GOVE-074", "0028-GOVE-128", "0028-GOVE-119", "0028-GOVE-120", "0028-GOVE-132", "0028-GOVE-122", "0028-GOVE-077", "0028-GOVE-079", "0028-GOVE-081", "0028-GOVE-082", "0028-GOVE-083", "0028-GOVE-084", "0028-GOVE-085", "0028-GOVE-086", "0028-GOVE-087", "0028-GOVE-088", "0028-GOVE-089", "0028-GOVE-091", "0028-GOVE-092", "0028-GOVE-094", "0028-GOVE-095", "0028-GOVE-096", "0028-GOVE-099", "0028-GOVE-100", "0028-GOVE-101", "0028-GOVE-102", "0028-GOVE-130", "0028-GOVE-131", "0028-GOVE-103", "0028-GOVE-133", "0028-GOVE-129", "0028-GOVE-104", "0028-GOVE-105", "0028-GOVE-106", "0028-GOVE-107", "0028-GOVE-123", "0028-GOVE-124", "0028-GOVE-125", "0028-GOVE-126", "0028-GOVE-127", "0028-GOVE-140", "0028-GOVE-141", "0028-GOVE-142", "0028-GOVE-143"] }, "Iceberg Orders": { "milestone": "deployment-1", @@ -14,7 +14,7 @@ }, "Successor Markets": { "milestone": "deployment-1", - "acs": ["0001-MKTF-006", "0001-MKTF-007", "0001-MKTF-008", "0001-MKTF-009", "0001-MKTF-010", "0028-GOVE-071", "0028-GOVE-072", "0028-GOVE-093", "0042-LIQF-031", "0042-LIQF-048", "0042-LIQF-033", "0042-LIQF-034", "0081-SUCM-001", "0081-SUCM-002", "0081-SUCM-003", "0081-SUCM-005", "0081-SUCM-006", "0081-SUCM-007", "0081-SUCM-008", "0081-SUCM-027", "0081-SUCM-009", "0081-SUCM-010", "0081-SUCM-011", "0081-SUCM-014", "0081-SUCM-018", "0081-SUCM-012", "0081-SUCM-023", "0081-SUCM-024", "0081-SUCM-013", "0081-SUCM-016", "0081-SUCM-017", "0081-SUCM-025", "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", "0081-SUCM-022" + "acs": ["0001-MKTF-006", "0001-MKTF-007", "0001-MKTF-008", "0001-MKTF-009", "0001-MKTF-010", "0028-GOVE-071", "0028-GOVE-072", "0028-GOVE-093", "0042-LIQF-031", "0042-LIQF-048", "0042-LIQF-033", "0042-LIQF-034", "0081-SUCM-001", "0081-SUCM-003", "0081-SUCM-005", "0081-SUCM-006", "0081-SUCM-007", "0081-SUCM-008", "0081-SUCM-027", "0081-SUCM-009", "0081-SUCM-010", "0081-SUCM-011", "0081-SUCM-014", "0081-SUCM-018", "0081-SUCM-012", "0081-SUCM-023", "0081-SUCM-024", "0081-SUCM-013", "0081-SUCM-016", "0081-SUCM-017", "0081-SUCM-025", "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", "0081-SUCM-022" ] }, "Perps": { From f9cacf7cab724ce8b0f6c4244489d73ccd64b86d Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 20 Jul 2023 15:37:15 +0100 Subject: [PATCH 326/649] reformat features.json, fix Governance Transfers & Stop Orders --- protocol/features.json | 642 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 634 insertions(+), 8 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 0d2d5b7b7..831dfa71e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,39 +1,665 @@ { "Governance Transfers": { "milestone": "deployment-1", - "acs": [ "0028-GOVE-073", "0028-GOVE-074", "0028-GOVE-128", "0028-GOVE-119", "0028-GOVE-120", "0028-GOVE-132", "0028-GOVE-122", "0028-GOVE-077", "0028-GOVE-079", "0028-GOVE-081", "0028-GOVE-082", "0028-GOVE-083", "0028-GOVE-084", "0028-GOVE-085", "0028-GOVE-086", "0028-GOVE-087", "0028-GOVE-088", "0028-GOVE-089", "0028-GOVE-091", "0028-GOVE-092", "0028-GOVE-094", "0028-GOVE-095", "0028-GOVE-096", "0028-GOVE-099", "0028-GOVE-100", "0028-GOVE-101", "0028-GOVE-102", "0028-GOVE-130", "0028-GOVE-131", "0028-GOVE-103", "0028-GOVE-133", "0028-GOVE-129", "0028-GOVE-104", "0028-GOVE-105", "0028-GOVE-106", "0028-GOVE-107", "0028-GOVE-123", "0028-GOVE-124", "0028-GOVE-125", "0028-GOVE-126", "0028-GOVE-127", "0028-GOVE-140", "0028-GOVE-141", "0028-GOVE-142", "0028-GOVE-143"] + "acs": [ + "0028-GOVE-073", + "0028-GOVE-074", + "0028-GOVE-128", + "0028-GOVE-119", + "0028-GOVE-120", + "0028-GOVE-132", + "0028-GOVE-122", + "0028-GOVE-077", + "0028-GOVE-079", + "0028-GOVE-081", + "0028-GOVE-082", + "0028-GOVE-083", + "0028-GOVE-084", + "0028-GOVE-085", + "0028-GOVE-086", + "0028-GOVE-087", + "0028-GOVE-088", + "0028-GOVE-089", + "0028-GOVE-091", + "0028-GOVE-092", + "0028-GOVE-094", + "0028-GOVE-095", + "0028-GOVE-096", + "0028-GOVE-099", + "0028-GOVE-100", + "0028-GOVE-101", + "0028-GOVE-102", + "0028-GOVE-130", + "0028-GOVE-131", + "0028-GOVE-103", + "0028-GOVE-133", + "0028-GOVE-129", + "0028-GOVE-104", + "0028-GOVE-105", + "0028-GOVE-106", + "0028-GOVE-107", + "0028-GOVE-123", + "0028-GOVE-124", + "0028-GOVE-125", + "0028-GOVE-126", + "0028-GOVE-127", + "0028-GOVE-140", + "0028-GOVE-141", + "0028-GOVE-142", + "0028-GOVE-143", + "0028-GOVE-144" + ] }, "Iceberg Orders": { "milestone": "deployment-1", - "acs": ["0014-ORDT-039", "0014-ORDT-007", "0014-ORDT-008", "0014-ORDT-009", "0014-ORDT-010", "0014-ORDT-011", "0014-ORDT-012", "0014-ORDT-013", "0014-ORDT-014", "0014-ORDT-015", "0014-ORDT-016", "0014-ORDT-017", "0014-ORDT-018", "0014-ORDT-020", "0014-ORDT-021", "0014-ORDT-022", "0014-ORDT-023", "0014-ORDT-024", "0014-ORDT-025", "0014-ORDT-026", "0014-ORDT-027", "0014-ORDT-028", "0014-ORDT-029", "0014-ORDT-030", "0014-ORDT-031", "0014-ORDT-032", "0014-ORDT-033", "0014-ORDT-034", "0014-ORDT-037", "0014-ORDT-038", "0014-ORDT-035", "0014-ORDT-036", "0014-ORDT-069", "0014-ORDT-070"] + "acs": [ + "0014-ORDT-039", + "0014-ORDT-007", + "0014-ORDT-008", + "0014-ORDT-009", + "0014-ORDT-010", + "0014-ORDT-011", + "0014-ORDT-012", + "0014-ORDT-013", + "0014-ORDT-014", + "0014-ORDT-015", + "0014-ORDT-016", + "0014-ORDT-017", + "0014-ORDT-018", + "0014-ORDT-020", + "0014-ORDT-021", + "0014-ORDT-022", + "0014-ORDT-023", + "0014-ORDT-024", + "0014-ORDT-025", + "0014-ORDT-026", + "0014-ORDT-027", + "0014-ORDT-028", + "0014-ORDT-029", + "0014-ORDT-030", + "0014-ORDT-031", + "0014-ORDT-032", + "0014-ORDT-033", + "0014-ORDT-034", + "0014-ORDT-037", + "0014-ORDT-038", + "0014-ORDT-035", + "0014-ORDT-036", + "0014-ORDT-069", + "0014-ORDT-070" + ] }, "Stop Orders": { "milestone": "deployment-1", - "acs": ["0014-ORDT-040", "0014-ORDT-041", "0014-ORDT-042", "0014-ORDT-043", "0014-ORDT-044", "0014-ORDT-045", "0014-ORDT-046", "0014-ORDT-047", "0014-ORDT-048", "0014-ORDT-049", "0014-ORDT-050", "0014-ORDT-051", "0014-ORDT-052", "0014-ORDT-053", "0014-ORDT-054", "0014-ORDT-055", "0014-ORDT-056", "0014-ORDT-058", "0014-ORDT-059", "0014-ORDT-060", "0014-ORDT-061", "0014-ORDT-062", "0014-ORDT-063", "0014-ORDT-064", "0014-ORDT-065", "0014-ORDT-066", "0014-ORDT-067", "0014-ORDT-068", "0014-ORDT-071", "0014-ORDT-072", "0014-ORDT-073", "0014-ORDT-074", "0014-ORDT-075", "0014-ORDT-076", "0014-ORDT-077", "0014-ORDT-078", "0014-ORDT-079", "0014-ORDT-080", "0079-TGAP-004", "0079-TGAP-005" + "acs": [ + "0014-ORDT-041", + "0014-ORDT-042", + "0014-ORDT-043", + "0014-ORDT-044", + "0014-ORDT-045", + "0014-ORDT-046", + "0014-ORDT-047", + "0014-ORDT-048", + "0014-ORDT-049", + "0014-ORDT-050", + "0014-ORDT-051", + "0014-ORDT-052", + "0014-ORDT-053", + "0014-ORDT-054", + "0014-ORDT-055", + "0014-ORDT-056", + "0014-ORDT-058", + "0014-ORDT-059", + "0014-ORDT-060", + "0014-ORDT-061", + "0014-ORDT-062", + "0014-ORDT-063", + "0014-ORDT-064", + "0014-ORDT-065", + "0014-ORDT-066", + "0014-ORDT-067", + "0014-ORDT-068", + "0014-ORDT-071", + "0014-ORDT-072", + "0014-ORDT-073", + "0014-ORDT-074", + "0014-ORDT-075", + "0014-ORDT-076", + "0014-ORDT-077", + "0014-ORDT-078", + "0014-ORDT-079", + "0014-ORDT-080", + "0079-TGAP-004", + "0079-TGAP-005" ] }, "Successor Markets": { "milestone": "deployment-1", - "acs": ["0001-MKTF-006", "0001-MKTF-007", "0001-MKTF-008", "0001-MKTF-009", "0001-MKTF-010", "0028-GOVE-071", "0028-GOVE-072", "0028-GOVE-093", "0042-LIQF-031", "0042-LIQF-048", "0042-LIQF-033", "0042-LIQF-034", "0081-SUCM-001", "0081-SUCM-003", "0081-SUCM-005", "0081-SUCM-006", "0081-SUCM-007", "0081-SUCM-008", "0081-SUCM-027", "0081-SUCM-009", "0081-SUCM-010", "0081-SUCM-011", "0081-SUCM-014", "0081-SUCM-018", "0081-SUCM-012", "0081-SUCM-023", "0081-SUCM-024", "0081-SUCM-013", "0081-SUCM-016", "0081-SUCM-017", "0081-SUCM-025", "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", "0081-SUCM-022" + "acs": [ + "0001-MKTF-006", + "0001-MKTF-007", + "0001-MKTF-008", + "0001-MKTF-009", + "0001-MKTF-010", + "0028-GOVE-071", + "0028-GOVE-072", + "0028-GOVE-093", + "0042-LIQF-031", + "0042-LIQF-048", + "0042-LIQF-033", + "0042-LIQF-034", + "0081-SUCM-001", + "0081-SUCM-003", + "0081-SUCM-005", + "0081-SUCM-006", + "0081-SUCM-007", + "0081-SUCM-008", + "0081-SUCM-027", + "0081-SUCM-009", + "0081-SUCM-010", + "0081-SUCM-011", + "0081-SUCM-014", + "0081-SUCM-018", + "0081-SUCM-012", + "0081-SUCM-023", + "0081-SUCM-024", + "0081-SUCM-013", + "0081-SUCM-016", + "0081-SUCM-017", + "0081-SUCM-025", + "0081-SUCM-026", + "0081-SUCM-020", + "0081-SUCM-021", + "0081-SUCM-022" ] }, "Perps": { "milestone": "deployment-2", - "acs": ["0001-MKTF-005", "0053-PERP-001", "0053-PERP-002", "0053-PERP-003", "0053-PERP-004", "0053-PERP-005", "0053-PERP-006", "0053-PERP-007", "0053-PERP-008", "0053-PERP-009", "0053-PERP-015", "0053-PERP-016", "0053-PERP-017" + "acs": [ + "0001-MKTF-005", + "0053-PERP-001", + "0053-PERP-002", + "0053-PERP-003", + "0053-PERP-004", + "0053-PERP-005", + "0053-PERP-006", + "0053-PERP-007", + "0053-PERP-008", + "0053-PERP-009", + "0053-PERP-015", + "0053-PERP-016", + "0053-PERP-017" ] }, "Spot": { "milestone": "deployment-2", - "acs": ["0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", "0080-SPOT-018", "0080-SPOT-019", "0080-SPOT-020", "0081-SUCM-004", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", "0056-REWA-054", "0056-REWA-055", "0056-REWA-056", "0056-REWA-057", "0056-REWA-058", "0056-REWA-059", "0056-REWA-060", "0056-REWA-061", "0056-REWA-062", "0056-REWA-063", "0056-REWA-064", "0056-REWA-065", "0056-REWA-066", "0056-REWA-067", "0056-REWA-068", "0056-REWA-069", "0056-REWA-070", "0056-REWA-071", "0056-REWA-072", "0056-REWA-073", "0056-REWA-074", "0056-REWA-075", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-079", "0073-LIMN-080", "0073-LIMN-081", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", "0004-AMND-031", "0004-AMND-032", "0004-AMND-033", "0004-AMND-034", "0004-AMND-035", "0004-AMND-036", "0004-AMND-037", "0004-AMND-038", "0004-AMND-039", "0004-AMND-040", "0004-AMND-041", "0004-AMND-042", "0004-AMND-043", "0004-AMND-044", "0004-AMND-045", "0004-AMND-046", "0004-AMND-047", "0004-AMND-048", "0004-AMND-049", "0004-AMND-050", "0004-AMND-051", "0004-AMND-052", "0004-AMND-053", "0004-AMND-054", "0004-AMND-055", "0011-MARA-018", "0011-MARA-019", "0011-MARA-020", "0011-MARA-021", "0011-MARA-022", "0011-MARA-023", "0011-MARA-024", "0011-MARA-025", "0011-MARA-026", "0011-MARA-027", "0011-MARA-028", "0011-MARA-029", "0011-MARA-030", "0011-MARA-031", "0011-MARA-032", "0013-ACCT-024", "0013-ACCT-025", "0013-ACCT-030", "0013-ACCT-031", "0014-ORDT-081", "0014-ORDT-082", "0014-ORDT-083", "0014-ORDT-084", "0014-ORDT-085", "0014-ORDT-086", "0014-ORDT-087", "0014-ORDT-088", "0014-ORDT-089", "0014-ORDT-090", "0014-ORDT-091", "0014-ORDT-092", "0014-ORDT-093", "0014-ORDT-094", "0014-ORDT-095", "0014-ORDT-096", "0014-ORDT-097", "0014-ORDT-098", "0014-ORDT-099", "0014-ORDT-100", "0014-ORDT-101", "0014-ORDT-102", "0014-ORDT-103", "0014-ORDT-104", "0014-ORDT-105", "0014-ORDT-106", "0014-ORDT-107", "0014-ORDT-108", "0014-ORDT-109", "0014-ORDT-110", "0014-ORDT-111", "0014-ORDT-112", "0014-ORDT-113", "0014-ORDT-114", "0014-ORDT-115", "0014-ORDT-116", "0014-ORDT-117", "0014-ORDT-118", "0014-ORDT-119", "0021-MDAT-013", "0021-MDAT-014", "0021-MDAT-015", "0021-MDAT-016", "0021-MDAT-017", "0021-MDAT-018", "0021-MDAT-019", "0021-MDAT-020", "0024-OSTA-030", "0024-OSTA-031", "0024-OSTA-032", "0024-OSTA-033", "0024-OSTA-034", "0024-OSTA-035", "0024-OSTA-036", "0024-OSTA-037", "0024-OSTA-038", "0024-OSTA-039", "0024-OSTA-040", "0024-OSTA-041", "0024-OSTA-042", "0024-OSTA-043", "0024-OSTA-044", "0024-OSTA-045", "0024-OSTA-046", "0024-OSTA-047", "0024-OSTA-048", "0025-OCRE-004", "0025-OCRE-005", "0025-OCRE-006", "0026-AUCT-023", "0026-AUCT-024", "0026-AUCT-025", "0026-AUCT-026", "0026-AUCT-027", "0026-AUCT-028", "0026-AUCT-029", "0026-AUCT-031", "0026-AUCT-032", "0029-FEES-015", "0029-FEES-016", "0029-FEES-017", "0029-FEES-018", "0029-FEES-019", "0029-FEES-020", "0029-FEES-021", "0029-FEES-022", "0032-PRIM-022", "0032-PRIM-023", "0032-PRIM-024", "0032-PRIM-025", "0032-PRIM-026", "0032-PRIM-027", "0032-PRIM-028", "0032-PRIM-029", "0032-PRIM-030", "0032-PRIM-031", "0032-PRIM-032", "0032-PRIM-033", "0032-PRIM-034", "0032-PRIM-035", "0032-PRIM-036", "0032-PRIM-037", "0032-PRIM-038", "0033-OCAN-011", "0033-OCAN-012", "0033-OCAN-013", "0033-OCAN-014", "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", "0034-PROB-007", "0034-PROB-008", "0034-PROB-009", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", "0039-MKTD-023", "0039-MKTD-024", "0039-MKTD-025", "0039-MKTD-026", "0039-MKTD-027", "0039-MKTD-028", "0039-MKTD-029", "0039-MKTD-030", "0039-MKTD-031", "0039-MKTD-032", "0039-MKTD-033", "0043-MKTL-005", "0043-MKTL-006", "0043-MKTL-007", "0043-MKTL-008", "0049-TVAL-007", "0049-TVAL-008", "0049-TVAL-009", "0049-TVAL-010", "0049-TVAL-011", "0049-TVAL-012", "0051-PROD-004", "0051-PROD-005", "0051-PROD-006", "0052-FPOS-003", "0052-FPOS-004", "0054-NETP-007", "0054-NETP-008", "0054-NETP-009", "0054-NETP-010", "0054-NETP-011", "0057-TRAN-063", "0065-FTCO-005", "0065-FTCO-006", "0065-FTCO-007", "0065-FTCO-008", "0066-VALW-004", "0066-VALW-005", "0068-MATC-060", "0068-MATC-061", "0068-MATC-062", "0068-MATC-063", "0068-MATC-064", "0068-MATC-065", "0068-MATC-066", "0068-MATC-067", "0068-MATC-068", "0068-MATC-069", "0068-MATC-070", "0068-MATC-071", "0068-MATC-072", "0068-MATC-073", "0068-MATC-074", "0068-MATC-075", "0068-MATC-076", "0068-MATC-077", "0068-MATC-078", "0068-MATC-079", "0068-MATC-080", "0068-MATC-081", "0068-MATC-082", "0068-MATC-083", "0068-MATC-084", "0068-MATC-085", "0068-MATC-086", "0068-MATC-087", "0068-MATC-088", "0068-MATC-089", "0068-MATC-090", "0068-MATC-091", "0068-MATC-092", "0070-MKTD-008", "0070-MKTD-009", "0070-MKTD-010", "0070-MKTD-011", "0070-MKTD-012", "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", "0073-LIMN-077", "0073-LIMN-078", "0073-LIMN-080", "0073-LIMN-082", "0073-LIMN-083", "0073-LIMN-084", "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", "0073-LIMN-092", "0073-LIMN-093", "0073-LIMN-094", "0073-LIMN-095", "0073-LIMN-096", "0073-LIMN-097", "0073-LIMN-098", "0073-LIMN-099", "0073-LIMN-100", "0073-LIMN-101", "0073-LIMN-102", "0073-LIMN-103", "0073-LIMN-104", "0074-BTCH-011", "0074-BTCH-012", "0074-BTCH-015", "0074-BTCH-016", "0074-BTCH-019", "0079-TGAP-006", "0079-TGAP-007" + "acs": [ + "0080-SPOT-001", + "0080-SPOT-002", + "0080-SPOT-003", + "0080-SPOT-004", + "0080-SPOT-005", + "0080-SPOT-006", + "0080-SPOT-007", + "0080-SPOT-008", + "0080-SPOT-009", + "0080-SPOT-010", + "0080-SPOT-011", + "0080-SPOT-012", + "0080-SPOT-013", + "0080-SPOT-014", + "0080-SPOT-015", + "0080-SPOT-016", + "0080-SPOT-017", + "0080-SPOT-018", + "0080-SPOT-019", + "0080-SPOT-020", + "0081-SUCM-004", + "0044-LIME-043", + "0044-LIME-044", + "0044-LIME-045", + "0044-LIME-046", + "0044-LIME-047", + "0044-LIME-048", + "0056-REWA-051", + "0056-REWA-052", + "0056-REWA-053", + "0056-REWA-054", + "0056-REWA-055", + "0056-REWA-056", + "0056-REWA-057", + "0056-REWA-058", + "0056-REWA-059", + "0056-REWA-060", + "0056-REWA-061", + "0056-REWA-062", + "0056-REWA-063", + "0056-REWA-064", + "0056-REWA-065", + "0056-REWA-066", + "0056-REWA-067", + "0056-REWA-068", + "0056-REWA-069", + "0056-REWA-070", + "0056-REWA-071", + "0056-REWA-072", + "0056-REWA-073", + "0056-REWA-074", + "0056-REWA-075", + "0073-LIMN-077", + "0073-LIMN-078", + "0073-LIMN-079", + "0073-LIMN-080", + "0073-LIMN-081", + "0073-LIMN-082", + "0073-LIMN-083", + "0073-LIMN-084", + "0073-LIMN-085", + "0073-LIMN-086", + "0073-LIMN-087", + "0073-LIMN-088", + "0073-LIMN-089", + "0073-LIMN-090", + "0073-LIMN-091", + "0073-LIMN-092", + "0073-LIMN-093", + "0073-LIMN-094", + "0073-LIMN-095", + "0073-LIMN-096", + "0073-LIMN-097", + "0073-LIMN-098", + "0073-LIMN-099", + "0073-LIMN-100", + "0037-OPEG-019", + "0008-TRAD-008", + "0004-AMND-030", + "0004-AMND-031", + "0004-AMND-032", + "0004-AMND-033", + "0004-AMND-034", + "0004-AMND-035", + "0004-AMND-036", + "0004-AMND-037", + "0004-AMND-038", + "0004-AMND-039", + "0004-AMND-040", + "0004-AMND-041", + "0004-AMND-042", + "0004-AMND-043", + "0004-AMND-044", + "0004-AMND-045", + "0004-AMND-046", + "0004-AMND-047", + "0004-AMND-048", + "0004-AMND-049", + "0004-AMND-050", + "0004-AMND-051", + "0004-AMND-052", + "0004-AMND-053", + "0004-AMND-054", + "0004-AMND-055", + "0011-MARA-018", + "0011-MARA-019", + "0011-MARA-020", + "0011-MARA-021", + "0011-MARA-022", + "0011-MARA-023", + "0011-MARA-024", + "0011-MARA-025", + "0011-MARA-026", + "0011-MARA-027", + "0011-MARA-028", + "0011-MARA-029", + "0011-MARA-030", + "0011-MARA-031", + "0011-MARA-032", + "0013-ACCT-024", + "0013-ACCT-025", + "0013-ACCT-030", + "0013-ACCT-031", + "0014-ORDT-081", + "0014-ORDT-082", + "0014-ORDT-083", + "0014-ORDT-084", + "0014-ORDT-085", + "0014-ORDT-086", + "0014-ORDT-087", + "0014-ORDT-088", + "0014-ORDT-089", + "0014-ORDT-090", + "0014-ORDT-091", + "0014-ORDT-092", + "0014-ORDT-093", + "0014-ORDT-094", + "0014-ORDT-095", + "0014-ORDT-096", + "0014-ORDT-097", + "0014-ORDT-098", + "0014-ORDT-099", + "0014-ORDT-100", + "0014-ORDT-101", + "0014-ORDT-102", + "0014-ORDT-103", + "0014-ORDT-104", + "0014-ORDT-105", + "0014-ORDT-106", + "0014-ORDT-107", + "0014-ORDT-108", + "0014-ORDT-109", + "0014-ORDT-110", + "0014-ORDT-111", + "0014-ORDT-112", + "0014-ORDT-113", + "0014-ORDT-114", + "0014-ORDT-115", + "0014-ORDT-116", + "0014-ORDT-117", + "0014-ORDT-118", + "0014-ORDT-119", + "0021-MDAT-013", + "0021-MDAT-014", + "0021-MDAT-015", + "0021-MDAT-016", + "0021-MDAT-017", + "0021-MDAT-018", + "0021-MDAT-019", + "0021-MDAT-020", + "0024-OSTA-030", + "0024-OSTA-031", + "0024-OSTA-032", + "0024-OSTA-033", + "0024-OSTA-034", + "0024-OSTA-035", + "0024-OSTA-036", + "0024-OSTA-037", + "0024-OSTA-038", + "0024-OSTA-039", + "0024-OSTA-040", + "0024-OSTA-041", + "0024-OSTA-042", + "0024-OSTA-043", + "0024-OSTA-044", + "0024-OSTA-045", + "0024-OSTA-046", + "0024-OSTA-047", + "0024-OSTA-048", + "0025-OCRE-004", + "0025-OCRE-005", + "0025-OCRE-006", + "0026-AUCT-023", + "0026-AUCT-024", + "0026-AUCT-025", + "0026-AUCT-026", + "0026-AUCT-027", + "0026-AUCT-028", + "0026-AUCT-029", + "0026-AUCT-031", + "0026-AUCT-032", + "0029-FEES-015", + "0029-FEES-016", + "0029-FEES-017", + "0029-FEES-018", + "0029-FEES-019", + "0029-FEES-020", + "0029-FEES-021", + "0029-FEES-022", + "0032-PRIM-022", + "0032-PRIM-023", + "0032-PRIM-024", + "0032-PRIM-025", + "0032-PRIM-026", + "0032-PRIM-027", + "0032-PRIM-028", + "0032-PRIM-029", + "0032-PRIM-030", + "0032-PRIM-031", + "0032-PRIM-032", + "0032-PRIM-033", + "0032-PRIM-034", + "0032-PRIM-035", + "0032-PRIM-036", + "0032-PRIM-037", + "0032-PRIM-038", + "0033-OCAN-011", + "0033-OCAN-012", + "0033-OCAN-013", + "0033-OCAN-014", + "0033-OCAN-015", + "0033-OCAN-016", + "0033-OCAN-017", + "0034-PROB-007", + "0034-PROB-008", + "0034-PROB-009", + "0039-MKTD-020", + "0039-MKTD-021", + "0039-MKTD-022", + "0039-MKTD-023", + "0039-MKTD-024", + "0039-MKTD-025", + "0039-MKTD-026", + "0039-MKTD-027", + "0039-MKTD-028", + "0039-MKTD-029", + "0039-MKTD-030", + "0039-MKTD-031", + "0039-MKTD-032", + "0039-MKTD-033", + "0043-MKTL-005", + "0043-MKTL-006", + "0043-MKTL-007", + "0043-MKTL-008", + "0049-TVAL-007", + "0049-TVAL-008", + "0049-TVAL-009", + "0049-TVAL-010", + "0049-TVAL-011", + "0049-TVAL-012", + "0051-PROD-004", + "0051-PROD-005", + "0051-PROD-006", + "0052-FPOS-003", + "0052-FPOS-004", + "0054-NETP-007", + "0054-NETP-008", + "0054-NETP-009", + "0054-NETP-010", + "0054-NETP-011", + "0057-TRAN-063", + "0065-FTCO-005", + "0065-FTCO-006", + "0065-FTCO-007", + "0065-FTCO-008", + "0066-VALW-004", + "0066-VALW-005", + "0068-MATC-060", + "0068-MATC-061", + "0068-MATC-062", + "0068-MATC-063", + "0068-MATC-064", + "0068-MATC-065", + "0068-MATC-066", + "0068-MATC-067", + "0068-MATC-068", + "0068-MATC-069", + "0068-MATC-070", + "0068-MATC-071", + "0068-MATC-072", + "0068-MATC-073", + "0068-MATC-074", + "0068-MATC-075", + "0068-MATC-076", + "0068-MATC-077", + "0068-MATC-078", + "0068-MATC-079", + "0068-MATC-080", + "0068-MATC-081", + "0068-MATC-082", + "0068-MATC-083", + "0068-MATC-084", + "0068-MATC-085", + "0068-MATC-086", + "0068-MATC-087", + "0068-MATC-088", + "0068-MATC-089", + "0068-MATC-090", + "0068-MATC-091", + "0068-MATC-092", + "0070-MKTD-008", + "0070-MKTD-009", + "0070-MKTD-010", + "0070-MKTD-011", + "0070-MKTD-012", + "0070-MKTD-013", + "0070-MKTD-014", + "0070-MKTD-015", + "0073-LIMN-077", + "0073-LIMN-078", + "0073-LIMN-080", + "0073-LIMN-082", + "0073-LIMN-083", + "0073-LIMN-084", + "0073-LIMN-086", + "0073-LIMN-087", + "0073-LIMN-090", + "0073-LIMN-091", + "0073-LIMN-092", + "0073-LIMN-093", + "0073-LIMN-094", + "0073-LIMN-095", + "0073-LIMN-096", + "0073-LIMN-097", + "0073-LIMN-098", + "0073-LIMN-099", + "0073-LIMN-100", + "0073-LIMN-101", + "0073-LIMN-102", + "0073-LIMN-103", + "0073-LIMN-104", + "0074-BTCH-011", + "0074-BTCH-012", + "0074-BTCH-015", + "0074-BTCH-016", + "0074-BTCH-019", + "0079-TGAP-006", + "0079-TGAP-007" ] }, "Ethereum Oracles": { "milestone": "deployment-2", - "acs": ["0082-ETHD-001","0082-ETHD-002","0082-ETHD-003","0082-ETHD-004","0082-ETHD-005","0082-ETHD-006","0082-ETHD-007","0082-ETHD-008","0082-ETHD-009","0082-ETHD-010","0082-ETHD-011","0082-ETHD-012","0082-ETHD-013","0082-ETHD-014","0082-ETHD-015","0082-ETHD-016","0082-ETHD-017","0082-ETHD-018","0082-ETHD-019","0082-ETHD-020","0082-ETHD-021","0082-ETHD-022","0082-ETHD-023","0082-ETHD-024","0082-ETHD-025","0082-ETHD-026","0082-ETHD-027","0082-ETHD-028","0082-ETHD-029","0082-ETHD-030","0082-ETHD-031","0082-ETHD-032","0082-ETHD-033","0082-ETHD-034","0082-ETHD-035","0082-ETHD-036","0082-ETHD-037","0082-ETHD-038","0082-ETHD-039","0082-ETHD-040","0082-ETHD-041","0082-ETHD-042","0082-ETHD-043","0082-ETHD-044","0082-ETHD-045"] + "acs": [ + "0082-ETHD-001", + "0082-ETHD-002", + "0082-ETHD-003", + "0082-ETHD-004", + "0082-ETHD-005", + "0082-ETHD-006", + "0082-ETHD-007", + "0082-ETHD-008", + "0082-ETHD-009", + "0082-ETHD-010", + "0082-ETHD-011", + "0082-ETHD-012", + "0082-ETHD-013", + "0082-ETHD-014", + "0082-ETHD-015", + "0082-ETHD-016", + "0082-ETHD-017", + "0082-ETHD-018", + "0082-ETHD-019", + "0082-ETHD-020", + "0082-ETHD-021", + "0082-ETHD-022", + "0082-ETHD-023", + "0082-ETHD-024", + "0082-ETHD-025", + "0082-ETHD-026", + "0082-ETHD-027", + "0082-ETHD-028", + "0082-ETHD-029", + "0082-ETHD-030", + "0082-ETHD-031", + "0082-ETHD-032", + "0082-ETHD-033", + "0082-ETHD-034", + "0082-ETHD-035", + "0082-ETHD-036", + "0082-ETHD-037", + "0082-ETHD-038", + "0082-ETHD-039", + "0082-ETHD-040", + "0082-ETHD-041", + "0082-ETHD-042", + "0082-ETHD-043", + "0082-ETHD-044", + "0082-ETHD-045" + ] }, "SLA": { "milestone": "deployment-2", - "acs": ["0042-LIQF-032", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", "0042-LIQF-042", "0042-LIQF-035", "0042-LIQF-049", "0042-LIQF-047", "0042-LIQF-039", "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", "0044-LIME-050", "0044-LIME-051", "0044-LIME-052", "0044-LIME-053", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", "0044-LIME-016", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", "0044-LIME-022", "0044-LIME-023", "0044-LIME-030", "0044-LIME-024", "0044-LIME-031", "0044-LIME-025", "0044-LIME-026", "0044-LIME-027", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", "0044-LIME-037", "0044-LIME-038", "0044-LIME-039", "0044-LIME-040", "0044-LIME-041", "0044-LIME-042", "0044-LIME-043", "0044-LIME-044", "0044-LIME-045", "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", "0044-LIME-049", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022" + "acs": [ + "0042-LIQF-032", + "0042-LIQF-034", + "0042-LIQF-037", + "0042-LIQF-038", + "0042-LIQF-041", + "0042-LIQF-042", + "0042-LIQF-035", + "0042-LIQF-049", + "0042-LIQF-047", + "0042-LIQF-039", + "0042-LIQF-040", + "0042-LIQF-043", + "0042-LIQF-044", + "0044-LIME-050", + "0044-LIME-051", + "0044-LIME-052", + "0044-LIME-053", + "0042-LIQF-045", + "0042-LIQF-046", + "0044-LIME-013", + "0044-LIME-014", + "0044-LIME-015", + "0044-LIME-016", + "0044-LIME-018", + "0044-LIME-019", + "0044-LIME-020", + "0044-LIME-021", + "0044-LIME-030", + "0044-LIME-031", + "0044-LIME-022", + "0044-LIME-023", + "0044-LIME-030", + "0044-LIME-024", + "0044-LIME-031", + "0044-LIME-025", + "0044-LIME-026", + "0044-LIME-027", + "0044-LIME-028", + "0044-LIME-029", + "0044-LIME-032", + "0044-LIME-033", + "0044-LIME-034", + "0044-LIME-035", + "0044-LIME-036", + "0044-LIME-037", + "0044-LIME-038", + "0044-LIME-039", + "0044-LIME-040", + "0044-LIME-041", + "0044-LIME-042", + "0044-LIME-043", + "0044-LIME-044", + "0044-LIME-045", + "0044-LIME-046", + "0044-LIME-047", + "0044-LIME-048", + "0044-LIME-049", + "0026-AUCT-017", + "0026-AUCT-018", + "0026-AUCT-019", + "0026-AUCT-020", + "0026-AUCT-021", + "0026-AUCT-022" ] }, "Unknown": { From 94f6c3fdcbe9aef730b44714e560f5079b35e102 Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 20 Jul 2023 16:26:30 +0100 Subject: [PATCH 327/649] fix sla feats --- protocol/features.json | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 831dfa71e..947cc0468 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -610,10 +610,6 @@ "0042-LIQF-040", "0042-LIQF-043", "0042-LIQF-044", - "0044-LIME-050", - "0044-LIME-051", - "0044-LIME-052", - "0044-LIME-053", "0042-LIQF-045", "0042-LIQF-046", "0044-LIME-013", @@ -654,6 +650,10 @@ "0044-LIME-047", "0044-LIME-048", "0044-LIME-049", + "0044-LIME-050", + "0044-LIME-051", + "0044-LIME-052", + "0044-LIME-053", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", From 45120b1ce2b4c94e8e64cbe5fd92d39a764a1bc4 Mon Sep 17 00:00:00 2001 From: Edd Date: Thu, 20 Jul 2023 16:54:44 +0100 Subject: [PATCH 328/649] fix eth oracles --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 947cc0468..31f9b910d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -579,7 +579,6 @@ "0082-ETHD-030", "0082-ETHD-031", "0082-ETHD-032", - "0082-ETHD-033", "0082-ETHD-034", "0082-ETHD-035", "0082-ETHD-036", From 65b9428bfac0b29e4e88bbfab96e4dd238c5d5b7 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 24 Jul 2023 11:30:58 +0100 Subject: [PATCH 329/649] feat: add acs for new api --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++++ protocol/0044-LIME-lp_mechanics.md | 6 +++++- protocol/features.json | 6 ++++++ 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 9666b1258..ff880ca1f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -351,6 +351,10 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) - Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) +- Through the `LiquidityProviders` API, liquidity score, average entry valuation and equity-like share of each active LP can be obtained + - GRPC (0042-LIQF-047) + - GRAPHQL (0042-LIQF-048) + - REST (0042-LIQF-049) ### Successor markets diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 3eed49259..6d511286b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -285,7 +285,11 @@ Note: ## Acceptance Criteria -- Through the API, I can list all active liquidity providers for a market (0044-LIME-001) +- Through the `LiquidityProvisions` API, I can list all active liquidity providers for a market (0044-LIME-001) +- Through the `LiquidityProviders` API, I can list all active liquidity providers fee share information + - GRPC (0044-LIME-057) + - GRAPHQL (0044-LIME-058) + - REST (0044-LIME-059) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) diff --git a/protocol/features.json b/protocol/features.json index 44a18e497..37c86a4e4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -611,6 +611,9 @@ "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", + "0042-LIQF-047", + "0042-LIQF-048", + "0042-LIQF-049", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", @@ -656,6 +659,9 @@ "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", + "0044-LIME-057", + "0044-LIME-058", + "0044-LIME-059", "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", From 034438628117425c344cd4a4a104215caee988ad Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 24 Jul 2023 11:36:01 +0100 Subject: [PATCH 330/649] fix: duplicate ac numbers --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 6 +++--- protocol/features.json | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index ff880ca1f..454ab1a06 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -352,9 +352,9 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - Equity-like share of each active LP can be obtained via the API (0042-LIQF-016) - Liquidity score of each active LP can be obtained via the API (0042-LIQF-017) - Through the `LiquidityProviders` API, liquidity score, average entry valuation and equity-like share of each active LP can be obtained - - GRPC (0042-LIQF-047) - - GRAPHQL (0042-LIQF-048) - - REST (0042-LIQF-049) + - GRPC (0042-LIQF-050) + - GRAPHQL (0042-LIQF-051) + - REST (0042-LIQF-052) ### Successor markets diff --git a/protocol/features.json b/protocol/features.json index 37c86a4e4..8d53a71da 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -611,9 +611,9 @@ "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", - "0042-LIQF-047", - "0042-LIQF-048", - "0042-LIQF-049", + "0042-LIQF-050", + "0042-LIQF-051", + "0042-LIQF-052", "0044-LIME-013", "0044-LIME-014", "0044-LIME-015", From ad59cd75a440cf346c715fa555487746741d2179 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 24 Jul 2023 16:19:57 +0200 Subject: [PATCH 331/649] refactor: clarify calculationTimeStep market param --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 9666b1258..e05b01e37 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -192,7 +192,7 @@ Otherwise calculate fractional instantaneous liquidity score for each committed `fractional instantaneous liquidity score = instantaneous liquidity score / total` -If `market.liquidity.providers.fee.calculationTimeStep` is set to `0` then for each committed LP `liquidity score` is set to `fractional instantaneous liquidity score`. +If `market.liquidity.providers.fee.calculationTimeStep` is set to `0` for a given market, then for each committed LP within that market `liquidity score` is set to `fractional instantaneous liquidity score`. Otherwise whenever a new LP fee distribution period starts set a counter `n=1`. Then on every Vega time change, after `fractional instantaneous liquidity score` has been obtained for all the committed LPs, update: @@ -206,7 +206,7 @@ The liquidity score should always be rounded to 10 decimal places to prevent spu On every trade, liquidity fee should be collected immediately into the market's aggregate LP fee account. The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A network parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market's aggregate LP fee account. +A market parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market's aggregate LP fee account. Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.calculationTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. The liquidity fees are transferred from the market's aggregate LP fee account into the LP-per-market fee account, pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. @@ -329,7 +329,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - The examples provided result in the given outcomes. (0042-LIQF-008) - The total amount of liquidity fee distributed is equal to the most recent `liquidity-fee-factor` x `notional-value-of-all-trades` (0042-LIQF-011) - Liquidity providers with a commitment of 0 will not receive a share of the fees (0042-LIQF-012) -- If a market has `market.liquidity.providers.fee.calculationTimeStep` set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) +- If a market has its `market.liquidity.providers.fee.calculationTimeStep` parameter set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) - After fee distribution, if there is a remainder in the liquidity fee account and the market is not being settled, it should be left in the liquidity fee account and carried over to the next distribution window. (0042-LIQF-032) @@ -358,7 +358,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-048) - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) -- If `market.liquidity.providers.fee.calculationTimeStep > 0` and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) +- If `market.liquidity.providers.fee.calculationTimeStep > 0` for a given market and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income from that market compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) ### Calculating SLA Performance From d799bd80f8d1289f3908cb4917c55d2c249342eb Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 25 Jul 2023 16:36:06 +0200 Subject: [PATCH 332/649] Govt mkt closure AC clarification (#1851) * refactor: clarify market closure ACs * refactor: repharse AC --- protocol/0028-GOVE-governance.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 9758b44e9..3761793b2 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -518,10 +518,7 @@ APIs should also exist for clients to: - In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) - A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) - A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108) -- When multiple market closure governance proposals are submitted and accepted then one to be approved by governance last (i.e latest closing date and vote goes through) is the one whose enactment time and final settlement price get used to close the market (0028-GOVE-109) -- Once a market closure governance proposal has been accepted and was successful another proposal with same enactment date still gets accepted. If the later proposal is unsuccessful then values supplied by the last successful one get used to close the market (0028-GOVE-110) -- Once a market closure governance proposal has been accepted and was successful another proposal with earlier enactment date still gets accepted. If the later proposal is successful then values supplied within it get used to close the market (if no other proposals were successful after it) (0028-GOVE-111) -- Once a market closure governance proposal has been accepted and was successful another proposal with later enactment date gets rejected (0028-GOVE-112) +- When there's already been a market closure governance proposal successfully voted in for a given market, but not yet enacted it is still possible to submit additional market closure governance proposals for that market. If another market closure governance proposal gets voted it and it has an earlier enactment time then it's the final settlement price of that proposal which gets used. (0028-GOVE-110) - Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to resume the market. (0028-GOVE-113) - Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) - Resuming a market with other auction triggers active does not put it out of auction until those triggers allow to do so. (0028-GOVE-115) @@ -531,8 +528,9 @@ APIs should also exist for clients to: - Enacting a market closure governance proposal on a market which is in opening auction closes it immediately without generating any trades. (0028-GOVE-135) - Enacting a market closure governance proposal on a market which is in auction (of any type except the opening auction) uncrosses that auction at the current uncrossing price, generates the trades and then proceeds to close it using the final price (if applicable to the market type). (0028-GOVE-136) - Enacting a market closure governance proposal on a market that is in a settled state has no effect. (0028-GOVE-137) -- Enacting a market closure governance proposal on a market that is not in a settled state always uses the final price supplied with the proposal, even when the oracle settlement price is available at that time. (0028-GOVE-138) +- Enacting a market closure governance proposal on a market that is not in a settled state always uses the price supplied with the proposal for final settlement, even when the oracle settlement price is available at that time. (0028-GOVE-138) - Successful enactment of a market closure proposal changes the state of the market to `closed`. (0028-GOVE-139) +- Attempt to enact a market closure proposal on a closed market has no effect. (0028-GOVE-111) #### Network parameter change proposals From 0a1c10b4dd3190aa68ac8210e0efe59953393ad3 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:39:57 +0100 Subject: [PATCH 333/649] fix: update links in 0013-ACCT --- protocol/0013-ACCT-accounts.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index fb106ac90..8a127dc6c 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -16,7 +16,7 @@ Note that a party can also associate the governance / staking asset via the [Veg 1. Mark-to-market settlement account per market: this is used for collecting and distributing mark-to-market settlement cashflows and is *zero* at the end of each mark-to-market settlement run. 1. Margin accounts for each party with open orders or positions on any [market](./0043-MKTL-market_lifecycle.md). -1. Bond account for any party that's an [LP on any market](0038-OLIQ-liquidity_provision_order_type.md). +1. Bond account for any party that's an [LP on any market](0044-LIME-lp_mechanics_type.md). 1. [Insurance pool account](0015-INSR-market_insurance_pool_collateral.md) for any market. 1. [Liquidity fee pool](0042-LIQF-setting_fees_and_rewarding_lps.md) for any market. 1. [Infrastructure fee pool](0029-FEES-fees.md) for any asset. @@ -73,7 +73,7 @@ If there is a positive balance in an account that is being deleted, that balance ## Bond accounts -Bond accounts are opened when a party opens a [Liquidity Provision order](./0038-OLIQ-liquidity_provision_order_type.md). The bond is held by the network to ensure that the Liquidity Provider meets their SLA obligations. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. +Bond accounts are opened when a party opens a [Liquidity Provision order](./0044-LIME-lp_mechanics.mdd). The bond is held by the network to ensure that the Liquidity Provider meets their SLA obligations. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. ## Insurance pools @@ -123,7 +123,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### Liquidity Provider bond accounts - A bond account holds collateral to maintain collateral for [Liquidity Providers](./0044-LIME-lp_mechanics.md). (0013-ACCT-023) -- Each party that has placed a [Liquidity Provision order](./0038-OLIQ-liquidity_provision_order_type.md) will have one bond account per market they have provided liquidity to (0013-ACCT-018) +- Each party that has placed a [Liquidity Provision order](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) will have one bond account per market they have provided liquidity to (0013-ACCT-018) - [Fees earned from liquidity provision](./0044-LIME-lp_mechanics.md#fees) are *not* paid in to this bond account - [they are paid in to the *margin* account for this trader](./0042-LIQF-setting_fees_and_rewarding_lps.md#distributing-fees) (0013-ACCT-019) ### Insurance pool accounts From 70c3444f18d721245d4a05db4b7fd314d6a3e795 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:40:47 +0100 Subject: [PATCH 334/649] fix: update links in 0017-PART --- protocol/0017-PART-party.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0017-PART-party.md b/protocol/0017-PART-party.md index d8a1f800f..cc63d3315 100644 --- a/protocol/0017-PART-party.md +++ b/protocol/0017-PART-party.md @@ -18,7 +18,7 @@ A standard party can: - [Cancel an order](./0033-OCAN-cancel_orders.md) - [Submit a governance proposal](./0028-GOVE-governance.md) - [Vote on a governance proposal](./0028-GOVE-governance.md) -- [Commit to provide liquidity on a market](./0038-OLIQ-liquidity_provision_order_type.md) +- [Commit to provide liquidity on a market](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) ## Guide-level explanation From 775d09518960ff38999916603479ae79c087e6d0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:42:31 +0100 Subject: [PATCH 335/649] fix: update links in 0021-MDAT --- protocol/0021-MDAT-market_data_spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index 072c5a4c0..ddd2bb326 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -21,13 +21,13 @@ This data is a snapshot of the state of the market at a point in time. ## Guide-level explanation -Due to supporting dynamic orders such as [pegged orders](0037-OPEG-pegged_orders.md) and [LP provision orders](0038-OLIQ-liquidity_provision_order_type.md) the main market data fields are split up into two parts. Normal values and static values. Normal values for **Mid price**, **Best bid price** and **Best offer price** take into account all orders on the book (both normal and dynamic). Static values are calculated using only non-dynamic orders and so will not count any pegged orders in the calculation. +Due to supporting dynamic orders such as [pegged orders](0037-OPEG-pegged_orders.md), the main market data fields are split up into two parts. Normal values and static values. Normal values for **Mid price**, **Best bid price** and **Best offer price** take into account all orders on the book (both normal and dynamic). Static values are calculated using only non-dynamic orders and so will not count any pegged orders in the calculation. ## Reference-level explanation ### Definition of dynamic orders -A "dynamic" order is either a [pegged order](0037-OPEG-pegged_orders.md) or orders that are placed on the book by Vega as part of the [LP liquidity provision order](0038-OLIQ-liquidity_provision_order_type.md). +A "dynamic" order is a [pegged order](0037-OPEG-pegged_orders.md). ### Market data fields From 4809a68c1ec0ad4ce4de95a302afd6018d14ade2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:45:09 +0100 Subject: [PATCH 336/649] fix: update links in 0026-AUCT --- protocol/0026-AUCT-auctions.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index a5d441370..eeb38ed26 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -87,7 +87,7 @@ Good for normal trading (GFN) orders are rejected during an auction. ### Upon exiting auction mode -- [Pegged orders](./0037-OPEG-pegged_orders.md) (all kinds, including the ones placed by [Liquidity Provision](./0038-OLIQ-liquidity_provision_order_type.md)) get reinstated in the order book they were originally submitted in. +- [Pegged orders](./0037-OPEG-pegged_orders.md) get reinstated in the order book they were originally submitted in. - Limit orders stay on the book (unless they have a `TIF:GFA` only good for auction, in this case they are removed from the book and have their status set to cancelled). ## Exiting the auction mode @@ -168,12 +168,12 @@ message Market { - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md). (0026-AUCT-017) for product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) - 2. past the enactment time if there is no [liquidity supplied](./0038-OLIQ-liquidity_provision_order_type.md). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) - 3. past the enactment time if [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017) for product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) + 2. past the enactment time if there is no [liquidity supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) + 3. past the enactment time if [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) - or if orders are cancelled such that the uncrossing volume will create open interest sufficiently small so that the original stake can support it. (0026-AUCT-020) - 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0038-OLIQ-liquidity_provision_order_type.md) but after the auction uncrossing we will not have + 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but after the auction uncrossing we will not have - best bid; it will still open. (0026-AUCT-021) - or best ask; it will still open. (0026-AUCT-022) - When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015) for product spot: (0026-AUCT-031) From ef22adf4a745d66d03668749d1c8c18092d2e4d8 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:46:02 +0100 Subject: [PATCH 337/649] fix: update links in 0028-GOVE --- protocol/0028-GOVE-governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 3761793b2..7e5a14695 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -230,7 +230,7 @@ See [sucessor markets spec](./0081-SUCM-successor_markets.md for more details). All _new market proposals_ initially have their validation configured by the network parameters `Governance.CreateMarket.All.*`. These may be split from `All` to subtypes in future, for instance when other market types like RFQ are created. -A market in Proposed state accepts [liquidity commitments](./0038-OLIQ-liquidity_provision_order_type.md) from any party. The LP commitments can be added / amended / removed. +A market in Proposed state accepts [liquidity commitments](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) from any party. The LP commitments can be added / amended / removed. ## 2. Change market parameters @@ -495,7 +495,7 @@ APIs should also exist for clients to: - As the vega network, if a proposal is accepted and the duration required before change takes effect is reached, the changes are applied (0028-GOVE-008) - New market proposals cannot be created before [`limits.markets.proposeEnabledFrom`](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#network-parameters) is in the past (0028-GOVE-024) -- A market that has been proposed and successfully voted through doesn't leave the opening auction until the `enactment date/time` is reached and until sufficient [liquidity commitment](./0038-OLIQ-liquidity_provision_order_type.md) has been made for the market. Sufficient means that it meets all the criteria set in [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md). (0028-GOVE-025) +- A market that has been proposed and successfully voted through doesn't leave the opening auction until the `enactment date/time` is reached and until sufficient [liquidity commitment](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) has been made for the market. Sufficient means that it meets all the criteria set in [liquidity monitoring](./0035-LIQM-liquidity_monitoring.md). (0028-GOVE-025) - A market proposal with a negative or non-integer value supplied for market decimal places gets rejected. (0028-GOVE-061) - A market proposal with position decimal places not in `{-6,...,-1,0,1,2,...,6}` gets rejected. (0028-GOVE-062) From d340280c76e2a6ed4abaa6b5d5772c83537cc8ce Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:46:57 +0100 Subject: [PATCH 338/649] fix: update links in 0042-LIQF --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 407083bab..83ce63322 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -18,7 +18,7 @@ The [liquidity fee factor](./0029-FEES-fees.md) is an input to the total taker f `liquidity_fee = fee_factor[liquidity] x trade_value_for_fee_purposes` -As part of the [commit liquidity network transaction](./0038-OLIQ-liquidity_provision_order_type.md), the liquidity provider submits their desired level for the [liquidity fee factor](./0042-LIQF-setting_fees_and_rewarding_lps.md) for the market. Here we describe how this fee factor is set from the values submitted by all liquidity providers for a given market. +As part of the [commit liquidity network transaction](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction), the liquidity provider submits their desired level for the [liquidity fee factor](./0042-LIQF-setting_fees_and_rewarding_lps.md) for the market. Here we describe how this fee factor is set from the values submitted by all liquidity providers for a given market. First, we produce a list of pairs which capture committed liquidity of each LP together with their desired liquidity fee factor and arrange this list in an increasing order by fee amount. Thus we have ```text From 92e319ec886f74e24c1c2d68faca79b9dca49415 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:56:16 +0100 Subject: [PATCH 339/649] fix: update links in 0043-MKTL --- protocol/0043-MKTL-market_lifecycle.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 788dbf431..d8918aa72 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -12,7 +12,7 @@ Markets on Vega are proposed, permissionless, using the [governance mechanism](. Markets proposed via [governance proposals](./0028-GOVE-governance.md#1-create-market) undergo certain additional validations. Note the distinctions between a proposal that is `valid` or `accepted` and a proposal that is `sucessful`. A `valid` proposal has passed or will pass validation checks; an `accepted` proposal has been received in a Vega transaction and passed validation checks; and a `successful` proposal has been voted for and won. The proposal becomes `enacted` when the action specified (i.e. for the purposes of this spec, market creation/update/close). -All markets are proposed without any [liquidity commitment](./0038-OLIQ-liquidity_provision_order_type.md). +All markets are proposed without any [liquidity commitment](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). If the proposal is successful the market will go into opening auction at least until the proposed `enactment` date. However, the market may stay in an opening auction past the proposed `enactment` date until at least on party makes a liquidity commitment that meets criteria for exiting [liquidity auction](./0035-LIQM-liquidity_monitoring.md). @@ -32,7 +32,7 @@ A market can progress through a number of statuses through its life. The overall | Trading Terminated | No | No trading | Defined by the product (i.e. from a product parameter, specified in market definition, giving close date/time) | Settlement event commences | Settled | No | No trading | Settlement triggered and completed as defined by product | N/A -[1] Accepting LPs: it is possible to make or amend [Liquidity Provision Commitments](./0038-OLIQ-liquidity_provision_order_type.md) +[1] Accepting LPs: it is possible to make or amend [Liquidity Provision Commitments](./0044-LIME-lp_mechanics.md). ![Life cycle flow diagram](./0043-market-lifecycle-flow-diagram.svg) @@ -42,7 +42,7 @@ Note that there is no governance proposal to cancel a market. However it is poss ### Proposed -All Markets are first [proposed via the governance mechanism](./0028-GOVE-governance.md#1-create-market). Once the valid Market Proposal is accepted *the Market (see [market framework](./0001-MKTF-market_framework.md)) is created* and can accept [Liquidity Provision Commitments](./0038-OLIQ-liquidity_provision_order_type.md), voting begins and its state is `proposed`. +All Markets are first [proposed via the governance mechanism](./0028-GOVE-governance.md#1-create-market). Once the valid Market Proposal is accepted *the Market (see [market framework](./0001-MKTF-market_framework.md)) is created* and can accept [Liquidity Provision Commitments](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction), voting begins and its state is `proposed`. **Entry:** From b3c9c92d08ca75e34ac61ea52e29505c44515c5d Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:57:21 +0100 Subject: [PATCH 340/649] feat: remove outdated AC 0044-LIME-011 --- protocol/0044-LIME-lp_mechanics.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 6d511286b..2df48195a 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -295,7 +295,6 @@ Note: - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) - Check that bond slashing works with non-default asset decimals, market decimals, position decimals. This can be done by following a similar story to [bond slashing feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature). Should test at least three different combinations, each decimal settings different to each other. (0044-LIME-009) - Change of `market.liquidity.stakeToCcyVolume` will change the liquidity obligation hence change the size of the LP orders on the order book. (0044-LIME-010) -- If `market.liquidity.stakeToCcyVolume` is set to `0.0` then the [LP provision order](./0038-OLIQ-liquidity_provision_order_type.md) places `0` volume on the book for the LP regardless of the shape submitted and regardless of the `stake` committed. (0044-LIME-011) - If `market.liquidity.stakeToCcyVolume` is set to `0.0`, there is [target stake](./0041-TSTK-target_stake.md) of `1000` and there are 3 LPs on the market with stake / fee bid submissions of `100, 0.01`, `1000, 0.02` and `200, 0.03` then the liquidity fee is `0.02`. (0044-LIME-012) - If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.committmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) From dd350d41eecf34c387a4a13ffd5129812f078cea Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:58:38 +0100 Subject: [PATCH 341/649] fix: update links in 0052-FPOS --- protocol/0052-FPOS-fractional_orders_positions.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0052-FPOS-fractional_orders_positions.md b/protocol/0052-FPOS-fractional_orders_positions.md index 14eb674a4..f4e55bce7 100644 --- a/protocol/0052-FPOS-fractional_orders_positions.md +++ b/protocol/0052-FPOS-fractional_orders_positions.md @@ -16,7 +16,6 @@ Specs affected by this change (Note: in many cases the implementation may not ch - [0003 - Mark to mark settlement](./0003-MTMK-mark_to_market_settlement.md) - [0019 - Margin Caculator](./0019-MCAL-margin_calculator.md) - [0029 - Fees](./0029-FEES-fees.md) -- [0038 - Liquidity Provision order type](./0038-OLIQ-liquidity_provision_order_type.md) ## Acceptance Criteria From 785996e2b2f5d7d07d777e496b6c524406fb8303 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 09:59:56 +0100 Subject: [PATCH 342/649] fix: remove reference to removed AC 0038-OLIQ-006 --- protocol/0052-FPOS-fractional_orders_positions.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0052-FPOS-fractional_orders_positions.md b/protocol/0052-FPOS-fractional_orders_positions.md index f4e55bce7..057b7bc82 100644 --- a/protocol/0052-FPOS-fractional_orders_positions.md +++ b/protocol/0052-FPOS-fractional_orders_positions.md @@ -22,7 +22,6 @@ Specs affected by this change (Note: in many cases the implementation may not ch - All proposed markets will have a decimal places property available via the API (0052-FPOS-001) for product spot: (0052-FPOS-003) - An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002) for product spot: (0052-FPOS-004) - Fees are calculated as per ([0029-FEES-013](./0029-FEES-fees.md#0029-FEES-013)) -- LP order volume is implied correctly using fractional volume amounts as per ([0038-OLIQ-006](./0038-OLIQ-liquidity_provision_order_type.md#0038-OLIQ-006)) - Mark-to-market settlement happens correctly with PDP > 0 ([0003-MTMK-0015](./0003-MTMK-mark_to_market_settlement.md#0003-MTMK-015)) - Margins are correctly calculated for markets with PDP > 0 ([0019-MCAL-008](./0019-MCAL-margin_calculator.md#0019-MCAL-008)). - Market framework reports position decimal places ([0001-MKTF-001](./0001-MKTF-market_framework.md#0001-MTMF-001)). From 9b95c4e3af0333db3fe400aaec131eb2196018e2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 10:00:46 +0100 Subject: [PATCH 343/649] fix: update links in 0073-LIMN --- protocol/0073-LIMN-limited_network_life.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 0aafe9448..932715c36 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -30,7 +30,7 @@ Information to store: - All [network parameters](../protocol/0054-NETP-network_parameters.md), including those defined [below](#network-parameters). - All [asset definitions](../protocol/0040-ASSF-asset_framework.md#asset-definition). -Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_overview.md), [LP committed liquidity](../protocol/0038-OLIQ-liquidity_provision_order_type.md) and [LP fee pool](../protocol/0029-FEES-fees.md) balances for the markets that have been enacted will be stored with the accepted market proposal that must have preceded the market. +Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_overview.md), [LP committed liquidity](./0044-LIME-lp_mechanics.md) and [LP fee pool](../protocol/0029-FEES-fees.md) balances for the markets that have been enacted will be stored with the accepted market proposal that must have preceded the market. - All market proposals ([creation](../protocol/0028-GOVE-governance.md#1-create-market) and [update](../protocol/0028-GOVE-governance.md#2-change-market-parameters)) that have been *accepted* but not those where the market already started trading and reached *trading terminated* state. - All [asset proposals](../protocol/0028-GOVE-governance.md) that have been *accepted*. - All delegation info. From 7ca7b93ce66cef6277d45b453508f32ef911221b Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 10:03:01 +0100 Subject: [PATCH 344/649] fix: update links in README --- protocol/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/README.md b/protocol/README.md index 90d265af2..b3c86864e 100644 --- a/protocol/README.md +++ b/protocol/README.md @@ -50,7 +50,6 @@ - [Order submission](./0025-OCRE-order_submission.md) - [Pegged orders](./0037-OPEG-pegged_orders.md) - [Cancelling orders](./0033-OCAN-cancel_orders.md) -- [Liquidity provisions](./0038-OLIQ-liquidity_provision_order_type.md) ## Margin, collateral & risk From dbce57b36b01236371943e4fa59368f3ecccf712 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 5 Jul 2023 10:20:02 +0100 Subject: [PATCH 345/649] fix: update links in 0001-NP --- .../0001-NP-LIQB-liquidity_providing_bots.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md index 37efa641e..fa468e16b 100644 --- a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md +++ b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md @@ -14,14 +14,14 @@ This achieves the following: the price on the market looks "real" and there is v The downside is that if the bot is "unlucky" they can run out of even large amount of collateral and their orders / positions are liquidated. To avoid this they need regular collateral top-ups. -From Flamenco Tavern onwards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../protocol/0038-OLIQ-liquidity_provision_order_type.md). +From Flamenco Tavern onwards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transactiond). If a feature is marked as "optional" then the bot can be configured in such a way that it is not providing this functionality but still doing other tasks. The aim of this spec is bots that: 1. submit a market proposal (optional) or connects to an existing market -1. serve as a liquidity provider for the market by submitting the [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) (optional). +1. serve as a liquidity provider for the market by submitting the [LP order type](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) (optional). 1. participate in an opening auction (optional) 1. create markets that look real with more-or-less correct price by placing limit orders that "steer" the price up-or-down as appropriate (optional) 1. manage their position in such a way so as to not require ever growing amount of collateral. This will mean changing the "shape" in the liquidity provision order and also being strategic about placing limit orders to steer the price. The bot can have an optional position limit. @@ -53,7 +53,7 @@ The bot needs to be able to query Vega to know the risk model and parameters for This is only relevant if the option to submit a market proposal is enabled. -The bot will read the required market proposal from a file (configuration option), decide if it has minimum LP stake in the right asset, check it's got enough vote tokens and then submit the proposal and vote for it. They will also need to submit [liquidity shapes](../protocol/0038-OLIQ-liquidity_provision_order_type.md) but that will be treated below. +The bot will read the required market proposal from a file (configuration option), decide if it has minimum LP stake in the right asset, check it's got enough vote tokens and then submit the proposal and vote for it. To decide that it will ask Vega for `assetBalance`, `quantum` for asset and `min_LP_stake_quantum_multiple` and proceed if `assetBalance x stakeFraction > min_LP_stake_quantum_multiple x quantum` It will then check whether it has enough collateral for maintaining the commitment but that will be described below as it applies below too. @@ -212,8 +212,8 @@ Don't use any of the pseudocode above! ### Acceptance criteria -1. Bot can submit a market proposal (optional), commit liquidity and then manage it's position as described above, see also [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md). (0001-NP-LIQB-001) -1. Bot can connect to an existing market, submit an [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) and then manage it's position as described above. (0001-NP-LIQB-002) +1. Bot can submit a market proposal (optional), commit liquidity and then manage it's position as described above, see also [LP order type](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0001-NP-LIQB-001) +1. Bot can connect to an existing market, submit an [LP order type](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) and then manage it's position as described above. (0001-NP-LIQB-002) 1. Bot can participate in an opening auction placing orders around target price (set via parameters, see above).(0001-NP-LIQB-003) 1. Can read a price target from external source and and places limit orders that "steer" the price up-or-down as appropriate and have the right `targetLNVol` using one of the methods above (note that this has to take into account other identical bots trying to do the same on the same market).(0001-NP-LIQB-004) 1. Bot manages its position in such a way that it stays close to zero and starts placing market orders if configured maxima are breached.(0001-NP-LIQB-005) From 1b51f946f340e7a046f775a96cf93f696be788af Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 26 Jul 2023 12:47:49 +0200 Subject: [PATCH 346/649] fix: remove final 0038 links --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- protocol/0078-NWLI-network_wide_limits.md | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 83ce63322..e9961260c 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -188,7 +188,7 @@ Now calculate the total of the instantaneous liquidity scores obtained for each `total = the sum of instantaneous liquidity scores for all LPs that have an active liquidity commitment` Now, if the `total` comes out as `0` then set `fractional instantaneous liquidity score` to `1.0/n`, where `n` is the number of committed LPs. -Otherwise calculate fractional instantaneous liquidity score for each committed LP (i.e. a party that successfully submitted [LP order](./0038-OLIQ-liquidity_provision_order_type.md) as: +Otherwise calculate fractional instantaneous liquidity score for each committed LP. `fractional instantaneous liquidity score = instantaneous liquidity score / total` diff --git a/protocol/0078-NWLI-network_wide_limits.md b/protocol/0078-NWLI-network_wide_limits.md index d0b80f3aa..3529bac9d 100644 --- a/protocol/0078-NWLI-network_wide_limits.md +++ b/protocol/0078-NWLI-network_wide_limits.md @@ -13,8 +13,6 @@ Default value: `1,500`. If the network parameter gets increased via a governance vote no further actions are needed. If it gets decreased below the current total number of pegged orders across all active markets then no further actions are needed. Specifically: all pegged orders already present in the markets remain unaffected, but no new pegged orders are allowed until the **total pegged order count** drops below the new limit. -[Liquidity provision orders](./0038-OLIQ-liquidity_provision_order_type.md) do not get counted towards the limit. - ## Acceptance Criteria ### Pegged order tests From ec79148ee647a8032240b6181d640b1239782a49 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 26 Jul 2023 16:22:55 +0100 Subject: [PATCH 347/649] feat: update SLA penalty for spot --- protocol/0044-LIME-lp_mechanics.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 2df48195a..a3f6117ee 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -239,11 +239,12 @@ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, w For spot markets, the transfer is to go into the network treasury account for the asset. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). +In the case of spot markets the transfer goes into the network treasury account for the asset. + ### Penalty for not supporting open positions If at any point in time, a liquidity provider has insufficient capital to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions, the network will utilise their liquidity provision commitment, held in the _liquidity provider bond account_ to cover the shortfall. The protocol will also apply a penalty proportional to the size of the shortfall, which will be transferred to the market's insurance pool. -In the case of spot markets the transfer goes into the network treasury account for the asset. Calculating the penalty: From 7d4c280041e3b445d2de14057ca29437967fd193 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 27 Jul 2023 09:57:15 +0100 Subject: [PATCH 348/649] feat: Adding Batch Proposals (#1782) * feat: Adding spec for batch proposal submissions --------- Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: Jiajia-Cui --- protocol/0028-GOVE-governance.md | 21 ++++++++++++++++++++- protocol/features.json | 12 ++++++++++++ wordlist.txt | 1 + 3 files changed, 33 insertions(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 7e5a14695..e8777dd6d 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -442,6 +442,14 @@ Notes: - The categorisation of parameters is liable to change and be added to as the protocol evolves. - As these are themselves network parameters, a set of parameters will control these parameters for the actions that update these parameters (including being self-referential), i.e. the parameter `Governance.UpdateNetwork.GovernanceProposalValidation.MinimumRequiredParticipation` would control the amount of voting participation needed to change these parameters. See the Network Parameters spec. +## Batch Proposals + +A `BatchProposalSubmission` is a top-level proposal type (living at the same level in a `Transaction` object as a standard `ProposalSubmission` ) which allows grouping of several related changes into a single proposal, ensuring that all changes will pass or fail governance voting together. The batch proposal is a wrapper containing the same `reference` and `rationale` fields as a standard `ProposalSubmission` alongside a repeated list of `ProposalSubmission`s. + +Validation should be applied by the protocol when accepting such a transaction that all proposals within the batch are of the same category for the purposes of ensuring voting thresholds and minimum voting periods can be uniquely determined. Additionally, the closing time of each proposal's voting period must be identical to ensure that a single voting period can be run to determine the result of all. The enactment timestamp, however, should be customisable and can be different for each proposal within the batch. + +Once submitted, a single voting period should be run in which participants may place a single vote to approve/disapprove of the entire batch. It should not be possible to vote for components in the batch separately. If the batch fails to pass the vote, the entire batch should be discarded as with any other proposal. If the batch passes, each of the component proposals should be enacted at their enactment timestamp exactly as if each had been proposed and passed individually. The enactment order of two proposals in the batch with the same enactment timestamp does not need to be defined and should be considered indeterminate from a user's point-of-view. + ## APIs The core should expose via core APIs: @@ -644,13 +652,24 @@ It is NOT possible to submit a governance proposal where the source account is t ##### Cancelling governance initiated transfers -- Only recurring governance initiated transfers can be cancelled by proposing a governance initiated transfer cancellation. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) +- Only recurring governance transfers can be cancelled via governance cancel transfer proposal. Trying to cancel any other transfer should fail upon validation of the proposal.(0028-GOVE-107) - After a transfer is cancelled there will be no more transfers occurring in the block/seq following the cancellation. This applies to one off and recurring transfers. (0028-GOVE-123) - Recurring transfers can be cancelled only after the transfer proposal reached an enacted state. Attempts to cancel before the recurring transfer proposal has enacted will result in a proposal rejection which states the transfer does not exist (0028-GOVE-124) - Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) - When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126) +##### Batch Proposals + +- A batch proposal containing one or more component submissions for each type of proposal term can be submitted and is accepted as a valid proposal. (0028-GOVE-146) + +- A batch proposal containing component submissions with different categories will be rejected with an informative error message. (0028-GOVE-147) + +- A batch proposal submitted with component submissions having the same category but different closing timestamps will be rejected with an informative error message. (0028-GOVE-148) + +- A batch proposal submitted with component submissions having the same category and the same closing timestamps but different enactment timestamps will be accepted and move to voting. (0028-GOVE-149) + 1. If this proposal is accepted, each of the components will be enacted at the time of their differing enactment timestamps. (0028-GOVE-145) + ##### Network History - A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127) diff --git a/protocol/features.json b/protocol/features.json index 8d53a71da..58a5073da 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -670,6 +670,18 @@ "0026-AUCT-022" ] }, + + "Batch Change Proposals": { + "milestone": "deployment-2", + "acs": [ + "0028-GOVE-145", + "0028-GOVE-146", + "0028-GOVE-147", + "0028-GOVE-148", + "0028-GOVE-149" + ] + }, + "Unknown": { "milestone": "unknown", "acs": [] diff --git a/wordlist.txt b/wordlist.txt index e5346737c..d4db52e34 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -50,6 +50,7 @@ cryptocurrencies cryptographic CQRS cumulated +customisable customised DAI datanode From 00dd9572a5cc935b978f556759e8ae6c8ed6aa1a Mon Sep 17 00:00:00 2001 From: Matthew Pendrey Date: Thu, 27 Jul 2023 15:47:58 +0100 Subject: [PATCH 349/649] add confirmation height to spec --- protocol/0082-ETHD-ethereum-data-source.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 35168f8a8..3a9b217f3 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -169,6 +169,7 @@ Select { 2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-035) 3. Create a market to use an external data source to terminate a market and a manual oracle to settle the market (0082-ETHD-036) 4. Data sourcing should be completely decoupled from data filtering (0082-ETHD-037) +4. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-046) ### Checkpoints From 48119b12e2e74498c6ac0ddc96199429f9dbf301 Mon Sep 17 00:00:00 2001 From: Matthew Pendrey Date: Thu, 27 Jul 2023 15:48:52 +0100 Subject: [PATCH 350/649] add confirmation height to spec --- protocol/0082-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 3a9b217f3..4a6e0e067 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -169,7 +169,7 @@ Select { 2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-035) 3. Create a market to use an external data source to terminate a market and a manual oracle to settle the market (0082-ETHD-036) 4. Data sourcing should be completely decoupled from data filtering (0082-ETHD-037) -4. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-046) +5. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-046) ### Checkpoints From 84ed7ee5850672a186ec797af5fc42cd4e952057 Mon Sep 17 00:00:00 2001 From: Tom Date: Thu, 27 Jul 2023 15:59:48 +0100 Subject: [PATCH 351/649] chore: Fixing AC to use correct values for non-averaging state in performance hysteresis (#1861) --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index e9961260c..0c7fff77e 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -375,12 +375,12 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0`. (0042-LIQF-041) - If an LP has an active liquidity provision at the start of an epoch, `market.liquidity.slaCompetitionFactor = 0.5`, `market.liquidity.commitmentMinTimeFraction = 0.5` and throughout the epoch meets their liquidity provision requirements such that the `fraction_of_time_on_book = 0.75` then their penalty from that epoch will be `0.25`. (0042-LIQF-042) -- When `market.liquidity.performanceHysteresisEpochs = 0`: +- When `market.liquidity.performanceHysteresisEpochs = 1`: - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) -- When `market.liquidity.performanceHysteresisEpochs = n`: +- When `market.liquidity.performanceHysteresisEpochs > 1`: - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-047) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) From b7997f959f6c0dcd2bba7613edaa993f5bd8952d Mon Sep 17 00:00:00 2001 From: Matthew Pendrey Date: Fri, 28 Jul 2023 14:29:27 +0100 Subject: [PATCH 352/649] update eth oracle error handling AC --- protocol/0082-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 4a6e0e067..3fe697269 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -156,7 +156,7 @@ Select { ### Non Functional -1. System needs to emit an error via the TX RESULT event if the data source does NOT return data in a timely fashion - e.g. the read method of the smart contract take too long to return data OR times out (0082-ETHD-027) +1. Network wide contract error should be reported via oracle data events (0082-ETHD-027) 2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-ETHD-028) 3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-ETHD-029) 4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0082-ETHD-030) From fab2aa91ee063ed0688f250ccc47642ac2374cb5 Mon Sep 17 00:00:00 2001 From: Matthew Pendrey Date: Fri, 28 Jul 2023 14:44:58 +0100 Subject: [PATCH 353/649] update eth oracle error handling AC --- protocol/0082-ETHD-ethereum-data-source.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 3fe697269..0b3a21e44 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -160,15 +160,13 @@ Select { 2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-ETHD-028) 3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-ETHD-029) 4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0082-ETHD-030) -5. SPAM rules if any defined should be tested for (0082-ETHD-031) -6. NOT all data sourced should be stored on chain - invalid / incorrect data is filtered out and is NOT processed / stored on chain - understand what the rules are and design the AC's / test accordingly (0082-ETHD-032) ### Usage 1. It should be possible to use only ethereum oracle data sources in a market proposal, or create any combination with any of the other types of currently existing external or internal data sources (0082-ETHD-034) 2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-035) 3. Create a market to use an external data source to terminate a market and a manual oracle to settle the market (0082-ETHD-036) -4. Data sourcing should be completely decoupled from data filtering (0082-ETHD-037) +4. Chain events should only be sent when the filter is matched (0082-ETHD-037) 5. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-046) ### Checkpoints From 6835f5a51c299f134a762b5d385bd2571db4ce32 Mon Sep 17 00:00:00 2001 From: Elias Van Ootegem Date: Fri, 28 Jul 2023 15:41:05 +0100 Subject: [PATCH 354/649] Pending is a valid state (opening auction) as per AC 009 Signed-off-by: Elias Van Ootegem --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 990dcc4c8..b2d1342c4 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -81,7 +81,7 @@ Successor markets which are proposed whilst the parent is also still in a "propo Successor markets can be enacted when the parent market is in opening auction. There is no virtual stake to copy over, and no insurance pool balance to transfer. (0081-SUCM-009) -A successor market proposal can be enacted when the parent market is in one of the following states: Suspended, Active, Trading terminated or Settled (settled within the successor time window) (0081-SUCM-010) +A successor market proposal can be enacted when the parent market is in one of the following states: Pending, Suspended, Active, Trading terminated or Settled (settled within the successor time window) (0081-SUCM-010) When a successor market is enacted (i.e. leaves the opening auction), all other related successor market proposals, in the state "pending" or "proposed", are automatically rejected. Any LP submissions associated with these proposals are cancelled, and the funds are released (0081-SUCM-011) From c075d34fdcd3a3c7d344483e75643f64070c53de Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 28 Jul 2023 16:13:06 +0100 Subject: [PATCH 355/649] fix: new LPs committing liquidity / existing LPs increasing --- protocol/0044-LIME-lp_mechanics.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index a3f6117ee..36ee1e0c0 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -76,7 +76,9 @@ There is an minimum LP stake which is `market.liquidityProvision.minLpStakeQuant If the participant has sufficient collateral to cover their commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are committing liquidity, created as needed). For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). -Entering commitment will happen(*) at the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated). It's the prospective LP's responsibility to have sufficient balance in their general account at the epoch boundary; if not the LP commitment is cancelled. +A new or increased commitment will get activated in two stages.(*) First the commitment amount (increase) will get transferred from general to bond account. +Their obligation for providing liquidity under SLA is the one from the beginning of current epoch (so in particular for a new LP it's `0`). +At the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated) the commitmed amount is noted and the LP is expected to provide sufficient liquidity for the epoch. (*) The expectation is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. From 3b524db9d1a463d284483de491c648696d9553ef Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 28 Jul 2023 16:49:04 +0100 Subject: [PATCH 356/649] chore: update features.json (#1863) * chore: update features.json * fix: order the deployments correctly --- protocol/features.json | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 58a5073da..a2e35338f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -590,7 +590,8 @@ "0082-ETHD-042", "0082-ETHD-043", "0082-ETHD-044", - "0082-ETHD-045" + "0082-ETHD-045", + "0082-ETHD-046" ] }, "SLA": { @@ -670,7 +671,6 @@ "0026-AUCT-022" ] }, - "Batch Change Proposals": { "milestone": "deployment-2", "acs": [ @@ -681,7 +681,31 @@ "0028-GOVE-149" ] }, - + "Referral program": { + "milestone": "deployment-2", + "acs": [ + "0083-RFPR-000", + "0084-VDPR-000" + ] + }, + "Market governance": { + "milestone": "deployment-2", + "acs": [ + "0028-GOVE-064", + "0028-GOVE-069", + "0028-GOVE-070", + "0028-GOVE-072", + "0028-GOVE-110", + "0028-GOVE-113", + "0028-GOVE-118", + "0028-GOVE-135", + "0028-GOVE-136", + "0028-GOVE-137", + "0028-GOVE-138", + "0028-GOVE-139", + "0028-GOVE-111" + ] + }, "Unknown": { "milestone": "unknown", "acs": [] From 35e593c0a6023e13ace0b2a98b6e7e5010856ca3 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 28 Jul 2023 16:51:53 +0100 Subject: [PATCH 357/649] fix: new LPs committing liquidity / existing LPs increasing --- protocol/0044-LIME-lp_mechanics.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 36ee1e0c0..488a23ea0 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -76,9 +76,9 @@ There is an minimum LP stake which is `market.liquidityProvision.minLpStakeQuant If the participant has sufficient collateral to cover their commitment, the commitment amount (stake) is transferred from the participant's general account to their (maybe newly created) [liquidity provision bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts) (new account type, 1 per liquidity provider per market and asset where they are committing liquidity, created as needed). For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). -A new or increased commitment will get activated in two stages.(*) First the commitment amount (increase) will get transferred from general to bond account. -Their obligation for providing liquidity under SLA is the one from the beginning of current epoch (so in particular for a new LP it's `0`). -At the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated) the commitmed amount is noted and the LP is expected to provide sufficient liquidity for the epoch. +A new or increased commitment will get activated in two stages.(*) First the commitment amount (increase) will get transferred from general to bond account. +Their obligation for providing liquidity under SLA is the one from the beginning of current epoch (so in particular for a new LP it's `0`). +At the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated) the commitment amount is noted and the LP is expected to provide sufficient liquidity for the epoch. (*) The expectation is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. From 19e0e58c48c1ece60b9c5db64ddb8f823453bc5d Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Fri, 28 Jul 2023 16:55:57 +0100 Subject: [PATCH 358/649] =?UTF-8?q?Markets=20in=20suspension=20can=20be=20?= =?UTF-8?q?resumed=20or=20terminated=20after=20a=20protocol=20u=E2=80=A6?= =?UTF-8?q?=20(#1855)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Markets in suspension can be resumed or terminated after a protocol upgrade restarts the network * Update 0028-GOVE-governance.md * fix: update AC code numbers * chore: add to features.json --------- Co-authored-by: gordsport --- protocol/0028-GOVE-governance.md | 6 ++++-- protocol/features.json | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index e8777dd6d..1811ef2a3 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -539,6 +539,8 @@ APIs should also exist for clients to: - Enacting a market closure governance proposal on a market that is not in a settled state always uses the price supplied with the proposal for final settlement, even when the oracle settlement price is available at that time. (0028-GOVE-138) - Successful enactment of a market closure proposal changes the state of the market to `closed`. (0028-GOVE-139) - Attempt to enact a market closure proposal on a closed market has no effect. (0028-GOVE-111) +- Markets which have been suspended via a governance proposal can be resumed after a protocol upgrade restarts the network. (0028-GOVE-150) +- Markets which have been suspended via a governance proposal can be terminated after a protocol upgrade restarts the network. (0028-GOVE-151) #### Network parameter change proposals @@ -664,9 +666,9 @@ It is NOT possible to submit a governance proposal where the source account is t - A batch proposal containing one or more component submissions for each type of proposal term can be submitted and is accepted as a valid proposal. (0028-GOVE-146) - A batch proposal containing component submissions with different categories will be rejected with an informative error message. (0028-GOVE-147) - + - A batch proposal submitted with component submissions having the same category but different closing timestamps will be rejected with an informative error message. (0028-GOVE-148) - + - A batch proposal submitted with component submissions having the same category and the same closing timestamps but different enactment timestamps will be accepted and move to voting. (0028-GOVE-149) 1. If this proposal is accepted, each of the components will be enacted at the time of their differing enactment timestamps. (0028-GOVE-145) diff --git a/protocol/features.json b/protocol/features.json index a2e35338f..f430ff799 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -671,7 +671,7 @@ "0026-AUCT-022" ] }, - "Batch Change Proposals": { + "Batch change proposals": { "milestone": "deployment-2", "acs": [ "0028-GOVE-145", @@ -703,7 +703,9 @@ "0028-GOVE-137", "0028-GOVE-138", "0028-GOVE-139", - "0028-GOVE-111" + "0028-GOVE-111", + "0028-GOVE-150", + "0028-GOVE-151" ] }, "Unknown": { From 92fade27f62de1e97205e01655ab6a20f2712d80 Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Fri, 28 Jul 2023 18:15:25 +0100 Subject: [PATCH 359/649] feat: Adding additional feature tests for perpetuals --- protocol/0002-STTL-settlement.md | 10 +++--- protocol/0043-MKTL-market_lifecycle.md | 34 +++++++++++++++++++++ protocol/0051-PROD-product.md | 6 ++-- protocol/0070-MKTD-market-decimal-places.md | 1 + protocol/0073-LIMN-limited_network_life.md | 34 +++++++++++++++++++-- protocol/features.json | 18 ++++++++++- 6 files changed, 92 insertions(+), 11 deletions(-) diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index 163c936a8..7e6a107d0 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -64,11 +64,11 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on ## Acceptance Criteria -### The typical "Happy Path" case (0002-STTL-001) +### The typical "Happy Path" case (Expiring Future: 0002-STTL-001, Perpetual Future: 0002-STTL-011) - With a market configured to take an oracle termination time and settlement price and put into continuous trading mode. When there are traders with open positions on the market and the termination trigger from oracle is sent so the market is terminated. Send market settlement price and assert that it is no longer possible to trade on this market. -### Example 1 - A typical path of a cash settled futures market nearing expiry when market is trading in continuous session (0002-STTL-002) +### Example 1 - A typical path of a cash settled futures market nearing expiry when market is trading in continuous session (Expiring Future: 0002-STTL-002, Perpetual Future: 0002-STTL-012) 1. Market has a status of ACTIVE and is trading in default trading mode 1. The product's [trading terminated trigger is hit](./0016-PFUT-product_builtin_future.md#41-termination-of-trading) @@ -82,9 +82,9 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. -1. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (0002-STTL-003) +2. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (Expiring Future: 0002-STTL-003, Perpetual Future: 0002-STTL-013) -### Example 2 - A less typical path of such a futures market nearing expiry when market is suspended (0002-STTL-004) +### Example 2 - A less typical path of such a futures market nearing expiry when market is suspended (Expiring Future: 0002-STTL-004, Perpetual Future: 0002-STTL-014) 1. Market has a status of SUSPENDED and in a protective auction 1. The product's [trading terminated trigger is hit](./0016-PFUT-product_builtin_future.md#41-termination-of-trading) @@ -107,7 +107,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. If margin and general account of trader are insufficient to cover collateral transfers, then collateral is attempted to be taken from market's insurance pool. (0002-STTL-008) 1. If the full required amount for collateral cannot be collected from individual or combination of these accounts, then as much as possible in the above sequence of accounts is collected and loss socialisation occurs. (0002-STTL-009) -### Example 3 - Settlement data to cash settled future is submitted before trading is terminated (0002-STTL-010) +### Example 3 - Settlement data to cash settled future is submitted before trading is terminated (0002-STTL-010)(Expiring Future: 0002-STTL-010, Perpetual Future: 0002-STTL-015) 1. A [cash settled futures](0016-PFUT-product_builtin_future.md) market has a status of ACTIVE and is trading in default trading mode (continuous trading) 1. An [oracle event occurs](./0045-DSRC-data_sourcing.md) that is eligible to settle the market, as defined on the [Product](./0001-MKTF-market_framework.md) (see also [cash settled futures spec](./0016-PFUT-product_builtin_future.md)). In other words the settlement price is submitted to the market before trading is terminated. diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index d8918aa72..413bc0d6c 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -301,6 +301,40 @@ Market state is `suspended`. The market state is `active`. 1. When a new governance proposal for "closing" the Spot market, then market state is `trading terminated`. +### Lifecycle happy path in Perpetual market(0043-MKTL-009) + +1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). +Market state is `proposed`. +The LP bond of the party that proposed the market is transferred from general to bond account. +1. Market `m1` is accepted and enters opening auction. +Market state is `pending`. +1. Parties place orders and at least one trade happens in continuous trading mode. +Market state is `active`. +1. Parties place orders so that a [price monitoring auction is triggered](0032-PRIM-price_monitoring.md). +Market state is `suspended`. +1. Price monitoring auction ends and the market is in continuous trading again. +The market state is `active`. +1. Parties cancel orders so that there is no "best static bid" on the order book. +The market enters [liquidity monitoring auction](0035-LIQM-liquidity_monitoring.md). +The market state is `suspended`. +1. A party place bid; this becomes a best static bid. +After the specified time the liquidity auction ends. +The market state is `active`. +1. Make sure that trades happen so that at least two parties have open positions. + +1. An oracle event arrives which triggers the perpetual market's interim settlement logic, causing cashflow transfers but the market remains open. +1. Further trades happen, with parties still having different positions to previously. The mark price is `p`. +1. The time specified at market proposal by the internal time oracle is reached. +Any orders that parties submit get rejected. +The parties with open position in the immediately preceding step still have open positions. +Parties with open positions still have non-zero margin account balances. +The market state is `trading terminated`. +1. The settlement price oracle transaction is sent and it is *not* equal to `p`. +Parties that had open positions see settlement cash-flows happen. +Margin account balances are transferred to the general account. +The market state is `settled`. +After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. + ### Market never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-003) 1. A market is proposed, approved by governance process and enters the opening auction (Pending state). diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index da1cd540a..0acdbcd24 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -119,12 +119,12 @@ APIS should be available to: Settlement assets: -- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001) for product spot: (0051-PROD-004) -- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002) for product spot: (0051-PROD-005) +- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001) for product spot: (0051-PROD-004) for product perpetual: (0051-PROD-007) +- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002) for product spot: (0051-PROD-005) for product perpetual: (0051-PROD-008) Product updates via governance: -- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003) for product spot: (0051-PROD-006) +- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003) for product spot: (0051-PROD-006) for product perpetual: (0051-PROD-009) ## See also diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 8d227dbc1..1fe54983f 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -78,3 +78,4 @@ Trades of course result in transfers. The amounts transferred (for the trade as - Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006) for product spot: (0070-MKTD-013) - As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007) for product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008) for product spot: ( 0070-MKTD-015) +- Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-016) \ No newline at end of file diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 932715c36..f989c30c8 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -160,7 +160,7 @@ for product spot: (0073-LIMN-1010073-LIMN-102) +#### Test case 3.1.1: Spot market is proposed, accepted, restored (0073-LIMN-102) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -178,9 +178,28 @@ for product spot: (0073-LIMN-1010073-LIMN-105) + +1. There is an asset USD and no asset proposals. +1. There are no markets and no market proposals. +1. There is a party a party called `LP party` with general balance of 10 000 USD. +1. A market is proposed by a party called `LP party` and has enactment date 1 year in the future. The market has id `id_xxx`. +1. `LP party` commits a stake of 1000 USD to `id_xxx`. +1. Other parties vote on the market and the proposal is accepted (passes rules for vote majority and participation). The market has id `id_xxx`. +1. The market is in `pending` state, see [market lifecycle](../protocol/0043-MKTL-market_lifecycle.md). +1. Another party places a limit sell order on the market and has `other_gen_bal`, holding balance `other_hold_bal`. +1. Enough time passes so a checkpoint is created and no party submitted any withdrawal transactions throughout. +1. The network is shut down. +1. The network is restarted with the checkpoint hash from the above checkpoint in genesis. The checkpoint restore transaction is submitted and processed. +1. There is an asset USD. +1. There is a market with `id_xxx` with all the same parameters as the accepted proposal had. +1. The LP party has general account balance in USD of `9000` and bond account balance `1000` on the market `id_xxx`. +1. The other party has no open orders anywhere and general account balance in USD of `other_gen_bal + other_hold_bal`. +2. #### Test case 3.2: Market is proposed, voting hasn't closed, not restored (0073-LIMN-010) for product spot: (0073-LIMN-103) +for product perpetuals: (0073-LIMN-106) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -198,6 +217,8 @@ for product spot: (0073-LIMN-1030073-LIMN-104) +for product perpetuals:(0073-LIMN-107) + 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. 1. There is a party a party called `LP party` with general balance of `10 000` USD. @@ -215,6 +236,8 @@ for product spot:(0073-LIMN-1040073-LIMN-077) +for product perpetuals:(0073-LIMN-108) + 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. 1. There is a party a party called `LP party` with general balance of 10 000 USD. @@ -230,6 +253,10 @@ for product spot: (0073-LIMN-0770073-LIMN-078) + +for product perpetuals:(0073-LIMN-109) + + 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. 1. There is a party a party called `LP party` with general balance of 10 000 USD. @@ -245,6 +272,9 @@ for product spot: (0073-LIMN-0780073-LIMN-079) +for product perpetuals:(0073-LIMN-110) + + 1. A party has general account balance of 100 USD. 1. The party submits a withdrawal transaction for 100 USD. A checkpoint is immediately created. 1. The network is shut down. @@ -255,7 +285,7 @@ for product spot: (0073-LIMN-0790073-LIMN-016) +### Test case 4a: Party's Margin Account balance is put in to a General Account balance for that asset after a reset (0073-LIMN-016) (for perpetuals: 0073-LIMN-111) 1. A party has USD general account balance of 100 USD. 2. That party has USD margin account balance of 100 USD. diff --git a/protocol/features.json b/protocol/features.json index 58a5073da..cd8cd39e5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -188,7 +188,23 @@ "0053-PERP-009", "0053-PERP-015", "0053-PERP-016", - "0053-PERP-017" + "0053-PERP-017", + "0002-STTL-011", + "0002-STTL-012", + "0002-STTL-013", + "0002-STTL-014", + "0002-STTL-015", + "0043-MKTL-009", + "0051-PROD-007", + "0051-PROD-008", + "0051-PROD-009", + "0073-LIMN-105", + "0073-LIMN-106", + "0073-LIMN-107", + "0073-LIMN-108", + "0073-LIMN-109", + "0073-LIMN-110", + "0073-LIMN-111" ] }, "Spot": { From 84e62fd4e8c3c2e175bff38e3910eddeef20d683 Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Fri, 28 Jul 2023 18:42:39 +0100 Subject: [PATCH 360/649] feat: Fix up linting --- protocol/0002-STTL-settlement.md | 2 +- protocol/0070-MKTD-market-decimal-places.md | 2 +- protocol/0073-LIMN-limited_network_life.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index 7e6a107d0..64020110c 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -82,7 +82,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. -2. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (Expiring Future: 0002-STTL-003, Perpetual Future: 0002-STTL-013) +1. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (Expiring Future: 0002-STTL-003, Perpetual Future: 0002-STTL-013) ### Example 2 - A less typical path of such a futures market nearing expiry when market is suspended (Expiring Future: 0002-STTL-004, Perpetual Future: 0002-STTL-014) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 1fe54983f..aaca532df 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -78,4 +78,4 @@ Trades of course result in transfers. The amounts transferred (for the trade as - Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006) for product spot: (0070-MKTD-013) - As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007) for product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008) for product spot: ( 0070-MKTD-015) -- Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-016) \ No newline at end of file +- Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-016) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index f989c30c8..d9d99e94f 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -195,7 +195,7 @@ for product spot: (0073-LIMN-1010073-LIMN-010) for product spot: (0073-LIMN-103) From b47ce37d8ad7ff1784da4e34745799ab1ca218ca Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Fri, 28 Jul 2023 18:47:40 +0100 Subject: [PATCH 361/649] feat: Fix up linting --- protocol/0002-STTL-settlement.md | 2 +- protocol/0070-MKTD-market-decimal-places.md | 5 ++++- protocol/features.json | 3 +++ 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index 64020110c..76b9633af 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -107,7 +107,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. If margin and general account of trader are insufficient to cover collateral transfers, then collateral is attempted to be taken from market's insurance pool. (0002-STTL-008) 1. If the full required amount for collateral cannot be collected from individual or combination of these accounts, then as much as possible in the above sequence of accounts is collected and loss socialisation occurs. (0002-STTL-009) -### Example 3 - Settlement data to cash settled future is submitted before trading is terminated (0002-STTL-010)(Expiring Future: 0002-STTL-010, Perpetual Future: 0002-STTL-015) +### Example 3 - Settlement data to cash settled future is submitted before trading is terminated (0002-STTL-010)(Perpetual Future: 0002-STTL-015) 1. A [cash settled futures](0016-PFUT-product_builtin_future.md) market has a status of ACTIVE and is trading in default trading mode (continuous trading) 1. An [oracle event occurs](./0045-DSRC-data_sourcing.md) that is eligible to settle the market, as defined on the [Product](./0001-MKTF-market_framework.md) (see also [cash settled futures spec](./0016-PFUT-product_builtin_future.md)). In other words the settlement price is submitted to the market before trading is terminated. diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index aaca532df..1a093b928 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -72,10 +72,13 @@ Trades of course result in transfers. The amounts transferred (for the trade as - As a user, I can propose a market with a different precision than its settlement asset - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001) for product spot: (0070-MKTD-016) - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002) for product spot: (0070-MKTD-009) +- As a user, I can propose a perpetual market with a different periodic settlement precision than its settlement asset + - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-018) + - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-019) - As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003) for product spot: (0070-MKTD-010) - As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004) for product spot: (0070-MKTD-011) - As a user I should see the market data prices using market precision. (0070-MKTD-005) for product spot: (0070-MKTD-012) - Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006) for product spot: (0070-MKTD-013) - As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007) for product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008) for product spot: ( 0070-MKTD-015) -- Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-016) +- Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) diff --git a/protocol/features.json b/protocol/features.json index cd8cd39e5..97b8afae6 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -198,6 +198,9 @@ "0051-PROD-007", "0051-PROD-008", "0051-PROD-009", + "0070-MKTD-017", + "0070-MKTD-018", + "0070-MKTD-019", "0073-LIMN-105", "0073-LIMN-106", "0073-LIMN-107", From dd6e4e8b8156886a8a4184e6a348c44fbaf957a1 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 31 Jul 2023 17:05:31 +0100 Subject: [PATCH 362/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 488a23ea0..cca931bed 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -77,7 +77,7 @@ If the participant has sufficient collateral to cover their commitment, the comm For clarity, liquidity providers will have a separate [margin account](./0013-ACCT-accounts.md#trader-margin-accounts) and [bond account](./0013-ACCT-accounts.md#liquidity-provider-bond-accounts). A new or increased commitment will get activated in two stages.(*) First the commitment amount (increase) will get transferred from general to bond account. -Their obligation for providing liquidity under SLA is the one from the beginning of current epoch (so in particular for a new LP it's `0`). +Their obligation for providing liquidity under SLA is determined by their commitment from the beginning of the current epoch (so, in particular, for a new LP, it's 0). At the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated) the commitment amount is noted and the LP is expected to provide sufficient liquidity for the epoch. (*) The expectation is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. From c753915d5f992106a21bafbcb2d3e05f1efbc819 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 31 Jul 2023 17:06:15 +0100 Subject: [PATCH 363/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index cca931bed..474076c75 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -78,7 +78,7 @@ For clarity, liquidity providers will have a separate [margin account](./0013-AC A new or increased commitment will get activated in two stages.(*) First the commitment amount (increase) will get transferred from general to bond account. Their obligation for providing liquidity under SLA is determined by their commitment from the beginning of the current epoch (so, in particular, for a new LP, it's 0). -At the beginning of the next epoch (after the rewards / penalties for present LPs have been evaluated) the commitment amount is noted and the LP is expected to provide sufficient liquidity for the epoch. +Second, at the beginning of the next epoch (after the rewards/penalties for present LPs have been evaluated), the commitment amount is noted, and the LP is expected to provide sufficient liquidity for the epoch. (*) The expectation is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. From 6bbbd6d2129599f15a60edd3c1f64b7a621814a2 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 31 Jul 2023 17:07:05 +0100 Subject: [PATCH 364/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 474076c75..4f8ccf2a7 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -80,7 +80,7 @@ A new or increased commitment will get activated in two stages.(*) First the com Their obligation for providing liquidity under SLA is determined by their commitment from the beginning of the current epoch (so, in particular, for a new LP, it's 0). Second, at the beginning of the next epoch (after the rewards/penalties for present LPs have been evaluated), the commitment amount is noted, and the LP is expected to provide sufficient liquidity for the epoch. -(*) The expectation is the end of the opening auction of the market. The LPs that submit commitment during the opening auction become the market LPs as soon as the opening auction ends. +(*) The exception is the end of the opening auction of the market. The LPs that submit a commitment during the opening auction become the market LPs as soon as the opening auction ends. The fee for the market is only [updated at the epoch boundary using the "auction" mechanism set here](0042-LIQF-setting_fees_and_rewarding_lps.md). From a19397ab198bd0e5f0a0811cfbfc8c6c3649b4fa Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 2 Aug 2023 10:37:10 +0200 Subject: [PATCH 365/649] fix: Unpaid LP fees go into net treasury (#1874) * fix: Unpaid LP fees go into net treasury * fix/linting --- protocol/0073-LIMN-limited_network_life.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 932715c36..131942ec1 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -30,10 +30,11 @@ Information to store: - All [network parameters](../protocol/0054-NETP-network_parameters.md), including those defined [below](#network-parameters). - All [asset definitions](../protocol/0040-ASSF-asset_framework.md#asset-definition). -Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_overview.md), [LP committed liquidity](./0044-LIME-lp_mechanics.md) and [LP fee pool](../protocol/0029-FEES-fees.md) balances for the markets that have been enacted will be stored with the accepted market proposal that must have preceded the market. +Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_overview.md) and [LP committed liquidity](./0044-LIME-lp_mechanics.md) balances for the markets that have been enacted will be stored with the accepted market proposal that must have preceded the market. - All market proposals ([creation](../protocol/0028-GOVE-governance.md#1-create-market) and [update](../protocol/0028-GOVE-governance.md#2-change-market-parameters)) that have been *accepted* but not those where the market already started trading and reached *trading terminated* state. - All [asset proposals](../protocol/0028-GOVE-governance.md) that have been *accepted*. - All delegation info. +- [LP fee pool](../protocol/0029-FEES-fees.md) for undistributed LP fee balances on a market will be added to the into the network treasury for the asset balances. - On chain treasury balances and on-chain rewards for staking and delegation [Staking and delegation](../protocol/0056-REWA-rewards_overview.md). - [Account balances](../protocol/0013-ACCT-accounts.md) for all parties per asset: sum of general, margin and LP bond accounts. - Event ID of the last processed deposit event for all bridged chains From 866e526999c76b38f6d464c32b69996910e1c594 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Mon, 24 Jul 2023 15:28:35 +0100 Subject: [PATCH 366/649] tests: Add more successor market ACs. --- protocol/0081-SUCM-successor_markets.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index b2d1342c4..e994cfcdf 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -87,6 +87,8 @@ When a successor market is enacted (i.e. leaves the opening auction), all other With two successor markets in opening auction, that have the same parent market, and one additional market in the state "Proposed". Get one of the two markets to leave the opening auction (passage of time, LP commitment, crossing trade). The other market in auction and the proposed market should both be "Rejected" and all LP funds will be released (0081-SUCM-014) +Propose two markets which are attempting to succeed the same parent, and which have an overlapping voting period. Ensure the first child passes governance and enters opening auction. Ensure that the second child is also able to enter opening auction. The first to complete opening auction becomes the successor, and the other is rejected.(0081-SUCM-028) + Propose a successor market which specifies a parent which is settled, and for which the successor time window has expired. The proposal is declined. (0081-SUCM-018) ### APIs @@ -104,6 +106,14 @@ When fetching a market that is part of a "parent / successor chain", we should s After a LNL checkpoint restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-016) +A market which has been settled, but is still inside successor expiry window, is retained in a checkpoint, and can be used by a successor market after restart(0081-SUCM-029) + +A market which has been settled, and beyond the successor expiry window, is not retained in a checkpoint, and cannot be used by a successor market after restart(0081-SUCM-030) + +A market which has been settled, and already has a child which has succeeded it, is retained in a checkpoint, and can be found after restart. Both child and parent retain child/parent links in the API(0081-SUCM-031) + +For a parent/child (explicitly: the child has left opening auction), after a checkpoint restart, parent/child enter opening auction again. It is not possible to propose a new market which attempts to succeed that parent.(0081-SUCM-032) + After snapshot restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-017) A market which has expired before a protocol upgrade is still eligible to be used as a successor market after the upgrade, if it is inside the successor time window (0081-SUCM-025) From 18215f421304e8a2a7b54e5e282e709ab2085892 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Mon, 24 Jul 2023 16:34:21 +0100 Subject: [PATCH 367/649] fix: Clarification based on review. --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index e994cfcdf..d127fd9e8 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -112,7 +112,7 @@ A market which has been settled, and beyond the successor expiry window, is not A market which has been settled, and already has a child which has succeeded it, is retained in a checkpoint, and can be found after restart. Both child and parent retain child/parent links in the API(0081-SUCM-031) -For a parent/child (explicitly: the child has left opening auction), after a checkpoint restart, parent/child enter opening auction again. It is not possible to propose a new market which attempts to succeed that parent.(0081-SUCM-032) +For a parent and child (explicitly: the child has left opening auction), after a checkpoint restart, parent and child both enter opening auction again. It is not possible to propose a new market which attempts to succeed that parent.(0081-SUCM-032) After snapshot restart the successor (child) / parent market state is preserved where applicable inc. the LPs ELS (0081-SUCM-017) From d0d457595103e48ce7fc3466a0127ef65e86f3d4 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Wed, 2 Aug 2023 10:03:40 +0100 Subject: [PATCH 368/649] fix: Be more explicit on a successor markets AC. --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index d127fd9e8..e14c7d322 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -110,7 +110,7 @@ A market which has been settled, but is still inside successor expiry window, is A market which has been settled, and beyond the successor expiry window, is not retained in a checkpoint, and cannot be used by a successor market after restart(0081-SUCM-030) -A market which has been settled, and already has a child which has succeeded it, is retained in a checkpoint, and can be found after restart. Both child and parent retain child/parent links in the API(0081-SUCM-031) +A market which has been settled, and already has a child which has succeeded it, is retained in a checkpoint. Market can be queried via APIs and settled market state can be retrieved. Both child and parent retain parent/child links in market state, and are listed in "successor chain" API request(0081-SUCM-031) For a parent and child (explicitly: the child has left opening auction), after a checkpoint restart, parent and child both enter opening auction again. It is not possible to propose a new market which attempts to succeed that parent.(0081-SUCM-032) From 0fe2f1b83158e9ebe7c2cf109c8c415008af87bb Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Wed, 2 Aug 2023 10:10:38 +0100 Subject: [PATCH 369/649] chore: Update features.json for new ACs. --- protocol/features.json | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index f430ff799..fb6d0c400 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -170,7 +170,12 @@ "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", - "0081-SUCM-022" + "0081-SUCM-022", + "0081-SUCM-028", + "0081-SUCM-029", + "0081-SUCM-030", + "0081-SUCM-031", + "0081-SUCM-032" ] }, "Perps": { From 8b38aa351fce3a97750087b947fa823ea40dbdf2 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Fri, 28 Jul 2023 15:15:34 +0100 Subject: [PATCH 370/649] feat: update "cosmicelevator" ac --- protocol/0045-DSRC-data_sourcing.md | 2 +- protocol/0047-DSRF-data_source_filter.md | 4 ++-- protocol/0048-DSRI-data_source_internal.md | 18 +++++++++--------- protocol/0076-DANO-data-node.md | 6 +++--- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/protocol/0045-DSRC-data_sourcing.md b/protocol/0045-DSRC-data_sourcing.md index b11ef91c4..91307c1a2 100644 --- a/protocol/0045-DSRC-data_sourcing.md +++ b/protocol/0045-DSRC-data_sourcing.md @@ -240,7 +240,7 @@ Vega should reject any data source tx that is not explicitly required, so this w 1. Party submitting an oracle transaction that gets rejected (e.g. because no data source is listening for transactions from such key) can receive an error message detailing reason for rejection. (0045-DSRC-013) 1. It's possible to listen to events and see all data that is supplied across all data sources or for any specific source. (0045-DSRC-014) 1. Data node carries historic data of at least all valid data that was supplied for each data source. (0045-DSRC-015) -1. Data sources can be composed/nested arbitrarily (as long as the definition is valid), for example selecting a field on filtered data that itself was sourced by selecting a field on a message sent by a signed data source (for example this might be processing a complex object in the source data). (0045-COSMICELEVATOR-016) +1. Data sources can be composed/nested arbitrarily (as long as the definition is valid), for example selecting a field on filtered data that itself was sourced by selecting a field on a message sent by a signed data source (for example this might be processing a complex object in the source data). (0045-DSRC-016) 1. A market proposal specifies data source where value used for settlement is integer with implied decimals; the implied decimals are included in the oracle spec; once trading terminated and settlement data is submitted the price is interpreted correctly for settlement purposes. E.g. market decimals `1`, market uses asset for settlement with `10` decimals, oracle implied decimals `5`, submitted value `10156789` interpreted as `101.56789`. In asset decimals this is `1015678900000` and this is used for settlement. (0045-DSRC-017) 1. Data source transactions can be submitted by a party with zero balance in all assets. (0045-DSRC-018) 1. After trading termination has been triggered the trading terminated data source is no longer active (assuming it is not used anywhere else) and data from that source is no longer processed (0045-DSRC-019) diff --git a/protocol/0047-DSRF-data_source_filter.md b/protocol/0047-DSRF-data_source_filter.md index d85e3e7cf..fcb4113dc 100644 --- a/protocol/0047-DSRF-data_source_filter.md +++ b/protocol/0047-DSRF-data_source_filter.md @@ -90,8 +90,8 @@ To be clear, this also means that if the input data is the wrong "shape" or type 1. Create the same filter for multiple types of provider and ensure that with the same input data, the output is the same. (0047-DSRF-002) 1. All filter conditions are applied 1. Create a filter with multiple "AND" conditions and ensure that data is only passed through if all conditions are met. (0047-DSRF-003) - 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-COSMICELEVATOR-004) - 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01" _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-0041). + 1. Create a filter using an "OR" sub-filter (if implemented) and ensure that data is passed through if any of the OR conditions are met. (0047-DSRF-004) + 1. Create a "greater than or equal" filter on the "timestamp" field of the signed message (_not_ on the timestamp when oracle transaction is submitted) (e.g. greater than or equal "2022-04-01" _and_ on "equal" filter on the "asset" field (e.g. equals ETH) of the signed message from Coinbase oracle. Ensure these are applied correctly (0047-DSRF-041). 1. Data that is filtered out does not result in a data event but is recorded 1. No data source event is emitted for a data source if the triggering event (`SubmitData` transaction, internal source, etc.) does not pass through the filter for that source. (0047-DSRF-005) 1. No product/market processing is triggered by a data source when the event does not pass through the filters. (0047-DSRF-006) diff --git a/protocol/0048-DSRI-data_source_internal.md b/protocol/0048-DSRI-data_source_internal.md index 039e042d7..927e37c3d 100644 --- a/protocol/0048-DSRI-data_source_internal.md +++ b/protocol/0048-DSRI-data_source_internal.md @@ -108,16 +108,16 @@ Currently (as of Oregon Trail), only the *Vega time changed (1.3 above)* interna ## Acceptance criteria 1. A simple value data source can be provided - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-001) - 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-COSMICELEVATOR-002) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a Value source. The market settles immediately with the value provided as the settlement data. (0048-DSRI-001) + 1. Change a cash settled futures market's trading terminated trigger source with a market governance proposal to a blank Value data source (or one with any value, to be discarded) and ensure the market state changes to trading terminated. (0048-DSRI-002) 1. A time triggered value data source can be provided - 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-COSMICELEVATOR-009) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-COSMICELEVATOR-003) - 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-COSMICELEVATOR-004) - 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-005) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-COSMICELEVATOR-006) - 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-COSMICELEVATOR-007) - 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-COSMICELEVATOR-008) + 1. Use a market governance proposal to change a cash settled futures market that is already in Trading Terminated state and has a signed message data source configured for settlement data (where no signed message is ever received) so that the settlement data source is a time triggered Value source with the trigger time in the future after the proposal is enacted. The market settles at the trigger time with the value provided as the settlement data (this allows governance to settle a market with a dead oracle). (0048-DSRI-009) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated before the time specified in the trigger for the settlement data source. The market settles at the time specified in the trigger. (0048-DSRI-003) + 1. Create a cash settled futures market with a time triggered value data source for the settlement data. Trigger trading terminated after the time specified in the trigger for the settlement data source. The market settles immediately once trading terminated is triggered. (0048-DSRI-004) + 1. Create a cash settled futures market with the trading terminated trigger source being a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-005) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-006) + 1. Change a cash settled futures market so the trading terminated trigger source becomes a time triggered blank Value data source (or one with any value, to be discarded) with the trigger time being in the past. The market state changes to trading terminated immediately. (0048-DSRI-007) + 1. Change a cash settled futures market that is already in Trading Terminated state so that the settlement data source is a time triggered Value source with the trigger time in the past. The market settles immediately with the value provided as the settlement data. (0048-DSRI-008) 1. A Vega time changed value data source can be provided 1. Create a cash settled futures market with the trading terminated trigger source being a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-010) 1. Change a cash settled futures market so the trading terminated trigger source becomes a Vega time changed value data source with a greater than or greater than or equal filter against a time in the future. The market state changes to trading terminated at the time of the trigger. (0048-DSRI-011) diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 03f863784..3765e6284 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -146,7 +146,7 @@ It must be possible to add to the data node APIs that return the result of calcu ### Data synchronisation -1. To ensure no loss of historical data access; data nodes must be able to have access to and synchronise all historical data since genesis block or LNL restart (0076-COSMICELEVATOR-001) +1. To ensure no loss of historical data access; data nodes must be able to have access to and synchronise all historical data since genesis block or LNL restart (0076-DANO-001) 1. To ensure that new nodes joining the network have access to all historical data; nodes must be able to have access to and synchronise all historical data across the network without having to replay the full chain (0076-DANO-003) 1. Nodes must be able to start processing new blocks having loaded the only the most recent history (0076-DANO-023) 1. Nodes that have been temporarily disconnected from the network should be able to load the missed history to get back up to the current network height (or most recently produced history) and then be able to start processing new blocks (0076-DANO-024) @@ -176,8 +176,8 @@ It must be possible to add to the data node APIs that return the result of calcu ### Schema compatibility -1. It is possible to identify if schema versions are NOT backwards compatible. Pull existing network snapshots start network, run a protocol upgrade to at later version and ensure both the core state and data-node data is correct (0076-COSMICELEVATOR-XXX) -1. Restoring a node from decentralised history should work across schema upgrade boundaries and the state of the datanode should match that of a datanode populated purely by event consumption (0076-COSMICELEVATOR-XXX) +1. It is possible to identify if schema versions are NOT backwards compatible. Pull existing network snapshots start network, run a protocol upgrade to at later version and ensure both the core state and data-node data is correct (0076-DANO-041) +1. Restoring a node from decentralised history should work across schema upgrade boundaries and the state of the datanode should match that of a datanode populated purely by event consumption (0076-DANO-042) ### Data Retention From 112c2f4ae671d5d7d08b85e868978eee76b1ba0c Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 2 Aug 2023 12:30:14 +0100 Subject: [PATCH 371/649] chore: update asset framework ACs --- protocol/0040-ASSF-asset_framework.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/protocol/0040-ASSF-asset_framework.md b/protocol/0040-ASSF-asset_framework.md index ed2a82d75..0beb4bbaa 100644 --- a/protocol/0040-ASSF-asset_framework.md +++ b/protocol/0040-ASSF-asset_framework.md @@ -294,10 +294,9 @@ Once a withdrawal is complete and the appropriate events/transaction information For each asset class to be considered "supported" by Vega, the following must happen: 1. An asset of that class can Be voted into Vega (0040-ASSF-001) -2. An asset previously voted in can be voted out of Vega (0040-COSMICELEVATOR-002) -3. A voted-in asset can be deposited into a Vega bridge (0040-ASSF-003) -4. A properly deposited asset is credited to the appropriate user (0040-ASSF-004) -5. A withdrawal can be requested and verified by Vega validator nodes (0040-ASSF-005) -6. multisig withdrawal order signatures from Vega validator nodes can be aggregated at the request of the user (0040-ASSF-006) -7. A user can submit the withdrawal order and receive their asset (0040-ASSF-007) -8. Every asset must specify `quantum` and this must be an integer strictly greater than `0` (0040-ASSF-008) +1. A voted-in asset can be deposited into a Vega bridge (0040-ASSF-003) +1. A properly deposited asset is credited to the appropriate user (0040-ASSF-004) +1. A withdrawal can be requested and verified by Vega validator nodes (0040-ASSF-005) +1. multisig withdrawal order signatures from Vega validator nodes can be aggregated at the request of the user (0040-ASSF-006) +1. A user can submit the withdrawal order and receive their asset (0040-ASSF-007) +1. Every asset must specify `quantum` and this must be an integer strictly greater than `0` (0040-ASSF-008) From 710b197bdd7948c6a9e5a0e86f15f90f81e14141 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 3 Aug 2023 10:55:31 +0100 Subject: [PATCH 372/649] fix: update remaining ACs marked for COSMIC --- protocol/0031-ETHB-ethereum_bridge_spec.md | 6 ------ protocol/0055-TREA-on_chain_treasury.md | 9 ++++----- protocol/0057-TRAN-transfers.md | 4 ++-- protocol/0062-SPAM-spam_protection.md | 2 +- .../0069-VCBS-validators_chosen_by_stake.md | 4 ---- protocol/0072-SPPW-spam-protection-PoW.md | 17 ++++++++--------- 6 files changed, 15 insertions(+), 27 deletions(-) diff --git a/protocol/0031-ETHB-ethereum_bridge_spec.md b/protocol/0031-ETHB-ethereum_bridge_spec.md index 7a88be6cf..fb20caa84 100644 --- a/protocol/0031-ETHB-ethereum_bridge_spec.md +++ b/protocol/0031-ETHB-ethereum_bridge_spec.md @@ -153,12 +153,6 @@ This example connects the network to Ropsten: - A valid multisig bundle can be passed to the `list_asset` function to successfully add a token to the allowed list (0031-ETHB-016) - An invalid multisig bundle is rejected by the `list_asset` function (0031-ETHB-017) -### Blocklist a token (by eth address) - -- ERC-20 smart contract specific requirements: - - A valid multisig bundle can be passed to the `remove_asset` function to successfully remove a previously allow listed token (0031-COSMICELEVATOR-019) - - An invalid multisig bundle is rejected by the `remove_asset` function (0031-COSMICELEVATOR-020) - ### ERC20 Bridge Logic to Vega Integration Tests (Vega System Tests) To ensure complete coverage of public and external smart contract functions, listed below are all of the callable functions on `ERC20_Bridge_Logic` and their corresponding acceptance criteria. diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index 28a98428b..48be85293 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -58,10 +58,9 @@ A governance proposal may be submitted to transfer funds on enactment from the o - The Network Treasury accounts API returns the correct balance for the new account (0055-TREA-007) - The network treasury account balances [are restored after a network restart](./0073-LIMN-limited_network_life.md) (0055-TREA-010) -### Cosmic Elevator +### ☄️ Cosmic Elevator - If a governance proposal for a single transfer from a network treasury account to some other account is enacted then - - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-COSMICELEVATOR-050) - - if the balance in the network treasury for the asset is greater than the amount specified in the transfer then the network treasury balance is decreased by the said amount and the destination account (party address) account is incremented by the right amount. (0055-COSMICELEVATOR-051) -- If a governance proposal for a single periodic transfer from a network treasury account to some other account is enacted then the transfers run as individual transfers as specified by the schedule / amounts until the schedule ends. (0055-COSMICELEVATOR-060) - + - if the amount in the proposal greater than or equal amount in network treasury for the asset then the entire balance of the net treasury account is transferred to the destination account (party address). (0055-TREA-008) + - if the balance in the network treasury for the asset is greater than the amount specified in the transfer then the network treasury balance is decreased by the said amount and the destination account (party address) account is incremented by the right amount. (0055-TREA-009) +- If a governance proposal for a single periodic transfer from a network treasury account to some other account is enacted then the transfers run as individual transfers as specified by the schedule / amounts until the schedule ends. (0055-TREA-011) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 67d7d2d95..49c9e0db2 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -189,8 +189,8 @@ message CancelTransfer { - As a user I can transfer funds from a general account I control to an other party's general account. Such transfer can be immediate or delayed. (0057-TRAN-001) - As a user I **cannot** transfer funds from a general account I control to reward account with a one-off transfer. (0057-TRAN-002) -- As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-003). -- As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-COSMICELEVATOR-TRAN-004) +- As a user I can transfer funds from a general account I control to an locked_for_staking. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-PALAZZO-003). +- As a user I can transfer funds from a locked_from_staking account under my control to any party's general_account. Such transfer can be immediate or delayed. This functionality is currently not implemented (so don't try to test) (0057-PALAZZO-004) - As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005) - As a user I cannot transfer funds from accounts I own but from the type is not supported: - for accounts created in a futures market, bond and margin (0057-TRAN-006) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index b6209beaa..58f775b1b 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -116,6 +116,6 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Try to set `spam.protection.minimumWithdrawalQuantumMultiple` to `0` and verify that the parameter is rejected.(0062-SPAM-022) - Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) - Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) -- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-COSMICELEVATOR-001) +- Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-PALAZZO-001) > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. diff --git a/protocol/0069-VCBS-validators_chosen_by_stake.md b/protocol/0069-VCBS-validators_chosen_by_stake.md index 47eb23108..09891ea03 100644 --- a/protocol/0069-VCBS-validators_chosen_by_stake.md +++ b/protocol/0069-VCBS-validators_chosen_by_stake.md @@ -564,9 +564,6 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid ### Multisig update -1. Vega network receives the ethereum events updating the weights and stores them (`key`,`value`). (0069-COSMICELEVATOR-002) -1. For validators up to `network.validators.multisig.numberOfSigners` the `validator_score` is capped by the value on `Ethereum`, if available and it's `0` for those who should have value on Ethereum but don't (they are one of the top `network.validators.multisig.numberOfSigners` by `validator_score` on VEGA). (0069-COSMICELEVATOR-003) -1. It is possible to submit a transaction to update the weights. (0069-COSMICELEVATOR-004) 1. Can update multisig for new validator, and expect rewards (0069-VCBS-066) - Arrange a network with N validators and 1 ersatz validator. - Set `network.validators.multisig.numberOfSigners` = N. @@ -606,4 +603,3 @@ Setup a network with 6 nodes (3 validators, 2 ersatz validators, 1 pending valid 1. Issue 5 requests from a vega key in the same block, 4 of which with invalid signatures. Verify that only the one with the correct signature is passed to consensus, and is properly executed. (0069-VCBS-087) - diff --git a/protocol/0072-SPPW-spam-protection-PoW.md b/protocol/0072-SPPW-spam-protection-PoW.md index 001cb67d8..0d0c26beb 100644 --- a/protocol/0072-SPPW-spam-protection-PoW.md +++ b/protocol/0072-SPPW-spam-protection-PoW.md @@ -93,7 +93,7 @@ All Vega clients that submitted transactions can verify that their transaction h - Linking too many transactions with a low difficulty level to a block is detected and leads to blocking of the account (if increasing difficulty is turned on) (0072-SPPW-004) - Reusing a transaction identifier in a way that several transactions with the same ID end up in the same block is detected and the transactions are rejected (0072-SPPW-005) - A blocked account is unblocked after the maximum of 1/48 of an Epoch or 30 seconds. For transactions sent in the meantime, a meaningful error message is returned. (0072-SPPW-006) -- PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-COSMICELEVATOR-007) +- PoW attached to a valid transaction will be accepted provided it's using correct chain ID and, at time of submission, the block hash is one of the last `spam.pow.numberOfPastBlocks` blocks. (0072-SPPW-007) - For each transaction less than or equal to `spam.pow.numberOfTxPerBlock` in a block `spam.pow.difficulty` zeros are needed in the proof-of-work (0072-SPPW-008) - For each `spam.pow.numberOfTxPerBlock` sized block of transactions greater than `spam.pow.numberOfTxPerBlock` an additional 0 is required in the proof-of-work (1 additional zero for the first batch, two additional for the second batch etc) (0072-SPPW-009) - For a given block, a user is able to submit more than `spam.pow.numberOfTxPerBlock` transactions with only `spam.pow.difficulty` zeros by tying them to one or more historic blocks all of which are within `spam.pow.numberOfPastBlocks` blocks (0072-SPPW-010) @@ -101,30 +101,29 @@ All Vega clients that submitted transactions can verify that their transaction h - The parameter `spam.pow.difficulty` is increased. Verify that - Transactions tied to such a block using the original difficulty are rejected with an error message. - - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-008) + - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-SPPW-013) - The parameter `spam.pow.difficulty` is decreased. Verify that - Transactions tied to such a block using the new difficulty are not rejected. - - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-COSMICELEVATOR-009) + - The effect of `pow.increaseDifficulty` is still applied, i.e., a wallet key that had the increased difficulty still has the increased difficulty w.r.t. the new baseline. (0072-SPPW-014) - The parameter `spam.pow.increaseDifficulty` is changed from 0 to 1. Verify that - - Transactions tied to such a block using insufficient difficulty due to the new parameter are rejected with an error message. (0072-COSMICELEVATOR-010) + - Transactions tied to such a block using insufficient difficulty due to the new parameter are rejected with an error message. (0072-SPPW-015) - The parameter `spam.pow.increaseDifficulty` is changed from 1 to 0. Verify that - - Transactions tied to such a block using the base difficulty are not rejected. (0072-COSMICELEVATOR-011) + - Transactions tied to such a block using the base difficulty are not rejected. (0072-SPPW-016) - The parameter `spam.pow.numberofTxPerBlock` is decreased. Verify that - - The new parameter is used for all blocks with a block height higher than the current one, i.e., a number of transactions that was allowed before and is no longer due to the new parameter is rejected (leaving the spam difficulty level constant) (0072-COSMICELEVATOR-012) + - The new parameter is used for all blocks with a block height higher than the current one, i.e., a number of transactions that was allowed before and is no longer due to the new parameter is rejected (leaving the spam difficulty level constant) (0072-SPPW-017) - The parameter `spam.pow.numberofTxPerBlock` is increased. Verify that - - If a number of transactions is submitted with the lower lever PoW that would have exceeded the `spam.pow.numberOfTXPerBlock` before the change and not after, no transaction is rejected. (0072-COSMICELEVATOR-013) + - If a number of transactions is submitted with the lower lever PoW that would have exceeded the `spam.pow.numberOfTXPerBlock` before the change and not after, no transaction is rejected. (0072-SPPW-018) - Repeat tests 008-013, where in the same block, - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is increased. - `Spam.pow.difficulty` is increased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. - - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-COSMICELEVATOR-014) + - `Spam.pow.difficulty` is decreased and `spam.pow.increaseDifficulty` is increased (0 to 1), and `spam.pow.numberOfTXPerBlock` is decreased. (0072-SPPW-019) - *Mempool pruning* Cause congestion in the mempool by submitting many transactions (perhaps from several parties). Submit a transaction `T` tied to block number `N_old`. Make sure the transactions causing congestion create sufficiently large `N_current`. At some point we'll have `N_old + spam.pow.numberOfPastBlocks < N_current` and the transaction `T` is removed from the mempool and never scheduled. (0072-SPPW-012) - From 89cdb53df052f64536969120b5b0fb9ec04490f3 Mon Sep 17 00:00:00 2001 From: gordsport Date: Thu, 3 Aug 2023 11:17:50 +0100 Subject: [PATCH 373/649] chore: add AC to features list --- protocol/features.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index fb6d0c400..0f833cc4f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -47,7 +47,8 @@ "0028-GOVE-141", "0028-GOVE-142", "0028-GOVE-143", - "0028-GOVE-144" + "0028-GOVE-144", + "0055-TREA-011" ] }, "Iceberg Orders": { From 2417f68e60fd4a91e3ff7728bb163f9de3b3f63d Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 10:40:54 +0100 Subject: [PATCH 374/649] fix: division by zero in penalty calculation --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 0c7fff77e..13019d628 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -256,9 +256,10 @@ Let $s$ be `market.liquidity.commitmentMinTimeFraction`. Let $c$ be `market.liquidity.slaCompetitionFactor`. -$$ -p_i = (1 - \frac{t - s}{1 - s}) \cdot c. -$$ +$$p_i = \begin{cases} + (1 - \frac{t - s}{1 - s}) \cdot c &\text{if } s < 1 \\ + 0 &\text{if } s = 1 +\end{cases}$$ #### Calculating the SLA performance penalty for over hysteresis period From 3f6987807fa25debf0898517a695a3b5e5284031 Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Mon, 7 Aug 2023 10:47:12 +0100 Subject: [PATCH 375/649] feat: Review comments --- protocol/0002-STTL-settlement.md | 10 +++++----- protocol/0043-MKTL-market_lifecycle.md | 11 +++-------- protocol/features.json | 5 ----- 3 files changed, 8 insertions(+), 18 deletions(-) diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index 76b9633af..acba02d7d 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -64,11 +64,11 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on ## Acceptance Criteria -### The typical "Happy Path" case (Expiring Future: 0002-STTL-001, Perpetual Future: 0002-STTL-011) +### The typical "Happy Path" case (0002-STTL-001,) - With a market configured to take an oracle termination time and settlement price and put into continuous trading mode. When there are traders with open positions on the market and the termination trigger from oracle is sent so the market is terminated. Send market settlement price and assert that it is no longer possible to trade on this market. -### Example 1 - A typical path of a cash settled futures market nearing expiry when market is trading in continuous session (Expiring Future: 0002-STTL-002, Perpetual Future: 0002-STTL-012) +### Example 1 - A typical path of a cash settled futures market nearing expiry when market is trading in continuous session (0002-STTL-002) 1. Market has a status of ACTIVE and is trading in default trading mode 1. The product's [trading terminated trigger is hit](./0016-PFUT-product_builtin_future.md#41-termination-of-trading) @@ -82,9 +82,9 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. -1. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (Expiring Future: 0002-STTL-003, Perpetual Future: 0002-STTL-013) +2. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (0002-STTL-003) -### Example 2 - A less typical path of such a futures market nearing expiry when market is suspended (Expiring Future: 0002-STTL-004, Perpetual Future: 0002-STTL-014) +### Example 2 - A less typical path of such a futures market nearing expiry when market is suspended (0002-STTL-004) 1. Market has a status of SUSPENDED and in a protective auction 1. The product's [trading terminated trigger is hit](./0016-PFUT-product_builtin_future.md#41-termination-of-trading) @@ -107,7 +107,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. If margin and general account of trader are insufficient to cover collateral transfers, then collateral is attempted to be taken from market's insurance pool. (0002-STTL-008) 1. If the full required amount for collateral cannot be collected from individual or combination of these accounts, then as much as possible in the above sequence of accounts is collected and loss socialisation occurs. (0002-STTL-009) -### Example 3 - Settlement data to cash settled future is submitted before trading is terminated (0002-STTL-010)(Perpetual Future: 0002-STTL-015) +### Example 3 - Settlement data to cash settled future is submitted before trading is terminated (0002-STTL-010) 1. A [cash settled futures](0016-PFUT-product_builtin_future.md) market has a status of ACTIVE and is trading in default trading mode (continuous trading) 1. An [oracle event occurs](./0045-DSRC-data_sourcing.md) that is eligible to settle the market, as defined on the [Product](./0001-MKTF-market_framework.md) (see also [cash settled futures spec](./0016-PFUT-product_builtin_future.md)). In other words the settlement price is submitted to the market before trading is terminated. diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 413bc0d6c..b335f6c69 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -324,15 +324,10 @@ The market state is `active`. 1. An oracle event arrives which triggers the perpetual market's interim settlement logic, causing cashflow transfers but the market remains open. 1. Further trades happen, with parties still having different positions to previously. The mark price is `p`. -1. The time specified at market proposal by the internal time oracle is reached. -Any orders that parties submit get rejected. -The parties with open position in the immediately preceding step still have open positions. -Parties with open positions still have non-zero margin account balances. -The market state is `trading terminated`. -1. The settlement price oracle transaction is sent and it is *not* equal to `p`. -Parties that had open positions see settlement cash-flows happen. +1. A market state change proposal is created to terminate the market at a given price that is *not* equal to `p`. +When this is approved and enacted the market state is `closed`. +Parties that had open positions see settlement cash-flows happen to settle positions. Margin account balances are transferred to the general account. -The market state is `settled`. After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. ### Market never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-003) diff --git a/protocol/features.json b/protocol/features.json index 97b8afae6..08e91f7e7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -189,11 +189,6 @@ "0053-PERP-015", "0053-PERP-016", "0053-PERP-017", - "0002-STTL-011", - "0002-STTL-012", - "0002-STTL-013", - "0002-STTL-014", - "0002-STTL-015", "0043-MKTL-009", "0051-PROD-007", "0051-PROD-008", From 4aaf611f3b08ad88097fd42d7662989d5128ddab Mon Sep 17 00:00:00 2001 From: Tom McLean Date: Mon, 7 Aug 2023 11:51:32 +0100 Subject: [PATCH 376/649] feat: Review comments --- protocol/0002-STTL-settlement.md | 2 +- protocol/0043-MKTL-market_lifecycle.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index acba02d7d..c1f43de23 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -82,7 +82,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. -2. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (0002-STTL-003) +1. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (0002-STTL-003) ### Example 2 - A less typical path of such a futures market nearing expiry when market is suspended (0002-STTL-004) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index b335f6c69..a824991c7 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -325,7 +325,7 @@ The market state is `active`. 1. An oracle event arrives which triggers the perpetual market's interim settlement logic, causing cashflow transfers but the market remains open. 1. Further trades happen, with parties still having different positions to previously. The mark price is `p`. 1. A market state change proposal is created to terminate the market at a given price that is *not* equal to `p`. -When this is approved and enacted the market state is `closed`. +When this is approved and enacted the market state is `closed`. Parties that had open positions see settlement cash-flows happen to settle positions. Margin account balances are transferred to the general account. After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. From a2f10573ddab83838c4e1a9718bb174cebb9299f Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 7 Aug 2023 14:56:22 +0100 Subject: [PATCH 377/649] Update features.json (#1879) correct ethereum features --- protocol/features.json | 3 --- 1 file changed, 3 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 0f833cc4f..8f4927fc2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -567,7 +567,6 @@ "0082-ETHD-012", "0082-ETHD-013", "0082-ETHD-014", - "0082-ETHD-015", "0082-ETHD-016", "0082-ETHD-017", "0082-ETHD-018", @@ -583,8 +582,6 @@ "0082-ETHD-028", "0082-ETHD-029", "0082-ETHD-030", - "0082-ETHD-031", - "0082-ETHD-032", "0082-ETHD-034", "0082-ETHD-035", "0082-ETHD-036", From b08b6fc2f6195dd482108875594b5d1ed6867595 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 7 Aug 2023 16:13:21 +0200 Subject: [PATCH 378/649] refactor: clarify `delta_t` --- protocol/0053-PERP-product_builtin_perpetual_future.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index ec716e8d6..49335a255 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -149,7 +149,7 @@ delta_t = funding_period_end - max(funding_period_start, internal_data_points[0] funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower_bound*s_twap, (1 + delta_t * interest_rate)*s_twap-f_twap)) ``` -where `(1 + delta_t * interest_rate)` is the linearisation of `exp(delta_t*interest_rate)`. +where `(1 + delta_t * interest_rate)` is the linearisation of `exp(delta_t*interest_rate)` and `delta_t` is expressed as a year fraction. #### Funding rate calculation From 34ad58c9c89475a978ebe156a439ed0509643d4a Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 13 Jul 2023 15:08:38 +0100 Subject: [PATCH 379/649] feat: first draft --- .../0082-RFPR-on_chain_referral_program.md | 235 ++++++++++++++++++ 1 file changed, 235 insertions(+) create mode 100644 protocol/0082-RFPR-on_chain_referral_program.md diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md new file mode 100644 index 000000000..b658cc29e --- /dev/null +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -0,0 +1,235 @@ +# On Chain Referral Program Specification + +## Summary + +The aim of the on-chain referral program is to incentivise users and community members to refer new traders by providing benefits for both referrers and referees. + +Whilst a referral program is active, the following benefits will be available to eligible parties: + +- a **referrer** will receive a proportion of all referee taker fees as a **reward**. +- a **referee** will be eligible for a **discount** on any taker fees they incur. + +The size of the reward or discount will be dependent on the benefit tier the referees [team](#team-mechanics) is currently placed in. A team becomes eligible for greater benefits by reaching a minimum running volume over a number of epochs. Both referrers and referees contribute to their teams running volume. + +On-chain referral programs can be created and updated through [governance proposals](#governance-proposals). + +## Network Parameters + +- `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#benefit-tiers) which can be specified as part of a referral program +- `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program +- `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal +- `referralProgram.maxPartyVolumePerEpoch` - limits the volume which is eligible each epoch for referral program mechanisms +- `referralProgram.minStakedVegaTokens` - limits team creation to parties staking at least this number of tokens + +## Governance Proposals + +An on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: + +- `name`: name of the referral program +- `benefit_tiers`: a list of dictionaries with the following fields + - `minimum_running_volume`: the required `running_team_volume` for a team to access this tier + - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer + - `referral_discount_factor`: the proportion of the referees taker fees to be discounted +- `start_epoch`: the first epoch the program will become `STATE_ACTIVE` and benefits will be enabled +- `end_epoch`: the first epoch the program will become `STATE_CLOSED` and benefits will be disabled +- `window_length`: the number of epochs over which to evaluate a teams running volume + +```protobuf +message NewReferralProgram{ + changes: ReferralProgramConfiguration{ + name: "Vega Protocol Q4 Referral Program" + benefit_tiers: [ + { + "minimum_running_volume": 10000, + "referral_reward_factor": 0.000, + "referral_discount_factor": 0.000, + }, + { + "minimum_running_volume": 20000, + "referral_reward_factor": 0.005, + "referral_discount_factor": 0.005, + }, + { + "minimum_running_volume": 30000, + "referral_reward_factor": 0.010, + "referral_discount_factor": 0.010, + }, + ], + start_epoch: 100, + end_epoch: 128, + window_length: 7, + } +} +``` + +When submitting a referral program proposal through governance the following conditions apply: +- a proposer cannot set a `start_epoch` or `end_epoch` less than or equal to the current epoch. +- a proposer cannot set an `end_epoch` less than or equal to the `start_epoch`. +- the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. +- all `referral_reward_factor` values must be less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. +- all `referral_discount_factor` values must be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. +- `window_length` must be an integer greater than zero. + +After a referral program has been passed, the referral program must be assigned an `id` by the network and exposed through an API. A program can then be updated through a governance proposal using this `id`. +. +```protobuf +message UpdateReferralProgram{ + id: "abcd3fgh1jklmn0pqf5tuvwzyz" + changes: UpdateReferralProgramConfiguration{ + benefit_tiers: [ + { + "minimum_running_volume": 10000, + "referral_reward_factor": 0.001, + "referral_discount_factor": 0.002, + } + ], + start_epoch: 107 + end_epoch: 114, + window_length: 1, + } +} +``` +In addition to the conditions which apply when creating a referral program, the following apply: +- a proposer cannot update a program if its state is `STATUS_REJECTED`, `STATUS_STOPPED`, or `STATUS_CLOSED`. +- a proposer cannot update the `name` of a program. +- a proposer cannot update the `start_epoch` if the program is `STATUS_ACTIVE` + +## Referral Program Lifecycle: + +After a referral program [proposal](#governance-proposals) is validated and accepted by the network, a referral program is created and can be one of the following states. The current state of a program should be exposed via an API. + +| Status | Benefits Enabled | Condition for entry | Condition for exit | +| ------------------ | ---------------- | --------------------------------------------------------- | ---------------------------------------------------- | +| `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends | +| `STATUS_REJECTED` | No | Governance vote fails | na | +| `STATUS_PENDING` | No | Governance vote passes | Current epoch greater than or equal to `start_epoch` | +| `STATUS_STOPPED` | No | There is already an existing program with `STATUS_ACTIVE` | na | +| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | Current epoch less than or equal to `end_epoch` | +| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | na | + +## Team Mechanics +A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. + +### Creating a team + +To create a team and generate a referral code, a party must fulfil the following criteria: + +- party must not currently be a **referrer** +- party must not currently be a **referee** +- party must be staking at least `referralProgram.minStakedVegaTokens` tokens. + +This staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. + +A separate URL hosted on IPFS should allow a party to connect their Vega wallet and fill in the following optional team information: +- name: an optional team name to be added to the referral banner. +- url: an optional link to a team forum, discord, etc. +- image: optional image data to be used when creating the referral banner. + +The party can then generate a team id by approving a transaction generated by the dApp. This team id should be associated with referrers public key by the network. + +As well as generating a referral code the dApp should then generate a banner with the referrers optional fields which they can use to invite referees. + +### Joining a team + +To become a referee, a referee must create a key (programmatically or through a dApp) and then send a transaction to associate their key with an existing team. + +message JoinTeam{ + id: "abcd3fgh1jklmn0pqf5tuvwzyz" +} + +A user should also be able to do this process by approving a transaction from a dApp. + +### Team epoch and running volumes +Whilst a referral program is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. Note, for a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). + +```pseudo +party_epoch_volume = party_epoch_volume + (trade_price * trade_size * settlement_asset_quantum) +``` + +At the end of an epoch, for each team, a `team_epoch_volume` is calculated by summing each team members `party_epoch_volume`. The amount a party can contribute to their teams volume however is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. (Note this cap should not be directly to `party_epoch_volume` in case the network parameter is updated during an epoch). + +```pseudo +team_epoch_volume = sum[min(party_epoch_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] +``` + +After the values are calculated, the `team_epoch_volume` is stored by the network and each parties `party_epoch_volume` is reset to `0` ready for the next epoch. + +The network can then calculate the teams `team_running_volume` by summing a teams team_epoch_volume values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). + +## Benefit mechanics + +### Setting benefit factors + +Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. This is done by identifying a referees team and identifying the teams current benefit tier. A teams benefit tier is defined as the highest tier for which their `team_running_volume` is greater or equal to the tiers `minimum_running_volume`. If a party does not qualify for any tier, both values are set to `0`. + +```psuedo +Given: + benefit_tiers=[ + { + "minimum_running_volume": 10000, + "referral_reward_factor": 0.001, + "referral_discount_factor": 0.001, + }, + { + "minimum_running_volume": 20000, + "referral_reward_factor": 0.005, + "referral_discount_factor": 0.005, + }, + { + "minimum_running_volume": 30000, + "referral_reward_factor": 0.010, + "referral_discount_factor": 0.010, + }, + ] + +And: + team_running_volume=22353 + +Then: + referral_reward_factor=0.005 + referral_reward_factor=0.005 +``` + +These benefit factors are then fixed for the duration of the next epoch. + +### Applying benefit factors + +Whenever a fee is incurred by a referee (either during continuous trading or on auction exit) the network must apply referral program benefits. + +The network can first calculate individual fee components following the [fees specification](./0029-FEES-fees.md#calculating-fees) and apply any usual checks. + +The network must then: + +- Calculate the rewards due to the referrer. + ```pseudo + infrastructure_fee_reward = floor(infrastructure_fee * referral_reward_factor) + liquidity_fee_reward = floor(liquidity_fee * referral_reward_factor) + maker_fee_reward = floor(maker_fee * referral_reward_factor) + ``` +- Calculate the discounts due to the referee. + ```pseudo + infrastructure_fee_discount = floor(infrastructure_fee * referral_discount_factor) + liquidity_fee_discount = floor(liquidity_fee * referral_discount_factor) + maker_fee_discount = floor(maker_fee * referral_discount_factor) + ``` +- And then update the fees. + ```pseudo + infrastructure_fee = infrastructure_fee - infrastructure_fee_reward - infrastructure_fee_discount + liquidity_fee = liquidity_fee - liquidity_fee_reward - liquidity_fee_discount + maker_fee = maker_fee - maker_fee_reward - maker_fee_discount + ``` + +Note the rewards and discounts are floored rather than raised to ensure the final infrastructure fee cannot be negative. + +The network can then carry out the normal fee transfers using the updated fee amounts followed by additional transfers from the referees general account to the referrers general account. These transfers will use the following new transfer types. + +- `TRANSFER_TYPE_MAKER_FEE_REWARD_PAY` +- `TRANSFER_TYPE_MAKER_FEE_REWARD_DISTRIBUTE` +- `TRANSFER_TYPE_LIQUIDITY_FEE_REWARD_PAY` +- `TRANSFER_TYPE_LIQUIDITY_FEE_REWARD_DISTRIBUTE` +- `TRANSFER_TYPE_INFRASTRUCTURE_FEE_REWARD_PAY` +- `TRANSFER_TYPE_INFRASTRUCTURE_FEE_REWARD_DISTRIBUTE` + +## Acceptance Criteria + +WIP \ No newline at end of file From 878d7cff151d18e0fb04bfda1ecca64ca7065ff2 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 13 Jul 2023 15:54:14 +0100 Subject: [PATCH 380/649] fix: apply suggestion Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0082-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index b658cc29e..00776aed6 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -187,7 +187,7 @@ And: Then: referral_reward_factor=0.005 - referral_reward_factor=0.005 + referral_discount_factor=0.005 ``` These benefit factors are then fixed for the duration of the next epoch. From e3c1ef69e52d203ca035d9666bc82789eb1ac578 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 13 Jul 2023 16:36:22 +0100 Subject: [PATCH 381/649] refactor: apply suggestion Co-authored-by: Barnaby M --- protocol/0082-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 00776aed6..d2fb26feb 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -2,7 +2,7 @@ ## Summary -The aim of the on-chain referral program is to incentivise users and community members to refer new traders by providing benefits for both referrers and referees. +The aim of the on-chain referral program is to allow users of the protocol to incentivise users and community members to refer new traders by voting to provide benefits for referrers and/or referees. Whilst a referral program is active, the following benefits will be available to eligible parties: From 727ccd916c86ce18f4fa33dd0a3d278804037093 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 13 Jul 2023 16:36:45 +0100 Subject: [PATCH 382/649] refactor: apply suggestion Co-authored-by: Barnaby M --- protocol/0082-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index d2fb26feb..4f6558e32 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -4,7 +4,7 @@ The aim of the on-chain referral program is to allow users of the protocol to incentivise users and community members to refer new traders by voting to provide benefits for referrers and/or referees. -Whilst a referral program is active, the following benefits will be available to eligible parties: +Whilst a referral program is active, the following benefits may be available to eligible parties: - a **referrer** will receive a proportion of all referee taker fees as a **reward**. - a **referee** will be eligible for a **discount** on any taker fees they incur. From 5772c311b1bf4c4dbfb1b8604aaeafd4accb7562 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 13 Jul 2023 16:37:13 +0100 Subject: [PATCH 383/649] refactor: apply suggestion Co-authored-by: Barnaby M --- protocol/0082-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 4f6558e32..82f9bfa6e 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -9,7 +9,7 @@ Whilst a referral program is active, the following benefits may be available to - a **referrer** will receive a proportion of all referee taker fees as a **reward**. - a **referee** will be eligible for a **discount** on any taker fees they incur. -The size of the reward or discount will be dependent on the benefit tier the referees [team](#team-mechanics) is currently placed in. A team becomes eligible for greater benefits by reaching a minimum running volume over a number of epochs. Both referrers and referees contribute to their teams running volume. +The size of the reward or discount will be dependent on the benefit tier the referee's [team](#team-mechanics) is currently placed in. A team becomes eligible for greater benefits by reaching a minimum running volume over a number of epochs. Both referrers and referees contribute to their team's running volume. On-chain referral programs can be created and updated through [governance proposals](#governance-proposals). From c55835ab7b6bf8ebaba839944bc849a205aebdb9 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 13 Jul 2023 16:37:24 +0100 Subject: [PATCH 384/649] refactor: apply suggestion Co-authored-by: Barnaby M --- protocol/0082-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 82f9bfa6e..a88b56d66 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -23,7 +23,7 @@ On-chain referral programs can be created and updated through [governance propos ## Governance Proposals -An on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: +Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: - `name`: name of the referral program - `benefit_tiers`: a list of dictionaries with the following fields From 8e0c26d7c8fd8ebe52be37f02a2f88e38642c45e Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 13 Jul 2023 16:58:36 +0100 Subject: [PATCH 385/649] refactor: address feedback --- protocol/0082-RFPR-on_chain_referral_program.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index a88b56d66..bc9a2d570 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -18,7 +18,7 @@ On-chain referral programs can be created and updated through [governance propos - `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#benefit-tiers) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal -- `referralProgram.maxPartyVolumePerEpoch` - limits the volume which is eligible each epoch for referral program mechanisms +- `referralProgram.maxPartyVolumePerEpoch` - limits the volume in quantum units which is eligible each epoch for referral program mechanisms - `referralProgram.minStakedVegaTokens` - limits team creation to parties staking at least this number of tokens ## Governance Proposals @@ -27,7 +27,7 @@ Enabling or changing the terms of the on-chain referral program can be proposed - `name`: name of the referral program - `benefit_tiers`: a list of dictionaries with the following fields - - `minimum_running_volume`: the required `running_team_volume` for a team to access this tier + - `minimum_running_volume`: the required `running_team_volume` in quantum units for a team to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted - `start_epoch`: the first epoch the program will become `STATE_ACTIVE` and benefits will be enabled @@ -66,9 +66,9 @@ When submitting a referral program proposal through governance the following con - a proposer cannot set a `start_epoch` or `end_epoch` less than or equal to the current epoch. - a proposer cannot set an `end_epoch` less than or equal to the `start_epoch`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. -- all `referral_reward_factor` values must be less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. -- all `referral_discount_factor` values must be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. -- `window_length` must be an integer greater than zero. +- all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. +- all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. +- `window_length` must be an integer strictly greater than zero. After a referral program has been passed, the referral program must be assigned an `id` by the network and exposed through an API. A program can then be updated through a governance proposal using this `id`. . @@ -224,11 +224,8 @@ Note the rewards and discounts are floored rather than raised to ensure the fina The network can then carry out the normal fee transfers using the updated fee amounts followed by additional transfers from the referees general account to the referrers general account. These transfers will use the following new transfer types. - `TRANSFER_TYPE_MAKER_FEE_REWARD_PAY` -- `TRANSFER_TYPE_MAKER_FEE_REWARD_DISTRIBUTE` - `TRANSFER_TYPE_LIQUIDITY_FEE_REWARD_PAY` -- `TRANSFER_TYPE_LIQUIDITY_FEE_REWARD_DISTRIBUTE` - `TRANSFER_TYPE_INFRASTRUCTURE_FEE_REWARD_PAY` -- `TRANSFER_TYPE_INFRASTRUCTURE_FEE_REWARD_DISTRIBUTE` ## Acceptance Criteria From 10499c8f925c093c392930e7cf2618083d3d2d85 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 13 Jul 2023 17:51:02 +0100 Subject: [PATCH 386/649] feat: clarify creating joining a team transactions --- .../0082-RFPR-on_chain_referral_program.md | 27 ++++++++++++++----- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index bc9a2d570..f7fd6b7cb 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -110,7 +110,7 @@ After a referral program [proposal](#governance-proposals) is validated and acce ## Team Mechanics A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. -### Creating a team +### Creating / updating a team To create a team and generate a referral code, a party must fulfil the following criteria: @@ -120,22 +120,35 @@ To create a team and generate a referral code, a party must fulfil the following This staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. -A separate URL hosted on IPFS should allow a party to connect their Vega wallet and fill in the following optional team information: +To generate a team id / referral code, the party must submit a signed `CreateTeam` transaction with the following optional team information. + - name: an optional team name to be added to the referral banner. -- url: an optional link to a team forum, discord, etc. -- image: optional image data to be used when creating the referral banner. +- teamUrl: an optional link to a team forum, discord, etc. +- avatarUrl: an optional url to an image to be used as the teams avatar -The party can then generate a team id by approving a transaction generated by the dApp. This team id should be associated with referrers public key by the network. +```protobuf +message CreateTeam + name: "VegaRocks", + teamUrl: https://discord.com/channels/vegarocks + avatarUrl: https://vega-rocks/logo-360x360.jpg +``` -As well as generating a referral code the dApp should then generate a banner with the referrers optional fields which they can use to invite referees. +If a party which is already a referrer submits a `CreateTeam` transaction, their team metadata is simply updated. ### Joining a team -To become a referee, a referee must create a key (programmatically or through a dApp) and then send a transaction to associate their key with an existing team. +To join a team the party must fulfil the following criteria: +- party must not currently be a **referrer** +- party must not currently be a **referee** + +To become a referee, a referee must submit a signed `JoinTeam` transaction with the following fields: +- `id`: the id of the team they want to join (same as the referral code) +```protobuf message JoinTeam{ id: "abcd3fgh1jklmn0pqf5tuvwzyz" } +``` A user should also be able to do this process by approving a transaction from a dApp. From 3f2b0ec99c864a3cfaf068a775c1f46f97825b24 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 10:42:57 +0200 Subject: [PATCH 387/649] feat: add liquidity provider restrictions --- .../0082-RFPR-on_chain_referral_program.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index f7fd6b7cb..0c0fe3e3a 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -117,6 +117,10 @@ To create a team and generate a referral code, a party must fulfil the following - party must not currently be a **referrer** - party must not currently be a **referee** - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. +- party must not have a liquidity provision in any of the following states: + - `STATUS_ACTIVE` + - `STATUS_PENDING` + - `STATUS_UNDEPLOYED` This staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. @@ -140,6 +144,10 @@ If a party which is already a referrer submits a `CreateTeam` transaction, their To join a team the party must fulfil the following criteria: - party must not currently be a **referrer** - party must not currently be a **referee** +- party must not have a liquidity provision in any of the following states: + - `STATUS_ACTIVE` + - `STATUS_PENDING` + - `STATUS_UNDEPLOYED` To become a referee, a referee must submit a signed `JoinTeam` transaction with the following fields: - `id`: the id of the team they want to join (same as the referral code) @@ -169,6 +177,19 @@ After the values are calculated, the `team_epoch_volume` is stored by the networ The network can then calculate the teams `team_running_volume` by summing a teams team_epoch_volume values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). +### Removing liquidity providers + +As stated in [creating a team](#creating--updating-a-team) and [joining a team](#joining-a-team), referrers and referees are restricted from having a liquidity provision in one of the following states: +- `STATUS_ACTIVE` +- `STATUS_PENDING` +- `STATUS_UNDEPLOYED`. + +This rule is constant and cannot be broken even after becoming a referrer of referee. + +If a current referee becomes a liquidity provider they are simply removed from their team and are no longer eligible for benefits from the referral program. + +If a current referrer becomes a liquidity provider, the following actions happen each referees `referral_reward_factor` is set to `0`. At the end of the each epoch, the network should check if the referrer has cancelled their liquidity provision. If they have set each referees `referral_reward_factor` as detailed in [setting benefit factors](#setting-benefit-factors) + ## Benefit mechanics ### Setting benefit factors From f56f12c27bf345c631e565d458e0a8e7d3785a7e Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 10:48:47 +0200 Subject: [PATCH 388/649] feat: switch to single program --- .../0082-RFPR-on_chain_referral_program.md | 56 +++++-------------- 1 file changed, 14 insertions(+), 42 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 0c0fe3e3a..202d75366 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -25,19 +25,16 @@ On-chain referral programs can be created and updated through [governance propos Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: -- `name`: name of the referral program - `benefit_tiers`: a list of dictionaries with the following fields - `minimum_running_volume`: the required `running_team_volume` in quantum units for a team to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted -- `start_epoch`: the first epoch the program will become `STATE_ACTIVE` and benefits will be enabled -- `end_epoch`: the first epoch the program will become `STATE_CLOSED` and benefits will be disabled +- `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled - `window_length`: the number of epochs over which to evaluate a teams running volume ```protobuf -message NewReferralProgram{ - changes: ReferralProgramConfiguration{ - name: "Vega Protocol Q4 Referral Program" +message UpdateReferralProgram{ + changes: UpdateReferralProgramConfiguration{ benefit_tiers: [ { "minimum_running_volume": 10000, @@ -55,57 +52,32 @@ message NewReferralProgram{ "referral_discount_factor": 0.010, }, ], - start_epoch: 100, - end_epoch: 128, + closing_timestamp: 123456789, window_length: 7, } } ``` When submitting a referral program proposal through governance the following conditions apply: -- a proposer cannot set a `start_epoch` or `end_epoch` less than or equal to the current epoch. -- a proposer cannot set an `end_epoch` less than or equal to the `start_epoch`. +- a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. -After a referral program has been passed, the referral program must be assigned an `id` by the network and exposed through an API. A program can then be updated through a governance proposal using this `id`. -. -```protobuf -message UpdateReferralProgram{ - id: "abcd3fgh1jklmn0pqf5tuvwzyz" - changes: UpdateReferralProgramConfiguration{ - benefit_tiers: [ - { - "minimum_running_volume": 10000, - "referral_reward_factor": 0.001, - "referral_discount_factor": 0.002, - } - ], - start_epoch: 107 - end_epoch: 114, - window_length: 1, - } -} -``` -In addition to the conditions which apply when creating a referral program, the following apply: -- a proposer cannot update a program if its state is `STATUS_REJECTED`, `STATUS_STOPPED`, or `STATUS_CLOSED`. -- a proposer cannot update the `name` of a program. -- a proposer cannot update the `start_epoch` if the program is `STATUS_ACTIVE` +The referral program will start the epoch after the `enactment_timestamp` is reached. ## Referral Program Lifecycle: -After a referral program [proposal](#governance-proposals) is validated and accepted by the network, a referral program is created and can be one of the following states. The current state of a program should be exposed via an API. +After a referral program [proposal](#governance-proposals) is validated and accepted by the network, the network referral program is created / updated and can be one of the following states. The current state of the network referral program should be exposed via an API. -| Status | Benefits Enabled | Condition for entry | Condition for exit | -| ------------------ | ---------------- | --------------------------------------------------------- | ---------------------------------------------------- | -| `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends | -| `STATUS_REJECTED` | No | Governance vote fails | na | -| `STATUS_PENDING` | No | Governance vote passes | Current epoch greater than or equal to `start_epoch` | -| `STATUS_STOPPED` | No | There is already an existing program with `STATUS_ACTIVE` | na | -| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | Current epoch less than or equal to `end_epoch` | -| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | na | +| Status | Benefits Enabled | Condition for entry | Condition for exit | +| -------------------- | ---------------- | --------------------------------------------------------- | ----------------------------------------------------------------- | +| `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | +| `STATUS_REJECTED` | No | Governance vote fails (or is invalid) | New governance proposal submitted to the network | +| `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | +| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | +| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | ## Team Mechanics A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. From 15d7c3b2c0602baa85b73ecfe6d4467edda737c1 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 16:05:19 +0200 Subject: [PATCH 389/649] feat: add uncoded acceptance criteria --- .../0082-RFPR-on_chain_referral_program.md | 95 ++++++++++++++++++- 1 file changed, 94 insertions(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 202d75366..06d5f4f81 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -235,4 +235,97 @@ The network can then carry out the normal fee transfers using the updated fee am ## Acceptance Criteria -WIP \ No newline at end of file +### Governance Proposals + +1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: + - the `closing_timestamp` must be less than or equal to the proposals `enactment_time`. + - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers` + - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` + - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor` + - the `window_length` must be an integer strictly greater than zero. +1. A referral program should be started the first epoch change after the `enactment_datetime` is reached. +1. A referral program should be closed the first epoch change after the `closing_timestamp` is reached. +1. If a referral program is already active and a proposal `enactment_datetime` is reached, the referral program is updated at the next epoch change. + - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec + - Proposal for program A accepted and begins first epoch after 1st Jan + - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug + - Proposal for program B accepted and overrides program A the first epoch after 1st June + - Program is closed first epoch after 31st Aug, there should be no active proposals. + +### Team Mechanics + +#### Creating / updating a team + +1. If a party **is not** currently a referrer, the party can **create** a team, by submitting a signed `CreateParty` transaction. +1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `CreateParty` transaction. +1. If one or more of the following conditions are not met, any `CreateParty` transaction should be rejected. + - party must not currently be a **referee** + - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. + - party must not have a liquidity provision in any of the following states: + - `STATUS_ACTIVE` + - `STATUS_PENDING` + - `STATUS_UNDEPLOYED` + +#### Joining a team + +1. If a party **is not** currently a **referee**, the party can join a team by submitting a signed `JoinParty` transaction. +1. If one or more of the following conditions are not met, any `JoinParty` transaction should be rejected. + - a party must not currently be a **referrer** + - a party must not currently be a **referee** + - party must not have a liquidity provision in any of the following states: + - `STATUS_ACTIVE` + - `STATUS_PENDING` + - `STATUS_UNDEPLOYED` + +#### Team epoch and running volumes + +1. Each trade should increment both the maker and taker parties `party_epoch_volume` by the volume of the trade (expressed in quantum units) providing both parties are not members of the same team. +1. At the end of the epoch, the `team_epoch_volume` should be calculated by summing each team members `party_epoch_volume`. +1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their teams `team_epoch_volume`. +1. A teams `team_running_volume` is calculated as the sum of all `team_epoch_volumes` over the last `epoch_window` epochs. + +#### Reviewing team members + +1. If a **referrer** de-stakes enough tokens to no longer fulfil the `referralProgram.minStakedVegaTokens` requirement, the following actions are taken: + - volume from any trades involving the party no longer contribute to `party_epoch_volume` + - the `referral_reward_factor` of all **referees** is set to `0` + - at the start of the next epoch, the network will evaluate if the **referrer** has re-staked enough tokens. +1. If a **referrer** becomes a liquidity provider, the following actions are taken. + - volume from any trades involving the party no longer contribute to `party_epoch_volume` + - the `referral_reward_factor` of all **referees** is set to `0` + - at the start of the next epoch, the network will evaluate if the **referrer** has cancelled their liquidity commitment. +1. If a **referee** becomes a liquidity provider, they are removed from the team. + +### Benefit Mechanics + +#### Setting benefit factors + +1. At the start of an epoch, each referees `referral_reward_factor` and `referral_discount_factor` is reevaluated and fixed for the epoch. +1. A referees `referral_reward_factor` and `referral_discount_factor` is set equal to the factors in the highest benefit tier their team qualifies for. +1. If a referees team does not qualify for the lowest tier, their `referral_reward_factor` and `referral_discount_factor` are both set to `0`. +1. If a referees `referral_reward_factor` or `referral_discount_factor` is set to `0` during an epoch, their factors are not reevaluated until the start of the next epoch. + +#### Applying benefit factors + +1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. + - infrastructure fee + - liquidity fee + - maker fee +1. Referee discounts are correctly calculated and applied for each taker fee component when exiting an auction. + - infrastructure fee + - liquidity fee + - maker fee +1. Referrer rewards are correctly calculated and transferred for each taker fee component during continuous trading. + - infrastructure fee + - liquidity fee + - maker fee +1. Referrer rewards are correctly calculated and transferred for each taker fee component when exiting an auction. + - infrastructure fee + - liquidity fee + - maker fee + +### APIs +The following must be exposed via an API. +1. A list of teams and there comprising **referrer** and **referees** +1. Previous `team_epoch_volume` values and the current `team_running_volume` value for each team +1. The `referral_reward` and `referral_discount` for every trade \ No newline at end of file From 3e8fc0b7fc453f17408bfec3ddeaae491637b4ef Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 18:02:11 +0200 Subject: [PATCH 390/649] refactor: fix formatting for linting --- protocol/0082-RFPR-on_chain_referral_program.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 06d5f4f81..7733f9361 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -59,6 +59,7 @@ message UpdateReferralProgram{ ``` When submitting a referral program proposal through governance the following conditions apply: + - a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. @@ -79,7 +80,9 @@ After a referral program [proposal](#governance-proposals) is validated and acce | `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | | `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | + ## Team Mechanics + A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. ### Creating / updating a team @@ -114,6 +117,7 @@ If a party which is already a referrer submits a `CreateTeam` transaction, their ### Joining a team To join a team the party must fulfil the following criteria: + - party must not currently be a **referrer** - party must not currently be a **referee** - party must not have a liquidity provision in any of the following states: @@ -122,6 +126,7 @@ To join a team the party must fulfil the following criteria: - `STATUS_UNDEPLOYED` To become a referee, a referee must submit a signed `JoinTeam` transaction with the following fields: + - `id`: the id of the team they want to join (same as the referral code) ```protobuf @@ -133,6 +138,7 @@ message JoinTeam{ A user should also be able to do this process by approving a transaction from a dApp. ### Team epoch and running volumes + Whilst a referral program is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. Note, for a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo @@ -152,6 +158,7 @@ The network can then calculate the teams `team_running_volume` by summing a team ### Removing liquidity providers As stated in [creating a team](#creating--updating-a-team) and [joining a team](#joining-a-team), referrers and referees are restricted from having a liquidity provision in one of the following states: + - `STATUS_ACTIVE` - `STATUS_PENDING` - `STATUS_UNDEPLOYED`. From 1ed839a55d7cb5e9073add623bc06f0feb36831f Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 18:20:36 +0200 Subject: [PATCH 391/649] feat: restrict program participant committing liquidity --- .../0082-RFPR-on_chain_referral_program.md | 49 ++++++------------- 1 file changed, 14 insertions(+), 35 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 7733f9361..f2778169a 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -85,7 +85,7 @@ After a referral program [proposal](#governance-proposals) is validated and acce A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. -### Creating / updating a team +### Creating / updating teams To create a team and generate a referral code, a party must fulfil the following criteria: @@ -97,13 +97,15 @@ To create a team and generate a referral code, a party must fulfil the following - `STATUS_PENDING` - `STATUS_UNDEPLOYED` -This staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. +The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. Note, referees will be able to "move team" by submitting a new team. + +The liquidity provision restriction is constant, once a party has become a referrer they will be restricted from committing liquidity. Any liquidity provision transactions from a referrer should be rejected. To generate a team id / referral code, the party must submit a signed `CreateTeam` transaction with the following optional team information. -- name: an optional team name to be added to the referral banner. -- teamUrl: an optional link to a team forum, discord, etc. -- avatarUrl: an optional url to an image to be used as the teams avatar +- `name`: an optional team name to be added to the referral banner. +- `teamUrl`: an optional link to a team forum, discord, etc. +- `avatarUrl`: an optional url to an image to be used as the teams avatar ```protobuf message CreateTeam @@ -114,17 +116,18 @@ message CreateTeam If a party which is already a referrer submits a `CreateTeam` transaction, their team metadata is simply updated. -### Joining a team +### Joining / moving teams To join a team the party must fulfil the following criteria: - party must not currently be a **referrer** -- party must not currently be a **referee** - party must not have a liquidity provision in any of the following states: - `STATUS_ACTIVE` - `STATUS_PENDING` - `STATUS_UNDEPLOYED` +The liquidity provision restriction is constant, once a party has become a referee they will be restricted from committing liquidity. Any liquidity provision transactions from a referee should be rejected. + To become a referee, a referee must submit a signed `JoinTeam` transaction with the following fields: - `id`: the id of the team they want to join (same as the referral code) @@ -135,16 +138,18 @@ message JoinTeam{ } ``` -A user should also be able to do this process by approving a transaction from a dApp. +If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end of the epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. ### Team epoch and running volumes -Whilst a referral program is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. Note, for a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). +Whilst a referral program is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo party_epoch_volume = party_epoch_volume + (trade_price * trade_size * settlement_asset_quantum) ``` +Note, to prevent participants "wash trading" within a team to boost their teams volume, trades where both the maker and taker are a member of the same party do not contribute to each parties `party_epoch_volume`. + At the end of an epoch, for each team, a `team_epoch_volume` is calculated by summing each team members `party_epoch_volume`. The amount a party can contribute to their teams volume however is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. (Note this cap should not be directly to `party_epoch_volume` in case the network parameter is updated during an epoch). ```pseudo @@ -155,20 +160,6 @@ After the values are calculated, the `team_epoch_volume` is stored by the networ The network can then calculate the teams `team_running_volume` by summing a teams team_epoch_volume values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). -### Removing liquidity providers - -As stated in [creating a team](#creating--updating-a-team) and [joining a team](#joining-a-team), referrers and referees are restricted from having a liquidity provision in one of the following states: - -- `STATUS_ACTIVE` -- `STATUS_PENDING` -- `STATUS_UNDEPLOYED`. - -This rule is constant and cannot be broken even after becoming a referrer of referee. - -If a current referee becomes a liquidity provider they are simply removed from their team and are no longer eligible for benefits from the referral program. - -If a current referrer becomes a liquidity provider, the following actions happen each referees `referral_reward_factor` is set to `0`. At the end of the each epoch, the network should check if the referrer has cancelled their liquidity provision. If they have set each referees `referral_reward_factor` as detailed in [setting benefit factors](#setting-benefit-factors) - ## Benefit mechanics ### Setting benefit factors @@ -291,18 +282,6 @@ The network can then carry out the normal fee transfers using the updated fee am 1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their teams `team_epoch_volume`. 1. A teams `team_running_volume` is calculated as the sum of all `team_epoch_volumes` over the last `epoch_window` epochs. -#### Reviewing team members - -1. If a **referrer** de-stakes enough tokens to no longer fulfil the `referralProgram.minStakedVegaTokens` requirement, the following actions are taken: - - volume from any trades involving the party no longer contribute to `party_epoch_volume` - - the `referral_reward_factor` of all **referees** is set to `0` - - at the start of the next epoch, the network will evaluate if the **referrer** has re-staked enough tokens. -1. If a **referrer** becomes a liquidity provider, the following actions are taken. - - volume from any trades involving the party no longer contribute to `party_epoch_volume` - - the `referral_reward_factor` of all **referees** is set to `0` - - at the start of the next epoch, the network will evaluate if the **referrer** has cancelled their liquidity commitment. -1. If a **referee** becomes a liquidity provider, they are removed from the team. - ### Benefit Mechanics #### Setting benefit factors From 22d10535a95d7bf0a3d7b53af6855cd5daa32f0a Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 18:23:59 +0200 Subject: [PATCH 392/649] refactor: remove unneeded LP states for SLA --- .../0082-RFPR-on_chain_referral_program.md | 22 +++++-------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index f2778169a..94d85c56b 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -92,10 +92,7 @@ To create a team and generate a referral code, a party must fulfil the following - party must not currently be a **referrer** - party must not currently be a **referee** - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. -- party must not have a liquidity provision in any of the following states: - - `STATUS_ACTIVE` - - `STATUS_PENDING` - - `STATUS_UNDEPLOYED` +- party must not have an active liquidity provision The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. Note, referees will be able to "move team" by submitting a new team. @@ -121,10 +118,7 @@ If a party which is already a referrer submits a `CreateTeam` transaction, their To join a team the party must fulfil the following criteria: - party must not currently be a **referrer** -- party must not have a liquidity provision in any of the following states: - - `STATUS_ACTIVE` - - `STATUS_PENDING` - - `STATUS_UNDEPLOYED` +- party must not have an active liquidity provision The liquidity provision restriction is constant, once a party has become a referee they will be restricted from committing liquidity. Any liquidity provision transactions from a referee should be rejected. @@ -259,10 +253,8 @@ The network can then carry out the normal fee transfers using the updated fee am 1. If one or more of the following conditions are not met, any `CreateParty` transaction should be rejected. - party must not currently be a **referee** - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - - party must not have a liquidity provision in any of the following states: - - `STATUS_ACTIVE` - - `STATUS_PENDING` - - `STATUS_UNDEPLOYED` + - party must not have an active liquidity provision + #### Joining a team @@ -270,10 +262,8 @@ The network can then carry out the normal fee transfers using the updated fee am 1. If one or more of the following conditions are not met, any `JoinParty` transaction should be rejected. - a party must not currently be a **referrer** - a party must not currently be a **referee** - - party must not have a liquidity provision in any of the following states: - - `STATUS_ACTIVE` - - `STATUS_PENDING` - - `STATUS_UNDEPLOYED` + - party must not have an active liquidity provision + #### Team epoch and running volumes From 7e450bbe61f1d2264484a32e75a2239964d2cc61 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 18:46:32 +0200 Subject: [PATCH 393/649] feat: add API requirements --- .../0082-RFPR-on_chain_referral_program.md | 28 +++++++++++++++---- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 94d85c56b..711ae7b49 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -225,6 +225,28 @@ The network can then carry out the normal fee transfers using the updated fee am - `TRANSFER_TYPE_LIQUIDITY_FEE_REWARD_PAY` - `TRANSFER_TYPE_INFRASTRUCTURE_FEE_REWARD_PAY` +## APIs + +The Teams API should expose the following information: + +- a list of all **teams** (by `id`), their founding **referrer**, and any current **referees** +- a list of all **teams** (by `id`) and the following metrics: + - current `team_running_volume` (value at the start of the epoch) + - current `referral_reward_factor` applied to referee taker fees + - current `referral_discount_factor` applied to referee taker fees + - any data required for additional reward metrics + +The Trades API should now also expose the following additional information for every trade: + +- Referral program rewards + - `infrastructure_fee_reward` + - `liquidity_fee_reward` + - `maker_fee_reward` +- Referral program discounts + - `infrastructure_fee_discount` + - `liquidity_fee_discount` + - `maker_fee_discount` + ## Acceptance Criteria ### Governance Proposals @@ -299,9 +321,3 @@ The network can then carry out the normal fee transfers using the updated fee am - infrastructure fee - liquidity fee - maker fee - -### APIs -The following must be exposed via an API. -1. A list of teams and there comprising **referrer** and **referees** -1. Previous `team_epoch_volume` values and the current `team_running_volume` value for each team -1. The `referral_reward` and `referral_discount` for every trade \ No newline at end of file From c94a0314dc1726e4fda525b181b35e745c7cb6d6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 18:59:32 +0200 Subject: [PATCH 394/649] feat: update ACs --- .../0082-RFPR-on_chain_referral_program.md | 61 +++++++++++-------- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 711ae7b49..9fba46e0c 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -253,39 +253,46 @@ The Trades API should now also expose the following additional information for e 1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - the `closing_timestamp` must be less than or equal to the proposals `enactment_time`. - - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers` - - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` - - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor` + - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. + - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. + - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - the `window_length` must be an integer strictly greater than zero. 1. A referral program should be started the first epoch change after the `enactment_datetime` is reached. 1. A referral program should be closed the first epoch change after the `closing_timestamp` is reached. 1. If a referral program is already active and a proposal `enactment_datetime` is reached, the referral program is updated at the next epoch change. - - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec - - Proposal for program A accepted and begins first epoch after 1st Jan - - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug - - Proposal for program B accepted and overrides program A the first epoch after 1st June + - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec. + - Proposal for program A accepted and begins first epoch after 1st Jan. + - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug. + - Proposal for program B accepted and overrides program A the first epoch after 1st June. - Program is closed first epoch after 31st Aug, there should be no active proposals. ### Team Mechanics -#### Creating / updating a team +#### Creating / updating teams 1. If a party **is not** currently a referrer, the party can **create** a team, by submitting a signed `CreateParty` transaction. 1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `CreateParty` transaction. 1. If one or more of the following conditions are not met, any `CreateParty` transaction should be rejected. - - party must not currently be a **referee** + - party must not currently be a **referee**. - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - - party must not have an active liquidity provision + - party must not have an active liquidity provision. +1. If a referrer removes sufficient stake to not meet the required tokens, the referrers team should not be eligible for the following referral program benefits: + - team member trades should not contribute to their teams volume. + - the referrer should not be rewarded for any referee taker fees. + - referees should not receive any discount on their taker fees. +1. If the referrer of a team currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the next epoch. +1. If a party has created a team (i.e. is a referrer) any future liquidity provision transactions from the party should be rejected. -#### Joining a team +#### Joining / moving teams 1. If a party **is not** currently a **referee**, the party can join a team by submitting a signed `JoinParty` transaction. +1. If a party **is** currently a **referee**, the party can move team (at the start of the next epoch) by submitting a signed `JoinParty` transaction. +1. If a party **is** currently a **referee** and submits multiple `JoinParty` transactions in an epoch, the latest valid `JoinParty` transaction will be applied. 1. If one or more of the following conditions are not met, any `JoinParty` transaction should be rejected. - - a party must not currently be a **referrer** - - a party must not currently be a **referee** - - party must not have an active liquidity provision - + - a party must not currently be a **referrer**. + - party must not have an active liquidity provision. +1. If a party has joined a team (i.e. is a referee) any future liquidity provision transactions from the party should be rejected. #### Team epoch and running volumes @@ -306,18 +313,18 @@ The Trades API should now also expose the following additional information for e #### Applying benefit factors 1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. - - infrastructure fee - - liquidity fee - - maker fee + - `infrastructure_fee_discount` + - `liquidity_fee_discount` + - `maker_fee_discount` 1. Referee discounts are correctly calculated and applied for each taker fee component when exiting an auction. - - infrastructure fee - - liquidity fee - - maker fee + - `infrastructure_fee_discount` + - `liquidity_fee_discount` + - `maker_fee_discount` 1. Referrer rewards are correctly calculated and transferred for each taker fee component during continuous trading. - - infrastructure fee - - liquidity fee - - maker fee + - `infrastructure_fee_reward` + - `liquidity_fee_reward` + - `maker_fee_reward` 1. Referrer rewards are correctly calculated and transferred for each taker fee component when exiting an auction. - - infrastructure fee - - liquidity fee - - maker fee + - `infrastructure_fee_reward` + - `liquidity_fee_reward` + - `maker_fee_reward` From ca1b1e30db44809e39e7ed1b3b7259e1a1eda6ea Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 17 Jul 2023 19:00:35 +0200 Subject: [PATCH 395/649] feat: update wordlist --- wordlist.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/wordlist.txt b/wordlist.txt index d4db52e34..76391db34 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -308,3 +308,6 @@ wBTC whitepaper Yubikey $VEGA +teamUrl +avatarUrl +dApp From 94197174b595009f08743a5e5876b1aaaaa095b1 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 19 Jul 2023 19:30:48 +0200 Subject: [PATCH 396/649] feat: add volume discount program spec --- protocol/0029-FEES-fees.md | 73 ++++++++- .../0082-RFPR-on_chain_referral_program.md | 96 +++--------- protocol/0083-VDPR-volume_discount_program.md | 139 ++++++++++++++++++ 3 files changed, 231 insertions(+), 77 deletions(-) create mode 100644 protocol/0083-VDPR-volume_discount_program.md diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 9537b2e6e..c3c7ce736 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -21,6 +21,44 @@ Fees are calculated and collected in the settlement currency of the market, coll Note that maker_fee = 0 if there is no maker, taker relationship between the trading parties (in particular auctions). +## Applying benefit factors + +Before fees are transferred, if there is an [active referral program](./0082-RFPR-on_chain_referral_program.md) or [volume discount program](./0083-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. + +1. Calculate any referral rewards due to the parties referrer. + + ```pseudo + infrastructure_fee_referral_reward = floor(infrastructure_fee * referral_reward_factor) + liquidity_fee_referral_reward = floor(liquidity_fee * referral_reward_factor) + maker_fee_referral_reward = floor(maker_fee * referral_reward_factor) + ``` + +2. Calculate any referral discounts due to the party. + + ```pseudo + infrastructure_fee_referral_discount = floor(infrastructure_fee * referral_discount_factor) + liquidity_fee_referral_discount = floor(liquidity_fee * referral_discount_factor) + maker_fee_referral_discount = floor(maker_fee * referral_discount_factor) + ``` + +3. Calculate any volume discounts due to the party. + + ```pseudo + infrastructure_fee_volume_discount = floor(infrastructure_fee * volume_discount_factor) + liquidity_fee_volume_discount = floor(liquidity_fee * volume_discount_factor) + maker_fee_volume_discount = floor(maker_fee * volume_discount_factor) + ``` + +4. And then update the fees. + + ```pseudo + infrastructure_fee = infrastructure_fee - infrastructure_fee_referral_reward - infrastructure_fee_referral_discount - infrastructure_fee_volume_discount + liquidity_fee = liquidity_fee - liquidity_fee_referral_reward - liquidity_fee_referral_discount - liquidity_fee_volume_discount + maker_fee = maker_fee - maker_fee_referral_reward - maker_fee_referral_discount - maker_fee_volume_discount + ``` + +(Note the rewards and discounts are floored rather than raised to ensure the final fees cannot be negative.) + ### Factors - infrastructure: staking/governance system/engine (network wide) @@ -42,7 +80,7 @@ NB: size of trade needs to take into account Position Decimal Places specified i ### Collecting and Distributing Fees -We need to calculate the total fee for the transaction. +We need to calculate the total fee for the transaction (before applying benefit factors). Attempt to transfer the full fee from the trader into a temporary bucket, one bucket per trade (so we know who the maker is) from the trader general account. If insufficient, then take the remainder (possibly full fee) from the margin account. The margin account should have enough left after paying the fees to cover maintenance level of margin for the trades. @@ -55,11 +93,12 @@ Other than the criteria whether to proceed or discard, this is exactly the same The transfer of fees must be completed before performing the normal post-trade calculations (MTM Settlement, position resolution etc...). The transfers have to be identifiable as fee transfers and separate for the three components. -Now distribute funds from the "temporary fee bucket" as follows: +Now [apply benefit factors](#applying-benefit-factors) and then distribute funds from the "temporary fee bucket" as follows: -1. Infrastructure_fee is transferred to infrastructure fee pool for that asset. Its distribution is described in [0061 - Proof of Stake rewards](./0061-REWP-pos_rewards.md). In particular, at the end of each epoch the amount due to each validator and delegator is to be calculated and then distributed subject to validator score and type. -1. The maker_fee is transferred to the relevant party. -1. The liquidity_fee is distributed as described in [this spec](./0042-LIQF-setting_fees_and_rewarding_lps.md). +1. The `infrastructure_fee` is transferred to infrastructure fee pool for that asset. Its distribution is described in [0061 - Proof of Stake rewards](./0061-REWP-pos_rewards.md). In particular, at the end of each epoch the amount due to each validator and delegator is to be calculated and then distributed subject to validator score and type. +1. The `maker_fee` is transferred to the relevant party (the maker). +1. The `liquidity_fee` is distributed as described in [this spec](./0042-LIQF-setting_fees_and_rewarding_lps.md). +1. The referral fee components (if any) can then be individually transferred to the relevant party (the referee). ### During Continuous Trading @@ -107,3 +146,27 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012) for product spot: (0029-FEES-020) - A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013) for product spot: (0029-FEES-021) - A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014) for product spot: (0029-FEES-022) + +### Applying benefit factors + +1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. + - `infrastructure_referral_fee_discount` + - `liquidity_fee_referral_discount` + - `maker_fee_referral_discount` +1. Referee discounts are correctly calculated and applied for each fee component when exiting an auction. + - `infrastructure_fee_referral_discount` + - `liquidity_fee_referral_discount` +1. Referrer rewards are correctly calculated and transferred for each fee component during continuous trading. + - `infrastructure_fee_referral_reward` + - `liquidity_fee_referral_reward` + - `maker_fee_referral_reward` +1. Referrer rewards are correctly calculated and transferred for each fee component when exiting an auction. + - `infrastructure_fee_referral_reward` + - `liquidity_fee_referral_reward` +1. Volume discount rewards are correctly calculated and transferred for each taker fee component during continuous trading. + - `infrastructure_fee_volume_discount` + - `liquidity_fee_volume_discount` + - `maker_fee_volume_discount` +1. Volume discount rewards are correctly calculated and transferred for each fee component when exiting an auction. + - `infrastructure_fee_volume_discount` + - `liquidity_fee_volume_discount` diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 9fba46e0c..78bdfac85 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -2,7 +2,7 @@ ## Summary -The aim of the on-chain referral program is to allow users of the protocol to incentivise users and community members to refer new traders by voting to provide benefits for referrers and/or referees. +The aim of the on-chain referral program is to allow users of the protocol to incentivise users and community members to refer new traders by voting to provide benefits for referrers and/or referees. Whilst a referral program is active, the following benefits may be available to eligible parties: @@ -15,7 +15,7 @@ On-chain referral programs can be created and updated through [governance propos ## Network Parameters -- `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#benefit-tiers) which can be specified as part of a referral program +- `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal - `referralProgram.maxPartyVolumePerEpoch` - limits the volume in quantum units which is eligible each epoch for referral program mechanisms @@ -68,7 +68,7 @@ When submitting a referral program proposal through governance the following con The referral program will start the epoch after the `enactment_timestamp` is reached. -## Referral Program Lifecycle: +## Referral program lifecycle After a referral program [proposal](#governance-proposals) is validated and accepted by the network, the network referral program is created / updated and can be one of the following states. The current state of the network referral program should be exposed via an API. @@ -78,8 +78,7 @@ After a referral program [proposal](#governance-proposals) is validated and acce | `STATUS_REJECTED` | No | Governance vote fails (or is invalid) | New governance proposal submitted to the network | | `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | | `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | -| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | - +| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | ## Team Mechanics @@ -134,15 +133,17 @@ message JoinTeam{ If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end of the epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. -### Team epoch and running volumes +### Party epoch volumes -Whilst a referral program is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). +Whilst a referral program or [volume discount program](./0083-VDPR-volume_discount_program.md) is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo party_epoch_volume = party_epoch_volume + (trade_price * trade_size * settlement_asset_quantum) ``` -Note, to prevent participants "wash trading" within a team to boost their teams volume, trades where both the maker and taker are a member of the same party do not contribute to each parties `party_epoch_volume`. +At the end of an epoch, the `party_epoch_value` is stored by the network and each parties `party_epoch_value` is reset to `0` ready for the next epoch. + +### Team epoch and running volumes At the end of an epoch, for each team, a `team_epoch_volume` is calculated by summing each team members `party_epoch_volume`. The amount a party can contribute to their teams volume however is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. (Note this cap should not be directly to `party_epoch_volume` in case the network parameter is updated during an epoch). @@ -150,9 +151,9 @@ At the end of an epoch, for each team, a `team_epoch_volume` is calculated by su team_epoch_volume = sum[min(party_epoch_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] ``` -After the values are calculated, the `team_epoch_volume` is stored by the network and each parties `party_epoch_volume` is reset to `0` ready for the next epoch. +After the values are calculated, the `team_epoch_volume` is stored by the network. -The network can then calculate the teams `team_running_volume` by summing a teams team_epoch_volume values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). +The network can then calculate the teams `team_running_volume` by summing a teams `team_epoch_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). ## Benefit mechanics @@ -160,7 +161,7 @@ The network can then calculate the teams `team_running_volume` by summing a team Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. This is done by identifying a referees team and identifying the teams current benefit tier. A teams benefit tier is defined as the highest tier for which their `team_running_volume` is greater or equal to the tiers `minimum_running_volume`. If a party does not qualify for any tier, both values are set to `0`. -```psuedo +```pseudo Given: benefit_tiers=[ { @@ -192,38 +193,8 @@ These benefit factors are then fixed for the duration of the next epoch. ### Applying benefit factors -Whenever a fee is incurred by a referee (either during continuous trading or on auction exit) the network must apply referral program benefits. - -The network can first calculate individual fee components following the [fees specification](./0029-FEES-fees.md#calculating-fees) and apply any usual checks. +Referral program benefit factors are applied by modifying [the fees](./0029-FEES-fees.md) paid by a party (either during continuous trading or on auction exit). -The network must then: - -- Calculate the rewards due to the referrer. - ```pseudo - infrastructure_fee_reward = floor(infrastructure_fee * referral_reward_factor) - liquidity_fee_reward = floor(liquidity_fee * referral_reward_factor) - maker_fee_reward = floor(maker_fee * referral_reward_factor) - ``` -- Calculate the discounts due to the referee. - ```pseudo - infrastructure_fee_discount = floor(infrastructure_fee * referral_discount_factor) - liquidity_fee_discount = floor(liquidity_fee * referral_discount_factor) - maker_fee_discount = floor(maker_fee * referral_discount_factor) - ``` -- And then update the fees. - ```pseudo - infrastructure_fee = infrastructure_fee - infrastructure_fee_reward - infrastructure_fee_discount - liquidity_fee = liquidity_fee - liquidity_fee_reward - liquidity_fee_discount - maker_fee = maker_fee - maker_fee_reward - maker_fee_discount - ``` - -Note the rewards and discounts are floored rather than raised to ensure the final infrastructure fee cannot be negative. - -The network can then carry out the normal fee transfers using the updated fee amounts followed by additional transfers from the referees general account to the referrers general account. These transfers will use the following new transfer types. - -- `TRANSFER_TYPE_MAKER_FEE_REWARD_PAY` -- `TRANSFER_TYPE_LIQUIDITY_FEE_REWARD_PAY` -- `TRANSFER_TYPE_INFRASTRUCTURE_FEE_REWARD_PAY` ## APIs @@ -231,21 +202,21 @@ The Teams API should expose the following information: - a list of all **teams** (by `id`), their founding **referrer**, and any current **referees** - a list of all **teams** (by `id`) and the following metrics: - - current `team_running_volume` (value at the start of the epoch) - - current `referral_reward_factor` applied to referee taker fees - - current `referral_discount_factor` applied to referee taker fees - - any data required for additional reward metrics + - current `team_running_volume` (value at the start of the epoch) + - current `referral_reward_factor` applied to referee taker fees + - current `referral_discount_factor` applied to referee taker fees + - any data required for additional reward metrics The Trades API should now also expose the following additional information for every trade: - Referral program rewards - - `infrastructure_fee_reward` - - `liquidity_fee_reward` - - `maker_fee_reward` + - `infrastructure_fee_reward` + - `liquidity_fee_reward` + - `maker_fee_reward` - Referral program discounts - - `infrastructure_fee_discount` - - `liquidity_fee_discount` - - `maker_fee_discount` + - `infrastructure_fee_discount` + - `liquidity_fee_discount` + - `maker_fee_discount` ## Acceptance Criteria @@ -280,7 +251,7 @@ The Trades API should now also expose the following additional information for e - team member trades should not contribute to their teams volume. - the referrer should not be rewarded for any referee taker fees. - referees should not receive any discount on their taker fees. -1. If the referrer of a team currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the next epoch. +1. If the referrer of a team currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the next epoch. 1. If a party has created a team (i.e. is a referrer) any future liquidity provision transactions from the party should be rejected. @@ -309,22 +280,3 @@ The Trades API should now also expose the following additional information for e 1. A referees `referral_reward_factor` and `referral_discount_factor` is set equal to the factors in the highest benefit tier their team qualifies for. 1. If a referees team does not qualify for the lowest tier, their `referral_reward_factor` and `referral_discount_factor` are both set to `0`. 1. If a referees `referral_reward_factor` or `referral_discount_factor` is set to `0` during an epoch, their factors are not reevaluated until the start of the next epoch. - -#### Applying benefit factors - -1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. - - `infrastructure_fee_discount` - - `liquidity_fee_discount` - - `maker_fee_discount` -1. Referee discounts are correctly calculated and applied for each taker fee component when exiting an auction. - - `infrastructure_fee_discount` - - `liquidity_fee_discount` - - `maker_fee_discount` -1. Referrer rewards are correctly calculated and transferred for each taker fee component during continuous trading. - - `infrastructure_fee_reward` - - `liquidity_fee_reward` - - `maker_fee_reward` -1. Referrer rewards are correctly calculated and transferred for each taker fee component when exiting an auction. - - `infrastructure_fee_reward` - - `liquidity_fee_reward` - - `maker_fee_reward` diff --git a/protocol/0083-VDPR-volume_discount_program.md b/protocol/0083-VDPR-volume_discount_program.md new file mode 100644 index 000000000..6e0239f98 --- /dev/null +++ b/protocol/0083-VDPR-volume_discount_program.md @@ -0,0 +1,139 @@ +# Volume Discount Program + +## Network parameters + +- `volumeDiscountProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a volume discount program +- `volumeDiscountProgram.maxVolumeDiscountFactor` - limits the maximum volume discount factor which can be specified as part of a volume discount program + +## Governance proposals + +Enabling or changing the terms of the volume discount program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: + +- `benefit_tiers`: a list of dictionaries with the following fields + - `minimum_party_running_volume`: the required `running_party_volume` in quantum units for a party to access this tier + - `volume_discount_factor`: the proportion of the referees taker fees to be rewarded to the referrer +- `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled. If this field is empty, the program runs indefinitely. +- `window_length`: the number of epochs over which to evaluate a parties running volume + +```protobuf +message UpdateVolumeDiscountProgram{ + changes: UpdateReferralProgramConfiguration{ + benefit_tiers: [ + { + "minimum_party_running_volume": 1000, + "volume_discount_factor": 0.001, + }, + { + "minimum_party_running_volume": 20000, + "volume_discount_factor": 0.002, + }, + { + "minimum_party_running_volume": 30000, + "volume_discount_factor": 0.003, + }, + ], + closing_timestamp: 123456789, + window_length: 7, + } +} +``` + +When submitting a volume discount program proposal through governance the following conditions apply: + +- a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. +- the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers`. +- all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor`. +- `window_length` must be an integer strictly greater than zero. + +The volume discount program will start the epoch after the `enactment_timestamp` is reached. + +## Volume discount program lifecycle + +After a volume discount program [proposal](#governance-proposals) is validated and accepted by the network, the network volume discount program is created / updated and can be one of the following states. The current state of the network volume discount program should be exposed via an API. + +| Status | Benefits Enabled | Condition for entry | Condition for exit | +| -------------------- | ---------------- | --------------------------------------------------------- | ----------------------------------------------------------------- | +| `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | +| `STATUS_REJECTED` | No | Governance vote fails (or is invalid) | New governance proposal submitted to the network | +| `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | +| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | +| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | + +## Benefit Mechanics + +### Setting benefit factors + +At the start of an epoch the network should calculate each parties `party_running_volume` by summing each parties `party_epoch_volume` [values](./0082-RFPR-on_chain_referral_program.md#party-epoch-volumes) over the last n epochs where n is the `window_length` set in the volume discount program [governance proposal](#governance-proposals). + +Each parties `volume_discount_factor` is then fixed to the value in the highest benefit tier they qualify for. A parties benefit tier is defined as the highest tier for which their `party_running_volume` is greater or equal to the tiers `min_party_running_volume`. If a party does not qualify for any tier, their `volume_discount_factor` is set to `0`. + +```pseudo +Given: + benefit_tiers=[ + { + "min_party_running_volume": 10000, + "volume_discount_factor": 0.001, + }, + { + "min_party_running_volume": 20000, + "volume_discount_factor": 0.005, + }, + { + "min_party_running_volume": 30000, + "volume_discount_factor": 0.010, + }, + ] + +And: + party_running_volume=22353 + +Then: + volume_discount_factor=0.005 +``` + +This benefit factor is then fixed for the duration of the next epoch. + +### Applying benefit factors + +Volume discount program benefit factors are applied by modifying [the fees](./0029-FEES-fees.md) paid by a party (either during continuous trading or on auction exit). + +## APIs + +The Parties API should expose the following information: + +- a list of all **parties** (by `id`) and the following metrics: + - current `party_running_volume` (value at the start of the epoch) + - current `volume_discount_factor` applied to fees + - any data required for additional reward metrics + +The Trades API should now also expose the following additional information for every trade: + +- Volume discount program discounts + - `infrastructure_fee_volume_discount` + - `liquidity_fee_volume_discount` + - `maker_fee_volume_discount` + +## Acceptance Criteria + +### Governance Proposals + +1. If an `UpdateVolumeDiscount` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: + - the `closing_timestamp` must be less than or equal to the proposals `enactment_time`. + - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers`. + - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxReferralRewardFactor`. + - the `window_length` must be an integer strictly greater than zero. +1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached. +1. A volume discount program should be closed the first epoch change after the `closing_timestamp` is reached. +1. If a volume discount program is already active and a proposal `enactment_datetime` is reached, the volume discount program is updated at the next epoch change. + - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec. + - Proposal for program A accepted and begins first epoch after 1st Jan. + - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug. + - Proposal for program B accepted and overrides program A the first epoch after 1st June. + - Program is closed first epoch after 31st Aug, there should be no active proposals. + + +### Setting benefit factors + +1. At the start of an epoch, each parties `volume_discount_factor` is reevaluated and fixed for the epoch. +1. A parties `volume_discount_factor` is set equal to the factors in the highest benefit tier they qualify for. +1. If a party does not qualify for the lowest tier, their `volume_discount_factor`is set to `0`. From c0d4afafe9d5e8b847063eade40ef7787ed70535 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Tue, 25 Jul 2023 13:25:31 +0200 Subject: [PATCH 397/649] fix: correct transaction name Co-authored-by: Jeremy Letang --- protocol/0082-RFPR-on_chain_referral_program.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 78bdfac85..b5379bbd4 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -257,10 +257,10 @@ The Trades API should now also expose the following additional information for e #### Joining / moving teams -1. If a party **is not** currently a **referee**, the party can join a team by submitting a signed `JoinParty` transaction. -1. If a party **is** currently a **referee**, the party can move team (at the start of the next epoch) by submitting a signed `JoinParty` transaction. -1. If a party **is** currently a **referee** and submits multiple `JoinParty` transactions in an epoch, the latest valid `JoinParty` transaction will be applied. -1. If one or more of the following conditions are not met, any `JoinParty` transaction should be rejected. +1. If a party **is not** currently a **referee**, the party can join a team by submitting a signed `JoinTeam` transaction. +1. If a party **is** currently a **referee**, the party can move team (at the start of the next epoch) by submitting a signed `JoinTeam` transaction. +1. If a party **is** currently a **referee** and submits multiple `JoinTeam` transactions in an epoch, the latest valid `JoinTeam` transaction will be applied. +1. If one or more of the following conditions are not met, any `JoinTeam` transaction should be rejected. - a party must not currently be a **referrer**. - party must not have an active liquidity provision. 1. If a party has joined a team (i.e. is a referee) any future liquidity provision transactions from the party should be rejected. From 7145cd1ec7082edd409a80634c73705cbe00dfa5 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Tue, 25 Jul 2023 13:25:56 +0200 Subject: [PATCH 398/649] fix: correct transaction name Co-authored-by: Jeremy Letang --- protocol/0082-RFPR-on_chain_referral_program.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index b5379bbd4..5b93d8395 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -241,9 +241,9 @@ The Trades API should now also expose the following additional information for e #### Creating / updating teams -1. If a party **is not** currently a referrer, the party can **create** a team, by submitting a signed `CreateParty` transaction. -1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `CreateParty` transaction. -1. If one or more of the following conditions are not met, any `CreateParty` transaction should be rejected. +1. If a party **is not** currently a referrer, the party can **create** a team, by submitting a signed `CreateTeam` transaction. +1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `CreateTeam` transaction. +1. If one or more of the following conditions are not met, any `CreateTeam` transaction should be rejected. - party must not currently be a **referee**. - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - party must not have an active liquidity provision. From bf02dc7c871a2dbbc949616bd1d803baf6077b5d Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 25 Jul 2023 14:09:41 +0200 Subject: [PATCH 399/649] feat: add DisbandTeam transaction --- protocol/0082-RFPR-on_chain_referral_program.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 5b93d8395..fe720197c 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -131,7 +131,15 @@ message JoinTeam{ } ``` -If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end of the epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. +If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end of the epoch (after any [team disbandments](#disbanding-a-team) are enacted). Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. + +## Disbanding a team + +If a referrer needs to to disband a `Team` (either to join a team themselves or to become a liquidity provider without creating a new key) they are able to submit a `DisbandTeam` transaction. If a party submits a `DisbandTeam` transaction and is not currently a referrer then the transaction should be rejected. + +If a referrer disbands a team, the transaction is only enacted at the end of the current epoch. Referees are still eligible for discounts for the duration of the current epoch. At the end of the epoch, all referees are disassociated from the team and if they have any pending `JoinTeam` proposals then these are applied. + +Note, once a team disbandment message is submitted and accepted by the network, it cannot be cancelled. ### Party epoch volumes @@ -265,6 +273,13 @@ The Trades API should now also expose the following additional information for e - party must not have an active liquidity provision. 1. If a party has joined a team (i.e. is a referee) any future liquidity provision transactions from the party should be rejected. +#### Disbanding teams + +1. If a party **is** currently a **referrer**, the party can disband a team by submitting a signed `DisbandTeam` transaction. +1. The party will be disbanded at the end of the current epoch at which point all referees and referrers will be disassociated from the team. +1. If a party **is not** currently a **referrer**, they should be able to create a new team after disbanding a team, their `Create` transaction should be accepted (providing it is valid). +1. If a party **is not** currently a **referee**, they should not be able to join a disbanded team, their `JoinTeam` transaction should be rejected. +1. If a party **is** currently a **referee**, they should not be able to move to a disbanded team, their `JoinTeam` transaction should be rejected. #### Team epoch and running volumes 1. Each trade should increment both the maker and taker parties `party_epoch_volume` by the volume of the trade (expressed in quantum units) providing both parties are not members of the same team. From 833148c5e5e54e11cb1ad51c9c592ef2b5a4a483 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 25 Jul 2023 14:59:10 +0200 Subject: [PATCH 400/649] feat: change when JoinTeam transactions processed --- protocol/0082-RFPR-on_chain_referral_program.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index fe720197c..b150f306a 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -131,7 +131,7 @@ message JoinTeam{ } ``` -If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end of the epoch (after any [team disbandments](#disbanding-a-team) are enacted). Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. +If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. ## Disbanding a team @@ -167,7 +167,7 @@ The network can then calculate the teams `team_running_volume` by summing a team ### Setting benefit factors -Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. This is done by identifying a referees team and identifying the teams current benefit tier. A teams benefit tier is defined as the highest tier for which their `team_running_volume` is greater or equal to the tiers `minimum_running_volume`. If a party does not qualify for any tier, both values are set to `0`. +Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `JoinTeam` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. This is done by identifying a referees team and identifying the teams current benefit tier. A teams benefit tier is defined as the highest tier for which their `team_running_volume` is greater or equal to the tiers `minimum_running_volume`. If a party does not qualify for any tier, both values are set to `0`. ```pseudo Given: @@ -280,6 +280,7 @@ The Trades API should now also expose the following additional information for e 1. If a party **is not** currently a **referrer**, they should be able to create a new team after disbanding a team, their `Create` transaction should be accepted (providing it is valid). 1. If a party **is not** currently a **referee**, they should not be able to join a disbanded team, their `JoinTeam` transaction should be rejected. 1. If a party **is** currently a **referee**, they should not be able to move to a disbanded team, their `JoinTeam` transaction should be rejected. + #### Team epoch and running volumes 1. Each trade should increment both the maker and taker parties `party_epoch_volume` by the volume of the trade (expressed in quantum units) providing both parties are not members of the same team. From 92fe6bbdc1f75f05088d01b20c4e8865b2e1acfd Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 26 Jul 2023 13:43:08 +0200 Subject: [PATCH 401/649] feat: add minimum_epochs_in_team requirement --- .../0082-RFPR-on_chain_referral_program.md | 51 +++++++++++++++---- 1 file changed, 42 insertions(+), 9 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index b150f306a..5bd12b8d4 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -27,6 +27,7 @@ Enabling or changing the terms of the on-chain referral program can be proposed - `benefit_tiers`: a list of dictionaries with the following fields - `minimum_running_volume`: the required `running_team_volume` in quantum units for a team to access this tier + - `minimum_epochs_in_team`: the required number of epochs a referee must have been in a team to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted - `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled @@ -38,16 +39,19 @@ message UpdateReferralProgram{ benefit_tiers: [ { "minimum_running_volume": 10000, - "referral_reward_factor": 0.000, - "referral_discount_factor": 0.000, + "minimum_epochs_in_team": 0, + "referral_reward_factor": 0.001, + "referral_discount_factor": 0.001, }, { "minimum_running_volume": 20000, + "minimum_epochs_in_team": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { "minimum_running_volume": 30000, + "minimum_epochs_in_team": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, }, @@ -62,6 +66,7 @@ When submitting a referral program proposal through governance the following con - a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. +- all `minimum_epochs_in_team` values must be an integer strictly greater than 0 - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. @@ -167,23 +172,45 @@ The network can then calculate the teams `team_running_volume` by summing a team ### Setting benefit factors -Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `JoinTeam` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. This is done by identifying a referees team and identifying the teams current benefit tier. A teams benefit tier is defined as the highest tier for which their `team_running_volume` is greater or equal to the tiers `minimum_running_volume`. If a party does not qualify for any tier, both values are set to `0`. +Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `JoinTeam` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. + +#### Setting the referral reward factor + +The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. + +- `team_running_volume` is greater than the tiers `minimum_running_volume`. + +The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. + +#### Setting the referral discount factor + +The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. + +- `team_running_volume` is greater than the tiers `minimum_running_volume`. +- the referee has been a member of the team for more than the tiers `minimum_epochs_in_team`. + +The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. + +#### Example ```pseudo Given: - benefit_tiers=[ + benefit_tiers: [ { "minimum_running_volume": 10000, + "minimum_epochs_in_team": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { "minimum_running_volume": 20000, + "minimum_epochs_in_team": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { "minimum_running_volume": 30000, + "minimum_epochs_in_team": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, }, @@ -191,10 +218,11 @@ Given: And: team_running_volume=22353 + party_epochs_in_team=4 Then: referral_reward_factor=0.005 - referral_discount_factor=0.005 + referral_discount_factor=0.001 ``` These benefit factors are then fixed for the duration of the next epoch. @@ -208,7 +236,9 @@ Referral program benefit factors are applied by modifying [the fees](./0029-FEES The Teams API should expose the following information: -- a list of all **teams** (by `id`), their founding **referrer**, and any current **referees** +- a list of all **teams** (by `id`) and the following information: + - the teams founding **referrer** + - the teams **referees** and their current number of epochs in the team - a list of all **teams** (by `id`) and the following metrics: - current `team_running_volume` (value at the start of the epoch) - current `referral_reward_factor` applied to referee taker fees @@ -233,6 +263,7 @@ The Trades API should now also expose the following additional information for e 1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - the `closing_timestamp` must be less than or equal to the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. + - all `minimum_epochs_in_team` values must be an integer strictly greater than 0. - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - the `window_length` must be an integer strictly greater than zero. @@ -293,6 +324,8 @@ The Trades API should now also expose the following additional information for e #### Setting benefit factors 1. At the start of an epoch, each referees `referral_reward_factor` and `referral_discount_factor` is reevaluated and fixed for the epoch. -1. A referees `referral_reward_factor` and `referral_discount_factor` is set equal to the factors in the highest benefit tier their team qualifies for. -1. If a referees team does not qualify for the lowest tier, their `referral_reward_factor` and `referral_discount_factor` are both set to `0`. -1. If a referees `referral_reward_factor` or `referral_discount_factor` is set to `0` during an epoch, their factors are not reevaluated until the start of the next epoch. +1. At the start of an epoch, a referees `referral_reward_factor` is set equal to the factor in the highest benefit tier they qualify for. +1. At the start of an epoch, a referees `referral_discount_factor` is set equal to the factor in the highest benefit tier they qualify for. +1. If when evaluating the tier to set the `referral_reward_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0`. +1. If when evaluating the tier to set the `referral_discount_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0`. + From c29f6e640998ae45ff43813d41937554e1080c84 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 26 Jul 2023 13:57:18 +0200 Subject: [PATCH 402/649] feat: update API requirements --- protocol/0082-RFPR-on_chain_referral_program.md | 14 ++++++++------ protocol/0083-VDPR-volume_discount_program.md | 2 +- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index 5bd12b8d4..d3c79905e 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -243,18 +243,20 @@ The Teams API should expose the following information: - current `team_running_volume` (value at the start of the epoch) - current `referral_reward_factor` applied to referee taker fees - current `referral_discount_factor` applied to referee taker fees + - the total amount rewarded to the referrer during the referral program + - the total amount discounted for all referees during the referral program - any data required for additional reward metrics The Trades API should now also expose the following additional information for every trade: - Referral program rewards - - `infrastructure_fee_reward` - - `liquidity_fee_reward` - - `maker_fee_reward` + - `infrastructure_fee_referral_reward` + - `liquidity_fee_referral_reward` + - `maker_fee_referral_reward` - Referral program discounts - - `infrastructure_fee_discount` - - `liquidity_fee_discount` - - `maker_fee_discount` + - `infrastructure_fee_referral_discount` + - `liquidity_fee_referral_discount` + - `maker_fee_referral_discount` ## Acceptance Criteria diff --git a/protocol/0083-VDPR-volume_discount_program.md b/protocol/0083-VDPR-volume_discount_program.md index 6e0239f98..383fb55bb 100644 --- a/protocol/0083-VDPR-volume_discount_program.md +++ b/protocol/0083-VDPR-volume_discount_program.md @@ -104,7 +104,7 @@ The Parties API should expose the following information: - a list of all **parties** (by `id`) and the following metrics: - current `party_running_volume` (value at the start of the epoch) - current `volume_discount_factor` applied to fees - - any data required for additional reward metrics + - the total amount discounted for the party The Trades API should now also expose the following additional information for every trade: From 14832b2d4b1db64cb50046ce8a3d318c5d64e228 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 26 Jul 2023 13:58:17 +0200 Subject: [PATCH 403/649] feat: add opt in to rewards --- protocol/0082-RFPR-on_chain_referral_program.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0082-RFPR-on_chain_referral_program.md index d3c79905e..8b282b7dc 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0082-RFPR-on_chain_referral_program.md @@ -104,18 +104,22 @@ The liquidity provision restriction is constant, once a party has become a refer To generate a team id / referral code, the party must submit a signed `CreateTeam` transaction with the following optional team information. +- `enable_rewards`: a boolean value which specifies whether the team should be eligible for team based rewards (spec not started). - `name`: an optional team name to be added to the referral banner. - `teamUrl`: an optional link to a team forum, discord, etc. - `avatarUrl`: an optional url to an image to be used as the teams avatar ```protobuf message CreateTeam + enable_rewards: True, name: "VegaRocks", - teamUrl: https://discord.com/channels/vegarocks - avatarUrl: https://vega-rocks/logo-360x360.jpg + team_url: "https://discord.com/channels/vegarocks" + avatar_url: "https://vega-rocks/logo-360x360.jpg" ``` -If a party which is already a referrer submits a `CreateTeam` transaction, their team metadata is simply updated. +The `name`, `team_url` and `avatar_url` fields are only optional if a party has wishes to enabled rewards for their team. + +If a party which is already a referrer submits a `CreateTeam` transaction, their team data is simply updated. ### Joining / moving teams @@ -289,7 +293,7 @@ The Trades API should now also expose the following additional information for e - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - party must not have an active liquidity provision. 1. If a referrer removes sufficient stake to not meet the required tokens, the referrers team should not be eligible for the following referral program benefits: - - team member trades should not contribute to their teams volume. + - the party should not be eligible for team based rewards (not yet specced) - the referrer should not be rewarded for any referee taker fees. - referees should not receive any discount on their taker fees. 1. If the referrer of a team currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the next epoch. From 62b99950e0d0e8e50ef91de1bf5d3f2993c01a30 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 26 Jul 2023 14:10:38 +0200 Subject: [PATCH 404/649] fix: failing git actions --- ...ferral_program.md => 0083-RFPR-on_chain_referral_program.md} | 2 +- ...discount_program.md => 0084-VDPR-volume_discount_program.md} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename protocol/{0082-RFPR-on_chain_referral_program.md => 0083-RFPR-on_chain_referral_program.md} (99%) rename protocol/{0083-VDPR-volume_discount_program.md => 0084-VDPR-volume_discount_program.md} (100%) diff --git a/protocol/0082-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md similarity index 99% rename from protocol/0082-RFPR-on_chain_referral_program.md rename to protocol/0083-RFPR-on_chain_referral_program.md index 8b282b7dc..d59167207 100644 --- a/protocol/0082-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -293,7 +293,7 @@ The Trades API should now also expose the following additional information for e - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - party must not have an active liquidity provision. 1. If a referrer removes sufficient stake to not meet the required tokens, the referrers team should not be eligible for the following referral program benefits: - - the party should not be eligible for team based rewards (not yet specced) + - the party should not be eligible for team based rewards (spec not started) - the referrer should not be rewarded for any referee taker fees. - referees should not receive any discount on their taker fees. 1. If the referrer of a team currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the next epoch. diff --git a/protocol/0083-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md similarity index 100% rename from protocol/0083-VDPR-volume_discount_program.md rename to protocol/0084-VDPR-volume_discount_program.md From f1d331f9605fb0e461d327c8c42c57a3f8e63c4a Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 26 Jul 2023 15:59:25 +0200 Subject: [PATCH 405/649] fix: update broken links --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index c3c7ce736..f71fefb59 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -23,7 +23,7 @@ Note that maker_fee = 0 if there is no maker, taker relationship between the tra ## Applying benefit factors -Before fees are transferred, if there is an [active referral program](./0082-RFPR-on_chain_referral_program.md) or [volume discount program](./0083-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. +Before fees are transferred, if there is an [active referral program](./0083-RFPR-on_chain_referral_program.md) or [volume discount program](./0084-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. 1. Calculate any referral rewards due to the parties referrer. From 7a4bc7d4c1ccd3728f2c14d3aac218d351327831 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 27 Jul 2023 12:31:42 +0200 Subject: [PATCH 406/649] refactor: clarify tier requirements --- protocol/0083-RFPR-on_chain_referral_program.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index d59167207..2355c1dcd 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -182,7 +182,7 @@ Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pe The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. -- `team_running_volume` is greater than the tiers `minimum_running_volume`. +- `team_running_volume` is greater than or equal to the tiers `minimum_running_volume`. The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. @@ -190,8 +190,8 @@ The referees `referral_reward_factor` is then set to the `referral_reward_factor The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. -- `team_running_volume` is greater than the tiers `minimum_running_volume`. -- the referee has been a member of the team for more than the tiers `minimum_epochs_in_team`. +- `team_running_volume` is greater than or equal to the tiers `minimum_running_volume`. +- the referee has been a member of the team for at least the tiers `minimum_epochs_in_team`. The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. From 1952de2ce19c46983a6a1bf40944946bf470a2c3 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 27 Jul 2023 12:49:25 +0200 Subject: [PATCH 407/649] feat: separate create and update team transactions --- .../0083-RFPR-on_chain_referral_program.md | 37 +++++++++++++++++-- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 2355c1dcd..37a918dbe 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -89,7 +89,7 @@ After a referral program [proposal](#governance-proposals) is validated and acce A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. -### Creating / updating teams +### Creating teams To create a team and generate a referral code, a party must fulfil the following criteria: @@ -119,7 +119,27 @@ message CreateTeam The `name`, `team_url` and `avatar_url` fields are only optional if a party has wishes to enabled rewards for their team. -If a party which is already a referrer submits a `CreateTeam` transaction, their team data is simply updated. +### Updating teams + +If a party is already a referrer, they can update their team by submitting an `UpdateTeam` transaction with the following fields: + +- `team_id`: id of the team to be updated (this must be the id of the team they created) +- `enable_rewards`: a boolean value which specifies whether the team should be eligible for team based rewards (spec not started). +- `name`: an optional team name to be added to the referral banner. +- `teamUrl`: an optional link to a team forum, discord, etc. +- `avatarUrl`: an optional url to an image to be used as the teams avatar + +Note, in an `UpdateTeam` transaction all fields other than `team_id` are optional, if a value is not specified for a field then that field is simply not updated. + +```protobuf +message UpdateTeam + team_id: "abcdefghijklmnopqrstuvqxyz" + name: "VegaRocks2", + team_url: "https://discord.com/channels/vegarocks2" + avatar_url: "https://vega-rocks2/logo-360x360.jpg" +``` + +Note, only the creator of a team can submit an `UpdateTeam` transaction for the team they created. If any other party attempts to submit an `UpdateTeam` message, their transaction should be rejected. ### Joining / moving teams @@ -284,11 +304,11 @@ The Trades API should now also expose the following additional information for e ### Team Mechanics -#### Creating / updating teams +#### Creating teams 1. If a party **is not** currently a referrer, the party can **create** a team, by submitting a signed `CreateTeam` transaction. -1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `CreateTeam` transaction. 1. If one or more of the following conditions are not met, any `CreateTeam` transaction should be rejected. + - party must not currently be a **referrer**. - party must not currently be a **referee**. - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - party must not have an active liquidity provision. @@ -300,6 +320,15 @@ The Trades API should now also expose the following additional information for e 1. If a party has created a team (i.e. is a referrer) any future liquidity provision transactions from the party should be rejected. +#### Updating teams + +1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `UpdateTeam` transaction. +1. If one or more of the following conditions are not met, any `UpdateTeam` transaction should be rejected. + - party does not specify a valid `team_id` + - party is not the creator of the team specified +1. If a party enables rewards for a team, rewards will be enabled at the start of the next epoch. +1. If a party disables rewards for a team, rewards will be disabled at the start of the next epoch. + #### Joining / moving teams 1. If a party **is not** currently a **referee**, the party can join a team by submitting a signed `JoinTeam` transaction. From 18c583a36ca9d28f0365f69bb234bc5d309c69d1 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 28 Jul 2023 13:56:27 +0200 Subject: [PATCH 408/649] feat: api updates --- .../0083-RFPR-on_chain_referral_program.md | 51 +++++++++++++------ 1 file changed, 36 insertions(+), 15 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 37a918dbe..5525ac390 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -258,21 +258,25 @@ Referral program benefit factors are applied by modifying [the fees](./0029-FEES ## APIs -The Teams API should expose the following information: - -- a list of all **teams** (by `id`) and the following information: - - the teams founding **referrer** - - the teams **referees** and their current number of epochs in the team -- a list of all **teams** (by `id`) and the following metrics: - - current `team_running_volume` (value at the start of the epoch) - - current `referral_reward_factor` applied to referee taker fees - - current `referral_discount_factor` applied to referee taker fees - - the total amount rewarded to the referrer during the referral program - - the total amount discounted for all referees during the referral program - - any data required for additional reward metrics - -The Trades API should now also expose the following additional information for every trade: - +The Parties API should now return a list of all **parties** (which can be filtered by party `id`) with the following additional information: +- current team `id` if the party is part of a referral team +- current `epochs_in_team` +- current `party_epoch_volume` +- current `referral_reward_factor` +- current `referral_discount_factor` +- for each asset, the total referral rewards generated by the parties taker fees +- for each asset, the total referral discounts applied to the parties taker fees + +The Teams API should now expose a list of all **teams** (which can be filtered by team `id`) with the following information: +- the teams founding **referrer** +- the teams **referees** +- current `team_running_volume` +- current `referral_reward_factor` applied to referee taker fees +- current **maximum possible** `referral_discount_factor` applied to referee taker fees +- for each asset, the total referral rewards generated by all referee taker fees +- for each asset, the total referral discounts applied to all referee taker fees + +The Trades API should now expose a list of all **trades** (which can be filtered by trade `id`) with the following additional information: - Referral program rewards - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` @@ -281,6 +285,23 @@ The Trades API should now also expose the following additional information for e - `infrastructure_fee_referral_discount` - `liquidity_fee_referral_discount` - `maker_fee_referral_discount` +- Referral program totals + - `total_referral_reward` + - `total_referral_discount` + +The Estimate Fees API should now calculate the following additional information: +- Expected referral program rewards + - `infrastructure_fee_referral_reward` + - `liquidity_fee_referral_reward` + - `maker_fee_referral_reward` +- Expected referral program discounts + - `infrastructure_fee_referral_discount` + - `liquidity_fee_referral_discount` + - `maker_fee_referral_discount` +- Expected referral program totals + - `total_referral_reward` + - `total_referral_discount` + ## Acceptance Criteria From 98192056f2348ece1549117114bd805e33294ba0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 31 Jul 2023 15:22:56 +0100 Subject: [PATCH 409/649] feat: clarify referral sets and teams --- protocol/0029-FEES-fees.md | 2 +- .../0083-RFPR-on_chain_referral_program.md | 253 ++++++++++-------- ...eferral_program_referral_set_hierarchy.png | Bin 0 -> 15897 bytes wordlist.txt | 1 + 4 files changed, 137 insertions(+), 119 deletions(-) create mode 100644 protocol/0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index f71fefb59..04cf60ab4 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -23,7 +23,7 @@ Note that maker_fee = 0 if there is no maker, taker relationship between the tra ## Applying benefit factors -Before fees are transferred, if there is an [active referral program](./0083-RFPR-on_chain_referral_program.md) or [volume discount program](./0084-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. +Before fees are transferred, if there is an [active referral program](./0083-RFPR-on_chain_referral_program.md) or [volume discount program](./0085-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. 1. Calculate any referral rewards due to the parties referrer. diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 5525ac390..ee522f8dd 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -4,14 +4,25 @@ The aim of the on-chain referral program is to allow users of the protocol to incentivise users and community members to refer new traders by voting to provide benefits for referrers and/or referees. -Whilst a referral program is active, the following benefits may be available to eligible parties: +A party will be able to [create a referral code](#creating-a-referral-set) and share this code with referees. Referees who [apply the code](#applying-a-referral-code) will be added to the referrers "referral set". -- a **referrer** will receive a proportion of all referee taker fees as a **reward**. -- a **referee** will be eligible for a **discount** on any taker fees they incur. +Whilst a referral program is active, the following benefits may be available to members of a referral set: -The size of the reward or discount will be dependent on the benefit tier the referee's [team](#team-mechanics) is currently placed in. A team becomes eligible for greater benefits by reaching a minimum running volume over a number of epochs. Both referrers and referees contribute to their team's running volume. +- a **referrer** may receive a proportion of all referee taker fees as a **reward**. +- a **referee** may be eligible for a **discount** on any taker fees they incur. -On-chain referral programs can be created and updated through [governance proposals](#governance-proposals). +Providing a party has been associated with a referral set for long enough, they will become eligible for greater benefits as their referral sets running trading volume increases. + +To create an emphasis on community, collaboration, and competition. Referrers will be able to designate their referral set as a team. Teams will have additional fields which allow them to be visible on leaderboards and later to compete for team based rewards. + +![referral-set-hierarchy-diagram](./0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png) + +## Glossary + +- `referrer`: a party who has generated a referral code for a referral set +- `referee`: a party who has applied a referral code to join a referral set +- `referral_set`: a group comprised of a single referrer and all their referees +- `team`: a `referral_set` which has been designated as a team and enriched with additional details allowing it to be visible on leaderboards. ## Network Parameters @@ -19,19 +30,19 @@ On-chain referral programs can be created and updated through [governance propos - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal - `referralProgram.maxPartyVolumePerEpoch` - limits the volume in quantum units which is eligible each epoch for referral program mechanisms -- `referralProgram.minStakedVegaTokens` - limits team creation to parties staking at least this number of tokens +- `referralProgram.minStakedVegaTokens` - limits referral code generation to parties staking at least this number of tokens ## Governance Proposals Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: - `benefit_tiers`: a list of dictionaries with the following fields - - `minimum_running_volume`: the required `running_team_volume` in quantum units for a team to access this tier - - `minimum_epochs_in_team`: the required number of epochs a referee must have been in a team to access this tier + - `minimum_running_volume`: the required [`referral_set_running_volume`](#referral-set-volumes) in quantum units for parties to access this tier + - `minimum_epochs`: the required number of epochs a party must have been in a referral set to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted - `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled -- `window_length`: the number of epochs over which to evaluate a teams running volume +- `window_length`: the number of epochs over which to evaluate a referral sets running volume ```protobuf message UpdateReferralProgram{ @@ -39,19 +50,19 @@ message UpdateReferralProgram{ benefit_tiers: [ { "minimum_running_volume": 10000, - "minimum_epochs_in_team": 0, + "minimum_epochs": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { "minimum_running_volume": 20000, - "minimum_epochs_in_team": 7, + "minimum_epochs": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { "minimum_running_volume": 30000, - "minimum_epochs_in_team": 31, + "minimum_epochs": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, }, @@ -66,7 +77,7 @@ When submitting a referral program proposal through governance the following con - a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. -- all `minimum_epochs_in_team` values must be an integer strictly greater than 0 +- all `minimum_epochs` values must be an integer strictly greater than 0 - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. @@ -85,94 +96,106 @@ After a referral program [proposal](#governance-proposals) is validated and acce | `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | | `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | -## Team Mechanics +## Referral set mechanics -A team is comprised of a referrer and all their referees. There can only ever be one referrer per team but the number of referees is unlimited. +A referral set is comprised of a referrer and all the referees who have applied the associated referral code. There can only ever be one referrer per referral set but the number of referees is unlimited. Referees can move between referral sets by applying a new referral code. -### Creating teams +### Creating a referral set -To create a team and generate a referral code, a party must fulfil the following criteria: +To create a new referral set and become a referrer, a party must fulfil the following criteria: - party must not currently be a **referrer** - party must not currently be a **referee** -- party must be staking at least `referralProgram.minStakedVegaTokens` tokens. +- party must be staking at least `referralProgram.minStakedVegaTokens` tokens - party must not have an active liquidity provision -The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will no long be eligible for program benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, the team will become eligible for referral program benefits. Note, referees will be able to "move team" by submitting a new team. +The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will immediately no longer be eligible for referral benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, they and their referees will become eligible for referral benefits **at the start of the next epoch**. Note, for the case where a party does not re-stake, the protocol will allow referees will to "move" referral sets by [applying](#applying-a-referral-code) a new referral code. The liquidity provision restriction is constant, once a party has become a referrer they will be restricted from committing liquidity. Any liquidity provision transactions from a referrer should be rejected. -To generate a team id / referral code, the party must submit a signed `CreateTeam` transaction with the following optional team information. +To create a referral set and generate a referral code, the party must submit a signed `CreateReferralSet` transaction. When creating a referral set, a party can optionally designate it as a [team](#glossary) and provide additional team details. When designated as a team a referral set will be visible on leaderboards and in future releases will be eligible for team rewards. A `CreateReferralSet` transaction has the following fields: + +- `is_team`: a boolean defining whether the referral set should be designated as a team +- `team_details`: an optional dictionary defining the teams details (non-optional if `is_team` is `True`) + - `name`: mandatory str team name + - `team_url`: mandatory str of a link to a team forum, discord, etc. + - `avatar_url`: mandatory str of a link to an image to be used as the teams avatar + +*Example: if party wants to create a simple referral set.* -- `enable_rewards`: a boolean value which specifies whether the team should be eligible for team based rewards (spec not started). -- `name`: an optional team name to be added to the referral banner. -- `teamUrl`: an optional link to a team forum, discord, etc. -- `avatarUrl`: an optional url to an image to be used as the teams avatar +```protobuf +message CreateReferralSet + is_team: False + team_details: None +``` + +*Example: if party wants to create a referral set and designate it as a team.* ```protobuf -message CreateTeam - enable_rewards: True, - name: "VegaRocks", - team_url: "https://discord.com/channels/vegarocks" - avatar_url: "https://vega-rocks/logo-360x360.jpg" +message CreateReferralSet + is_team: True + team_details: { + name: "VegaRocks", + team_url: "https://discord.com/channels/vegarocks" + avatar_url: "https://vega-rocks/logo-360x360.jpg" + } ``` -The `name`, `team_url` and `avatar_url` fields are only optional if a party has wishes to enabled rewards for their team. +When the network receives a valid `CreateReferralSet` transaction, the network will create a referral set with the referral set `id` as the referral code. Any future parties who [apply](#applying-a-referral-code) the referral code will be added to the referral set. + +### Updating a referral set -### Updating teams +There are two cases where a referrer may want to update their referral set: -If a party is already a referrer, they can update their team by submitting an `UpdateTeam` transaction with the following fields: +- they want to designate their `referral_set` as a team +- their `referral_set` is already designated as a team and they want to update their `team_details`. -- `team_id`: id of the team to be updated (this must be the id of the team they created) -- `enable_rewards`: a boolean value which specifies whether the team should be eligible for team based rewards (spec not started). -- `name`: an optional team name to be added to the referral banner. -- `teamUrl`: an optional link to a team forum, discord, etc. -- `avatarUrl`: an optional url to an image to be used as the teams avatar +To update a referral set the party submit a signed `UpdateReferralSet` transaction. For the transaction to be valid, the party must be the referrer associated with the referral set. An `UpdateReferralSet` transaction must have the following fields. -Note, in an `UpdateTeam` transaction all fields other than `team_id` are optional, if a value is not specified for a field then that field is simply not updated. +- `id`: id of the referral set to update +- `is_team`: a boolean defining whether the party should made into a team visible on leaderboards +- `team_details`: an optional dictionary defining the team + - `name`: optional str team name + - `team_url`: optional str of a link to a team forum, discord, etc. + - `avatar_url`: optional str of a link to an image to be used as the teams avatar ```protobuf -message UpdateTeam - team_id: "abcdefghijklmnopqrstuvqxyz" - name: "VegaRocks2", - team_url: "https://discord.com/channels/vegarocks2" - avatar_url: "https://vega-rocks2/logo-360x360.jpg" +message UpdateReferralSet + id: "mYr3f3rra15et1d" + is_team: True + team_details: { + name: "VegaRocks", + team_url: "https://discord.com/channels/vegarocks" + avatar_url: "https://vega-rocks/logo-360x360.jpg" + } ``` -Note, only the creator of a team can submit an `UpdateTeam` transaction for the team they created. If any other party attempts to submit an `UpdateTeam` message, their transaction should be rejected. +If a referral set is currently designated as a team, a party is able to effectively "disband" a team by updating their referral set and setting their `is_team` value to `False`. Note a team should only be "disbanded" and removed from leaderboards at the end of the current epoch after rewards have been distributed. -### Joining / moving teams +### Applying a referral code -To join a team the party must fulfil the following criteria: +To apply a referral code and become a referee, a party must fulfil the following criteria: - party must not currently be a **referrer** - party must not have an active liquidity provision The liquidity provision restriction is constant, once a party has become a referee they will be restricted from committing liquidity. Any liquidity provision transactions from a referee should be rejected. -To become a referee, a referee must submit a signed `JoinTeam` transaction with the following fields: +To become a referee, a referee must submit a signed `ApplyReferralCode` transaction with the following fields: -- `id`: the id of the team they want to join (same as the referral code) +- `referral_code`: the referral code they wish to apply ```protobuf -message JoinTeam{ - id: "abcd3fgh1jklmn0pqf5tuvwzyz" +message ApplyReferralCode{ + id: "mYr3f3rra1c0d3" } ``` -If a party is already a referee, and submits another `JoinTeam` transaction, their membership will be transferred to the new team at the end start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be transferred using the latest valid transaction. +If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors updated](#setting-benefit-factors) accordingly. If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will be transferred to the new referral set at the start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be associated with the set specified in the latest valid transaction. -## Disbanding a team +### Party volumes -If a referrer needs to to disband a `Team` (either to join a team themselves or to become a liquidity provider without creating a new key) they are able to submit a `DisbandTeam` transaction. If a party submits a `DisbandTeam` transaction and is not currently a referrer then the transaction should be rejected. - -If a referrer disbands a team, the transaction is only enacted at the end of the current epoch. Referees are still eligible for discounts for the duration of the current epoch. At the end of the epoch, all referees are disassociated from the team and if they have any pending `JoinTeam` proposals then these are applied. - -Note, once a team disbandment message is submitted and accepted by the network, it cannot be cancelled. - -### Party epoch volumes - -Whilst a referral program or [volume discount program](./0083-VDPR-volume_discount_program.md) is `STATUS_ACTIVE`, the network must track the cumulative volume of trades for each party in that epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). +The network must now track the cumulative volume of trades for each party in an epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo party_epoch_volume = party_epoch_volume + (trade_price * trade_size * settlement_asset_quantum) @@ -180,29 +203,29 @@ party_epoch_volume = party_epoch_volume + (trade_price * trade_size * settlement At the end of an epoch, the `party_epoch_value` is stored by the network and each parties `party_epoch_value` is reset to `0` ready for the next epoch. -### Team epoch and running volumes +### Referral set volumes -At the end of an epoch, for each team, a `team_epoch_volume` is calculated by summing each team members `party_epoch_volume`. The amount a party can contribute to their teams volume however is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. (Note this cap should not be directly to `party_epoch_volume` in case the network parameter is updated during an epoch). +At the end of an epoch, for each referral set, a `referral_set_epoch_volume` is calculated by summing the `party_epoch_volume` of each party in the referral set (include both referrers and referees). The amount a party can contribute to their referral set is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. Note this cap is not applied directly to `party_epoch_volume` in case the network parameter is updated during an epoch. ```pseudo -team_epoch_volume = sum[min(party_epoch_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] +referral_set_epoch_volume = sum[min(party_epoch_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] ``` -After the values are calculated, the `team_epoch_volume` is stored by the network. +After the values are calculated, the `referral_set_epoch_volume` is stored by the network. -The network can then calculate the teams `team_running_volume` by summing a teams `team_epoch_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). +The network can then calculate the sets `referral_set_running_volume` by summing the sets `referral_set_epoch_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). ## Benefit mechanics ### Setting benefit factors -Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `JoinTeam` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. +Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `ApplyReferralCode` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. #### Setting the referral reward factor The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. -- `team_running_volume` is greater than or equal to the tiers `minimum_running_volume`. +- `referee_set_running_volume` is greater than or equal to the tiers `minimum_running_volume`. The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. @@ -210,8 +233,8 @@ The referees `referral_reward_factor` is then set to the `referral_reward_factor The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. -- `team_running_volume` is greater than or equal to the tiers `minimum_running_volume`. -- the referee has been a member of the team for at least the tiers `minimum_epochs_in_team`. +- `referral_set_running_volume` is greater than or equal to the tiers `minimum_running_volume`. +- the referee has been a associated with the referral set for at least the tiers `minimum_epochs`. The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. @@ -222,27 +245,27 @@ Given: benefit_tiers: [ { "minimum_running_volume": 10000, - "minimum_epochs_in_team": 0, + "minimum_epochs": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { "minimum_running_volume": 20000, - "minimum_epochs_in_team": 7, + "minimum_epochs": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { "minimum_running_volume": 30000, - "minimum_epochs_in_team": 31, + "minimum_epochs": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, }, ] And: - team_running_volume=22353 - party_epochs_in_team=4 + referral_set_running_volume=22353 + party_epochs_in_referral_set=4 Then: referral_reward_factor=0.005 @@ -259,24 +282,29 @@ Referral program benefit factors are applied by modifying [the fees](./0029-FEES ## APIs The Parties API should now return a list of all **parties** (which can be filtered by party `id`) with the following additional information: -- current team `id` if the party is part of a referral team -- current `epochs_in_team` + +- current `id` of the referral set the party is associated with +- current `epochs_in_referral_set` - current `party_epoch_volume` - current `referral_reward_factor` - current `referral_discount_factor` - for each asset, the total referral rewards generated by the parties taker fees - for each asset, the total referral discounts applied to the parties taker fees -The Teams API should now expose a list of all **teams** (which can be filtered by team `id`) with the following information: -- the teams founding **referrer** -- the teams **referees** -- current `team_running_volume` +The ReferralSet API should now expose a list of all **referral sets** (which can be filtered by referral set `id`) with the following information: + +- the sets founding **referrer** +- the sets **referees** +- current `referral_set_running_volume` - current `referral_reward_factor` applied to referee taker fees - current **maximum possible** `referral_discount_factor` applied to referee taker fees - for each asset, the total referral rewards generated by all referee taker fees - for each asset, the total referral discounts applied to all referee taker fees +- whether the referral set has been designated as a team +- any `team_details` if the referral set has been designated as a team. The Trades API should now expose a list of all **trades** (which can be filtered by trade `id`) with the following additional information: + - Referral program rewards - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` @@ -290,6 +318,7 @@ The Trades API should now expose a list of all **trades** (which can be filtered - `total_referral_discount` The Estimate Fees API should now calculate the following additional information: + - Expected referral program rewards - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` @@ -323,57 +352,45 @@ The Estimate Fees API should now calculate the following additional information: - Proposal for program B accepted and overrides program A the first epoch after 1st June. - Program is closed first epoch after 31st Aug, there should be no active proposals. -### Team Mechanics +### Referral set mechanics -#### Creating teams +#### Creating a referral set -1. If a party **is not** currently a referrer, the party can **create** a team, by submitting a signed `CreateTeam` transaction. -1. If one or more of the following conditions are not met, any `CreateTeam` transaction should be rejected. - - party must not currently be a **referrer**. +1. If a party **is not** currently a referrer, the party can **create** a referral set, by submitting a signed `CreateReferralSet` transaction. +1. If one or more of the following conditions are not met, any `CreateReferralCode` transaction should be rejected. + - party must not currently be a **referrer**.CreateReferralSet - party must not currently be a **referee**. - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - party must not have an active liquidity provision. -1. If a referrer removes sufficient stake to not meet the required tokens, the referrers team should not be eligible for the following referral program benefits: - - the party should not be eligible for team based rewards (spec not started) +1. If a referrer removes sufficient stake to not meet the required tokens, the referral set should not be eligible for the following referral benefits: - the referrer should not be rewarded for any referee taker fees. - - referees should not receive any discount on their taker fees. -1. If the referrer of a team currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the next epoch. - -1. If a party has created a team (i.e. is a referrer) any future liquidity provision transactions from the party should be rejected. + - all referees should not receive any discount on their taker fees. +1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch. +1. If a party has created a referral code any future liquidity provision transactions from the party should be rejected. +1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory. -#### Updating teams +#### Updating a referral set -1. If a party **is** currently a referrer, the party can **update** a team, by submitting a signed `UpdateTeam` transaction. -1. If one or more of the following conditions are not met, any `UpdateTeam` transaction should be rejected. - - party does not specify a valid `team_id` - - party is not the creator of the team specified -1. If a party enables rewards for a team, rewards will be enabled at the start of the next epoch. -1. If a party disables rewards for a team, rewards will be disabled at the start of the next epoch. +1. If a party is currently a referrer, the party can **update** a referral set by submitting a signed `UpdateReferralSet` transaction. +1. If a party submits an `UpdateReferralSet` transaction for a referral set they are not the referrer off, the transaction should be rejected. +1. When updating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory. -#### Joining / moving teams +#### Applying a referral code -1. If a party **is not** currently a **referee**, the party can join a team by submitting a signed `JoinTeam` transaction. -1. If a party **is** currently a **referee**, the party can move team (at the start of the next epoch) by submitting a signed `JoinTeam` transaction. -1. If a party **is** currently a **referee** and submits multiple `JoinTeam` transactions in an epoch, the latest valid `JoinTeam` transaction will be applied. -1. If one or more of the following conditions are not met, any `JoinTeam` transaction should be rejected. +1. If a party **is not** currently a **referee**, the party can immediately become associated with a referral set by submitting a signed `ApplyReferralCode` transaction. +1. If a party **is** currently a **referee**, the party can become associated with a new referral set (at the start of the next epoch) by submitting a signed `ApplyReferralCode` transaction. +1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied. +1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected. - a party must not currently be a **referrer**. - party must not have an active liquidity provision. -1. If a party has joined a team (i.e. is a referee) any future liquidity provision transactions from the party should be rejected. - -#### Disbanding teams - -1. If a party **is** currently a **referrer**, the party can disband a team by submitting a signed `DisbandTeam` transaction. -1. The party will be disbanded at the end of the current epoch at which point all referees and referrers will be disassociated from the team. -1. If a party **is not** currently a **referrer**, they should be able to create a new team after disbanding a team, their `Create` transaction should be accepted (providing it is valid). -1. If a party **is not** currently a **referee**, they should not be able to join a disbanded team, their `JoinTeam` transaction should be rejected. -1. If a party **is** currently a **referee**, they should not be able to move to a disbanded team, their `JoinTeam` transaction should be rejected. +1. If a party is associated with a referral set any future liquidity provision transactions from the party should be rejected. -#### Team epoch and running volumes +#### Epoch and running volumes -1. Each trade should increment both the maker and taker parties `party_epoch_volume` by the volume of the trade (expressed in quantum units) providing both parties are not members of the same team. -1. At the end of the epoch, the `team_epoch_volume` should be calculated by summing each team members `party_epoch_volume`. -1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their teams `team_epoch_volume`. -1. A teams `team_running_volume` is calculated as the sum of all `team_epoch_volumes` over the last `epoch_window` epochs. +1. Each trade should increment both the maker and taker parties `party_epoch_volume` by the volume of the trade (expressed in quantum units). +1. At the end of the epoch, the `referral_set_epoch_volume` should be correctly calculated by summing each team members `party_epoch_volume`. +1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their sets `referral_set_epoch_volume`. +1. A referral sets `referral_set_running_volume` is calculated as the sum of all `referral_set_epoch_volumes` over the last `epoch_window` epochs. ### Benefit Mechanics diff --git a/protocol/0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png b/protocol/0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png new file mode 100644 index 0000000000000000000000000000000000000000..5430d02acb9f4ad4c3e9748bf3eafcc47359ef6c GIT binary patch literal 15897 zcmZvD1z1#V*EJx*NDc$iT_W8Ll0zfi-8FQVf`mgzNrQyaAxKDxbO-_>Al=d;DUILF z`#kS=egAd+a4|C+4rk6ebML*^UTbZnhPnbS7C9CQ3JR{0qMR0ZKD_&ZV1P&RAN!HT*1{+~xh$6$ApU)Rlx) zJ$OC19X&m`4VB;qGA?RPGEeOdM1)<`9c1K{0u2mYJ^h53c)^W@%Lp2IDf;X2AVl;m z{gqsKb>;nh6|FrKt%Q|@?E)R2dTVLGJ)G4v9eC_C)tnujt$8gqrNPaF+w<7C>*{N0 zC@BZHs5rX7mE8;s17&q>H3c0M5pXpXJ%l6af0ar~2LlaTV5c^A$AI*MUFPkqPv+_vh7+ z^$Fl}lGW$+w{+n#6hzoN2x@pqdujxzs%ttaJIGkNsXM7E84Bogy9@ZrE2(RH%5XbK z!+Ch^4B*n-BJR%m`a**GfqvEso_cU29)yd5yt<~Bs;s)6s)MbgimsqMcyoI#b-0U> zf*Rb(z*$3A+D*yzshyiFzo${4qmiz#j=zkwp;w@xf`E}fx3-X@oR_Aux-|GVBRLyK z5hWpQJ3(nJ6-_=~JxgyTRYzqn4K@3x-U`kE{xSwO`oah+FFh|cSrI)4K`$LYk$|Ux z+RCncu9|w*+@7kMd;yAne9m^xHu`WYa7Yjra8+eHIk=;%kW-+n9WOXNxV$oWkP{J* z))4ZPgYyMEHL&wj1e@%1HNYYSFaEm@|FbB;@BfB5pL}Dc?IRQvS`;NYX&ryFU#1TX zUQgaicGQUOagTJoeD3hE<{4*ET3VLMhL+-LR`NzNn?qDl0Mewo5NYG!WVH40Ar23p zhYFiO1CDW}G5uR^Y#cG1dtKbud1tM!^dIDeJlPDWRM@;4xyU`sITPEw9&z)atv9%b z)*g{K5&@N@V|@A5F1o3u#n-CVK)gt6yF`ceQ+9T?7z+{BS#dG*kBtqxG_5jkE!Nam z=%MrHsZ zqgW(>Vl&DsI_3*48r(79vwyUPCBd53+wv;NT+I*1>_LLc2uW zRa#nl1QivvXK5+#{QMls#lj?cr>lO7Kb?_E(*B)^bQ3OLR2 zu`#K2Pm!{U3I+iIfp_KQF|X6pQ$Bp)rB71K!otR;a9wCAVqs7IQ{Y7+&(oeE%5yEl2}+w z%=}?&ZwZ7>e?NK7q;M9|`nso>;<8;*QnGttVL?GhPfv1XZSDK~d-Er~9bxxE0?+n; zO}|yZU)|nz6m>jtDQj#@GimjWH~AE(8?Zm$yfc)}C8n#ZD{^shal@WIQ@jA^7oHBIX#Vk%*FM4Xzh?Z8i#E4pbMMJ|H<(%A0rE-)n<;> zsy4%<%|9te*rV`rIFpY9hV1EGTKem0XlS^RE9UoVNy2(guY@CC=ygvNRfL%dr=O>n zmzPdRNXS?so$UIzZ{KcZqj2atJ3FHggIG?4NV#=z7)CL%)>ZJl55BDI?KdfF4RWL* z7lT+W77yvQV7pILCC-CycRicMXM1}i!FpPN5fZLRIE>NWI5*akkK~FefSX?ap{|aK zf`Y=9nwok>rof$qZapjBXY$=b0pk>|D`#|f=H&P|Oa-!{n!#NV@a6Sm$(zg5?^S|g z!Mo!{DmF{)A(NQ+)I997?&qYP~nhE{+U{9g^QK$=ugci`vCrR8*z}G&D40pPxOeVrB|4@I&V`X_69jTQo__&HdHCd0Yn; zul~27t;WN5jJIN(H?lG^db&C~C)q-7X4WPqIUhO9Ft^pYzPBTtD<&o;cB+g&wwzyF zn6k37n99)z;~!jX>?;jMn3_R*a6pKaRbhJMS2fmGX%I#xrpZdv)+q^L;q!bcS_2!m zS(jFNj}rAJg+GfO#((ncfNmrdm8%ZSv(M2+@me?t>GIywa8<>j6C z?(+xH9UfESZLU?DwqCv~F2?w?zc6Rk_hbJu;B-e9Mna;Wm6vC(tEF{>LAUN~jM+J* zv`0ov+}PUE64+C$mOXD}ZEe^nnP30xuRIEzK_!j7dF|J)TsA1g4l3h>cu0}WRGX0S z)Wyr|c*A3@PoSiz=t3Kt%{aH~*BLgk1vW7|%g~oER?SUKJ?ZJ`C3Eyxjfz&E$Hp|8 zT25!0y-K(m5RJW#6{dL>*%HoE>^)emp1V_3gAs{Xznp6JN)RzUW@cuDsmee5zZa`% zTbwqyY?XNz!!0_)??2q$-mY2BWJnpr%W4U+Zm{QL#KXs5;z}P<2)*1cF=K$oaTA-> zo3Sa-3JImF=1G3)>+W8w2oDce(p#j02OHCRxZy>oTkI0>$e1ZtXNb!} zOKPSNNC7Hx^aLivd~Oudo>FpAbf7W<9srdgOr32M6a5Cm+aRAhhLsdwXeYY;1&k zdU`Yz%-J5r6~*LbW+L;WIZQau)IdNN6nzQ!Y@#QYL=_BTB%D=X3B5)zmj8ygtz%_b`SDPQavAVef2 zDFh7g*OOCIq1qZ6+#|`Yw%-^*u0Eatg-8C4um?SK=Ek7_k^w`tNuiVsZaV3Ur}zwV zR8Y<1xv63f6jz_b|~KwxJdQc^-V?$fej$}fka z!(cGh@87?(6=^+&xf!A-aYXjCQ;GRrTh7)y($>)A3KF5Jz)|ED>+GM(D=7_Xr`0qx zqQhE`{o5)CnN_zkl9Oc~xD3{%fAPgfb*aLq7H3ISWQ0uH>Di{wC{a>U2K!8uYSQT- z<;koN5UClTz3Ez+Bt@I4fmk~xp8c?^(_Ip!_eqtAORWH1$nxbjNbEnp1|+x$!n$E> z;^Nmc04{iJz0QXi@S%YOmO@NK6l~8q#95a}+BgQHC*}C)2(6SUP2j0Hs~GgTt^Vj6 zi6JK^C*EO8XM`uLn?k8Tqw>qp&~aho*lYC0a1@uSpg((t-Bz`FS+iGz6O5s6daZKL zZ?AqEPEZW$6?6TH#zOUfB5`x_9V=4iF#PdNlA6-$h>PIW=0dAqUD*@v-1Ej5ly1cyHTU}kv_V@busX6(?$evd$ zmIXaJH28Ot0(DuN*X9VTb#%9YAkuR1hym}Kzp@f(hmYv9f=UU`w_=&}yyi7}9{4sn zqkCmuRaJF;BwHu}!}nuGnf!eoCNzjf-s{&o?5WDFq!p%blSrGBKv@)72XV>I8(j-e zm~wsyiK7sz<_CBpuGaGjS!BKwHZiFb`%U0 zZ+R5=`t9nlK|ODC^p#;4!7*ykrF-rY$HT)j$(zYOKX#FXtG+rmHnzr~@G3ZF1GBMQ z1Rg1XiZ+lC3|0dT2p`+A`Bn_3+RvY#RhE?4$4JrUulT5PKXxFTik31kFt9}+eytuI z9eK+txhcYe0s{ky?d*OnvY-h@c5HtyQS$co)kAMH3oyKA8Tk-DQ zyX^MV9ksg;@L@qgfyd@(UJ0D)@)btNQZFMbdsHZ6jzc;f7 zDBWdbe0C>Fs;VdBMV6O%^3UlH%+ZsRlbw8jFNPG=)VODGW^5_1-h!`YTU%QfQ}UwU z8t5!&`1DXHl$MQ)D_UgZKBD#;vL{&b?<$DZpq}2|X6HHDkT>)P+~|z32N%CSE)9U# zkat~dQv%55!EIH2{cC`LlUrIuJvT?Fn5X!x(m(-D#-kF2nwy)$NJ$m_#i<`WctB^` z;!U^E;==#}&Hnc5xC#j48<0fbKZxwIuTRw_f#I)uHYw zeO$l#{rQo8wFzB(d_2zK?P0<*ZaH+i7vbTM=x#ay!y~@h@%8w4dowB*CDYZbGBW^h zEytP)t2G#g($GBrd%gK&7_$>V)syY-m@77eUZWBUmw$daCoy!c9XbJ+V~OIaPJ!CM z%#%0z_ZD2@zR0uNV0{F6;iwk+a}>q&loZ+a>mwDkv$o}BiztJet26tT#KgpQ?)m6w zsK;SV?ki}=olvA4y6cCx3JJ`bnwrB3oiJr1quE@a-Kn1sB4rqPel$6#tlk1RVji4i=%{8|qb2)>tNlE@gU<5${LtoT zeK1aZgA*k0N>JFLa%*+9dW?7v9$W;jbVY`wbDAn!+hqpTSLNSiWs!dfx$^zs{DX62 zSk(3l5wB$z`o^BqzPoc2;r3YVA=v%#{;ct&Gyf2v$Ni-CCe~+o_FMQ*t`jd(5)-8s12(Brs)vWtI4UIFm!(`SEm!2!F3TSy zLqNMR6cZCeS@8H>B>fmUs_OZ>cZ_ze*MH{RvVT@OZ)tYU1b}5W>?_8@lXSt7St!-L zSf>4`NUJR3u}x8npa8vxhQ`>{(1*G=f4{!16?wbX7$n!Q0Bg?Dn zS?Bj;)mGS5+jXOo){Q?jLc@mp*oE^F$oPtzK77!sDvDudq`sN9P6+Y6x%6qlqVSri zEZxrwy+jU!OfDxUm-zZMQS7)N1qIxpj)coh_2~F`aH`5!33RP-QveOw^#1<*ms$mK zaby`^$^=&Hlh)viqgzlnd<3)V>#ZuJQD%)zI$h=(<1apcA~wnWnk$yxEc4>e0_o4S zgeR^>b#`Cx7ib6@(7?P5+4VHl)No__MtJ+U4fS&YJf;JYEpP!Kl*`dx#V?2DN^!3Z z)uZd<(G<08LC33>*-e7jp`js_0u2^X0-2b(pp^nPp6G5v5%=Yerr}}LmQ+3L=3kO1 z+Jj0d%mmYzdoy*>WB8YU`^e?81rg+(H~Y6YSGcZSBB9skM{eyG%(|?p)#J#Xu&}TT zGBPq#2TI2|rqY%-o$l749gj2R8~I#cACEFJSTic=y_G19D`!D08gR6pT~t&=(304s zU}3TRQLF6rtkT@}Fb4|@E!XF3UTdEQ&!5U-^3uny?~NK_YX69Ou0vp@j<jqsYv}2uJ_f^4S0r|Ym#60+tjMlNqonE4(Wl;^%H@aNTxL>`%(f#5I*0?$4_1a3 zxR`4GEWa3N(v}Q3dMDjD1tOIGEj%8kucJfDy0N4j#OA@pnI4oTdh7h;`P41OYlE@I zuB9~B0v{SRm#P&mTtqwFb?R>noDSXZPpgWYQhLOxf4``;?r(pSmIlwI@}^O!2<8(N z&GO!#&t$E|;SSXBU1$%Tv$k-oSJGYA!FS14%BjYyRj?ki}_|R4erLWB3Eao{b9Shzok`GMbZcC!QrG@ z;w;wV4k*+dI3`*8Onlu@#4j2 zvsT|<76t`lRy2@h46DnNZC?a7VlOEw{UrH`4ts+VcMr4 zCQdWf(2&9v9~NIOcA&<);Vx?ny=gIRCd@*cYn**fVQpi>Xq{E&Y!L>K9c!4>b5(+L zU4(cI?CSiyG7gCh@B+B}#A(ok0nz14u#QS>_-A>{O~!y`mMBgtUoPVNXHMIxO2f%$ zJgUq5^75TGvOV`0@vyL360@={aoR`frv=eoB7IhS9(e9e^UUp+-v8qYu=IK)iP_j= zI}*LarlzJ?tJ-t3^D#`ty^Rg#)_`L>Omdu2G=;_I^mMFDg&N^KIur;g3xP^3Bd0`C zO@W4Zw|Lq>P-e@V9UPj{hYvzw3ZBjLu@e(o-AOg8{rSV?)zx-gLt|Fd=+MQ1xjExU zOg~HsRT<5!kI0suu5N?6MS)Kvxo7{z^_!kr7)lPsd9Y+1Rt7_4%;QT3Tm&s8r?0F` zfrj%VWNB&X7XbJ=8uq?pDuN#H4-+G!>dStI zDw1kF0KH>0*#a)(XA~|4UQF-mAbz4SH}}Dlyl1x;45N})m3j}yqpL7cb0V8fIK7H& z;xoxAF&)1$_PRp!)j>mOlpFu~YG3T=3)}l^T_dB*fqRU0wFYVrA3kJ%`jmV?wvMi* zy+qJux&uo3gRr+sWig`mofIg$A&}bSwTI9*2ri zJ%E1|0v$2A^o!MPK}gyyv6fd?e0-LH(Y|6Q5#j!4McfLdFqO3o9_u4OaR?{$5-_+W=P6lw7R;w%H0-P1R$VR0)Auv0#x=8fq*1Q zYg0%^$Gs%6zK3S_`P@%@Fsp`FQTLS%K=Gk>pWFipwxrQOO&Sj zpqkUdSp`wV;cPOSjL|r8VA`RZ&-`=2ZwaBSq@?6~aCY_-G~-!OO-=RF#Axnf!K=te zFLhWOs$R{wy9ra`U0iJD33xu0%Q-k(403yaFS=Xga3z`suVjv6E}IO{U{*OJN%${` zccoAQYM}L&(>0b(_xq-Tz7@(pqC&fO@7eIcz!m}**~7-hrX(x-0&f1e0YbWs8Y$E1 z61{8|738-r;OQ$ks&wDn$)DpJgc?rn!k`oTlIFl^+{Qjw2=zkOrNnK0V*^ggJ2n3L zv9=-{-nY~O5mE?tOyt==?5FvG6<%7(!W_VNB%3P{q*vjGdw2i{VTegbB2&R9wAfOi zMgO%hKHNqHBoc}K;;q`n@#qtzRvBZ0WK1Ph%fod&nQM31qDQ?F%pc^%D?1wSq{kh< z;iA5imk-_sV4FaQmb?qT9VRq0bXSeVxV zpiu|wR9VVy-q*3ktf`}crJpiM^FA`Mf^ukGiBZ`*i zItq|5@f%O}mX|vwaJ{6Ba9*HX#}dL|{4px=53gwco-3rjsHmtgp-*bMx+EW&TC-$? z$H1Xzw<#ItEH(G!Wt>?o4A_bJRu26JA|8AQzVO`0TK{|d`|rRI*XQ9%SC(@pI;fB$ z9vew8(Sg_(0DHQE*%tx9n+!UYKfmS_l$Di9pO5wNjf%^HA|z{}A6K>C8%sjgItlho zHZ-jX>2oVbd=`aSQ)Iq*GvXoySd)v6msVo2b>btXkh1KX&T-|}6o*xi%f*UW+=G;E>h_O-D zK?fEG2a(qY-S{@WF%O5&S0JaoB<9>VJxf5K%3R2B8n*0#k&}N>#K=W9l9Jsgm0e9=ueh;=Y;0ZFU;?Y9uxZ?EGmsJCr#5dCqj;>Tl2w+31<5 zO8GlkFv-&LsN$$Ph!c{K^rHuM`%*}xlSlT?VFa?jW=5p`y(<{<{z z;j?Rs(79S`%#>QZ3Z`2;UO@o?o_7kJdedLO#s~bioO8^vl+vqzkwB<7{>KWdB87^O zRP5oq-njU9TS@xzW=0W?B=YB57@jpYSiIJ11xEbXeD0&`= zBs6Z7QXSCFwHj;9Uv}K>wA_;L^4j3N+WrBC1aTQW8p+|{VVy8Mi^F#u@ST@dJ4=>g z@wbjvvhf!yKYvcHFK=y42ZPR9p;A4Hl@(?^shx}TXzymlDGYl_%OpwZ_W4FoRx8-U zJaC%{j&4xd2Fhcco)6$IhxJJSE*@6h2*&)%mC$dE0re@wt@NhF>&ns5(cylFfwbIv z{@^+OeXN0(eo{Dcp(h6i78uloDCSQl%OiF1DuieIT6YxVCT)i^c<@a&EsiYZ^LVWL zJ_QOSQCWNZ^(F6zsaovu)>KGcfICdeMB{=eIB~AXcl-JCCwxd~KC36|5AJWv^m}KD zM8RYp>raVg=Y?G?sOx=tSohg*SEb7^8U&EKjQwOMw?vf& zD~AI8zJzSzig8s!jT_~K^gPUX**8nHml-JTIey;WHmf|{Z_(|QCKWK}tbG{a5*!>H zsu58skDl_9d$+x3O~n0yku~s&+(9f%T2aqj%e)rej!GCjrjusFT4|g@+Q-Uz zb-!{}*l1bro}NRM5>7uVf`^xw^KuH?%1P9f^xoU*9)x2_txw;SVuL`RAeOx#3zrdz zLt{a`!zb9jPNkF>1iZq<7!iIXL@lg+;}#9;Wew&{&!Jm5QE0_-%}H8cjt&NY-PR{NFelZ zTJ!mH?wHO~qF31EsiZeONvQIKur(0`&v?3fRH%7L>U4(vYNKKt-w5c-$zGtaByk(o zddhg=FkxWr(@P7ghE^I?DaCd6vf?rg+@!Bgi^|ePa&RafP<^bLFWI?3sht_n$oa z_(r2xlF*r#Q<(IRa1ja$S?8S>pj$=(MXh~@C87eh#cA}uXEu?P2Gf+Am;b?O)zcEb z+Omf4tW}3CKD(s7$uSetb}wo&atx|?Jao~W)T~^-5^NB%5$trN5{+03`<0J;EBEC$ zM0%XXIaBW8)f@r5ym_YOY;nKi5QXiwyZ$@v z)0eVO)bJJ{Dh-4c3O_fg%bM2I>i%+=%@Qx3QolQAtrgNpFA4XqXu{S9!6-bKHTSyw zWyPv+k%t7&spXC1PMC5FmVPLSA>x9pQfHWmNUKJjg|WL|Ln}Cmj0`Tcw6!0+HZ2e5 zgYkc7EyB>#&3TdkP4B0A6q*xYtcC?%ms>0s;B+d#oTRDgCkn=C0pKWCF)#wsnn zK{Sf&BL%jzmA_YZLHbFD2~ECQo<&+ekQ~;)DX%={t~O}a{dnJ>q#rU3rQJeR#JPzE zwIwU!a;oIJL@f_{qxUvMPsAkq`2@g!Kemj}E65>H6}UKsJLBf*e-80-?jN9P+G2y% zU@S3FQ5Hoah6GwIuT6J9dWE`i6hBA~6@)C^H46%zGZYH<9e#VfihKFe-$6efQ9Eh2 zmUV(l^JqG{TSwRSElQ<_T!)9uk3tT3OQUt=nfHfj-l$*owW5l^7 z(CZs=_vb#o?_n`hZGk*p;t@xS`eVi07E#|f1=(8fwNbn6@g8W9eSS&k9G%W2UX}8M zCw|ZJfvi0xnS%}f+OpHIQA7M50SSp;Oy4x`#>I_+es2_UBrpF(0z7jpCI=@|}UE(@lXP;1V>Yc7! z{uqsazrI*8^RGzmn)=dLl%zX;bR2zcgGS+niWHv|DW%q1-O{HRkgV82hiKkl1VCWO}JA*DF~*B-R~yYjQ1o|@`oYjxz_JpUfx z9rGTNY~ndtlvk9Hc9aqv>-%5pBqmgUFf`GuvO?9R$}_xojH31RWn{VzS65e)aFD?K z@B^$kK1m=!n=TBU`0dJ}&^VmaF&Hs(q(!1!FBd#V=Mmrl)MJXjM*o*CP)#+SrFF6$?UEq)L1u7Yr?#iE5?hdtlfAx%qN{;M3+AZZ_ln9m zDJ7-uHMEN{ygjcc323;5a`XjXI1tc=E_;F`Lez6;SPJnm?Q;k<=$L4++_0#*vvd6`!9TOk0G7Q3d+$AO&X~{YZ zk2Y=924IIE|g_fZlZnof@VG)12mrXgXd(GR3Y2{5eb$Ne zBG!_8&JOq}wC9}e#ZkGuO_Gxk6Eprj3wTNM+}zw7B@YjtVGbIW|9mj9LqFdXF=qr? zyZJn%eT{#F8c)g-UTM-izO(+3C=7U8*d;WRNwO-VU+E6`}Fsp_9);-P!@U#dIml6yeIz?_Np2y}utkyr~x&fLM%GWK?M z$$*X{jq7ko>t2~iOH1qO+0ANXw5y-EBi5tvsLG{Dwip^;qBKr%f9;WYgv&T~3z0=e z2Ki>_IPKD0*93T7o;dOXa$T@ty!?#15w?b1;|Y3jkIc->iGyxpvU1D3{JkuGM;I{g zS%r^%4_g0=8XaU|AS4JJd_WPSkVE?Xt%;*~(te%o)~*CZsxwMzem$3kki;RY+8Chr z8F(-A=Nt-NlkO)KAZ~!nP-;s;7k7UOKwUCKd;3`jLX9GrwymuV3VlyV_pa$v+38p+ zDc9k}bsd{t<<{Rm3ODYgQ-@kN^!)m;_|rzj+}`XIdE*$6KbX!xx2GBW`dW&ZYkWLa zZ5m|8LbU2swosVXGhlxGzluvyqucG`u7pb!ff+MBeYnV@xfBWpz!=|t9UZmrqS&^^ zu5uNXhr`qU0>^;+pIa?+7{k}t|A;-pN#A7%H0V%-;OK9ks;f7~cAzy~sVOR2gn!!I zQ7_%zlOB5xiW8B(o?dx;VacGfYWRy6`gcYHHyc~q`wpz=AtRDdDGSuZng0H0;Egkcw($(!v)Yp#=McBy!ReuKb=^p`a|ExUdDFcjQGwbbJYeT@yG2j-K;Avf5 zQ}MJ)S-so1(?t>Vl$>2(s*OLsq7`6QtW;5DH?_MLzT&epp;V^BTI--!ULmUuv(~@^ z4m(RZAh!9$XhfIi-o9eVGAOJ0)ECiD<2=kC#`5}{Wd*-+blTB@B2_EzagEE&haDgo z%md0sZQ>nuJP3EBP2J2B9bMh#wf02f7^xsghm;LS$u^)$#x;=Cf1JvH+9^Ub>t|rf zVbYY?)89`q;Vzp(_TtJ8xZ}=opA^NgRqab4Kr?y13!3;pcR4z`C1(3K5o+adQ+U|X z(2pPKs+qizGp@$Tf)ulMF6n20$6#e+BP)7XJ*L`xwD?3@&~=_=2@uOa0Y!)@bFfvF z+x|ZMUrF^rLrF2^Bo^wr!pOjYg`P;pVf)FrimIfU*Sq9SLy{vv)R3Ut#ZPmnz7aR9 zxb86WF^i2B^W8IGOI0>!jBud*u2+#t`r+W>`u9@6W-c|jIIr(Af|o4v&!thAb3mS4 z2N7p;jUdo{IBVwe(J~Ja$Hza?RO8&|OE&8*7a#HY1T-H?!12+k#^gh_Q(s>%2JB!% zgjkVJowcK<7?~q*?gVa!4itn%@n~ao$Iqd3GAp`9l9y3&@c@fHQhd2sq(Wj>)E5tQ zZOiJ~X%|6RQ3VBsLLJu3gm6`6>*{Ckv>vByptJn~LTqNw!snYm6e$5v8c0t|7v@_4 zR)|Gt{iyz$Ge_inhfA3%4p;W6q;rPQb8^1I`2HOOaan1Eo=M6Po<5V4aY=8uC-RhZ{y&A?N&x_RU z+Eum+{-v%4%xt4UzdtEx7Z?reQkxys3%FksN)J zmlR4v-^Bf3;AY6Lti<{9sTepQ-()Rfe}t>iz+_X-e@nl>h@buxBy{Rtc$`F^e-Dk% zZkXi>P^CS>q_}mXe`M;P(DS&I|JRZ6d!hAXHSgFN3z{#oW3obj@LyL3v{$Pt-aCkP zTg8gh={@AZ1Ed)60OXs#LjT1tFQtHvfkUccWMGhCq@z<0?`OsN0OLyq(%<2Gz|2SY z_Vs-@A&6>MA*dm_bB#O%eh0KNomsUd$=y$|rH9M^YeBL0*cM|v2{BecsjWK?Zm%pX zM2n&_-<>m;O(IpUuIvN?J*ej-y1Kh!tiTZlU#{let(2mD$s?zL3%8PaSprI_rLS)z ze!Mo~WkG?@G(DPo)5}+{s)4|POBXRgUYHQY$a8phmT-D2Qyd)~PxhxZ-pcLPK0v>#pSP3x<~RPkQydxk zrjk2m4W113_hjsvY+@_nQ*V3h?Lf0zcQGw8AUOf=z4dSIkv&R?wF* zG0C@}_AWut!w>t2zc4bwANh+fx&dJwOI=y{h{w0Y;f4s+i#{oHF=^Hey~-{;HUf=ki!QwpaA< z=4`2MpZZ+wo5J0`j1Z}?tCR0f*@&=uv7-*u$8{XEQ%HFtNLW+9Oak9J@OSHLi)?!l zp~k}Vo0>9CfB+xWYgI*r6-kq&Wss6WntNxhX3hTkCMP|ej_#N4F(v7tYRMWh-w{UP7?e$nta4H>U*!}HoLMCNcL_|akaD20Zm`#9cIeDVaI*cVNR?;8! z4yHW18n0?#QpIQOzJaitwKZ7*zBiSLiAfR7l>j{|I1O%P=lu0wJ7*$mD+`kSJ}OHs z&@_x#lN2wFyNG9DqdisqU+&z{*C5-7e%pPdlG*o%4YN9FB=3niBMga=VT_!dVlh}% z4t}aW&*1lK_Ouo-lAfiu={Ly(CKAz1QwJ;EMMAFg=L8^%;+AzNU))p}-wh|UCVAhZL_H{t=F*y%$d-zOFo zv%XAUid4`Yns(;d*UiiT+lXTUfs8km=cO4CC+Yiv@tV>G*m@q{gq>0mI5Y5E&Smzm zQ3dUkl?Vf&H-Hwmz2rAh{%?lT1rYAy_RJ{V-MLAljTn;RrgKqB~=Jl@6=CqT$>7zC!Zv zUBY^B)CX=DffqaE&Wp`Y@%C}?E1$-&y$GP{zCS!TIR9eMoTM5b_cf8UgO1{@R@t>b z@Y7;t(acO}4<60QhAvA4{i&g(qFUmH`^tFHS!jckC^UC)aKNB@HwwZf1h@j6I9(iD ziNo)#jf22VmEYD94B*1!s1baZeb-rfB$+BGtkz(DLa4u|heh&o>n%#4p5U1dU&xj4 z6{kT>K06y*?9bIzn7NtR8`r?caZ80?lg~N5-vB3KD-f3yfN8M_NOAFY-h8(?A6^pQ z)up>n>)_9yk%tg;J_ua{F@wI{yN8EI z5ok?y!Gd=)Ncovs4V}eCk_C(U?9><5*L(NAQ%YGM92~qwMdj}(t|sgsUj(8h1Av8W zqXPp6Kq@t7fFY+0vf}!Z`>Pd$N#vG*Uz>wI$>Cb;cboR##h~8-WY{J~?;W9v%F5-2 zfG?t<`bih9TcPt@V zB{DMdFd}g`3ehR*RAS2BlK9p*(P#ZUU77eup9M4x;Z|&)SxkF|Z`tRF;OSl?4 zvg;#+j%1GncL?XTef1$}&*t&p$?0j*iz#C_5e~Dq>27d!CLhLpjp@eb=T$*ETBi_n zaq#u3v&ObhvBDTwabaAHxq9Rp4xu4-O8N`g{9QPdWB6^v+MHw|E5F%&Vh| z>q=0#b^ioz=tc`M)rv+y4kIhFKs6m)JIn!{;?_fu_f$DLChnE|BCM&o1d4gq-C`j} z%8jq@@3(8S6L-r)nN#ZPU!XA6`f6MA=Z!wAYijcEn69<10O|49Q$$_Ey_%{L%egk| ze!R+-ML^E9X|P;BhaMH(3d||szV2y>=S%Ni8Fq4XL^4IVGplBdi349@Ug%BYn`mM+ zXp{FgZ04hz`6PfZ1ro18mVXBdb8bYUmD*y-=rum7vek{fEIycDX))oX*#$HlpjZC? zGedP?W{4cj47s|x=Ee4|E<_|c3r^{#_(msB*SMcyVPR#>PfQT$nw!(`+YCShyuIuH z0^J&_JW#`7D2<>`dYL2Q6$Ly{>3JevePBGxbl9r)l_FzuNJL^@Wj?kZ9X(U+VN_XN zMa6C`ut=-{JKNQfe_J1&Y?N>tn66qJ6+gyVb)a}}%QqRfn;%QUl?)QGUY=w~i#$+k z&#$h`)0B%cL8dX))1asBBe5_x&QW9r#PQnwpzGX=rL5Mu5Q*ug{@3L_q33 z*#?-?8W5oNag;asPMz^>wi4S|9Ea zVA`iPfre=QIW!meWp-9}cY{)TtxSQ3zXVK%Y)MoHFcUJ>2DrPupHz52m(jAD zG>C;LrkXbs=gRdFXZqY2;Da~7(933GB2*vDOQCsQU0o4^uC9lK0W=G=V7jXZ2&Q06 zjxZyhKAZ8wRi{gBSs9X_pC8(6q7E!9fPTX*D=()9svx=z7^PDKk$MVHfh*@f^L$ZM z0esnCiN(akHiv#5we9RU<=Cz`97Nkn+kYO{fEo8sU(p}mr;A9a*8y)v2ZqwX_+m~I z5bkc3i^hTftN8^OFLQHp@Ig(w#TJ**6Xb8)pUwl~(rla5lpNA3Z7o z4OPDrCT8>z7ywxXVPPtT&31yt-Vq Ij79kW0A-^LGXMYp literal 0 HcmV?d00001 diff --git a/wordlist.txt b/wordlist.txt index 76391db34..8c3fd6d0c 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -311,3 +311,4 @@ $VEGA teamUrl avatarUrl dApp +leaderboards From 21b972d7deb5d904a7d0f5203f62cb7c3d12d382 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 2 Aug 2023 15:04:33 +0100 Subject: [PATCH 410/649] feat: remove LP restriction --- protocol/0083-RFPR-on_chain_referral_program.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index ee522f8dd..efce1b3ed 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -107,12 +107,9 @@ To create a new referral set and become a referrer, a party must fulfil the foll - party must not currently be a **referrer** - party must not currently be a **referee** - party must be staking at least `referralProgram.minStakedVegaTokens` tokens -- party must not have an active liquidity provision The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will immediately no longer be eligible for referral benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, they and their referees will become eligible for referral benefits **at the start of the next epoch**. Note, for the case where a party does not re-stake, the protocol will allow referees will to "move" referral sets by [applying](#applying-a-referral-code) a new referral code. -The liquidity provision restriction is constant, once a party has become a referrer they will be restricted from committing liquidity. Any liquidity provision transactions from a referrer should be rejected. - To create a referral set and generate a referral code, the party must submit a signed `CreateReferralSet` transaction. When creating a referral set, a party can optionally designate it as a [team](#glossary) and provide additional team details. When designated as a team a referral set will be visible on leaderboards and in future releases will be eligible for team rewards. A `CreateReferralSet` transaction has the following fields: - `is_team`: a boolean defining whether the referral set should be designated as a team @@ -177,9 +174,6 @@ If a referral set is currently designated as a team, a party is able to effectiv To apply a referral code and become a referee, a party must fulfil the following criteria: - party must not currently be a **referrer** -- party must not have an active liquidity provision - -The liquidity provision restriction is constant, once a party has become a referee they will be restricted from committing liquidity. Any liquidity provision transactions from a referee should be rejected. To become a referee, a referee must submit a signed `ApplyReferralCode` transaction with the following fields: @@ -361,12 +355,10 @@ The Estimate Fees API should now calculate the following additional information: - party must not currently be a **referrer**.CreateReferralSet - party must not currently be a **referee**. - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. - - party must not have an active liquidity provision. 1. If a referrer removes sufficient stake to not meet the required tokens, the referral set should not be eligible for the following referral benefits: - the referrer should not be rewarded for any referee taker fees. - all referees should not receive any discount on their taker fees. 1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch. -1. If a party has created a referral code any future liquidity provision transactions from the party should be rejected. 1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory. #### Updating a referral set @@ -382,8 +374,6 @@ The Estimate Fees API should now calculate the following additional information: 1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied. 1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected. - a party must not currently be a **referrer**. - - party must not have an active liquidity provision. -1. If a party is associated with a referral set any future liquidity provision transactions from the party should be rejected. #### Epoch and running volumes From 13c59703404df92044ea291e6d1d65c2c2ecf94a Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 2 Aug 2023 16:33:15 +0100 Subject: [PATCH 411/649] feat: only taker volume contributes --- .../0083-RFPR-on_chain_referral_program.md | 49 ++++++++++--------- protocol/0084-VDPR-volume_discount_program.md | 23 ++++----- 2 files changed, 37 insertions(+), 35 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index efce1b3ed..844885b1a 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -11,7 +11,7 @@ Whilst a referral program is active, the following benefits may be available to - a **referrer** may receive a proportion of all referee taker fees as a **reward**. - a **referee** may be eligible for a **discount** on any taker 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 sets running trading volume increases. +Providing a party has been associated with a referral set for long enough, they will become eligible for greater benefits as their referral sets running taker volume increases. To create an emphasis on community, collaboration, and competition. Referrers will be able to designate their referral set as a team. Teams will have additional fields which allow them to be visible on leaderboards and later to compete for team based rewards. @@ -37,7 +37,7 @@ To create an emphasis on community, collaboration, and competition. Referrers wi Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: - `benefit_tiers`: a list of dictionaries with the following fields - - `minimum_running_volume`: the required [`referral_set_running_volume`](#referral-set-volumes) in quantum units for parties to access this tier + - `minimum_running_taker_volume`: the required [`referral_set_running_taker_volume`](#referral-set-volumes) in quantum units for parties to access this tier - `minimum_epochs`: the required number of epochs a party must have been in a referral set to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted @@ -49,19 +49,19 @@ message UpdateReferralProgram{ changes: UpdateReferralProgramConfiguration{ benefit_tiers: [ { - "minimum_running_volume": 10000, + "minimum_running_taker_volume": 10000, "minimum_epochs": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { - "minimum_running_volume": 20000, + "minimum_running_taker_volume": 20000, "minimum_epochs": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { - "minimum_running_volume": 30000, + "minimum_running_taker_volume": 30000, "minimum_epochs": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, @@ -189,25 +189,25 @@ If a party is not currently a referee, they must immediately be added to the ref ### Party volumes -The network must now track the cumulative volume of trades for each party in an epoch, call this value `party_epoch_volume`. Each time a trade is generated, the network should increment a parties `party_epoch_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). +The network must now track the cumulative volume of taker trades for each party in an epoch, call this value `party_epoch_taker_volume`. Note, trades generated by auction uncrossing are not counted. Each time a eligible trade is generated, the network should increment a parties `party_epoch_taker_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo -party_epoch_volume = party_epoch_volume + (trade_price * trade_size * settlement_asset_quantum) +party_epoch_taker_volume = party_epoch_taker_volume + (trade_price * trade_size * settlement_asset_quantum) ``` -At the end of an epoch, the `party_epoch_value` is stored by the network and each parties `party_epoch_value` is reset to `0` ready for the next epoch. +At the end of an epoch, the `party_epoch_taker_volume` is stored by the network and each parties `party_epoch_taker_volume` is reset to `0` ready for the next epoch. ### Referral set volumes -At the end of an epoch, for each referral set, a `referral_set_epoch_volume` is calculated by summing the `party_epoch_volume` of each party in the referral set (include both referrers and referees). The amount a party can contribute to their referral set is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. Note this cap is not applied directly to `party_epoch_volume` in case the network parameter is updated during an epoch. +At the end of an epoch, for each referral set, a `referral_set_epoch_taker_volume` is calculated by summing the `party_epoch_taker_volume` of each party in the referral set (include both referrers and referees). The amount a party can contribute to their referral set is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. Note this cap is not applied directly to `party_epoch_taker_volume` in case the network parameter is updated during an epoch. ```pseudo -referral_set_epoch_volume = sum[min(party_epoch_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] +referral_set_epoch_taker_volume = sum[min(party_epoch_taker_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] ``` -After the values are calculated, the `referral_set_epoch_volume` is stored by the network. +After the values are calculated, the `referral_set_epoch_taker_volume` is stored by the network. -The network can then calculate the sets `referral_set_running_volume` by summing the sets `referral_set_epoch_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). +The network can then calculate the sets `referral_set_running_taker_volume` by summing the sets `referral_set_epoch_taker_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). ## Benefit mechanics @@ -219,7 +219,7 @@ Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pe The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. -- `referee_set_running_volume` is greater than or equal to the tiers `minimum_running_volume`. +- `referral_set_running_taker_volume` is greater than or equal to the tiers `minimum_running_taker_volume`. The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. @@ -227,7 +227,7 @@ The referees `referral_reward_factor` is then set to the `referral_reward_factor The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. -- `referral_set_running_volume` is greater than or equal to the tiers `minimum_running_volume`. +- `referral_set_running_taker_volume` is greater than or equal to the tiers `minimum_running_taker_volume`. - the referee has been a associated with the referral set for at least the tiers `minimum_epochs`. The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. @@ -238,19 +238,19 @@ The referees `referral_discount_factor` is then set to the `referral_discount_fa Given: benefit_tiers: [ { - "minimum_running_volume": 10000, + "minimum_running_taker_volume": 10000, "minimum_epochs": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { - "minimum_running_volume": 20000, + "minimum_running_taker_volume": 20000, "minimum_epochs": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { - "minimum_running_volume": 30000, + "minimum_running_taker_volume": 30000, "minimum_epochs": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, @@ -258,7 +258,7 @@ Given: ] And: - referral_set_running_volume=22353 + referral_set_running_taker_volume=22353 party_epochs_in_referral_set=4 Then: @@ -279,7 +279,7 @@ The Parties API should now return a list of all **parties** (which can be filter - current `id` of the referral set the party is associated with - current `epochs_in_referral_set` -- current `party_epoch_volume` +- current `party_epoch_taker_volume` - current `referral_reward_factor` - current `referral_discount_factor` - for each asset, the total referral rewards generated by the parties taker fees @@ -289,7 +289,7 @@ The ReferralSet API should now expose a list of all **referral sets** (which can - the sets founding **referrer** - the sets **referees** -- current `referral_set_running_volume` +- current `referral_set_running_taker_volume` - current `referral_reward_factor` applied to referee taker fees - current **maximum possible** `referral_discount_factor` applied to referee taker fees - for each asset, the total referral rewards generated by all referee taker fees @@ -377,10 +377,11 @@ The Estimate Fees API should now calculate the following additional information: #### Epoch and running volumes -1. Each trade should increment both the maker and taker parties `party_epoch_volume` by the volume of the trade (expressed in quantum units). -1. At the end of the epoch, the `referral_set_epoch_volume` should be correctly calculated by summing each team members `party_epoch_volume`. -1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their sets `referral_set_epoch_volume`. -1. A referral sets `referral_set_running_volume` is calculated as the sum of all `referral_set_epoch_volumes` over the last `epoch_window` epochs. +1. Each trade should increment the taker parties `party_epoch_taker_volume` by the volume of the trade (expressed in quantum units). +1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_taker_volume`. +1. At the end of the epoch, the `referral_set_epoch_taker_volume` should be correctly calculated by summing each team members `party_epoch_taker_volume`. +1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their sets `referral_set_epoch_taker_volume`. +1. A referral sets `referral_set_running_taker_volume` is calculated as the sum of all `referral_set_epoch_taker_volumes` over the last `epoch_window` epochs. ### Benefit Mechanics diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 383fb55bb..0edda55d3 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -1,5 +1,6 @@ # Volume Discount Program +The volume discount program provides tiered discounts on taker fees to traders. A trader accesses greater discounts by increasing their taker volume over a specified number of epochs. ## Network parameters - `volumeDiscountProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a volume discount program @@ -10,7 +11,7 @@ Enabling or changing the terms of the volume discount program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: - `benefit_tiers`: a list of dictionaries with the following fields - - `minimum_party_running_volume`: the required `running_party_volume` in quantum units for a party to access this tier + - `minimum_party_running_taker_volume`: the required `party_running_taker_volume` in quantum units for a party to access this tier - `volume_discount_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled. If this field is empty, the program runs indefinitely. - `window_length`: the number of epochs over which to evaluate a parties running volume @@ -20,15 +21,15 @@ message UpdateVolumeDiscountProgram{ changes: UpdateReferralProgramConfiguration{ benefit_tiers: [ { - "minimum_party_running_volume": 1000, + "minimum_party_running_taker_volume": 1000, "volume_discount_factor": 0.001, }, { - "minimum_party_running_volume": 20000, + "minimum_party_running_taker_volume": 20000, "volume_discount_factor": 0.002, }, { - "minimum_party_running_volume": 30000, + "minimum_party_running_taker_volume": 30000, "volume_discount_factor": 0.003, }, ], @@ -63,29 +64,29 @@ After a volume discount program [proposal](#governance-proposals) is validated a ### Setting benefit factors -At the start of an epoch the network should calculate each parties `party_running_volume` by summing each parties `party_epoch_volume` [values](./0082-RFPR-on_chain_referral_program.md#party-epoch-volumes) over the last n epochs where n is the `window_length` set in the volume discount program [governance proposal](#governance-proposals). +At the start of an epoch the network should calculate each parties `party_running_taker_volume` by summing each parties `party_epoch_volume` [values](./0082-RFPR-on_chain_referral_program.md#party-epoch-volumes) over the last n epochs where n is the `window_length` set in the volume discount program [governance proposal](#governance-proposals). -Each parties `volume_discount_factor` is then fixed to the value in the highest benefit tier they qualify for. A parties benefit tier is defined as the highest tier for which their `party_running_volume` is greater or equal to the tiers `min_party_running_volume`. If a party does not qualify for any tier, their `volume_discount_factor` is set to `0`. +Each parties `volume_discount_factor` is then fixed to the value in the highest benefit tier they qualify for. A parties benefit tier is defined as the highest tier for which their `party_running_taker_volume` is greater or equal to the tiers `minimum_party_running_taker_volume`. If a party does not qualify for any tier, their `volume_discount_factor` is set to `0`. ```pseudo Given: benefit_tiers=[ { - "min_party_running_volume": 10000, + "minimum_party_running_taker_volume": 10000, "volume_discount_factor": 0.001, }, { - "min_party_running_volume": 20000, + "minimum_party_running_taker_volume": 20000, "volume_discount_factor": 0.005, }, { - "min_party_running_volume": 30000, + "minimum_party_running_taker_volume": 30000, "volume_discount_factor": 0.010, }, ] And: - party_running_volume=22353 + party_running_taker_volume=22353 Then: volume_discount_factor=0.005 @@ -102,7 +103,7 @@ Volume discount program benefit factors are applied by modifying [the fees](./00 The Parties API should expose the following information: - a list of all **parties** (by `id`) and the following metrics: - - current `party_running_volume` (value at the start of the epoch) + - current `party_running_taker_volume` (value at the start of the epoch) - current `volume_discount_factor` applied to fees - the total amount discounted for the party From c2e8fec8d376ce5ca0388a2db9a0bf422ad32ac5 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 2 Aug 2023 20:16:32 +0100 Subject: [PATCH 412/649] feat: allow closing of teams to new members --- protocol/0083-RFPR-on_chain_referral_program.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 844885b1a..53215766f 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -117,6 +117,7 @@ To create a referral set and generate a referral code, the party must submit a s - `name`: mandatory str team name - `team_url`: mandatory str of a link to a team forum, discord, etc. - `avatar_url`: mandatory str of a link to an image to be used as the teams avatar + - `closed`: mandatory bool, defines whether a team is accepting new members *Example: if party wants to create a simple referral set.* @@ -133,8 +134,9 @@ message CreateReferralSet is_team: True team_details: { name: "VegaRocks", - team_url: "https://discord.com/channels/vegarocks" - avatar_url: "https://vega-rocks/logo-360x360.jpg" + team_url: "https://discord.com/channels/vegarocks", + avatar_url: "https://vega-rocks/logo-360x360.jpg", + closed: False, } ``` @@ -155,6 +157,7 @@ To update a referral set the party submit a signed `UpdateReferralSet` transacti - `name`: optional str team name - `team_url`: optional str of a link to a team forum, discord, etc. - `avatar_url`: optional str of a link to an image to be used as the teams avatar + - `closed`: optional bool, defines whether a team is accepting new members ```protobuf message UpdateReferralSet @@ -164,9 +167,12 @@ message UpdateReferralSet name: "VegaRocks", team_url: "https://discord.com/channels/vegarocks" avatar_url: "https://vega-rocks/logo-360x360.jpg" + closed: True, } ``` +If a referral set is currently designated as a team, a referrer should be able to "close" their team to any new members by setting the `closed` field to `True`. Note, closing a team is the same as closing a referral set and as such all `ApplyReferralCode` transactions applying the referral code associated with the closed referrals set should be rejected. + If a referral set is currently designated as a team, a party is able to effectively "disband" a team by updating their referral set and setting their `is_team` value to `False`. Note a team should only be "disbanded" and removed from leaderboards at the end of the current epoch after rewards have been distributed. ### Applying a referral code @@ -374,6 +380,7 @@ The Estimate Fees API should now calculate the following additional information: 1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied. 1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected. - a party must not currently be a **referrer**. +1. If the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed. #### Epoch and running volumes From ef456e1e00faeefb19bb5ef4fad01b532bc46bdd Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 3 Aug 2023 07:58:09 +0100 Subject: [PATCH 413/649] fix: fix spellcheck errors --- .../0083-RFPR-on_chain_referral_program.md | 29 ++++++++++--------- protocol/0084-VDPR-volume_discount_program.md | 1 + wordlist.txt | 2 ++ 3 files changed, 18 insertions(+), 14 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 53215766f..1ecaddcf3 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -114,30 +114,31 @@ To create a referral set and generate a referral code, the party must submit a s - `is_team`: a boolean defining whether the referral set should be designated as a team - `team_details`: an optional dictionary defining the teams details (non-optional if `is_team` is `True`) - - `name`: mandatory str team name - - `team_url`: mandatory str of a link to a team forum, discord, etc. - - `avatar_url`: mandatory str of a link to an image to be used as the teams avatar - - `closed`: mandatory bool, defines whether a team is accepting new members + - `name`: mandatory string team name + - `team_url`: mandatory string of a link to a team forum, discord, etc. + - `avatar_url`: mandatory string of a link to an image to be used as the teams avatar + - `closed`: mandatory boolean, defines whether a team is accepting new members *Example: if party wants to create a simple referral set.* ```protobuf -message CreateReferralSet +message CreateReferralSet{ is_team: False team_details: None +} ``` *Example: if party wants to create a referral set and designate it as a team.* ```protobuf -message CreateReferralSet +message CreateReferralSet{ is_team: True team_details: { name: "VegaRocks", team_url: "https://discord.com/channels/vegarocks", avatar_url: "https://vega-rocks/logo-360x360.jpg", closed: False, - } +} ``` When the network receives a valid `CreateReferralSet` transaction, the network will create a referral set with the referral set `id` as the referral code. Any future parties who [apply](#applying-a-referral-code) the referral code will be added to the referral set. @@ -154,13 +155,13 @@ To update a referral set the party submit a signed `UpdateReferralSet` transacti - `id`: id of the referral set to update - `is_team`: a boolean defining whether the party should made into a team visible on leaderboards - `team_details`: an optional dictionary defining the team - - `name`: optional str team name - - `team_url`: optional str of a link to a team forum, discord, etc. - - `avatar_url`: optional str of a link to an image to be used as the teams avatar - - `closed`: optional bool, defines whether a team is accepting new members + - `name`: optional string team name + - `team_url`: optional string of a link to a team forum, discord, etc. + - `avatar_url`: optional string of a link to an image to be used as the teams avatar + - `closed`: optional boolean, defines whether a team is accepting new members ```protobuf -message UpdateReferralSet +message UpdateReferralSet{ id: "mYr3f3rra15et1d" is_team: True team_details: { @@ -168,10 +169,10 @@ message UpdateReferralSet team_url: "https://discord.com/channels/vegarocks" avatar_url: "https://vega-rocks/logo-360x360.jpg" closed: True, - } +} ``` -If a referral set is currently designated as a team, a referrer should be able to "close" their team to any new members by setting the `closed` field to `True`. Note, closing a team is the same as closing a referral set and as such all `ApplyReferralCode` transactions applying the referral code associated with the closed referrals set should be rejected. +If a referral set is currently designated as a team, a referrer should be able to "close" their team to any new members by setting the `closed` field to `True`. Note, closing a team is the same as closing a referral set and as such all `ApplyReferralCode` transactions applying the referral code associated with the closed referrals set should be rejected. If a referral set is currently designated as a team, a party is able to effectively "disband" a team by updating their referral set and setting their `is_team` value to `False`. Note a team should only be "disbanded" and removed from leaderboards at the end of the current epoch after rewards have been distributed. diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 0edda55d3..3023f2cf3 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -1,6 +1,7 @@ # Volume Discount Program The volume discount program provides tiered discounts on taker fees to traders. A trader accesses greater discounts by increasing their taker volume over a specified number of epochs. + ## Network parameters - `volumeDiscountProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a volume discount program diff --git a/wordlist.txt b/wordlist.txt index 8c3fd6d0c..b1e92ecbf 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -312,3 +312,5 @@ teamUrl avatarUrl dApp leaderboards +ReferralSet +CreateReferralSet From a1c04d017a50b929a529ae89e62dbba05279793e Mon Sep 17 00:00:00 2001 From: gordsport Date: Fri, 4 Aug 2023 12:49:21 +0100 Subject: [PATCH 414/649] chore: add AC codes --- .../0083-RFPR-on_chain_referral_program.md | 81 +++++++++---------- protocol/0084-VDPR-volume_discount_program.md | 28 +++---- protocol/features.json | 56 ++++++++++++- 3 files changed, 108 insertions(+), 57 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 1ecaddcf3..ec60ce286 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -338,66 +338,65 @@ The Estimate Fees API should now calculate the following additional information: ### Governance Proposals 1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - - the `closing_timestamp` must be less than or equal to the proposals `enactment_time`. - - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. - - all `minimum_epochs_in_team` values must be an integer strictly greater than 0. - - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. - - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - - the `window_length` must be an integer strictly greater than zero. -1. A referral program should be started the first epoch change after the `enactment_datetime` is reached. -1. A referral program should be closed the first epoch change after the `closing_timestamp` is reached. + - the `closing_timestamp` must be less than or equal to the proposals `enactment_time` (0083-RFPR-001). + - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers` (0083-RFPR-002). + - all `minimum_epochs_in_team` values must be an integer strictly greater than 0 (0083-RFPR-003). + - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` (0083-RFPR-004). + - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor` (0083-RFPR-005). + - the `window_length` must be an integer strictly greater than zero (0083-RFPR-006). +1. A referral program should be started the first epoch change after the `enactment_datetime` is reached (0083-RFPR-007). +1. A referral program should be closed the first epoch change after the `closing_timestamp` is reached (0083-RFPR-008). 1. If a referral program is already active and a proposal `enactment_datetime` is reached, the referral program is updated at the next epoch change. - - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec. - - Proposal for program A accepted and begins first epoch after 1st Jan. - - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug. - - Proposal for program B accepted and overrides program A the first epoch after 1st June. - - Program is closed first epoch after 31st Aug, there should be no active proposals. + - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec (0083-RFPR-009). + - Proposal for program A accepted and begins first epoch after 1st Jan (0083-RFPR-010). + - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug (0083-RFPR-011). + - Proposal for program B accepted and overrides program A the first epoch after 1st June (0083-RFPR-012). + - Program is closed first epoch after 31st Aug, there should be no active proposals (0083-RFPR-013). ### Referral set mechanics #### Creating a referral set -1. If a party **is not** currently a referrer, the party can **create** a referral set, by submitting a signed `CreateReferralSet` transaction. +1. If a party **is not** currently a referrer, the party can **create** a referral set, by submitting a signed `CreateReferralSet` transaction (0083-RFPR-014). 1. If one or more of the following conditions are not met, any `CreateReferralCode` transaction should be rejected. - - party must not currently be a **referrer**.CreateReferralSet - - party must not currently be a **referee**. - - party must be staking at least `referralProgram.minStakedVegaTokens` tokens. + - party must not currently be a **referrer**.CreateReferralSet (0083-RFPR-015). + - party must not currently be a **referee** (0083-RFPR-016). + - party must be staking at least `referralProgram.minStakedVegaTokens` tokens (0083-RFPR-017). 1. If a referrer removes sufficient stake to not meet the required tokens, the referral set should not be eligible for the following referral benefits: - - the referrer should not be rewarded for any referee taker fees. - - all referees should not receive any discount on their taker fees. -1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch. -1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory. + - the referrer should not be rewarded for any referee taker fees (0083-RFPR-018). + - all referees should not receive any discount on their taker fees (0083-RFPR-019). +1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch (0083-RFPR-020). +1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory (0083-RFPR-021). #### Updating a referral set -1. If a party is currently a referrer, the party can **update** a referral set by submitting a signed `UpdateReferralSet` transaction. -1. If a party submits an `UpdateReferralSet` transaction for a referral set they are not the referrer off, the transaction should be rejected. -1. When updating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory. +1. If a party is currently a referrer, the party can **update** a referral set by submitting a signed `UpdateReferralSet` transaction (0083-RFPR-022). +1. If a party submits an `UpdateReferralSet` transaction for a referral set they are not the referrer off, the transaction should be rejected (0083-RFPR-023). +1. When updating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory (0083-RFPR-024). #### Applying a referral code -1. If a party **is not** currently a **referee**, the party can immediately become associated with a referral set by submitting a signed `ApplyReferralCode` transaction. -1. If a party **is** currently a **referee**, the party can become associated with a new referral set (at the start of the next epoch) by submitting a signed `ApplyReferralCode` transaction. -1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied. -1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected. - - a party must not currently be a **referrer**. -1. If the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed. +1. If a party **is not** currently a **referee**, the party can immediately become associated with a referral set by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-025). +1. If a party **is** currently a **referee**, the party can become associated with a new referral set (at the start of the next epoch) by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-026). +1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied (0083-RFPR-027). +1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected (0083-RFPR-028). + - a party must not currently be a **referrer** (0083-RFPR-029). +1. If the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed (0083-RFPR-030). #### Epoch and running volumes -1. Each trade should increment the taker parties `party_epoch_taker_volume` by the volume of the trade (expressed in quantum units). -1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_taker_volume`. -1. At the end of the epoch, the `referral_set_epoch_taker_volume` should be correctly calculated by summing each team members `party_epoch_taker_volume`. -1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their sets `referral_set_epoch_taker_volume`. -1. A referral sets `referral_set_running_taker_volume` is calculated as the sum of all `referral_set_epoch_taker_volumes` over the last `epoch_window` epochs. +1. Each trade should increment the taker parties `party_epoch_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). +1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_taker_volume` (0083-RFPR-032). +1. At the end of the epoch, the `referral_set_epoch_taker_volume` should be correctly calculated by summing each team members `party_epoch_taker_volume` (0083-RFPR-033). +1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their sets `referral_set_epoch_taker_volume` (0083-RFPR-034). +1. A referral sets `referral_set_running_taker_volume` is calculated as the sum of all `referral_set_epoch_taker_volumes` over the last `epoch_window` epochs (0083-RFPR-035). ### Benefit Mechanics #### Setting benefit factors -1. At the start of an epoch, each referees `referral_reward_factor` and `referral_discount_factor` is reevaluated and fixed for the epoch. -1. At the start of an epoch, a referees `referral_reward_factor` is set equal to the factor in the highest benefit tier they qualify for. -1. At the start of an epoch, a referees `referral_discount_factor` is set equal to the factor in the highest benefit tier they qualify for. -1. If when evaluating the tier to set the `referral_reward_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0`. -1. If when evaluating the tier to set the `referral_discount_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0`. - +1. At the start of an epoch, each referees `referral_reward_factor` and `referral_discount_factor` is reevaluated and fixed for the epoch (0083-RFPR-036). +1. At the start of an epoch, a referees `referral_reward_factor` is set equal to the factor in the highest benefit tier they qualify for (0083-RFPR-037). +1. At the start of an epoch, a referees `referral_discount_factor` is set equal to the factor in the highest benefit tier they qualify for (0083-RFPR-038). +1. If when evaluating the tier to set the `referral_reward_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0` (0083-RFPR-039). +1. If when evaluating the tier to set the `referral_discount_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0` (0083-RFPR-040). diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 3023f2cf3..7c9975dbe 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -120,22 +120,22 @@ The Trades API should now also expose the following additional information for e ### Governance Proposals 1. If an `UpdateVolumeDiscount` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - - the `closing_timestamp` must be less than or equal to the proposals `enactment_time`. - - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers`. - - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxReferralRewardFactor`. - - the `window_length` must be an integer strictly greater than zero. -1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached. -1. A volume discount program should be closed the first epoch change after the `closing_timestamp` is reached. + - the `closing_timestamp` must be less than or equal to the proposals `enactment_time` (0084-VDPR-001). + - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers` (0084-VDPR-002). + - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxReferralRewardFactor` (0084-VDPR-003). + - the `window_length` must be an integer strictly greater than zero (0084-VDPR-004). +1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached (0084-VDPR-005). +1. A volume discount program should be closed the first epoch change after the `closing_timestamp` is reached (0084-VDPR-006). 1. If a volume discount program is already active and a proposal `enactment_datetime` is reached, the volume discount program is updated at the next epoch change. - - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec. - - Proposal for program A accepted and begins first epoch after 1st Jan. - - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug. - - Proposal for program B accepted and overrides program A the first epoch after 1st June. - - Program is closed first epoch after 31st Aug, there should be no active proposals. + - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec (0084-VDPR-007). + - Proposal for program A accepted and begins first epoch after 1st Jan (0084-VDPR-008). + - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug (0084-VDPR-009). + - Proposal for program B accepted and overrides program A the first epoch after 1st June (0084-VDPR-010). + - Program is closed first epoch after 31st Aug, there should be no active proposals (0084-VDPR-011). ### Setting benefit factors -1. At the start of an epoch, each parties `volume_discount_factor` is reevaluated and fixed for the epoch. -1. A parties `volume_discount_factor` is set equal to the factors in the highest benefit tier they qualify for. -1. If a party does not qualify for the lowest tier, their `volume_discount_factor`is set to `0`. +1. At the start of an epoch, each parties `volume_discount_factor` is reevaluated and fixed for the epoch (0084-VDPR-012). +1. A parties `volume_discount_factor` is set equal to the factors in the highest benefit tier they qualify for (0084-VDPR-013). +1. If a party does not qualify for the lowest tier, their `volume_discount_factor`is set to `0` (0084-VDPR-014). diff --git a/protocol/features.json b/protocol/features.json index 8f4927fc2..1963a77b4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -687,8 +687,60 @@ "Referral program": { "milestone": "deployment-2", "acs": [ - "0083-RFPR-000", - "0084-VDPR-000" + "0083-RFPR-001", + "0083-RFPR-002", + "0083-RFPR-003", + "0083-RFPR-004", + "0083-RFPR-005", + "0083-RFPR-006", + "0083-RFPR-007", + "0083-RFPR-008", + "0083-RFPR-009", + "0083-RFPR-010", + "0083-RFPR-011", + "0083-RFPR-012", + "0083-RFPR-013", + "0083-RFPR-014", + "0083-RFPR-015", + "0083-RFPR-016", + "0083-RFPR-017", + "0083-RFPR-018", + "0083-RFPR-019", + "0083-RFPR-020", + "0083-RFPR-021", + "0083-RFPR-022", + "0083-RFPR-023", + "0083-RFPR-024", + "0083-RFPR-025", + "0083-RFPR-026", + "0083-RFPR-027", + "0083-RFPR-028", + "0083-RFPR-029", + "0083-RFPR-030", + "0083-RFPR-031", + "0083-RFPR-032", + "0083-RFPR-033", + "0083-RFPR-034", + "0083-RFPR-035", + "0083-RFPR-036", + "0083-RFPR-037", + "0083-RFPR-038", + "0083-RFPR-039", + "0083-RFPR-040", + "0084-VDPR-001", + "0084-VDPR-002", + "0084-VDPR-003", + "0084-VDPR-004", + "0084-VDPR-005", + "0084-VDPR-006", + "0084-VDPR-007", + "0084-VDPR-008", + "0084-VDPR-009", + "0084-VDPR-010", + "0084-VDPR-011", + "0084-VDPR-012", + "0084-VDPR-013", + "0084-VDPR-014" ] }, "Market governance": { From ada4e6bbb4ae4f4378402df1c00e232668d5e93e Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 15:33:23 +0100 Subject: [PATCH 415/649] fix: calculate rewards after applying discounts --- protocol/0029-FEES-fees.md | 36 +++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 04cf60ab4..fe51122b0 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -25,15 +25,9 @@ Note that maker_fee = 0 if there is no maker, taker relationship between the tra Before fees are transferred, if there is an [active referral program](./0083-RFPR-on_chain_referral_program.md) or [volume discount program](./0085-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. -1. Calculate any referral rewards due to the parties referrer. +Note, it is important discounts are calculated and applied **before** rewards are calculated and applied. - ```pseudo - infrastructure_fee_referral_reward = floor(infrastructure_fee * referral_reward_factor) - liquidity_fee_referral_reward = floor(liquidity_fee * referral_reward_factor) - maker_fee_referral_reward = floor(maker_fee * referral_reward_factor) - ``` - -2. Calculate any referral discounts due to the party. +1. Calculate any referral discounts due to the party. ```pseudo infrastructure_fee_referral_discount = floor(infrastructure_fee * referral_discount_factor) @@ -41,7 +35,7 @@ Before fees are transferred, if there is an [active referral program](./0083-RFP maker_fee_referral_discount = floor(maker_fee * referral_discount_factor) ``` -3. Calculate any volume discounts due to the party. +1. Calculate any volume discounts due to the party. ```pseudo infrastructure_fee_volume_discount = floor(infrastructure_fee * volume_discount_factor) @@ -49,12 +43,28 @@ Before fees are transferred, if there is an [active referral program](./0083-RFP maker_fee_volume_discount = floor(maker_fee * volume_discount_factor) ``` -4. And then update the fees. +1. Update the fee components by applying the discounts. + + ```pseudo + infrastructure_fee = infrastructure_fee - infrastructure_fee_referral_discount - infrastructure_fee_volume_discount + liquidity_fee = liquidity_fee - liquidity_fee_referral_discount - liquidity_fee_volume_discount + maker_fee = maker_fee - maker_fee_referral_discount - maker_fee_volume_discount + ``` + +1. Calculate any referral rewards due to the parties referrer (Note we are using the updated fee components from step 3) + + ```pseudo + infrastructure_fee_referral_reward = floor(infrastructure_fee * referral_reward_factor) + liquidity_fee_referral_reward = floor(liquidity_fee * referral_reward_factor) + maker_fee_referral_reward = floor(maker_fee * referral_reward_factor) + ``` + +1. Finally, update the fee components by applying the rewards. ```pseudo - infrastructure_fee = infrastructure_fee - infrastructure_fee_referral_reward - infrastructure_fee_referral_discount - infrastructure_fee_volume_discount - liquidity_fee = liquidity_fee - liquidity_fee_referral_reward - liquidity_fee_referral_discount - liquidity_fee_volume_discount - maker_fee = maker_fee - maker_fee_referral_reward - maker_fee_referral_discount - maker_fee_volume_discount + infrastructure_fee = infrastructure_fee - infrastructure_fee_referral_reward + liquidity_fee = liquidity_fee - liquidity_fee_referral_reward + maker_fee = maker_fee - maker_fee_referral_reward ``` (Note the rewards and discounts are floored rather than raised to ensure the final fees cannot be negative.) From e95d37b4c11ee9c6758542d2593dc5876fc225e2 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Mon, 7 Aug 2023 15:35:49 +0100 Subject: [PATCH 416/649] refactor: clarify AC as suggested Co-authored-by: Barnaby M --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index ec60ce286..730ce16af 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -108,7 +108,7 @@ To create a new referral set and become a referrer, a party must fulfil the foll - party must not currently be a **referee** - party must be staking at least `referralProgram.minStakedVegaTokens` tokens -The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will immediately no longer be eligible for referral benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, they and their referees will become eligible for referral benefits **at the start of the next epoch**. Note, for the case where a party does not re-stake, the protocol will allow referees will to "move" referral sets by [applying](#applying-a-referral-code) a new referral code. +The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will immediately no longer be eligible for referral benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, they and their referees will become eligible for referral benefits **at the start of the next epoch**. Note, for the case where a party does not re-stake, the protocol will still allow referees to "move" referral sets by [applying](#applying-a-referral-code) a new referral code as normal. To create a referral set and generate a referral code, the party must submit a signed `CreateReferralSet` transaction. When creating a referral set, a party can optionally designate it as a [team](#glossary) and provide additional team details. When designated as a team a referral set will be visible on leaderboards and in future releases will be eligible for team rewards. A `CreateReferralSet` transaction has the following fields: From 6613fb22d68372e6bf7a750934865b7aa2d13513 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 15:43:22 +0100 Subject: [PATCH 417/649] feat: remove program rejected status --- protocol/0083-RFPR-on_chain_referral_program.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 730ce16af..38c70d413 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -90,11 +90,10 @@ After a referral program [proposal](#governance-proposals) is validated and acce | Status | Benefits Enabled | Condition for entry | Condition for exit | | -------------------- | ---------------- | --------------------------------------------------------- | ----------------------------------------------------------------- | +| `STATUS_INACTIVE` | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | | `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | -| `STATUS_REJECTED` | No | Governance vote fails (or is invalid) | New governance proposal submitted to the network | | `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | | `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | -| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | ## Referral set mechanics From ca2b1043df8a42178b7cd3a0c84ebd45d480eeaf Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 15:52:48 +0100 Subject: [PATCH 418/649] feat: remove program rejected status --- protocol/0084-VDPR-volume_discount_program.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 7c9975dbe..d5b852e64 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -55,11 +55,10 @@ After a volume discount program [proposal](#governance-proposals) is validated a | Status | Benefits Enabled | Condition for entry | Condition for exit | | -------------------- | ---------------- | --------------------------------------------------------- | ----------------------------------------------------------------- | +| `STATUS_INACTIVE` | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | | `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | -| `STATUS_REJECTED` | No | Governance vote fails (or is invalid) | New governance proposal submitted to the network | | `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | | `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | -| `STATUS_CLOSED` | No | Previously `STATUS_ACTIVE` | New governance proposal submitted to the network | ## Benefit Mechanics From 853671eedd00e3cc01f36949d1e4f781e41e646a Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Mon, 7 Aug 2023 16:52:32 +0100 Subject: [PATCH 419/649] Update 0083-RFPR-on_chain_referral_program.md Make most team fields optional --- protocol/0083-RFPR-on_chain_referral_program.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 38c70d413..23c1d666d 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -114,9 +114,9 @@ To create a referral set and generate a referral code, the party must submit a s - `is_team`: a boolean defining whether the referral set should be designated as a team - `team_details`: an optional dictionary defining the teams details (non-optional if `is_team` is `True`) - `name`: mandatory string team name - - `team_url`: mandatory string of a link to a team forum, discord, etc. - - `avatar_url`: mandatory string of a link to an image to be used as the teams avatar - - `closed`: mandatory boolean, defines whether a team is accepting new members + - `team_url`: optional string of a link to a team forum, discord, etc. (defaults to empty string / none-type) + - `avatar_url`: mandatory string of a link to an image to be used as the teams avatar (defaults to empty string / none-type) + - `closed`: mandatory boolean, defines whether a team is accepting new members (defaults to false) *Example: if party wants to create a simple referral set.* From baa97336aa3d3254d97fd9639913debff47730ec Mon Sep 17 00:00:00 2001 From: Barnaby M Date: Mon, 7 Aug 2023 16:59:22 +0100 Subject: [PATCH 420/649] Update 0083-RFPR-on_chain_referral_program.md --- protocol/0083-RFPR-on_chain_referral_program.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 23c1d666d..f34b5a09e 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -115,8 +115,8 @@ To create a referral set and generate a referral code, the party must submit a s - `team_details`: an optional dictionary defining the teams details (non-optional if `is_team` is `True`) - `name`: mandatory string team name - `team_url`: optional string of a link to a team forum, discord, etc. (defaults to empty string / none-type) - - `avatar_url`: mandatory string of a link to an image to be used as the teams avatar (defaults to empty string / none-type) - - `closed`: mandatory boolean, defines whether a team is accepting new members (defaults to false) + - `avatar_url`: optional string of a link to an image to be used as the teams avatar (defaults to empty string / none-type) + - `closed`: optional boolean, defines whether a team is accepting new members (defaults to false) *Example: if party wants to create a simple referral set.* From 16ab9f2ab8d4539e2109352f9795cf35938dd79c Mon Sep 17 00:00:00 2001 From: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Date: Tue, 8 Aug 2023 12:29:31 +0100 Subject: [PATCH 421/649] chore: ethereum oracles acceptance criteria updates (#1875) * chore: Update acceptance criteria * Update 0082-ETHD-ethereum-data-source.md * Update 0082-ETHD-ethereum-data-source.md * Update 0082-ETHD-ethereum-data-source.md * Update 0082-ETHD-ethereum-data-source.md * Update 0082-ETHD-ethereum-data-source.md * Update 0082-ETHD-ethereum-data-source.md * Update 0082-ETHD-ethereum-data-source.md * chore: Update numbering * chore: Update Phase 2 acceptance criteria * chore: Remove redundant acceptance criteria * fix: Address review comments * chore: Fix typo * clarify consensus test * chore: Fix typo * fix: features.json --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: gordsport --- protocol/0028-GOVE-governance.md | 2 + protocol/0082-ETHD-ethereum-data-source.md | 101 ++++++++++----------- protocol/features.json | 79 ++++++++-------- wordlist.txt | 1 + 4 files changed, 88 insertions(+), 95 deletions(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 1811ef2a3..499799e4e 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -541,6 +541,8 @@ APIs should also exist for clients to: - Attempt to enact a market closure proposal on a closed market has no effect. (0028-GOVE-111) - Markets which have been suspended via a governance proposal can be resumed after a protocol upgrade restarts the network. (0028-GOVE-150) - Markets which have been suspended via a governance proposal can be terminated after a protocol upgrade restarts the network. (0028-GOVE-151) +- Oracle data sources shared between multiple markets are not deactivated if one of the markets sharing the oracle data sources is terminated and settled using governance proposals. Now the status of the data sources should still be ACTIVE as Market2 is still using them. (0028-GOVE-152) +- Ensure that when a market is suspended and then resumed via a governance proposal we can still terminate and settle the market using ethereum oracle. (0028-GOVE-153) #### Network parameter change proposals diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 0b3a21e44..cd65db701 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -110,81 +110,78 @@ Select { ### External Oracles - Creation -1. Using the existing ways to create or update a market via governance proposals, define data sources for settlement and termination as the result of calling a read method of a smart contract on ethereum network. (Phase 2 of this step would be defining an oracle that is based on listening for events on ethereum network) (0082-ETHD-001) -2. All current governance rules that apply to propose / submit / vote on a proposal should be applicable for the ethereum oracle data source creation / amendment (0082-ETHD-002) -3. Create more than spam.protection.max.proposals oracle data source proposals in an epoch - proposal rejected with error message (0082-ETHD-003) -4. Create ethereum oracles based on calling a read method of a smart contract by supplying incorrect ABI (Phase 2 - oracle based on listening for events) (0082-ETHD-004) +1. Using the existing ways to create or update a market via governance proposals, define data sources for settlement and termination as the result of calling a read method of a smart contract on ethereum network. (0082-ETHD-001) +2. Phase 2 of the above step would be defining an oracle that is based on listening for events on ethereum network) (0082-PLAZZO-001) ### External Oracles - Amendments -1. Amend the oracle data source via governance proposals. Amendments should take effect as soon as the proposal is enacted (0082-ETHD-005) -2. Amend an existing ethereum data source and change the contract address and enact the proposal. Once enacted, the data should be sourced from the new smart contract. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0082-ETHD-006) -3. Phase 2 - Amend an existing ethereum data source and change the events that we are listening to and enact the proposal. Once enacted , the data should be sourced from the amended events. Try amending the other fields in the oracle data source and the changes should take effect after the proposals are enacted (0082-ETHD-007) +1. Update an existing market using the market update proposal to change the smart contract address and read method. The changes take effect after the market update proposal is enacted and data is sourced from the new smart contract. The old data source will be deactivated when the proposal is enacted (0082-ETHD-002) +2. Using the market update proposal all data elements for the ethereum oracles can be updated. On successful enactment , a new oracle data source is created for the market. In case any existing data source matches the new data source , then a new data source is not created and the existing one is used (0082-ETHD-003) +3. Phase 2 - Update an existing market using the market update proposal to change the events that the market is listening to. The changes take effect after the market update proposal is enacted and data is sourced from the new events (0082-PLAZZO-002) +4. Ensure existing oracle data sources are deactivated when market data sources are amended on another market. Create 2 markets to use different ethereum oracles for termination and settlement. Two sets of ethereum oracles are created and are ACTIVE. Then amend Market 2 to use exactly the same ethereum oracles for termination and settlement as Market1. Now ,the ethereum oracles originally created for for Market2 should be set to DEACTIVATED. No new ethereum oracles should be created and the Market2 should use the existing ethereum oracles created for Market1 (0082-ETHD-005) +5. Ensure that when a market data source type is amended from internal, external, ethereum or open (coinbase) to an alternative for both termination and settlement we see that old data source is deactivated (if no other market is using) and we see the new data source created and it supports termination and settlement specific to its data source type (0082-ETHD-006) -### External Oracles - Deletions +### External Oracles - Deactivation -1. Aligned with the existing logic, when no market listens to a data source, whatever that source is, it is automatically disregarded / deleted from the engine. Same applies for ethereum oracles (0082-ETHD-008) -2. When ethereum oracle is referenced / used by an existing market, it should not be deleted (0082-ETHD-009) -3. If a single data source is used by multiple markets, then should NOT be able to delete the data source even if one of those markets is actively using the data source (0082-ETHD-010) +1. Aligned with the existing logic, when no market listens to a data source, whatever that source is, it is automatically disregarded by the engine and the status of the data source is set to DEACTIVATED. Same applies for ethereum oracles (0082-ETHD-007) ### External Oracles - Validations -1. Validate if the smart contract address is valid (0082-ETHD-011) -2. Validate if the data elements of the oracle data source is valid - e.g. source for a value that's returned as boolean but have a filter / condition for greater than 0 (0082-ETHD-012) -3. Validations for min / max frequency of listening for events / read a smart contract (0082-ETHD-013) -4. When a proposal that uses ethereum oracles, defines incorrect data (contract address, ABI) the system should throw an error and the proposal should not pass validation (0082-ETHD-014) -5. Any mismatch between expected fields and received fields should emit an error via the TX RESULT event (0082-ETHD-016) +1. Validate if the smart contract address is valid (0082-ETHD-010) +2. Validate if the data elements of the oracle data source is valid - e.g. call the smart contract and check if the types in the ABI match whats provided in the oracle spec (0082-ETHD-011) +3. Validations for min / max frequency of listening for events / read a smart contract (0082-ETHD-012) +4. When a proposal that uses ethereum oracles, defines incorrect data (contract address, ABI) the system should return an error and the proposal should not pass validation (0082-ETHD-013) +5. Any mismatch between expected fields/field types and received fields/field types should emit an error event (0082-ETHD-014) + +### Usage + +1. It should be possible to use only ethereum oracle data sources in a market proposal, or create any combination with any of the other types of currently existing external or internal data sources (0082-ETHD-015) +2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-016) +3. Create a market to use an external data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-017) +4. Create a market to use an open oracle data source to settle a market and an ethereum oracle to terminate the market (0082-ETHD-018) +5. Chain events should only be sent when the filter is matched, this can be verified using an API and the core/data node events (BUS_EVENT_TYPE_ORACLE_DATA) (0082-ETHD-019) +6. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-020) +7. Create 2 markets to use the same ethereum oracle for termination say DS-T1 but two different ethereum oracles for settlement DS-S1 and DS-S2. Now trigger the termination ethereum oracle data source. Both markets should be terminated and the data source DS-T1 is set to DEACTIVATED and the data sources DS-S1 and DS-S2 are still ACTIVE. Now settle market1. DS-S1 is set to DEACTIVATED and DS-S2 is still active. (0082-ETHD-021) +8. Create a market to use an ethereum oracle for termination configured such that - it expects a boolean value True for termination and the contract supplying the termination value is polled every 5 seconds. Set the contract to return False for termination. The market is not terminated. The data source is still ACTIVE and no BUS_EVENT_TYPE_ORACLE_DATA events for that ethereum oracle spec are emitted. Then set the contract to return True for termination. The market is terminated and an event for BUS_EVENT_TYPE_ORACLE_DATA for the ethereum oracle data spec is received and the ethereum oracle is set to DEACTIVATED. (0082-ETHD-022) +9. Only one oracle data event is emitted for data that matches multiple data sources - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 300. One single event BUS_EVENT_TYPE_ORACLE_DATA for the settlement data is emitted with both matching ethereum oracle data sources listed within the event. Both markets are settled and both the data sources are DEACTIVATED. (0082-ETHD-023) +10. Different oracle data events for multiple spec id's with non matching filter values - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 50. NO data events for BUS_EVENT_TYPE_ORACLE_DATA. Send settlement data of 150. One single event BUS_EVENT_TYPE_ORACLE_DATA emitted for the settlement data is emitted with matching ethereum oracle data spec for Market1, market1 is settled and the data source is set to DEACTIVATED. Send settlement data of 250. One single event BUS_EVENT_TYPE_ORACLE_DATA emitted for the settlement data is emitted with matching ethereum oracle data spec for Market2, Market2 is settled and the data source is set to DEACTIVATED. (0082-ETHD-024) +11. Network wide contract error should be reported via oracle data events (0082-ETHD-025) +12. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-PLAZZO-003) +13. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-PLAZZO-004) ### New Network parameters -1. Test min / max values / validations for any new network parameters that are added (0082-ETHD-017) -2. Test the successful disabling / enabling of ethereum oracles when the new network parameter "ethereum.oracles.enabled" is set to false or true respectively (0082-ETHD-018) +1. New network parameter - ethereum.oracles.enabled. Setting this to 0 should NOT allow market creation and market updates with ethereum oracles. (0082-ETHD-028) +2. New network parameter - ethereum.oracles.enabled. Setting this to 1 should allow market creation amd market updates with ethereum oracles. (0082-ETHD-029) ### Negative Tests -1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) (0082-ETHD-019) -2. Data source returns incorrect data - raise an error via the TX RESULT event. The data source is expected to send a positive price for an asset BUT sends a negative value (0082-ETHD-020) -3. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this (0082-ETHD-021) -4. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-022) -5. Create an oracle that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should throw an error (0082-ETHD-023) -6. Will need some tests around consensus, will require setting up a network and having some nodes receive different values for the same oracle data point and testing that the oracle data point is/is not published depending on voting (0082-ETHD-024) +1. Set up a new data source with invalid contract address - should fail validations (Phase 2 - listening for invalid event ) (0082-ETHD-030) +2. Phase 2 - Set up a data source for listening to a particular event sent at a frequency of 2 secs. The oracle data source stops emitting events after emitting a couple of events. Raise and error via the TX RESULT event if 5 consecutive events are missed - need to ratify / expand on this (0082-PLAZZO-005) +3. Phase 2 - Create an oracle source listening for a particular event and specify an incorrect ABI format for the event. Proposal should fail validation and should return an error (0082-PLAZZO-006) +4. Create an oracle that calls a read method of a smart contract and specify an incorrect ABI format for the event. Proposal should fail validation and should return an error (0082-ETHD-034) +5. Set up a network such that different vega nodes receive conflicting results from an identical ethereum contract call. Attempt to settle a market using that contract. Observe that if there are not enough nodes voting in agreement, the market is not settled (0082-ETHD-035) ### API -1. Ability to query oracle data sources via an API endpoint - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0082-ETHD-025) -2. Ability to query historic data sent by an oracle data source (0082-ETHD-026) - -### Non Functional - -1. Network wide contract error should be reported via oracle data events (0082-ETHD-027) -2. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-ETHD-028) -3. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-ETHD-029) -4. If an oracle data source is inactive - then any events / any data received from that oracle data source is NOT processed (0082-ETHD-030) - -### Usage - -1. It should be possible to use only ethereum oracle data sources in a market proposal, or create any combination with any of the other types of currently existing external or internal data sources (0082-ETHD-034) -2. Create a market to use an internal data source to terminate a market and an ethereum oracle to settle the market (0082-ETHD-035) -3. Create a market to use an external data source to terminate a market and a manual oracle to settle the market (0082-ETHD-036) -4. Chain events should only be sent when the filter is matched (0082-ETHD-037) -5. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-046) +1. Ability to query oracle data sources via an API endpoint (REST, gRPC and graphQL) - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0082-ETHD-038) +2. Ability to query historic data sent by an oracle data source and processed by vega network (0082-ETHD-039) ### Checkpoints -1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints (0082-ETHD-038) -2. Restart a network with an active external data source from checkpoint. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0082-ETHD-039) +1. Oracle data sources should be stored in checkpoints and should be restored when restarting a network from checkpoints. Therefore enacted markets with termination or settlement ethereum data sources are able to terminate and settle correctly post restart. (0082-ETHD-040) +2. Ensure that any ethereum oracle events that were generated during network downtime are correctly processed as soon as the network is restored and operational. This means that any termination or settlement actions that would of occurred during downtime are immediately actioned when network is up and we ensure they are processed in sequenced that they were received by the core polling. (0082-ETHD-041) ### Snapshots -1. Oracle data sources should be stored on snapshots and should be able to be restored from snapshots (0082-ETHD-040) -2. Restart a network with an active external data source from snapshot. Ensure the data source is active and either catches up all missed events or starts processing new events based on config (0082-ETHD-041) +1. Oracle data sources linked to markets should be stored on snapshots and should be able to be restored from snapshots. The states of the oracle data sources should be maintained across any markets where they are linked to ethereum data sources. (0082-ETHD-042) ### Protocol Upgrade -1. Create / amend an external oracle data source and before it is enacted perform a protocol upgrade. The oracle data source should be enacted at the correct time after the upgrade (0082-ETHD-042) -2. Create / amend an external oracle data source with enactment time that falls during a protocol upgrade. The oracle data source should be enacted immediately after the network is up after the protocol upgrade (0082-ETHD-043) -3. Phase 2 - Have a network running g with a mix of internal and external active and inactive oracles. Perform a protocol upgrade. Once the network is up , the state of the various oracles should be the same as before the protocol upgrade and either catch up all missed events or start processing new events based on config (0082-ETHD-044) - -### Regression - -1. The ethereum oracles feature ONLY changes the way we source the data BUT does not change the way the sourced data is filtered / processed / used by the system . So in theory all existing oracle data sourcing tests should pass. In addition , it should be possible to run the existing tests by swapping the interval oracle data source for an external one (0082-ETHD-045) +1. Have a network running with a couple of futures markets with a mix of internal, external, open and ethereum oracles. Perform a protocol upgrade. Once the network is up , the state of the various data sources should be the same as before the protocol upgrade (0082-ETHD-043) +2. Have a network running with a couple of perpetual markets with a mix of internal, external, open and ethereum oracles. Perform a protocol upgrade. Once the network is up , the state of the various data sources should be the same as before the protocol upgrade (0082-ETHD-044) +3. Create a futures market with an ethereum oracle for termination such that it polls at a specific time. Perform a protocol upgrade such that the termination triggers in the middle of the protocol upgrade. Once the network is up , the termination should be triggered and the market should be terminated. (0082-ETHD-045) +4. Create a perpetual market with an ethereum oracle for termination such that it polls at a specific time. Perform a protocol upgrade such that the termination triggers in the middle of the protocol upgrade. Once the network is up , the termination should be triggered and the market should be terminated. (0082-ETHD-046) +5. Create a futures market with an ethereum oracle for settlement such that it polls at a specific time. Perform a protocol upgrade such that the settlement price matching the filters is triggered in the middle of the protocol upgrade. Once the network is up , the settlement should be triggered and the market should be terminated. (0082-ETHD-047) +6. Create a perpetual market with an ethereum oracle for settlement such that it polls at a specific time. Perform a protocol upgrade such that the settlement price matching the filters is triggered in the middle of the protocol upgrade. Once the network is up , the settlement should be triggered and the market should be terminated. (0082-ETHD-048) +7. Ensure that markets with ethereum termination and settlement data sources continue to successfully terminate and settle markets after the protocol upgrade. (0082-ETHD-049) diff --git a/protocol/features.json b/protocol/features.json index 1963a77b4..972951f7b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -150,7 +150,10 @@ "0042-LIQF-033", "0042-LIQF-034", "0081-SUCM-001", + "0081-SUCM-002", "0081-SUCM-003", + "0081-SUCM-004", + "0081-SUCM-015", "0081-SUCM-005", "0081-SUCM-006", "0081-SUCM-007", @@ -160,23 +163,23 @@ "0081-SUCM-010", "0081-SUCM-011", "0081-SUCM-014", + "0081-SUCM-028", "0081-SUCM-018", "0081-SUCM-012", "0081-SUCM-023", "0081-SUCM-024", "0081-SUCM-013", "0081-SUCM-016", + "0081-SUCM-029", + "0081-SUCM-030", + "0081-SUCM-031", + "0081-SUCM-032", "0081-SUCM-017", "0081-SUCM-025", "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", - "0081-SUCM-022", - "0081-SUCM-028", - "0081-SUCM-029", - "0081-SUCM-030", - "0081-SUCM-031", - "0081-SUCM-032" + "0081-SUCM-022" ] }, "Perps": { @@ -556,17 +559,15 @@ "0082-ETHD-001", "0082-ETHD-002", "0082-ETHD-003", - "0082-ETHD-004", "0082-ETHD-005", "0082-ETHD-006", "0082-ETHD-007", - "0082-ETHD-008", - "0082-ETHD-009", "0082-ETHD-010", "0082-ETHD-011", "0082-ETHD-012", "0082-ETHD-013", "0082-ETHD-014", + "0082-ETHD-015", "0082-ETHD-016", "0082-ETHD-017", "0082-ETHD-018", @@ -577,15 +578,11 @@ "0082-ETHD-023", "0082-ETHD-024", "0082-ETHD-025", - "0082-ETHD-026", - "0082-ETHD-027", "0082-ETHD-028", "0082-ETHD-029", "0082-ETHD-030", "0082-ETHD-034", "0082-ETHD-035", - "0082-ETHD-036", - "0082-ETHD-037", "0082-ETHD-038", "0082-ETHD-039", "0082-ETHD-040", @@ -594,13 +591,19 @@ "0082-ETHD-043", "0082-ETHD-044", "0082-ETHD-045", - "0082-ETHD-046" + "0082-ETHD-046", + "0082-ETHD-047", + "0082-ETHD-048", + "0082-ETHD-049" ] }, "SLA": { "milestone": "deployment-2", "acs": [ "0042-LIQF-032", + "0042-LIQF-050", + "0042-LIQF-051", + "0042-LIQF-052", "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", @@ -615,27 +618,39 @@ "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", - "0042-LIQF-050", - "0042-LIQF-051", - "0042-LIQF-052", + "0044-LIME-057", + "0044-LIME-058", + "0044-LIME-059", "0044-LIME-013", "0044-LIME-014", + "0044-LIME-048", "0044-LIME-015", + "0044-LIME-046", "0044-LIME-016", + "0044-LIME-047", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", "0044-LIME-021", "0044-LIME-030", "0044-LIME-031", + "0044-LIME-049", "0044-LIME-022", "0044-LIME-023", - "0044-LIME-030", + "0044-LIME-045", "0044-LIME-024", - "0044-LIME-031", + "0044-LIME-044", "0044-LIME-025", + "0044-LIME-043", "0044-LIME-026", "0044-LIME-027", + "0044-LIME-050", + "0044-LIME-054", + "0044-LIME-051", + "0044-LIME-055", + "0044-LIME-053", + "0044-LIME-052", + "0044-LIME-056", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", @@ -643,30 +658,8 @@ "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", - "0044-LIME-037", - "0044-LIME-038", - "0044-LIME-039", - "0044-LIME-040", - "0044-LIME-041", - "0044-LIME-042", - "0044-LIME-043", - "0044-LIME-044", - "0044-LIME-045", - "0044-LIME-046", - "0044-LIME-047", - "0044-LIME-048", - "0044-LIME-049", - "0044-LIME-050", - "0044-LIME-051", - "0044-LIME-052", - "0044-LIME-053", - "0044-LIME-054", - "0044-LIME-055", - "0044-LIME-056", - "0044-LIME-057", - "0044-LIME-058", - "0044-LIME-059", - "0026-AUCT-017", + "0026-AUCT-016", + "0026-AUCT-047", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", diff --git a/wordlist.txt b/wordlist.txt index b1e92ecbf..be1231188 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -308,6 +308,7 @@ wBTC whitepaper Yubikey $VEGA +DS teamUrl avatarUrl dApp From df9fbcc74e5ab86012b61f01b1990c1ca562591c Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 9 Aug 2023 09:49:01 +0100 Subject: [PATCH 422/649] fix: duplicated ACs across features and implement a check in makefile (#1885) * fix: duplicated ACs across features * feat: add checker to make file * fix: Cannot index string with string error --- makefile | 7 ++++++- protocol/features.json | 28 ---------------------------- 2 files changed, 6 insertions(+), 29 deletions(-) diff --git a/makefile b/makefile index 1cafcf49f..18bceb853 100644 --- a/makefile +++ b/makefile @@ -1,7 +1,7 @@ # Set default to run all checks if none specified .DEFAULT_GOAL := all -all: spellcheck markdownlint names codes references links clean +all: spellcheck markdownlint names codes references links featureacs clean # Check that all the specifications are named appropriately .PHONY: names @@ -61,5 +61,10 @@ markdownlint: spellcheck: @./spellcheck.sh +# Checks for duplicated ACs in the features.json file +.PHONY: featureacs +featureacs: + jq -r '.. | .[]? | .acs?' -s < protocol/features.json | sort | uniq -d + clean: rm -rf $(TEMP) diff --git a/protocol/features.json b/protocol/features.json index 972951f7b..8468912db 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -143,7 +143,6 @@ "0001-MKTF-009", "0001-MKTF-010", "0028-GOVE-071", - "0028-GOVE-072", "0028-GOVE-093", "0042-LIQF-031", "0042-LIQF-048", @@ -152,7 +151,6 @@ "0081-SUCM-001", "0081-SUCM-002", "0081-SUCM-003", - "0081-SUCM-004", "0081-SUCM-015", "0081-SUCM-005", "0081-SUCM-006", @@ -265,20 +263,8 @@ "0073-LIMN-084", "0073-LIMN-085", "0073-LIMN-086", - "0073-LIMN-087", "0073-LIMN-088", "0073-LIMN-089", - "0073-LIMN-090", - "0073-LIMN-091", - "0073-LIMN-092", - "0073-LIMN-093", - "0073-LIMN-094", - "0073-LIMN-095", - "0073-LIMN-096", - "0073-LIMN-097", - "0073-LIMN-098", - "0073-LIMN-099", - "0073-LIMN-100", "0037-OPEG-019", "0008-TRAD-008", "0004-AMND-030", @@ -521,13 +507,6 @@ "0070-MKTD-013", "0070-MKTD-014", "0070-MKTD-015", - "0073-LIMN-077", - "0073-LIMN-078", - "0073-LIMN-080", - "0073-LIMN-082", - "0073-LIMN-083", - "0073-LIMN-084", - "0073-LIMN-086", "0073-LIMN-087", "0073-LIMN-090", "0073-LIMN-091", @@ -604,7 +583,6 @@ "0042-LIQF-050", "0042-LIQF-051", "0042-LIQF-052", - "0042-LIQF-034", "0042-LIQF-037", "0042-LIQF-038", "0042-LIQF-041", @@ -623,11 +601,8 @@ "0044-LIME-059", "0044-LIME-013", "0044-LIME-014", - "0044-LIME-048", "0044-LIME-015", - "0044-LIME-046", "0044-LIME-016", - "0044-LIME-047", "0044-LIME-018", "0044-LIME-019", "0044-LIME-020", @@ -637,11 +612,8 @@ "0044-LIME-049", "0044-LIME-022", "0044-LIME-023", - "0044-LIME-045", "0044-LIME-024", - "0044-LIME-044", "0044-LIME-025", - "0044-LIME-043", "0044-LIME-026", "0044-LIME-027", "0044-LIME-050", From 977ec5d9049d57d126697d64166e775e3496188d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 9 Aug 2023 10:45:49 +0100 Subject: [PATCH 423/649] feat: update ac 007 --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index e14c7d322..89ee23387 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -73,7 +73,7 @@ Two proposals that name the same parent can be submitted. Both can be approved b A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, there is no transfer into the insurance pool of the new market from the parent and the new market has no parent market Id set (0081-SUCM-007) +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, the successor market is not a successor market anymore, it's just a market like any other, and the insurance pool balance will be distributed equally across all markets with the same settlement asset, including those markets which are still in opening auction (0081-SUCM-007) Successor markets cannot be enacted if the parent market is still in the "proposed" state. Successor market proposals can be submitted when the parent market is still in proposed state. When the voting period for the successor market ends then either: a) the parent market is already enacted in which case the successor market moves from "proposed" in to opening auction/"pending" state. Or the parent market is still in "proposed" state in which case successor market is rejected. (0081-SUCM-008) From 17344f38e73d399b34f42eb12747bee8982e991c Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 9 Aug 2023 10:48:02 +0100 Subject: [PATCH 424/649] fix: corrected case 2 for current behaviour --- protocol/0073-LIMN-limited_network_life.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 131942ec1..170f5af1f 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -137,8 +137,7 @@ for product spot: (0073-LIMN-101 Date: Wed, 9 Aug 2023 13:12:15 +0100 Subject: [PATCH 425/649] fix: undistributed LP fees go to their general account on LNL checkpoint --- protocol/0073-LIMN-limited_network_life.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 74f6ae13c..3e945c6fa 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -34,7 +34,7 @@ Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_ - All market proposals ([creation](../protocol/0028-GOVE-governance.md#1-create-market) and [update](../protocol/0028-GOVE-governance.md#2-change-market-parameters)) that have been *accepted* but not those where the market already started trading and reached *trading terminated* state. - All [asset proposals](../protocol/0028-GOVE-governance.md) that have been *accepted*. - All delegation info. -- [LP fee pool](../protocol/0029-FEES-fees.md) for undistributed LP fee balances on a market will be added to the into the network treasury for the asset balances. +- [LP fee pool](../protocol/0029-FEES-fees.md) for undistributed LP fee balances on a market will be added to the LP's general account balances (without applying any SLA penalties). - On chain treasury balances and on-chain rewards for staking and delegation [Staking and delegation](../protocol/0056-REWA-rewards_overview.md). - [Account balances](../protocol/0013-ACCT-accounts.md) for all parties per asset: sum of general, margin and LP bond accounts. - Event ID of the last processed deposit event for all bridged chains From 6472dd6c48a75065bd96f2ba4f1235d4b7209d30 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 9 Aug 2023 13:14:19 +0100 Subject: [PATCH 426/649] fix: linting --- protocol/0073-LIMN-limited_network_life.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 3e945c6fa..02f7346f7 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -34,7 +34,7 @@ Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_ - All market proposals ([creation](../protocol/0028-GOVE-governance.md#1-create-market) and [update](../protocol/0028-GOVE-governance.md#2-change-market-parameters)) that have been *accepted* but not those where the market already started trading and reached *trading terminated* state. - All [asset proposals](../protocol/0028-GOVE-governance.md) that have been *accepted*. - All delegation info. -- [LP fee pool](../protocol/0029-FEES-fees.md) for undistributed LP fee balances on a market will be added to the LP's general account balances (without applying any SLA penalties). +- [LP fee pool](../protocol/0029-FEES-fees.md) for undistributed LP fee balances on a market will be added to the LP's general account balances (without applying any SLA penalties). - On chain treasury balances and on-chain rewards for staking and delegation [Staking and delegation](../protocol/0056-REWA-rewards_overview.md). - [Account balances](../protocol/0013-ACCT-accounts.md) for all parties per asset: sum of general, margin and LP bond accounts. - Event ID of the last processed deposit event for all bridged chains From 5a17f6de054969f16a0267520ed2927e276a4237 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 9 Aug 2023 14:13:18 +0100 Subject: [PATCH 427/649] refactor: clarify parameter and variable terms --- .../0083-RFPR-on_chain_referral_program.md | 52 +++++++++---------- protocol/0084-VDPR-volume_discount_program.md | 24 ++++----- 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index f34b5a09e..dba8e0579 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -29,7 +29,7 @@ To create an emphasis on community, collaboration, and competition. Referrers wi - `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal -- `referralProgram.maxPartyVolumePerEpoch` - limits the volume in quantum units which is eligible each epoch for referral program mechanisms +- `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` - limits the volume in quantum units which is eligible each epoch for referral program mechanisms - `referralProgram.minStakedVegaTokens` - limits referral code generation to parties staking at least this number of tokens ## Governance Proposals @@ -37,31 +37,31 @@ To create an emphasis on community, collaboration, and competition. Referrers wi Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: - `benefit_tiers`: a list of dictionaries with the following fields - - `minimum_running_taker_volume`: the required [`referral_set_running_taker_volume`](#referral-set-volumes) in quantum units for parties to access this tier + - `minimum_running_notional_taker_volume`: the required [`referral_set_running_notional_taker_volume`](#referral-set-volumes) in quantum units for parties to access this tier - `minimum_epochs`: the required number of epochs a party must have been in a referral set to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted - `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled -- `window_length`: the number of epochs over which to evaluate a referral sets running volume +- `window_length`: the number of epochs over which to evaluate a referral sets running notional taker volume ```protobuf message UpdateReferralProgram{ changes: UpdateReferralProgramConfiguration{ benefit_tiers: [ { - "minimum_running_taker_volume": 10000, + "minimum_running_notional_taker_volume": 10000, "minimum_epochs": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { - "minimum_running_taker_volume": 20000, + "minimum_running_notional_taker_volume": 20000, "minimum_epochs": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { - "minimum_running_taker_volume": 30000, + "minimum_running_notional_taker_volume": 30000, "minimum_epochs": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, @@ -195,25 +195,25 @@ If a party is not currently a referee, they must immediately be added to the ref ### Party volumes -The network must now track the cumulative volume of taker trades for each party in an epoch, call this value `party_epoch_taker_volume`. Note, trades generated by auction uncrossing are not counted. Each time a eligible trade is generated, the network should increment a parties `party_epoch_taker_volume` by the quantum volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). +The network must now track the cumulative notional volume of taker trades for each party in an epoch, call this value `party_epoch_notional_taker_volume`. Note, trades generated by auction uncrossing are not counted. Each time a eligible trade is generated, the network should increment a parties `party_epoch_notional_taker_volume` by the quantum notional volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo -party_epoch_taker_volume = party_epoch_taker_volume + (trade_price * trade_size * settlement_asset_quantum) +party_epoch_notional_taker_volume = party_epoch_notional_taker_volume + (trade_price * trade_size * settlement_asset_quantum) ``` -At the end of an epoch, the `party_epoch_taker_volume` is stored by the network and each parties `party_epoch_taker_volume` is reset to `0` ready for the next epoch. +At the end of an epoch, the `party_epoch_notional_taker_volume` is stored by the network and each parties `party_epoch_notional_taker_volume` is reset to `0` ready for the next epoch. ### Referral set volumes -At the end of an epoch, for each referral set, a `referral_set_epoch_taker_volume` is calculated by summing the `party_epoch_taker_volume` of each party in the referral set (include both referrers and referees). The amount a party can contribute to their referral set is capped by the network parameter `referralProgram.maxPartyVolumePerEpoch`. Note this cap is not applied directly to `party_epoch_taker_volume` in case the network parameter is updated during an epoch. +At the end of an epoch, for each referral set, a `referral_set_epoch_notional_taker_volume` is calculated by summing the `party_epoch_notional_taker_volume` of each party in the referral set (include both referrers and referees). The amount a party can contribute to their referral set is capped by the network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch`. Note this cap is not applied directly to `party_epoch_notional_taker_volume` in case the network parameter is updated during an epoch. ```pseudo -referral_set_epoch_taker_volume = sum[min(party_epoch_taker_volume, referralProgram.maxPartyVolumePerEpoch) for each party in team] +referral_set_epoch_notional_taker_volume = sum[min(party_epoch_notional_taker_volume, referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch) for each party in team] ``` -After the values are calculated, the `referral_set_epoch_taker_volume` is stored by the network. +After the values are calculated, the `referral_set_epoch_notional_taker_volume` is stored by the network. -The network can then calculate the sets `referral_set_running_taker_volume` by summing the sets `referral_set_epoch_taker_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). +The network can then calculate the sets `referral_set_running_notional_taker_volume` by summing the sets `referral_set_epoch_notional_taker_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). ## Benefit mechanics @@ -225,7 +225,7 @@ Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pe The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. -- `referral_set_running_taker_volume` is greater than or equal to the tiers `minimum_running_taker_volume`. +- `referral_set_running_notional_taker_volume` is greater than or equal to the tiers `minimum_running_notional_taker_volume`. The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. @@ -233,7 +233,7 @@ The referees `referral_reward_factor` is then set to the `referral_reward_factor The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. -- `referral_set_running_taker_volume` is greater than or equal to the tiers `minimum_running_taker_volume`. +- `referral_set_running_notional_taker_volume` is greater than or equal to the tiers `minimum_running_notional_taker_volume`. - the referee has been a associated with the referral set for at least the tiers `minimum_epochs`. The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. @@ -244,19 +244,19 @@ The referees `referral_discount_factor` is then set to the `referral_discount_fa Given: benefit_tiers: [ { - "minimum_running_taker_volume": 10000, + "minimum_running_notional_taker_volume": 10000, "minimum_epochs": 0, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, { - "minimum_running_taker_volume": 20000, + "minimum_running_notional_taker_volume": 20000, "minimum_epochs": 7, "referral_reward_factor": 0.005, "referral_discount_factor": 0.005, }, { - "minimum_running_taker_volume": 30000, + "minimum_running_notional_taker_volume": 30000, "minimum_epochs": 31, "referral_reward_factor": 0.010, "referral_discount_factor": 0.010, @@ -264,7 +264,7 @@ Given: ] And: - referral_set_running_taker_volume=22353 + referral_set_running_notional_taker_volume=22353 party_epochs_in_referral_set=4 Then: @@ -285,7 +285,7 @@ The Parties API should now return a list of all **parties** (which can be filter - current `id` of the referral set the party is associated with - current `epochs_in_referral_set` -- current `party_epoch_taker_volume` +- current `party_epoch_notional_taker_volume` - current `referral_reward_factor` - current `referral_discount_factor` - for each asset, the total referral rewards generated by the parties taker fees @@ -295,7 +295,7 @@ The ReferralSet API should now expose a list of all **referral sets** (which can - the sets founding **referrer** - the sets **referees** -- current `referral_set_running_taker_volume` +- current `referral_set_running_notional_taker_volume` - current `referral_reward_factor` applied to referee taker fees - current **maximum possible** `referral_discount_factor` applied to referee taker fees - for each asset, the total referral rewards generated by all referee taker fees @@ -384,11 +384,11 @@ The Estimate Fees API should now calculate the following additional information: #### Epoch and running volumes -1. Each trade should increment the taker parties `party_epoch_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). -1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_taker_volume` (0083-RFPR-032). -1. At the end of the epoch, the `referral_set_epoch_taker_volume` should be correctly calculated by summing each team members `party_epoch_taker_volume` (0083-RFPR-033). -1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyVolumePerEpoch` to their sets `referral_set_epoch_taker_volume` (0083-RFPR-034). -1. A referral sets `referral_set_running_taker_volume` is calculated as the sum of all `referral_set_epoch_taker_volumes` over the last `epoch_window` epochs (0083-RFPR-035). +1. Each trade should increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). +1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_notional_taker_volume` (0083-RFPR-032). +1. At the end of the epoch, the `referral_set_epoch_notional_taker_volume` should be correctly calculated by summing each team members `party_epoch_notional_taker_volume` (0083-RFPR-033). +1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` to their sets `referral_set_epoch_notional_taker_volume` (0083-RFPR-034). +1. A referral sets `referral_set_running_notional_taker_volume` is calculated as the sum of all `referral_set_epoch_notional_taker_volumes` over the last `epoch_window` epochs (0083-RFPR-035). ### Benefit Mechanics diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index d5b852e64..358525484 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -12,25 +12,25 @@ The volume discount program provides tiered discounts on taker fees to traders. Enabling or changing the terms of the volume discount program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: - `benefit_tiers`: a list of dictionaries with the following fields - - `minimum_party_running_taker_volume`: the required `party_running_taker_volume` in quantum units for a party to access this tier + - `minimum_party_running_notional_taker_volume`: the required `party_running_notional_taker_volume` in quantum units for a party to access this tier - `volume_discount_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled. If this field is empty, the program runs indefinitely. -- `window_length`: the number of epochs over which to evaluate a parties running volume +- `window_length`: the number of epochs over which to evaluate a parties notional running volume ```protobuf message UpdateVolumeDiscountProgram{ changes: UpdateReferralProgramConfiguration{ benefit_tiers: [ { - "minimum_party_running_taker_volume": 1000, + "minimum_party_running_notional_taker_volume": 1000, "volume_discount_factor": 0.001, }, { - "minimum_party_running_taker_volume": 20000, + "minimum_party_running_notional_taker_volume": 20000, "volume_discount_factor": 0.002, }, { - "minimum_party_running_taker_volume": 30000, + "minimum_party_running_notional_taker_volume": 30000, "volume_discount_factor": 0.003, }, ], @@ -64,29 +64,29 @@ After a volume discount program [proposal](#governance-proposals) is validated a ### Setting benefit factors -At the start of an epoch the network should calculate each parties `party_running_taker_volume` by summing each parties `party_epoch_volume` [values](./0082-RFPR-on_chain_referral_program.md#party-epoch-volumes) over the last n epochs where n is the `window_length` set in the volume discount program [governance proposal](#governance-proposals). +At the start of an epoch the network should calculate each parties `party_running_notional_taker_volume` by summing each parties `party_epoch_notional_volume` [values](./0082-RFPR-on_chain_referral_program.md#party-epoch-volumes) over the last n epochs where n is the `window_length` set in the volume discount program [governance proposal](#governance-proposals). -Each parties `volume_discount_factor` is then fixed to the value in the highest benefit tier they qualify for. A parties benefit tier is defined as the highest tier for which their `party_running_taker_volume` is greater or equal to the tiers `minimum_party_running_taker_volume`. If a party does not qualify for any tier, their `volume_discount_factor` is set to `0`. +Each parties `volume_discount_factor` is then fixed to the value in the highest benefit tier they qualify for. A parties benefit tier is defined as the highest tier for which their `party_running_notional_taker_volume` is greater or equal to the tiers `minimum_party_running_notional_taker_volume`. If a party does not qualify for any tier, their `volume_discount_factor` is set to `0`. ```pseudo Given: benefit_tiers=[ { - "minimum_party_running_taker_volume": 10000, + "minimum_party_running_notional_taker_volume": 10000, "volume_discount_factor": 0.001, }, { - "minimum_party_running_taker_volume": 20000, + "minimum_party_running_notional_taker_volume": 20000, "volume_discount_factor": 0.005, }, { - "minimum_party_running_taker_volume": 30000, + "minimum_party_running_notional_taker_volume": 30000, "volume_discount_factor": 0.010, }, ] And: - party_running_taker_volume=22353 + party_running_notional_taker_volume=22353 Then: volume_discount_factor=0.005 @@ -103,7 +103,7 @@ Volume discount program benefit factors are applied by modifying [the fees](./00 The Parties API should expose the following information: - a list of all **parties** (by `id`) and the following metrics: - - current `party_running_taker_volume` (value at the start of the epoch) + - current `party_running_notional_taker_volume` (value at the start of the epoch) - current `volume_discount_factor` applied to fees - the total amount discounted for the party From 3cfe03f9395b27c3f036952f18b6d4cbcdfce566 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 9 Aug 2023 14:16:39 +0100 Subject: [PATCH 428/649] refactor: clarify description --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index dba8e0579..6af261223 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -29,7 +29,7 @@ To create an emphasis on community, collaboration, and competition. Referrers wi - `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal -- `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` - limits the volume in quantum units which is eligible each epoch for referral program mechanisms +- `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` - limits the notional volume in quantum units which is eligible each epoch for referral program mechanisms - `referralProgram.minStakedVegaTokens` - limits referral code generation to parties staking at least this number of tokens ## Governance Proposals From 131567e86f05a82d91943dd5de3130c96d90b6e9 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 9 Aug 2023 15:40:13 +0100 Subject: [PATCH 429/649] fix: the AC codes for the SLA coverage metrics (#1893) --- protocol/features.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index f13f8e826..bab9e5b73 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -645,7 +645,7 @@ "0044-LIME-035", "0044-LIME-036", "0026-AUCT-016", - "0026-AUCT-047", + "0026-AUCT-017", "0026-AUCT-018", "0026-AUCT-019", "0026-AUCT-020", From 40bc4def1e48bd697308884c61f46bb0bbdaac14 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 10 Aug 2023 11:32:56 +0100 Subject: [PATCH 430/649] chore: update successor market ACs and the feature linkings (#1894) --- protocol/0081-SUCM-successor_markets.md | 5 +- protocol/features.json | 114 ++++++++++++------------ 2 files changed, 62 insertions(+), 57 deletions(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 89ee23387..c5bda89b5 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -62,7 +62,10 @@ At the end of opening auction, if the parent market still exists, the fraction o Market proposal may specify parent market ID. If it does then: - It must also specify insurance pool fraction (0081-SUCM-001) -- The product type, settlement asset and margin asset must match between parent and successor; if not proposal is rejected (0081-SUCM-002) +- The product type, settlement asset and margin asset must match between parent and successor; if not proposal is rejected: + - futures to perpetuals (0081-SUCM-002) + - perpetuals to spot (0081-SUCM-033) + - spot to futures (0081-SUCM-034) - It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). diff --git a/protocol/features.json b/protocol/features.json index bab9e5b73..85dc215f9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,56 +1,4 @@ { - "Governance Transfers": { - "milestone": "deployment-1", - "acs": [ - "0028-GOVE-073", - "0028-GOVE-074", - "0028-GOVE-128", - "0028-GOVE-119", - "0028-GOVE-120", - "0028-GOVE-132", - "0028-GOVE-122", - "0028-GOVE-077", - "0028-GOVE-079", - "0028-GOVE-081", - "0028-GOVE-082", - "0028-GOVE-083", - "0028-GOVE-084", - "0028-GOVE-085", - "0028-GOVE-086", - "0028-GOVE-087", - "0028-GOVE-088", - "0028-GOVE-089", - "0028-GOVE-091", - "0028-GOVE-092", - "0028-GOVE-094", - "0028-GOVE-095", - "0028-GOVE-096", - "0028-GOVE-099", - "0028-GOVE-100", - "0028-GOVE-101", - "0028-GOVE-102", - "0028-GOVE-130", - "0028-GOVE-131", - "0028-GOVE-103", - "0028-GOVE-133", - "0028-GOVE-129", - "0028-GOVE-104", - "0028-GOVE-105", - "0028-GOVE-106", - "0028-GOVE-107", - "0028-GOVE-123", - "0028-GOVE-124", - "0028-GOVE-125", - "0028-GOVE-126", - "0028-GOVE-127", - "0028-GOVE-140", - "0028-GOVE-141", - "0028-GOVE-142", - "0028-GOVE-143", - "0028-GOVE-144", - "0055-TREA-011" - ] - }, "Iceberg Orders": { "milestone": "deployment-1", "acs": [ @@ -149,9 +97,7 @@ "0042-LIQF-033", "0042-LIQF-034", "0081-SUCM-001", - "0081-SUCM-002", "0081-SUCM-003", - "0081-SUCM-015", "0081-SUCM-005", "0081-SUCM-006", "0081-SUCM-007", @@ -179,6 +125,58 @@ "0081-SUCM-021", "0081-SUCM-022" ] + }, + "Governance Transfers": { + "milestone": "deployment-2", + "acs": [ + "0028-GOVE-073", + "0028-GOVE-074", + "0028-GOVE-128", + "0028-GOVE-119", + "0028-GOVE-120", + "0028-GOVE-132", + "0028-GOVE-122", + "0028-GOVE-077", + "0028-GOVE-079", + "0028-GOVE-081", + "0028-GOVE-082", + "0028-GOVE-083", + "0028-GOVE-084", + "0028-GOVE-085", + "0028-GOVE-086", + "0028-GOVE-087", + "0028-GOVE-088", + "0028-GOVE-089", + "0028-GOVE-091", + "0028-GOVE-092", + "0028-GOVE-094", + "0028-GOVE-095", + "0028-GOVE-096", + "0028-GOVE-099", + "0028-GOVE-100", + "0028-GOVE-101", + "0028-GOVE-102", + "0028-GOVE-130", + "0028-GOVE-131", + "0028-GOVE-103", + "0028-GOVE-133", + "0028-GOVE-129", + "0028-GOVE-104", + "0028-GOVE-105", + "0028-GOVE-106", + "0028-GOVE-107", + "0028-GOVE-123", + "0028-GOVE-124", + "0028-GOVE-125", + "0028-GOVE-126", + "0028-GOVE-127", + "0028-GOVE-140", + "0028-GOVE-141", + "0028-GOVE-142", + "0028-GOVE-143", + "0028-GOVE-144", + "0055-TREA-011" + ] }, "Perps": { "milestone": "deployment-2", @@ -209,7 +207,9 @@ "0073-LIMN-108", "0073-LIMN-109", "0073-LIMN-110", - "0073-LIMN-111" + "0073-LIMN-111", + "0081-SUCM-002", + "0081-SUCM-015" ] }, "Spot": { @@ -543,7 +543,9 @@ "0074-BTCH-016", "0074-BTCH-019", "0079-TGAP-006", - "0079-TGAP-007" + "0079-TGAP-007", + "0081-SUCM-033", + "0081-SUCM-034" ] }, "Ethereum Oracles": { From d9e98840aeb9a8a8fa8a75c64985a094b6b03b8e Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 10 Aug 2023 15:12:22 +0100 Subject: [PATCH 431/649] fix: more clean up of the features.json file (#1895) --- protocol/features.json | 399 ++++++++++++++++++++--------------------- 1 file changed, 198 insertions(+), 201 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 85dc215f9..446430b1a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -212,23 +212,213 @@ "0081-SUCM-015" ] }, - "Spot": { + + "Ethereum Oracles": { + "milestone": "deployment-2", + "acs": [ + "0082-ETHD-001", + "0082-ETHD-002", + "0082-ETHD-003", + "0082-ETHD-005", + "0082-ETHD-006", + "0082-ETHD-007", + "0082-ETHD-010", + "0082-ETHD-011", + "0082-ETHD-012", + "0082-ETHD-013", + "0082-ETHD-014", + "0082-ETHD-015", + "0082-ETHD-016", + "0082-ETHD-017", + "0082-ETHD-018", + "0082-ETHD-019", + "0082-ETHD-020", + "0082-ETHD-021", + "0082-ETHD-022", + "0082-ETHD-023", + "0082-ETHD-024", + "0082-ETHD-025", + "0082-ETHD-028", + "0082-ETHD-029", + "0082-ETHD-030", + "0082-ETHD-034", + "0082-ETHD-035", + "0082-ETHD-038", + "0082-ETHD-039", + "0082-ETHD-040", + "0082-ETHD-041", + "0082-ETHD-042", + "0082-ETHD-043", + "0082-ETHD-044", + "0082-ETHD-045", + "0082-ETHD-046", + "0082-ETHD-047", + "0082-ETHD-048", + "0082-ETHD-049" + ] + }, + "SLA": { "milestone": "deployment-2", + "acs": [ + "0042-LIQF-032", + "0042-LIQF-050", + "0042-LIQF-051", + "0042-LIQF-052", + "0042-LIQF-037", + "0042-LIQF-038", + "0042-LIQF-041", + "0042-LIQF-042", + "0042-LIQF-035", + "0042-LIQF-049", + "0042-LIQF-047", + "0042-LIQF-039", + "0042-LIQF-040", + "0042-LIQF-043", + "0042-LIQF-044", + "0042-LIQF-045", + "0042-LIQF-046", + "0044-LIME-057", + "0044-LIME-058", + "0044-LIME-059", + "0044-LIME-013", + "0044-LIME-014", + "0044-LIME-015", + "0044-LIME-016", + "0044-LIME-018", + "0044-LIME-019", + "0044-LIME-020", + "0044-LIME-021", + "0044-LIME-030", + "0044-LIME-031", + "0044-LIME-049", + "0044-LIME-022", + "0044-LIME-023", + "0044-LIME-024", + "0044-LIME-025", + "0044-LIME-026", + "0044-LIME-027", + "0044-LIME-050", + "0044-LIME-051", + "0044-LIME-053", + "0044-LIME-052", + "0044-LIME-028", + "0044-LIME-029", + "0044-LIME-032", + "0044-LIME-033", + "0044-LIME-034", + "0044-LIME-035", + "0044-LIME-036", + "0026-AUCT-016", + "0026-AUCT-017", + "0026-AUCT-018", + "0026-AUCT-019", + "0026-AUCT-020", + "0026-AUCT-021", + "0026-AUCT-022" + ] + }, + "Batch change proposals": { + "milestone": "deployment-2", + "acs": [ + "0028-GOVE-145", + "0028-GOVE-146", + "0028-GOVE-147", + "0028-GOVE-148", + "0028-GOVE-149" + ] + }, + "Referral program": { + "milestone": "deployment-2", + "acs": [ + "0083-RFPR-001", + "0083-RFPR-002", + "0083-RFPR-003", + "0083-RFPR-004", + "0083-RFPR-005", + "0083-RFPR-006", + "0083-RFPR-007", + "0083-RFPR-008", + "0083-RFPR-009", + "0083-RFPR-010", + "0083-RFPR-011", + "0083-RFPR-012", + "0083-RFPR-013", + "0083-RFPR-014", + "0083-RFPR-015", + "0083-RFPR-016", + "0083-RFPR-017", + "0083-RFPR-018", + "0083-RFPR-019", + "0083-RFPR-020", + "0083-RFPR-021", + "0083-RFPR-022", + "0083-RFPR-023", + "0083-RFPR-024", + "0083-RFPR-025", + "0083-RFPR-026", + "0083-RFPR-027", + "0083-RFPR-028", + "0083-RFPR-029", + "0083-RFPR-030", + "0083-RFPR-031", + "0083-RFPR-032", + "0083-RFPR-033", + "0083-RFPR-034", + "0083-RFPR-035", + "0083-RFPR-036", + "0083-RFPR-037", + "0083-RFPR-038", + "0083-RFPR-039", + "0083-RFPR-040", + "0084-VDPR-001", + "0084-VDPR-002", + "0084-VDPR-003", + "0084-VDPR-004", + "0084-VDPR-005", + "0084-VDPR-006", + "0084-VDPR-007", + "0084-VDPR-008", + "0084-VDPR-009", + "0084-VDPR-010", + "0084-VDPR-011", + "0084-VDPR-012", + "0084-VDPR-013", + "0084-VDPR-014" + ] + }, + "Market governance": { + "milestone": "deployment-2", + "acs": [ + "0028-GOVE-064", + "0028-GOVE-069", + "0028-GOVE-070", + "0028-GOVE-072", + "0028-GOVE-110", + "0028-GOVE-113", + "0028-GOVE-118", + "0028-GOVE-135", + "0028-GOVE-136", + "0028-GOVE-137", + "0028-GOVE-138", + "0028-GOVE-139", + "0028-GOVE-111", + "0028-GOVE-150", + "0028-GOVE-151" + ] + }, + "Spot": { + "milestone": "deployment-3", "acs": [ "0080-SPOT-001", "0080-SPOT-002", "0080-SPOT-003", "0080-SPOT-004", - "0080-SPOT-005", "0080-SPOT-006", "0080-SPOT-007", - "0080-SPOT-008", "0080-SPOT-009", "0080-SPOT-010", - "0080-SPOT-011", "0080-SPOT-012", "0080-SPOT-013", - "0080-SPOT-014", "0080-SPOT-015", "0080-SPOT-016", "0080-SPOT-017", @@ -242,6 +432,9 @@ "0044-LIME-046", "0044-LIME-047", "0044-LIME-048", + "0044-LIME-054", + "0044-LIME-055", + "0044-LIME-056", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", @@ -548,202 +741,6 @@ "0081-SUCM-034" ] }, - "Ethereum Oracles": { - "milestone": "deployment-2", - "acs": [ - "0082-ETHD-001", - "0082-ETHD-002", - "0082-ETHD-003", - "0082-ETHD-005", - "0082-ETHD-006", - "0082-ETHD-007", - "0082-ETHD-010", - "0082-ETHD-011", - "0082-ETHD-012", - "0082-ETHD-013", - "0082-ETHD-014", - "0082-ETHD-015", - "0082-ETHD-016", - "0082-ETHD-017", - "0082-ETHD-018", - "0082-ETHD-019", - "0082-ETHD-020", - "0082-ETHD-021", - "0082-ETHD-022", - "0082-ETHD-023", - "0082-ETHD-024", - "0082-ETHD-025", - "0082-ETHD-028", - "0082-ETHD-029", - "0082-ETHD-030", - "0082-ETHD-034", - "0082-ETHD-035", - "0082-ETHD-038", - "0082-ETHD-039", - "0082-ETHD-040", - "0082-ETHD-041", - "0082-ETHD-042", - "0082-ETHD-043", - "0082-ETHD-044", - "0082-ETHD-045", - "0082-ETHD-046", - "0082-ETHD-047", - "0082-ETHD-048", - "0082-ETHD-049" - ] - }, - "SLA": { - "milestone": "deployment-2", - "acs": [ - "0042-LIQF-032", - "0042-LIQF-050", - "0042-LIQF-051", - "0042-LIQF-052", - "0042-LIQF-037", - "0042-LIQF-038", - "0042-LIQF-041", - "0042-LIQF-042", - "0042-LIQF-035", - "0042-LIQF-049", - "0042-LIQF-047", - "0042-LIQF-039", - "0042-LIQF-040", - "0042-LIQF-043", - "0042-LIQF-044", - "0042-LIQF-045", - "0042-LIQF-046", - "0044-LIME-057", - "0044-LIME-058", - "0044-LIME-059", - "0044-LIME-013", - "0044-LIME-014", - "0044-LIME-015", - "0044-LIME-016", - "0044-LIME-018", - "0044-LIME-019", - "0044-LIME-020", - "0044-LIME-021", - "0044-LIME-030", - "0044-LIME-031", - "0044-LIME-049", - "0044-LIME-022", - "0044-LIME-023", - "0044-LIME-024", - "0044-LIME-025", - "0044-LIME-026", - "0044-LIME-027", - "0044-LIME-050", - "0044-LIME-054", - "0044-LIME-051", - "0044-LIME-055", - "0044-LIME-053", - "0044-LIME-052", - "0044-LIME-056", - "0044-LIME-028", - "0044-LIME-029", - "0044-LIME-032", - "0044-LIME-033", - "0044-LIME-034", - "0044-LIME-035", - "0044-LIME-036", - "0026-AUCT-016", - "0026-AUCT-017", - "0026-AUCT-018", - "0026-AUCT-019", - "0026-AUCT-020", - "0026-AUCT-021", - "0026-AUCT-022" - ] - }, - "Batch change proposals": { - "milestone": "deployment-2", - "acs": [ - "0028-GOVE-145", - "0028-GOVE-146", - "0028-GOVE-147", - "0028-GOVE-148", - "0028-GOVE-149" - ] - }, - "Referral program": { - "milestone": "deployment-2", - "acs": [ - "0083-RFPR-001", - "0083-RFPR-002", - "0083-RFPR-003", - "0083-RFPR-004", - "0083-RFPR-005", - "0083-RFPR-006", - "0083-RFPR-007", - "0083-RFPR-008", - "0083-RFPR-009", - "0083-RFPR-010", - "0083-RFPR-011", - "0083-RFPR-012", - "0083-RFPR-013", - "0083-RFPR-014", - "0083-RFPR-015", - "0083-RFPR-016", - "0083-RFPR-017", - "0083-RFPR-018", - "0083-RFPR-019", - "0083-RFPR-020", - "0083-RFPR-021", - "0083-RFPR-022", - "0083-RFPR-023", - "0083-RFPR-024", - "0083-RFPR-025", - "0083-RFPR-026", - "0083-RFPR-027", - "0083-RFPR-028", - "0083-RFPR-029", - "0083-RFPR-030", - "0083-RFPR-031", - "0083-RFPR-032", - "0083-RFPR-033", - "0083-RFPR-034", - "0083-RFPR-035", - "0083-RFPR-036", - "0083-RFPR-037", - "0083-RFPR-038", - "0083-RFPR-039", - "0083-RFPR-040", - "0084-VDPR-001", - "0084-VDPR-002", - "0084-VDPR-003", - "0084-VDPR-004", - "0084-VDPR-005", - "0084-VDPR-006", - "0084-VDPR-007", - "0084-VDPR-008", - "0084-VDPR-009", - "0084-VDPR-010", - "0084-VDPR-011", - "0084-VDPR-012", - "0084-VDPR-013", - "0084-VDPR-014" - ] - }, - "Market governance": { - "milestone": "deployment-2", - "acs": [ - "0028-GOVE-064", - "0028-GOVE-069", - "0028-GOVE-070", - "0028-GOVE-072", - "0028-GOVE-110", - "0028-GOVE-113", - "0028-GOVE-118", - "0028-GOVE-135", - "0028-GOVE-136", - "0028-GOVE-137", - "0028-GOVE-138", - "0028-GOVE-139", - "0028-GOVE-111", - "0028-GOVE-150", - "0028-GOVE-151" - ] - }, "Unknown": { "milestone": "unknown", "acs": [] From f8da66046ebb68ef9937018fa2a274c5534ea091 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Fri, 11 Aug 2023 09:18:17 +0100 Subject: [PATCH 432/649] Update 0026-AUCT-auctions.md (#1897) make the difference between spot and futures clear --- protocol/0026-AUCT-auctions.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index eeb38ed26..083958f1d 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -157,13 +157,13 @@ message Market { ## Acceptance Criteria -- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003) for product spot: (0026-AUCT-023) -- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004) for product spot: (0026-AUCT-024) +- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). For product spot: (0026-AUCT-023) +- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) - As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) for product spot: (0068-MATC-060) -- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005)for product spot:(0026-AUCT-025) -- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006) for product spot: (0026-AUCT-026) -- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007) for product spot: (0026-AUCT-027) -- As an API user, I can identify: (0026-AUCT-008) for product spot: (0026-AUCT-028) +- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) +- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006).For product spot: (0026-AUCT-026) +- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) +- As an API user, I can identify: (0026-AUCT-008). For product spot: (0026-AUCT-028) - If a market is temporarily in an auction period - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. @@ -176,5 +176,5 @@ message Market { 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but after the auction uncrossing we will not have - best bid; it will still open. (0026-AUCT-021) - or best ask; it will still open. (0026-AUCT-022) -- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015) for product spot: (0026-AUCT-031) -- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016) for product spot: (0026-AUCT-032) +- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015). For product spot: (0026-AUCT-031) +- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016). For product spot: (0026-AUCT-032) From 2854214ba96e8ef5a30f1405a6d407db657ce6ea Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 11 Aug 2023 14:14:19 +0100 Subject: [PATCH 433/649] fix: readability For product spot --- protocol/0026-AUCT-auctions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 083958f1d..04e59c934 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -159,16 +159,16 @@ message Market { - The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). For product spot: (0026-AUCT-023) - As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) for product spot: (0068-MATC-060) +- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) For product spot: (0068-MATC-060) - As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) -- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006).For product spot: (0026-AUCT-026) +- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) - As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) - As an API user, I can identify: (0026-AUCT-008). For product spot: (0026-AUCT-028) - If a market is temporarily in an auction period - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017) for product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017). For product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) 2. past the enactment time if there is no [liquidity supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) 3. past the enactment time if [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) From 81f29b7d1db5731a0bf335f0161aae2caeb08d35 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 11 Aug 2023 14:19:30 +0100 Subject: [PATCH 434/649] fix: updated checkpoint ac --- protocol/0044-LIME-lp_mechanics.md | 4 +--- protocol/features.json | 1 - 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 4f8ccf2a7..bc4be3e8d 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -357,9 +357,7 @@ In the case of spot markets it will be transferred into the network treasury for ### Checkpoint -- Each market's aggregate LP fee accounts must be included in the checkpoint and where the network is down - - Rewards accrued during the down time will be actioned when the network is available (0044-LIME-034) - - Fees to be paid during the down time will be actioned when the network is available (0044-LIME-035) +- Each market's aggregate LP fee accounts must be included in the checkpoint and where the network is restored, the aggregate LP fee account balance will be transferred to the LP's general account. (0044-LIME-034) #### Network History - Data node restored from network history segments diff --git a/protocol/features.json b/protocol/features.json index 446430b1a..3835e70bb 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -306,7 +306,6 @@ "0044-LIME-032", "0044-LIME-033", "0044-LIME-034", - "0044-LIME-035", "0044-LIME-036", "0026-AUCT-016", "0026-AUCT-017", From 455285f20b5845f96d5c4e45b28c3175f3ff2856 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Sun, 13 Aug 2023 13:33:34 +0100 Subject: [PATCH 435/649] feat: new acs for LIME spec --- protocol/0044-LIME-lp_mechanics.md | 33 +++++++++++++++++++++++++++++- protocol/features.json | 22 ++++++++++++++++++++ 2 files changed, 54 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index bc4be3e8d..0da816084 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -26,7 +26,9 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. ### Market parameters -- `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. This is set / can be modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal. +All market parameters can be set / modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal and the new value take effect at at the first new epoch after enactment. + +- `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. - `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. @@ -293,6 +295,7 @@ Note: - GRPC (0044-LIME-057) - GRAPHQL (0044-LIME-058) - REST (0044-LIME-059) +- When a LP commits liquidity and places orders on market 1 and on market 2 the LP has no liquidity commitment when I request for all LP orders through `ListLiquidityProvisions` api for this party, then only LP orders for market 1 are returned. (0044-LIME-068) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) @@ -303,6 +306,8 @@ Note: - If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.committmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) and in the case of spot markets into the network treasury for the asset (0044-LIME-048) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.committmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their committment and will not forfeit any of their bond stake. (0044-LIME-069) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.committmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. At the end of the next epoch, the LP will have their bond slashed. (0044-LIME-070) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) and in the case of spot markets into the network treasury for the asset (0044-LIME-046) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) @@ -341,6 +346,23 @@ In the case of spot markets it will be transferred into the network treasury for - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spot (0044-LIME-056) +- For a market that is in continuous trading and LP has committed liquidity + - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-060) + - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) + - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) +- For a market that is in continuous trading if a new LP submits buy and sell orders on the market then makes a liquidity committment to that market the previous orders will count towards the LPs liquidity commitment. (0044-LIME-071) +- For a market that has market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: + - if the LP has a buy order for `4.74` and a sell order for `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-072) + - if the LP has a buy order for `4.75` and a sell order for `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) + - if the LP has a buy order for `4.75` and a sell order for `5.25`, the LP is meeting their committed volume of notional (0044-LIME-074) +- For a market that has market parameter `market.liquidity.priceRange = 0.5` (5%), is in monitoring auction with `last trade price` set to `5` and a new LP has committed liquidity: + - if the `indicative uncrossing price` is set to `4`, the LP has a buy order for `3.79` and a sell order for `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-075) + - if the `indicative uncrossing price` is set to `4`, the LP has a buy order for `3.8` and a sell order for `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) + - if the `indicative uncrossing price` is set to `6`, the LP has a buy order for `4.75` and a sell order for `6.31`, the LP is not meeting their committed volume of notional(0044-LIME-077) + - if the `indicative uncrossing price` is set to `6`, the LP has a buy order for `4.75` and a sell order for `6.3`, the LP is meeting their committed volume of notional(0044-LIME-078) + - if there is no `indicative uncrossing price` and the LP has a buy order for `4.74` and a sell order for `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-079) + - if there is no `indicative uncrossing price` and the LP has a buy order for `4.75` and a sell order for `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-080) + - if there is no `indicative uncrossing price` and the LP has a buy order for `4.75` and a sell order for `5.25`, the LP is meeting their committed volume of notional (0044-LIME-081) ### Qualifying Order Types @@ -372,3 +394,12 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) + +#### Market parameters validation + +- Boundary values are respected for the market parameters + - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` (0044-LIME-063) + - `market.liquidity.committmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-064) + - `market.liquidity.priceRange` valid values: `>=0`, `<=100` (0044-LIME-065) + - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-066) + - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-067) diff --git a/protocol/features.json b/protocol/features.json index 3835e70bb..5b4b29b52 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -307,6 +307,28 @@ "0044-LIME-033", "0044-LIME-034", "0044-LIME-036", + "0044-LIME-060", + "0044-LIME-061", + "0044-LIME-062", + "0044-LIME-063", + "0044-LIME-064", + "0044-LIME-065", + "0044-LIME-066", + "0044-LIME-067", + "0044-LIME-068", + "0044-LIME-069", + "0044-LIME-070", + "0044-LIME-071", + "0044-LIME-072", + "0044-LIME-073", + "0044-LIME-074", + "0044-LIME-075", + "0044-LIME-076", + "0044-LIME-077", + "0044-LIME-078", + "0044-LIME-079", + "0044-LIME-080", + "0044-LIME-081", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From 1c7a38c85bf21eca1bf869c5364ba6868d8d7762 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Sun, 13 Aug 2023 14:24:47 +0100 Subject: [PATCH 436/649] feat: add epoch param change acs --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 3 +++ protocol/features.json | 3 +++ 2 files changed, 6 insertions(+) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 13019d628..c891fc35a 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -380,12 +380,15 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) + - If an LP has an active liquidity provision at the start of an epoch, during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs > 1` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) - When `market.liquidity.performanceHysteresisEpochs > 1`: - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-047) + - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75`, during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 1` is enacted and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate will be applied to liquidity fee payments at the end of the epoch. The next epoch if LP always meet their liquidity provision requirements then they will a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-053) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they never meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 0` for the latest epoch a penalty rate of `1` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-040) + - If an LP has an active liquidity provision at the start of an epoch and no previous performance hysteresis and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-055) ### SLA Performance bonus transfers diff --git a/protocol/features.json b/protocol/features.json index 5b4b29b52..b1a336f35 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -277,6 +277,9 @@ "0042-LIQF-044", "0042-LIQF-045", "0042-LIQF-046", + "0042-LIQF-053", + "0042-LIQF-054", + "0042-LIQF-055", "0044-LIME-057", "0044-LIME-058", "0044-LIME-059", From 7c531f10f055ec5b5b9779c91f9225c36fc70b4d Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Sun, 13 Aug 2023 14:40:15 +0100 Subject: [PATCH 437/649] feat: changed ac wording --- protocol/0044-LIME-lp_mechanics.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 0da816084..a0ac10ea8 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -351,18 +351,18 @@ In the case of spot markets it will be transferred into the network treasury for - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) - For a market that is in continuous trading if a new LP submits buy and sell orders on the market then makes a liquidity committment to that market the previous orders will count towards the LPs liquidity commitment. (0044-LIME-071) -- For a market that has market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: - - if the LP has a buy order for `4.74` and a sell order for `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-072) - - if the LP has a buy order for `4.75` and a sell order for `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) - - if the LP has a buy order for `4.75` and a sell order for `5.25`, the LP is meeting their committed volume of notional (0044-LIME-074) -- For a market that has market parameter `market.liquidity.priceRange = 0.5` (5%), is in monitoring auction with `last trade price` set to `5` and a new LP has committed liquidity: - - if the `indicative uncrossing price` is set to `4`, the LP has a buy order for `3.79` and a sell order for `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-075) - - if the `indicative uncrossing price` is set to `4`, the LP has a buy order for `3.8` and a sell order for `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) - - if the `indicative uncrossing price` is set to `6`, the LP has a buy order for `4.75` and a sell order for `6.31`, the LP is not meeting their committed volume of notional(0044-LIME-077) - - if the `indicative uncrossing price` is set to `6`, the LP has a buy order for `4.75` and a sell order for `6.3`, the LP is meeting their committed volume of notional(0044-LIME-078) - - if there is no `indicative uncrossing price` and the LP has a buy order for `4.74` and a sell order for `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-079) - - if there is no `indicative uncrossing price` and the LP has a buy order for `4.75` and a sell order for `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-080) - - if there is no `indicative uncrossing price` and the LP has a buy order for `4.75` and a sell order for `5.25`, the LP is meeting their committed volume of notional (0044-LIME-081) +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: + - if during the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional and a bond penalty will apply. The next epoch the parameter change takes effect, LP will meet their committed volume of notional and no bond penalty will apply. (0044-LIME-072) + - if the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) + - if during the epoch market parameter change `market.liquidity.priceRange = 0.01` (1%) the LP has a buy order at price `4.75` and a sell order at price `5.25`, the LP is meeting their committed volume of notional and no bond penalty will apply. The next epoch the parameter change takes effect, LP will not meet their volume of notional and bond penalty will apply. (0044-LIME-074) +- For a market with market parameter `market.liquidity.priceRange = 0.5` (5%), is in monitoring auction with `last trade price` set to `5` and a new LP has committed liquidity: + - if the `indicative uncrossing price` is set to `4`, the LP has a buy order at price `3.79` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-075) + - if the `indicative uncrossing price` is set to `4`, the LP has a buy order at price `3.8` and a sell order at price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) + - if the `indicative uncrossing price` is set to `6`, the LP has a buy order at price `4.75` and a sell order at price `6.31`, the LP is not meeting their committed volume of notional (0044-LIME-077) + - if the `indicative uncrossing price` is set to `6`, the LP has a buy order at price `4.75` and a sell order at price `6.3`, the LP is meeting their committed volume of notional (0044-LIME-078) + - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-079) + - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-080) + - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.75` and a sell order at price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-081) ### Qualifying Order Types From 82b953cf898d5c295e5af54987aad6e4bb25dcd0 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Sun, 13 Aug 2023 14:53:20 +0100 Subject: [PATCH 438/649] fix: spelcheck for commitment --- protocol/0044-LIME-lp_mechanics.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index a0ac10ea8..4a9384f10 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -19,7 +19,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.sla.nonPerformanceBondPenaltyMax` - used to calculate how much is the LP bond slashed if they fail to reach the minimum SLA. Valid values: any decimal number `>= 0` and `<=1.0` with a default value of `0.5`. - `market.liquidity.maximumLiquidityFeeFactorLevel` - used in validating fee amounts that are submitted as part of the LP commitment transaction. Note that a value of `0.05 = 5%`. Valid values are: any decimal number `>=0` and `<=1`. Default value `1`. - `market.liquidity.stakeToCcyVolume` - used to translate a commitment to an obligation. Any decimal number `>0` with default value `1.0`. -- `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.committmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liquidity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). +- `validators.epoch.length` - LP rewards from liquidity fees are paid out once per epoch according to whether they met the "SLA" (implied by `market.liquidity.commitmentMinTimeFraction`) and their previous performance (for the last n epochs defined by `market.liquidity.performanceHysteresisEpochs`), see [epoch spec](./0050-EPOC-epochs.md). - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. @@ -30,13 +30,13 @@ All market parameters can be set / modified as part of [market proposal](0028-GO - `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. -- `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. +- `market.liquidity.commitmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. - `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. - `market.liquidity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. -- `market.liquidity.slaCompetitionFactor` - the maximum fraction of their accrued fees an LP that meets the SLA implied by `market.liquidity.committmentMinTimeFraction` will lose to LPs that achieved a higher SLA performance than them. +- `market.liquidity.slaCompetitionFactor` - the maximum fraction of their accrued fees an LP that meets the SLA implied by `market.liquidity.commitmentMinTimeFraction` will lose to LPs that achieved a higher SLA performance than them. For LP reward calculations based on the SLA see the [0042-LIQF spec](./0042-LIQF-setting_fees_and_rewarding_lps.md). @@ -222,12 +222,12 @@ Note: we don't evaluate whether LPs meet the SLA during opening auctions so ther See the [Calculating the SLA performance penalty for a single epoch section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md) for how `fraction_of_time_on_book` is calculated. This is available at the end of each epoch. -If, at the end of the epoch, `fraction_of_time_on_book >= market.liquidity.committmentMinTimeFraction` then let $f=0$. +If, at the end of the epoch, `fraction_of_time_on_book >= market.liquidity.commitmentMinTimeFraction` then let $f=0$. Otherwise we calculate a penalty to be applied to the bond as follows. Let $t$ be `fraction_of_time_on_book` -Let $s$ be `market.liquidity.committmentMinTimeFraction`. +Let $s$ be `market.liquidity.commitmentMinTimeFraction`. Let $p$ be `market.liquidity.sla.nonPerformanceBondPenaltySlope`. @@ -303,14 +303,14 @@ Note: - Change of `market.liquidity.stakeToCcyVolume` will change the liquidity obligation hence change the size of the LP orders on the order book. (0044-LIME-010) - If `market.liquidity.stakeToCcyVolume` is set to `0.0`, there is [target stake](./0041-TSTK-target_stake.md) of `1000` and there are 3 LPs on the market with stake / fee bid submissions of `100, 0.01`, `1000, 0.02` and `200, 0.03` then the liquidity fee is `0.02`. (0044-LIME-012) -- If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.committmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) -- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) +- If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.commitmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) and in the case of spot markets into the network treasury for the asset (0044-LIME-048) -- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.committmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their committment and will not forfeit any of their bond stake. (0044-LIME-069) -- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.committmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.committmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. At the end of the next epoch, the LP will have their bond slashed. (0044-LIME-070) -- If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their commitment and will not forfeit any of their bond stake. (0044-LIME-069) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. At the end of the next epoch, the LP will have their bond slashed. (0044-LIME-070) +- If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) and in the case of spot markets into the network treasury for the asset (0044-LIME-046) -- If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.committmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) +- If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) and in the case of spot markets into the network treasury for the asset (0044-LIME-047) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. (0044-LIME-018) @@ -350,7 +350,7 @@ In the case of spot markets it will be transferred into the network treasury for - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-060) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) -- For a market that is in continuous trading if a new LP submits buy and sell orders on the market then makes a liquidity committment to that market the previous orders will count towards the LPs liquidity commitment. (0044-LIME-071) +- For a market that is in continuous trading if a new LP submits buy and sell orders on the market then makes a liquidity commitment to that market the previous orders will count towards the LPs liquidity commitment. (0044-LIME-071) - For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: - if during the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional and a bond penalty will apply. The next epoch the parameter change takes effect, LP will meet their committed volume of notional and no bond penalty will apply. (0044-LIME-072) - if the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) @@ -399,7 +399,7 @@ In the case of spot markets it will be transferred into the network treasury for - Boundary values are respected for the market parameters - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` (0044-LIME-063) - - `market.liquidity.committmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-064) + - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-064) - `market.liquidity.priceRange` valid values: `>=0`, `<=100` (0044-LIME-065) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-066) - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-067) From 84f46202b9eb6e3e5be2497a9165e885c64882c9 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 14 Aug 2023 09:18:54 +0100 Subject: [PATCH 439/649] feat: update pricerange valid values --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 4a9384f10..9a0f404d6 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -400,6 +400,6 @@ In the case of spot markets it will be transferred into the network treasury for - Boundary values are respected for the market parameters - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` (0044-LIME-063) - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-064) - - `market.liquidity.priceRange` valid values: `>=0`, `<=100` (0044-LIME-065) + - `market.liquidity.priceRange` valid values: `>0`, `<=100` (0044-LIME-065) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-066) - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-067) From a21762aa59a487bcb24dd63363b9b2a5a42b6a61 Mon Sep 17 00:00:00 2001 From: Edd Date: Mon, 14 Aug 2023 11:15:03 +0100 Subject: [PATCH 440/649] Add check-features check (#1899) * Add check-features check * fix: grammar to avoid confusion with spot ACs * chore: update action and make to check ipynb files too --------- Co-authored-by: gordsport --- .github/workflows/quality_check.yml | 8 ++- makefile | 12 ++-- protocol/0004-AMND-amends.md | 50 ++++++------- protocol/0008-TRAD-trading_workflow.md | 2 +- protocol/0013-ACCT-accounts.md | 4 +- protocol/0014-ORDT-order_types.md | 70 +++++++++---------- protocol/0021-MDAT-market_data_spec.md | 16 ++--- protocol/0024-OSTA-order_status.md | 38 +++++----- protocol/0025-OCRE-order_submission.md | 2 +- protocol/0026-AUCT-auctions.md | 4 +- protocol/0029-FEES-fees.md | 22 +++--- protocol/0032-PRIM-price_monitoring.md | 34 ++++----- protocol/0033-OCAN-cancel_orders.md | 14 ++-- ...PROB-prob_weighted_liquidity_measure.ipynb | 6 +- protocol/0037-OPEG-pegged_orders.md | 2 +- .../0039-MKTD-market_depth_calculation.md | 28 ++++---- protocol/0043-MKTL-market_lifecycle.md | 2 +- protocol/0051-PROD-product.md | 6 +- .../0052-FPOS-fractional_orders_positions.md | 4 +- protocol/0054-NETP-network_parameters.md | 10 +-- .../0065-FTCO-floating_point_consensus.md | 8 +-- protocol/0068-MATC-matching_engine.md | 66 ++++++++--------- protocol/0070-MKTD-market-decimal-places.md | 16 ++--- protocol/0073-LIMN-limited_network_life.md | 30 ++++---- .../0074-BTCH-batch-market-instructions.md | 8 +-- 25 files changed, 233 insertions(+), 229 deletions(-) diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 2ac04678c..1fa8103da 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -61,8 +61,12 @@ jobs: - name: "Run Check AC codes" run: | - npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" - name: "Run Check file names" run: | - npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" + + - name: "Run Check Features" + run: | + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" diff --git a/makefile b/makefile index 18bceb853..ae9bcacd0 100644 --- a/makefile +++ b/makefile @@ -1,19 +1,19 @@ # Set default to run all checks if none specified .DEFAULT_GOAL := all -all: spellcheck markdownlint names codes references links featureacs clean +all: spellcheck markdownlint names codes references links check-features clean # Check that all the specifications are named appropriately .PHONY: names names: @$(MAKE) clone-sources - npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" # Count how many Acceptance Criteria each specification has .PHONY: codes codes: @$(MAKE) clone-sources - npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}" + npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" TEMP=./.build .PHONY:clone-sources @@ -62,9 +62,9 @@ spellcheck: @./spellcheck.sh # Checks for duplicated ACs in the features.json file -.PHONY: featureacs -featureacs: - jq -r '.. | .[]? | .acs?' -s < protocol/features.json | sort | uniq -d +.PHONY: check-features +check-features: + npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json" clean: rm -rf $(TEMP) diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index adbf1ce39..73848c678 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -2,27 +2,27 @@ ## Acceptance Criteria -- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001) for product spot: (0004-AMND-030) -- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002) for product spot: (0004-AMND-031) -- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003) for product spot: (0004-AMND-032) -- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004) for product spot: (0004-AMND-055) -- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005) for product spot: (0004-AMND-033) -- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006) for product spot: (0004-AMND-034) -- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007) for product spot: (0004-AMND-035) -- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008) for product spot: (0004-AMND-036) -- The `orderID` remains the same after an amend (0004-AMND-009) for product spot: (0004-AMND-037) -- Amends can occur in continuous trading or in an auction (0004-AMND-010) for product spot: (0004-AMND-038) -- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011) for product spot: (0004-AMND-039) -- All amendable fields can be amended in the same amend message (0004-AMND-012) for product spot: (0004-AMND-040) -- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013) for product spot: (0004-AMND-041) -- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014) for product spot: (0004-AMND-042) -- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015) for product spot: (0004-AMND-043) -- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016) for product spot: (0004-AMND-044) -- A parked pegged order can be amended. (0037-OPEG-014) for product spot: (0037-OPEG-019) -- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017) for product spot: (0004-AMND-045) -- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018) for product spot: (0004-AMND-046) -- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019) for product spot: (0004-AMND-047) -- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029) for product spot: (0004-AMND-048) +- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001). For product spot: (0004-AMND-030) +- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002). For product spot: (0004-AMND-031) +- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003). For product spot: (0004-AMND-032) +- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004). For product spot: (0004-AMND-055) +- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005). For product spot: (0004-AMND-033) +- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006). For product spot: (0004-AMND-034) +- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007). For product spot: (0004-AMND-035) +- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008). For product spot: (0004-AMND-036) +- The `orderID` remains the same after an amend (0004-AMND-009). For product spot: (0004-AMND-037) +- Amends can occur in continuous trading or in an auction (0004-AMND-010). For product spot: (0004-AMND-038) +- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011). For product spot: (0004-AMND-039) +- All amendable fields can be amended in the same amend message (0004-AMND-012). For product spot: (0004-AMND-040) +- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013). For product spot: (0004-AMND-041) +- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014). For product spot: (0004-AMND-042) +- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015). For product spot: (0004-AMND-043) +- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016). For product spot: (0004-AMND-044) +- A parked pegged order can be amended. (0037-OPEG-014). For product spot: (0037-OPEG-019) +- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017). For product spot: (0004-AMND-045) +- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018). For product spot: (0004-AMND-046) +- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019). For product spot: (0004-AMND-047) +- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029). For product spot: (0004-AMND-048) For a party with no position on a given market: @@ -30,10 +30,10 @@ For a party with no position on a given market: - In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-AMND-049) - Amending an order in a way that decreases the volume sufficiently leads to margin account balance decreasing (0004-AMND-022) - In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-AMND-050) -- It is possible to amend a fractional size order (0004-AMND-025) for product spot: (0004-AMND-051) -- It is possible to amend a partially filled limit order (0004-AMND-026) for product spot: (0004-AMND-052) -- It is possible to amend a versioned order (already amended several times) (0004-AMND-027) for product spot: (0004-AMND-053) -- Attempts to amend order fields not in scope are rejected (0004-AMND-028) for product spot: (0004-AMND-054) +- It is possible to amend a fractional size order (0004-AMND-025). For product spot: (0004-AMND-051) +- It is possible to amend a partially filled limit order (0004-AMND-026). For product spot: (0004-AMND-052) +- It is possible to amend a versioned order (already amended several times) (0004-AMND-027). For product spot: (0004-AMND-053) +- Attempts to amend order fields not in scope are rejected (0004-AMND-028). For product spot: (0004-AMND-054) ## Summary diff --git a/protocol/0008-TRAD-trading_workflow.md b/protocol/0008-TRAD-trading_workflow.md index dbab4143a..16c4b2232 100644 --- a/protocol/0008-TRAD-trading_workflow.md +++ b/protocol/0008-TRAD-trading_workflow.md @@ -10,7 +10,7 @@ The order of processing of transactions happens in the order defined in the diag 1. Before a valid order is processed in any other way by Vega, the [party](./0017-PART-party.md)'s [margin levels](./0011-MARA-check_order_allocate_margin.md) are checked as though they had the order in their position, and any transfers that are needed to support that order occur. (0008-TRAD-001) 1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there will be changes in positions for one or more traders. (0008-TRAD-002) -1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003) for product spot: (0008-TRAD-008) +1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003). For product spot: (0008-TRAD-008) 1. Following the above 3 actions, a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is run for all parties against their most recently updated positions and Mark Price. This will result in a set of transfers between the parties' accounts and possibly may result in loss socialisation occurring if a party has insufficient collateral to cover the move. (0008-TRAD-004) 1. Following the mark to market settlement, the margin liabilities for traders are evaluated against their collateral balances. Any traders that do not have sufficient collateral to support their positions (after collateral searches have been done to their main account) will undergo position resolution. (0008-TRAD-005) 1. After position resolution has occurred, margins are recalculated and evaluated against balances for any traders that gained positions as a result of supplying liquidity on the order book to the network during position resolution. (0008-TRAD-006) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 8a127dc6c..9e0f03b63 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -97,8 +97,8 @@ Note that it *is* possible to have markets in the governance asset, in which cas ### All ordinary accounts -- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001) for product spot: (0013-ACCT-024) -- Only transfer requests move money between accounts. (0013-ACCT-002) for product spot: (0013-ACCT-025) +- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001). For product spot: (0013-ACCT-024) +- Only transfer requests move money between accounts. (0013-ACCT-002). For product spot: (0013-ACCT-025) ### Party asset accounts diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index abcc5a364..3b895b718 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -255,47 +255,47 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ## Acceptance Criteria - Immediate orders, continuous trading: - - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001) for product spot: (0014-ORDT-081) - - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002) for product spot: (0014-ORDT-082) - - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003) for product spot: (0014-ORDT-083) - - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004) for product spot: (0014-ORDT-084) - - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005) for product spot: (0014-ORDT-085) -- No party can submit a [network order type](#network-orders) (0014-ORDT-006) for product spot: (0014-ORDT-086) + - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001). For product spot: (0014-ORDT-081) + - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002). For product spot: (0014-ORDT-082) + - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003). For product spot: (0014-ORDT-083) + - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004). For product spot: (0014-ORDT-084) + - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005). For product spot: (0014-ORDT-085) +- No party can submit a [network order type](#network-orders) (0014-ORDT-006). For product spot: (0014-ORDT-086) - A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) ### Iceberg Orders AC's #### Iceberg Order Submission -1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007) for product spot: (0014-ORDT-087) -2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008) for product spot: (0014-ORDT-088) -3. An iceberg post only order can be submitted (0014-ORDT-009) for product spot: (0014-ORDT-089) -4. An iceberg reduce only order is rejected (0014-ORDT-010) for product spot: (0014-ORDT-090) +1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007). For product spot: (0014-ORDT-087) +2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008). For product spot: (0014-ORDT-088) +3. An iceberg post only order can be submitted (0014-ORDT-009). For product spot: (0014-ORDT-089) +4. An iceberg reduce only order is rejected (0014-ORDT-010). For product spot: (0014-ORDT-090) 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) In Spot market, for an iceberg order that is submitted with total size x and display size y the holding asset taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-091) -6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012) for product spot: (0014-ORDT-092) +6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012). For product spot: (0014-ORDT-092) - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue -7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013) for product spot: (0014-ORDT-093) +7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013). For product spot: (0014-ORDT-093) #### Iceberg Order Batch Submission 1. For multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, margin calculations , order status are all correct (0014-ORDT-014) In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all correct. (0014-ORDT-094) -2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015) for product spot: (0014-ORDT-095) +2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015). For product spot: (0014-ORDT-095) #### Iceberg Order Submission - Negative tests -1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016) for product spot: (0014-ORDT-096) -2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017) for product spot: (0014-ORDT-097) -3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018) for product spot: (0014-ORDT-098) -4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020) for product spot: (0014-ORDT-099) -5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021) for product spot: (0014-ORDT-100) -6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022) for product spot: (0014-ORDT-119) +1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016). For product spot: (0014-ORDT-096) +2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017). For product spot: (0014-ORDT-097) +3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018). For product spot: (0014-ORDT-098) +4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020). For product spot: (0014-ORDT-099) +5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021). For product spot: (0014-ORDT-100) +6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022). For product spot: (0014-ORDT-119) #### Iceberg Order Amendment -1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023) for product spot: (0014-ORDT-101) -2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024) for product spot: (0014-ORDT-102) +1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023). For product spot: (0014-ORDT-101) +2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024). For product spot: (0014-ORDT-102) 3. Amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost (0014-ORDT-025) 4. In Spot market, amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost. (0014-ORDT-103) @@ -306,27 +306,27 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with #### Iceberg Order Execution -1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027) for product spot: (0014-ORDT-105) -2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028) for product spot: (0014-ORDT-106) -3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029) for product spot: (0014-ORDT-107) -4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030) for product spot: (0014-ORDT-108) -5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031) for product spot: (0014-ORDT-109) -6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032) for product spot: (0014-ORDT-110) -7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033) for product spot: (0014-ORDT-111) -8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034) for product spot: ( 0014-ORDT-118) +1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027). For product spot: (0014-ORDT-105) +2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028). For product spot: (0014-ORDT-106) +3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029). For product spot: (0014-ORDT-107) +4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030). For product spot: (0014-ORDT-108) +5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031). For product spot: (0014-ORDT-109) +6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032). For product spot: (0014-ORDT-110) +7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033). For product spot: (0014-ORDT-111) +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034). For product spot: ( 0014-ORDT-118) 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037) for product spot: (0014-ORDT-112) - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038) for product spot: (0014-ORDT-113) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037). For product spot: (0014-ORDT-112) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038). For product spot: (0014-ORDT-113) ### Snapshots -1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035) for product spot: (0014-ORDT-114) +1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035). For product spot: (0014-ORDT-114) ### API -1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036) for product spot: (0014-ORDT-115) -2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069) for product spot: (0014-ORDT-116) -3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070) for product spot: (0014-ORDT-117) +1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036). For product spot: (0014-ORDT-115) +2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069). For product spot: (0014-ORDT-116) +3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070). For product spot: (0014-ORDT-117) ### Stop orders diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index ddd2bb326..4938d78df 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -2,18 +2,18 @@ ## Acceptance Criteria -- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001) for product spot: (0021-MDAT-013) -- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002) for product spot: (0021-MDAT-014) -- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003) for product spot: (0021-MDAT-015) -- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004) for product spot: (0021-MDAT-016) -- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005) for product spot: (0021-MDAT-017) -- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006) for product spot: (0021-MDAT-018) -- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007) for product spot: (0021-MDAT-019) +- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001). For product spot: (0021-MDAT-013) +- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002). For product spot: (0021-MDAT-014) +- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003). For product spot: (0021-MDAT-015) +- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004). For product spot: (0021-MDAT-016) +- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005). For product spot: (0021-MDAT-017) +- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006). For product spot: (0021-MDAT-018) +- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007). For product spot: (0021-MDAT-019) - The Open interest returns the sum of the size for all open positions where positions size is greater than 0. (0021-MDAT-008) - The Open interest returns 0 if there are no positions on the market (0021-MDAT-009) - Pegged orders are excluded from the best static price and best static volume calculations. (0021-MDAT-010) - Dynamic orders should be ignored when calculating the static values (0021-MDAT-011) -- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012) for product spot: (0021-MDAT-020) +- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012). For product spot: (0021-MDAT-020) ## Summary diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index b07215002..f2c31d0c4 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -45,7 +45,7 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. ### Fill or Or Kill (0024-OSTA-001) -for product spot: (0024-OSTA-030) +For product spot: (0024-OSTA-030) | Time In Force | Filled | Resulting status | |---------------|--------|------------------| @@ -54,7 +54,7 @@ for product spot: (0024-OSTA-0300024-OSTA-002) -for product spot: (0024-OSTA-031) +For product spot: (0024-OSTA-031) | Time In Force | Filled | Resulting status | |---------------|---------|------------------| @@ -64,7 +64,7 @@ for product spot: (0024-OSTA-0310024-OSTA-003) -for product spot: (0024-OSTA-032) +For product spot: (0024-OSTA-032) | Time In Force | Filled | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|-------------------|-------------------|------------------| @@ -78,7 +78,7 @@ for product spot: (0024-OSTA-0320024-OSTA-004) -for product spot: (0024-OSTA-033) +For product spot: (0024-OSTA-033) | Time In Force | Filled | Expired | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|---------|-------------------|-------------------|------------------| @@ -97,10 +97,10 @@ Note: The last row in the table above is added for clarity. If the order was fil ### Wash trading Acceptance Criteria -- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-OSTA-005) for product spot: (0024-OSTA-034) -- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006) for product spot: (0024-OSTA-035) -- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007) for product spot: (0024-OSTA-036) -- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008) for product spot: (0024-OSTA-037) +- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-OSTA-005). For product spot: (0024-OSTA-034) +- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006). For product spot: (0024-OSTA-035) +- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007). For product spot: (0024-OSTA-036) +- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008). For product spot: (0024-OSTA-037) ### Impact of order types on settlement @@ -110,20 +110,20 @@ Note: The last row in the table above is added for clarity. If the order was fil - Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` is given if a position is closed out because they do now have enough margin to cover the position (0024-OSTA-010) - Order reason of `ORDER_ERROR_MARGIN_CHECK_FAILED` is given if a new order is placed and the user does not have enough collateral to cover the initial margin requirements (0024-OSTA-011) -- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012) for product spot: (0024-OSTA-038) -- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013) for product spot: (0024-OSTA-039) -- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014) for product spot: (0024-OSTA-040) -- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015) for product spot: (0024-OSTA-041) -- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016) for product spot: (0024-OSTA-042) -- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017)for product spot: (0024-OSTA-043) -- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018) for product spot: (0024-OSTA-044) -- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019) for product spot: (0024-OSTA-045) -- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020) for product spot: (0024-OSTA-046) +- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012). For product spot: (0024-OSTA-038) +- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013). For product spot: (0024-OSTA-039) +- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014).. For product spot: (0024-OSTA-040) +- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015). For product spot: (0024-OSTA-041) +- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016). For product spot: (0024-OSTA-042) +- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017). For product spot: (0024-OSTA-043) +- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018). For product spot: (0024-OSTA-044) +- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019). For product spot: (0024-OSTA-045) +- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020). For product spot: (0024-OSTA-046) - Order reason of `ORDER_ERROR_MUST_BE_LIMIT_ORDER` when sending a pegged order that is not a LIMIT order (0024-OSTA-021) - Order reason of `ORDER_ERROR_MUST_BE_GTT_OR_GTC` pegged order must be either GTC or GTT (0024-OSTA-022) - Order reason of `ORDER_ERROR_WITHOUT_REFERENCE_PRICE` pegged order must have a reference field (0024-OSTA-023) - Order reason of `ORDER_ERROR_BUY_CANNOT_REFERENCE_BEST_ASK_PRICE` buy pegged order cannot reference the ask price (0024-OSTA-024) - Order reason of `ORDER_ERROR_OFFSET_MUST_BE_GREATER_THAN_ZERO` pegged order offset must be > 0 when referencing `MID` price (0024-OSTA-025) - Order reason of `ORDER_ERROR_SELL_CANNOT_REFERENCE_BEST_BID_PRICE` sell pegged order cannot reference the bid price (0024-OSTA-026) -- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027) for product spot: (0024-OSTA-047) -- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029) for product spot: (0024-OSTA-048) +- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027). For product spot: (0024-OSTA-047) +- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029). For product spot: (0024-OSTA-048) diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index 9f8ed801f..f163e500f 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -37,7 +37,7 @@ Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an ## Acceptance Criteria -- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001) for product spot: (0025-OCRE-004) +- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001). For product spot: (0025-OCRE-004) - Margin will taken before the order is entered into the book (0025-OCRE-002) - If sufficient margin cannot be reserved, the order will have a status of `REJECTED` (0025-OCRE-003) - Fees are charged as per [0029-FEES](./0029-FEES-fees.md). diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 083958f1d..8192c78b1 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -159,7 +159,7 @@ message Market { - The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). For product spot: (0026-AUCT-023) - As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) for product spot: (0068-MATC-060) +- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) - As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) - As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006).For product spot: (0026-AUCT-026) - As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) @@ -168,7 +168,7 @@ message Market { - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017) for product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017). For product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) 2. past the enactment time if there is no [liquidity supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) 3. past the enactment time if [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index fe51122b0..9f97c5d1c 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -54,9 +54,9 @@ Note, it is important discounts are calculated and applied **before** rewards ar 1. Calculate any referral rewards due to the parties referrer (Note we are using the updated fee components from step 3) ```pseudo - infrastructure_fee_referral_reward = floor(infrastructure_fee * referral_reward_factor) - liquidity_fee_referral_reward = floor(liquidity_fee * referral_reward_factor) - maker_fee_referral_reward = floor(maker_fee * referral_reward_factor) + infrastructure_fee_referral_reward = floor(infrastructure_fee * referral_reward_factor) + liquidity_fee_referral_reward = floor(liquidity_fee * referral_reward_factor) + maker_fee_referral_reward = floor(maker_fee * referral_reward_factor) ``` 1. Finally, update the fee components by applying the rewards. @@ -142,20 +142,20 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria -- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001) for product spot: (0029-FEES-015) +- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001). For product spot: (0029-FEES-015) - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) -- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005) for product spot: (0029-FEES-016) +- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005). For product spot: (0029-FEES-016) - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) - During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) -- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009) for product spot: (0029-FEES-017) -- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010) for product spot: (0029-FEES-018) -- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011) for product spot: (0029-FEES-019) -- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012) for product spot: (0029-FEES-020) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013) for product spot: (0029-FEES-021) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014) for product spot: (0029-FEES-022) +- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009). For product spot: (0029-FEES-017) +- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010). For product spot: (0029-FEES-018) +- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011). For product spot: (0029-FEES-019) +- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012). For product spot: (0029-FEES-020) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013). For product spot: (0029-FEES-021) +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014). For product spot: (0029-FEES-022) ### Applying benefit factors diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index e74b9ed4a..3de366ae7 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -109,23 +109,23 @@ to the risk model and obtains the range of valid up/down price moves per each of ## Acceptance Criteria -- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001) for product spot: (0032-PRIM-022) +- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001). For product spot: (0032-PRIM-022) - Non-persistent order does not result in an auction (1 out of 2 triggers breached), order gets cancelled (never makes it to the order book) -(0032-PRIM-003) for product spot: (0032-PRIM-023) -- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005) for product spot: (0032-PRIM-024) -- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006) for product spot: (0032-PRIM-025) -- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007) for product spot: (0032-PRIM-026) -- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008) for product spot: (0032-PRIM-027) -- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009) for product spot: (0032-PRIM-028) -- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010) for product spot: (0032-PRIM-029) -- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011) for product spot: (0032-PRIM-030) -- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012) for product spot: (0032-PRIM-031) -- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013) for product spot: (0032-PRIM-032) -- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014) for product spot: (0032-PRIM-033) -- Specifying a non-positive horizon results in an error. (0032-PRIM-015) for product spot: (0032-PRIM-034) -- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016) for product spot: (0032-PRIM-035) -- Specifying a non-positive auction extension results in an error. (0032-PRIM-017) for product spot: (0032-PRIM-036) +(0032-PRIM-003). For product spot: (0032-PRIM-023) +- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005). For product spot: (0032-PRIM-024) +- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006). For product spot: (0032-PRIM-025) +- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007). For product spot: (0032-PRIM-026) +- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008). For product spot: (0032-PRIM-027) +- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009). For product spot: (0032-PRIM-028) +- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010). For product spot: (0032-PRIM-029) +- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011). For product spot: (0032-PRIM-030) +- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012). For product spot: (0032-PRIM-031) +- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013). For product spot: (0032-PRIM-032) +- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014). For product spot: (0032-PRIM-033) +- Specifying a non-positive horizon results in an error. (0032-PRIM-015). For product spot: (0032-PRIM-034) +- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016). For product spot: (0032-PRIM-035) +- Specifying a non-positive auction extension results in an error. (0032-PRIM-017). For product spot: (0032-PRIM-036) - Settlement price outside the current price monitoring bounds does not trigger an auction (0032-PRIM-018) - A network trade (during closeout) with a price outside price monitoring bounds does not trigger an auction. (0032-PRIM-019) -- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020) for product spot: (0032-PRIM-037) -- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021) for product spot: (0032-PRIM-038) +- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020). For product spot: (0032-PRIM-037) +- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021). For product spot: (0032-PRIM-038) diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index 0dddb6ce9..228d66663 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -2,15 +2,15 @@ ## Acceptance Criteria -- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001) for product spot: (0033-OCAN-011) -- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002) for product spot: (0033-OCAN-012) -- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003) for product spot: (0033-OCAN-013) -- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004) for product spot: (0033-OCAN-014) -- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005) for product spot: (0033-OCAN-015) +- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001). For product spot: (0033-OCAN-011) +- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002). For product spot: (0033-OCAN-012) +- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003). For product spot: (0033-OCAN-013) +- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004). For product spot: (0033-OCAN-014) +- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005). For product spot: (0033-OCAN-015) - Margins must be recalculated after a cancel event (0033-OCAN-007) - An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008) -- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009) for product spot: (0033-OCAN-016) -- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010) for product spot: (0033-OCAN-017) +- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009). For product spot: (0033-OCAN-016) +- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010). For product spot: (0033-OCAN-017) ## Summary diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index d429e034a..890a8ef38 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -88,11 +88,11 @@ "\n", "Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) The feature test has covered following scenarios:\n", "\n", - "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001) for product spot: (0034-PROB-007);\n", + "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001). For product spot: (0034-PROB-007);\n", "\n", - "2. Probability of trading decreases away from the mid-price (0034-PROB-005) for product spot: (0034-PROB-008).\n", + "2. Probability of trading decreases away from the mid-price (0034-PROB-005). For product spot: (0034-PROB-008).\n", "\n", - "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006) for product spot: (0034-PROB-009).\n", + "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006). For product spot: (0034-PROB-009).\n", "\n", "\n", "\n" diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index cf9c050fd..c3edc288f 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -15,7 +15,7 @@ - If the midprice is calculated to be a fraction (e.g. 102.5), it should be rounded up for a buy and rounded down for a sell. (0037-OPEG-011) - The order version is not updated during a repricing (0037-OPEG-012) - Pegged orders are included in the calculation of the BEST_BID, BEST_ASK and MID prices but excluded from BEST_STATIC_BID, BEST_STATIC_ASK and STATIC_MID (0037-OPEG-013) -- A parked pegged order can be amended. (0037-OPEG-014) for product spot: (0037-OPEG-019) +- A parked pegged order can be amended. (0037-OPEG-014). For product spot: (0037-OPEG-019) - A pegged order with an offset which would cause it to be priced <= 0 is parked. (0037-OPEG-017) - An active pegged order can be amended. (0037-OPEG-016) - A transaction submitting a pegged order with negative offset fails with an error explaining the cause was negative offset. (0037-OPEG-018) diff --git a/protocol/0039-MKTD-market_depth_calculation.md b/protocol/0039-MKTD-market_depth_calculation.md index bfe30113f..0a9203919 100644 --- a/protocol/0039-MKTD-market_depth_calculation.md +++ b/protocol/0039-MKTD-market_depth_calculation.md @@ -2,21 +2,21 @@ ## Acceptance Criteria -- The market depth builder must be able to handle all available order types (0039-MKTD-001) for product spot: (0039-MKTD-020) -- Entering and leaving auctions must be handled correctly (0039-MKTD-003) for product spot: (0039-MKTD-021) -- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004) for product spot: (0039-MKTD-022) -- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005) for product spot: (0039-MKTD-023) -- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006) for product spot: (0039-MKTD-024) -- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007) for product spot: (0039-MKTD-025) -- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008) for product spot: (0039-MKTD-026) -- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009) for product spot: (0039-MKTD-027) -- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010) for product spot: (0039-MKTD-028) -- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012) for product spot: (0039-MKTD-029) -- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013) for product spot: (0039-MKTD-030) -- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014) for product spot: (0039-MKTD-033) +- The market depth builder must be able to handle all available order types (0039-MKTD-001). For product spot: (0039-MKTD-020) +- Entering and leaving auctions must be handled correctly (0039-MKTD-003). For product spot: (0039-MKTD-021) +- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004). For product spot: (0039-MKTD-022) +- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005) . For product spot: (0039-MKTD-023) +- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006). For product spot: (0039-MKTD-024) +- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007). For product spot: (0039-MKTD-025) +- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008). For product spot: (0039-MKTD-026) +- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009). For product spot: (0039-MKTD-027) +- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010). For product spot: (0039-MKTD-028) +- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012). For product spot: (0039-MKTD-029) +- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013). For product spot: (0039-MKTD-030) +- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014). For product spot: (0039-MKTD-033) - Pegged orders are part of the market depth view and should update the view when their orders are repriced (0039-MKTD-015) -- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018) for product spot: (0039-MKTD-031) -- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019) for product spot: (0039-MKTD-032) +- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018). For product spot: (0039-MKTD-031) +- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019). For product spot: (0039-MKTD-032) ## Summary diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index a824991c7..a1b16959d 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -244,7 +244,7 @@ After `market.liquidity.successorLaunchWindowLength` has elapsed since the settl ### Market is proposed but rejected (0043-MKTL-001) -also for for product spot: (0043-MKTL-005) +For product spot: (0043-MKTL-005) 1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index 0acdbcd24..ce2142f19 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -119,12 +119,12 @@ APIS should be available to: Settlement assets: -- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001) for product spot: (0051-PROD-004) for product perpetual: (0051-PROD-007) -- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002) for product spot: (0051-PROD-005) for product perpetual: (0051-PROD-008) +- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001). For product spot: (0051-PROD-004). For product perpetual: (0051-PROD-007) +- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002). For product spot: (0051-PROD-005). For product perpetual: (0051-PROD-008) Product updates via governance: -- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003) for product spot: (0051-PROD-006) for product perpetual: (0051-PROD-009) +- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003). For product spot: (0051-PROD-006). F for product perpetual: (0051-PROD-009) ## See also diff --git a/protocol/0052-FPOS-fractional_orders_positions.md b/protocol/0052-FPOS-fractional_orders_positions.md index 057b7bc82..202c3726b 100644 --- a/protocol/0052-FPOS-fractional_orders_positions.md +++ b/protocol/0052-FPOS-fractional_orders_positions.md @@ -19,8 +19,8 @@ Specs affected by this change (Note: in many cases the implementation may not ch ## Acceptance Criteria -- All proposed markets will have a decimal places property available via the API (0052-FPOS-001) for product spot: (0052-FPOS-003) -- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002) for product spot: (0052-FPOS-004) +- All proposed markets will have a decimal places property available via the API (0052-FPOS-001). For product spot: (0052-FPOS-003) +- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002). For product spot: (0052-FPOS-004) - Fees are calculated as per ([0029-FEES-013](./0029-FEES-fees.md#0029-FEES-013)) - Mark-to-market settlement happens correctly with PDP > 0 ([0003-MTMK-0015](./0003-MTMK-mark_to_market_settlement.md#0003-MTMK-015)) - Margins are correctly calculated for markets with PDP > 0 ([0019-MCAL-008](./0019-MCAL-margin_calculator.md#0019-MCAL-008)). diff --git a/protocol/0054-NETP-network_parameters.md b/protocol/0054-NETP-network_parameters.md index 742cebfe5..baecaf000 100644 --- a/protocol/0054-NETP-network_parameters.md +++ b/protocol/0054-NETP-network_parameters.md @@ -91,9 +91,9 @@ The current network parameters are specified in the code specifiying the min and ## Acceptance criteria -- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001) for product spot: (0054-NETP-007) -- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002) for product spot: (0054-NETP-008) +- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001). For product spot: (0054-NETP-007) +- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002). For product spot: (0054-NETP-008) - For `market.margin.scalingFactors` set in `genesis.json` or in a governance proposal we validate the format and the fact that "1.0 <= search <= initial <= release"; if these are invalid a useful error is returned. (0054-NETP-003) -- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004) for product spot: (0054-NETP-009) -- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005) for product spot: (0054-NETP-010) -- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006)for product spot: (0054-NETP-011) +- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004). For product spot: (0054-NETP-009) +- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005). For product spot: (0054-NETP-010) +- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006). For product spot: (0054-NETP-011) diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index 83c443371..f6309d68c 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -84,7 +84,7 @@ This section outlines floating-point quantities `vega` currently relies on: ## Acceptance criteria -1. Floating-point values get initialised and updated correctly (0065-FTCO-001) for product spot: (0065-FTCO-005) +1. Floating-point values get initialised and updated correctly (0065-FTCO-001). For product spot: (0065-FTCO-005) - A market is proposed and initially it has the following default values: - Risk factors: - Short: 1.0 @@ -100,12 +100,12 @@ This section outlines floating-point quantities `vega` currently relies on: - When the time-based trigger elapses price monitoring bounds and probability of trading get recalculated. - When the market goes into liquidity monitoring auction the state variables stay the same as prior to its' start, when that auction concludes (choose a price that's not been traded at before) price monitoring bounds and probability of trading get recalculated again and the time-based trigger countdown gets reset. -1. Event announcing diverging values gets emitted (0065-FTCO-004) for product spot: (0065-FTCO-006) +1. Event announcing diverging values gets emitted (0065-FTCO-004). For product spot: (0065-FTCO-006) - For all the state variables nodes submit candidate values that differ by up to half the tolerance. - The event announcing the fact that at least one of the values differed gets emitted. - Since differences are within tolerance the consensus successfully chooses a consensus value and systems keeps running as expected (market goes into continuous trading mode accepts orders and generates trades). -1. Consensus failure event gets emitted (0065-FTCO-002) for product spot: (0065-FTCO-007) +1. Consensus failure event gets emitted (0065-FTCO-002). For product spot: (0065-FTCO-007) - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get submitted by nodes, one of the nodes submits a value that is higher than tolerance. - An appropriate event is sent to signal that at least one of the values differed. @@ -115,7 +115,7 @@ This section outlines floating-point quantities `vega` currently relies on: - Situation continues for 2 more risk factor update attempts (can be time-based or auction). - Market still runs with previously calculated risk factors, but an event informing that the market is using stale values gets emitted. -1. Market cannot leave opening auction with default values (0065-FTCO-003) for product spot: (0065-FTCO-008) +1. Market cannot leave opening auction with default values (0065-FTCO-003). For product spot: (0065-FTCO-008) - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get calculated (their values change from defaults). - When the opening auction sees uncrossing price for the first time (there are two overlapping orders from buy and sell side on the order book) price monitoring bounds get calculated, but probability of trading get doesn't pass consensus (all nodes submit conflicting values) diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index 9ac4d32e7..a1b61a174 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -8,13 +8,13 @@ The matching engine co-ordinates the trading of incoming orders with existing or An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001) for product spot: (0068-MATC-061) - - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002) for product spot: (0068-MATC-062) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003) for product spot: (0068-MATC-063) - - If there is no match the order will be cancelled. (0068-MATC-004) for product spot: (0068-MATC-064) - - If there is a partial match then the remaining will be cancelled. (0068-MATC-005) for product spot: (0068-MATC-065) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001). For product spot: (0068-MATC-061) + - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002). For product spot: (0068-MATC-062) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003). For product spot: (0068-MATC-063) + - If there is no match the order will be cancelled. (0068-MATC-004). For product spot: (0068-MATC-064) + - If there is a partial match then the remaining will be cancelled. (0068-MATC-005). For product spot: (0068-MATC-065) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057) for product spot: (0068-MATC-066) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057). For product spot: (0068-MATC-066) - For Reduce-Only = True orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-056) @@ -27,12 +27,12 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008) for product spot: (0068-MATC-067) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008). For product spot: (0068-MATC-067) - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will either be: - - Fully matched if possible to the other side of the book (0068-MATC-009) for product spot: (0068-MATC-068) - - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010) for product spot: (0068-MATC-069) + - Fully matched if possible to the other side of the book (0068-MATC-009). For product spot: (0068-MATC-068) + - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010). For product spot: (0068-MATC-069) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039) for product spot: (0068-MATC-070) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039). For product spot: (0068-MATC-070) - For Reduce-Only = TRUE orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) @@ -45,48 +45,48 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013) for product spot: (0068-MATC-071) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014) for product spot: (0068-MATC-072) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013). For product spot: (0068-MATC-071) +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014). For product spot: (0068-MATC-072) - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced and placed on the book if the price is valid, except GFN which are rejected by the wallet validation layer. (0068-MATC-015) - otherwise they are parked. (0068-MATC-016) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040) for product spot: (0068-MATC-073) - - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041) for product spot: (0068-MATC-074) - - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042) for product spot: (0068-MATC-075) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040). For product spot: (0068-MATC-073) + - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041). For product spot: (0068-MATC-074) + - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042). For product spot: (0068-MATC-075) - A market will enter auction if the volume on either side of the book is empty. (0068-MATC-017) -- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018) for product spot: (0068-MATC-076) -- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019) for product spot: (0068-MATC-077) +- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018). For product spot: (0068-MATC-076) +- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019). For product spot: (0068-MATC-077) - All orders with Reduce-Only set to TRUE are rejected as invalid. (0068-MATC-054) In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): - [IOC/FOK/GFN](./0014-ORDT-order_types.md#time-in-force--validity) - - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021) for product spot: (0068-MATC-078) + - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021). For product spot: (0068-MATC-078) - [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022) for product spot: (0068-MATC-079) - - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023) for product spot: (0068-MATC-080) - - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055) for product spot: (0068-MATC-081) - - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024) for product spot: (0068-MATC-082) + - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022). For product spot: (0068-MATC-079) + - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023). For product spot: (0068-MATC-080) + - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055). For product spot: (0068-MATC-081) + - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024). For product spot: (0068-MATC-082) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are parked (and have their status set to PARKED). (0068-MATC-025) - - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038) for product spot: (0068-MATC-083) + - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038). For product spot: (0068-MATC-083) When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): - All [PEGGED](./0014-ORDT-order_types.md#auction) orders are parked (and have their status set to PARKED). (0068-MATC-026) -- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027) for product spot: (0068-MATC-084) -- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028) for product spot: (0068-MATC-085) +- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027). For product spot: (0068-MATC-084) +- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028). For product spot: (0068-MATC-085) When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auction-mode): -- The book is uncrossed. (0068-MATC-029) for product spot: (0068-MATC-086) - - Self trading is allowed during uncrossing. (0068-MATC-030) for product spot: (0068-MATC-087) -- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031) for product spot: (0068-MATC-088) +- The book is uncrossed. (0068-MATC-029). For product spot: (0068-MATC-086) + - Self trading is allowed during uncrossing. (0068-MATC-030). For product spot: (0068-MATC-087) +- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031). For product spot: (0068-MATC-088) - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced where possible. (0068-MATC-032) -- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033) for product spot: (0068-MATC-060) -- The price of any persistent order can be updated (0068-MATC-034) for product spot: (0068-MATC-089) -- The size of any persistent order can be updated (0068-MATC-035) for product spot: (0068-MATC-090) -- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036) for product spot: (0068-MATC-092) -- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037) for product spot: (0068-MATC-091) +- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033). For product spot: (0068-MATC-060) +- The price of any persistent order can be updated (0068-MATC-034). For product spot: (0068-MATC-089) +- The size of any persistent order can be updated (0068-MATC-035). For product spot: (0068-MATC-090) +- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036). For product spot: (0068-MATC-092) +- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037). For product spot: (0068-MATC-091) ## Summary diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 1a093b928..8171cde75 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,15 +70,15 @@ Trades of course result in transfers. The amounts transferred (for the trade as ## Acceptance criteria - As a user, I can propose a market with a different precision than its settlement asset - - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001) for product spot: (0070-MKTD-016) - - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002) for product spot: (0070-MKTD-009) + - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001). For product spot: (0070-MKTD-016) + - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002). For product spot: (0070-MKTD-009) - As a user, I can propose a perpetual market with a different periodic settlement precision than its settlement asset - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-018) - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-019) -- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003) for product spot: (0070-MKTD-010) -- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004) for product spot: (0070-MKTD-011) -- As a user I should see the market data prices using market precision. (0070-MKTD-005) for product spot: (0070-MKTD-012) -- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006) for product spot: (0070-MKTD-013) -- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007) for product spot: (0070-MKTD-014) -- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008) for product spot: ( 0070-MKTD-015) +- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003). For product spot: (0070-MKTD-010) +- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). For product spot: (0070-MKTD-011) +- As a user I should see the market data prices using market precision. (0070-MKTD-005). For product spot: (0070-MKTD-012) +- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006). For product spot: (0070-MKTD-013) +- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) +- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008). For product spot: ( 0070-MKTD-015) - Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 02f7346f7..1b7a6c8ca 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -345,7 +345,7 @@ for product perpetuals:(0073-LIMN- 1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023) 1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024) 1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025) -1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026) for product spot: (0073-LIMN-081) +1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026). For product spot: (0073-LIMN-081) 1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027) 1. Propose a valid ERC-20 asset. @@ -385,25 +385,25 @@ for product spot: (0073-LIMN-082 0, submit trading terminated. 1. System saves LNL checkpoint at a time when undistributed LP fees for the market are > 0. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029) for product spot: (0073-LIMN-083) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029). For product spot: (0073-LIMN-083) 1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031) 1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-LIMN-084) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032) for product spot: (0073-LIMN-085) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032). For product spot: (0073-LIMN-085) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034) for product spot: (0073-LIMN-086) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034). For product spot: (0073-LIMN-086) ### Test case 15: Market with trading terminated that settled is not restored, collateral moved correctly 1. Propose, enact, trade in the market, submit trading terminated and settlement data, observe final settlement cashflows for at least 2 parties. 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040) for product spot: (0073-LIMN-087) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040). For product spot: (0073-LIMN-087) 1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-088) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044) for product spot: (0073-LIMN-089) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044). For product spot: (0073-LIMN-089) ### Test case 16: Markets can be settled and terminated after restore as proposed @@ -413,20 +413,20 @@ for product spot: (0073-LIMN-0820073-LIMN-050) 1. In Spot market, market can be closed after a restore. (0073-LIMN-090) -1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051) for product spot: (0073-LIMN-091) +1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051). For product spot: (0073-LIMN-091) ### Test case 17: Markets with internal time trigger for trading terminated that fires between shutdown and restore 1. Propose, enact a market with some trading terminated given by internal time trigger. Trade in the market creating positions for at least 2 parties. 1. System saves LNL checkpoint before the trading terminated trigger is set off. 1. Restart Vega, load LNL checkpoint at a time which is after trading terminated trigger should have rung. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060) for product spot: (0073-LIMN-092); if it exists it in `cancelled` state. -1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061) for product spot: (0073-LIMN-093) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060). For product spot: (0073-LIMN-092); if it exists it in `cancelled` state. +1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061). For product spot: (0073-LIMN-093) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-094) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063) for product spot: (0073-LIMN-095) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063). For product spot: (0073-LIMN-095) 1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065) for product spot: (0073-LIMN-096) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065). For product spot: (0073-LIMN-096) ### Test case 18: market definition is the same pre and post LNL restore @@ -434,9 +434,9 @@ for product spot: (0073-LIMN-0820073-LIMN-070) for product spot: (0073-LIMN-097) - - price monitoring bounds (0073-LIMN-071) for product spot: (0073-LIMN-098) - - oracle settings (0073-LIMN-072) for product spot: (0073-LIMN-099) + - risk model and parameters (0073-LIMN-070). For product spot: (0073-LIMN-097) + - price monitoring bounds (0073-LIMN-071). For product spot: (0073-LIMN-098) + - oracle settings (0073-LIMN-072). For product spot: (0073-LIMN-099) - margin scaling factors (0073-LIMN-073) ### Test case 19: Deposit tokens during checkpoint restore @@ -446,7 +446,7 @@ for product spot: (0073-LIMN-0820073-LIMN-074) for product spot: (0073-LIMN-100) +1. There party's newly deposited assets are available. (0073-LIMN-074). For product spot: (0073-LIMN-100) ### Test case 20: Multisig updates during checkpoint restart diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index ea74ace4b..3bc322faf 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -48,15 +48,15 @@ After entering or exiting an auction mid-batch, the full batch must be processed ## Acceptance criteria -- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001) for product spot: (0074-BTCH-012) +- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001). For product spot: (0074-BTCH-012) - Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002) - An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003) -- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005) for product spot: (0074-BTCH-015) -- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006) for product spot: (0074-BTCH-016) In particular: +- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005). For product spot: (0074-BTCH-015) +- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006). For product spot: (0074-BTCH-016) In particular: - A batch consisting of two limit order placements C1 and C2 where the party has enough balance to place either of them individually but not both should place C1 but reject C2. - A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction and a C2 which is marked `GFN` (good for normal) should execute C1 but reject C2. - A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007) - Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008) -- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009) for product spot: (0074-BTCH-019) +- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009). For product spot: (0074-BTCH-019) - If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010) - Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011) From 5747905002408a61344a68158dec0a9bd4d93dcb Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 14 Aug 2023 11:38:14 +0100 Subject: [PATCH 441/649] fix: for spot wording --- protocol/0044-LIME-lp_mechanics.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9a0f404d6..c48fbbfca 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -341,11 +341,11 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - - LP can increase their commitment and it will take affect immediately (0044-LIME-050) for spot (0044-LIME-054) - - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) + - LP can increase their commitment and it will take affect immediately (0044-LIME-050). For spot (0044-LIME-054) + - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spot (0044-LIME-056) + - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052). For spot (0044-LIME-056) - For a market that is in continuous trading and LP has committed liquidity - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-060) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) From a21254bd73a41f66856ea4ee232e8a7e39b8863a Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 14 Aug 2023 12:18:22 +0100 Subject: [PATCH 442/649] Update protocol/0026-AUCT-auctions.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0026-AUCT-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 04e59c934..8ffdb9351 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -159,7 +159,7 @@ message Market { - The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). For product spot: (0026-AUCT-023) - As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033) For product spot: (0068-MATC-060) +- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) - As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) - As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) - As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) From 0e769442c125704435f8f6828f9cc63a2c84fad2 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 14 Aug 2023 13:49:01 +0100 Subject: [PATCH 443/649] chore: update the features.json file for governace ACs (#1900) --- protocol/features.json | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 446430b1a..31fe3935f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -393,8 +393,13 @@ "0028-GOVE-069", "0028-GOVE-070", "0028-GOVE-072", + "0028-GOVE-108", "0028-GOVE-110", "0028-GOVE-113", + "0028-GOVE-114", + "0028-GOVE-115", + "0028-GOVE-116", + "0028-GOVE-117", "0028-GOVE-118", "0028-GOVE-135", "0028-GOVE-136", @@ -403,7 +408,8 @@ "0028-GOVE-139", "0028-GOVE-111", "0028-GOVE-150", - "0028-GOVE-151" + "0028-GOVE-151", + "0028-GOVE-152" ] }, "Spot": { From 8d16087f4695bc89ac81728a709b6deb7f866848 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 14 Aug 2023 23:13:13 +0200 Subject: [PATCH 444/649] refactor: remove LIME-052 + clafify new behaviour --- protocol/0044-LIME-lp_mechanics.md | 2 +- protocol/features.json | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 4f8ccf2a7..14ac504fb 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -340,7 +340,7 @@ In the case of spot markets it will be transferred into the network treasury for - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052) for spot (0044-LIME-056) + - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) ### Qualifying Order Types diff --git a/protocol/features.json b/protocol/features.json index 31fe3935f..0f635aa7d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -300,7 +300,7 @@ "0044-LIME-050", "0044-LIME-051", "0044-LIME-053", - "0044-LIME-052", + "0044-LIME-060", "0044-LIME-028", "0044-LIME-029", "0044-LIME-032", From cdc79791fed4b6e2fa82f96e7621db6a89a1b0a8 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 08:44:59 +0100 Subject: [PATCH 445/649] Update protocol/0026-AUCT-auctions.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0026-AUCT-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 8ffdb9351..e06ea6453 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -159,7 +159,7 @@ message Market { - The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). For product spot: (0026-AUCT-023) - As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) +- As a user, I can cancel an order that is either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) - As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) - As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) - As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) From d0ee1fae2b09f24c4037cb801c8a191afc0b06c9 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 08:58:15 +0100 Subject: [PATCH 446/649] Update protocol/0044-LIME-lp_mechanics.md --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index c48fbbfca..768b97f86 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -295,7 +295,7 @@ Note: - GRPC (0044-LIME-057) - GRAPHQL (0044-LIME-058) - REST (0044-LIME-059) -- When a LP commits liquidity and places orders on market 1 and on market 2 the LP has no liquidity commitment when I request for all LP orders through `ListLiquidityProvisions` api for this party, then only LP orders for market 1 are returned. (0044-LIME-068) +- When a LP commits liquidity on market 1 and on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-068) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) From 5969dc46a89b62dccce40169eb0397626366b5c5 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 09:20:51 +0100 Subject: [PATCH 447/649] fix: merge error --- protocol/0044-LIME-lp_mechanics.md | 12 ++++++------ protocol/features.json | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index a3933b1ab..bd3775621 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -345,11 +345,11 @@ In the case of spot markets it will be transferred into the network treasury for - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - - The LP cannot cancel their commitment but instead submit governance vote to cancel the market (0044-LIME-052). For spot (0044-LIME-056) + - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - For a market that is in continuous trading and LP has committed liquidity - - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-060) - - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) - - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch market parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) + - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-082) + - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) + - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) - For a market that is in continuous trading if a new LP submits buy and sell orders on the market then makes a liquidity commitment to that market the previous orders will count towards the LPs liquidity commitment. (0044-LIME-071) - For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: - if during the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional and a bond penalty will apply. The next epoch the parameter change takes effect, LP will meet their committed volume of notional and no bond penalty will apply. (0044-LIME-072) @@ -363,7 +363,7 @@ In the case of spot markets it will be transferred into the network treasury for - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-079) - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-080) - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.75` and a sell order at price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-081) - - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) + ### Qualifying Order Types @@ -395,11 +395,11 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) + - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` (0044-LIME-063) #### Market parameters validation - Boundary values are respected for the market parameters - - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` (0044-LIME-063) - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-064) - `market.liquidity.priceRange` valid values: `>0`, `<=100` (0044-LIME-065) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-066) diff --git a/protocol/features.json b/protocol/features.json index 79da63505..c46b6a424 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -310,7 +310,6 @@ "0044-LIME-033", "0044-LIME-034", "0044-LIME-036", - "0044-LIME-060", "0044-LIME-061", "0044-LIME-062", "0044-LIME-063", @@ -332,6 +331,7 @@ "0044-LIME-079", "0044-LIME-080", "0044-LIME-081", + "0044-LIME-082", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From 7b16a2a271f8f4630135248780d850b5ea5e22d2 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 11:39:44 +0100 Subject: [PATCH 448/649] feat: added one more ac --- protocol/0044-LIME-lp_mechanics.md | 3 ++- protocol/features.json | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index bd3775621..bf89735d8 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -350,7 +350,8 @@ In the case of spot markets it will be transferred into the network treasury for - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-082) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) -- For a market that is in continuous trading if a new LP submits buy and sell orders on the market then makes a liquidity commitment to that market the previous orders will count towards the LPs liquidity commitment. (0044-LIME-071) +- For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-071) +- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-083) - For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: - if during the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional and a bond penalty will apply. The next epoch the parameter change takes effect, LP will meet their committed volume of notional and no bond penalty will apply. (0044-LIME-072) - if the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) diff --git a/protocol/features.json b/protocol/features.json index c46b6a424..f84ad6163 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -332,6 +332,7 @@ "0044-LIME-080", "0044-LIME-081", "0044-LIME-082", + "0044-LIME-083", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From a372859a8edaa459af027ced7ef15e0c9a8a91f9 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 16 Aug 2023 11:51:49 +0100 Subject: [PATCH 449/649] chore: update milestone names --- protocol/features.json | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index f84ad6163..513ec3097 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,6 +1,6 @@ { "Iceberg Orders": { - "milestone": "deployment-1", + "milestone": "cosmic-deploy-1", "acs": [ "0014-ORDT-039", "0014-ORDT-007", @@ -39,7 +39,7 @@ ] }, "Stop Orders": { - "milestone": "deployment-1", + "milestone": "cosmic-deploy-1", "acs": [ "0014-ORDT-041", "0014-ORDT-042", @@ -83,7 +83,7 @@ ] }, "Successor Markets": { - "milestone": "deployment-1", + "milestone": "cosmic-deploy-1", "acs": [ "0001-MKTF-006", "0001-MKTF-007", @@ -127,7 +127,7 @@ ] }, "Governance Transfers": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0028-GOVE-073", "0028-GOVE-074", @@ -179,7 +179,7 @@ ] }, "Perps": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0001-MKTF-005", "0053-PERP-001", @@ -214,7 +214,7 @@ }, "Ethereum Oracles": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0082-ETHD-001", "0082-ETHD-002", @@ -258,7 +258,7 @@ ] }, "SLA": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0042-LIQF-032", "0042-LIQF-050", @@ -343,7 +343,7 @@ ] }, "Batch change proposals": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0028-GOVE-145", "0028-GOVE-146", @@ -353,7 +353,7 @@ ] }, "Referral program": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0083-RFPR-001", "0083-RFPR-002", @@ -412,7 +412,7 @@ ] }, "Market governance": { - "milestone": "deployment-2", + "milestone": "cosmic-deploy-2", "acs": [ "0028-GOVE-064", "0028-GOVE-069", @@ -438,7 +438,7 @@ ] }, "Spot": { - "milestone": "deployment-3", + "milestone": "plazzo-deploy-1", "acs": [ "0080-SPOT-001", "0080-SPOT-002", From 0a62e72fc9d8ed52d768dcdc411859095ffe22ad Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 16 Aug 2023 12:33:47 +0100 Subject: [PATCH 450/649] Update 0028-GOVE-governance.md new AC 154 During a recurring transfer fund the source account and ensure extra tokens are distributed --- protocol/0028-GOVE-governance.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 499799e4e..cbe799464 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -603,6 +603,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - For transfer source types of Market Insurance the destination must be a valid market ID else is rejected (0028-GOVE-091) - The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092) - For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) +- During a recurring transfer ensure that the correct tokens continue to be distributed when the source account is funded (0028-GOVE-154) ##### Governance initiated transfer enactment From 6687dd28c879b6c7b91fddeede66453560f809fd Mon Sep 17 00:00:00 2001 From: gordsport Date: Wed, 16 Aug 2023 17:08:00 +0100 Subject: [PATCH 451/649] chore: update the features.json file --- protocol/features.json | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/features.json b/protocol/features.json index 0f635aa7d..6be3eb8e5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -175,6 +175,7 @@ "0028-GOVE-142", "0028-GOVE-143", "0028-GOVE-144", + "0028-GOVE-154", "0055-TREA-011" ] }, From d97be91d00318e2f2a2c37a6aa72177f1e83baf5 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 21:03:54 +0100 Subject: [PATCH 452/649] fix: calculation for ac --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index c891fc35a..f152ba73f 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -380,7 +380,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - - If an LP has an active liquidity provision at the start of an epoch, during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs > 1` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) + - If an LP has an active liquidity provision at the start of an epoch, the average penalty rateover the previousn-1epochs is `0.75` and during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 3` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.375` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.375` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) - When `market.liquidity.performanceHysteresisEpochs > 1`: From 5e22b1b07f5209c268bbff0124f307d2bb2a04de Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 21:10:03 +0100 Subject: [PATCH 453/649] remove real time from ac --- protocol/0026-AUCT-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 8ffdb9351..8885554e1 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -161,7 +161,7 @@ message Market { - As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) - As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) - As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) -- As a user, I can get real time information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) +- As a user, I can get information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) - As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) - As an API user, I can identify: (0026-AUCT-008). For product spot: (0026-AUCT-028) - If a market is temporarily in an auction period From 7bbe54a7409a617276b0366656aefe2f7c682ed9 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 21:10:12 +0100 Subject: [PATCH 454/649] fix spelling --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index f152ba73f..7e7b5e591 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -380,7 +380,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - - If an LP has an active liquidity provision at the start of an epoch, the average penalty rateover the previousn-1epochs is `0.75` and during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 3` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.375` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.375` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) + - If an LP has an active liquidity provision at the start of an epoch, the average penalty rateover the previous `n-1` epochs is `0.75` and during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 3` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.375` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.375` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) - When `market.liquidity.performanceHysteresisEpochs > 1`: From ef19274c49a66e604cb8d0c36632b30d905add04 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 16 Aug 2023 21:13:03 +0100 Subject: [PATCH 455/649] fix: more spellcheck errors --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 7e7b5e591..332646a45 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -380,7 +380,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - - If an LP has an active liquidity provision at the start of an epoch, the average penalty rateover the previous `n-1` epochs is `0.75` and during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 3` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.375` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.375` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) + - If an LP has an active liquidity provision at the start of an epoch, the average penalty rate over the previous `n-1` epochs is `0.75` and during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 3` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.375` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.375` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) - When `market.liquidity.performanceHysteresisEpochs > 1`: From ef9b9f55fb1a28a7cf93b4575edd4978925575c2 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 17 Aug 2023 13:01:58 +0100 Subject: [PATCH 456/649] Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 332646a45..f72f49792 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -380,7 +380,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - - If an LP has an active liquidity provision at the start of an epoch, the average penalty rate over the previous `n-1` epochs is `0.75` and during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 3` is enacted, throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. The next epoch, the average `penalty rate` over the previous `n-1` epochs is `0.375` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.375` will be applied to liquidity fee payments at the end of the epoch. (0042-LIQF-054) + - An LP has an active liquidity provision at the start of an epoch. The penalty rate for said LP over the previous `2` epochs is `0.75`. During the epoch `market.liquidity.performanceHysteresisEpochs` is set to `3`. Throughout the current epoch the LP meets their liquidity provision requirements so they will have `fraction_of_time_on_book == 1`. The penalty applied to fee distribution at epoch end will be `0.375`. (0042-LIQF-054) - When `market.liquidity.performanceHysteresisEpochs > 1`: From f9749f196520d761facca248ba94e6547203bbcd Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 17 Aug 2023 13:12:22 +0100 Subject: [PATCH 457/649] fix: uncrossing --- protocol/0026-AUCT-auctions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index 8885554e1..a358bc1bf 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -161,7 +161,7 @@ message Market { - As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) - As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) - As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) -- As a user, I can get information through the API about a market in auction mode: indicative crossing price, indicative crossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) +- As a user, I can get information through the API about a market in auction mode: indicative uncrossing price, indicative uncrossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) - As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) - As an API user, I can identify: (0026-AUCT-008). For product spot: (0026-AUCT-028) - If a market is temporarily in an auction period From 3272d40f91bb3a510f2bb4c27340cff529761a8e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 17 Aug 2023 14:13:15 +0100 Subject: [PATCH 458/649] chore: remove new ac since its already covered --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 5 ++--- protocol/features.json | 1 - 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index f72f49792..65120df44 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -380,15 +380,14 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - - An LP has an active liquidity provision at the start of an epoch. The penalty rate for said LP over the previous `2` epochs is `0.75`. During the epoch `market.liquidity.performanceHysteresisEpochs` is set to `3`. Throughout the current epoch the LP meets their liquidity provision requirements so they will have `fraction_of_time_on_book == 1`. The penalty applied to fee distribution at epoch end will be `0.375`. (0042-LIQF-054) + - An LP has an active liquidity provision at the start of an epoch. The penalty rate for said LP over the previous `2` epochs is `0.75`. During the epoch `market.liquidity.performanceHysteresisEpochs` is set to `3`. Throughout the current epoch the LP meets their liquidity provision requirements so they will have `fraction_of_time_on_book == 1`. The penalty applied to fee distribution at epoch end will be `0.375`. (0042-LIQF-053) - When `market.liquidity.performanceHysteresisEpochs > 1`: - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-047) - - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75`, during the epoch market parameter change `market.liquidity.performanceHysteresisEpochs = 1` is enacted and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate will be applied to liquidity fee payments at the end of the epoch. The next epoch if LP always meet their liquidity provision requirements then they will a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-053) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they never meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 0` for the latest epoch a penalty rate of `1` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-040) - - If an LP has an active liquidity provision at the start of an epoch and no previous performance hysteresis and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-055) + - If an LP has an active liquidity provision at the start of an epoch and no previous performance hysteresis and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-054) ### SLA Performance bonus transfers diff --git a/protocol/features.json b/protocol/features.json index 513ec3097..72e4ce050 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -279,7 +279,6 @@ "0042-LIQF-046", "0042-LIQF-053", "0042-LIQF-054", - "0042-LIQF-055", "0044-LIME-057", "0044-LIME-058", "0044-LIME-059", From 69b1b14ca7cde5aaffc372a59bec2cf6ad032ced Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 17 Aug 2023 14:16:28 +0100 Subject: [PATCH 459/649] feat: added default value for calculationTimeStep --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index bf89735d8..1076b8486 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -396,7 +396,7 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) - - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` (0044-LIME-063) + - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` default value of `60m` (0044-LIME-063) #### Market parameters validation From 736e08b46580fa536cd57af346498d8ba36b9f9e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 17 Aug 2023 16:16:45 +0100 Subject: [PATCH 460/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: peterbarrow <62435083+peterbarrow@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 1076b8486..bcb747601 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -26,7 +26,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. ### Market parameters -All market parameters can be set / modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal and the new value take effect at at the first new epoch after enactment. +All market parameters can be set / modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal and the new value take effect at the first new epoch after enactment. - `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. From a3ab0a22ea95bd761b66270821b6d94c90e3dce5 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Thu, 17 Aug 2023 16:34:08 +0100 Subject: [PATCH 461/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: peterbarrow <62435083+peterbarrow@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index bcb747601..42b0c4921 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -356,7 +356,7 @@ In the case of spot markets it will be transferred into the network treasury for - if during the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional and a bond penalty will apply. The next epoch the parameter change takes effect, LP will meet their committed volume of notional and no bond penalty will apply. (0044-LIME-072) - if the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) - if during the epoch market parameter change `market.liquidity.priceRange = 0.01` (1%) the LP has a buy order at price `4.75` and a sell order at price `5.25`, the LP is meeting their committed volume of notional and no bond penalty will apply. The next epoch the parameter change takes effect, LP will not meet their volume of notional and bond penalty will apply. (0044-LIME-074) -- For a market with market parameter `market.liquidity.priceRange = 0.5` (5%), is in monitoring auction with `last trade price` set to `5` and a new LP has committed liquidity: +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and a new LP has committed liquidity: - if the `indicative uncrossing price` is set to `4`, the LP has a buy order at price `3.79` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-075) - if the `indicative uncrossing price` is set to `4`, the LP has a buy order at price `3.8` and a sell order at price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) - if the `indicative uncrossing price` is set to `6`, the LP has a buy order at price `4.75` and a sell order at price `6.31`, the LP is not meeting their committed volume of notional (0044-LIME-077) From e391b2f17a7f3b1faacfa5a07e0b6f0166270e07 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 18 Aug 2023 16:09:48 +0200 Subject: [PATCH 462/649] refactor: remove market value proxy --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 4 ++-- protocol/0076-DANO-data-node.md | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 13019d628..0d8ed1ab4 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -6,7 +6,7 @@ The aim of this specification is to set out how fees on Vega are set based on co ## Definitions / Glossary of terms used -- **Market value proxy window length `market.value.windowLength`**: sets the length of the window over which we estimate the market value. This is a network parameter. +- **`market.value.windowLength`**: sets the length of the window over which we estimate the market growth. This is a network parameter. - **Target stake**: as defined in [target stake spec](./0041-TSTK-target_stake.md). The ideal amount of stake LPs would commit to a market. - `market.liquidityProvision.minLpStakeQuantumMultiple`: There is a network wide parameter specifying the minimum LP stake as the `quantum` specified per asset, see [asset framework spec](../protocol/0040-ASSF-asset_framework.md). @@ -67,7 +67,7 @@ The guiding principle of this section is that by committing stake a liquidity pr ### Calculating liquidity provider equity-like share -The parameter which determines the period over which market value and hence growth is `market.value.windowLength` which could be e.g. a week. +The parameter which determines the period over which growth is estimated is `market.value.windowLength` which could be e.g. a week. From the end of the opening auction, which we will refer to as `t0` until `t0+market.value.windowLength` is the `0th` or "bootstrap period". Then from `t0+market.value.windowLength` until `t0 + 2 x market.value.windowLength` is the `1st` period and so on. For each LP we track the stake they have and also their virtual stake. For markets that have no "parent" market, see [governance](./0028-GOVE-governance.md) we postulate that before and during the 0th (bootstrap) any stake commitment or removal is mirrored in the virtual stake. diff --git a/protocol/0076-DANO-data-node.md b/protocol/0076-DANO-data-node.md index 3765e6284..40349959d 100644 --- a/protocol/0076-DANO-data-node.md +++ b/protocol/0076-DANO-data-node.md @@ -107,7 +107,6 @@ All of these should be available at various time resolutions: on every change, o - LP order submissions - Equity-like share changes -- Market value proxy - Target stake - Supplied stake From 4306bd8341c3c0b931073c20d0a09098061dda1e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Fri, 18 Aug 2023 15:25:24 +0100 Subject: [PATCH 463/649] fix: reworded new acs --- protocol/0044-LIME-lp_mechanics.md | 36 +++++++++++++++++------------- protocol/features.json | 2 -- 2 files changed, 20 insertions(+), 18 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 42b0c4921..40b0c60de 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -347,23 +347,27 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - For a market that is in continuous trading and LP has committed liquidity - - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-082) - - if `market.liquidity.providers.fee.calculationTimeStep` is set to `15s` and `validators.epoch.length` is set to `10s`, during the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 5s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `5` second (0044-LIME-061) - - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second (0044-LIME-062) + - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-061) + - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) - For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-071) -- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-083) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5` and a new LP has committed liquidity: - - if during the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional and a bond penalty will apply. The next epoch the parameter change takes effect, LP will meet their committed volume of notional and no bond penalty will apply. (0044-LIME-072) - - if the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-073) - - if during the epoch market parameter change `market.liquidity.priceRange = 0.01` (1%) the LP has a buy order at price `4.75` and a sell order at price `5.25`, the LP is meeting their committed volume of notional and no bond penalty will apply. The next epoch the parameter change takes effect, LP will not meet their volume of notional and bond penalty will apply. (0044-LIME-074) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and a new LP has committed liquidity: - - if the `indicative uncrossing price` is set to `4`, the LP has a buy order at price `3.79` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-075) - - if the `indicative uncrossing price` is set to `4`, the LP has a buy order at price `3.8` and a sell order at price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) - - if the `indicative uncrossing price` is set to `6`, the LP has a buy order at price `4.75` and a sell order at price `6.31`, the LP is not meeting their committed volume of notional (0044-LIME-077) - - if the `indicative uncrossing price` is set to `6`, the LP has a buy order at price `4.75` and a sell order at price `6.3`, the LP is meeting their committed volume of notional (0044-LIME-078) - - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.74` and a sell order at price `5.25`, the LP is not meeting their committed volume of notional (0044-LIME-079) - - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.75` and a sell order at price `5.26`, the LP is not meeting their committed volume of notional (0044-LIME-080) - - if there is no `indicative uncrossing price` and the LP has a buy order at price `4.75` and a sell order at price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-081) +- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-081) +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5`, a new LP has committed liquidity with buy order at price `4.74` and sell order at price `5.25`. During the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted then at the end of the current epoch the LP is meeting their committed volume of notional and a bond penalty will apply. (0044-LIME-072) + +- For a market with parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5`, a new LP has committed liquidity and orders at buy price `4.74` and sell price `5.25`. During the epoch market parameter change `market.liquidity.priceRange = 0.01` (1%) is enacted then at the end of the current epoch the LP is meeting their volume of notional and penalty will not apply. (0044-LIME-074) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.79` and sell price `5.25`, at the end of the epoch the LP is not meeting their committed volume of notional because the buy price `3.79` is less than `5%` of `1-0.05 x min(5, 4) = 3.80` (0044-LIME-075) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and a sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31`, the LP is not meeting their committed volume of notional because the sell price `6.31` is more than `5%` of `1+ 0.05 x max (5, 6) = 6.30` (0044-LIME-077) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.3`, the LP is not meeting their committed volume of notional (0044-LIME-078) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we dont have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` and sell price `5.25`, the LP is not meeting their committed volume of notional because the buy price `4.74` is less than `5%` of `1-0.05 x min(5, n/a) = 4.75` (0044-LIME-079) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we dont have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` the LP is not meeting their committed volume of notional because the sell price `5.26` is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25` (0044-LIME-080) + +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we dont have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) ### Qualifying Order Types diff --git a/protocol/features.json b/protocol/features.json index 72e4ce050..08fca7f63 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -330,8 +330,6 @@ "0044-LIME-079", "0044-LIME-080", "0044-LIME-081", - "0044-LIME-082", - "0044-LIME-083", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From 8ab0dbfb124c8f428ee57e53e38c614d82d69ee2 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Sun, 20 Aug 2023 22:31:02 +0100 Subject: [PATCH 464/649] refactor: update 0070-MKTD-007 --- protocol/0070-MKTD-market-decimal-places.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 8171cde75..b8c3d9a21 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -79,6 +79,6 @@ Trades of course result in transfers. The amounts transferred (for the trade as - As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). For product spot: (0070-MKTD-011) - As a user I should see the market data prices using market precision. (0070-MKTD-005). For product spot: (0070-MKTD-012) - Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006). For product spot: (0070-MKTD-013) -- As a user, offsets specified in pegged orders and LP shapes represent the smallest value according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) +- As a user, offsets specified in pegged orders represent the smallest value according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008). For product spot: ( 0070-MKTD-015) - Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) From c761628959dcca8d75dd5cfa3b31162697191f8c Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 21 Aug 2023 10:09:15 +0100 Subject: [PATCH 465/649] Update protocol/0070-MKTD-market-decimal-places.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0070-MKTD-market-decimal-places.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index b8c3d9a21..34d092279 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -79,6 +79,6 @@ Trades of course result in transfers. The amounts transferred (for the trade as - As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). For product spot: (0070-MKTD-011) - As a user I should see the market data prices using market precision. (0070-MKTD-005). For product spot: (0070-MKTD-012) - Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006). For product spot: (0070-MKTD-013) -- As a user, offsets specified in pegged orders represent the smallest value according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) +- As a user, offsets specified in pegged orders represent the smallest incremental value to tick away from the offset of a pegged order according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008). For product spot: ( 0070-MKTD-015) - Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) From 2f65e657fd9433fca3d059840b770927a0d62d1d Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 21 Aug 2023 10:14:29 +0100 Subject: [PATCH 466/649] Update protocol/0070-MKTD-market-decimal-places.md --- protocol/0070-MKTD-market-decimal-places.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 34d092279..2ef3b4f8b 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -79,6 +79,6 @@ Trades of course result in transfers. The amounts transferred (for the trade as - As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). For product spot: (0070-MKTD-011) - As a user I should see the market data prices using market precision. (0070-MKTD-005). For product spot: (0070-MKTD-012) - Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006). For product spot: (0070-MKTD-013) -- As a user, offsets specified in pegged orders represent the smallest incremental value to tick away from the offset of a pegged order according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) +- As a user, offsets specified in pegged orders represent the smallest incremental value to tick away from the pegged price of a pegged order according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) - Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008). For product spot: ( 0070-MKTD-015) - Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) From 929d5281c55d626c3ecde4b1fa6de7905fec3baa Mon Sep 17 00:00:00 2001 From: "vanitha.thangavelu" Date: Mon, 21 Aug 2023 13:38:16 +0100 Subject: [PATCH 467/649] feat: added Acceptance Criteria for Liquidity Provisioning Signed-off-by: vanitha.thangavelu --- protocol/0044-LIME-lp_mechanics.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 14ac504fb..dfd10bb49 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -341,11 +341,19 @@ In the case of spot markets it will be transferred into the network treasury for - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) + - The LP can increase their commitment at any time without incurring fee (0044-LIME-061) for spot (0044-LIME-062) + - When LP increases their commitment higher than their account balance are rejected and old provision persists (0044-LIME-063) for spot (0044-LIME-064) + - When LP decreases their commitment are not charged (0044-LIME-065) for spot (0044-LIME-066) + - When LP decreases their commitment to zero are rejected (0044-LIME-067) for spot (0044-LIME-068) + - When LP amends the Fee Factor greater than `market.liquidityV2.maximumLiquidityFeeFactorLevel` are rejected (0044-LIME-070) for spot (0044-LIME-071) + - Distressed LP is cancelled automatically or closeout of LP order which doesn't meet minimum margin are cancelled (0044-LIME-071) for spot (0044-LIME-072) + - Party submits LP in multiple markets and multiple bond accounts are created and managed by vega (0044-LIME-072) for spot (0044-LIME-073) ### Qualifying Order Types - Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-029) +- LPs can submit GFA orders and do not count towards an LPs liquidity commitment (0044-LIME-069) ### Snapshot @@ -374,3 +382,4 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) + From 669cd7f398a9280a521bc002d55ea11d74621578 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 22 Aug 2023 17:30:43 +0200 Subject: [PATCH 468/649] refactor: clarify API considerations --- ...3-PERP-product_builtin_perpetual_future.md | 26 ++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 49335a255..0f56298b4 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -190,7 +190,28 @@ Should a perpetual futures market get closed using the [governance proposal](./0 ### API considerations -It should be possible to query the market for the list of current funding payment data points as well as history of calculated funding payment values. +For every completed funding period the following data should be emitted: + +- funding period start time, +- funding period end time, +- funding rate, +- funding payment, +- external (spot) price TWAP, +- internal (mark) price TWAP. + +Furthermore, within the ongoing funding period the following data should be emitted at least every time the mark price is updated: + +- funding period start time, +- estimate time, +- funding rate estimate, +- funding payment estimate, +- external (spot) price TWAP to-date, +- internal (mark) price TWAP to-date. + + The estimates are obtained assuming the current period ended now. The time for which the estimate was obtained is recorded as `estimate time`. + Please note that the above estimates calculated within the ongoing funding period should be available internally for inclusion in the margin calculation as outlined in the [margin considerations](#5-margin-considerations) subsection as well as on the data-node. Only the most recent observation should be kept in both these places. + +In both cases the estimates are for a hypothetical position of size 1. ## Acceptance Criteria @@ -206,3 +227,6 @@ It should be possible to query the market for the list of current funding paymen 1. When the funding payment is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) 1. When the funding payment is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) 1. An event containing funding rate should be emitted each time the funding payment is calculated (0053-PERP-017) +1. No data relating to funding payment is available until the perpetual futures market leaves the opening auction. (0053-PERP-018) +1. For the ongoing period the following data is available via the API: funding period start time, estimate time, funding rate estimate, funding payment estimate, external (spot) price TWAP to-date, internal (mark) price TWAP to-date. (0053-PERP-019) +1. For each of the fully completed past funding periods the following data is available (subject to data-node's retention settings): funding period start time, funding period end time, funding rate, funding payment, external (spot) price TWAP, internal (mark) price TWAP. (0053-PERP-020) From da796da53d622b035ae2a4f2fafb6e9d7b8f244e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 23 Aug 2023 09:47:56 +0100 Subject: [PATCH 469/649] fix: mkt param to be a netparam --- protocol/0044-LIME-lp_mechanics.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 14ac504fb..80f19b477 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,6 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. +- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value `0`. Maximum valid value `validators.epoch.length`. ### Market parameters @@ -30,8 +31,6 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.committmentMinTimeFraction` (decimal) — minimum fraction of time LPs must spend "on the book" providing their committed liquidity. This is a decimal number in the interval $[0,1]$ i.e. both limits included. When set to $0$ the SLA mechanics are switched off for the market entirely. -- `market.liquidity.providers.fee.calculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. - - `market.liquidity.performanceHysteresisEpochs` (uint) - number of liquidity epochs over which past performance will continue to affect rewards. - `market.liquidity.slaCompetitionFactor` - the maximum fraction of their accrued fees an LP that meets the SLA implied by `market.liquidity.committmentMinTimeFraction` will lose to LPs that achieved a higher SLA performance than them. From 06e3ab62aed9863ece0d034dcdb096a7dedea214 Mon Sep 17 00:00:00 2001 From: "vanitha.thangavelu" Date: Wed, 23 Aug 2023 09:49:49 +0100 Subject: [PATCH 470/649] fix: modified the LP ACs as per the feedback Signed-off-by: vanitha.thangavelu --- protocol/0044-LIME-lp_mechanics.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index dfd10bb49..a22c68888 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -343,17 +343,17 @@ In the case of spot markets it will be transferred into the network treasury for - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - The LP can increase their commitment at any time without incurring fee (0044-LIME-061) for spot (0044-LIME-062) - When LP increases their commitment higher than their account balance are rejected and old provision persists (0044-LIME-063) for spot (0044-LIME-064) - - When LP decreases their commitment are not charged (0044-LIME-065) for spot (0044-LIME-066) - - When LP decreases their commitment to zero are rejected (0044-LIME-067) for spot (0044-LIME-068) - - When LP amends the Fee Factor greater than `market.liquidityV2.maximumLiquidityFeeFactorLevel` are rejected (0044-LIME-070) for spot (0044-LIME-071) - - Distressed LP is cancelled automatically or closeout of LP order which doesn't meet minimum margin are cancelled (0044-LIME-071) for spot (0044-LIME-072) - - Party submits LP in multiple markets and multiple bond accounts are created and managed by vega (0044-LIME-072) for spot (0044-LIME-073) + - When LP decreases their commitment are charged as per `market.liquidity.earlyExitPenalty` (0044-LIME-065) for spot (0044-LIME-066) + - When LP that creates new provision with zero commitment or amend a provision with zero commitment are rejected with error message that commitment amount is too low (0044-LIME-067) for spot (0044-LIME-068) + - When LP amends the Fee Factor greater than `market.liquidity.maximumLiquidityFeeFactorLevel` are rejected (0044-LIME-070) for spot (0044-LIME-071) + - Distressed LP which doesn't meet minimum margin is not cancelled automatically and stays active (0044-LIME-071) for spot (0044-LIME-072) + - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-072) for spot (0044-LIME-073) ### Qualifying Order Types - Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-029) -- LPs can submit GFA orders and do not count towards an LPs liquidity commitment (0044-LIME-069) +- LPs can submit GFA orders which gets cancelled as soon as market exits opening-auction and do not count towards an LPs liquidity commitment (0044-LIME-069) ### Snapshot From 039fab3bfd1d9fcb7f5a7177cb885677a7e692df Mon Sep 17 00:00:00 2001 From: Tom Date: Wed, 23 Aug 2023 09:50:16 +0100 Subject: [PATCH 471/649] feat: Adding generic AC for perp order types (#1908) * feat: Adding generic AC for perp order types --- protocol/0014-ORDT-order_types.md | 8 ++++++++ protocol/features.json | 8 ++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 3b895b718..9b83d992d 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -388,6 +388,14 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with - API end points should be available to query stop orders with all relevant fields. (0014-ORDT-080) +## Perpetuals + +- All order types should be able to be placed and act in the same way on a perpetual market as on an expiring future market. Specifically this includes: + - Limit orders (0014-ORDT-120) + - Market orders (0014-ORDT-121) + - Icebergs (0014-ORDT-122) + - All stop order types (0014-ORDT-123) + ### See also - [0068-MATC-Matching engine](./0068-MATC-matching_engine.md) diff --git a/protocol/features.json b/protocol/features.json index 0f635aa7d..8dd4a268c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -126,7 +126,7 @@ "0081-SUCM-022" ] }, - "Governance Transfers": { + "Governance Transfers": { "milestone": "deployment-2", "acs": [ "0028-GOVE-073", @@ -209,7 +209,11 @@ "0073-LIMN-110", "0073-LIMN-111", "0081-SUCM-002", - "0081-SUCM-015" + "0081-SUCM-015", + "0014-ORDT-120", + "0014-ORDT-121", + "0014-ORDT-122", + "0014-ORDT-123" ] }, From e96c150ddfdd44e25fb31bb825afcd4971124071 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 22 Aug 2023 21:52:44 +0100 Subject: [PATCH 472/649] refactor: clarify network parameter behaviour --- protocol/0083-RFPR-on_chain_referral_program.md | 4 ++++ protocol/0084-VDPR-volume_discount_program.md | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 6af261223..523026d8c 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -32,6 +32,10 @@ To create an emphasis on community, collaboration, and competition. Referrers wi - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` - limits the notional volume in quantum units which is eligible each epoch for referral program mechanisms - `referralProgram.minStakedVegaTokens` - limits referral code generation to parties staking at least this number of tokens +Note, if any of the above mentioned network parameters are updated whilst a referral program is active, the active program will not be affected in anyway even if the active program breaches the new network parameter value. The new network parameter value however will be checked on any future [referral program proposals](#governance-proposals). + +If the community wish to update the referral program limits **and** apply these to the existing program, they can do so by first updating the network parameters and then submitting a proposal to update the program (adhering to the new limits). + ## Governance Proposals Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 358525484..f9d056782 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -7,6 +7,10 @@ The volume discount program provides tiered discounts on taker fees to traders. - `volumeDiscountProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a volume discount program - `volumeDiscountProgram.maxVolumeDiscountFactor` - limits the maximum volume discount factor which can be specified as part of a volume discount program +Note, if any of the above mentioned network parameters are updated whilst a volume discount program is active, the active program will not be affected in anyway even if the active program breaches the new network parameter value. The new network parameter value however will be checked on any future [volume discount program proposals](#governance-proposals). + +If the community wish to update the volume discount program limits **and** apply these to the existing program, they can do so by first updating the network parameters and then submitting a proposal to update the program (adhering to the new limits). + ## Governance proposals Enabling or changing the terms of the volume discount program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: From edace6498b6a74ccf1e57d4ecbc7209d3fdf40f5 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 23 Aug 2023 08:57:24 +0100 Subject: [PATCH 473/649] feat: add acceptance criteria for program updates --- protocol/0083-RFPR-on_chain_referral_program.md | 6 ++++++ protocol/0084-VDPR-volume_discount_program.md | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 523026d8c..fc9b0e26b 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -370,6 +370,12 @@ The Estimate Fees API should now calculate the following additional information: - all referees should not receive any discount on their taker fees (0083-RFPR-019). 1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch (0083-RFPR-020). 1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory (0083-RFPR-021). +1. Updating any of the following network parameters whilst there is an active referral program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future referral program proposals. + - `referralProgram.maxBenefitTiers` (0083-RFPR-041) + - `referralProgram.maxReferralRewardFactor` (0083-RFPR-042) + - `referralProgram.maxReferralDiscountFactor` (0083-RFPR-043) + - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` (0083-RFPR-044) + - `referralProgram.minStakedVegaTokens` (0083-RFPR-045) #### Updating a referral set diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index f9d056782..9fbc69e88 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -135,7 +135,9 @@ The Trades API should now also expose the following additional information for e - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug (0084-VDPR-009). - Proposal for program B accepted and overrides program A the first epoch after 1st June (0084-VDPR-010). - Program is closed first epoch after 31st Aug, there should be no active proposals (0084-VDPR-011). - +1. Updating any of the following network parameters whilst there is an active volume discount program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future volume discount program proposals. + - `volumeDiscountProgram.maxBenefitTiers` (0084-VDPR-015). + - `volumeDiscountProgram.maxVolumeDiscountFactor` (0084-VDPR-016). ### Setting benefit factors From c36f97c373904cb4a4675b3ddbf33a78424e63f8 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 23 Aug 2023 09:00:55 +0100 Subject: [PATCH 474/649] feat: update features --- protocol/features.json | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 8dd4a268c..2fbad18e9 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -374,6 +374,11 @@ "0083-RFPR-038", "0083-RFPR-039", "0083-RFPR-040", + "0083-RFPR-041", + "0083-RFPR-042", + "0083-RFPR-043", + "0083-RFPR-044", + "0083-RFPR-045", "0084-VDPR-001", "0084-VDPR-002", "0084-VDPR-003", @@ -387,7 +392,9 @@ "0084-VDPR-011", "0084-VDPR-012", "0084-VDPR-013", - "0084-VDPR-014" + "0084-VDPR-014", + "0084-VDPR-015", + "0084-VDPR-016" ] }, "Market governance": { From 7c00967ec085deeeb0aa87e071cd05ee703fd06c Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 23 Aug 2023 10:42:22 +0100 Subject: [PATCH 475/649] fix spellcheck --- protocol/0044-LIME-lp_mechanics.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 40b0c60de..1cd666a0b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -363,11 +363,11 @@ In the case of spot markets it will be transferred into the network treasury for - For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.3`, the LP is not meeting their committed volume of notional (0044-LIME-078) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we dont have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` and sell price `5.25`, the LP is not meeting their committed volume of notional because the buy price `4.74` is less than `5%` of `1-0.05 x min(5, n/a) = 4.75` (0044-LIME-079) +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` and sell price `5.25`, the LP is not meeting their committed volume of notional because the buy price `4.74` is less than `5%` of `1-0.05 x min(5, n/a) = 4.75` (0044-LIME-079) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we dont have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` the LP is not meeting their committed volume of notional because the sell price `5.26` is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25` (0044-LIME-080) +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` the LP is not meeting their committed volume of notional because the sell price `5.26` is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25` (0044-LIME-080) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we dont have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) +- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) ### Qualifying Order Types From 0acaf8a664a285855820acc73ad0a17258c2571f Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 23 Aug 2023 11:00:13 +0100 Subject: [PATCH 476/649] fix: mkt param to be a netparam --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 80f19b477..194e95459 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,7 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. -- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value `0`. Maximum valid value `validators.epoch.length`. +- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value `0`. Maximum valid value `validators.epoch.length`. ### Market parameters From b66158782e2252018ff9a6a7a50eb4896b7da72d Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 23 Aug 2023 11:01:52 +0100 Subject: [PATCH 477/649] refactor: update spelling as per feedback Co-authored-by: Tom --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- protocol/0084-VDPR-volume_discount_program.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index fc9b0e26b..8282e06a5 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -32,7 +32,7 @@ To create an emphasis on community, collaboration, and competition. Referrers wi - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` - limits the notional volume in quantum units which is eligible each epoch for referral program mechanisms - `referralProgram.minStakedVegaTokens` - limits referral code generation to parties staking at least this number of tokens -Note, if any of the above mentioned network parameters are updated whilst a referral program is active, the active program will not be affected in anyway even if the active program breaches the new network parameter value. The new network parameter value however will be checked on any future [referral program proposals](#governance-proposals). +Note, if any of the above mentioned network parameters are updated whilst a referral program is active, the active program will not be affected in any way even if the active program breaches the new network parameter value. The new network parameter value however will be checked on any future [referral program proposals](#governance-proposals). If the community wish to update the referral program limits **and** apply these to the existing program, they can do so by first updating the network parameters and then submitting a proposal to update the program (adhering to the new limits). diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 9fbc69e88..a1d004666 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -7,7 +7,7 @@ The volume discount program provides tiered discounts on taker fees to traders. - `volumeDiscountProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a volume discount program - `volumeDiscountProgram.maxVolumeDiscountFactor` - limits the maximum volume discount factor which can be specified as part of a volume discount program -Note, if any of the above mentioned network parameters are updated whilst a volume discount program is active, the active program will not be affected in anyway even if the active program breaches the new network parameter value. The new network parameter value however will be checked on any future [volume discount program proposals](#governance-proposals). +Note, if any of the above mentioned network parameters are updated whilst a volume discount program is active, the active program will not be affected in any way even if the active program breaches the new network parameter value. The new network parameter value however will be checked on any future [volume discount program proposals](#governance-proposals). If the community wish to update the volume discount program limits **and** apply these to the existing program, they can do so by first updating the network parameters and then submitting a proposal to update the program (adhering to the new limits). From 5b43bb55ebf73d70dd7b0a49f18553ebc03a1427 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 3 Aug 2023 19:28:13 +0100 Subject: [PATCH 478/649] feat: add vesting spec --- protocol/0085-RVST-rewards_vesting.md | 50 +++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 protocol/0085-RVST-rewards_vesting.md diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md new file mode 100644 index 000000000..4d9f6f417 --- /dev/null +++ b/protocol/0085-RVST-rewards_vesting.md @@ -0,0 +1,50 @@ +# Rewards Vesting Specification + +## Summary + +The aim of the rewards vesting mechanics is to prevent farming rewards by delaying the payout of rewards through vesting. To encourage longer term behaviour parties can accelerate their rewards vesting rate through the [activity streak program](./0086-ASPR-activity_streak_program.md). + +## Network Parameters + +- `rewards.vesting.baseRate`: the proportion of rewards in a vesting account which are vested each epoch +- `rewards.vesting.minimumTransfer`: the minimum amount (expressed in quantum) which can be vested each epoch + +## Vesting mechanics + +As detailed in [distributing rewards](), each party has their rewards paid into vesting rewards accounts (one for each asset). + +At the end of each epoch, a proportion of the rewards accumulated in each "vesting" account should be released and transferred to the respective "vested" account. The percentage released can be scaled by the account owner increasing their [activity streak](./0086-ASPR-activity_streak_program.md) and a minimum transfer amount will be applied to ensure the account is eventually emptied. The proportion released and minimum applied are controlled for parameters for the asset. + +Now, let: + +- $T$ be the amount to be "vested" (transferred from the vesting account to the vested account) +- $B_{vested}$ be the total quantum amount in the vesting account +- $r_{bvr}$ be the network parameter `rewards.vesting.baseRate` +- $a$ be the account owners current [`activity_streak_vesting_multiplier`](./0086-ASPR-activity_streak_program.md#setting-activity-benefits) +- $m_{mva}$ be the network parameter `rewards.vesting.minimumTransfer` + +The quantum amount to be transferred from each "vesting" account to the relevant "vested" account is defined as: +$$ +T = min(B_{vested} * r * a, m) +$$ + +When transferring funds from the vesting account to the vested account, a new transfer type should be used, `TRANSFER_TYPE_REWARDS_VESTED`. + +## APIs + +### Accounts API + +Must expose the following: + +- every account with `ACCOUNT_TYPE_VESTING_REWARDS` for each party +- every account with `ACCOUNT_TYPE_VESTED_REWARDS` for each party + +### Ledger Entries API + +Must expose the following: + +- every transfer with `TRANSFER_TYPE_REWARDS_VESTED` for each party + +## Acceptance Criteria + +TBD \ No newline at end of file From ab6a30283a1874e16c33c74c84716060b091b0c5 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 3 Aug 2023 19:28:34 +0100 Subject: [PATCH 479/649] feat: add activity spec --- protocol/0086-ASPR-activity_streak_program.md | 125 ++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 protocol/0086-ASPR-activity_streak_program.md diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md new file mode 100644 index 000000000..ddaa370dd --- /dev/null +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -0,0 +1,125 @@ +# Activity Streak Program + +The purpose of the activity streak program is to reward loyal, active traders with the following tiered benefits: + +- a greater share of rewards schemes +- an accelerated vesting rate on locked rewards + +Parties access higher tiers and greater benefits by maintaining an activity streak. The length of a streak is measured in epochs and a party is considered active if they made a trade or held an open position during the epoch. If a party is inactive for more than a specified number of epochs they lose their streak. + +## Network parameters + +- `rewards.activityStreak.benefitTiers`: is an ordered list of dictionaries defining the requirements and benefits for each tier. +- `rewards.activityStreak.inactivityLimit`: the maximum number of epochs a trader can be inactive before loosing their streak. +- `rewards.activityStreak.minQuantumOpenVolume`: the minimum open notional volume (expressed in quantum) for a trader to be considered active in an epoch +- `rewards.activityStreak.minQuantumTradeVolume`: the minimum trade volume (expressed in quantum) for a trader to be considered active in an epoch + + +## Governance proposals + +The network parameter [`rewards.activityStreak.benefitTiers`](#network-parameters) can be updated via a `UpdateNetworkParameter` governance proposal. Each tier in the ordered list must have the following fields: + +- `minimum_activity_streak`: int greater or equal to `0` defining the minimum activity streak a party must have to access this tier +- `reward_multiplier`: float greater or equal to `1` defining the factor to scale a parties [reward shares]() by +- `vesting_multiplier`: float greater or equal to `1` defining the factor to scale a parties [base vesting rate]() by + +*Example:* +```proto +message UpdateNetworkParameter{ + changes: NetworkParameter{ + key: "rewards.activityStreak.benefitTiers", + value: [ + {"minimum_activity_streak": 1, "reward_multiplier": 1.0, "vesting_multiplier": 1.05}, + {"minimum_activity_streak": 7, "reward_multiplier": 5.0, "vesting_multiplier": 1.25}, + {"minimum_activity_streak": 31, "reward_multiplier": 10.0, "vesting_multiplier": 1.50}, + {"minimum_activity_streak": 365, "reward_multiplier": 20.0, "vesting_multiplier": 2.00}, + + ], + } +} +``` + +## Activity streak mechanics + +The following steps should occur **before** rewards are [distributed] and [vested]. + +### Setting activity / inactivity streak + +For the feature, the network must track each parties "activity streak". At the end of an epoch: + +- if a party was "active" in the epoch + + - increment their `activity_streak` by `1` + - reset their `inactivity_streak` to `0`. + +- if a party was "inactive" in the epoch + + - increment their `inactivity_streak` streak by `1` + - if their `inactivity_streak` is greater than or equal to the `rewards.activityStreak.streakLength`, reset their `activity_streak` to `0`. + +A party is defined as active if they fulfil **either** of the following criteria: + +- their open interest was strictly greater than `rewards.activityStreak.minQuantumOpenVolume` at any point in the epoch +- their total trade volume was strictly greater than `rewards.activityStreak.minQuantumTradeVolume` at the end of the epoch + +### Setting activity benefits + +After determining a parties "activity streak" there `reward_distribution_activity_multiplier` and `reward_vesting_activity_multiplier` should be set according to the highest tier they qualify for. + +```pseudo +Given: + rewards.activityStreak.benefitTiers: [ + [ + {"minimum_activity_streak": 1, "reward_multiplier": 1.0, "vesting_multiplier": 1.05}, + {"minimum_activity_streak": 7, "reward_multiplier": 5.0, "vesting_multiplier": 1.25}, + {"minimum_activity_streak": 31, "reward_multiplier": 10.0, "vesting_multiplier": 1.50}, + {"minimum_activity_streak": 365, "reward_multiplier": 20.0, "vesting_multiplier": 2.00}, + + ], + ] + +And: + activity_streak=48 + inactivity_streak=3 + +Then: + reward_distribution_activity_multiplier=10.0 + reward_vesting_activity_multiplier=1.50 +``` + +### Applying activity benefits + +#### Applying the activity reward multiplier + +The `activity_streak_reward_multiplier` scales the parties [reward share]() for all rewards they are eligible for. + +#### Applying the activity vesting multiplier + +The `activity_streak_vesting_multiplier` scales the parties [vesting rate]() of all funds locked in the parties vesting accounts. + + +## APIs + +### Parties API + +Must expose the following: + +- a parties `activity_streak` +- a parties `inactivity_streak` +- whether a party has been considered "active" in the current epoch +- a parties current `reward_distribution_activity_multiplier` +- a parties current `reward_vesting_activity_multiplier` + +## Acceptance Criteria + +### Governance proposals + +TBD + +### Setting activity / inactivity streak + +TBD + +### Setting activity benefits + +TBD \ No newline at end of file From da05d5afbd764b0473046705ed11a90eb5091755 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 02:37:14 +0100 Subject: [PATCH 480/649] feat: update reward distribution --- protocol/0056-REWA-rewards_overview.md | 119 +++++++++++++++++++------ 1 file changed, 94 insertions(+), 25 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index edc794678..83976a171 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -1,6 +1,6 @@ # Reward framework -The reward framework provides a mechanism for measuring and rewarding a number of key activities on the Vega network. +The reward framework provides a mechanism for measuring and rewarding individuals or [teams](./0083-RFPR-on_chain_referral_program.md#glossary) (collectively referred to within this spec as entities) for a number of key activities on the Vega network. These rewards operate in addition to the main protocol economic incentives which come from [fees](0029-FEES-fees.md) on every trade. These fees are the fundamental income stream for [liquidity providers LPs](0042-LIQF-setting_fees_and_rewarding_lps.md) and [validators](./0061-REWP-pos_rewards.md). @@ -9,7 +9,6 @@ The additional rewards described here can be funded arbitrarily by users of the Note that transfers via governance, including to fund rewards, is a post-Oregon Trail feature. Note that validator rewards (and the reward account for those) is covered in [validator rewards](./0061-REWP-pos_rewards.md) and is separate from the trading reward framework described here. - ## New network parameter for market creation threshold The parameter `rewards.marketCreationQuantumMultiple` will be used together with [quantum](0040-ASSF-asset_framework.md) to asses market size when deciding whether a market qualifies for the payment of market creation rewards. @@ -20,17 +19,18 @@ Therefore, for example, to reward futures markets when they reach a lifetime tra At a high level, rewards work as follows: -- Reward metrics are calculated for each combination of [reward type, party, market]. - - The calculation used for the reward metric is specific to each reward type. +- Individual reward metrics are calculated for each combination of [reward type, party, market] and team reward metrics for each combination of [reward type, team, market]. At the end of the epoch: 1. Recurring reward transfers (set up by the parties funding the rewards) are made to the reward account(s) for a specific reward type, for one or more markets in scope where the total reward metric is `>0`. See [transfers](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts). -1. Then the entire balance of each reward account is distributed to the parties with a non-zero reward metric for that reward type and market, pro-rata by their reward metric. +1. Then the entire balance of each reward account is distributed amongst entities with a non-zero reward metric for that reward type and market using the mechanism specified in the recurring transfer. +1. Distributed rewards are transferred to a [vesting account](./0085-RVST-rewards_vesting.md). + +## Individual reward metrics -## Reward metrics +Individual reward metrics are scoped by [`reward type`, `market`, `party`] (this triplet can be thought of as a primary key for fee-based reward metrics). -Fee-based reward metrics are scoped by [`reward type`, `market`, `party`] (this triplet can be thought of as a primary key for fee-based reward metrics). Therefore a party may be in scope for the same reward type multiple times but no more than once per market per epoch. Metrics will be calculated at the end of every epoch, for every eligible party, in each market for each reward type. Metrics only need to be calculated where the [market, reward type] reward account has a non-zero balance of at least one asset. @@ -38,10 +38,9 @@ Metrics only need to be calculated where the [market, reward type] reward accoun Reward metrics will be calculated once for each party/market combination in the reward metric asset which is the [settlement asset](0070-MKTD-market-decimal-places.md) of the market. This is the original precision for the metric source data. -### Market activity (fee based) reward metrics +### Fee-based reward metrics -There will be three market activity reward metrics calculated based on fees (as a proxy for activity). -Each of these represents a reward type with its own segregated reward accounts for each market. +There will be three reward metrics calculated based on fees. 1. Sum of maker fees paid by the party on the market this epoch 1. Sum of maker fees received by the party on the market this epoch @@ -51,7 +50,15 @@ These metrics apply only to the sum of fees for the epoch in question. That is, the metrics are reset to zero for all parties at the end of the epoch. If the reward account balance is 0 at the end of the epoch for a given market, any parties with non-zero metrics will not be rewarded for that epoch and their metric scores do not roll over (they are still zeroed). -Market activity (fee based) reward metrics (the total fees paid/received by each party as defined above) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and are restored after a checkpoint restart to ensure rewards are not lost. +Fee-based reward metrics (the total fees paid/received by each party as defined above) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and are restored after a checkpoint restart to ensure rewards are not lost. + +### Open interest metrics + + +### Pnl metrics + + +### Volatility metrics ### Market creation reward metrics @@ -82,6 +89,13 @@ This flag is used to prevent any given funder from funding a creation reward in Market creation reward metrics (both each market's `cumulative volume` and the payout record flags to identify [funder, market scope, reward asset] combinations that have already been rewarded) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and will be restored after a checkpoint restart. +## Team reward metrics + +All metrics (except [market creation](#market-creation-reward-metrics)) can be used to define the distribution of both individual rewards and team rewards. + +A team’s reward metric is the weighted average metric score of the top performing `n` % of team members by number where `n` is specified when creating the recurring transfer (i.e. for a team of 100 parties with `n=0.1`, the 10 members with the highest metric score). + + ## Reward accounts Trading reward accounts are defined by the reward asset (the asset in which the reward is paid out), the market, and the reward type (metric). @@ -98,26 +112,81 @@ Reward accounts and balances must be saved in [LNL checkpoints](./0073-LIMN-limi ## Reward distribution -All rewards are paid out at the end of each epoch *after* [recurring transfers](0057-TRAN-transfers.md) have been executed. -The entire reward account balance is paid out every epoch unless the total value of the metric over all parties is zero, in which case the balance will also be zero anyway (there are no fractional payouts). -There are no payout delays, rewards are paid out instantly at epoch end. +All rewards are distributed to [vesting accounts](./0085-RVST-rewards_vesting.md) at the end of each epoch *after* [recurring transfers](0057-TRAN-transfers.md) have been executed. -Rewards will be distributed pro-rata by the party's reward metric value to all parties that have metric values `>0`. Note that for the market creation reward, the metric is defined to either be `0` or `1`, which will lead to equal payments for each eligible market under the pro-rata calculation. If we have reward account balance `R` and parties `p_1 – p_n` with non-zero metrics `m_1 – m_n` on the market in question: +The entire reward account balance is paid out every epoch unless the total value of the metric over all entities is zero, in which case the balance will also be zero anyway (there are no fractional payouts). -```math -[p_1, m_1] -[p_2, m_2] -... -[p_n, m_n] -``` +Rewards are first [distributed amongst entities](#distributing-rewards-amongst-entities) (individuals or teams) and then any rewards distributed to teams are [distributed amongst team members](#distributing-rewards-amongst-team-members). + +### Distributing rewards amongst entities + +Rewards are distributed amongst entities based on the distribution method defined in the recurring transfer. + +The protocol currently supports the following distribution strategies: + +- [pro-rata](#distributing-pro-rata) by reward metric +- [exponential-decay](#distributing-with-exponential-decay) by reward metric + +#### Distributing pro-rata + +Rewards funded using the pro-rata strategy should be distributed pro-rata by each entities reward metric scaled by any active multipliers that party has, i.e. + +Let: +- $d_{i}$ be the payout factor for entity $i$ +- $r_{i}$ be the reward metric value for entity $i$ +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ +- $s_{i}$ be the share of the rewards for entity $i$ + +$$d_{i}=r_{i} M_{i}$$ + +Note if the entity is a team, $M_{i}$ is set to zero as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). + +Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. + +$$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ + +#### Distributing with exponential decay + +Rewards funded using the exponential-decay strategy should be distributed as follows. + +1. Calculate each entities reward metric +2. Order each entity in a descending list by their reward metric value and determine their "rank" in the list +3. Calculate each entities share of the rewards using the below formula. + +Let: +- $d_{i}$ be the payout factor for entity $i$ +- $s_{i}$ be the share of the rewards for entity $i$ +- $k$ be the decay factor specified in the recurring transfer funding the reward +- $R_{i}$ be the rank of entity $i$ +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ + +$$d_{i}=e^{-k R_{i}} M_{i}$$ + +Note if the entity is a team, $M_{i}$ is set to zero as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). + +Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. + +$$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ +### Distributing rewards amongst team members + +If rewards are distributed to a team, rewards must then be distributed between team members. -Then calculate `M := m_1 + m_2 + … + m_n` and transfer `R ✖️ m_i / M` to party `p_i` (for each `p_i`) at the end of the epoch. +Let: +- $d_{i}$ be the payout for team member $i$ +- $s_{i}$ be the share of the rewards for team member $i$ +- $B_{i}$ be the total balance in all of the team members accounts (expressed in quantum) +- $F$ be the network parameter `rewards.teamDistribution.minimumAccountQuantum` +- $C$ be the network parameter `rewards.teamDistribution.maximumAccountQuantum` +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ -If `M=0` (no-one incurred or received fees as specified by the metric type for the given market) then no transfer will have been made to the reward account and therefore there are no rewards to pay out. -The transfer will be retried the next epoch if it is still active. +$$d_{i} = \begin{cases} + 0 &\text{if } B_{i} < F \\ + M_{i}\log(\min(B_{i}+1, C+1)) &\text{if } B_{i} \geq F +\end{cases}$$ -Reward payouts will be calculated using the decimal precision of the reward payout asset. If this allows less precision than the reward metric asset (the market's settlement asset) then the ratios between reward payouts may not match exactly the ratio between the reward metrics for any two parties. All funds will always be paid out. +Calculate each parties share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. +$$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ ## Acceptance criteria ### Funding reward accounts (0056-REWA-001) From 80229e16369123adac3d706f49d824170a3bc8d2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 08:58:19 +0100 Subject: [PATCH 481/649] feat: address vesting feedback --- protocol/0085-RVST-rewards_vesting.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 4d9f6f417..800793a5b 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -6,8 +6,8 @@ The aim of the rewards vesting mechanics is to prevent farming rewards by delayi ## Network Parameters -- `rewards.vesting.baseRate`: the proportion of rewards in a vesting account which are vested each epoch -- `rewards.vesting.minimumTransfer`: the minimum amount (expressed in quantum) which can be vested each epoch +- `rewards.vesting.baseRate`: the proportion of rewards in a vesting account which are vested each epoch, value defaults to `0.1` and must be a float strictly greater than 0. +- `rewards.vesting.minimumTransfer`: the minimum amount (expressed in quantum) which can be vested each epoch, value defaults to 100 and must be an integer greater or equal than `0`. ## Vesting mechanics @@ -24,9 +24,8 @@ Now, let: - $m_{mva}$ be the network parameter `rewards.vesting.minimumTransfer` The quantum amount to be transferred from each "vesting" account to the relevant "vested" account is defined as: -$$ -T = min(B_{vested} * r * a, m) -$$ + +$$T = max(B_{vesting} * r * a, m)$$ When transferring funds from the vesting account to the vested account, a new transfer type should be used, `TRANSFER_TYPE_REWARDS_VESTED`. From 7ae6bc5c4d3556bff12521179b754737705a638e Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 7 Aug 2023 13:53:04 +0100 Subject: [PATCH 482/649] feat: update reward metrics --- protocol/0056-REWA-rewards_overview.md | 63 ++++++++++++++++++++++++-- 1 file changed, 60 insertions(+), 3 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 83976a171..8b95cc5f5 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -52,13 +52,70 @@ If the reward account balance is 0 at the end of the epoch for a given market, a Fee-based reward metrics (the total fees paid/received by each party as defined above) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and are restored after a checkpoint restart to ensure rewards are not lost. -### Open interest metrics +### Open interest metric +The open interest metric, ($m_{oi}$, measures each parties time-weighted average open interest over a number of epochs. -### Pnl metrics +At the start of each epoch, the network must reset each parties time weighted average open interest for the epoch ($\bar{OI}$) to `0`. Whenever a parties position changes during an epoch, **and** at the end of the epoch, this value should be updated as follows. +Let: + +- $\bar{OI}$ be the parties time weighted average open interest in the epoch so far +- $OI_{n}$ be the parties open interest before their open interest changed +- $t_{n}$ be the time the party held the previous position in seconds +- $t$ be the amount of time elapsed in the current epoch so far + + +$$\bar{OI} = \bar{OI} \cdot \left(1 - \frac{t_{n}}{t}\right) + \frac{OI_{n} \cdot t_{n}}{t}$$ + +At the end of the epoch, the network must store the parties time weighted average open interest and then calculate their open interest reward metric as follows. + +Let: + +- $m_{oi}$ be the parties open interest reward metric +- $\bar{OI_{i}}$ be the parties time weighted average open interest in the ith epoch +- $N$ be the network parameter `rewards.metrics.openInterestWindow` + +$$m_{oi} = \frac{\sum_{i}^{n}\bar{OI_{i}}}{N}$$ + +### Relative return metric + +The relative return metric, $m_{rr}$, measures each parties average relative return, weighted by their [time-weighted average open-interest](#open-interest-metric), over a number of epochs. + +At the start of the epoch, the network must store the parties current pnl. + +$$p_{0} = p_{realised} + p_{unrealised}$$ + +At the end of each epoch, the network must calculate and store the parties change in pnl: + +Let: +- $\Delta{p}$ be the parties change in pnl +- $p_{realised}$ be the parties realised pnl at the end of the epoch +- $p_{unrealised}$ be the parties unrealised pnl at the end of the epoch + +$$\Delta{p} = p_{realised} + p_{unrealised} - p_{0}$$ + +And calculate their average relative return, weighted by the log of their [time weighted average open interest](#open-interest-metrics), over the last $N$ epochs as follows. + +Let: +- $m_{rr}$ be the parties relative return reward metric +- $\bar{OI_{i}}$ be the parties time weighted average open interest in the ith epoch +- $\Delta{p}$ be the parties change in pnl in the ith epoch +- $N$ be the network parameter `rewards.metrics.relativeReturnsWindow` + +$$m_{rr} = \frac{\sum_{i}^{n}{p_{i}\cdot\log(1 + \bar{OI_{i}})}}{N}$$ + +### Returns volatility metric + +The return volatility metric, $m_{rv}$, measures the volatility of a parties returns across a number of epochs. + +At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the network parameter `rewards.metrics.returnsVolatilityWindow`), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the standard deviation of the set of each parties returns weighted by the log of their [time weighted average open interest](#open-interest-metrics) over the last $N$ epochs. + +Given the set: + +$$R = \{r_i \cdot \log(1 +\bar{OI_{i}}) \mid i = 1, 2, \ldots, N\}$$ -### Volatility metrics +The reward metric $m_{rv}$ is the standard deviation of the set $R$. ### Market creation reward metrics From 6f75ebce0d55149658baf1955130d1dce01790ba Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 8 Aug 2023 10:22:07 +0100 Subject: [PATCH 483/649] feat: add validator power metric --- protocol/0056-REWA-rewards_overview.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 8b95cc5f5..d26ac4c77 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -117,6 +117,18 @@ $$R = \{r_i \cdot \log(1 +\bar{OI_{i}}) \mid i = 1, 2, \ldots, N\}$$ The reward metric $m_{rv}$ is the standard deviation of the set $R$. +### Validator power metric + +The validator power metric, $m_{vp}$, measures the voting power of validators. + +At the end of each epoch, for each party who is a validator set their reward metric as follows. + +$$m_{vp} = validatorScore$$ + +Note the `validatorScore` is the score **after** any [penalties](./0061-REWP-pos_rewards.md#for-each-validator-we-then-do) have been applied. +If a party is not a validator, their reward metric is simply: + +$$m_{vp} = 0$$ ### Market creation reward metrics There will be a single market creation reward metric and reward type. @@ -146,6 +158,8 @@ This flag is used to prevent any given funder from funding a creation reward in Market creation reward metrics (both each market's `cumulative volume` and the payout record flags to identify [funder, market scope, reward asset] combinations that have already been rewarded) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and will be restored after a checkpoint restart. +Note this reward metric **is not** available for team rewards. + ## Team reward metrics All metrics (except [market creation](#market-creation-reward-metrics)) can be used to define the distribution of both individual rewards and team rewards. From 05a7c962ad6e2d39b297a43c270ed1309cef95bc Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 8 Aug 2023 10:23:31 +0100 Subject: [PATCH 484/649] feat: add new entity scoping --- protocol/0057-TRAN-transfers.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 49c9e0db2..b92eeb954 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -87,6 +87,20 @@ To be able to dispatch rewards to reward pools of multiple markets pro rata to t - `reward metric asset` — (the settlement asset of all markets that will be in scope for the transfer) - `market scope` — a subset of markets in which parties are eligible to be rewarded from this transfer. - If the market scope is not defined / an empty list, it is taken as all the markets that settle in the reward metric asset. + +A party can further control their recurring transfer funding the reward pool by defining the entities which are within scope. Entities within scope can be either individual parties or [teams](./0083-RFPR-on_chain_referral_program.md#glossary). When scoping individuals, a subset of keys can be detailed, and when scoping teams a specific set of team ids can be detailed. + +To support entity scoping, the transaction include the following fields: + +- `entity scope` - mandatory enum which defines the entities within scope. + - `ENTITY_SCOPE_INDIVIDUALS` - the rewards must be distributed directly amongst eligible parties + - `ENTITY_SCOPE_TEAMS` - the rewards must be distributed amongst directly eligible teams (and then amongst team members) +- `individual scope` - optional enum if the entity scope is `ENTITY_SCOPE_INDIVIDUALS` which defines the subset of individuals which are eligible to be rewarded. + - `INDIVIDUAL_SCOPE_ALL` - all parties on the network are within the scope of this reward + - `INDIVIDUAL_SCOPE_IN_TEAM` - all parties which are part of a team are within the scope of this reward + - `INDIVIDUAL_SCOPE_NOT_IN_TEAM` - all parties which are not part of a team are within the scope of this reward +- `team scope` - optional list if the reward type is `ENTITY_SCOPE_TEAMS`, field allows the funder to define a list of team ids which are eligible to be rewarded from this transfer + - At the end of the epoch when the transfer is about to be distributed, it first calculates the contribution of each market to the sum total reward metric for all markets in the `market scope` and then distributes the transfer amount to the corresponding accounts of the markets pro-rata by their contribution to the total. Where the reward metric type is "market creation rewards", it is important that no market creator will receive more than one market creation reward paid in the same asset from the same source account (reward funder). From 1ff1e3f13799cba345d10cc65be2cafd44eef6f6 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 8 Aug 2023 10:41:04 +0100 Subject: [PATCH 485/649] refactor: linting and spellcheck fixes --- protocol/0056-REWA-rewards_overview.md | 17 ++++++++++---- protocol/0057-TRAN-transfers.md | 10 ++++---- protocol/0085-RVST-rewards_vesting.md | 8 +++---- protocol/0086-ASPR-activity_streak_program.md | 23 ++++++++++--------- 4 files changed, 34 insertions(+), 24 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index d26ac4c77..941919849 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -9,6 +9,7 @@ The additional rewards described here can be funded arbitrarily by users of the Note that transfers via governance, including to fund rewards, is a post-Oregon Trail feature. Note that validator rewards (and the reward account for those) is covered in [validator rewards](./0061-REWP-pos_rewards.md) and is separate from the trading reward framework described here. + ## New network parameter for market creation threshold The parameter `rewards.marketCreationQuantumMultiple` will be used together with [quantum](0040-ASSF-asset_framework.md) to asses market size when deciding whether a market qualifies for the payment of market creation rewards. @@ -54,7 +55,7 @@ Fee-based reward metrics (the total fees paid/received by each party as defined ### Open interest metric -The open interest metric, ($m_{oi}$, measures each parties time-weighted average open interest over a number of epochs. +The open interest metric, $m_{oi}$, measures each parties time-weighted average open interest over a number of epochs. At the start of each epoch, the network must reset each parties time weighted average open interest for the epoch ($\bar{OI}$) to `0`. Whenever a parties position changes during an epoch, **and** at the end of the epoch, this value should be updated as follows. @@ -89,27 +90,29 @@ $$p_{0} = p_{realised} + p_{unrealised}$$ At the end of each epoch, the network must calculate and store the parties change in pnl: Let: + - $\Delta{p}$ be the parties change in pnl - $p_{realised}$ be the parties realised pnl at the end of the epoch - $p_{unrealised}$ be the parties unrealised pnl at the end of the epoch $$\Delta{p} = p_{realised} + p_{unrealised} - p_{0}$$ -And calculate their average relative return, weighted by the log of their [time weighted average open interest](#open-interest-metrics), over the last $N$ epochs as follows. +And calculate their average relative return, weighted by the log of their [time weighted average open interest](#open-interest-metric), over the last $N$ epochs as follows. Let: + - $m_{rr}$ be the parties relative return reward metric - $\bar{OI_{i}}$ be the parties time weighted average open interest in the ith epoch - $\Delta{p}$ be the parties change in pnl in the ith epoch - $N$ be the network parameter `rewards.metrics.relativeReturnsWindow` -$$m_{rr} = \frac{\sum_{i}^{n}{p_{i}\cdot\log(1 + \bar{OI_{i}})}}{N}$$ +$$m_{rr} = \frac{\sum_{i}^{n}{$\Delta{p}$\cdot\log(1 + \bar{OI_{i}})}}{N}$$ ### Returns volatility metric The return volatility metric, $m_{rv}$, measures the volatility of a parties returns across a number of epochs. -At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the network parameter `rewards.metrics.returnsVolatilityWindow`), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the standard deviation of the set of each parties returns weighted by the log of their [time weighted average open interest](#open-interest-metrics) over the last $N$ epochs. +At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the network parameter `rewards.metrics.returnsVolatilityWindow`), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the standard deviation of the set of each parties returns weighted by the log of their [time weighted average open interest](#open-interest-metric) over the last $N$ epochs. Given the set: @@ -129,6 +132,7 @@ Note the `validatorScore` is the score **after** any [penalties](./0061-REWP-pos If a party is not a validator, their reward metric is simply: $$m_{vp} = 0$$ + ### Market creation reward metrics There will be a single market creation reward metric and reward type. @@ -203,6 +207,7 @@ The protocol currently supports the following distribution strategies: Rewards funded using the pro-rata strategy should be distributed pro-rata by each entities reward metric scaled by any active multipliers that party has, i.e. Let: + - $d_{i}$ be the payout factor for entity $i$ - $r_{i}$ be the reward metric value for entity $i$ - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ @@ -225,6 +230,7 @@ Rewards funded using the exponential-decay strategy should be distributed as fol 3. Calculate each entities share of the rewards using the below formula. Let: + - $d_{i}$ be the payout factor for entity $i$ - $s_{i}$ be the share of the rewards for entity $i$ - $k$ be the decay factor specified in the recurring transfer funding the reward @@ -238,11 +244,13 @@ Note if the entity is a team, $M_{i}$ is set to zero as reward payout multiplier Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. $$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ + ### Distributing rewards amongst team members If rewards are distributed to a team, rewards must then be distributed between team members. Let: + - $d_{i}$ be the payout for team member $i$ - $s_{i}$ be the share of the rewards for team member $i$ - $B_{i}$ be the total balance in all of the team members accounts (expressed in quantum) @@ -258,6 +266,7 @@ $$d_{i} = \begin{cases} Calculate each parties share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. $$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ + ## Acceptance criteria ### Funding reward accounts (0056-REWA-001) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index b92eeb954..4258374b0 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -93,12 +93,12 @@ A party can further control their recurring transfer funding the reward pool by To support entity scoping, the transaction include the following fields: - `entity scope` - mandatory enum which defines the entities within scope. - - `ENTITY_SCOPE_INDIVIDUALS` - the rewards must be distributed directly amongst eligible parties - - `ENTITY_SCOPE_TEAMS` - the rewards must be distributed amongst directly eligible teams (and then amongst team members) + - `ENTITY_SCOPE_INDIVIDUALS` - the rewards must be distributed directly amongst eligible parties + - `ENTITY_SCOPE_TEAMS` - the rewards must be distributed amongst directly eligible teams (and then amongst team members) - `individual scope` - optional enum if the entity scope is `ENTITY_SCOPE_INDIVIDUALS` which defines the subset of individuals which are eligible to be rewarded. - - `INDIVIDUAL_SCOPE_ALL` - all parties on the network are within the scope of this reward - - `INDIVIDUAL_SCOPE_IN_TEAM` - all parties which are part of a team are within the scope of this reward - - `INDIVIDUAL_SCOPE_NOT_IN_TEAM` - all parties which are not part of a team are within the scope of this reward + - `INDIVIDUAL_SCOPE_ALL` - all parties on the network are within the scope of this reward + - `INDIVIDUAL_SCOPE_IN_TEAM` - all parties which are part of a team are within the scope of this reward + - `INDIVIDUAL_SCOPE_NOT_IN_TEAM` - all parties which are not part of a team are within the scope of this reward - `team scope` - optional list if the reward type is `ENTITY_SCOPE_TEAMS`, field allows the funder to define a list of team ids which are eligible to be rewarded from this transfer - At the end of the epoch when the transfer is about to be distributed, it first calculates the contribution of each market to the sum total reward metric for all markets in the `market scope` and then distributes the transfer amount to the corresponding accounts of the markets pro-rata by their contribution to the total. diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 800793a5b..293715ed3 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -11,7 +11,7 @@ The aim of the rewards vesting mechanics is to prevent farming rewards by delayi ## Vesting mechanics -As detailed in [distributing rewards](), each party has their rewards paid into vesting rewards accounts (one for each asset). +As detailed in [distributing rewards](./0056-REWA-rewards_overview.md#distributing-rewards-amongst-entities), each party has their rewards paid into vesting rewards accounts (one for each asset). At the end of each epoch, a proportion of the rewards accumulated in each "vesting" account should be released and transferred to the respective "vested" account. The percentage released can be scaled by the account owner increasing their [activity streak](./0086-ASPR-activity_streak_program.md) and a minimum transfer amount will be applied to ensure the account is eventually emptied. The proportion released and minimum applied are controlled for parameters for the asset. @@ -19,9 +19,9 @@ Now, let: - $T$ be the amount to be "vested" (transferred from the vesting account to the vested account) - $B_{vested}$ be the total quantum amount in the vesting account -- $r_{bvr}$ be the network parameter `rewards.vesting.baseRate` +- $r$ be the network parameter `rewards.vesting.baseRate` - $a$ be the account owners current [`activity_streak_vesting_multiplier`](./0086-ASPR-activity_streak_program.md#setting-activity-benefits) -- $m_{mva}$ be the network parameter `rewards.vesting.minimumTransfer` +- $m$ be the network parameter `rewards.vesting.minimumTransfer` The quantum amount to be transferred from each "vesting" account to the relevant "vested" account is defined as: @@ -46,4 +46,4 @@ Must expose the following: ## Acceptance Criteria -TBD \ No newline at end of file +WIP diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index ddaa370dd..da18df0bb 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -20,10 +20,11 @@ Parties access higher tiers and greater benefits by maintaining an activity stre The network parameter [`rewards.activityStreak.benefitTiers`](#network-parameters) can be updated via a `UpdateNetworkParameter` governance proposal. Each tier in the ordered list must have the following fields: - `minimum_activity_streak`: int greater or equal to `0` defining the minimum activity streak a party must have to access this tier -- `reward_multiplier`: float greater or equal to `1` defining the factor to scale a parties [reward shares]() by -- `vesting_multiplier`: float greater or equal to `1` defining the factor to scale a parties [base vesting rate]() by +- `reward_multiplier`: float greater or equal to `1` defining the factor to scale a parties [reward shares](./0056-REWA-rewards_overview.md#distributing-rewards-amongst-entities) by +- `vesting_multiplier`: float greater or equal to `1` defining the factor to scale a parties [base vesting rate](./0085-RVST-rewards_vesting.md#vesting-mechanics) by *Example:* + ```proto message UpdateNetworkParameter{ changes: NetworkParameter{ @@ -49,13 +50,13 @@ For the feature, the network must track each parties "activity streak". At the e - if a party was "active" in the epoch - - increment their `activity_streak` by `1` - - reset their `inactivity_streak` to `0`. + - increment their `activity_streak` by `1` + - reset their `inactivity_streak` to `0`. - if a party was "inactive" in the epoch - - increment their `inactivity_streak` streak by `1` - - if their `inactivity_streak` is greater than or equal to the `rewards.activityStreak.streakLength`, reset their `activity_streak` to `0`. + - increment their `inactivity_streak` streak by `1` + - if their `inactivity_streak` is greater than or equal to the `rewards.activityStreak.streakLength`, reset their `activity_streak` to `0`. A party is defined as active if they fulfil **either** of the following criteria: @@ -91,11 +92,11 @@ Then: #### Applying the activity reward multiplier -The `activity_streak_reward_multiplier` scales the parties [reward share]() for all rewards they are eligible for. +The `activity_streak_reward_multiplier` scales the parties [reward share](./0056-REWA-rewards_overview.md#distributing-rewards-amongs-entities) for all rewards they are eligible for. #### Applying the activity vesting multiplier -The `activity_streak_vesting_multiplier` scales the parties [vesting rate]() of all funds locked in the parties vesting accounts. +The `activity_streak_vesting_multiplier` scales the parties [vesting rate](./0085-RVST-rewards_vesting.md#vesting-mechanics) of all funds locked in the parties vesting accounts. ## APIs @@ -114,12 +115,12 @@ Must expose the following: ### Governance proposals -TBD +WIP ### Setting activity / inactivity streak -TBD +WIP ### Setting activity benefits -TBD \ No newline at end of file +WIP From 11dd0ba58385fc4a8fdb69a0b0880537c2934959 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 8 Aug 2023 19:23:49 +0100 Subject: [PATCH 486/649] refactor: address network param feedback --- protocol/0086-ASPR-activity_streak_program.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index da18df0bb..1a7fdbf22 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -11,7 +11,7 @@ Parties access higher tiers and greater benefits by maintaining an activity stre - `rewards.activityStreak.benefitTiers`: is an ordered list of dictionaries defining the requirements and benefits for each tier. - `rewards.activityStreak.inactivityLimit`: the maximum number of epochs a trader can be inactive before loosing their streak. -- `rewards.activityStreak.minQuantumOpenVolume`: the minimum open notional volume (expressed in quantum) for a trader to be considered active in an epoch +- `rewards.activityStreak.minQuantumOpenNotionalVolume`: the minimum open notional volume (expressed in quantum) for a trader to be considered active in an epoch - `rewards.activityStreak.minQuantumTradeVolume`: the minimum trade volume (expressed in quantum) for a trader to be considered active in an epoch @@ -56,11 +56,11 @@ For the feature, the network must track each parties "activity streak". At the e - if a party was "inactive" in the epoch - increment their `inactivity_streak` streak by `1` - - if their `inactivity_streak` is greater than or equal to the `rewards.activityStreak.streakLength`, reset their `activity_streak` to `0`. + - if their `inactivity_streak` is greater than or equal to the `rewards.activityStreak.inactivityLimit`, reset their `activity_streak` to `0`. A party is defined as active if they fulfil **either** of the following criteria: -- their open interest was strictly greater than `rewards.activityStreak.minQuantumOpenVolume` at any point in the epoch +- their open interest was strictly greater than `rewards.activityStreak.minQuantumOpenNotionalVolume` at any point in the epoch - their total trade volume was strictly greater than `rewards.activityStreak.minQuantumTradeVolume` at the end of the epoch ### Setting activity benefits From b75b4f1ff223ef7032465dcbf7f886736f846d3a Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 8 Aug 2023 19:26:31 +0100 Subject: [PATCH 487/649] refactor: fix formatting --- protocol/0083-RFPR-on_chain_referral_program.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 8282e06a5..68e67385e 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -141,6 +141,7 @@ message CreateReferralSet{ team_url: "https://discord.com/channels/vegarocks", avatar_url: "https://vega-rocks/logo-360x360.jpg", closed: False, + } } ``` From 37554b5a30deb411eb3c1a25900be113accf09ee Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 8 Aug 2023 19:29:06 +0100 Subject: [PATCH 488/649] feat: update the validator ranking metric --- protocol/0056-REWA-rewards_overview.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 941919849..94173633e 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -120,18 +120,17 @@ $$R = \{r_i \cdot \log(1 +\bar{OI_{i}}) \mid i = 1, 2, \ldots, N\}$$ The reward metric $m_{rv}$ is the standard deviation of the set $R$. -### Validator power metric +### Validator ranking metric -The validator power metric, $m_{vp}$, measures the voting power of validators. +The validator ranking metric, $m_{vr}$, measures the ranking score of consensus and standby validators. -At the end of each epoch, for each party who is a validator set their reward metric as follows. +At the end of each epoch, for each party who **is** a consensus or standby validator set their reward metric as follows. -$$m_{vp} = validatorScore$$ +$$m_{vr} = rankingScore$$ -Note the `validatorScore` is the score **after** any [penalties](./0061-REWP-pos_rewards.md#for-each-validator-we-then-do) have been applied. -If a party is not a validator, their reward metric is simply: +If a party **is not** a consensus or standby validator, their reward metric is simply: -$$m_{vp} = 0$$ +$$m_{vr} = 0$$ ### Market creation reward metrics From 771f14cee53b08473c8ee775c64ef9341ab46458 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 10 Aug 2023 09:13:58 +0100 Subject: [PATCH 489/649] fix: correct variable name --- protocol/0056-REWA-rewards_overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 94173633e..97448f6b2 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -116,7 +116,7 @@ At the end of an epoch, if a party has had net returns less than or equal to `0` Given the set: -$$R = \{r_i \cdot \log(1 +\bar{OI_{i}}) \mid i = 1, 2, \ldots, N\}$$ +$$R = \{\Delta{p} \cdot \log(1 +\bar{OI_{i}}) \mid i = 1, 2, \ldots, N\}$$ The reward metric $m_{rv}$ is the standard deviation of the set $R$. From cefc4990cfcdac6bae276cec1635282708a99bf0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 14 Aug 2023 13:18:40 +0100 Subject: [PATCH 490/649] feat: add vested multiplier --- protocol/0056-REWA-rewards_overview.md | 6 +++--- protocol/0085-RVST-rewards_vesting.md | 30 ++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 97448f6b2..51de18c56 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -209,7 +209,7 @@ Let: - $d_{i}$ be the payout factor for entity $i$ - $r_{i}$ be the reward metric value for entity $i$ -- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [vested rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-vested-bonus-multiplier)). - $s_{i}$ be the share of the rewards for entity $i$ $$d_{i}=r_{i} M_{i}$$ @@ -234,7 +234,7 @@ Let: - $s_{i}$ be the share of the rewards for entity $i$ - $k$ be the decay factor specified in the recurring transfer funding the reward - $R_{i}$ be the rank of entity $i$ -- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [vested rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-vested-bonus-multiplier)). $$d_{i}=e^{-k R_{i}} M_{i}$$ @@ -255,7 +255,7 @@ Let: - $B_{i}$ be the total balance in all of the team members accounts (expressed in quantum) - $F$ be the network parameter `rewards.teamDistribution.minimumAccountQuantum` - $C$ be the network parameter `rewards.teamDistribution.maximumAccountQuantum` -- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [vested rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-vested-bonus-multiplier)). $$d_{i} = \begin{cases} 0 &\text{if } B_{i} < F \\ diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 293715ed3..12d77b3e9 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -8,6 +8,7 @@ The aim of the rewards vesting mechanics is to prevent farming rewards by delayi - `rewards.vesting.baseRate`: the proportion of rewards in a vesting account which are vested each epoch, value defaults to `0.1` and must be a float strictly greater than 0. - `rewards.vesting.minimumTransfer`: the minimum amount (expressed in quantum) which can be vested each epoch, value defaults to 100 and must be an integer greater or equal than `0`. +- `rewards.vesting.rewardPayoutMultipliers`: is an ordered list of dictionaries defining the requirements and multipliers for each tier. ## Vesting mechanics @@ -29,6 +30,35 @@ $$T = max(B_{vesting} * r * a, m)$$ When transferring funds from the vesting account to the vested account, a new transfer type should be used, `TRANSFER_TYPE_REWARDS_VESTED`. +## Vested bonus + +Once vested rewards are transferred to the vested account, the party will be able to transfer funds to their general account using a normal transfer. + +Alternatively, they can leave their rewards in the vested account to receive a multiplier on their reward payout share. The size of this multiplier is dependent on the balance (expressed in quantum) in the vested account before rewards are distributed. + +Note, a party will be unable to transfer funds in to the vested account. + +### Determining the vested bonus multiplier + +Before [distributing rewards](./0056-REWA-rewards_overview.md#distributing-rewards-amongst-entities), each parties `reward_distribution_vested_multiplier` should be set according to the highest tier they qualify for. + +```pseudo +Given: + rewards.vesting.benefitTiers: [ + [ + {"minimum_quantum_balance": 10000, "reward_multiplier": 1.0}, + {"minimum_quantum_balance": 100000, "reward_multiplier": 5.0}, + {"minimum_quantum_balance": 1000000, "reward_multiplier": 10.0}, + ], + ] + +And: + vested_quantum_balance=145231 + +Then: + reward_distribution_vested_multiplier=5.0 +``` + ## APIs ### Accounts API From ff72db22a6b266c984d5dc279819540776fa21aa Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 14 Aug 2023 13:48:10 +0100 Subject: [PATCH 491/649] feat: change total rewards calc as per feedback --- protocol/0056-REWA-rewards_overview.md | 6 +++--- protocol/0085-RVST-rewards_vesting.md | 16 +++++++++------- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 51de18c56..274b75b5f 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -209,7 +209,7 @@ Let: - $d_{i}$ be the payout factor for entity $i$ - $r_{i}$ be the reward metric value for entity $i$ -- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [vested rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-vested-bonus-multiplier)). +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). - $s_{i}$ be the share of the rewards for entity $i$ $$d_{i}=r_{i} M_{i}$$ @@ -234,7 +234,7 @@ Let: - $s_{i}$ be the share of the rewards for entity $i$ - $k$ be the decay factor specified in the recurring transfer funding the reward - $R_{i}$ be the rank of entity $i$ -- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [vested rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-vested-bonus-multiplier)). +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). $$d_{i}=e^{-k R_{i}} M_{i}$$ @@ -255,7 +255,7 @@ Let: - $B_{i}$ be the total balance in all of the team members accounts (expressed in quantum) - $F$ be the network parameter `rewards.teamDistribution.minimumAccountQuantum` - $C$ be the network parameter `rewards.teamDistribution.maximumAccountQuantum` -- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [vested rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-vested-bonus-multiplier)). +- $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). $$d_{i} = \begin{cases} 0 &\text{if } B_{i} < F \\ diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 12d77b3e9..f91ab894b 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -8,7 +8,7 @@ The aim of the rewards vesting mechanics is to prevent farming rewards by delayi - `rewards.vesting.baseRate`: the proportion of rewards in a vesting account which are vested each epoch, value defaults to `0.1` and must be a float strictly greater than 0. - `rewards.vesting.minimumTransfer`: the minimum amount (expressed in quantum) which can be vested each epoch, value defaults to 100 and must be an integer greater or equal than `0`. -- `rewards.vesting.rewardPayoutMultipliers`: is an ordered list of dictionaries defining the requirements and multipliers for each tier. +- `rewards.vesting.rewardPayoutTiers`: is an ordered list of dictionaries defining the requirements and multipliers for each tier. ## Vesting mechanics @@ -30,17 +30,17 @@ $$T = max(B_{vesting} * r * a, m)$$ When transferring funds from the vesting account to the vested account, a new transfer type should be used, `TRANSFER_TYPE_REWARDS_VESTED`. -## Vested bonus +## Rewards bonus multiplier Once vested rewards are transferred to the vested account, the party will be able to transfer funds to their general account using a normal transfer. -Alternatively, they can leave their rewards in the vested account to receive a multiplier on their reward payout share. The size of this multiplier is dependent on the balance (expressed in quantum) in the vested account before rewards are distributed. +Alternatively, they can leave their rewards in the vested account to increase their total rewards balance and receive a multiplier on their reward payout share. The size of this multiplier is dependent on their total rewards balance, i.e. the sum of the parties locked rewards, vesting rewards and vested rewards. Note, funds removed from the vested account are not included in this total. Note, a party will be unable to transfer funds in to the vested account. -### Determining the vested bonus multiplier +### Determining the rewards bonus multiplier -Before [distributing rewards](./0056-REWA-rewards_overview.md#distributing-rewards-amongst-entities), each parties `reward_distribution_vested_multiplier` should be set according to the highest tier they qualify for. +Before [distributing rewards](./0056-REWA-rewards_overview.md#distributing-rewards-amongst-entities), each parties `reward_distribution_bonus_multiplier` should be set according to the highest tier they qualify for. ```pseudo Given: @@ -53,10 +53,12 @@ Given: ] And: - vested_quantum_balance=145231 + locked_quantum_amount=2 + vesting_quantum_amount=999 + vested_quantum_amount=99000 Then: - reward_distribution_vested_multiplier=5.0 + reward_distribution_bonus_multiplier=5.0 ``` ## APIs From 29c50f8cbdaaf26c2f883e9b6a44d4df55f6e484 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 14 Aug 2023 18:51:01 +0100 Subject: [PATCH 492/649] feat: remove logarithmic functions --- protocol/0056-REWA-rewards_overview.md | 65 +++++++++++++------------- protocol/0057-TRAN-transfers.md | 7 +++ 2 files changed, 40 insertions(+), 32 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 274b75b5f..d3f3d7857 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -30,15 +30,17 @@ At the end of the epoch: ## Individual reward metrics -Individual reward metrics are scoped by [`reward type`, `market`, `party`] (this triplet can be thought of as a primary key for fee-based reward metrics). +Individual reward metrics are scoped by [`recurring transfer`, `market`, `party`] (this triplet can be thought of as a primary key for fee-based reward metrics). -Therefore a party may be in scope for the same reward type multiple times but no more than once per market per epoch. -Metrics will be calculated at the end of every epoch, for every eligible party, in each market for each reward type. +Therefore a party may be in scope for the same reward type multiple times per epoch. +Metrics will be calculated at the end of every epoch, for every eligible party, in each market, for each recurring transfer. Metrics only need to be calculated where the [market, reward type] reward account has a non-zero balance of at least one asset. Reward metrics will be calculated once for each party/market combination in the reward metric asset which is the [settlement asset](0070-MKTD-market-decimal-places.md) of the market. This is the original precision for the metric source data. +For each reward metric an individual must meet the [staking requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) **AND** [notional time-weighted average position requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts)) set in the recurring transfer. If they do not then their reward metric is set to `0`. + ### Fee-based reward metrics There will be three reward metrics calculated based on fees. @@ -81,42 +83,38 @@ $$m_{oi} = \frac{\sum_{i}^{n}\bar{OI_{i}}}{N}$$ ### Relative return metric -The relative return metric, $m_{rr}$, measures each parties average relative return, weighted by their [time-weighted average open-interest](#open-interest-metric), over a number of epochs. - -At the start of the epoch, the network must store the parties current pnl. - -$$p_{0} = p_{realised} + p_{unrealised}$$ +The relative return metric, $m_{rr}$, measures each parties average relative return, weighted by their [time-weighted average position](#average-position-metric), over a number of epochs. -At the end of each epoch, the network must calculate and store the parties change in pnl: +At the end of each epoch, the network must calculate and store the parties relative returns as follows. Let: -- $\Delta{p}$ be the parties change in pnl -- $p_{realised}$ be the parties realised pnl at the end of the epoch -- $p_{unrealised}$ be the parties unrealised pnl at the end of the epoch +- $r_i$ be the parties relative returns in the epoch +- $m2m_{wins}$ be the sum of all mark-to-market win transfers in the epoch +- $m2m_{losses}$ be the sum of all mark-to-market loss transfers in the epoch +- $TWAP$ be the parties time-weighted average position in the epoch. -$$\Delta{p} = p_{realised} + p_{unrealised} - p_{0}$$ +$$r = \frac{m2m_{wins} + m2m_{losses}}{TWAP}$$ -And calculate their average relative return, weighted by the log of their [time weighted average open interest](#open-interest-metric), over the last $N$ epochs as follows. +And calculate their average relative returns over the last $N$ epochs as follows. Let: - $m_{rr}$ be the parties relative return reward metric -- $\bar{OI_{i}}$ be the parties time weighted average open interest in the ith epoch -- $\Delta{p}$ be the parties change in pnl in the ith epoch -- $N$ be the network parameter `rewards.metrics.relativeReturnsWindow` +- $r_i$ be the parties change in pnl in the i th epoch +- $N$ be the window length specified in the recurring transfer. -$$m_{rr} = \frac{\sum_{i}^{n}{$\Delta{p}$\cdot\log(1 + \bar{OI_{i}})}}{N}$$ +$$m_{rr} = \max(\frac{\sum_{i}^{n}{r_{i}}}{N}, 0)$$ ### Returns volatility metric The return volatility metric, $m_{rv}$, measures the volatility of a parties returns across a number of epochs. -At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the network parameter `rewards.metrics.returnsVolatilityWindow`), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the standard deviation of the set of each parties returns weighted by the log of their [time weighted average open interest](#open-interest-metric) over the last $N$ epochs. +At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the window length specified in the recurring transfer), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the standard deviation of the set of each parties returns over the last $N$ epochs. Given the set: -$$R = \{\Delta{p} \cdot \log(1 +\bar{OI_{i}}) \mid i = 1, 2, \ldots, N\}$$ +$$R = \{r_i \mid i = 1, 2, \ldots, N\}$$ The reward metric $m_{rv}$ is the standard deviation of the set $R$. @@ -214,7 +212,7 @@ Let: $$d_{i}=r_{i} M_{i}$$ -Note if the entity is a team, $M_{i}$ is set to zero as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). +Note if the entity is a team, $M_{i}$ is set to `1` as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. @@ -226,19 +224,24 @@ Rewards funded using the exponential-decay strategy should be distributed as fol 1. Calculate each entities reward metric 2. Order each entity in a descending list by their reward metric value and determine their "rank" in the list -3. Calculate each entities share of the rewards using the below formula. +3. Normalize the rank of each party within a range of 0 to 1, using the highest rank as the upper limit for normalization. +4. Calculate each entities share of the rewards using the below formula. Let: - $d_{i}$ be the payout factor for entity $i$ - $s_{i}$ be the share of the rewards for entity $i$ -- $k$ be the decay factor specified in the recurring transfer funding the reward -- $R_{i}$ be the rank of entity $i$ +- $k$ be the decay factor specified in the recurring transfer funding the reward. +- $R_{i}$ be the normalised rank of entity $i$ - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). -$$d_{i}=e^{-k R_{i}} M_{i}$$ +$$d_{i}=M_{i} e^{-k R_{i}}$$ + +Note if the entity is a team, $M_{i}$ is set to 1 as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). + +To avoid exponential formulas in the core implementation, the above exponential equation can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. -Note if the entity is a team, $M_{i}$ is set to zero as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). +$$d_{i} = M_{i} e^{-k R_i} \approx M_{i} \min(1- \sum_{j=0}^{7} \frac{(-k R_i)^j}{j!}, 0)$$ Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. @@ -246,20 +249,18 @@ $$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ ### Distributing rewards amongst team members -If rewards are distributed to a team, rewards must then be distributed between team members. +If rewards are distributed to a team, rewards must then be distributed between team members who had a reward metric, $m$, greater than `0` based on their payout multipliers. Let: - $d_{i}$ be the payout for team member $i$ - $s_{i}$ be the share of the rewards for team member $i$ -- $B_{i}$ be the total balance in all of the team members accounts (expressed in quantum) -- $F$ be the network parameter `rewards.teamDistribution.minimumAccountQuantum` -- $C$ be the network parameter `rewards.teamDistribution.maximumAccountQuantum` +- $m$ be the reward metric of the team member - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). $$d_{i} = \begin{cases} - 0 &\text{if } B_{i} < F \\ - M_{i}\log(\min(B_{i}+1, C+1)) &\text{if } B_{i} \geq F + 0 &\text{if } m = 0 \\ + M_{i} &\text{if } m > 0 \end{cases}$$ Calculate each parties share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 4258374b0..7db780a4b 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -100,6 +100,13 @@ To support entity scoping, the transaction include the following fields: - `INDIVIDUAL_SCOPE_IN_TEAM` - all parties which are part of a team are within the scope of this reward - `INDIVIDUAL_SCOPE_NOT_IN_TEAM` - all parties which are not part of a team are within the scope of this reward - `team scope` - optional list if the reward type is `ENTITY_SCOPE_TEAMS`, field allows the funder to define a list of team ids which are eligible to be rewarded from this transfer +- `staking_requirement` - the required minimum number of tokens staked for a party to be considered eligible. Defaults to `0`. +- `notional_time_weighted_average_position_requirement` - the required minimum notional time-weighted averaged position required for a party to be considered eligible. Defaults to `0`. + +A party should be able to configure the distribution of rewards by specifying a number of epochs to evaluate the reward metric over and specify a number of epochs to delay vesting by. The transaction should now include the following fields. + +- `window_length` - the number of epochs over which to evaluate the reward metric. +- `lock_period` - the number of epochs after distribution to delay [vesting of rewards](./0085-RVST-rewards_vesting.md#vesting-mechanics) by. - At the end of the epoch when the transfer is about to be distributed, it first calculates the contribution of each market to the sum total reward metric for all markets in the `market scope` and then distributes the transfer amount to the corresponding accounts of the markets pro-rata by their contribution to the total. From 9fac4b2badfa328c9488bbc0aff8e2011c613204 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 14 Aug 2023 18:52:38 +0100 Subject: [PATCH 493/649] refactor: rename open-interest metric to position metric --- protocol/0056-REWA-rewards_overview.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index d3f3d7857..47b05c58d 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -55,31 +55,31 @@ If the reward account balance is 0 at the end of the epoch for a given market, a Fee-based reward metrics (the total fees paid/received by each party as defined above) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and are restored after a checkpoint restart to ensure rewards are not lost. -### Open interest metric +### Average position metric -The open interest metric, $m_{oi}$, measures each parties time-weighted average open interest over a number of epochs. +The average position metric, $m_{ap}$, measures each parties time-weighted average position over a number of epochs. -At the start of each epoch, the network must reset each parties time weighted average open interest for the epoch ($\bar{OI}$) to `0`. Whenever a parties position changes during an epoch, **and** at the end of the epoch, this value should be updated as follows. +At the start of each epoch, the network must reset each parties time weighted average position for the epoch ($\bar{P}$) to `0`. Whenever a parties position changes during an epoch, **and** at the end of the epoch, this value should be updated as follows. Let: -- $\bar{OI}$ be the parties time weighted average open interest in the epoch so far -- $OI_{n}$ be the parties open interest before their open interest changed +- $\bar{P}$ be the parties time weighted average position in the epoch so far +- $P_{n}$ be the parties position before their position changed - $t_{n}$ be the time the party held the previous position in seconds - $t$ be the amount of time elapsed in the current epoch so far -$$\bar{OI} = \bar{OI} \cdot \left(1 - \frac{t_{n}}{t}\right) + \frac{OI_{n} \cdot t_{n}}{t}$$ +$$\bar{P} = \bar{P} \cdot \left(1 - \frac{t_{n}}{t}\right) + \frac{|P_{n}| \cdot t_{n}}{t}$$ -At the end of the epoch, the network must store the parties time weighted average open interest and then calculate their open interest reward metric as follows. +At the end of the epoch, the network must store the parties time weighted average position and then calculate their average position reward metric as follows. Let: -- $m_{oi}$ be the parties open interest reward metric -- $\bar{OI_{i}}$ be the parties time weighted average open interest in the ith epoch -- $N$ be the network parameter `rewards.metrics.openInterestWindow` +- $m_{ap}$ be the parties average position reward metric +- $\bar{P_{i}}$ be the parties time weighted average position in the i th epoch +- $N$ be the window length specified in the recurring transfer. -$$m_{oi} = \frac{\sum_{i}^{n}\bar{OI_{i}}}{N}$$ +$$m_{ap} = \frac{\sum_{i}^{n}\bar{P_{i}}}{N}$$ ### Relative return metric From 3855351817fcfcd623446f345dbc836d621df69f Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 14 Aug 2023 19:00:09 +0100 Subject: [PATCH 494/649] fix: fix linting and spellcheck --- protocol/0056-REWA-rewards_overview.md | 8 ++++---- protocol/0085-RVST-rewards_vesting.md | 2 +- protocol/0086-ASPR-activity_streak_program.md | 6 +++--- wordlist.txt | 3 +++ 4 files changed, 11 insertions(+), 8 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 47b05c58d..09bc93c65 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -120,15 +120,15 @@ The reward metric $m_{rv}$ is the standard deviation of the set $R$. ### Validator ranking metric -The validator ranking metric, $m_{vr}$, measures the ranking score of consensus and standby validators. +The validator ranking metric, $m_v$, measures the ranking score of consensus and standby validators. At the end of each epoch, for each party who **is** a consensus or standby validator set their reward metric as follows. -$$m_{vr} = rankingScore$$ +$$m_v = ranking_score$$ If a party **is not** a consensus or standby validator, their reward metric is simply: -$$m_{vr} = 0$$ +$$m_v = 0$$ ### Market creation reward metrics @@ -224,7 +224,7 @@ Rewards funded using the exponential-decay strategy should be distributed as fol 1. Calculate each entities reward metric 2. Order each entity in a descending list by their reward metric value and determine their "rank" in the list -3. Normalize the rank of each party within a range of 0 to 1, using the highest rank as the upper limit for normalization. +3. Normalise the rank of each party within a range of 0 to 1, using the highest rank as the upper limit for normalisation. 4. Calculate each entities share of the rewards using the below formula. Let: diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index f91ab894b..eb3073b4c 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -78,4 +78,4 @@ Must expose the following: ## Acceptance Criteria -WIP +Too be added diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index 1a7fdbf22..5c7721959 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -115,12 +115,12 @@ Must expose the following: ### Governance proposals -WIP +Too be added ### Setting activity / inactivity streak -WIP +Too be added ### Setting activity benefits -WIP +Too be added diff --git a/wordlist.txt b/wordlist.txt index be1231188..8c5869ec7 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -315,3 +315,6 @@ dApp leaderboards ReferralSet CreateReferralSet +enum +ldots +infty From bbe8e929009775ec8f840ae7998c9867aa2aa097 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 15 Aug 2023 09:29:38 +0100 Subject: [PATCH 495/649] feat: add validation for k --- protocol/0056-REWA-rewards_overview.md | 4 ++-- wordlist.txt | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 09bc93c65..148d8e839 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -231,7 +231,7 @@ Let: - $d_{i}$ be the payout factor for entity $i$ - $s_{i}$ be the share of the rewards for entity $i$ -- $k$ be the decay factor specified in the recurring transfer funding the reward. +- $k$ be the decay factor specified in the recurring transfer funding the reward. This must be a float in the range $0\leq k \leq 2$. - $R_{i}$ be the normalised rank of entity $i$ - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). @@ -241,7 +241,7 @@ Note if the entity is a team, $M_{i}$ is set to 1 as reward payout multipliers a To avoid exponential formulas in the core implementation, the above exponential equation can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. -$$d_{i} = M_{i} e^{-k R_i} \approx M_{i} \min(1- \sum_{j=0}^{7} \frac{(-k R_i)^j}{j!}, 0)$$ +$$d_{i} = M_{i} e^{-k R_i} \approx M_{i} \min(\sum_{j=0}^{7} \frac{(-k R_i)^j}{j!}, 0)$$ Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. diff --git a/wordlist.txt b/wordlist.txt index 8c5869ec7..7ca46810b 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -318,3 +318,4 @@ CreateReferralSet enum ldots infty +leq From 2f18f45c19991a5cb6bc1bf82215476a3bd5635d Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Tue, 15 Aug 2023 10:55:54 +0100 Subject: [PATCH 496/649] feat: address feedback Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0056-REWA-rewards_overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 148d8e839..fd13bb13a 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -69,14 +69,14 @@ Let: - $t$ be the amount of time elapsed in the current epoch so far -$$\bar{P} = \bar{P} \cdot \left(1 - \frac{t_{n}}{t}\right) + \frac{|P_{n}| \cdot t_{n}}{t}$$ +$$\bar{P} \leftarrow \bar{P} \cdot \left(1 - \frac{t_{n}}{t}\right) + \frac{|P_{n}| \cdot t_{n}}{t}$$ At the end of the epoch, the network must store the parties time weighted average position and then calculate their average position reward metric as follows. Let: - $m_{ap}$ be the parties average position reward metric -- $\bar{P_{i}}$ be the parties time weighted average position in the i th epoch +- $\bar{P_{i}}$ be the parties time weighted average position in the $i$-th epoch - $N$ be the window length specified in the recurring transfer. $$m_{ap} = \frac{\sum_{i}^{n}\bar{P_{i}}}{N}$$ @@ -92,9 +92,9 @@ Let: - $r_i$ be the parties relative returns in the epoch - $m2m_{wins}$ be the sum of all mark-to-market win transfers in the epoch - $m2m_{losses}$ be the sum of all mark-to-market loss transfers in the epoch -- $TWAP$ be the parties time-weighted average position in the epoch. +- $\bar{P}$ be the parties time-weighted average position in the epoch. -$$r = \frac{m2m_{wins} + m2m_{losses}}{TWAP}$$ +$$r = \frac{|m2m_{wins}| - |m2m_{losses}|}{\bar{P}}$$ And calculate their average relative returns over the last $N$ epochs as follows. From 28249770a2f0ae7e32558198aa97bbbae36dea4f Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Tue, 15 Aug 2023 11:17:00 +0100 Subject: [PATCH 497/649] feat: address exponential feedback Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0056-REWA-rewards_overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index fd13bb13a..e6231f20e 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -231,7 +231,7 @@ Let: - $d_{i}$ be the payout factor for entity $i$ - $s_{i}$ be the share of the rewards for entity $i$ -- $k$ be the decay factor specified in the recurring transfer funding the reward. This must be a float in the range $0\leq k \leq 2$. +- $k$ be the decay factor specified in the recurring transfer funding the reward. This must be a decimal in the range $0\leq k \leq 2$. - $R_{i}$ be the normalised rank of entity $i$ - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). @@ -239,7 +239,7 @@ $$d_{i}=M_{i} e^{-k R_{i}}$$ Note if the entity is a team, $M_{i}$ is set to 1 as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). -To avoid exponential formulas in the core implementation, the above exponential equation can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. +To avoid exponential formulas in the core implementation, the above exponential function can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. $$d_{i} = M_{i} e^{-k R_i} \approx M_{i} \min(\sum_{j=0}^{7} \frac{(-k R_i)^j}{j!}, 0)$$ From 4154bcb70a8851fb631a19051e467d0d9b4de8a1 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 15 Aug 2023 18:18:17 +0100 Subject: [PATCH 498/649] feat: switch rank exponential distribution to table --- protocol/0056-REWA-rewards_overview.md | 39 ++++++++++++++++++-------- protocol/0057-TRAN-transfers.md | 16 ++++++++++- 2 files changed, 43 insertions(+), 12 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index e6231f20e..fb35f8bdb 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -196,8 +196,8 @@ Rewards are distributed amongst entities based on the distribution method define The protocol currently supports the following distribution strategies: -- [pro-rata](#distributing-pro-rata) by reward metric -- [exponential-decay](#distributing-with-exponential-decay) by reward metric +- [pro-rata]:(#distributing-pro-rata) distributed pro-rata by reward metric +- [rank]:(#distributing-based-on-rank) distributed by entities rank when ordered by reward metric #### Distributing pro-rata @@ -218,28 +218,45 @@ Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, $$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ -#### Distributing with exponential decay +#### Distributing based on rank -Rewards funded using the exponential-decay strategy should be distributed as follows. +Rewards funded using the rank-distribution strategy should be distributed as follows. -1. Calculate each entities reward metric -2. Order each entity in a descending list by their reward metric value and determine their "rank" in the list -3. Normalise the rank of each party within a range of 0 to 1, using the highest rank as the upper limit for normalisation. -4. Calculate each entities share of the rewards using the below formula. +1. Calculate each entity's reward metric. +2. Arrange all entities in a list in descending order based on their reward metric values and determine their rank. If multiple entities share the same reward metric value, they should be assigned the same rank. The next entity's rank should be adjusted to account for the shared rank among the previous entities. For instance, if two entities share rank 2, the next entity should be assigned rank 4 (since there are two entities with rank 2). +3. Set the entities `share_ratio` based on their position in the `rank_table` specified in the recurring transfer. +4. Calculate each entities share of the rewards. + +```pseudo +Given: + rank_table = [ + {"start_rank": 1, "share_ratio": 10}, + {"start_rank": 2, "share_ratio": 5}, + {"start_rank": 4, "share_ratio": 2}, + {"start_rank": 10, "share_ratio": 1}, + {"start_rank": 20, "share_ratio": 0}, + ] + rank=6 + +Then: + share_ratio=2 +``` + +Calculate each entities share of the rewards as follows. Let: - $d_{i}$ be the payout factor for entity $i$ - $s_{i}$ be the share of the rewards for entity $i$ -- $k$ be the decay factor specified in the recurring transfer funding the reward. This must be a decimal in the range $0\leq k \leq 2$. +- $k$ be the decay factor specified in the recurring transfer funding the reward. This must be a float in the range $0\leq k \leq 2$. - $R_{i}$ be the normalised rank of entity $i$ - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). -$$d_{i}=M_{i} e^{-k R_{i}}$$ +$$d_{i}=M_{i} * r_{i}$$ Note if the entity is a team, $M_{i}$ is set to 1 as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). -To avoid exponential formulas in the core implementation, the above exponential function can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. +To avoid exponential formulas in the core implementation, the above exponential equation can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. $$d_{i} = M_{i} e^{-k R_i} \approx M_{i} \min(\sum_{j=0}^{7} \frac{(-k R_i)^j}{j!}, 0)$$ diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 7db780a4b..774dd01e5 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -103,10 +103,24 @@ To support entity scoping, the transaction include the following fields: - `staking_requirement` - the required minimum number of tokens staked for a party to be considered eligible. Defaults to `0`. - `notional_time_weighted_average_position_requirement` - the required minimum notional time-weighted averaged position required for a party to be considered eligible. Defaults to `0`. -A party should be able to configure the distribution of rewards by specifying a number of epochs to evaluate the reward metric over and specify a number of epochs to delay vesting by. The transaction should now include the following fields. +A party should be able to configure the distribution of rewards by specifying the following fields: - `window_length` - the number of epochs over which to evaluate the reward metric. - `lock_period` - the number of epochs after distribution to delay [vesting of rewards](./0085-RVST-rewards_vesting.md#vesting-mechanics) by. +- `distribution_strategy` - enum defining which [distribution strategy](./0056-REWA-rewards_overview.md#distributing-rewards-between-entities) to use. + - `DISTRIBUTION_STRATEGY_PRO_RATA` - rewards should be distributed among entities [pro-rata](./0056-REWA-rewards_overview.md#distributing-pro-rata) by reward-metric. + - `DISTRIBUTION_STRATEGY_RANK` - rewards should be distributed among entities [based on their rank](./0056-REWA-rewards_overview.md#distributing-based-on-rank) when ordered by reward-metric. +- `rank_table` - if the distribution strategy is `DISTRIBUTION_STRATEGY_RANK`, an ordered list dictionaries defining the rank bands and share ratio for each band should be specified. Note, the `start_rank` values must be integers and in an ascending order. + + ```pseudo + rank_table = [ + {"start_rank": 1, "share_ratio": 10}, + {"start_rank": 2, "share_ratio": 5}, + {"start_rank": 4, "share_ratio": 2}, + {"start_rank": 10, "share_ratio": 1}, + {"start_rank": 20, "share_ratio": 0}, + ] + ``` - At the end of the epoch when the transfer is about to be distributed, it first calculates the contribution of each market to the sum total reward metric for all markets in the `market scope` and then distributes the transfer amount to the corresponding accounts of the markets pro-rata by their contribution to the total. From a6e14e836ca04c52f6fb78f01f79dc3fa351292d Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 15 Aug 2023 18:30:39 +0100 Subject: [PATCH 499/649] feat: address feedback --- protocol/0056-REWA-rewards_overview.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index fb35f8bdb..1529dbcff 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -248,18 +248,13 @@ Let: - $d_{i}$ be the payout factor for entity $i$ - $s_{i}$ be the share of the rewards for entity $i$ -- $k$ be the decay factor specified in the recurring transfer funding the reward. This must be a float in the range $0\leq k \leq 2$. -- $R_{i}$ be the normalised rank of entity $i$ +- $r_{i}$ be the share ratio of entity $i$ as determined from the rank table - $M_{i}$ be the sum of all reward payout multipliers for entity $i$ (reward payout multipliers include the [activity streak multiplier](./0086-ASPR-activity_streak_program.md#applying-the-activity-reward-multiplier) and [bonus rewards multiplier](./0085-RVST-rewards_vesting.md#determining-the-rewards-bonus-multiplier)). $$d_{i}=M_{i} * r_{i}$$ Note if the entity is a team, $M_{i}$ is set to 1 as reward payout multipliers are considered later when distributing rewards [amongst the team members](#distributing-rewards-amongst-team-members). -To avoid exponential formulas in the core implementation, the above exponential equation can be approximated using the following 7th order Taylor expansion. An odd number of terms has intentionally been chosen so the expansion diverges to $-\infty$ rather than $+\infty$. - -$$d_{i} = M_{i} e^{-k R_i} \approx M_{i} \min(\sum_{j=0}^{7} \frac{(-k R_i)^j}{j!}, 0)$$ - Calculate each entities share of the rewards, $s_{i}$ pro-rata based on $d_{i}$, i.e. $$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ From f83d1cdddd75506dbefb0e43f9ae5232bb670b41 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 16 Aug 2023 08:56:29 +0100 Subject: [PATCH 500/649] feat: apply suggestion Co-authored-by: Barnaby M --- protocol/0057-TRAN-transfers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 774dd01e5..0242aeb62 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -100,7 +100,7 @@ To support entity scoping, the transaction include the following fields: - `INDIVIDUAL_SCOPE_IN_TEAM` - all parties which are part of a team are within the scope of this reward - `INDIVIDUAL_SCOPE_NOT_IN_TEAM` - all parties which are not part of a team are within the scope of this reward - `team scope` - optional list if the reward type is `ENTITY_SCOPE_TEAMS`, field allows the funder to define a list of team ids which are eligible to be rewarded from this transfer -- `staking_requirement` - the required minimum number of tokens staked for a party to be considered eligible. Defaults to `0`. +- `staking_requirement` - the required minimum number of governance (e.g. VEGA) tokens staked for a party to be considered eligible. Defaults to `0`. - `notional_time_weighted_average_position_requirement` - the required minimum notional time-weighted averaged position required for a party to be considered eligible. Defaults to `0`. A party should be able to configure the distribution of rewards by specifying the following fields: From 1a29685a886928918d3a2b6b04e4a3302f6d3d7f Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 16 Aug 2023 12:51:11 +0100 Subject: [PATCH 501/649] feat: add limits --- protocol/0057-TRAN-transfers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 0242aeb62..576d1c4cf 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -105,12 +105,12 @@ To support entity scoping, the transaction include the following fields: A party should be able to configure the distribution of rewards by specifying the following fields: -- `window_length` - the number of epochs over which to evaluate the reward metric. +- `window_length` - the number of epochs over which to evaluate the reward metric. The value should be limited to 100 epochs. - `lock_period` - the number of epochs after distribution to delay [vesting of rewards](./0085-RVST-rewards_vesting.md#vesting-mechanics) by. - `distribution_strategy` - enum defining which [distribution strategy](./0056-REWA-rewards_overview.md#distributing-rewards-between-entities) to use. - `DISTRIBUTION_STRATEGY_PRO_RATA` - rewards should be distributed among entities [pro-rata](./0056-REWA-rewards_overview.md#distributing-pro-rata) by reward-metric. - `DISTRIBUTION_STRATEGY_RANK` - rewards should be distributed among entities [based on their rank](./0056-REWA-rewards_overview.md#distributing-based-on-rank) when ordered by reward-metric. -- `rank_table` - if the distribution strategy is `DISTRIBUTION_STRATEGY_RANK`, an ordered list dictionaries defining the rank bands and share ratio for each band should be specified. Note, the `start_rank` values must be integers and in an ascending order. +- `rank_table` - if the distribution strategy is `DISTRIBUTION_STRATEGY_RANK`, an ordered list dictionaries defining the rank bands and share ratio for each band should be specified. Note, the `start_rank` values must be integers in an ascending order and the table can have strictly no more than 500 rows. ```pseudo rank_table = [ From 99c66bdab101620e41d15158bf55612a86eb8755 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 16 Aug 2023 13:03:08 +0100 Subject: [PATCH 502/649] feat: clarify requirements not applied for certain metrics --- protocol/0056-REWA-rewards_overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 1529dbcff..0113b1151 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -39,7 +39,7 @@ Metrics only need to be calculated where the [market, reward type] reward accoun Reward metrics will be calculated once for each party/market combination in the reward metric asset which is the [settlement asset](0070-MKTD-market-decimal-places.md) of the market. This is the original precision for the metric source data. -For each reward metric an individual must meet the [staking requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) **AND** [notional time-weighted average position requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts)) set in the recurring transfer. If they do not then their reward metric is set to `0`. +For reward metrics relating to trading, an individual must meet the [staking requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) **AND** [notional time-weighted average position requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts)) set in the recurring transfer. If they do not then their reward metric is set to `0`. Note, these requirements do not apply to the [validator ranking metric](#returns-volatility-metric) or the [market creation reward metric](#market-creation-reward-metrics). ### Fee-based reward metrics From 1c35a929240b304d4121ace769e0cd5d71d5800d Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 22 Aug 2023 21:07:11 +0100 Subject: [PATCH 503/649] feat: switch reward accounts to per unique transfer --- protocol/0056-REWA-rewards_overview.md | 15 ++++++++------- protocol/0057-TRAN-transfers.md | 4 ++-- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 0113b1151..b62c71944 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -41,6 +41,8 @@ This is the original precision for the metric source data. For reward metrics relating to trading, an individual must meet the [staking requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) **AND** [notional time-weighted average position requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts)) set in the recurring transfer. If they do not then their reward metric is set to `0`. Note, these requirements do not apply to the [validator ranking metric](#returns-volatility-metric) or the [market creation reward metric](#market-creation-reward-metrics). +For reward transfers where the [scope](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) is set to teams, each party must meet the minimum time in team requirement. That is, given a party has been in a team for $N$ epochs, if $N$ is strictly less than the network parameter `rewards.minimumEpochsInTeam` (an integer defaulting to `0`) their reward metric is set to `0`. + ### Fee-based reward metrics There will be three reward metrics calculated based on fees. @@ -51,7 +53,7 @@ There will be three reward metrics calculated based on fees. These metrics apply only to the sum of fees for the epoch in question. That is, the metrics are reset to zero for all parties at the end of the epoch. -If the reward account balance is 0 at the end of the epoch for a given market, any parties with non-zero metrics will not be rewarded for that epoch and their metric scores do not roll over (they are still zeroed). +If the reward account balance is `0` at the end of the epoch for a given recurring transfer, any parties with non-zero metrics will not be rewarded for that epoch and their metric scores do not roll over (they are still zeroed). Fee-based reward metrics (the total fees paid/received by each party as defined above) are stored in [LNL checkpoints](./0073-LIMN-limited_network_life.md) and are restored after a checkpoint restart to ensure rewards are not lost. @@ -170,15 +172,14 @@ A team’s reward metric is the weighted average metric score of the top perform ## Reward accounts -Trading reward accounts are defined by the reward asset (the asset in which the reward is paid out), the market, and the reward type (metric). -That is, there can be multiple rewards with the same type paid in different assets for the same market. +Trading reward accounts are defined by a hash of the fields specified in the recurring transfer funding the reward account (see the [transfers](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) spec for relevant details about each field). This allows multiple recurring transfers to fund the same reward pool. + +Note as part of the recurring transfer a user specifies a settlement asset. The market settlement asset has nothing to do in in particular with the asset used to pay out a reward. -Note that the market settlement asset has nothing to do in particular with the asset used to pay out a reward for a market. That is, a participant might receive rewards in the settlement asset of the market, in VEGA governance tokens, and in any number of other unrelated tokens (perhaps governance of "loyalty"/reward tokens issued by LPs or market creators, or stablecoins like DAI). -Reward accounts are funded by setting up recurring transfers, which may be set to occur only once for a one off reward. -These allow a reward type to be automatically funded on an ongoing basis from a pool of assets. -Recurring transfers can target groups of markets, or all markets for a settlement asset, in which case the amount paid to each market is determined pro-rata by the markets' relative total reward metrics for the given reward type. See [transfers](./0057-TRAN-transfers.md) for more detail. +Reward accounts are funded by setting up recurring transfers, which may be set to occur only once for a one off reward. These allow a reward type to be automatically funded on an ongoing basis from a pool of assets. +Recurring transfers can target groups of markets, or all markets for a settlement asset. See [transfers](./0057-TRAN-transfers.md) for more detail. Reward accounts and balances must be saved in [LNL checkpoints](./0073-LIMN-limited_network_life.md) to ensure all funds remain accounted for across a restart. diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 576d1c4cf..2082e4b2c 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -79,9 +79,9 @@ If the `amount` is less than `transfer.minTransferQuantumMultiple x quantum` the Read this section alongside the [rewards](./0056-REWA-rewards_overview.md) specification. -To be able to dispatch rewards to reward pools of multiple markets pro rata to the contribution of the reward metric (e.g. received maker fees) in the market vs the total of the measured metric across all in scope markets, recurring transfers support auto dispatch in the following way: +When funding a reward account with a recurring transfer, the reward account funded is the hash of the fields in the recurring transfer specific to funding reward accounts (listed below). -- When transferring to a reward account, the transaction must also include the following: +When transferring to a reward account, the transaction must include the following: - `reward metric` — the type of reward (see [rewards](./0056-REWA-rewards_overview.md)) - `reward metric asset` — (the settlement asset of all markets that will be in scope for the transfer) From 4e8202bb8c36df94429dbcc3bae7a48156269adf Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 23 Aug 2023 15:06:46 +0100 Subject: [PATCH 504/649] refactor: clarification of lock period --- protocol/0056-REWA-rewards_overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index b62c71944..6828f9537 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -185,7 +185,7 @@ Reward accounts and balances must be saved in [LNL checkpoints](./0073-LIMN-limi ## Reward distribution -All rewards are distributed to [vesting accounts](./0085-RVST-rewards_vesting.md) at the end of each epoch *after* [recurring transfers](0057-TRAN-transfers.md) have been executed. +All rewards are distributed to [vesting accounts](./0085-RVST-rewards_vesting.md) at the end of each epoch *after* [recurring transfers](0057-TRAN-transfers.md) have been executed. Funds distributed to the vesting account will not start vesting until the [`lock period`](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) defined in the recurring transfer has expired. The entire reward account balance is paid out every epoch unless the total value of the metric over all entities is zero, in which case the balance will also be zero anyway (there are no fractional payouts). From 3b2a0edc020804e4f7a6d0ac60361d43c16d24bc Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 23 Aug 2023 16:44:27 +0100 Subject: [PATCH 505/649] feat: address comments --- protocol/0044-LIME-lp_mechanics.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index fc443454b..7bd06847b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -341,8 +341,10 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - The LP can increase their commitment at any time without incurring fee (0044-LIME-061) for spot (0044-LIME-062) - - When LP increases their commitment higher than their account balance are rejected and old provision persists (0044-LIME-063) for spot (0044-LIME-064) - - When LP decreases their commitment are charged as per `market.liquidity.earlyExitPenalty` (0044-LIME-065) for spot (0044-LIME-066) + - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063) for spot (0044-LIME-064) + - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-075) for spot (0044-LIME-076) + - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transfered into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transfered into market insurance pool (0044-LIME-077) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transfered into the network treasury for the asset (0044-LIME-078) + - When LP that creates new provision with zero commitment or amend a provision with zero commitment are rejected with error message that commitment amount is too low (0044-LIME-067) for spot (0044-LIME-068) - When LP amends the Fee Factor greater than `market.liquidity.maximumLiquidityFeeFactorLevel` are rejected (0044-LIME-070) for spot (0044-LIME-071) - Distressed LP which doesn't meet minimum margin is not cancelled automatically and stays active (0044-LIME-071) for spot (0044-LIME-072) From 8e430f4682fcce63ad0594f040009f287d7ef6f6 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 15:51:08 +0100 Subject: [PATCH 506/649] feat: address comments --- protocol/0044-LIME-lp_mechanics.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 7bd06847b..088a64f7c 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -342,19 +342,19 @@ In the case of spot markets it will be transferred into the network treasury for - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - The LP can increase their commitment at any time without incurring fee (0044-LIME-061) for spot (0044-LIME-062) - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063) for spot (0044-LIME-064) - - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-075) for spot (0044-LIME-076) - - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transfered into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transfered into market insurance pool (0044-LIME-077) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transfered into the network treasury for the asset (0044-LIME-078) - - - When LP that creates new provision with zero commitment or amend a provision with zero commitment are rejected with error message that commitment amount is too low (0044-LIME-067) for spot (0044-LIME-068) - - When LP amends the Fee Factor greater than `market.liquidity.maximumLiquidityFeeFactorLevel` are rejected (0044-LIME-070) for spot (0044-LIME-071) - - Distressed LP which doesn't meet minimum margin is not cancelled automatically and stays active (0044-LIME-071) for spot (0044-LIME-072) - - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-072) for spot (0044-LIME-073) + - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) + - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) + - When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069) for spot (0044-LIME-070) + - When an LP amends the Fee Factor to a value greater than market.liquidity.maximumLiquidityFeeFactorLevel, the amendments are rejected (0044-LIME-071) for spot (0044-LIME-072) + - A distressed LP (when $ bond account == 0 && general account == 0 && margin account < maintenance margin$) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073) for spot (0044-LIME-074) + - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075) for spot (0044-LIME-076) ### Qualifying Order Types -- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) -- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-029) -- LPs can submit GFA orders which gets cancelled as soon as market exits opening-auction and do not count towards an LPs liquidity commitment (0044-LIME-069) +- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) for spot (0044-LIME-029) +- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077) for spot (0044-LIME-078) +- GFA orders during auction (apart form openning auction) from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) +- GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081) for spot (0044-LIME-082) ### Snapshot From 68aa8d8301f7bc9e08149168965875445e0511db Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 16:12:52 +0100 Subject: [PATCH 507/649] feat: update json file --- protocol/features.json | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 40be31c50..1c027e20a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -313,6 +313,17 @@ "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", + "0044-LIME-061", + "0044-LIME-063", + "0044-LIME-065", + "0044-LIME-067", + "0044-LIME-069", + "0044-LIME-071", + "0044-LIME-073", + "0044-LIME-075", + "0044-LIME-077", + "0044-LIME-079", + "0044-LIME-081", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", @@ -453,6 +464,17 @@ "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", + "0044-LIME-062", + "0044-LIME-064", + "0044-LIME-066", + "0044-LIME-068", + "0044-LIME-070", + "0044-LIME-072", + "0044-LIME-074", + "0044-LIME-076", + "0044-LIME-078", + "0044-LIME-080", + "0044-LIME-082", "0056-REWA-051", "0056-REWA-052", "0056-REWA-053", From 6ef0fdea9f57651658f4cee6ec892efd4961136e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 16:17:56 +0100 Subject: [PATCH 508/649] feat: remove 061062 --- protocol/0044-LIME-lp_mechanics.md | 1 - protocol/features.json | 2 -- 2 files changed, 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 088a64f7c..906f2e54e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -340,7 +340,6 @@ In the case of spot markets it will be transferred into the network treasury for - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - - The LP can increase their commitment at any time without incurring fee (0044-LIME-061) for spot (0044-LIME-062) - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063) for spot (0044-LIME-064) - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) diff --git a/protocol/features.json b/protocol/features.json index 1c027e20a..e15ea921c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -313,7 +313,6 @@ "0044-LIME-034", "0044-LIME-035", "0044-LIME-036", - "0044-LIME-061", "0044-LIME-063", "0044-LIME-065", "0044-LIME-067", @@ -464,7 +463,6 @@ "0044-LIME-054", "0044-LIME-055", "0044-LIME-056", - "0044-LIME-062", "0044-LIME-064", "0044-LIME-066", "0044-LIME-068", From ce77913183c728164405f95338529088ab2b4bfb Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 16:31:53 +0100 Subject: [PATCH 509/649] feat: typo --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 906f2e54e..fb1b6a44a 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -344,7 +344,7 @@ In the case of spot markets it will be transferred into the network treasury for - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) - When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069) for spot (0044-LIME-070) - - When an LP amends the Fee Factor to a value greater than market.liquidity.maximumLiquidityFeeFactorLevel, the amendments are rejected (0044-LIME-071) for spot (0044-LIME-072) + - When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071) for spot (0044-LIME-072) - A distressed LP (when $ bond account == 0 && general account == 0 && margin account < maintenance margin$) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073) for spot (0044-LIME-074) - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075) for spot (0044-LIME-076) @@ -352,7 +352,7 @@ In the case of spot markets it will be transferred into the network treasury for - Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) for spot (0044-LIME-029) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077) for spot (0044-LIME-078) -- GFA orders during auction (apart form openning auction) from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) +- GFA orders during auction (apart form opening auction) from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) - GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081) for spot (0044-LIME-082) ### Snapshot From 387565fe91c8cba28e4daea1c2255462995b96b9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 16:45:48 +0100 Subject: [PATCH 510/649] feat: formatting --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index fb1b6a44a..1c5878fa7 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -341,7 +341,7 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063) for spot (0044-LIME-064) - - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) + - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) - When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069) for spot (0044-LIME-070) - When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071) for spot (0044-LIME-072) @@ -350,7 +350,7 @@ In the case of spot markets it will be transferred into the network treasury for ### Qualifying Order Types -- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment. (0044-LIME-028) for spot (0044-LIME-029) +- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028) for spot (0044-LIME-029) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077) for spot (0044-LIME-078) - GFA orders during auction (apart form opening auction) from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) - GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081) for spot (0044-LIME-082) From b737b2c22e8b1cbbd2ee90a0c0f032b7d83d6a39 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 16:49:56 +0100 Subject: [PATCH 511/649] feat: update format for formula --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 1c5878fa7..9ba664e33 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -345,7 +345,7 @@ In the case of spot markets it will be transferred into the network treasury for - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) - When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069) for spot (0044-LIME-070) - When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071) for spot (0044-LIME-072) - - A distressed LP (when $ bond account == 0 && general account == 0 && margin account < maintenance margin$) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073) for spot (0044-LIME-074) + - A distressed LP (when `bond account == 0 && general account == 0 && margin account < maintenance margin`) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073) for spot (0044-LIME-074) - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075) for spot (0044-LIME-076) ### Qualifying Order Types From 97d25bbd1d38a0c9a7299b87dc3fa1bf962ee411 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Thu, 24 Aug 2023 16:51:25 +0100 Subject: [PATCH 512/649] feat: Update AC 080 Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9ba664e33..ff2b8b8ec 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -352,7 +352,7 @@ In the case of spot markets it will be transferred into the network treasury for - Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028) for spot (0044-LIME-029) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077) for spot (0044-LIME-078) -- GFA orders during auction (apart form opening auction) from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) +- GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) - GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081) for spot (0044-LIME-082) ### Snapshot From 90c3812d658e74b3e3b1a84767d98b84a635f74d Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 24 Aug 2023 17:16:58 +0100 Subject: [PATCH 513/649] feat: update space --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index ff2b8b8ec..5e83867cb 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -350,7 +350,7 @@ In the case of spot markets it will be transferred into the network treasury for ### Qualifying Order Types -- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028) for spot (0044-LIME-029) +- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028) for spot (0044-LIME-029) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077) for spot (0044-LIME-078) - GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) - GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081) for spot (0044-LIME-082) From 0861fef5456bec9e4e6f8c5e65e0d1c5e6f99955 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Tue, 29 Aug 2023 11:21:46 +0100 Subject: [PATCH 514/649] Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 79bf67627..8d90f034d 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -387,7 +387,7 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.75` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.75` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-047) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they always meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` for the latest epoch a penalty rate of `0.5` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-039) - If an LP has an active liquidity provision at the start of an epoch, the average `penalty rate` over the previous `n-1` epochs is `0.5` and throughout the epoch they never meet their liquidity provision requirements then they will have a `fraction_of_time_on_book == 0` for the latest epoch a penalty rate of `1` will be applied to liquidity fee payments at the end of the epoch (0042-LIQF-040) - - If an LP has an active liquidity provision at the start of an epoch and no previous performance hysteresis and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-054) + - If an LP has an active liquidity provision at the start of an epoch and no previous performance penalties and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` then no penalty will be applied to their liquidity fee payments at the end of the epoch. (0042-LIQF-054) ### SLA Performance bonus transfers From eba5425c3c3cfed009c13c0dae279c5f4c5e600a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Tue, 29 Aug 2023 13:51:33 +0100 Subject: [PATCH 515/649] feat: typo Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9230fffcf..b8f895e44 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -340,7 +340,7 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - - LP can increase their commitment and it will take affect immediately (0044-LIME-050). For spot (0044-LIME-054) + - LP can increase their commitment and it will take effect immediately (0044-LIME-050). For spot (0044-LIME-054) - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: From f3501c31a7703973614b3ba8979d73bea8226b2e Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Tue, 29 Aug 2023 14:01:19 +0100 Subject: [PATCH 516/649] feat: typo Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index b8f895e44..1e4e554c6 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -341,7 +341,7 @@ In the case of spot markets it will be transferred into the network treasury for - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - LP can increase their commitment and it will take effect immediately (0044-LIME-050). For spot (0044-LIME-054) - - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) + - LP can decrease their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) From 4b853c353a770ae9e9342562aeb335af084d7e72 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 29 Aug 2023 14:30:20 +0100 Subject: [PATCH 517/649] feat: address comments --- protocol/0044-LIME-lp_mechanics.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 1e4e554c6..d11faa6c8 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -350,23 +350,23 @@ In the case of spot markets it will be transferred into the network treasury for - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) - For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-071) - If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-081) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5`, a new LP has committed liquidity with buy order at price `4.74` and sell order at price `5.25`. During the epoch market parameter change `market.liquidity.priceRange = 0.1` (10%) is enacted then at the end of the current epoch the LP is meeting their committed volume of notional and a bond penalty will apply. (0044-LIME-072) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to market.liquidity.priceRange = 0.1 (10%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-072) -- For a market with parameter `market.liquidity.priceRange = 0.05` (5%), is in continuous trading with `mid price` set to `5`, a new LP has committed liquidity and orders at buy price `4.74` and sell price `5.25`. During the epoch market parameter change `market.liquidity.priceRange = 0.01` (1%) is enacted then at the end of the current epoch the LP is meeting their volume of notional and penalty will not apply. (0044-LIME-074) +- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-074) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.79` and sell price `5.25`, at the end of the epoch the LP is not meeting their committed volume of notional because the buy price `3.79` is less than `5%` of `1-0.05 x min(5, 4) = 3.80` (0044-LIME-075) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, while the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than 5% of 1-0.05 x min(5, 4) = 3.80), and a sell order at a price of 5.25. However, at the end of the epoch, the LP has not fulfilled their committed notional volume. (0044-LIME-075) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and a sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and a sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31`, the LP is not meeting their committed volume of notional because the sell price `6.31` is more than `5%` of `1+ 0.05 x max (5, 6) = 6.30` (0044-LIME-077) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31` (which is is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`), the LP is not meeting their committed volume of notional. (0044-LIME-077) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.3`, the LP is not meeting their committed volume of notional (0044-LIME-078) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.3`, the LP is not meeting their committed volume of notional (0044-LIME-078) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` and sell price `5.25`, the LP is not meeting their committed volume of notional because the buy price `4.74` is less than `5%` of `1-0.05 x min(5, n/a) = 4.75` (0044-LIME-079) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell price `5.25`, the LP is not meeting their committed volume of notional. (0044-LIME-079) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` the LP is not meeting their committed volume of notional because the sell price `5.26` is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25` (0044-LIME-080) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`) the LP is not meeting their committed volume of notional. (0044-LIME-080) -- For a market with market parameter `market.liquidity.priceRange = 0.05` (5%), is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) ### Qualifying Order Types From 827aa85ace63445bd923a93719a5a17cf03b773b Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 24 Aug 2023 10:19:54 +0100 Subject: [PATCH 518/649] feat: benefit factors set by original referral set --- .../0083-RFPR-on_chain_referral_program.md | 23 +++++++++++++++---- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 68e67385e..e454a3aa3 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -15,6 +15,8 @@ Providing a party has been associated with a referral set for long enough, they To create an emphasis on community, collaboration, and competition. Referrers will be able to designate their referral set as a team. Teams will have additional fields which allow them to be visible on leaderboards and later to compete for team based rewards. +Note, if a party wants to contribute towards a different referral set or compete as a member of a different team, a party is able to move between referral sets by "reapplying" a new referral code. However, if they do, their referral rewards will still be paid out to the referrer of the original referral set. + ![referral-set-hierarchy-diagram](./0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png) ## Glossary @@ -196,7 +198,9 @@ message ApplyReferralCode{ } ``` -If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors updated](#setting-benefit-factors) accordingly. If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will be transferred to the new referral set at the start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be associated with the set specified in the latest valid transaction. +If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors updated](#setting-benefit-factors) accordingly. Their key must then become associated with the referrers key. All referral rewards will be transferred to this referrers key, regardless of whether the party reapplies a new referral code. + +If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will be transferred to the new referral set at the start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be associated with the set specified in the latest valid transaction. When a referee is transferred, the referrer for which they generate referral rewards for **is not** updated. ### Party volumes @@ -226,23 +230,29 @@ The network can then calculate the sets `referral_set_running_notional_taker_vol Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `ApplyReferralCode` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. +Note, when setting a referees benefit factors we compare a sets `referral_set_running_notional_taker_volume` to a `minimum_running_notional_taker_volume` value. To prevent parties self-referring and moving teams, this `referral_set_running_notional_taker_volume` is always the value of the referees original referral set. + #### Setting the referral reward factor The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. -- `referral_set_running_notional_taker_volume` is greater than or equal to the tiers `minimum_running_notional_taker_volume`. +- `referral_set_running_notional_taker_volume` of the referee's **original** referral set is greater than or equal to the tiers `minimum_running_notional_taker_volume`. The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. +Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. + #### Setting the referral discount factor The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. -- `referral_set_running_notional_taker_volume` is greater than or equal to the tiers `minimum_running_notional_taker_volume`. +- `referral_set_running_notional_taker_volume` of the referee's **original** referral set is greater than or equal to the tiers `minimum_running_notional_taker_volume`. - the referee has been a associated with the referral set for at least the tiers `minimum_epochs`. The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. +Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. + #### Example ```pseudo @@ -288,7 +298,8 @@ Referral program benefit factors are applied by modifying [the fees](./0029-FEES The Parties API should now return a list of all **parties** (which can be filtered by party `id`) with the following additional information: -- current `id` of the referral set the party is associated with +- current `id` of the referral set the party is currently associated with +- current `id` of the party they pay referral rewards to - current `epochs_in_referral_set` - current `party_epoch_notional_taker_volume` - current `referral_reward_factor` @@ -303,6 +314,7 @@ The ReferralSet API should now expose a list of all **referral sets** (which can - current `referral_set_running_notional_taker_volume` - current `referral_reward_factor` applied to referee taker fees - current **maximum possible** `referral_discount_factor` applied to referee taker fees +- for each asset, the total referral rewards paid to the referrer of the referral set - for each asset, the total referral rewards generated by all referee taker fees - for each asset, the total referral discounts applied to all referee taker fees - whether the referral set has been designated as a team @@ -389,9 +401,10 @@ The Estimate Fees API should now calculate the following additional information: 1. If a party **is not** currently a **referee**, the party can immediately become associated with a referral set by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-025). 1. If a party **is** currently a **referee**, the party can become associated with a new referral set (at the start of the next epoch) by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-026). 1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied (0083-RFPR-027). +1. If a party **is** currently a **referee** and becomes associated with a new referral set, their fees should still be paid out to the referrer of the original referral set they were associated with (0083-RFPR-041). 1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected (0083-RFPR-028). - a party must not currently be a **referrer** (0083-RFPR-029). -1. If the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed (0083-RFPR-030). + - the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed (0083-RFPR-030). #### Epoch and running volumes From 3218bcd4e005eb0ae2b11b5898fe92870695790e Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 24 Aug 2023 11:00:14 +0100 Subject: [PATCH 519/649] feat: add reward multipliers for staking --- protocol/0029-FEES-fees.md | 8 +-- .../0083-RFPR-on_chain_referral_program.md | 59 +++++++++++++++++-- 2 files changed, 59 insertions(+), 8 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 9f97c5d1c..5f54c466b 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -51,12 +51,12 @@ Note, it is important discounts are calculated and applied **before** rewards ar maker_fee = maker_fee - maker_fee_referral_discount - maker_fee_volume_discount ``` -1. Calculate any referral rewards due to the parties referrer (Note we are using the updated fee components from step 3) +1. Calculate any referral rewards due to the parties referrer (Note we are using the updated fee components from step 3 and the `referralProgram.maxReferralRewardProportion` is the network parameter described in the [referral program spec](./0083-RFPR-on_chain_referral_program.md#network-parameters)) ```pseudo - infrastructure_fee_referral_reward = floor(infrastructure_fee * referral_reward_factor) - liquidity_fee_referral_reward = floor(liquidity_fee * referral_reward_factor) - maker_fee_referral_reward = floor(maker_fee * referral_reward_factor) + infrastructure_fee_referral_reward = floor(infrastructure_fee * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) + liquidity_fee_referral_reward = floor(liquidity_fee * min(referral_reward_factor * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) + maker_fee_referral_reward = floor(maker_fee * min(referral_reward_factor * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) ``` 1. Finally, update the fee components by applying the rewards. diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index e454a3aa3..8c7961122 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -13,6 +13,8 @@ Whilst a referral program is active, the following benefits may be available to Providing a party has been associated with a referral set for long enough, they will become eligible for greater benefits as their referral sets running taker volume increases. +Referrers will also the ability to increase the proportion of referee taker fees they receive by staking governance tokens ($VEGA). + To create an emphasis on community, collaboration, and competition. Referrers will be able to designate their referral set as a team. Teams will have additional fields which allow them to be visible on leaderboards and later to compete for team based rewards. Note, if a party wants to contribute towards a different referral set or compete as a member of a different team, a party is able to move between referral sets by "reapplying" a new referral code. However, if they do, their referral rewards will still be paid out to the referrer of the original referral set. @@ -31,6 +33,7 @@ Note, if a party wants to contribute towards a different referral set or compete - `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal +- `referralProgram.maxReferralRewardProportion` - limits the proportion (`referee_reward_factor` * `referee_reward_multiplier`) of referee taker fees which can be given to the referrer. - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` - limits the notional volume in quantum units which is eligible each epoch for referral program mechanisms - `referralProgram.minStakedVegaTokens` - limits referral code generation to parties staking at least this number of tokens @@ -42,11 +45,14 @@ If the community wish to update the referral program limits **and** apply these Enabling or changing the terms of the on-chain referral program can be proposed via governance. As part of the proposal, the proposer specifies the following fields: -- `benefit_tiers`: a list of dictionaries with the following fields +- `benefit_tiers`: a list of dictionaries (with the below fields) defining the reward and discount factors from referrals - `minimum_running_notional_taker_volume`: the required [`referral_set_running_notional_taker_volume`](#referral-set-volumes) in quantum units for parties to access this tier - `minimum_epochs`: the required number of epochs a party must have been in a referral set to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted +- `staking_tiers`: a list of dictionaries (with the below fields) defining the multipliers from staking + - `minimum_staked_tokens`: the required number of governance tokens ($VEGA) a referrer must be staking to receive the multiplier + - `referral_reward_multiplier`: the multiplier applied to the referral_reward_factor when calculating referral rewards due to the referrer. - `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled - `window_length`: the number of epochs over which to evaluate a referral sets running notional taker volume @@ -73,6 +79,20 @@ message UpdateReferralProgram{ "referral_discount_factor": 0.010, }, ], + staking_tiers: [ + { + "minimum_staked_tokens": 100, + "referral_reward_multiplier": 1, + }, + { + "minimum_staked_tokens": 1000, + "referral_reward_multiplier": 2, + }. + { + "minimum_staked_tokens": 1000, + "referral_reward_multiplier": 2, + } + ], closing_timestamp: 123456789, window_length: 7, } @@ -85,6 +105,9 @@ When submitting a referral program proposal through governance the following con - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. - all `minimum_epochs` values must be an integer strictly greater than 0 - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. +- the number of tiers in `staking_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. +- all `minimum_staked_tokens` values must be an integer value greater than or equal to `0`. +- all `referral_reward_multiplier` values must be a float value greater than or equal to `1`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. @@ -198,7 +221,7 @@ message ApplyReferralCode{ } ``` -If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors updated](#setting-benefit-factors) accordingly. Their key must then become associated with the referrers key. All referral rewards will be transferred to this referrers key, regardless of whether the party reapplies a new referral code. +If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors and reward multipliers updated](#setting-benefit-factors-and-reward-multipliers) accordingly. Their key must then become associated with the referrers key. All referral rewards will be transferred to this referrers key, regardless of whether the party reapplies a new referral code. If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will be transferred to the new referral set at the start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be associated with the set specified in the latest valid transaction. When a referee is transferred, the referrer for which they generate referral rewards for **is not** updated. @@ -226,7 +249,7 @@ The network can then calculate the sets `referral_set_running_notional_taker_vol ## Benefit mechanics -### Setting benefit factors +### Setting benefit factors and reward multipliers Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `ApplyReferralCode` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. @@ -253,6 +276,16 @@ The referees `referral_discount_factor` is then set to the `referral_discount_fa Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. +### Setting the referral reward multiplier + +The `referral_reward_multiplier` should be set by identifying the "highest" staking tier where the following conditions are fulfilled. + +- the referees **original** referrer is staking greater than or equal to the tiers `minimum_staked_tokens`. + +The referees `referral_reward_multiplier` is then set to the `referral_reward_multiplier` defined in the selected benefit tier. + +Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. + #### Example ```pseudo @@ -277,14 +310,30 @@ Given: "referral_discount_factor": 0.010, }, ] + staking_tiers: [ + { + "minimum_staked_tokens": 100, + "referral_reward_multiplier": 1, + }, + { + "minimum_staked_tokens": 1000, + "referral_reward_multiplier": 2, + }. + { + "minimum_staked_tokens": 1000, + "referral_reward_multiplier": 2, + } + ] And: + referrer_staked_tokens=1023 referral_set_running_notional_taker_volume=22353 party_epochs_in_referral_set=4 Then: referral_reward_factor=0.005 referral_discount_factor=0.001 + referral_reward_multiplier=0.001 ``` These benefit factors are then fixed for the duration of the next epoch. @@ -416,10 +465,12 @@ The Estimate Fees API should now calculate the following additional information: ### Benefit Mechanics -#### Setting benefit factors +#### Setting benefit factors and reward multipliers 1. At the start of an epoch, each referees `referral_reward_factor` and `referral_discount_factor` is reevaluated and fixed for the epoch (0083-RFPR-036). 1. At the start of an epoch, a referees `referral_reward_factor` is set equal to the factor in the highest benefit tier they qualify for (0083-RFPR-037). 1. At the start of an epoch, a referees `referral_discount_factor` is set equal to the factor in the highest benefit tier they qualify for (0083-RFPR-038). +1. At the start of an epoch, a referees `referral_reward_multiplier` is set equal to the multiplier in the highest staking tier they qualify for (0083-RFPR-046). 1. If when evaluating the tier to set the `referral_reward_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0` (0083-RFPR-039). 1. If when evaluating the tier to set the `referral_discount_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0` (0083-RFPR-040). +1. If when evaluating the tier to set the `referral_reward_multiplier`, a referee does not qualify for any tier, their `referral_reward_multiplier` is set to `0` (0083-RFPR-047). From abb9409408ee0ea18045cd6ef39bf3ae0535d277 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 24 Aug 2023 11:01:15 +0100 Subject: [PATCH 520/649] refactor: rename maxBenefitTiers to maxReferralTiers --- protocol/0083-RFPR-on_chain_referral_program.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 8c7961122..187686c81 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -30,7 +30,7 @@ Note, if a party wants to contribute towards a different referral set or compete ## Network Parameters -- `referralProgram.maxBenefitTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program +- `referralProgram.maxReferralTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal - `referralProgram.maxReferralRewardProportion` - limits the proportion (`referee_reward_factor` * `referee_reward_multiplier`) of referee taker fees which can be given to the referrer. @@ -102,10 +102,10 @@ message UpdateReferralProgram{ When submitting a referral program proposal through governance the following conditions apply: - a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. -- the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. +- the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers`. - all `minimum_epochs` values must be an integer strictly greater than 0 - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. -- the number of tiers in `staking_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers`. +- the number of tiers in `staking_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers`. - all `minimum_staked_tokens` values must be an integer value greater than or equal to `0`. - all `referral_reward_multiplier` values must be a float value greater than or equal to `1`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. @@ -404,7 +404,7 @@ The Estimate Fees API should now calculate the following additional information: 1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - the `closing_timestamp` must be less than or equal to the proposals `enactment_time` (0083-RFPR-001). - - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxBenefitTiers` (0083-RFPR-002). + - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers` (0083-RFPR-002). - all `minimum_epochs_in_team` values must be an integer strictly greater than 0 (0083-RFPR-003). - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` (0083-RFPR-004). - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor` (0083-RFPR-005). @@ -433,7 +433,7 @@ The Estimate Fees API should now calculate the following additional information: 1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch (0083-RFPR-020). 1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory (0083-RFPR-021). 1. Updating any of the following network parameters whilst there is an active referral program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future referral program proposals. - - `referralProgram.maxBenefitTiers` (0083-RFPR-041) + - `referralProgram.maxReferralTiers` (0083-RFPR-041) - `referralProgram.maxReferralRewardFactor` (0083-RFPR-042) - `referralProgram.maxReferralDiscountFactor` (0083-RFPR-043) - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` (0083-RFPR-044) From c1a443eac8d033e4647fd9341783170fe38c422a Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 24 Aug 2023 12:07:05 +0100 Subject: [PATCH 521/649] fix: update referral codes --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- protocol/features.json | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 187686c81..6728b519e 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -450,7 +450,7 @@ The Estimate Fees API should now calculate the following additional information: 1. If a party **is not** currently a **referee**, the party can immediately become associated with a referral set by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-025). 1. If a party **is** currently a **referee**, the party can become associated with a new referral set (at the start of the next epoch) by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-026). 1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied (0083-RFPR-027). -1. If a party **is** currently a **referee** and becomes associated with a new referral set, their fees should still be paid out to the referrer of the original referral set they were associated with (0083-RFPR-041). +1. If a party **is** currently a **referee** and becomes associated with a new referral set, their fees should still be paid out to the referrer of the original referral set they were associated with (0083-RFPR-048). 1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected (0083-RFPR-028). - a party must not currently be a **referrer** (0083-RFPR-029). - the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed (0083-RFPR-030). diff --git a/protocol/features.json b/protocol/features.json index e15ea921c..b39e9995c 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -390,6 +390,9 @@ "0083-RFPR-043", "0083-RFPR-044", "0083-RFPR-045", + "0083-RFPR-046", + "0083-RFPR-047", + "0083-RFPR-048", "0084-VDPR-001", "0084-VDPR-002", "0084-VDPR-003", From 712afa3e13cbf3ce29d24dffd61c3f061e1cd78b Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 29 Aug 2023 10:44:24 +0100 Subject: [PATCH 522/649] refactor: address review comments --- protocol/0083-RFPR-on_chain_referral_program.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 6728b519e..cde955319 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -13,7 +13,7 @@ Whilst a referral program is active, the following benefits may be available to Providing a party has been associated with a referral set for long enough, they will become eligible for greater benefits as their referral sets running taker volume increases. -Referrers will also the ability to increase the proportion of referee taker fees they receive by staking governance tokens ($VEGA). +Referrers will also have the ability to increase the proportion of referee taker fees they receive by staking governance tokens ($VEGA). To create an emphasis on community, collaboration, and competition. Referrers will be able to designate their referral set as a team. Teams will have additional fields which allow them to be visible on leaderboards and later to compete for team based rewards. @@ -47,7 +47,7 @@ Enabling or changing the terms of the on-chain referral program can be proposed - `benefit_tiers`: a list of dictionaries (with the below fields) defining the reward and discount factors from referrals - `minimum_running_notional_taker_volume`: the required [`referral_set_running_notional_taker_volume`](#referral-set-volumes) in quantum units for parties to access this tier - - `minimum_epochs`: the required number of epochs a party must have been in a referral set to access this tier + - `minimum_epochs`: the required number of epochs a referee must have been in a referral set to access this tier - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - `referral_discount_factor`: the proportion of the referees taker fees to be discounted - `staking_tiers`: a list of dictionaries (with the below fields) defining the multipliers from staking From bc795f7f6d09bdf8aff3b8768474a1fea91b6b01 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 29 Aug 2023 11:01:15 +0100 Subject: [PATCH 523/649] fix: correct equation for converting to quantum --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index cde955319..21ae856d7 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -230,7 +230,7 @@ If a party is already a referee, and submits another `ApplyReferralCode` transac The network must now track the cumulative notional volume of taker trades for each party in an epoch, call this value `party_epoch_notional_taker_volume`. Note, trades generated by auction uncrossing are not counted. Each time a eligible trade is generated, the network should increment a parties `party_epoch_notional_taker_volume` by the quantum notional volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). ```pseudo -party_epoch_notional_taker_volume = party_epoch_notional_taker_volume + (trade_price * trade_size * settlement_asset_quantum) +party_epoch_notional_taker_volume = party_epoch_notional_taker_volume + (trade_price * trade_size / settlement_asset_quantum) ``` At the end of an epoch, the `party_epoch_notional_taker_volume` is stored by the network and each parties `party_epoch_notional_taker_volume` is reset to `0` ready for the next epoch. From ff6d92037c771eba2b361299a0cf71f9799a3444 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 29 Aug 2023 14:46:43 +0100 Subject: [PATCH 524/649] feat: align with core implementation --- .../0083-RFPR-on_chain_referral_program.md | 18 ++++++++---------- ...eferral_program_referral_set_hierarchy.png | Bin 15897 -> 0 bytes 2 files changed, 8 insertions(+), 10 deletions(-) delete mode 100644 protocol/0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 21ae856d7..2880407be 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -15,18 +15,16 @@ Providing a party has been associated with a referral set for long enough, they Referrers will also have the ability to increase the proportion of referee taker fees they receive by staking governance tokens ($VEGA). -To create an emphasis on community, collaboration, and competition. Referrers will be able to designate their referral set as a team. Teams will have additional fields which allow them to be visible on leaderboards and later to compete for team based rewards. +To create an emphasis on community, collaboration, and competition. Referrers will be able to create a team from their referral set. Teams will have fields which allow them to be visible on leaderboards and to compete for team based rewards. -Note, if a party wants to contribute towards a different referral set or compete as a member of a different team, a party is able to move between referral sets by "reapplying" a new referral code. However, if they do, their referral rewards will still be paid out to the referrer of the original referral set. - -![referral-set-hierarchy-diagram](./0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png) +Note, if a referee wants to compete as a member of a different team, they are able to move between teams by "reapplying" a referral code. However, their referral rewards will still be computed based their original referral set performance and, thus, paid out to the their original referrer. ## Glossary - `referrer`: a party who has generated a referral code for a referral set - `referee`: a party who has applied a referral code to join a referral set - `referral_set`: a group comprised of a single referrer and all their referees -- `team`: a `referral_set` which has been designated as a team and enriched with additional details allowing it to be visible on leaderboards. +- `team`: a group created from a `referral_set` which was designated as a team. A team will be visible on leaderboards and eligible for team rewards. ## Network Parameters @@ -138,9 +136,9 @@ To create a new referral set and become a referrer, a party must fulfil the foll The staking requirement is constant. If a referrer un-stakes enough tokens to fall below the requirement, they and their referees will immediately no longer be eligible for referral benefits. If the referrer re-stakes enough tokens to fulfil the staking requirement, they and their referees will become eligible for referral benefits **at the start of the next epoch**. Note, for the case where a party does not re-stake, the protocol will still allow referees to "move" referral sets by [applying](#applying-a-referral-code) a new referral code as normal. -To create a referral set and generate a referral code, the party must submit a signed `CreateReferralSet` transaction. When creating a referral set, a party can optionally designate it as a [team](#glossary) and provide additional team details. When designated as a team a referral set will be visible on leaderboards and in future releases will be eligible for team rewards. A `CreateReferralSet` transaction has the following fields: +To create a referral set and generate a referral code, the party must submit a signed `CreateReferralSet` transaction. When creating a referral set, a party can optionally designate it to as a [team](#glossary) and provide additional team details. When designated as a team a separate team will be created in addition to the referral set. The team will be visible on leaderboards and eligible for team rewards. A `CreateReferralSet` transaction has the following fields: -- `is_team`: a boolean defining whether the referral set should be designated as a team +- `is_team`: a boolean defining whether the referral set should be designated as a team (and a team created from it) - `team_details`: an optional dictionary defining the teams details (non-optional if `is_team` is `True`) - `name`: mandatory string team name - `team_url`: optional string of a link to a team forum, discord, etc. (defaults to empty string / none-type) @@ -156,7 +154,7 @@ message CreateReferralSet{ } ``` -*Example: if party wants to create a referral set and designate it as a team.* +*Example: if party wants to create a referral set and team.* ```protobuf message CreateReferralSet{ @@ -223,7 +221,7 @@ message ApplyReferralCode{ If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors and reward multipliers updated](#setting-benefit-factors-and-reward-multipliers) accordingly. Their key must then become associated with the referrers key. All referral rewards will be transferred to this referrers key, regardless of whether the party reapplies a new referral code. -If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will be transferred to the new referral set at the start of the next epoch. Note, if the referee has submitted multiple transactions in an epoch, the referee will be associated with the set specified in the latest valid transaction. When a referee is transferred, the referrer for which they generate referral rewards for **is not** updated. +If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will not be transferred to the new referral set but they will be added to the associated team at the start of the next epoch (providing a team exists). Note, if the referee has submitted multiple transactions in an epoch, the referee will be added to the new team specified in the latest valid transaction. ### Party volumes @@ -348,7 +346,7 @@ Referral program benefit factors are applied by modifying [the fees](./0029-FEES The Parties API should now return a list of all **parties** (which can be filtered by party `id`) with the following additional information: - current `id` of the referral set the party is currently associated with -- current `id` of the party they pay referral rewards to +- current `id` of the team the party is currently associated with - current `epochs_in_referral_set` - current `party_epoch_notional_taker_volume` - current `referral_reward_factor` diff --git a/protocol/0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png b/protocol/0083-RFPR-on_chain_referral_program_referral_set_hierarchy.png deleted file mode 100644 index 5430d02acb9f4ad4c3e9748bf3eafcc47359ef6c..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 15897 zcmZvD1z1#V*EJx*NDc$iT_W8Ll0zfi-8FQVf`mgzNrQyaAxKDxbO-_>Al=d;DUILF z`#kS=egAd+a4|C+4rk6ebML*^UTbZnhPnbS7C9CQ3JR{0qMR0ZKD_&ZV1P&RAN!HT*1{+~xh$6$ApU)Rlx) zJ$OC19X&m`4VB;qGA?RPGEeOdM1)<`9c1K{0u2mYJ^h53c)^W@%Lp2IDf;X2AVl;m z{gqsKb>;nh6|FrKt%Q|@?E)R2dTVLGJ)G4v9eC_C)tnujt$8gqrNPaF+w<7C>*{N0 zC@BZHs5rX7mE8;s17&q>H3c0M5pXpXJ%l6af0ar~2LlaTV5c^A$AI*MUFPkqPv+_vh7+ z^$Fl}lGW$+w{+n#6hzoN2x@pqdujxzs%ttaJIGkNsXM7E84Bogy9@ZrE2(RH%5XbK z!+Ch^4B*n-BJR%m`a**GfqvEso_cU29)yd5yt<~Bs;s)6s)MbgimsqMcyoI#b-0U> zf*Rb(z*$3A+D*yzshyiFzo${4qmiz#j=zkwp;w@xf`E}fx3-X@oR_Aux-|GVBRLyK z5hWpQJ3(nJ6-_=~JxgyTRYzqn4K@3x-U`kE{xSwO`oah+FFh|cSrI)4K`$LYk$|Ux z+RCncu9|w*+@7kMd;yAne9m^xHu`WYa7Yjra8+eHIk=;%kW-+n9WOXNxV$oWkP{J* z))4ZPgYyMEHL&wj1e@%1HNYYSFaEm@|FbB;@BfB5pL}Dc?IRQvS`;NYX&ryFU#1TX zUQgaicGQUOagTJoeD3hE<{4*ET3VLMhL+-LR`NzNn?qDl0Mewo5NYG!WVH40Ar23p zhYFiO1CDW}G5uR^Y#cG1dtKbud1tM!^dIDeJlPDWRM@;4xyU`sITPEw9&z)atv9%b z)*g{K5&@N@V|@A5F1o3u#n-CVK)gt6yF`ceQ+9T?7z+{BS#dG*kBtqxG_5jkE!Nam z=%MrHsZ zqgW(>Vl&DsI_3*48r(79vwyUPCBd53+wv;NT+I*1>_LLc2uW zRa#nl1QivvXK5+#{QMls#lj?cr>lO7Kb?_E(*B)^bQ3OLR2 zu`#K2Pm!{U3I+iIfp_KQF|X6pQ$Bp)rB71K!otR;a9wCAVqs7IQ{Y7+&(oeE%5yEl2}+w z%=}?&ZwZ7>e?NK7q;M9|`nso>;<8;*QnGttVL?GhPfv1XZSDK~d-Er~9bxxE0?+n; zO}|yZU)|nz6m>jtDQj#@GimjWH~AE(8?Zm$yfc)}C8n#ZD{^shal@WIQ@jA^7oHBIX#Vk%*FM4Xzh?Z8i#E4pbMMJ|H<(%A0rE-)n<;> zsy4%<%|9te*rV`rIFpY9hV1EGTKem0XlS^RE9UoVNy2(guY@CC=ygvNRfL%dr=O>n zmzPdRNXS?so$UIzZ{KcZqj2atJ3FHggIG?4NV#=z7)CL%)>ZJl55BDI?KdfF4RWL* z7lT+W77yvQV7pILCC-CycRicMXM1}i!FpPN5fZLRIE>NWI5*akkK~FefSX?ap{|aK zf`Y=9nwok>rof$qZapjBXY$=b0pk>|D`#|f=H&P|Oa-!{n!#NV@a6Sm$(zg5?^S|g z!Mo!{DmF{)A(NQ+)I997?&qYP~nhE{+U{9g^QK$=ugci`vCrR8*z}G&D40pPxOeVrB|4@I&V`X_69jTQo__&HdHCd0Yn; zul~27t;WN5jJIN(H?lG^db&C~C)q-7X4WPqIUhO9Ft^pYzPBTtD<&o;cB+g&wwzyF zn6k37n99)z;~!jX>?;jMn3_R*a6pKaRbhJMS2fmGX%I#xrpZdv)+q^L;q!bcS_2!m zS(jFNj}rAJg+GfO#((ncfNmrdm8%ZSv(M2+@me?t>GIywa8<>j6C z?(+xH9UfESZLU?DwqCv~F2?w?zc6Rk_hbJu;B-e9Mna;Wm6vC(tEF{>LAUN~jM+J* zv`0ov+}PUE64+C$mOXD}ZEe^nnP30xuRIEzK_!j7dF|J)TsA1g4l3h>cu0}WRGX0S z)Wyr|c*A3@PoSiz=t3Kt%{aH~*BLgk1vW7|%g~oER?SUKJ?ZJ`C3Eyxjfz&E$Hp|8 zT25!0y-K(m5RJW#6{dL>*%HoE>^)emp1V_3gAs{Xznp6JN)RzUW@cuDsmee5zZa`% zTbwqyY?XNz!!0_)??2q$-mY2BWJnpr%W4U+Zm{QL#KXs5;z}P<2)*1cF=K$oaTA-> zo3Sa-3JImF=1G3)>+W8w2oDce(p#j02OHCRxZy>oTkI0>$e1ZtXNb!} zOKPSNNC7Hx^aLivd~Oudo>FpAbf7W<9srdgOr32M6a5Cm+aRAhhLsdwXeYY;1&k zdU`Yz%-J5r6~*LbW+L;WIZQau)IdNN6nzQ!Y@#QYL=_BTB%D=X3B5)zmj8ygtz%_b`SDPQavAVef2 zDFh7g*OOCIq1qZ6+#|`Yw%-^*u0Eatg-8C4um?SK=Ek7_k^w`tNuiVsZaV3Ur}zwV zR8Y<1xv63f6jz_b|~KwxJdQc^-V?$fej$}fka z!(cGh@87?(6=^+&xf!A-aYXjCQ;GRrTh7)y($>)A3KF5Jz)|ED>+GM(D=7_Xr`0qx zqQhE`{o5)CnN_zkl9Oc~xD3{%fAPgfb*aLq7H3ISWQ0uH>Di{wC{a>U2K!8uYSQT- z<;koN5UClTz3Ez+Bt@I4fmk~xp8c?^(_Ip!_eqtAORWH1$nxbjNbEnp1|+x$!n$E> z;^Nmc04{iJz0QXi@S%YOmO@NK6l~8q#95a}+BgQHC*}C)2(6SUP2j0Hs~GgTt^Vj6 zi6JK^C*EO8XM`uLn?k8Tqw>qp&~aho*lYC0a1@uSpg((t-Bz`FS+iGz6O5s6daZKL zZ?AqEPEZW$6?6TH#zOUfB5`x_9V=4iF#PdNlA6-$h>PIW=0dAqUD*@v-1Ej5ly1cyHTU}kv_V@busX6(?$evd$ zmIXaJH28Ot0(DuN*X9VTb#%9YAkuR1hym}Kzp@f(hmYv9f=UU`w_=&}yyi7}9{4sn zqkCmuRaJF;BwHu}!}nuGnf!eoCNzjf-s{&o?5WDFq!p%blSrGBKv@)72XV>I8(j-e zm~wsyiK7sz<_CBpuGaGjS!BKwHZiFb`%U0 zZ+R5=`t9nlK|ODC^p#;4!7*ykrF-rY$HT)j$(zYOKX#FXtG+rmHnzr~@G3ZF1GBMQ z1Rg1XiZ+lC3|0dT2p`+A`Bn_3+RvY#RhE?4$4JrUulT5PKXxFTik31kFt9}+eytuI z9eK+txhcYe0s{ky?d*OnvY-h@c5HtyQS$co)kAMH3oyKA8Tk-DQ zyX^MV9ksg;@L@qgfyd@(UJ0D)@)btNQZFMbdsHZ6jzc;f7 zDBWdbe0C>Fs;VdBMV6O%^3UlH%+ZsRlbw8jFNPG=)VODGW^5_1-h!`YTU%QfQ}UwU z8t5!&`1DXHl$MQ)D_UgZKBD#;vL{&b?<$DZpq}2|X6HHDkT>)P+~|z32N%CSE)9U# zkat~dQv%55!EIH2{cC`LlUrIuJvT?Fn5X!x(m(-D#-kF2nwy)$NJ$m_#i<`WctB^` z;!U^E;==#}&Hnc5xC#j48<0fbKZxwIuTRw_f#I)uHYw zeO$l#{rQo8wFzB(d_2zK?P0<*ZaH+i7vbTM=x#ay!y~@h@%8w4dowB*CDYZbGBW^h zEytP)t2G#g($GBrd%gK&7_$>V)syY-m@77eUZWBUmw$daCoy!c9XbJ+V~OIaPJ!CM z%#%0z_ZD2@zR0uNV0{F6;iwk+a}>q&loZ+a>mwDkv$o}BiztJet26tT#KgpQ?)m6w zsK;SV?ki}=olvA4y6cCx3JJ`bnwrB3oiJr1quE@a-Kn1sB4rqPel$6#tlk1RVji4i=%{8|qb2)>tNlE@gU<5${LtoT zeK1aZgA*k0N>JFLa%*+9dW?7v9$W;jbVY`wbDAn!+hqpTSLNSiWs!dfx$^zs{DX62 zSk(3l5wB$z`o^BqzPoc2;r3YVA=v%#{;ct&Gyf2v$Ni-CCe~+o_FMQ*t`jd(5)-8s12(Brs)vWtI4UIFm!(`SEm!2!F3TSy zLqNMR6cZCeS@8H>B>fmUs_OZ>cZ_ze*MH{RvVT@OZ)tYU1b}5W>?_8@lXSt7St!-L zSf>4`NUJR3u}x8npa8vxhQ`>{(1*G=f4{!16?wbX7$n!Q0Bg?Dn zS?Bj;)mGS5+jXOo){Q?jLc@mp*oE^F$oPtzK77!sDvDudq`sN9P6+Y6x%6qlqVSri zEZxrwy+jU!OfDxUm-zZMQS7)N1qIxpj)coh_2~F`aH`5!33RP-QveOw^#1<*ms$mK zaby`^$^=&Hlh)viqgzlnd<3)V>#ZuJQD%)zI$h=(<1apcA~wnWnk$yxEc4>e0_o4S zgeR^>b#`Cx7ib6@(7?P5+4VHl)No__MtJ+U4fS&YJf;JYEpP!Kl*`dx#V?2DN^!3Z z)uZd<(G<08LC33>*-e7jp`js_0u2^X0-2b(pp^nPp6G5v5%=Yerr}}LmQ+3L=3kO1 z+Jj0d%mmYzdoy*>WB8YU`^e?81rg+(H~Y6YSGcZSBB9skM{eyG%(|?p)#J#Xu&}TT zGBPq#2TI2|rqY%-o$l749gj2R8~I#cACEFJSTic=y_G19D`!D08gR6pT~t&=(304s zU}3TRQLF6rtkT@}Fb4|@E!XF3UTdEQ&!5U-^3uny?~NK_YX69Ou0vp@j<jqsYv}2uJ_f^4S0r|Ym#60+tjMlNqonE4(Wl;^%H@aNTxL>`%(f#5I*0?$4_1a3 zxR`4GEWa3N(v}Q3dMDjD1tOIGEj%8kucJfDy0N4j#OA@pnI4oTdh7h;`P41OYlE@I zuB9~B0v{SRm#P&mTtqwFb?R>noDSXZPpgWYQhLOxf4``;?r(pSmIlwI@}^O!2<8(N z&GO!#&t$E|;SSXBU1$%Tv$k-oSJGYA!FS14%BjYyRj?ki}_|R4erLWB3Eao{b9Shzok`GMbZcC!QrG@ z;w;wV4k*+dI3`*8Onlu@#4j2 zvsT|<76t`lRy2@h46DnNZC?a7VlOEw{UrH`4ts+VcMr4 zCQdWf(2&9v9~NIOcA&<);Vx?ny=gIRCd@*cYn**fVQpi>Xq{E&Y!L>K9c!4>b5(+L zU4(cI?CSiyG7gCh@B+B}#A(ok0nz14u#QS>_-A>{O~!y`mMBgtUoPVNXHMIxO2f%$ zJgUq5^75TGvOV`0@vyL360@={aoR`frv=eoB7IhS9(e9e^UUp+-v8qYu=IK)iP_j= zI}*LarlzJ?tJ-t3^D#`ty^Rg#)_`L>Omdu2G=;_I^mMFDg&N^KIur;g3xP^3Bd0`C zO@W4Zw|Lq>P-e@V9UPj{hYvzw3ZBjLu@e(o-AOg8{rSV?)zx-gLt|Fd=+MQ1xjExU zOg~HsRT<5!kI0suu5N?6MS)Kvxo7{z^_!kr7)lPsd9Y+1Rt7_4%;QT3Tm&s8r?0F` zfrj%VWNB&X7XbJ=8uq?pDuN#H4-+G!>dStI zDw1kF0KH>0*#a)(XA~|4UQF-mAbz4SH}}Dlyl1x;45N})m3j}yqpL7cb0V8fIK7H& z;xoxAF&)1$_PRp!)j>mOlpFu~YG3T=3)}l^T_dB*fqRU0wFYVrA3kJ%`jmV?wvMi* zy+qJux&uo3gRr+sWig`mofIg$A&}bSwTI9*2ri zJ%E1|0v$2A^o!MPK}gyyv6fd?e0-LH(Y|6Q5#j!4McfLdFqO3o9_u4OaR?{$5-_+W=P6lw7R;w%H0-P1R$VR0)Auv0#x=8fq*1Q zYg0%^$Gs%6zK3S_`P@%@Fsp`FQTLS%K=Gk>pWFipwxrQOO&Sj zpqkUdSp`wV;cPOSjL|r8VA`RZ&-`=2ZwaBSq@?6~aCY_-G~-!OO-=RF#Axnf!K=te zFLhWOs$R{wy9ra`U0iJD33xu0%Q-k(403yaFS=Xga3z`suVjv6E}IO{U{*OJN%${` zccoAQYM}L&(>0b(_xq-Tz7@(pqC&fO@7eIcz!m}**~7-hrX(x-0&f1e0YbWs8Y$E1 z61{8|738-r;OQ$ks&wDn$)DpJgc?rn!k`oTlIFl^+{Qjw2=zkOrNnK0V*^ggJ2n3L zv9=-{-nY~O5mE?tOyt==?5FvG6<%7(!W_VNB%3P{q*vjGdw2i{VTegbB2&R9wAfOi zMgO%hKHNqHBoc}K;;q`n@#qtzRvBZ0WK1Ph%fod&nQM31qDQ?F%pc^%D?1wSq{kh< z;iA5imk-_sV4FaQmb?qT9VRq0bXSeVxV zpiu|wR9VVy-q*3ktf`}crJpiM^FA`Mf^ukGiBZ`*i zItq|5@f%O}mX|vwaJ{6Ba9*HX#}dL|{4px=53gwco-3rjsHmtgp-*bMx+EW&TC-$? z$H1Xzw<#ItEH(G!Wt>?o4A_bJRu26JA|8AQzVO`0TK{|d`|rRI*XQ9%SC(@pI;fB$ z9vew8(Sg_(0DHQE*%tx9n+!UYKfmS_l$Di9pO5wNjf%^HA|z{}A6K>C8%sjgItlho zHZ-jX>2oVbd=`aSQ)Iq*GvXoySd)v6msVo2b>btXkh1KX&T-|}6o*xi%f*UW+=G;E>h_O-D zK?fEG2a(qY-S{@WF%O5&S0JaoB<9>VJxf5K%3R2B8n*0#k&}N>#K=W9l9Jsgm0e9=ueh;=Y;0ZFU;?Y9uxZ?EGmsJCr#5dCqj;>Tl2w+31<5 zO8GlkFv-&LsN$$Ph!c{K^rHuM`%*}xlSlT?VFa?jW=5p`y(<{<{z z;j?Rs(79S`%#>QZ3Z`2;UO@o?o_7kJdedLO#s~bioO8^vl+vqzkwB<7{>KWdB87^O zRP5oq-njU9TS@xzW=0W?B=YB57@jpYSiIJ11xEbXeD0&`= zBs6Z7QXSCFwHj;9Uv}K>wA_;L^4j3N+WrBC1aTQW8p+|{VVy8Mi^F#u@ST@dJ4=>g z@wbjvvhf!yKYvcHFK=y42ZPR9p;A4Hl@(?^shx}TXzymlDGYl_%OpwZ_W4FoRx8-U zJaC%{j&4xd2Fhcco)6$IhxJJSE*@6h2*&)%mC$dE0re@wt@NhF>&ns5(cylFfwbIv z{@^+OeXN0(eo{Dcp(h6i78uloDCSQl%OiF1DuieIT6YxVCT)i^c<@a&EsiYZ^LVWL zJ_QOSQCWNZ^(F6zsaovu)>KGcfICdeMB{=eIB~AXcl-JCCwxd~KC36|5AJWv^m}KD zM8RYp>raVg=Y?G?sOx=tSohg*SEb7^8U&EKjQwOMw?vf& zD~AI8zJzSzig8s!jT_~K^gPUX**8nHml-JTIey;WHmf|{Z_(|QCKWK}tbG{a5*!>H zsu58skDl_9d$+x3O~n0yku~s&+(9f%T2aqj%e)rej!GCjrjusFT4|g@+Q-Uz zb-!{}*l1bro}NRM5>7uVf`^xw^KuH?%1P9f^xoU*9)x2_txw;SVuL`RAeOx#3zrdz zLt{a`!zb9jPNkF>1iZq<7!iIXL@lg+;}#9;Wew&{&!Jm5QE0_-%}H8cjt&NY-PR{NFelZ zTJ!mH?wHO~qF31EsiZeONvQIKur(0`&v?3fRH%7L>U4(vYNKKt-w5c-$zGtaByk(o zddhg=FkxWr(@P7ghE^I?DaCd6vf?rg+@!Bgi^|ePa&RafP<^bLFWI?3sht_n$oa z_(r2xlF*r#Q<(IRa1ja$S?8S>pj$=(MXh~@C87eh#cA}uXEu?P2Gf+Am;b?O)zcEb z+Omf4tW}3CKD(s7$uSetb}wo&atx|?Jao~W)T~^-5^NB%5$trN5{+03`<0J;EBEC$ zM0%XXIaBW8)f@r5ym_YOY;nKi5QXiwyZ$@v z)0eVO)bJJ{Dh-4c3O_fg%bM2I>i%+=%@Qx3QolQAtrgNpFA4XqXu{S9!6-bKHTSyw zWyPv+k%t7&spXC1PMC5FmVPLSA>x9pQfHWmNUKJjg|WL|Ln}Cmj0`Tcw6!0+HZ2e5 zgYkc7EyB>#&3TdkP4B0A6q*xYtcC?%ms>0s;B+d#oTRDgCkn=C0pKWCF)#wsnn zK{Sf&BL%jzmA_YZLHbFD2~ECQo<&+ekQ~;)DX%={t~O}a{dnJ>q#rU3rQJeR#JPzE zwIwU!a;oIJL@f_{qxUvMPsAkq`2@g!Kemj}E65>H6}UKsJLBf*e-80-?jN9P+G2y% zU@S3FQ5Hoah6GwIuT6J9dWE`i6hBA~6@)C^H46%zGZYH<9e#VfihKFe-$6efQ9Eh2 zmUV(l^JqG{TSwRSElQ<_T!)9uk3tT3OQUt=nfHfj-l$*owW5l^7 z(CZs=_vb#o?_n`hZGk*p;t@xS`eVi07E#|f1=(8fwNbn6@g8W9eSS&k9G%W2UX}8M zCw|ZJfvi0xnS%}f+OpHIQA7M50SSp;Oy4x`#>I_+es2_UBrpF(0z7jpCI=@|}UE(@lXP;1V>Yc7! z{uqsazrI*8^RGzmn)=dLl%zX;bR2zcgGS+niWHv|DW%q1-O{HRkgV82hiKkl1VCWO}JA*DF~*B-R~yYjQ1o|@`oYjxz_JpUfx z9rGTNY~ndtlvk9Hc9aqv>-%5pBqmgUFf`GuvO?9R$}_xojH31RWn{VzS65e)aFD?K z@B^$kK1m=!n=TBU`0dJ}&^VmaF&Hs(q(!1!FBd#V=Mmrl)MJXjM*o*CP)#+SrFF6$?UEq)L1u7Yr?#iE5?hdtlfAx%qN{;M3+AZZ_ln9m zDJ7-uHMEN{ygjcc323;5a`XjXI1tc=E_;F`Lez6;SPJnm?Q;k<=$L4++_0#*vvd6`!9TOk0G7Q3d+$AO&X~{YZ zk2Y=924IIE|g_fZlZnof@VG)12mrXgXd(GR3Y2{5eb$Ne zBG!_8&JOq}wC9}e#ZkGuO_Gxk6Eprj3wTNM+}zw7B@YjtVGbIW|9mj9LqFdXF=qr? zyZJn%eT{#F8c)g-UTM-izO(+3C=7U8*d;WRNwO-VU+E6`}Fsp_9);-P!@U#dIml6yeIz?_Np2y}utkyr~x&fLM%GWK?M z$$*X{jq7ko>t2~iOH1qO+0ANXw5y-EBi5tvsLG{Dwip^;qBKr%f9;WYgv&T~3z0=e z2Ki>_IPKD0*93T7o;dOXa$T@ty!?#15w?b1;|Y3jkIc->iGyxpvU1D3{JkuGM;I{g zS%r^%4_g0=8XaU|AS4JJd_WPSkVE?Xt%;*~(te%o)~*CZsxwMzem$3kki;RY+8Chr z8F(-A=Nt-NlkO)KAZ~!nP-;s;7k7UOKwUCKd;3`jLX9GrwymuV3VlyV_pa$v+38p+ zDc9k}bsd{t<<{Rm3ODYgQ-@kN^!)m;_|rzj+}`XIdE*$6KbX!xx2GBW`dW&ZYkWLa zZ5m|8LbU2swosVXGhlxGzluvyqucG`u7pb!ff+MBeYnV@xfBWpz!=|t9UZmrqS&^^ zu5uNXhr`qU0>^;+pIa?+7{k}t|A;-pN#A7%H0V%-;OK9ks;f7~cAzy~sVOR2gn!!I zQ7_%zlOB5xiW8B(o?dx;VacGfYWRy6`gcYHHyc~q`wpz=AtRDdDGSuZng0H0;Egkcw($(!v)Yp#=McBy!ReuKb=^p`a|ExUdDFcjQGwbbJYeT@yG2j-K;Avf5 zQ}MJ)S-so1(?t>Vl$>2(s*OLsq7`6QtW;5DH?_MLzT&epp;V^BTI--!ULmUuv(~@^ z4m(RZAh!9$XhfIi-o9eVGAOJ0)ECiD<2=kC#`5}{Wd*-+blTB@B2_EzagEE&haDgo z%md0sZQ>nuJP3EBP2J2B9bMh#wf02f7^xsghm;LS$u^)$#x;=Cf1JvH+9^Ub>t|rf zVbYY?)89`q;Vzp(_TtJ8xZ}=opA^NgRqab4Kr?y13!3;pcR4z`C1(3K5o+adQ+U|X z(2pPKs+qizGp@$Tf)ulMF6n20$6#e+BP)7XJ*L`xwD?3@&~=_=2@uOa0Y!)@bFfvF z+x|ZMUrF^rLrF2^Bo^wr!pOjYg`P;pVf)FrimIfU*Sq9SLy{vv)R3Ut#ZPmnz7aR9 zxb86WF^i2B^W8IGOI0>!jBud*u2+#t`r+W>`u9@6W-c|jIIr(Af|o4v&!thAb3mS4 z2N7p;jUdo{IBVwe(J~Ja$Hza?RO8&|OE&8*7a#HY1T-H?!12+k#^gh_Q(s>%2JB!% zgjkVJowcK<7?~q*?gVa!4itn%@n~ao$Iqd3GAp`9l9y3&@c@fHQhd2sq(Wj>)E5tQ zZOiJ~X%|6RQ3VBsLLJu3gm6`6>*{Ckv>vByptJn~LTqNw!snYm6e$5v8c0t|7v@_4 zR)|Gt{iyz$Ge_inhfA3%4p;W6q;rPQb8^1I`2HOOaan1Eo=M6Po<5V4aY=8uC-RhZ{y&A?N&x_RU z+Eum+{-v%4%xt4UzdtEx7Z?reQkxys3%FksN)J zmlR4v-^Bf3;AY6Lti<{9sTepQ-()Rfe}t>iz+_X-e@nl>h@buxBy{Rtc$`F^e-Dk% zZkXi>P^CS>q_}mXe`M;P(DS&I|JRZ6d!hAXHSgFN3z{#oW3obj@LyL3v{$Pt-aCkP zTg8gh={@AZ1Ed)60OXs#LjT1tFQtHvfkUccWMGhCq@z<0?`OsN0OLyq(%<2Gz|2SY z_Vs-@A&6>MA*dm_bB#O%eh0KNomsUd$=y$|rH9M^YeBL0*cM|v2{BecsjWK?Zm%pX zM2n&_-<>m;O(IpUuIvN?J*ej-y1Kh!tiTZlU#{let(2mD$s?zL3%8PaSprI_rLS)z ze!Mo~WkG?@G(DPo)5}+{s)4|POBXRgUYHQY$a8phmT-D2Qyd)~PxhxZ-pcLPK0v>#pSP3x<~RPkQydxk zrjk2m4W113_hjsvY+@_nQ*V3h?Lf0zcQGw8AUOf=z4dSIkv&R?wF* zG0C@}_AWut!w>t2zc4bwANh+fx&dJwOI=y{h{w0Y;f4s+i#{oHF=^Hey~-{;HUf=ki!QwpaA< z=4`2MpZZ+wo5J0`j1Z}?tCR0f*@&=uv7-*u$8{XEQ%HFtNLW+9Oak9J@OSHLi)?!l zp~k}Vo0>9CfB+xWYgI*r6-kq&Wss6WntNxhX3hTkCMP|ej_#N4F(v7tYRMWh-w{UP7?e$nta4H>U*!}HoLMCNcL_|akaD20Zm`#9cIeDVaI*cVNR?;8! z4yHW18n0?#QpIQOzJaitwKZ7*zBiSLiAfR7l>j{|I1O%P=lu0wJ7*$mD+`kSJ}OHs z&@_x#lN2wFyNG9DqdisqU+&z{*C5-7e%pPdlG*o%4YN9FB=3niBMga=VT_!dVlh}% z4t}aW&*1lK_Ouo-lAfiu={Ly(CKAz1QwJ;EMMAFg=L8^%;+AzNU))p}-wh|UCVAhZL_H{t=F*y%$d-zOFo zv%XAUid4`Yns(;d*UiiT+lXTUfs8km=cO4CC+Yiv@tV>G*m@q{gq>0mI5Y5E&Smzm zQ3dUkl?Vf&H-Hwmz2rAh{%?lT1rYAy_RJ{V-MLAljTn;RrgKqB~=Jl@6=CqT$>7zC!Zv zUBY^B)CX=DffqaE&Wp`Y@%C}?E1$-&y$GP{zCS!TIR9eMoTM5b_cf8UgO1{@R@t>b z@Y7;t(acO}4<60QhAvA4{i&g(qFUmH`^tFHS!jckC^UC)aKNB@HwwZf1h@j6I9(iD ziNo)#jf22VmEYD94B*1!s1baZeb-rfB$+BGtkz(DLa4u|heh&o>n%#4p5U1dU&xj4 z6{kT>K06y*?9bIzn7NtR8`r?caZ80?lg~N5-vB3KD-f3yfN8M_NOAFY-h8(?A6^pQ z)up>n>)_9yk%tg;J_ua{F@wI{yN8EI z5ok?y!Gd=)Ncovs4V}eCk_C(U?9><5*L(NAQ%YGM92~qwMdj}(t|sgsUj(8h1Av8W zqXPp6Kq@t7fFY+0vf}!Z`>Pd$N#vG*Uz>wI$>Cb;cboR##h~8-WY{J~?;W9v%F5-2 zfG?t<`bih9TcPt@V zB{DMdFd}g`3ehR*RAS2BlK9p*(P#ZUU77eup9M4x;Z|&)SxkF|Z`tRF;OSl?4 zvg;#+j%1GncL?XTef1$}&*t&p$?0j*iz#C_5e~Dq>27d!CLhLpjp@eb=T$*ETBi_n zaq#u3v&ObhvBDTwabaAHxq9Rp4xu4-O8N`g{9QPdWB6^v+MHw|E5F%&Vh| z>q=0#b^ioz=tc`M)rv+y4kIhFKs6m)JIn!{;?_fu_f$DLChnE|BCM&o1d4gq-C`j} z%8jq@@3(8S6L-r)nN#ZPU!XA6`f6MA=Z!wAYijcEn69<10O|49Q$$_Ey_%{L%egk| ze!R+-ML^E9X|P;BhaMH(3d||szV2y>=S%Ni8Fq4XL^4IVGplBdi349@Ug%BYn`mM+ zXp{FgZ04hz`6PfZ1ro18mVXBdb8bYUmD*y-=rum7vek{fEIycDX))oX*#$HlpjZC? zGedP?W{4cj47s|x=Ee4|E<_|c3r^{#_(msB*SMcyVPR#>PfQT$nw!(`+YCShyuIuH z0^J&_JW#`7D2<>`dYL2Q6$Ly{>3JevePBGxbl9r)l_FzuNJL^@Wj?kZ9X(U+VN_XN zMa6C`ut=-{JKNQfe_J1&Y?N>tn66qJ6+gyVb)a}}%QqRfn;%QUl?)QGUY=w~i#$+k z&#$h`)0B%cL8dX))1asBBe5_x&QW9r#PQnwpzGX=rL5Mu5Q*ug{@3L_q33 z*#?-?8W5oNag;asPMz^>wi4S|9Ea zVA`iPfre=QIW!meWp-9}cY{)TtxSQ3zXVK%Y)MoHFcUJ>2DrPupHz52m(jAD zG>C;LrkXbs=gRdFXZqY2;Da~7(933GB2*vDOQCsQU0o4^uC9lK0W=G=V7jXZ2&Q06 zjxZyhKAZ8wRi{gBSs9X_pC8(6q7E!9fPTX*D=()9svx=z7^PDKk$MVHfh*@f^L$ZM z0esnCiN(akHiv#5we9RU<=Cz`97Nkn+kYO{fEo8sU(p}mr;A9a*8y)v2ZqwX_+m~I z5bkc3i^hTftN8^OFLQHp@Ig(w#TJ**6Xb8)pUwl~(rla5lpNA3Z7o z4OPDrCT8>z7ywxXVPPtT&31yt-Vq Ij79kW0A-^LGXMYp From d855bdedc7fb73ea90eea376114ef5479d5f19b2 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 29 Aug 2023 16:15:16 +0100 Subject: [PATCH 525/649] feat: update market parameter part --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index d11faa6c8..68ff4e611 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -27,7 +27,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. ### Market parameters -All market parameters can be set / modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal and the new value take effect at the first new epoch after enactment. +All following market parameters can be set / modified as part of [market proposal](0028-GOVE-governance.md) / market change proposal and the new value take effect at the first new epoch after enactment. - `market.liquidity.priceRange` (decimal) - this is a percentage price move (e.g. `0.05 = 5%`) from `mid_price` during continuous trading or indicative uncrossing price during auctions. @@ -354,7 +354,7 @@ In the case of spot markets it will be transferred into the network treasury for - In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-074) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, while the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than 5% of 1-0.05 x min(5, 4) = 3.80), and a sell order at a price of 5.25. However, at the end of the epoch, the LP has not fulfilled their committed notional volume. (0044-LIME-075) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, while the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25. However, at the end of the epoch, the LP has not fulfilled their committed notional volume. (0044-LIME-075) - For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and a sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) From c34b94d02bfacc333753930fb742e95ef7dd55a9 Mon Sep 17 00:00:00 2001 From: Tom Date: Tue, 29 Aug 2023 21:37:07 +0100 Subject: [PATCH 526/649] feat: Adding perp margin calcs (#1915) * feat: Adding perp margin calcs --- protocol/0019-MCAL-margin_calculator.md | 42 +++++++++++++++++++++++++ protocol/features.json | 7 ++++- 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index 049ceaec8..fbad9aecb 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -40,6 +40,48 @@ - If the `market.maxSlippageFraction` is updated via governance then it will be used at the next margin evaluation i.e. at the first mark price update following the parameter update. (0019-MCAL-013) +- For a perpetual future market, the maintenance margin is equal to the maintenance margin on an equivalent dated future market, plus a component related to the expected upcoming margin funding payment. Specifically: + - If a party is long `1` unit and the mark price is `15 900` and `market.maxSlippageFraction[1] = 0.25`, `market.maxSlippageFraction[2] = 0.25` and `RF long = 0.1` and order book is + + ```book + buy 1 @ 15 000 + buy 10 @ 14 900 + and + sell 1 @ 100 000 + sell 10 @ 100 100 + ``` + + then the dated future maintenance margin component for the party is `15 900 x (0.25 x 1 + 0.25 x 1 x 1) + 0.1 x 1 x 15 900 = 9 540`. The current accrued funding payment for the perpetual component is calculated using + + ```book + delta_t = funding_period_end - max(funding_period_start, internal_data_points[0].t) + funding_payment = f_twap - s_twap + min(clamp_upper_bound*s_twap,max(clamp_lower_bound*s_twap, (1 + delta_t * interest_rate)*s_twap-f_twap)) + ``` + + Where `f_twap` represents the internal mark price TWAP and `s_twap` represents the TWAP from the external oracle feed. When clamp bounds are large we use: + + ```book + funding_payment = f_twap - s_twap + (1 + delta_t * interest_rate)*s_twap-f_twap + = s_twap * delta_t * interest_rate + ``` + + - If `s_twap = 1600`, `delta_t = 0.002` and `interest_rate = 0.05` then `funding_payment = 1600 * 0.002 * 0.05 = 0.16`. + - Thus, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 9540 + 0.5 * 0.16 * 1 = 9540.08` (0019-MCAL-019) + + - If instead + - `clamp_upper_bound*s_twap < max(clamp_lower_bound*s_twap, (1 + delta_t * interest_rate)*s_twap-f_twap)` + - `funding payment = f_twap - s_twap + clamp_upper_bound*s_twap = f_twap + s_twap * (clamp_upper_bound - 1)`. + - Then with `s_twap = 1600`, `clamp_upper_bound = 0.05` and `f_twap = 1550`, `funding_payment = 1590 + 1600 * (0.05 - 1) = 1590 - 1520 = 70` + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 9540 + 0.5 * 70 * 1 = 9575` (0019-MCAL-020) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 9540 + 0.5 * max(0, 70 * -1) = 9540`(0019-MCAL-021) + + - If instead + - `clamp_upper_bound*s_twap > clamp_lower_bound*s_twap > (1 + delta_t * interest_rate)*s_twap-f_twap)` + - `funding payment = f_twap - s_twap + clamp_lower_bound*s_twap = f_twap + s_twap * (clamp_lower_bound - 1)`. + - Then with `s_twap = 1600`, `clamp_lower_bound = -0.05` and `f_twap = 1550`, `funding_payment = 1590 + 1600 * (-0.05 - 1) = 1590 - 1680 = -90` + - Thus, with `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 9540 + 0.5 * max(0, -90 * 1) = 9540` (0019-MCAL-022) + - However is position is instead `-1`, with the same margin requirement, if `margin funding factor = 0.5`, `total margin requirement = futures margin + funding margin = 9540 + 0.5 * max(0, -90 * -1) = 9585`(0019-MCAL-023) + ## Summary The *margin calculator* returns the set of relevant margin levels for a given position and entry price: diff --git a/protocol/features.json b/protocol/features.json index b39e9995c..16914a28b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -214,7 +214,12 @@ "0014-ORDT-120", "0014-ORDT-121", "0014-ORDT-122", - "0014-ORDT-123" + "0014-ORDT-123", + "0019-MCAL-019", + "0019-MCAL-020", + "0019-MCAL-021", + "0019-MCAL-022", + "0019-MCAL-023" ] }, From a8091d06bb64c25b93fd04b09d0be2a572c48e29 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 30 Aug 2023 12:22:50 +0100 Subject: [PATCH 527/649] fixed: removed one ac --- protocol/0044-LIME-lp_mechanics.md | 24 +++++++++++------------- protocol/features.json | 1 - 2 files changed, 11 insertions(+), 14 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 68ff4e611..0aa54476b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -294,7 +294,7 @@ Note: - GRPC (0044-LIME-057) - GRAPHQL (0044-LIME-058) - REST (0044-LIME-059) -- When a LP commits liquidity on market 1 and on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-068) +- When a LP commits liquidity on market 1, on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-068) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) @@ -306,7 +306,7 @@ Note: - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) and in the case of spot markets into the network treasury for the asset (0044-LIME-048) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their commitment and will not forfeit any of their bond stake. (0044-LIME-069) -- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. At the end of the next epoch, the LP will have their bond slashed. (0044-LIME-070) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch at the end of the next epoch, the LP will have their bond slashed. (0044-LIME-070) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) and in the case of spot markets into the network treasury for the asset (0044-LIME-046) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) @@ -342,29 +342,27 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in opening auction and LP has committed liquidity: - LP can increase their commitment and it will take effect immediately (0044-LIME-050). For spot (0044-LIME-054) - LP can decrease their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - - LP can cancel their commitment without incurring penalties (0044-LIME-053) + - Target stake is 0 so LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - For a market that is in continuous trading and LP has committed liquidity - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) - For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-071) -- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-081) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to market.liquidity.priceRange = 0.1 (10%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-072) +- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-078) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-072) -- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-074) +- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-074) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, while the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25. However, at the end of the epoch, the LP has not fulfilled their committed notional volume. (0044-LIME-075) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-075) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and a sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-076) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and sell price `5.25` (with sufficient volume), the LP is meeting their committed volume of notional (0044-LIME-076) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31` (which is is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`), the LP is not meeting their committed volume of notional. (0044-LIME-077) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31` (which is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`), the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-077) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.3`, the LP is not meeting their committed volume of notional (0044-LIME-078) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell price `5.25`, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty.. (0044-LIME-079) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell price `5.25`, the LP is not meeting their committed volume of notional. (0044-LIME-079) - -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`) the LP is not meeting their committed volume of notional. (0044-LIME-080) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`) the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-080) - For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) diff --git a/protocol/features.json b/protocol/features.json index fc82e0533..7e7dbd927 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -334,7 +334,6 @@ "0044-LIME-078", "0044-LIME-079", "0044-LIME-080", - "0044-LIME-081", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From b265cbe3e8cba6053bf704a0b8a17f030565d1d1 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:56:09 +0100 Subject: [PATCH 528/649] fix: ac numbers --- protocol/0044-LIME-lp_mechanics.md | 36 +++++++++++++++--------------- protocol/features.json | 28 +++++++++++++++-------- 2 files changed, 37 insertions(+), 27 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 3d490746b..6ca2028d4 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -294,7 +294,7 @@ Note: - GRPC (0044-LIME-057) - GRAPHQL (0044-LIME-058) - REST (0044-LIME-059) -- When a LP commits liquidity on market 1, on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-068) +- When a LP commits liquidity on market 1, on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-087) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) @@ -305,8 +305,8 @@ Note: - If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.commitmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) and in the case of spot markets into the network treasury for the asset (0044-LIME-048) -- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their commitment and will not forfeit any of their bond stake. (0044-LIME-069) -- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch at the end of the next epoch, the LP will have their bond slashed. (0044-LIME-070) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their commitment and will not forfeit any of their bond stake. (0044-LIME-088) +- If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch at the end of the next epoch, the LP will have their bond slashed. (0044-LIME-089) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) and in the case of spot markets into the network treasury for the asset (0044-LIME-046) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) @@ -348,23 +348,23 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in continuous trading and LP has committed liquidity - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) -- For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-071) -- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-078) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-072) +- For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-090) +- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-097) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) -- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-074) +- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-075) +- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-094) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and sell price `5.25` (with sufficient volume), the LP is meeting their committed volume of notional (0044-LIME-076) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and sell price `5.25` (with sufficient volume), the LP is meeting their committed volume of notional (0044-LIME-095) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31` (which is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`), the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-077) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31` (which is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`), the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-096) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell price `5.25`, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty.. (0044-LIME-079) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell price `5.25`, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty.. (0044-LIME-098) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`) the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-080) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`) the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-099) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-073) +- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-092) - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063) for spot (0044-LIME-064) - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) @@ -407,13 +407,13 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) - - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` default value of `60m` (0044-LIME-063) + - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` default value of `60m` (0044-LIME-100) #### Market parameters validation - Boundary values are respected for the market parameters - - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-064) - - `market.liquidity.priceRange` valid values: `>0`, `<=100` (0044-LIME-065) - - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-066) - - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-067) + - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-083) + - `market.liquidity.priceRange` valid values: `>0`, `<=100` (0044-LIME-084) + - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-085) + - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-086) diff --git a/protocol/features.json b/protocol/features.json index a802fd325..ba15ef415 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -339,16 +339,26 @@ "0044-LIME-078", "0044-LIME-079", "0044-LIME-080", - "0044-LIME-063", - "0044-LIME-065", - "0044-LIME-067", - "0044-LIME-069", - "0044-LIME-071", - "0044-LIME-073", - "0044-LIME-075", - "0044-LIME-077", - "0044-LIME-079", "0044-LIME-081", + "0044-LIME-082", + "0044-LIME-083", + "0044-LIME-084", + "0044-LIME-085", + "0044-LIME-086", + "0044-LIME-087", + "0044-LIME-088", + "0044-LIME-089", + "0044-LIME-090", + "0044-LIME-091", + "0044-LIME-092", + "0044-LIME-093", + "0044-LIME-094", + "0044-LIME-095", + "0044-LIME-096", + "0044-LIME-097", + "0044-LIME-098", + "0044-LIME-099", + "0044-LIME-100", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From d7e69fcb862b6de489187994e2a19bd0a81ce1eb Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:59:30 +0100 Subject: [PATCH 529/649] fix: add quote --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 6ca2028d4..4b7b6f93e 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -352,7 +352,7 @@ In the case of spot markets it will be transferred into the network treasury for - If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-097) - In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) -- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to market.liquidity.priceRange = 0.01 (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) +- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to `market.liquidity.priceRange = 0.01` (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) - In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-094) From 4bd1d2a8667f15034e154a77552f656882b8f53e Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Thu, 31 Aug 2023 14:49:53 +0100 Subject: [PATCH 530/649] Update 0044-LIME-lp_mechanics.md (#1918) SLA remove 0044-LIME-010 --- protocol/0044-LIME-lp_mechanics.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 5e83867cb..99e93bdf7 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -296,7 +296,6 @@ Note: - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) - Check that bond slashing works with non-default asset decimals, market decimals, position decimals. This can be done by following a similar story to [bond slashing feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature). Should test at least three different combinations, each decimal settings different to each other. (0044-LIME-009) -- Change of `market.liquidity.stakeToCcyVolume` will change the liquidity obligation hence change the size of the LP orders on the order book. (0044-LIME-010) - If `market.liquidity.stakeToCcyVolume` is set to `0.0`, there is [target stake](./0041-TSTK-target_stake.md) of `1000` and there are 3 LPs on the market with stake / fee bid submissions of `100, 0.01`, `1000, 0.02` and `200, 0.03` then the liquidity fee is `0.02`. (0044-LIME-012) - If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.committmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) From f5f7cd3fe84f1732005ae871297379d7910742a7 Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 31 Aug 2023 16:00:41 +0100 Subject: [PATCH 531/649] chore: Delete incorrect acceptance criteria relating to perps and market termination --- protocol/0082-ETHD-ethereum-data-source.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index cd65db701..3d7fef074 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -181,7 +181,6 @@ Select { 1. Have a network running with a couple of futures markets with a mix of internal, external, open and ethereum oracles. Perform a protocol upgrade. Once the network is up , the state of the various data sources should be the same as before the protocol upgrade (0082-ETHD-043) 2. Have a network running with a couple of perpetual markets with a mix of internal, external, open and ethereum oracles. Perform a protocol upgrade. Once the network is up , the state of the various data sources should be the same as before the protocol upgrade (0082-ETHD-044) 3. Create a futures market with an ethereum oracle for termination such that it polls at a specific time. Perform a protocol upgrade such that the termination triggers in the middle of the protocol upgrade. Once the network is up , the termination should be triggered and the market should be terminated. (0082-ETHD-045) -4. Create a perpetual market with an ethereum oracle for termination such that it polls at a specific time. Perform a protocol upgrade such that the termination triggers in the middle of the protocol upgrade. Once the network is up , the termination should be triggered and the market should be terminated. (0082-ETHD-046) -5. Create a futures market with an ethereum oracle for settlement such that it polls at a specific time. Perform a protocol upgrade such that the settlement price matching the filters is triggered in the middle of the protocol upgrade. Once the network is up , the settlement should be triggered and the market should be terminated. (0082-ETHD-047) -6. Create a perpetual market with an ethereum oracle for settlement such that it polls at a specific time. Perform a protocol upgrade such that the settlement price matching the filters is triggered in the middle of the protocol upgrade. Once the network is up , the settlement should be triggered and the market should be terminated. (0082-ETHD-048) -7. Ensure that markets with ethereum termination and settlement data sources continue to successfully terminate and settle markets after the protocol upgrade. (0082-ETHD-049) +4. Create a futures market with an ethereum oracle for settlement such that it polls at a specific time. Perform a protocol upgrade such that the settlement price matching the filters is triggered in the middle of the protocol upgrade. Once the network is up , the settlement should be triggered and the market should be terminated. (0082-ETHD-047) +5. Create a perpetual market with an ethereum oracle for settlement such that it polls at a specific time. Perform a protocol upgrade such that the settlement price matching the filters is triggered in the middle of the protocol upgrade. Once the network is up , the settlement should be triggered and the market should be terminated. (0082-ETHD-048) +6. Ensure that markets with ethereum termination and settlement data sources continue to successfully terminate and settle markets after the protocol upgrade. (0082-ETHD-049) From 3cb26029959469f5b3fba8607e65a4ba1a9b784a Mon Sep 17 00:00:00 2001 From: MuthuVega Date: Thu, 31 Aug 2023 16:16:30 +0100 Subject: [PATCH 532/649] chore: Update features.json to reflect removed ac --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 16914a28b..44933dd05 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -261,7 +261,6 @@ "0082-ETHD-043", "0082-ETHD-044", "0082-ETHD-045", - "0082-ETHD-046", "0082-ETHD-047", "0082-ETHD-048", "0082-ETHD-049" From e4abb76191d63d6682aa3e22a358bbff0893006f Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 31 Aug 2023 16:31:13 +0100 Subject: [PATCH 533/649] feat: update ACs in 0034 --- protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index 890a8ef38..45e0411dc 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -88,11 +88,11 @@ "\n", "Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) The feature test has covered following scenarios:\n", "\n", - "1. Order from liquidity provision and from normal order submission are correctly cumulated in order book's total size(0034-PROB-001). For product spot: (0034-PROB-007);\n", + "1. Orders are correctly cumulated in order book's total size(0034-PROB-001). For product spot: (0034-PROB-007);\n", "\n", "2. Probability of trading decreases away from the mid-price (0034-PROB-005). For product spot: (0034-PROB-008).\n", "\n", - "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter for $\\tau$, hence will change the probability of trading in LP orders. (0034-PROB-006). For product spot: (0034-PROB-009).\n", + "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter, hence will change the probability of trading used for comparing quality of committed liquidity. (0034-PROB-006). For product spot: (0034-PROB-009).\n", "\n", "\n", "\n" From 0e51b73ffeb2333bfd6699a8c5e0eecf17244350 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 31 Aug 2023 16:35:37 +0100 Subject: [PATCH 534/649] feat: update AC code --- protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index 45e0411dc..69ad2b8db 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -88,11 +88,11 @@ "\n", "Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) The feature test has covered following scenarios:\n", "\n", - "1. Orders are correctly cumulated in order book's total size(0034-PROB-001). For product spot: (0034-PROB-007);\n", + "1. Orders are correctly cumulated in order book's total size(0034-PROB-002). For product spot: (0034-PROB-003);\n", "\n", "2. Probability of trading decreases away from the mid-price (0034-PROB-005). For product spot: (0034-PROB-008).\n", "\n", - "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter, hence will change the probability of trading used for comparing quality of committed liquidity. (0034-PROB-006). For product spot: (0034-PROB-009).\n", + "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter, hence will change the probability of trading used for comparing quality of committed liquidity. (0034-PROB-004). For product spot: (0034-PROB-010).\n", "\n", "\n", "\n" From 492c9d0a2a01ed63087db049dce6f5d8cfd1dfc0 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Mon, 4 Sep 2023 12:23:49 +0100 Subject: [PATCH 535/649] fix: appprobation from pr#1921 --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index ba15ef415..5859a8e43 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -706,9 +706,9 @@ "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", - "0034-PROB-007", + "0034-PROB-003", "0034-PROB-008", - "0034-PROB-009", + "0034-PROB-010", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", From 1fb5abff1db8b024d9bb476fc11b1e3fe1f0bafd Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 5 Sep 2023 11:34:21 +0100 Subject: [PATCH 536/649] fix: features.json for PR 1921 (#1924) Updates the features.json as pt2 of #1921 . --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 44933dd05..c8df3fbc2 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -674,9 +674,9 @@ "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", - "0034-PROB-007", + "0034-PROB-002", "0034-PROB-008", - "0034-PROB-009", + "0034-PROB-010", "0039-MKTD-020", "0039-MKTD-021", "0039-MKTD-022", From f409041dec03016e5368d7e96ecce5a7ae7081f5 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 5 Sep 2023 14:27:11 +0100 Subject: [PATCH 537/649] Update 0044-LIME-lp_mechanics.md (#1925) --- protocol/0044-LIME-lp_mechanics.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 99e93bdf7..f38a1c25f 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -334,25 +334,25 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - - LP can increase their commitment and it will take affect immediately (0044-LIME-050) for spot (0044-LIME-054) - - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051) for spot (0044-LIME-055) + - LP can increase their commitment and it will take affect immediately (0044-LIME-050). For spot (0044-LIME-054) + - LP can decrease their commitment and it will take affect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063) for spot (0044-LIME-064) - - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065) for spot (0044-LIME-066) - - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067) for spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) - - When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069) for spot (0044-LIME-070) - - When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071) for spot (0044-LIME-072) - - A distressed LP (when `bond account == 0 && general account == 0 && margin account < maintenance margin`) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073) for spot (0044-LIME-074) - - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075) for spot (0044-LIME-076) + - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060). For spot (0044-LIME-056) + - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063). For spot (0044-LIME-064) + - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065). For spot (0044-LIME-066) + - When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067). For spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) + - When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069). For spot (0044-LIME-070) + - When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071). For spot (0044-LIME-072) + - A distressed LP (when `bond account == 0 && general account == 0 && margin account < maintenance margin`) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073). For spot (0044-LIME-074) + - If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075). For spot (0044-LIME-076) ### Qualifying Order Types -- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028) for spot (0044-LIME-029) -- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077) for spot (0044-LIME-078) -- GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079) for spot (0044-LIME-080) -- GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081) for spot (0044-LIME-082) +- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028). For spot (0044-LIME-029) +- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077). For spot (0044-LIME-078) +- GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079). For spot (0044-LIME-080) +- GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081). For spot (0044-LIME-082) ### Snapshot From f848c41a4289f0f1cbc4ef5cddf085206c7df5bd Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 1 Sep 2023 11:02:09 +0200 Subject: [PATCH 538/649] refactor: bring specs in line with implementation --- glossaries/trading-and-protocol-glossary.md | 4 ++- protocol/0002-STTL-settlement.md | 10 +++---- .../0003-MTMK-mark_to_market_settlement.md | 2 +- protocol/0005-COLL-collateral.md | 2 +- protocol/0012-POSR-position_resolution.md | 6 ++-- protocol/0013-ACCT-accounts.md | 8 +++--- ...5-INSR-market_insurance_pool_collateral.md | 19 ++++++++----- protocol/0028-GOVE-governance.md | 28 ++++++++++++++----- protocol/0029-FEES-fees.md | 2 +- protocol/0043-MKTL-market_lifecycle.md | 10 +++---- protocol/0044-LIME-lp_mechanics.md | 2 +- protocol/0050-EPOC-epochs.md | 6 ++-- ...3-PERP-product_builtin_perpetual_future.md | 2 +- protocol/0055-TREA-on_chain_treasury.md | 12 ++++---- protocol/0056-REWA-rewards_overview.md | 15 ++++++++-- protocol/0061-REWP-pos_rewards.md | 12 ++------ protocol/0073-LIMN-limited_network_life.md | 10 +++---- protocol/0081-SUCM-successor_markets.md | 4 +-- protocol/README.md | 3 +- protocol/features.json | 11 ++++++-- 20 files changed, 98 insertions(+), 70 deletions(-) diff --git a/glossaries/trading-and-protocol-glossary.md b/glossaries/trading-and-protocol-glossary.md index 8c587200b..ca143777e 100644 --- a/glossaries/trading-and-protocol-glossary.md +++ b/glossaries/trading-and-protocol-glossary.md @@ -175,7 +175,9 @@ Parameters: ### Insurance Pool -A store of capital instantiated with the order book into which fines are contributed. It is utilised for financially covering [close out trades](#close-out-trades). +[Market insurance pool](../protocol/0015-INSR-market_insurance_pool_collateral.md#market-insurance-pool): a store of capital instantiated with the order book into which fines are contributed. It is utilised for financially covering [close out trades](#close-out-trades). + +[Global insurance pool](../protocol/0015-INSR-market_insurance_pool_collateral.md#global-insurance-pool): an insurance pool per given asset, not associated with any market. It receives part of remaining funds from insurance pool of the market using the same settlement asset. Funds can be transferred out of the global insurance pool using a governance initiated [transfer](../protocol/0028-GOVE-governance.md). ## L diff --git a/protocol/0002-STTL-settlement.md b/protocol/0002-STTL-settlement.md index c1f43de23..fc6458f63 100644 --- a/protocol/0002-STTL-settlement.md +++ b/protocol/0002-STTL-settlement.md @@ -39,7 +39,7 @@ If all requested amounts are successfully transferred to the *market settlement #### Loss socialisation -If some of the collection transfers are not able to supply the full amount to the *market settlement account* due to some traders having insufficient collateral in their margin account and general account to handle the price / position (mark to market) move, and if the insurance pool can't cover the shortfall for some of these, then not enough funds will have been collected to distribute the full amount of the mark to market gains made by traders on the other side. Therefore, settlement needs to decide how to fairly distribute the funds that have been collected. This is called *loss socialisation*. +If some of the collection transfers are not able to supply the full amount to the *market settlement account* due to some traders having insufficient collateral in their margin account and general account to handle the price / position (mark to market) move, and if the market's insurance pool can't cover the shortfall for some of these, then not enough funds will have been collected to distribute the full amount of the mark to market gains made by traders on the other side. Therefore, settlement needs to decide how to fairly distribute the funds that have been collected. This is called *loss socialisation*. In future, a more sophisticated algorithm may be used for this (perhaps taking into account a trader's overall profit on their positions, for example) but initially this will be implemented by reducing the amount to distribute to each trader with an MTM gain pro-rata by relative position size: @@ -50,7 +50,7 @@ distribute_amount[trader] = mtm_gain[trader] * ( actual_collected_amount / targe ### Network orders -When a trader is distressed their position is closed out by the network placing an order to bring their position back to 0. This [network order](../protocol/0014-ORDT-order_types.md) will match against normal orders in the order book and will be part of a [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md) action. As [the network user is a virtual user](./0017-PART-party.md#network-party) it does not have collateral accounts from which to provide or collect wins and loses. The [market insurance account](./0015-INSR-market_insurance_pool_collateral.md) is used in place of these. If a network order is settled as a win, the collateral will be transferred from the matched trader directly into the insurance account for the market. If the network order is a loss, the insurance pool will be used to pay the matched traders. [Loss socialisation](#loss-socialisation) is used if the insurance pool does not have enough collateral to cover the loss situation. +When a trader is distressed their position is closed out by the network placing an order to bring their position back to 0. This [network order](../protocol/0014-ORDT-order_types.md) will match against normal orders in the order book and will be part of a [mark-to-market settlement](./0003-MTMK-mark_to_market_settlement.md) action. As [the network user is a virtual user](./0017-PART-party.md#network-party) it does not have collateral accounts from which to provide or collect wins and loses. The [market insurance account](./0015-INSR-market_insurance_pool_collateral.md) is used in place of these. If a network order is settled as a win, the collateral will be transferred from the matched trader directly into the insurance account for the market. If the network order is a loss, the market's insurance pool will be used to pay the matched traders. [Loss socialisation](#loss-socialisation) is used if the market's insurance pool does not have enough collateral to cover the loss situation. ## Settlement at instrument expiry @@ -79,7 +79,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. Any remaining balances in parties' margin and LP bond accounts are moved to their general account. 1. The margin accounts and LP bond accounts for these markets are no longer required. 1. Positions can be left as open, or set to zero (this isn't important for the protocol but should be made clear on the API either way). -1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. 1. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (0002-STTL-003) @@ -95,7 +95,7 @@ The [market lifecycle spec](./0043-MKTL-market_lifecycle.md) provides detail on 1. Any remaining balances in parties' margin and LP bond accounts are moved to their general account. 1. The margin accounts and LP bond accounts for these markets are no longer required. 1. Positions can be left as open, or set to zero (this isn't important for the protocol but should be made clear on the API either way). -1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. 1. This mechanism does not incur fees to traders that have open positions that are settled at expiry. (0002-STTL-005) @@ -124,6 +124,6 @@ All of that happens while processing the trading terminated transaction. 1. Any remaining balances in parties' margin and LP bond accounts are moved to their general account. 1. The margin accounts and LP bond accounts for these markets are no longer required. 1. Positions can be left as open, or set to zero (this isn't important for the protocol but should be made clear on the API either way). -1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +1. The market's insurance pool is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. 1. Market status is now set to [SETTLED](./0043-MKTL-market_lifecycle.md). 1. Now the market can be deleted. diff --git a/protocol/0003-MTMK-mark_to_market_settlement.md b/protocol/0003-MTMK-mark_to_market_settlement.md index 950c9068b..7b7355f2b 100644 --- a/protocol/0003-MTMK-mark_to_market_settlement.md +++ b/protocol/0003-MTMK-mark_to_market_settlement.md @@ -69,7 +69,7 @@ SETTLEMENT_AMT( party ) = PDPscaling x party.PREV_OPEN_VOLUME x (product.value( 1. The settlement function calculates how much to *collect* from the margin accounts of those whose change in mark to market has been negative / incurred loss. This will be collected into the market's *margin* account via a set of transfer requests. The collection instruction should first collect from a trader's margin account for the market and then the trader's general account and then the market's insurance pool. 1. This will result in ledger entries being formulated ( see [settlement](./0002-STTL-settlement.md) ) which adhere to double entry accounting and record the actual transfers that occurred on the ledger. 1. If the net amounts are what was requested, the settlement function will formulate instructions to *distribute* to the margin accounts of those whose moves have been positive according to the amount they are owed. These transfers will be requested to debit from the market's *margin* account and credit the traders who have a positive mark-to-market. -1. If there's not enough money for the reallocation due to some traders having insufficient money in their margin account and general account to handle the price / position move, and if the insurance pool can't cover the full *distribute* requirements, the settlement function will need to alter the "distribute" amounts accordingly. The amounts are altered using a formula which is out of scope for this ticket. As a stub implementation distribution can pro-rata the amount in the settlement account between positions by relative position size. +1. If there's not enough money for the reallocation due to some traders having insufficient money in their margin account and general account to handle the price / position move, and if the market's insurance pool can't cover the full *distribute* requirements, the settlement function will need to alter the "distribute" amounts accordingly. The amounts are altered using a formula which is out of scope for this ticket. As a stub implementation distribution can pro-rata the amount in the settlement account between positions by relative position size. Note: a close out profit / loss is automatically captured in trader margin accounts via mark-to-market reallocation described above. The reduction in open volume will be used when risk margins are next calculated. diff --git a/protocol/0005-COLL-collateral.md b/protocol/0005-COLL-collateral.md index eb771c24c..c0cd35005 100644 --- a/protocol/0005-COLL-collateral.md +++ b/protocol/0005-COLL-collateral.md @@ -34,7 +34,7 @@ Data Structures ```json TransferRequest { - from: [Account], // This is an array of accounts in order of precedence, e.g. the first account in the list is emptied first when making transfers. For settlement at expiry scenarios, transferRequests will be sequenced to access 1. the trader's margin account for the Market, 2. the trader's collateral account and 3. the insurance pool. + from: [Account], // This is an array of accounts in order of precedence, e.g. the first account in the list is emptied first when making transfers. For settlement at expiry scenarios, transferRequests will be sequenced to access 1. the trader's margin account for the Market, 2. the trader's collateral account and 3. the market's insurance pool. to: Account, amount: FinancialAmount, reference: ???, // some way to link back to the causal event that created this transfer diff --git a/protocol/0012-POSR-position_resolution.md b/protocol/0012-POSR-position_resolution.md index 35b2028c7..6c69b452c 100644 --- a/protocol/0012-POSR-position_resolution.md +++ b/protocol/0012-POSR-position_resolution.md @@ -26,11 +26,11 @@ See [Whitepaper](https://vega.xyz/papers/vega-protocol-whitepaper.pdf), Section 1. A "distressed trader" has all their open orders on that market cancelled. Note, the network must then recalculate their margin requirement on their remaining open position and if they now have sufficient collateral (i.e. aren't in the close out zone) they are no longer considered a distressed trader and not subject to position resolution. The market may at any point in time have multiple distressed traders that require position resolution. They are 'resolved' together in a batch. 1. The batch of distressed open positions that require position resolution may be comprised of a collection of long and short positions. The network calculates the overall net long or short position. This tells the network how much volume (either long or short) needs to be sourced from the order book. For example, if there are 3 distressed traders with +5, -4 and +2 positions respectively. Then the net outstanding liability is +3. If this is a non-zero number, do Step 3. -1. This net outstanding liability is sourced from the market's order book via a single market order (in above example, that would be a market order to sell 3 on the order book) executed by the network as a counterpart. This internal entity is the counterpart of all trades that result from this single market order and now has a position which is comprised of a set of trades that transacted with the non-distressed traders on the order book. Note, the network's order should not incur a margin liability. Also, these new positions (including that incurred by the network) will need to be "MTM settled". This should happen after Step 5 to ensure we don't bankrupt the insurance pool before collecting the distressed trader's collateral. This has been included as Step 6. +1. This net outstanding liability is sourced from the market's order book via a single market order (in above example, that would be a market order to sell 3 on the order book) executed by the network as a counterpart. This internal entity is the counterpart of all trades that result from this single market order and now has a position which is comprised of a set of trades that transacted with the non-distressed traders on the order book. Note, the network's order should not incur a margin liability. Also, these new positions (including that incurred by the network) will need to be "MTM settled". This should happen after Step 5 to ensure we don't bankrupt the market's insurance pool before collecting the distressed trader's collateral. This has been included as Step 6. 1. The network then generates a set of trades with all the distressed traders all at the volume weighted average price of the network's (new) open position. These trades should be readily distinguished from the trades executed by the network counterpart in Step 3 (suggest by a flag on the trades) 1. Note, If there was no market order (i.e step 3 didn't happen) the close-out price is the most recently calculated _Mark Price_. See Scenario 1 below for the list of resulting trades for the above example. The open positions of all the "distressed" traders is now zero and the networks position is also zero. Note, no updates to the _Mark Price_ should happen as a result of any of these trades (as this would result in a new market-wide mark to market settlement at this new price and potentially lead to cascade close outs). 1. All bankrupt trader's remaining collateral in their margin account for this market is confiscated to the market's insurance pool. -1. If an order was executed on the market (in Step 3), the resulting trade volume between the network and passive orders must be mark-to-market settled for all parties involved including the network's internal 'virtual' party. As the network's closeout counterparty doesn't have collateral, any funds it 'owes' will be transferred from the insurance fund during this settlement process (as defined in the [settlement spec](./0003-MTMK-mark_to_market_settlement.md).). It's worth noting that the network close-out party must never have margins calculated for it. This also should naturally happen because no margin calculations would happen during the period that the network temporarily (instantaneously) has an open position, as the entire position resolution process must happen atomically. +1. If an order was executed on the market (in Step 3), the resulting trade volume between the network and passive orders must be mark-to-market settled for all parties involved including the network's internal 'virtual' party. As the network's closeout counterparty doesn't have collateral, any funds it 'owes' will be transferred from the market's insurance fund during this settlement process (as defined in the [settlement spec](./0003-MTMK-mark_to_market_settlement.md).). It's worth noting that the network close-out party must never have margins calculated for it. This also should naturally happen because no margin calculations would happen during the period that the network temporarily (instantaneously) has an open position, as the entire position resolution process must happen atomically. ### Note @@ -124,7 +124,7 @@ This results in the open position sizes for all distressed traders and the netwo #### STEP 5 -The collateral from distressed traders is moved to the insurance pool +The collateral from distressed traders is moved to the market's insurance pool ```json // sent by Settlement Engine to the Collateral Engine diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 9e0f03b63..f773b1528 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -17,11 +17,11 @@ Note that a party can also associate the governance / staking asset via the [Veg 1. Mark-to-market settlement account per market: this is used for collecting and distributing mark-to-market settlement cashflows and is *zero* at the end of each mark-to-market settlement run. 1. Margin accounts for each party with open orders or positions on any [market](./0043-MKTL-market_lifecycle.md). 1. Bond account for any party that's an [LP on any market](0044-LIME-lp_mechanics_type.md). -1. [Insurance pool account](0015-INSR-market_insurance_pool_collateral.md) for any market. +1. [Global insurance pool](0015-INSR-market_insurance_pool_collateral.md#global-insurance-pool) (1 per asset) +1. [Insurance pool account](0015-INSR-market_insurance_pool_collateral.md#market-insurance-pool) for any market. 1. [Liquidity fee pool](0042-LIQF-setting_fees_and_rewarding_lps.md) for any market. 1. [Infrastructure fee pool](0029-FEES-fees.md) for any asset. -1. [Reward accounts](0056-REWA-rewards_overview.md) which exist for *each* reward account per every Vega asset (settlement asset) and per every reward metric per every Vega asset (reward asset). There is an additional [staking rewards](0061-REWP-pos_rewards.md) account. -1. [Vega trasury accounts](0055-TREA-on_chain_treasury.md) per Vega asset. +1. [Reward accounts](0056-REWA-rewards_overview.md) which exist for *each* reward account per every Vega asset (settlement asset) and per every reward metric per every Vega asset (reward asset). There is an additional [global rewards account](0056-REWA-rewards_overview.md#validator-ranking-metric) used for supplementary (on top of infrastructure fee split) validator rewards. One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. @@ -130,7 +130,7 @@ Note that it *is* possible to have markets in the governance asset, in which cas - When a market opens for trading, there is an insurance account that is able to be used by that market for every settlement asset of that market. (0013-ACCT-020) - Only protocol-initiated aka internal transfer requests move money in or out of the insurance account. User initiated transfer requests cannot be used to move funds in or out of insurance pool. (0013-ACCT-021) -- When all markets of a risk universe expire and/or are closed, the insurance pool account has its outstanding funds redistributed to the [network treasury](./0055-TREA-on_chain_treasury.md) account for the appropriate asset (if it doesn't exist create it) and other insurance pools using the same asset. (0013-ACCT-022) +- When all markets of a risk universe expire and/or are closed, the insurance pool account has its outstanding funds redistributed to the global insurance pool account for the appropriate asset (if it doesn't exist create it) and other insurance pools using the same asset. (0013-ACCT-032) ### Special case: Staking accounts diff --git a/protocol/0015-INSR-market_insurance_pool_collateral.md b/protocol/0015-INSR-market_insurance_pool_collateral.md index 0531ab811..be3dee548 100644 --- a/protocol/0015-INSR-market_insurance_pool_collateral.md +++ b/protocol/0015-INSR-market_insurance_pool_collateral.md @@ -1,23 +1,28 @@ -# Market insurance pool +# Insurance pools -## Summary +## Market insurance pool Every market will have at least one insurance pool account that holds collateral that can be used to cover losses in case of unreasonable market events. -## Guide-level explanation - -## Reference-level explanation - Every [tradable instrument](./0001-MKTF-market_framework.md) has one or more settlement assets defined for that market. The market requires an insurance pool account for every settlement asset of the market. If no insurance pool account already exists in the risk universe that the tradable instrument sits within, then an insurance pool account needs to be created for all settlement assets of the market. These new insurance pool accounts will be instantiated in the settlement asset/s of the market, with a balance of zero (across all assets). -Only transfer requests can move collateral to or from the insurance account. +Only transfer requests can move collateral to or from the market's insurance account. When a market is finalised / closed remaining funds are distributed equally among other same-currency insurance pools (including the on-chain treasury for the asset, if no such treasury exists it gets created at this point). This occurs using ledger entries to preserve double entry accounting records within the collateral engine. +## Global insurance pool + +One global insurance pool per each of the settlement asset in which markets were terminated with remaining market-level insurance pool funds exists. It receives a portion of the funds from market's insurance pool upon its closure (funds get distributed equally between the global insurance pool and remaining active markets using the same settlement asset, e.g. if there are 4 such markets then the global insurance pool receives 1/5 of the funds). + +Global insurance pool is not included in the margin search process when party is insolvent - only the insurance pool of the market in which the insolvent party's liabilities are considered gets searched, if funds therein are insufficient then the remaining shortfall gets dealt with using loss socialisation. + +Funds can only be withdrawn from the global insurance pool via a [governance initiated transfer](./0028-GOVE-governance.md). + ## Acceptance Criteria - When a market proposal gets accepted and the opening auction commences, there is an insurance account that is available for use by that market for the settlement asset of that market and its balance is zero. (0015-INSR-001) - After the market enters transitions from "trading terminated state" to "settled" state (see [market lifecyle](0043-MKTL-market_lifecycle.md)), and `market.liquidity.successorLaunchWindowLength` has elapsed from the settlement time, the insurance pool account has its balance[redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. (0015-INSR-002) - The [insurance pool feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/0015-INSR-insurance_pool_balance_test.feature) is passing. (0015-INSR-003) +- When global insurance pool has positive balance for the settlement asset used by market with insolvent party, and that market's insurance pool has insufficient balance to cover the shortfall, the global insurance pool balance does NOT get used and the remaining balances are dealt with using the loss socialisation mechanism. (0015-INSR-004) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index cbe799464..ce85431a8 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -19,11 +19,13 @@ Governance actions can be the end result of a passed proposal. The allowable typ The types of governance action are: 1. Create a new market -2. Change an existing market's parameters -3. Change network parameters -4. Add an external asset to Vega (covered in a [separate spec - see 0027](./0027-ASSP-asset_proposal.md)) -5. Authorise a transfer to or from the [Network Treasury](./0055-TREA-on_chain_treasury.md) -6. Freeform proposals +1. Change an existing market's parameters +1. Change network parameters +1. Add an external asset to Vega (covered in a [separate spec - see 0027](./0027-ASSP-asset_proposal.md)) +1. Authorise a transfer to or from the [Network Treasury](./0055-TREA-on_chain_treasury.md) +1. Authorise a transfer to or from the [global insurance pool](./0015-INSR-market_insurance_pool_collateral.md#global-insurance-pool) +1. Authorise a transfer to or from the [market insurance pool](./0015-INSR-market_insurance_pool_collateral.md#market-insurance-pool) +1. Freeform proposals ### Lifecycle of a proposal @@ -281,23 +283,31 @@ The below table shows the allowable combinations of source and destination accou | Network treasury | Network treasury | No | | Network treasury | Party general account(s) | Yes | | Network treasury | Party other account types | No | +| Network treasury | Global insurance pool account | Yes | | Network treasury | Market insurance pool account | Yes | | Network treasury | Reward account | Yes | | Network treasury | Any other account | No | | Market insurance pool account | Party account(s) | Yes | | Market insurance pool account | Network treasury | Yes | +| Market insurance pool account | Global insurance pool account | Yes | | Market insurance pool account | Market insurance pool account | Yes | | Market insurance pool account | Reward account | Yes | | Market insurance pool account | Any other account | No | +| Global insurance pool account | Party account(s) | Yes | +| Global insurance pool account | Network treasury | Yes | +| Global insurance pool account | Market insurance pool account | Yes | +| Global insurance pool account | Reward account | Yes | +| Global insurance pool account | Any other account | No | | Any other account | Any | No | ### Transfer proposal details The proposal specifies: -- `source_type`: the source account type (i.e. network treasury, market insurance pool) +- `source_type`: the source account type (i.e. network treasury, global insurance pool, market insurance pool) - `source` specifies the account to transfer from, depending on the account type: - network treasury: leave blank (only one per asset) + - global insurance pool: leave blank (only one per asset) - market insurance pool: market ID - `type`, which can be either "all or nothing" or "best effort": - all or nothing: either transfers the specified amount or does not transfer anything @@ -309,6 +319,7 @@ The proposal specifies: - `destination` specifies the account to transfer to, depending on the account type: - network treasury: leave blank (only one per asset) - party: the party's public key + - global insurance pool: leave blank (only one per asset) - market insurance pool: market ID - A proposal can be for a one off transfer or recurring. - If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. @@ -604,7 +615,10 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo - The proposal will allow standard proposal fields to control timings on closing the voting period and enactment time, these will be validated in the same way as other proposals (0028-GOVE-092) - For successor markets we allow transfer between Market insurance pool account of parent market to Market insurance pool account of child market (0028-GOVE-093) - During a recurring transfer ensure that the correct tokens continue to be distributed when the source account is funded (0028-GOVE-154) - +- A proposal to transfer tokens between Network treasury and global insurance pool account is valid (0028-GOVE-155) +- A proposal to transfer tokens between global insurance pool account and Party account(s) is valid (0028-GOVE-156) +- A proposal to transfer tokens between global insurance pool account and Network treasury is valid (0028-GOVE-157) +- A proposal to transfer tokens between global insurance pool account and Market insurance pool account is valid (0028-GOVE-158) ##### Governance initiated transfer enactment diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 5f54c466b..8ed578d9b 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -132,7 +132,7 @@ Order that entered the book in the current batch are considered aggressive order The trades that were netted off against each other during position resolution incur no fees. During position resolution all of the parties being liquidated share the total fee for the network order, pro-rated by the size of position. -As for fees in other cases, the fee is taken out of the general + margin account for the liable traders (the insurance pool is not used to top up fees that cannot be paid). If the general + margin account is insufficient to cover the fee then the fee (or part of it) is not going to get paid. In this case we first pay out the maker_fee (or as much as possible), then then infrastructure_fee (or as much as possible) and finally the liquidity_fee. +As for fees in other cases, the fee is taken out of the general + margin account for the liable traders (the market's insurance pool is not used to top up fees that cannot be paid). If the general + margin account is insufficient to cover the fee then the fee (or part of it) is not going to get paid. In this case we first pay out the maker_fee (or as much as possible), then then infrastructure_fee (or as much as possible) and finally the liquidity_fee. ### Rounding diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index a1b16959d..20b01f8fb 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -107,7 +107,7 @@ Auction period ends when any of the following occur: ### Cancelled A market becomes Cancelled when a Market Proposal is successful and conditions are not met to transition the Market to the Active state during the Pending period, and the trading terminated data source input is triggered, see [data sourcing](./0045-DSRC-data_sourcing.md). -When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset. After `market.liquidity.successorLaunchWindowLength` has elapsed since cancellation any insurance pool balance should be transferred into the network treasury account for that asset. +When a market transitions to a cancelled state all orders should be cancelled and collateral returned to respective parties general account for the relevant asset, all LP commitments should be cancelled and their bond returned to the general account for the relevant asset. After `market.liquidity.successorLaunchWindowLength` has elapsed since cancellation any insurance pool balance should get [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. Once "cancelled" there must be no open positions tracked by the protocol for the market and any open positions must have been closed including returning all margin and other related collateral if necessary and also notifying downstream event consumers that the positions are closed. Specific position related actions may be unnecessary if the cancelled state is being entered from a state in which there cannot possibly have been any open positions. All data sources that are only referenced by this market should be unregistered. @@ -219,7 +219,7 @@ All money held in margin accounts after final settlement is returned to traders' [LP fees](0042-LIQF-setting_fees_and_rewarding_lps.md) that have been cumulated but not yet paid out are distributed to the market LPs as per the LP spec. After `market.liquidity.successorLaunchWindowLength` has elapsed since the settlement time -- [Insurance pool funds](./0015-INSR-market_insurance_pool_collateral.md) are transferred to the on-chain treasury for the asset for markets that have no successor market, see [governance](./0028-GOVE-governance.md). For markets that have a named successor market the insurance pool balance is transferred to the insurance pool of the successor market. +- [Insurance pool funds](./0015-INSR-market_insurance_pool_collateral.md) are redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. For markets that have a named successor market the insurance pool balance is transferred to the insurance pool of the successor market. - The market can be deleted entirely at this point, from a core perspective. **Entry:** @@ -284,7 +284,7 @@ The market state is `trading terminated`. Parties that had open positions see settlement cash-flows happen. Margin account balances are transferred to the general account. The market state is `settled`. -After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. ### Lifecycle happy path in Spot market (0043-MKTL-006) @@ -328,7 +328,7 @@ The market state is `active`. When this is approved and enacted the market state is `closed`. Parties that had open positions see settlement cash-flows happen to settle positions. Margin account balances are transferred to the general account. -After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +After `market.liquidity.successorLaunchWindowLength` has passed since market settlement, any insurance pool balance is [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. ### Market never leaves opening auction, trading terminated triggered, market cancelled (0043-MKTL-003) @@ -336,7 +336,7 @@ After `market.liquidity.successorLaunchWindowLength` has passed since market set 1. Trading terminated data source triggers before the market leaves the opening auction (so market never left Pending state so far). 1. All orders should be cancelled and collateral returned to respective parties general account for the relevant asset. 1. All LP commitments should be cancelled and their bond returned to the general account for the relevant asset. -1. After `market.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) to the on-chain treasury for the settlement asset of the market and other insurance pools using the same asset. +1. After `market.liquidity.successorLaunchWindowLength` has elapsed since market cancellation, any insurance pool balance should be [redistributed](./0015-INSR-market_insurance_pool_collateral.md) equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. 1. All data sources that are only referenced by that market are unregistered. 1. The market state is set to cancelled. diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index f38a1c25f..915e36c16 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -260,7 +260,7 @@ _Auctions:_ if this occurs at the transition from auction mode to continuous tra The network will: -1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's bond account in the list of accounts to search, and that these accounts would always be emptied before any insurance pool funds are used or loss socialisation occurs. +1. _As part of the normal collateral "search" process:_ Access first the liquidity provider's bond account to make up the shortfall. If there is insufficient funds to cover this amount, the full balance of both bond accounts will be used. Note that this means that the transfer request should include the liquidity provider's bond account in the list of accounts to search, and that these accounts would always be emptied before any market insurance pool funds are used or loss socialisation occurs. 1. _If there was a shortfall and the bond account was accessed:_ Transfer an amount equal to the `market.liquidity.bondPenaltyParameter` calculated above from the liquidity provider's bond account to the market's insurance pool. If there are insufficient funds in the bond account and the bond account, the full amount will be used and the remainder of the penalty (or as much as possible) should be transferred from the liquidity provider's margin account. diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index e25d2b106..f890e5e68 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -91,10 +91,8 @@ The delegator cannot move the tokens before the epoch ends, they remain locked. ## Undelegate now The action can be announced at any time and is executed immediately following the block -it is announced in. However, the stake is still counted as delegated to the validator until -the last block of the epoch, though the delegator rewards are not paid to the delegator, but -into an appropriate vega pool (the insurance pool, for example). The tokens are -released though, and the delegator can transfer their tokens in the smart contract. +it is announced in. The delegator is no longer considered for rewards. The stake is no longer counted as delegated to the previously chosen validator. +The tokens are released immediately, and the delegator can transfer their tokens in the smart contract. Rationale: This allows a delegator to sell their tokens in a rush, without requiring any interaction between the smart contract and the details of the delegation system. diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 0f56298b4..7dc3711fd 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -165,7 +165,7 @@ and emitted as an event. #### Exchanging funding payments between parties -Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding payment}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding payment is positive) and distributed to those receiving it. Any shortfall should be made-up from the insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). +Last step is to calculate each party's cash flows as $-\text{open volume} * \text{funding payment}$ where cashflows are first collected from parties that are making the payment (negative value of the cashflow, i.e. longs when the funding payment is positive) and distributed to those receiving it. Any shortfall should be made-up from the market's insurance pool and if that's not possible loss socialisation should be applied (exactly as per mark-to-market settlement methodology). ### 4.3.1. Periodic settlement during [auction](0026-AUCT-auctions.md) diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index 48be85293..78458bf01 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -1,10 +1,10 @@ # Network Treasury -The Network Treasury is a set of accounts (up to 1 per asset supported by the network via the asset framework) that are funded by parties, deposits, or by direct transfers (e.g. a portion of fees, or from insurance pools at market closure). +The Network Treasury is a set of accounts (up to 1 per asset supported by the network via the asset framework) that are funded by parties, deposits, by direct transfers (e.g. a portion of fees) or [governance transfers](./0028-GOVE-governance.md#5-transfers-initiated-by-governance). The purpose of the Network Treasury is to allow funding to be allocated to rewards, grants, etc. by token holder governance. -The funds in the network treasury are spent by being transferred to another account, either by direct governance action (i.e. voting on a specific proposed transfer) or by mechanisms controlled by governance, such as a periodic transfer, which may have network parameters that control the frequency of transfers, calculation of the amount, etc.. -These transfers may be to a party general account, reward pool account, or insurance pool account for a market. +The funds in the network treasury are spent by being transferred to another account, either by direct governance action (i.e. voting on a specific proposed transfer) or by mechanisms controlled by governance, such as a periodic transfer, which may have network parameters that control the frequency of transfers, calculation of the amount, etc. +These transfers may be to a party general account, reward pool account, general insurance pool or insurance pool account for a market. There is no requirement or expectation of symmetry between funds flowing into the Network Treasury and funds flowing out. For example, the treasury account may be seeded by funds held by the team or investors, or through the issuance of tokens at various irregular points in time, and these funds may then be allocated to incentives/rewards, grants, etc. on a different schedule. @@ -17,9 +17,9 @@ Funding is how the on-chain treasury account receives collateral to be allocated A transfer may specify the network treasury as the destination of the transfer. The funds, if available would be transferred instantly and irrevocably to the network treasury account for the asset in question (the treasury account for the asset will be created if it doesn’t exist). -- Transfer from protocol mechanics: there may be a protocol feature such as the charging of fees or handling of expired insurance pool balances that specifies the Network Treasury as destination in a transfer. (Charging of fees is placeholder, currently not to be implemented.) +- Transfer from protocol mechanics: there may be a protocol feature such as the charging of fees that specifies the Network Treasury as destination in a transfer. (Charging of fees is placeholder, currently not to be implemented.) -- Transfer by governance: a [governance proposal](./0028-GOVE-governance.md) can be submitted to transfer funds from a market's insurance pool into the on chain treasury account for the asset. +- Transfer by governance: a [governance proposal](./0028-GOVE-governance.md) can be submitted to transfer funds from the global or a market insurance pool into the on chain treasury account for the asset. - Transfer transaction: a transaction submitted to the network may request to transfer funds from the general account for an asset, controlled by the owner’s private key, to the Network Treasury. (see [transfers spec](./0057-TRAN-transfers.md)) @@ -38,7 +38,7 @@ In future a tax rate and/or inflation rate (controlled by governance) may be use ### Direct allocation by governance -A governance proposal may be submitted to transfer funds on enactment from the on-chain treasury to certain account types. Please see [the governance spec](./0028-GOVE-governance.md) for a description of this. +A governance proposal may be submitted to transfer funds on enactment from the on-chain treasury to certain account types. Such a transfer may be one-off or recurring. There is no other way to withdraw the funds from the network treasury account. Please see [the governance spec](./0028-GOVE-governance.md#5-transfers-initiated-by-governance) for a description of this. ## Acceptance criteria diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 6828f9537..53929b87d 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -6,7 +6,6 @@ These rewards operate in addition to the main protocol economic incentives which These fees are the fundamental income stream for [liquidity providers LPs](0042-LIQF-setting_fees_and_rewarding_lps.md) and [validators](./0061-REWP-pos_rewards.md). The additional rewards described here can be funded arbitrarily by users of the network and may be used by the project team, token holders (via governance), and individual traders and market makers to incentivise mutually beneficial behaviour. -Note that transfers via governance, including to fund rewards, is a post-Oregon Trail feature. Note that validator rewards (and the reward account for those) is covered in [validator rewards](./0061-REWP-pos_rewards.md) and is separate from the trading reward framework described here. @@ -24,7 +23,7 @@ At a high level, rewards work as follows: At the end of the epoch: -1. Recurring reward transfers (set up by the parties funding the rewards) are made to the reward account(s) for a specific reward type, for one or more markets in scope where the total reward metric is `>0`. See [transfers](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts). +1. Recurring reward transfers (set up by the parties funding the rewards or via governance) are made to the reward account(s) for a specific reward type, for one or more markets in scope where the total reward metric is `>0`. See [transfers](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts). 1. Then the entire balance of each reward account is distributed amongst entities with a non-zero reward metric for that reward type and market using the mechanism specified in the recurring transfer. 1. Distributed rewards are transferred to a [vesting account](./0085-RVST-rewards_vesting.md). @@ -39,7 +38,7 @@ Metrics only need to be calculated where the [market, reward type] reward accoun Reward metrics will be calculated once for each party/market combination in the reward metric asset which is the [settlement asset](0070-MKTD-market-decimal-places.md) of the market. This is the original precision for the metric source data. -For reward metrics relating to trading, an individual must meet the [staking requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) **AND** [notional time-weighted average position requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts)) set in the recurring transfer. If they do not then their reward metric is set to `0`. Note, these requirements do not apply to the [validator ranking metric](#returns-volatility-metric) or the [market creation reward metric](#market-creation-reward-metrics). +For reward metrics relating to trading, an individual must meet the [staking requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) **AND** [notional time-weighted average position requirement](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts)) set in the recurring transfer. If they do not then their reward metric is set to `0`. Note, these requirements do not apply to the [validator ranking metric](#validator-ranking-metric) or the [market creation reward metric](#market-creation-reward-metrics). For reward transfers where the [scope](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) is set to teams, each party must meet the minimum time in team requirement. That is, given a party has been in a team for $N$ epochs, if $N$ is strictly less than the network parameter `rewards.minimumEpochsInTeam` (an integer defaulting to `0`) their reward metric is set to `0`. @@ -132,6 +131,16 @@ If a party **is not** a consensus or standby validator, their reward metric is s $$m_v = 0$$ +A specialised global rewards account type is used for these rewards. + +The share of the reward attributed to the given validator gets further split between the validator itself and its delegators as outlined in [PoS rewards spec](./0061-REWP-pos_rewards.md) + +#### Maximum payout per participant + +For validator ranking metric based rewards the payments are subject to `reward.staking.delegation.maxPayoutPerParticipant`. +The maximum per participant is the maximum a single party (public key) on Vega can receive as a staking and delegation reward for one epoch. Each participant receives their due, capped by the max. The unpaid amount remain in the treasury. +Setting this to `0` means no cap. + ### Market creation reward metrics There will be a single market creation reward metric and reward type. diff --git a/protocol/0061-REWP-pos_rewards.md b/protocol/0061-REWP-pos_rewards.md index 9c78a5cbf..afb1ef313 100644 --- a/protocol/0061-REWP-pos_rewards.md +++ b/protocol/0061-REWP-pos_rewards.md @@ -2,7 +2,7 @@ This describes the SweetWater requirements for calculation and distribution of rewards to delegators and validators. For more information on the overall approach, please see the relevant research document. -This applies both the rewards coming from the [on-chain-treasury](./0055-TREA-on_chain_treasury.md) as well rewards resulting from trading via [infrastructure fees](./0029-FEES-fees.md). +This applies to the rewards resulting from trading via [infrastructure fees](./0029-FEES-fees.md). ## Network parameters used for `score_val` calculation @@ -22,7 +22,7 @@ This applies both the rewards coming from the [on-chain-treasury](./0055-TREA-on ## Calculation -This applies to the on-chain-treasury for each asset as well as network infrastructure fee pool for each asset. +This applies to the network infrastructure fee pool for each asset. At the end of an [epoch](./0050-EPOC-epochs.md), payments are calculated. As step *zero*: Vega keeps track of validators currently on the Ethereum multisig contract by knowing the initial state and by observing `validator added` and `validator removed` events emitted by the contract, see [multisig ethereum contract](./0033-OCAN-cancel_orders.md). @@ -49,7 +49,7 @@ The following formulas then apply to both primary and ersatz validators, where ' ## For each validator we then do 1. First, `validatorScore` is calculated to obtain the relative weight of the validator given `stake_val` is both own and delegated tokens, that is `stake_val = allDelegatedTokens + validatorsOwnTokens`. -Here `allDelegatedTokens` is the count of the tokes delegated to this validator. +Here `allDelegatedTokens` is the count of the tokens delegated to this validator. Note `validatorScore` also depends on the other network parameters, see below where the exact `validatorScore` function is defined. 1. Obtain the performance score as per [validator performance specification](./0064-VALP-validator_performance_based_rewards.md). Update `validatorScore <- validatorScore x performance_score`. 1. The fraction of the total available reward that goes to a node (some of this will be for the validator , some is for their delegators) is then `nodeAmount := stakingRewardAmtForEpoch x validatorScore / sumAllValidatorScores` where `sumAllValidatorScores` is the sum of all scores achieved by the validators. Note that this is subject to `min_own_stake` criteria being met. (see below). @@ -64,12 +64,6 @@ Each delegator should now receive `delegatorTokens / (allDelegatedTokens + valid If the validator (i.e. the associated key) does not have sufficient stake self-delegated (at least the network parameter `min_own_stake`), then the reward for the validator is set to zero. The corresponding amount is kept by the network, not distributed among the other validators. Note this only applies to the part of the reward attributable directly to such a validator, its delegators should still receive their rewards. If a Vega key which defines a validator delegates any amount to a different validator then the reward associated with that delegation will be paid out just like for any other delegator. -### Maximum payout per participant - -If the reward pool in question is the on-chain treasury for the staking and governance asset then payments are subject to `reward.staking.delegation.maxPayoutPerParticipant`. -The maximum per participant is the maximum a single party (public key) on Vega can receive as a staking and delegation reward for one epoch. Each participant receives their due, capped by the max. The unpaid amount remain in the treasury. -Setting this to `0` means no cap. - ## `validatorScore` functions This is defined as follows: diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 1b7a6c8ca..9756a7031 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -30,7 +30,7 @@ Information to store: - All [network parameters](../protocol/0054-NETP-network_parameters.md), including those defined [below](#network-parameters). - All [asset definitions](../protocol/0040-ASSF-asset_framework.md#asset-definition). -Insurance pool balances, [Reward account balance](../protocol/0056-REWA-rewards_overview.md) and [LP committed liquidity](./0044-LIME-lp_mechanics.md) balances for the markets that have been enacted will be stored with the accepted market proposal that must have preceded the market. +- Insurance pool balances (global for each asset and per-market), [Reward account balance](../protocol/0056-REWA-rewards_overview.md) and [LP committed liquidity](./0044-LIME-lp_mechanics.md) balances for the markets that have been enacted will be stored with the accepted market proposal that must have preceded the market. - All market proposals ([creation](../protocol/0028-GOVE-governance.md#1-create-market) and [update](../protocol/0028-GOVE-governance.md#2-change-market-parameters)) that have been *accepted* but not those where the market already started trading and reached *trading terminated* state. - All [asset proposals](../protocol/0028-GOVE-governance.md) that have been *accepted*. - All delegation info. @@ -382,7 +382,7 @@ for product spot: (0073-LIMN-082 0, submit trading terminated. +1. Propose, enact, trade in the market, close out distressed party so that market's insurance pool balance > 0, submit trading terminated. 1. System saves LNL checkpoint at a time when undistributed LP fees for the market are > 0. 1. Restart Vega, load LNL checkpoint. 1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029). For product spot: (0073-LIMN-083) @@ -390,7 +390,7 @@ for product spot: (0073-LIMN-0820073-LIMN-031) 1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-LIMN-084) 1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032). For product spot: (0073-LIMN-085) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-033) +1. The insurance pool balance has been redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. (0073-LIMN-112) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034). For product spot: (0073-LIMN-086) ### Test case 15: Market with trading terminated that settled is not restored, collateral moved correctly @@ -402,7 +402,7 @@ for product spot: (0073-LIMN-0820073-LIMN-041) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-088) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-043) +1. The insurance pool balance has been redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. (0073-LIMN-113) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044). For product spot: (0073-LIMN-089) ### Test case 16: Markets can be settled and terminated after restore as proposed @@ -425,7 +425,7 @@ for product spot: (0073-LIMN-0820073-LIMN-062) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-094) 1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063). For product spot: (0073-LIMN-095) -1. The insurance pool balance has been transferred to the Vega treasury for the asset. (0073-LIMN-064) +1. The insurance pool balance has been redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. (0073-LIMN-114) 1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065). For product spot: (0073-LIMN-096) ### Test case 18: market definition is the same pre and post LNL restore diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index c5bda89b5..3e947f838 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -11,7 +11,7 @@ For [details of virtual stake calculation see how LPs are rewarded](./0042-LIQF- Many derivative markets would terminate and settle periodically but would be part of a lineage. Think e.g. of a [cash-settled future](./0016-PFUT-product_builtin_future.md) written on the same underlying that settles every three months. Successor markets are a feature that allows for markets to have a lineage, but most importantly allows LPs to keep their virtual stake built up on one market (parent) in the lineage to be transferred to the next one (successor). -Moreover, part of the insurance pool of a parent market can be earmarked for transfer to the successor market instead of being distributed network wide (other markets in same settlement asset, network treasury). +Moreover, part of the insurance pool of a parent market can be earmarked for transfer to the successor market instead of being distributed network wide (other markets in same settlement asset, global insurance pool). ## Relevant network / market parameters @@ -76,7 +76,7 @@ Two proposals that name the same parent can be submitted. Both can be approved b A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction before `parent settlement time + market.liquidity.successorLaunchWindowLength` then the virtual stakes are carried over and the relevant fraction of the insurance pool is transferred over (0081-SUCM-006). -A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, the successor market is not a successor market anymore, it's just a market like any other, and the insurance pool balance will be distributed equally across all markets with the same settlement asset, including those markets which are still in opening auction (0081-SUCM-007) +A new market proposal sets parent market Id to a market that has settled. The parent market has non-zero insurance pool balance. If the new market clears the opening auction after `parent settlement time + market.liquidity.successorLaunchWindowLength` then no virtual stakes are carried over, the successor market is not a successor market anymore, it's just a market like any other, and the insurance pool balance will be distributed equally across the global insurance pool and all markets with the same settlement asset, including those markets which are still in opening auction (0081-SUCM-035) Successor markets cannot be enacted if the parent market is still in the "proposed" state. Successor market proposals can be submitted when the parent market is still in proposed state. When the voting period for the successor market ends then either: a) the parent market is already enacted in which case the successor market moves from "proposed" in to opening auction/"pending" state. Or the parent market is still in "proposed" state in which case successor market is rejected. (0081-SUCM-008) diff --git a/protocol/README.md b/protocol/README.md index b3c86864e..14f8dc393 100644 --- a/protocol/README.md +++ b/protocol/README.md @@ -57,7 +57,8 @@ - [Collateral](./0005-COLL-collateral.md) - [Margin orchestration](./0010-MARG-margin_orchestration.md) - [Check order, allocate margin](./0011-MARA-check_order_allocate_margin.md) -- [Market insurance pool](./0015-INSR-market_insurance_pool_collateral.md) +- [Market insurance pool](./0015-INSR-market_insurance_pool_collateral.md#market-insurance-pool) +- [Global insurance pool](./0015-INSR-market_insurance_pool_collateral.md#global-insurance-pool) - [Margin calculator](./0019-MCAL-margin_calculator.md) - [Quant risk models (Python notebook)](./0018-RSKM-quant_risk_models.ipynb) diff --git a/protocol/features.json b/protocol/features.json index c8df3fbc2..4aa7743a6 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -100,7 +100,6 @@ "0081-SUCM-003", "0081-SUCM-005", "0081-SUCM-006", - "0081-SUCM-007", "0081-SUCM-008", "0081-SUCM-027", "0081-SUCM-009", @@ -123,7 +122,8 @@ "0081-SUCM-026", "0081-SUCM-020", "0081-SUCM-021", - "0081-SUCM-022" + "0081-SUCM-022", + "0081-SUCM-035" ] }, "Governance Transfers": { @@ -176,7 +176,12 @@ "0028-GOVE-143", "0028-GOVE-144", "0028-GOVE-154", - "0055-TREA-011" + "0028-GOVE-155", + "0028-GOVE-156", + "0028-GOVE-157", + "0028-GOVE-158", + "0055-TREA-011", + "0013-ACCT-032" ] }, "Perps": { From a097e410e6764027e5423354460ec3cfe2daa1de Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 1 Sep 2023 11:08:28 +0200 Subject: [PATCH 539/649] refactor: remove undelegate in anger --- protocol/0050-EPOC-epochs.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/protocol/0050-EPOC-epochs.md b/protocol/0050-EPOC-epochs.md index f890e5e68..065bfa3bf 100644 --- a/protocol/0050-EPOC-epochs.md +++ b/protocol/0050-EPOC-epochs.md @@ -99,18 +99,6 @@ any interaction between the smart contract and the details of the delegation sys This also allows the delegator to change their mind about a delegation before it is activated. -## Undelegate in anger - -This action is announced at any time and is executed immediately following the block it -is announced in. The delegator loses the delegated stake and the income with it, as well -as their voting weight. As this is not required for first mainnet, and involves more subtleties -(weights need to be recalculated on the fly, there may be a mixture of normal undelegated -and undelegate in anger, ...), this feature does not need to be implemented right away for -Mainnet alpha. - -Rationale: A validator is found to have done something outrageous, and needs to be removed -right away. - ## Undelegation of locked stake Furthermore, the validators watch the smart contract, and observe the following actions: From 399df6dc6b67d0256b9b0bde08e56c192a5b6846 Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 1 Sep 2023 11:21:13 +0200 Subject: [PATCH 540/649] refactor: add `0` account bit --- protocol/0013-ACCT-accounts.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index f773b1528..8939308b6 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -25,6 +25,8 @@ Note that a party can also associate the governance / staking asset via the [Veg One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. +Note that both the global insurance pool and rewards account use the same `0` address. Account type is used to differentiate where the funds should go into when making a transfer or deposit. + ## Summary Accounts are used on Vega to maintain a record of the amount of collateral that is deposited and deployed by participants in the market. From 5f51770faa2d7ad31fee024e4fc16de7e2fb5657 Mon Sep 17 00:00:00 2001 From: Witold Date: Mon, 4 Sep 2023 12:04:52 +0200 Subject: [PATCH 541/649] refactor: general -> global --- protocol/0055-TREA-on_chain_treasury.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index 78458bf01..c8952e88b 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -4,7 +4,7 @@ The Network Treasury is a set of accounts (up to 1 per asset supported by the ne The purpose of the Network Treasury is to allow funding to be allocated to rewards, grants, etc. by token holder governance. The funds in the network treasury are spent by being transferred to another account, either by direct governance action (i.e. voting on a specific proposed transfer) or by mechanisms controlled by governance, such as a periodic transfer, which may have network parameters that control the frequency of transfers, calculation of the amount, etc. -These transfers may be to a party general account, reward pool account, general insurance pool or insurance pool account for a market. +These transfers may be to a party general account, reward pool account, global insurance pool or insurance pool account for a market. There is no requirement or expectation of symmetry between funds flowing into the Network Treasury and funds flowing out. For example, the treasury account may be seeded by funds held by the team or investors, or through the issuance of tokens at various irregular points in time, and these funds may then be allocated to incentives/rewards, grants, etc. on a different schedule. From 50c62e85ce44e9bc7bfb31c45c578dcab6b37e81 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 5 Sep 2023 17:00:50 +0200 Subject: [PATCH 542/649] refactor: address comments from PR review --- protocol/0013-ACCT-accounts.md | 43 +++++++++++++++++++++++-- protocol/0055-TREA-on_chain_treasury.md | 2 +- protocol/0056-REWA-rewards_overview.md | 1 - protocol/features.json | 6 +++- 4 files changed, 46 insertions(+), 6 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 8939308b6..7e17655e9 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -25,7 +25,7 @@ Note that a party can also associate the governance / staking asset via the [Veg One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. -Note that both the global insurance pool and rewards account use the same `0` address. Account type is used to differentiate where the funds should go into when making a transfer or deposit. +Note that both the network treasury and the global rewards account use the same `0` address. Account type is used to differentiate where the funds should go into when making a transfer or deposit. ## Summary @@ -77,7 +77,7 @@ If there is a positive balance in an account that is being deleted, that balance Bond accounts are opened when a party opens a [Liquidity Provision order](./0044-LIME-lp_mechanics.mdd). The bond is held by the network to ensure that the Liquidity Provider meets their SLA obligations. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. -## Insurance pools +## Market insurance pools Every market will have at least one insurance pool account that holds collateral that can be used to cover losses in case of unreasonable market events. @@ -85,7 +85,26 @@ Every market will have at least one insurance pool account that holds collateral When a [market launches](./0043-MKTL-market_lifecycle.md), an insurance pool account is created for that market for each settlement asset. This account is used by the protocol during the collection of [margin requirements](./0010-MARG-margin_orchestration.md) and the collection of [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md). -When a market is finalised / closed remaining funds are distributed to the on chain treasury. This occurs using ledger entries to preserve double entry accounting records within the collateral engine. +When a market is finalised / closed remaining funds are redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. This occurs using ledger entries to preserve double entry accounting records within the collateral engine. + +## General insurance pool + +There is a general insurance pool for every asset which has been used by at least one market which was closed and had positive balance in its insurance pool. + +**Creation/Deletion:** + +When a market gets closed and positive balance remains in its insurance pool then part of the that balance gets moved to the global insurance pool for the asset which market used as its settlement asset. If the insurance pool for that asset doesn't exist yet then it gets created on the fly at the point of that transfer. + +Currently these accounts never get deleted. + +## Network treasury + +Network treasury holds assets which can only be moved to another account via the [governance initiated transfer](./0028-GOVE-governance.md#governance-initiated-transfer-proposals). +Funds are moved into the network treasury using (external) deposits or (internal) transfers. If the network treasury doesn't exist for an asset supported for deposits and/or transfers then it gets created on the fly at the point of that transfer. + +## Fee distribution accounts + +Additional accounts (one per each supported asset) associated with distribution of trading fees (infrastructure fees, maker fees, liquidity provision fees) exist. Please refer to the [fees](./0029-FEES-fees.md) and [LP](./0042-LIQF-setting_fees_and_rewarding_lps.md) specs for more details. ## Staking accounts @@ -95,6 +114,14 @@ In Vega governance is controlled by a [governance token](./0028-GOVE-governance. Note that it *is* possible to have markets in the governance asset, in which case all of the accounts detailed above will still apply. Staking accounts only relate to the balance of the governance asset that has been staked. +## Global rewards account + +A special account type used for distribution of rewards based on validator ranking metric. Funds are moved into the global rewards account using (external) deposits or (internal) transfers. Please refer to the [subsection of the rewards spec](./0056-REWA-rewards_overview.md#validator-ranking-metric) for details around distribution of funds from that account. + +## Rewards account + +Additional accounts associated with [distribution](./0056-REWA-rewards_overview.md) and [vesting](./0085-RVST-rewards_vesting.md) of other rewards exist, please refer to the relevant spec files for more details. + ## Acceptance Criteria ### All ordinary accounts @@ -146,3 +173,13 @@ One key difference with staking accounts is that the collateral is not held in a - The balance can only be delegated to Validators (0013-ACCT-015) - The balance cannot be traded, or used as margin, or transferred, or withdrawn (0013-ACCT-016) - Delegated stake remains in the trader's staking account (0013-ACCT-017) + +### Network treasury + +- It is possible to deposit funds from Ethereum directly into the network treasury account by specifying the `0` address and appropriate account type. (0013-ACCT-026) +- It is possible to transfer funds from a Vega general account to the network treasury account by specifying the `0` address and appropriate account type. (0013-ACCT-027) + +### Global rewards account + +- It is possible to deposit funds from Ethereum directly into the global rewards account by specifying the `0` address and appropriate account type. (0013-ACCT-028) +- It is possible to transfer funds from a Vega general account to the global rewards account by specifying the `0` address and appropriate account type. (0013-ACCT-029) diff --git a/protocol/0055-TREA-on_chain_treasury.md b/protocol/0055-TREA-on_chain_treasury.md index c8952e88b..b79786cd7 100644 --- a/protocol/0055-TREA-on_chain_treasury.md +++ b/protocol/0055-TREA-on_chain_treasury.md @@ -1,6 +1,6 @@ # Network Treasury -The Network Treasury is a set of accounts (up to 1 per asset supported by the network via the asset framework) that are funded by parties, deposits, by direct transfers (e.g. a portion of fees) or [governance transfers](./0028-GOVE-governance.md#5-transfers-initiated-by-governance). +The Network Treasury is a set of accounts (up to 1 per asset supported by the network via the asset framework) that are funded by parties, deposits, by direct transfers (e.g. a portion of fees) or [governance transfers](./0028-GOVE-governance.md#5-transfers-initiated-by-governance). Please note that the network treasury, rewards accounts (including the global rewards account) and the global insurance pool are 3 separate concepts and funds can only flow between any of these 3 accounts via governance transfers. Please refer to the [accounts spec](./0013-ACCT-accounts.md) for more details. The purpose of the Network Treasury is to allow funding to be allocated to rewards, grants, etc. by token holder governance. The funds in the network treasury are spent by being transferred to another account, either by direct governance action (i.e. voting on a specific proposed transfer) or by mechanisms controlled by governance, such as a periodic transfer, which may have network parameters that control the frequency of transfers, calculation of the amount, etc. diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 53929b87d..1972db3d0 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -178,7 +178,6 @@ All metrics (except [market creation](#market-creation-reward-metrics)) can be u A team’s reward metric is the weighted average metric score of the top performing `n` % of team members by number where `n` is specified when creating the recurring transfer (i.e. for a team of 100 parties with `n=0.1`, the 10 members with the highest metric score). - ## Reward accounts Trading reward accounts are defined by a hash of the fields specified in the recurring transfer funding the reward account (see the [transfers](./0057-TRAN-transfers.md#recurring-transfers-to-reward-accounts) spec for relevant details about each field). This allows multiple recurring transfers to fund the same reward pool. diff --git a/protocol/features.json b/protocol/features.json index 4aa7743a6..63bc2910a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -181,7 +181,11 @@ "0028-GOVE-157", "0028-GOVE-158", "0055-TREA-011", - "0013-ACCT-032" + "0013-ACCT-032", + "0013-ACCT-026", + "0013-ACCT-027", + "0013-ACCT-028", + "0013-ACCT-029" ] }, "Perps": { From f8143099ace6ddeaa41269e3b3aabf253699d647 Mon Sep 17 00:00:00 2001 From: Witold Date: Tue, 5 Sep 2023 17:35:56 +0200 Subject: [PATCH 543/649] refactor: review suggestion Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0013-ACCT-accounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 7e17655e9..0848d61dd 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -21,7 +21,7 @@ Note that a party can also associate the governance / staking asset via the [Veg 1. [Insurance pool account](0015-INSR-market_insurance_pool_collateral.md#market-insurance-pool) for any market. 1. [Liquidity fee pool](0042-LIQF-setting_fees_and_rewarding_lps.md) for any market. 1. [Infrastructure fee pool](0029-FEES-fees.md) for any asset. -1. [Reward accounts](0056-REWA-rewards_overview.md) which exist for *each* reward account per every Vega asset (settlement asset) and per every reward metric per every Vega asset (reward asset). There is an additional [global rewards account](0056-REWA-rewards_overview.md#validator-ranking-metric) used for supplementary (on top of infrastructure fee split) validator rewards. +1. [Reward accounts](0056-REWA-rewards_overview.md) which exist for *each* Vega asset (settlement asset) and per every reward metric per every Vega asset (reward asset). There is an additional [global rewards account](0056-REWA-rewards_overview.md#validator-ranking-metric) used for supplementary (on top of infrastructure fee split) validator rewards. One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. From 2fbc3d502a58314d0331e4db389aafcbf6370164 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 6 Sep 2023 09:47:41 +0200 Subject: [PATCH 544/649] refactor: clarify details around `0` account --- protocol/0013-ACCT-accounts.md | 9 ++++----- protocol/features.json | 3 +-- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 0848d61dd..347abb9a7 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -25,7 +25,7 @@ Note that a party can also associate the governance / staking asset via the [Veg One key difference with staking accounts is that the collateral is not held in an asset bridge, but in the [staking bridge](./0071-STAK-erc20_governance_token_staking.md). The balance is changed by events on Ethereum, rather than actions taken on the Vega chain. -Note that both the network treasury and the global rewards account use the same `0` address. Account type is used to differentiate where the funds should go into when making a transfer or deposit. +Note that both the network treasury and the global rewards account use the same `0` address. Account type is used to differentiate where the funds should go into when making a transfer. The deposits made to the `0` account get credited to the global rewards account. ## Summary @@ -176,10 +176,9 @@ One key difference with staking accounts is that the collateral is not held in a ### Network treasury -- It is possible to deposit funds from Ethereum directly into the network treasury account by specifying the `0` address and appropriate account type. (0013-ACCT-026) -- It is possible to transfer funds from a Vega general account to the network treasury account by specifying the `0` address and appropriate account type. (0013-ACCT-027) +- It is possible to transfer funds from a Vega general account to the network treasury account by specifying the `0` address and appropriate account type. (0013-ACCT-026) ### Global rewards account -- It is possible to deposit funds from Ethereum directly into the global rewards account by specifying the `0` address and appropriate account type. (0013-ACCT-028) -- It is possible to transfer funds from a Vega general account to the global rewards account by specifying the `0` address and appropriate account type. (0013-ACCT-029) +- It is possible to deposit funds from Ethereum directly into the global rewards account by specifying the `0` Vega address. (0013-ACCT-027) +- It is possible to transfer funds from a Vega general account to the global rewards account by specifying the `0` address and appropriate account type. (0013-ACCT-028) diff --git a/protocol/features.json b/protocol/features.json index 63bc2910a..0e82acdaa 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -184,8 +184,7 @@ "0013-ACCT-032", "0013-ACCT-026", "0013-ACCT-027", - "0013-ACCT-028", - "0013-ACCT-029" + "0013-ACCT-028" ] }, "Perps": { From c5d36ef9d1deb094cd0b657bba1576857adb6c7b Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 6 Sep 2023 10:20:22 +0100 Subject: [PATCH 545/649] feat: update AC 0044-LIME-028 --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 915e36c16..cc54ac6eb 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -349,7 +349,7 @@ In the case of spot markets it will be transferred into the network treasury for ### Qualifying Order Types -- Once liquidity is committed LPs can meet their commitment by placing limit orders, pegged limit orders and iceberg orders. For iceberg orders only the visible peak counts towards the commitment (0044-LIME-028). For spot (0044-LIME-029) +- Once liquidity is committed, LPs can meet their commitment by placing limit orders, pegged limit orders, and iceberg orders. For iceberg orders, all the volume (including displayed and remaining volume) counts towards the commitment. (0044-LIME-028). For spot (0044-LIME-029) - Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077). For spot (0044-LIME-078) - GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079). For spot (0044-LIME-080) - GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081). For spot (0044-LIME-082) From 94c39ad537d6258166648e25f22d051d9dcd24a6 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 6 Sep 2023 10:26:38 +0100 Subject: [PATCH 546/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 742857ef2..14c77f12c 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -341,7 +341,7 @@ In the case of spot markets it will be transferred into the network treasury for - For a market that is in opening auction and LP has committed liquidity: - LP can increase their commitment and it will take effect immediately (0044-LIME-050). For spot (0044-LIME-054) - LP can decrease their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - - Target stake is 0 so LP can cancel their commitment without incurring penalties (0044-LIME-053) + - If target stake is 0 then any LP can cancel their commitment without incurring penalties (0044-LIME-053) - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) - For a market that is in continuous trading and LP has committed liquidity From 1c45fa8ed66974d018738d970f95cfd14f6ba1dc Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 6 Sep 2023 11:26:42 +0200 Subject: [PATCH 547/649] refactor: remove redundant sentences --- protocol/0053-PERP-product_builtin_perpetual_future.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 7dc3711fd..2ab10a9b2 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -4,7 +4,7 @@ This built-in product provides perpetual futures contracts that are cash-settled Background reading: [1](https://www.paradigm.xyz/2021/05/everlasting-options/#Perpetual_Futures), [2](https://arxiv.org/pdf/2212.06888.pdf). -Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data` oracle between to consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. +Perpetual futures are a simple "delta one" product. Mark-to-market settlement occurs with a predefined frequency as per [0003-MTMK-mark_to_market_settlement](0003-MTMK-mark_to_market_settlement.md). Additionally, a settlement using external data is carried out whenever `settlement_schedule` is triggered. Data obtained from the `settlement_data` oracle between two consecutive `settlement_schedule` events is used to calculate the funding payment and exchange cashflows between parties with open positions in the market. Unlike traditional futures contracts, the perpetual futures never expire. Without the settlement at expiry there would be nothing in the fixed-expiry futures to tether the contract price to the underlying spot market it's based on. To assure that the perpetuals market tracks the underlying spot market sufficiently well a periodic cashflow is exchanged based on the relative prices in the two markets. Such payment covering the time period $t_{i-1}$ to $t_i$ takes the basic form $G_i = \frac{1}{t_i-t_{i-1}} \int_{t_{i-1}}^{t_i}(F_u-S_u)du$, where $F_u$ and $S_u$ are respectively: the perpetual futures price and the spot price at time $u$. We choose to use the mark price to approximate $F_u$ and oracle to approximate $S_u$, so this is effectively the difference between the time-weighted average prices (TWAP) of the two. An optional interest rate and clamp function are included in the funding rate calculation, see the [funding payment calculation](#funding-payment-calculation) section for details. @@ -224,8 +224,8 @@ In both cases the estimates are for a hypothetical position of size 1. 1. Receiving correctly formatted data from settlement data oracles and settlement schedule oracles during continuous trading results in periodic settlement. (0053-PERP-007) 1. Receiving correctly formatted data from the settlement data and settlement schedule oracles during liquidity monitoring auction results in the exchange of periodic settlement cashflows. Market remains in liquidity monitoring auction until enough additional liquidity gets committed to the market. (0053-PERP-008) 1. Receiving correctly formatted data from the settlement data and settlement schedule oracles during price monitoring auction results in the exchange of periodic settlement cashflows. Market remains in price monitoring auction until its original duration elapses, uncrosses the auction and goes back to continuous trading mode. (0053-PERP-009) -1. When the funding payment is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with short positions are not impacted. (0053-PERP-015) -1. When the funding payment is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Moreover, the additional amount grows as the funding payment nears and drops right after the payment. Parties with long positions are not impacted. (0053-PERP-016) +1. When the funding payment is positive the margin levels of parties with long positions are larger than what the basic margin calculations imply. Parties with short positions are not impacted. (0053-PERP-015) +1. When the funding payment is negative the margin levels of parties with short positions are larger than what the basic margin calculations imply. Parties with long positions are not impacted. (0053-PERP-016) 1. An event containing funding rate should be emitted each time the funding payment is calculated (0053-PERP-017) 1. No data relating to funding payment is available until the perpetual futures market leaves the opening auction. (0053-PERP-018) 1. For the ongoing period the following data is available via the API: funding period start time, estimate time, funding rate estimate, funding payment estimate, external (spot) price TWAP to-date, internal (mark) price TWAP to-date. (0053-PERP-019) From 230a10460391f030352e867dd68361df2962d5b4 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 6 Sep 2023 10:27:30 +0100 Subject: [PATCH 548/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 14c77f12c..9db5ead5f 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -348,7 +348,7 @@ In the case of spot markets it will be transferred into the network treasury for - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) - For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-090) -- If an LP with a liquidity provision and active orders on a market cancel their provision only (orders remain active), after the cancellation penalty (if it applies at end of epoch) the end of next epoch lp will not accrue any rewards or incur penalty for trades on the market. (0044-LIME-097) +- If an LP with a liquidity provision and active orders on a market cancels their liquidity provision (orders remain active), after the cancellation penalty (if it applies at end of epoch) at the end of the next epoch the LP will not accrue any rewards for trades on the market. (0044-LIME-097) - In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) - In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to `market.liquidity.priceRange = 0.01` (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) From d0b050ea9b6e4f9da78461d23748349bca52c05b Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 6 Sep 2023 10:28:19 +0100 Subject: [PATCH 549/649] Update protocol/0044-LIME-lp_mechanics.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9db5ead5f..e0050411f 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -349,7 +349,7 @@ In the case of spot markets it will be transferred into the network treasury for - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) - For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-090) - If an LP with a liquidity provision and active orders on a market cancels their liquidity provision (orders remain active), after the cancellation penalty (if it applies at end of epoch) at the end of the next epoch the LP will not accrue any rewards for trades on the market. (0044-LIME-097) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05 (5%)` and is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has infused liquidity by placing a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) +- Consider a market where `market.liquidity.priceRange = 0.05 (5%)` and which is in continuous trading with a mid price of 5. There is an LP who's committed to provide liquidity. They place a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) - In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to `market.liquidity.priceRange = 0.01` (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) From 085645d7a1c03143ca437e2a0a5be82c941a0496 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 6 Sep 2023 11:01:09 +0100 Subject: [PATCH 550/649] addressed comments --- protocol/0044-LIME-lp_mechanics.md | 16 +++++++++++++--- protocol/features.json | 2 ++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index e0050411f..5198630ae 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -339,11 +339,21 @@ In the case of spot markets it will be transferred into the network treasury for `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) - For a market that is in opening auction and LP has committed liquidity: - - LP can increase their commitment and it will take effect immediately (0044-LIME-050). For spot (0044-LIME-054) - - LP can decrease their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) + - When a LP increases their commitment then: + - It takes effect immediately for the purposes of LP stake supplied to the market + - In terms of the liquidity they are expected to supply: this only takes effect from the start of the next epoch + (0044-LIME-050). For spot (0044-LIME-054) + - LP can decrease or cancel their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) - If target stake is 0 then any LP can cancel their commitment without incurring penalties (0044-LIME-053) + +- Consider a market in liquidity auction, when a LP increases their commitment it will take effect immediate for the purposes of LP stake supplied to the market. Where LP `supplied stake > target stake` the market will leave liquidity auction when the liquidity auction ends + - In terms of the liquidity they are expected to supply: this only takes effect from the start of the next epoch + (0044-LIME-102) + - For a market that is in continuous trading and a single LP has committed liquidity: - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060) for spot (0044-LIME-056) +- During continuous trading an LP can submit a transaction to decrease commitment but it will only happen at the end of current epoch. (0044-LIME-101) + - For a market that is in continuous trading and LP has committed liquidity - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-061) - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) @@ -351,7 +361,7 @@ In the case of spot markets it will be transferred into the network treasury for - If an LP with a liquidity provision and active orders on a market cancels their liquidity provision (orders remain active), after the cancellation penalty (if it applies at end of epoch) at the end of the next epoch the LP will not accrue any rewards for trades on the market. (0044-LIME-097) - Consider a market where `market.liquidity.priceRange = 0.05 (5%)` and which is in continuous trading with a mid price of 5. There is an LP who's committed to provide liquidity. They place a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) -- In a market, where the market parameter is `market.liquidity.priceRange = 0.05`, and it is engaged in continuous trading with a mid price set at 5, a new Liquidity Provider (LP) has injected liquidity by placing a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch unfolds, if the market parameter is modified to `market.liquidity.priceRange = 0.01` (1%), then at the conclusion of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in continuous trading with a mid price set at 5. There is an LP who's committed to provide liquidity. They place a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) - In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-094) diff --git a/protocol/features.json b/protocol/features.json index aa17420ac..5b01d736a 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -358,6 +358,8 @@ "0044-LIME-098", "0044-LIME-099", "0044-LIME-100", + "0044-LIME-101", + "0044-LIME-102", "0026-AUCT-016", "0026-AUCT-017", "0026-AUCT-018", From 8073f7c60beaed06fe8d1170be277128eb4ad28d Mon Sep 17 00:00:00 2001 From: wwestgarth Date: Wed, 6 Sep 2023 11:24:02 +0100 Subject: [PATCH 551/649] chore: add two eth oracles ACs related to multiple contracts (#1926) * chore: add two eth oracles ACs related to multiple contracts * fix: Update protocol/0082-ETHD-ethereum-data-source.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0082-ETHD-ethereum-data-source.md | 6 ++++-- protocol/features.json | 7 ++++--- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index 3d7fef074..af65d251f 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -146,8 +146,10 @@ Select { 9. Only one oracle data event is emitted for data that matches multiple data sources - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 300. One single event BUS_EVENT_TYPE_ORACLE_DATA for the settlement data is emitted with both matching ethereum oracle data sources listed within the event. Both markets are settled and both the data sources are DEACTIVATED. (0082-ETHD-023) 10. Different oracle data events for multiple spec id's with non matching filter values - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 50. NO data events for BUS_EVENT_TYPE_ORACLE_DATA. Send settlement data of 150. One single event BUS_EVENT_TYPE_ORACLE_DATA emitted for the settlement data is emitted with matching ethereum oracle data spec for Market1, market1 is settled and the data source is set to DEACTIVATED. Send settlement data of 250. One single event BUS_EVENT_TYPE_ORACLE_DATA emitted for the settlement data is emitted with matching ethereum oracle data spec for Market2, Market2 is settled and the data source is set to DEACTIVATED. (0082-ETHD-024) 11. Network wide contract error should be reported via oracle data events (0082-ETHD-025) -12. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-PLAZZO-003) -13. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-PLAZZO-004) +12. Different contracts on different markets - Create 2 markets with ethereum oracle settlement data sources containing different contract addresses and with *different* settlement keys, but with all conditions and filters the same. Confirm that sending settlement value that passes the market spec filter only settles one market. (0082-ETHD-050) +13. Different contracts on different markets - Create 2 markets with ethereum oracle settlement data sources containing different contract addresses and with the *same* settlement keys, but with all conditions and filters the same. Confirm that sending settlement value that passes the market spec filter only settles one market. (0082-ETHD-051) +14. Phase 2 - System needs to emit an error via the TX RESULT event if the data source does NOT emit events in a timely fashion. e.g. if the data source is expected to emit events every 5 minutes and if we do not receive 3 consecutive events , then raise an error via the TX RESULT event (0082-PLAZZO-003) +15. Phase 2 - Define behaviour for missed events / missed scheduled smart contract calls - e.g. if an oracle data source is scheduled to emit events every 10 minutes and we miss 5 events because of protocol upgrade or some other outage - then do we catch up those events or skip those events ? Maybe this is defined in the oracle data source definition (0082-PLAZZO-004) ### New Network parameters diff --git a/protocol/features.json b/protocol/features.json index 0e82acdaa..f9b75c78b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -230,7 +230,6 @@ "0019-MCAL-023" ] }, - "Ethereum Oracles": { "milestone": "deployment-2", "acs": [ @@ -271,7 +270,9 @@ "0082-ETHD-045", "0082-ETHD-047", "0082-ETHD-048", - "0082-ETHD-049" + "0082-ETHD-049", + "0082-ETHD-050", + "0082-ETHD-051" ] }, "SLA": { @@ -798,4 +799,4 @@ "milestone": "unknown", "acs": [] } -} +} \ No newline at end of file From 173d7a620fea433a78b3f0e60c4c04168215d12e Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 6 Sep 2023 11:43:17 +0100 Subject: [PATCH 552/649] modified for clarity and consistency --- protocol/0044-LIME-lp_mechanics.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 57416c532..7817d7956 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -363,17 +363,17 @@ In the case of spot markets it will be transferred into the network treasury for - Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in continuous trading with a mid price set at 5. There is an LP who's committed to provide liquidity. They place a buy order at a price of 4.74 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the ongoing epoch, the LP will not have met their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-093) -- In a market where the market parameter is `market.liquidity.priceRange = 0.05`, and it is in a monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4, the Liquidity Provider (LP) has committed liquidity by placing a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-094) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with the last trade price set at 5, the indicative uncrossing price is set at 4. There is an LP who's committed to provide liquidity. They place a buy order at a price of 3.79 (which is less than `5%` of `1-0.05 x min(5, 4) = 3.80`), and a sell order at a price of 5.25 (with sufficient volume). At the end of the epoch, the LP has not fulfilled their committed notional volume, resulting in the imposition of a bond penalty. (0044-LIME-094) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4` and the LP has committed liquidity and orders at buy price `3.8` and sell price `5.25` (with sufficient volume), the LP is meeting their committed volume of notional (0044-LIME-095) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `4`. There is a LP who's committed to provide liquidity. They place a buy order at price `3.8` and a sell order at price `5.25` (with sufficient volume). At the end of the epoch, the LP is meeting their committed volume of notional rendering them exempt from a bond penalty. (0044-LIME-095) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`, the LP has committed liquidity and orders at buy price `4.75` and sell price `6.31` (which is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`), the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-096) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with `last trade price` set to `5`, `indicative uncrossing price` is set to `6`. There is a LP who's committed to provide liquidity. They place a buy orders at price `4.75` and sell order at price `6.31` (which is larger than `5%` of `1+ 0.05 x max (5, 6) = 6.30`). At the end of the epoch, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-096) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell price `5.25`, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty.. (0044-LIME-098) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`. There is a LP who's committed to provide liquidity. They place a buy orders at price `4.74` (which is less than `5%` of `1-0.05 x min(5, n/a) = 4.75`) and sell order at price `5.25`. At the end of the epoch, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-098) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`) the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-099) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`. There is a LP who's committed to provide liquidity. They place a buy orders at price `4.75` and sell order at price `5.26` (which is is more than `5%` of `1+ 0.05 x max (5, n/a) = 5.25`). At the end of the epoch, the LP is not meeting their committed volume of notional, resulting in the imposition of a bond penalty. (0044-LIME-099) -- For a market with market parameter `market.liquidity.priceRange = 0.05`, is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`, the LP has committed liquidity and orders at buy price `4.75` and sell price `5.25`, the LP is meeting their committed volume of notional (0044-LIME-092) +- Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`. There is a LP who's committed to provide liquidity. They place a buy orders at price `4.75` and sell order at price `5.25`. At the end of the epoch, the LP is meeting their committed volume of notional rendering them exempt from a bond penalty. (0044-LIME-092) - When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063). For spot (0044-LIME-064) - When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065). For spot (0044-LIME-066) From 734449e06037ffa5987ce68b891f0b96e772a66b Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 6 Sep 2023 11:45:04 +0100 Subject: [PATCH 553/649] chore: tidy up the features.json file (#1929) --- protocol/features.json | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index f9b75c78b..bc66bf1cd 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,6 +1,6 @@ { "Iceberg Orders": { - "milestone": "deployment-1", + "milestone": "cosmic-elevator-1", "acs": [ "0014-ORDT-039", "0014-ORDT-007", @@ -39,7 +39,7 @@ ] }, "Stop Orders": { - "milestone": "deployment-1", + "milestone": "cosmic-elevator-1", "acs": [ "0014-ORDT-041", "0014-ORDT-042", @@ -83,7 +83,7 @@ ] }, "Successor Markets": { - "milestone": "deployment-1", + "milestone": "cosmic-elevator-1", "acs": [ "0001-MKTF-006", "0001-MKTF-007", @@ -126,8 +126,8 @@ "0081-SUCM-035" ] }, - "Governance Transfers": { - "milestone": "deployment-2", + "Transfers by governance": { + "milestone": "cosmic-elevator-2", "acs": [ "0028-GOVE-073", "0028-GOVE-074", @@ -187,8 +187,8 @@ "0013-ACCT-028" ] }, - "Perps": { - "milestone": "deployment-2", + "Perpetuals": { + "milestone": "cosmic-elevator-2", "acs": [ "0001-MKTF-005", "0053-PERP-001", @@ -203,6 +203,9 @@ "0053-PERP-015", "0053-PERP-016", "0053-PERP-017", + "0053-PERP-018", + "0053-PERP-019", + "0053-PERP-020", "0043-MKTL-009", "0051-PROD-007", "0051-PROD-008", @@ -231,7 +234,7 @@ ] }, "Ethereum Oracles": { - "milestone": "deployment-2", + "milestone": "cosmic-elevator-2", "acs": [ "0082-ETHD-001", "0082-ETHD-002", @@ -276,7 +279,7 @@ ] }, "SLA": { - "milestone": "deployment-2", + "milestone": "cosmic-elevator-2", "acs": [ "0042-LIQF-032", "0042-LIQF-050", @@ -342,11 +345,12 @@ "0026-AUCT-019", "0026-AUCT-020", "0026-AUCT-021", - "0026-AUCT-022" + "0026-AUCT-022", + "0034-PROB-004" ] }, "Batch change proposals": { - "milestone": "deployment-2", + "milestone": "cosmic-elevator-2", "acs": [ "0028-GOVE-145", "0028-GOVE-146", @@ -356,7 +360,7 @@ ] }, "Referral program": { - "milestone": "deployment-2", + "milestone": "cosmic-elevator-2", "acs": [ "0083-RFPR-001", "0083-RFPR-002", @@ -425,7 +429,7 @@ ] }, "Market governance": { - "milestone": "deployment-2", + "milestone": "cosmic-elevator-2", "acs": [ "0028-GOVE-064", "0028-GOVE-069", @@ -451,7 +455,7 @@ ] }, "Spot": { - "milestone": "deployment-3", + "milestone": "plazzo", "acs": [ "0080-SPOT-001", "0080-SPOT-002", @@ -683,7 +687,7 @@ "0033-OCAN-015", "0033-OCAN-016", "0033-OCAN-017", - "0034-PROB-002", + "0034-PROB-003", "0034-PROB-008", "0034-PROB-010", "0039-MKTD-020", From 9e84beae8437a95f896fed0b23b71e9958133ce7 Mon Sep 17 00:00:00 2001 From: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Date: Wed, 6 Sep 2023 15:42:16 +0300 Subject: [PATCH 554/649] fix: reword ACs 38, 39 (#1923) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0082-ETHD-ethereum-data-source.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index af65d251f..b60fac93f 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -166,8 +166,8 @@ Select { ### API -1. Ability to query oracle data sources via an API endpoint (REST, gRPC and graphQL) - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0082-ETHD-038) -2. Ability to query historic data sent by an oracle data source and processed by vega network (0082-ETHD-039) +1. Ability to query data source specs defined for ethereum oracle sources, for settlement and termination, via an API endpoint (REST, gRPC and graphQL) - filters should be available for data source - internal OR external, status - Active / Inactive / Expired (0082-ETHD-038) +2. Ability to query historic data sent by an ethereum oracle source, for settlement and termination, and processed by a market in vega network (0082-ETHD-039) ### Checkpoints From 4f02e12879f71e7e82b79eb4a0d1ba6f31668e51 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 6 Sep 2023 14:54:18 +0200 Subject: [PATCH 555/649] test: add a concrete example --- .../0042-LIQF-setting_fees_and_rewarding_lps.md | 13 ++++++++++--- protocol/features.json | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 8d90f034d..2bba54bb9 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -297,9 +297,6 @@ $$ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type that marks this as the "LP relative SLA performance bonus distribution". -There is an example [google sheet for this step](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY/edit#gid=0); once we're sure we're happy let's transfer this to a fixed example. - - ### APIs for fee splits and payments - Each liquidity provider's equity-like share @@ -396,3 +393,13 @@ There is an example [google sheet for this step](https://docs.google.com/spreads - With two liquidity providers, one with an effective penalty rate of `0.5` and earned fees of `n`, and the other with an effective rate of `0.75` and earned fees of `m`, `50% * n` and `25% * m` of the second provider's should be transferred back into market's aggregate LP fee account. Then the total provider bonus score should be `b = (m / (n + m)) * 0.25 + (n / (n + m)) * 0.5` and provider 1 should receive `(0.5 * n + 0.25 * m) * (n / (n + m)) * 0.5 / b` and provider 2 should receive `(0.5 * n + 0.25 * m) * (m / (n + m)) * 0.25 / b` as an additional bonus payment (0042-LIQF-044) - With two liquidity providers, one with an effective penalty rate of `1` and earned fees of `n`, and the other with an effective rate of `0` and earned fees of `m`, the entirety of `n` should be transferred to the second liquidity provider as a bonus payment (0042-LIQF-045) - With only one liquidity provider, with an effective penalty rate of `0.5`, `50%` of their initially earned fees will be taken initially but will be entirely paid back to them as a bonus payment (0042-LIQF-046) + +### Transfers example + +Example 1, generated with [supplementary worksheet](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY) [internal only]. Values should match up to rounding used by `core` (0042-LIQF-055): +| LP | penalty fraction | LP-per-market fee accounts balance | 1st transfer amt | 2nd (bonus) transfer amt | +| --- | -------------- | -------------- | -------------- | -------------- | +| LP1 | 0 | 1000 | 1000 | 24673.94095 | +| LP2 | 0.05 | 100 | 95 | 2344.02439 | +| LP3 | 0.6 | 7000 | 2800 | 69087.03466 | +| LP4 | 1 | 91900 | 0 | 0 | diff --git a/protocol/features.json b/protocol/features.json index e323c4844..3b33bf8f8 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -379,7 +379,8 @@ "0026-AUCT-020", "0026-AUCT-021", "0026-AUCT-022", - "0034-PROB-004" + "0034-PROB-004", + "0042-LIQF-055" ] }, "Batch change proposals": { From 7b5a2e8e94702b6e942d68732b63434c2dc46600 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 6 Sep 2023 16:48:21 +0100 Subject: [PATCH 556/649] fix: Spot ACs in features.json file (#1931) * fix: Spot ACs in features.json file moves the spot related SLA ACs into the spot feature for tracking * fix: dupes --- protocol/features.json | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 3b33bf8f8..b83f9ad29 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -333,25 +333,15 @@ "0044-LIME-061", "0044-LIME-062", "0044-LIME-063", - "0044-LIME-064", "0044-LIME-065", - "0044-LIME-066", "0044-LIME-067", - "0044-LIME-068", "0044-LIME-069", - "0044-LIME-070", "0044-LIME-071", - "0044-LIME-072", "0044-LIME-073", - "0044-LIME-074", "0044-LIME-075", - "0044-LIME-076", "0044-LIME-077", - "0044-LIME-078", "0044-LIME-079", - "0044-LIME-080", "0044-LIME-081", - "0044-LIME-082", "0044-LIME-083", "0044-LIME-084", "0044-LIME-085", From bbb768571991609f70665f97033e97674938261a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Thu, 7 Sep 2023 14:32:24 +0100 Subject: [PATCH 557/649] feat: update AC 0044-LIME-026 --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 7817d7956..891d5a4f1 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -334,7 +334,7 @@ In the case of spot markets it will be transferred into the network treasury for - For a futures market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - - `LP2` places a transaction to reduce their stake by `100`, + - `LP2` places a transaction to reduce their stake by `100`, and then wait till end of the epoch so the engine can pick up the reduction of their stake, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) From 69e48a3f89e2179daf5c980f5e72a4ae66b52550 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Date: Thu, 7 Sep 2023 15:01:54 +0100 Subject: [PATCH 558/649] feat: update AC Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 891d5a4f1..0385b0a17 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -334,7 +334,7 @@ In the case of spot markets it will be transferred into the network treasury for - For a futures market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: - `LP1` places a transaction to reduce their stake by `30` - - `LP2` places a transaction to reduce their stake by `100`, and then wait till end of the epoch so the engine can pick up the reduction of their stake, + - `LP2` places a transaction to reduce their stake by `100`, and then wait until end of the epoch, - `LP1` places a transaction to update their reduction to `100` `LP2` will receive a full `100` stake back whilst `LP1` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (0044-LIME-026) - When LP is committed they are obliged to provide liquidity equal to their commitment size on both sides of the order book (0044-LIME-027) From f568f5b6c4165fe31e497cc16185cd97f70eed0f Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Thu, 7 Sep 2023 17:45:17 +0100 Subject: [PATCH 559/649] fix: Minor spelling corrections, plus two new ACs for testing perp data is visible in REST and GRPC. --- protocol/0001-MKTF-market_framework.md | 5 ++++- protocol/0053-PERP-product_builtin_perpetual_future.md | 4 ++-- protocol/features.json | 2 ++ 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index fe446eebf..03fa15a16 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -233,7 +233,10 @@ Each market can have exactly one market as a *successor* market. - Details of a market's product must be available for each market through the API (0001-MKTF-002) - Details of a market's tradable instrument must be available for each market through the API (0001-MKTF-003) - Market framework can report position decimal places 0001-MKTF-004 -- It is possible to designate a market as perpetual; this is visible via APIs in market data. 0001-MKTF-005 +- It is possible to designate a market as perpetual; this is visible via APIs in market data. + - GRPC 0001-MKTF-005 + - REST 0001-MKTF-011 + - GraphQL 0001-MKTF-012 - A market may have a "parent" market; the parent market is visible via APIs in the form of the `marketID` of the parent market. 0001-MKTF-006 - A market may have a "successor" market; the parent market is visible via APIs in the form of the `marketID` (or `proposalID`) of the successor market. 0001-MKTF-007 - A parent and successor markets must have the same: diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 2ab10a9b2..f1b0b1be5 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -81,11 +81,11 @@ Every time a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.m ### 4.3. Periodic settlement -When the `settlement_schedule` event is received we need to calculated the funding payment. Store the current vega time as `funding_period_end`. +When the `settlement_schedule` event is received we need to calculate the funding payment. Store the current vega time as `funding_period_end`. If there are no oracle data points with a timestamp less than `funding_period_end` available then funding payment is skipped and `funding_period_start` gets overwritten with `funding_period_end`. -If such points available then the calculations discussed in the following subsections get executed and funding payments get exchanged. +If such points are available then the calculations discussed in the following subsections get executed and funding payments get exchanged. #### TWAP spot price calculation diff --git a/protocol/features.json b/protocol/features.json index b83f9ad29..99303993d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -191,6 +191,8 @@ "milestone": "cosmic-elevator-2", "acs": [ "0001-MKTF-005", + "0001-MKTF-011", + "0001-MKTF-012", "0053-PERP-001", "0053-PERP-002", "0053-PERP-003", From 1a586a9c64dc2fbefe1d190562a24eb2cae5b245 Mon Sep 17 00:00:00 2001 From: Peter Barrow Date: Thu, 7 Sep 2023 18:54:32 +0100 Subject: [PATCH 560/649] fix: logic fix --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 0385b0a17..2db6417ad 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -321,7 +321,7 @@ and in the case of spot markets into the network treasury for the asset (0044-LIME-049) - A liquidity provider who reduces their liquidity provision such that the total stake on the market is still above the target stake after reduction will have no penalty applied and will receive their full reduction in stake back at the end of the epoch. (0044-LIME-022) -- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake < total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) +- For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake > total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-045) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) - In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-044) From ab053562094060851ad94b6b6a7cd4866a108af4 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 15:29:38 +0100 Subject: [PATCH 561/649] fix: align AC with implementation --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 2bba54bb9..19d802cdb 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -377,7 +377,7 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch always meets their liquidity provision requirements then they will have a `fraction_of_time_on_book == 1` and no penalty will be applied to their liquidity fee payments at the end of the epoch (0042-LIQF-035) - If an LP has an active liquidity provision at the start of an epoch and throughout the epoch meets their liquidity provision requirements less than `market.liquidity.commitmentMinTimeFraction` fraction of the time then they will have a full penalty and will receive `0` liquidity fee payments at the end of the epoch (0042-LIQF-049) - - An LP has an active liquidity provision at the start of an epoch. The penalty rate for said LP over the previous `2` epochs is `0.75`. During the epoch `market.liquidity.performanceHysteresisEpochs` is set to `3`. Throughout the current epoch the LP meets their liquidity provision requirements so they will have `fraction_of_time_on_book == 1`. The penalty applied to fee distribution at epoch end will be `0.375`. (0042-LIQF-053) + - An LP has an active liquidity provision at the start of an epoch. The penalty rate for said LP over the previous `2` epochs is `0.75`. During the epoch `market.liquidity.performanceHysteresisEpochs` is set to `3`. Throughout the current epoch the LP meets their liquidity provision requirements so they will have `fraction_of_time_on_book == 1`. The penalty applied to fee distribution at epoch end will be `0` and will not consider the previous epochs. (0042-LIQF-053) - When `market.liquidity.performanceHysteresisEpochs > 1`: From 93ad31d5a2f83bc9af33575daadce453ac86e03e Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 11 Sep 2023 11:03:12 +0100 Subject: [PATCH 562/649] Fix/fee calc step is netparam (#1937) * fix: fee distribution time step is a netparam * fix: fee distribution time step is a netparam * fix: fee distribution time step is a netparam * fix: fee distribution time step is a netparam --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 12 +++++------- protocol/0044-LIME-lp_mechanics.md | 7 +++---- protocol/features.json | 1 - 3 files changed, 8 insertions(+), 12 deletions(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 2bba54bb9..dc33e8eef 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -192,9 +192,7 @@ Otherwise calculate fractional instantaneous liquidity score for each committed `fractional instantaneous liquidity score = instantaneous liquidity score / total` -If `market.liquidity.providers.fee.calculationTimeStep` is set to `0` for a given market, then for each committed LP within that market `liquidity score` is set to `fractional instantaneous liquidity score`. - -Otherwise whenever a new LP fee distribution period starts set a counter `n=1`. +Whenever a new LP fee distribution period starts set a counter `n=1`. Then on every Vega time change, after `fractional instantaneous liquidity score` has been obtained for all the committed LPs, update: `liquidity score <- ((n-1)/n) x liquidity score + (1/n) x fractional instantaneous liquidity score` @@ -206,8 +204,8 @@ The liquidity score should always be rounded to 10 decimal places to prevent spu On every trade, liquidity fee should be collected immediately into the market's aggregate LP fee account. The account is under control of the network and funds from this account will be transferred to the owning LP party according to the mechanism below. -A market parameter `market.liquidity.providers.fee.calculationTimeStep` will control how often fees are distributed from the market's aggregate LP fee account. -Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providers.fee.calculationTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. +A network parameter `market.liquidity.providersFeeCalculationTimeStep` will control how often fees are distributed from the market's aggregate LP fee account. +Starting with the end of the opening auction the clock starts ticking and then rings every time `market.liquidity.providersFeeCalculationTimeStep` has passed. Every time this happens the balance in this account is transferred to the liquidity provider's general account for the market settlement asset. The liquidity fees are transferred from the market's aggregate LP fee account into the LP-per-market fee account, pro-rata depending on the `LP i equity-like share` multiplied by `LP i liquidity score` scaled back to `1` across all LPs at a given time. @@ -327,7 +325,7 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - The examples provided result in the given outcomes. (0042-LIQF-008) - The total amount of liquidity fee distributed is equal to the most recent `liquidity-fee-factor` x `notional-value-of-all-trades` (0042-LIQF-011) - Liquidity providers with a commitment of 0 will not receive a share of the fees (0042-LIQF-012) -- If a market has its `market.liquidity.providers.fee.calculationTimeStep` parameter set to more than `0` and such market settles then the fees are distributed as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) +- When a market settles any fees from any intermediate fee accounts are distributed as if the epoch ended as part of the settlement process, see [market lifecycle](./0043-MKTL-market_lifecycle.md). Any settled market has zero balances in all the LP fee accounts. (0042-LIQF-014) - All liquidity providers with `average fraction of liquidity provided by committed LP > 0` in the market receive a greater than zero amount of liquidity fee. The only exception is if a non-zero amount is rounded to zero due to integer representation. (0042-LIQF-015) - After fee distribution, if there is a remainder in the liquidity fee account and the market is not being settled, it should be left in the liquidity fee account and carried over to the next distribution window. (0042-LIQF-032) @@ -360,7 +358,7 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - If an LP has virtual stake of `11000` and stake of `10000` on a parent marketID=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `10000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake of `11000` and stake of `10000` on `m2`. (0042-LIQF-031) - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `20000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake which must be result of the virtual stake obtained from `m1` with the `delta=10000` added on, so virtual stake of `21000`, assuming all other LPs committed exactly the stake they had on `m1`. (0042-LIQF-048) - If an LP has virtual stake of `11000` and stake of `10000` on a parent `marketID`=`m1` and a new market is proposed and enacted as `m2` with `m1` as its parent market and the LP submits a commitment of `5000` to `m2` during the "Pending" period, see [lifecycle](./0043-MKTL-market_lifecycle.md) then for the duration of the first `market.value.windowLength` after the opening auction ends the LP has virtual stake obtained from `m1` with the `delta=-5000` added on (i.e. 5000 removed). (0042-LIQF-033) -- If `market.liquidity.providers.fee.calculationTimeStep > 0` for a given market and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income from that market compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) +- If `market.liquidity.providersFeeCalculationTimeStep > 0` for a given market and an LP submits a new liquidity commitment halfway through the time interval then they receive roughly 1/2 the fee income from that market compared with the next time interval when they maintain their commitment (and the traded value is the same in both time intervals). (0042-LIQF-034) ### Calculating SLA Performance diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 2db6417ad..77aec9f7d 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,7 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. -- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value `0`. Maximum valid value `validators.epoch.length`. +- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value is anything strictly more than `0`. Maximum valid value `validators.epoch.length`. ### Market parameters @@ -355,8 +355,7 @@ In the case of spot markets it will be transferred into the network treasury for - During continuous trading an LP can submit a transaction to decrease commitment but it will only happen at the end of current epoch. (0044-LIME-101) - For a market that is in continuous trading and LP has committed liquidity - - when `market.liquidity.providers.fee.calculationTimeStep` is set to `0` any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block (0044-LIME-061) - - if `market.liquidity.providers.fee.calculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providers.fee.calculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) + - if `market.liquidity.providersFeeCalculationTimeStep` is set to `10s` and `validators.epoch.length` is set to `15s`, during the first `10` seconds of the current epoch parameter change `market.liquidity.providersFeeCalculationTimeStep = 3s` is enacted, at the end of the epoch any funds that are in `ACCOUNT_TYPE_FEES_LIQUIDITY` account will be distributed to `ACCOUNT_TYPE_LP_LIQUIDITY_FEES` on the next block. For the next epoch the distribution will take place at `3` second intervals (0044-LIME-062) - For a market that is in continuous trading if a new LP has active buy and sell orders on the market then makes a liquidity commitment to that market, at the start of the next epoch the active orders will count towards the LPs liquidity commitment. (0044-LIME-090) - If an LP with a liquidity provision and active orders on a market cancels their liquidity provision (orders remain active), after the cancellation penalty (if it applies at end of epoch) at the end of the next epoch the LP will not accrue any rewards for trades on the market. (0044-LIME-097) - Consider a market where `market.liquidity.priceRange = 0.05 (5%)` and which is in continuous trading with a mid price of 5. There is an LP who's committed to provide liquidity. They place a buy order at a price of 4.75 and a sell order at a price of 5.25 (with sufficient volume). As the epoch progresses, if the market parameter is altered to `market.liquidity.priceRange = 0.01` (1%), then upon the culmination of the current epoch, the LP will still have fulfilled their committed notional volume, rendering them exempt from a bond penalty. (0044-LIME-091) @@ -416,7 +415,7 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidityV2.sla.nonPerformanceBondPenaltySlope` valid values: `>=0`, `<=1000` default value of `2` (0044-LIME-040) - `market.liquidityV2.sla.nonPerformanceBondPenaltyMax` valid values: `>=0`, `<=1` default value of `0.5` (0044-LIME-041) - `market.liquidityV2.stakeToCcyVolume` valid values: `>=0`, `<=100` default value of `1` (0044-LIME-042) - - `market.liquidity.providers.fee.calculationTimeStep` valid values: `>=0`, `<= validators.epoch.length` default value of `60m` (0044-LIME-100) + - `market.liquidity.providersFeeCalculationTimeStep` valid values: `>0`, `<= validators.epoch.length` default value of `60m` (0044-LIME-100) #### Market parameters validation diff --git a/protocol/features.json b/protocol/features.json index 99303993d..a5835d144 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -332,7 +332,6 @@ "0044-LIME-033", "0044-LIME-034", "0044-LIME-036", - "0044-LIME-061", "0044-LIME-062", "0044-LIME-063", "0044-LIME-065", From eb5108be57db68bd54d0d7a1c2d304f2b8aa6749 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Mon, 11 Sep 2023 11:25:07 +0100 Subject: [PATCH 563/649] fix: revert the deployment name changes in the features.json file (#1943) --- protocol/features.json | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index a5835d144..53322bcde 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -1,6 +1,6 @@ { "Iceberg Orders": { - "milestone": "cosmic-elevator-1", + "milestone": "deployment-1", "acs": [ "0014-ORDT-039", "0014-ORDT-007", @@ -39,7 +39,7 @@ ] }, "Stop Orders": { - "milestone": "cosmic-elevator-1", + "milestone": "deployment-1", "acs": [ "0014-ORDT-041", "0014-ORDT-042", @@ -83,7 +83,7 @@ ] }, "Successor Markets": { - "milestone": "cosmic-elevator-1", + "milestone": "deployment-1", "acs": [ "0001-MKTF-006", "0001-MKTF-007", @@ -127,7 +127,7 @@ ] }, "Transfers by governance": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0028-GOVE-073", "0028-GOVE-074", @@ -188,7 +188,7 @@ ] }, "Perpetuals": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0001-MKTF-005", "0001-MKTF-011", @@ -236,7 +236,7 @@ ] }, "Ethereum Oracles": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0082-ETHD-001", "0082-ETHD-002", @@ -281,7 +281,7 @@ ] }, "SLA": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0042-LIQF-032", "0042-LIQF-050", @@ -375,7 +375,7 @@ ] }, "Batch change proposals": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0028-GOVE-145", "0028-GOVE-146", @@ -385,7 +385,7 @@ ] }, "Referral program": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0083-RFPR-001", "0083-RFPR-002", @@ -454,7 +454,7 @@ ] }, "Market governance": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0028-GOVE-064", "0028-GOVE-069", @@ -480,7 +480,7 @@ ] }, "Spot": { - "milestone": "plazzo", + "milestone": "deployment-3", "acs": [ "0080-SPOT-001", "0080-SPOT-002", From 0769dc761dd5031b0ad5e4b719295bee89311b87 Mon Sep 17 00:00:00 2001 From: Karel Moravec Date: Mon, 11 Sep 2023 14:31:46 +0200 Subject: [PATCH 564/649] fix: align with core --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 77aec9f7d..5fa7913c5 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,7 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. -- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value is anything strictly more than `0`. Maximum valid value `validators.epoch.length`. +- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value is anything strictly more than `1s`. Maximum valid value `validators.epoch.length`. ### Market parameters From bcc712f62b2a914141ca5ca1825e319f58abddc5 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 11 Sep 2023 16:07:32 +0100 Subject: [PATCH 565/649] fix: small correction --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 5fa7913c5..0a1412780 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -23,7 +23,7 @@ Valid values: any decimal number `>= 0` with a default value of `0.1`. - `market.liquidity.earlyExitPenalty` (decimal ≥0), sets how much LP forfeits of their bond in case the market is below target stake and they wish to reduce their commitment. If set to `0` there is no penalty for early exit, if set to `1` their entire bond is forfeited if they exit their entire commitment, if set >1, their entire bond will be forfeited for exiting `1/earlyExitPenalty` of their commitment amount. - `market.liquidity.probabilityOfTrading.tau.scaling` sets how the probability of trading is calculated from the risk model; this is used to [measure the relative competitiveness of LPs supplied volume](0042-LIQF-setting_fees_and_rewarding_lps.md). - `market.liquidity.minimum.probabilityOfTrading.lpOrders` sets a lower bound on the result of the probability of trading calculation. -- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value is anything strictly more than `1s`. Maximum valid value `validators.epoch.length`. +- `market.liquidity.feeCalculationTimeStep` (time period e.g. `1m`) controls how often the quality of liquidity supplied by the LPs is evaluated and fees arising from that period are earmarked for specific parties. Minimum valid value is anything more than or equal `1s`. Maximum valid value `validators.epoch.length`. ### Market parameters From bd924a3a2a6d2d7080f523918dc8214622404f21 Mon Sep 17 00:00:00 2001 From: Jake Bennett Date: Mon, 11 Sep 2023 16:53:02 +0100 Subject: [PATCH 566/649] fix: Add tests for perpetuals doing protocol upgrade, checkpoint and network history. (#1940) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0053-PERP-product_builtin_perpetual_future.md | 3 +++ protocol/features.json | 3 +++ 2 files changed, 6 insertions(+) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index f1b0b1be5..beab7b5fa 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -230,3 +230,6 @@ In both cases the estimates are for a hypothetical position of size 1. 1. No data relating to funding payment is available until the perpetual futures market leaves the opening auction. (0053-PERP-018) 1. For the ongoing period the following data is available via the API: funding period start time, estimate time, funding rate estimate, funding payment estimate, external (spot) price TWAP to-date, internal (mark) price TWAP to-date. (0053-PERP-019) 1. For each of the fully completed past funding periods the following data is available (subject to data-node's retention settings): funding period start time, funding period end time, funding rate, funding payment, external (spot) price TWAP, internal (mark) price TWAP. (0053-PERP-020) +1. A perpetual market which is active and has open orders, continues to function after protocol upgrade, and preserves all market settings and statistics. (0053-PERP-021) +1. A perpetual market which is active and has open orders, after checkpoint restart, is in opening auction. All margin accounts are transferred to general accounts. (0053-PERP-022) +1. A perpetual market which is active and has open orders. Wait for a new network history snapshot to be created. Load a new data node from network history. All market data is preserved. (0053-PERP-023) diff --git a/protocol/features.json b/protocol/features.json index 53322bcde..280b8052f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -208,6 +208,9 @@ "0053-PERP-018", "0053-PERP-019", "0053-PERP-020", + "0053-PERP-021", + "0053-PERP-022", + "0053-PERP-023", "0043-MKTL-009", "0051-PROD-007", "0051-PROD-008", From 8ec9eb565023dbd9807df2118669e9046eadfe66 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 12 Sep 2023 13:29:49 +0100 Subject: [PATCH 567/649] chore: add AC codes to referral ACs in fees spec (#1947) * chore: add AC codes to referral ACs in fees spec * chore: add Codes --- protocol/0029-FEES-fees.md | 12 ++++++------ protocol/features.json | 8 +++++++- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 8ed578d9b..54b73c193 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -159,24 +159,24 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ### Applying benefit factors -1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. +1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. (0029-FEES-023) - `infrastructure_referral_fee_discount` - `liquidity_fee_referral_discount` - `maker_fee_referral_discount` -1. Referee discounts are correctly calculated and applied for each fee component when exiting an auction. +1. Referee discounts are correctly calculated and applied for each fee component when exiting an auction. (0029-FEES-024) - `infrastructure_fee_referral_discount` - `liquidity_fee_referral_discount` -1. Referrer rewards are correctly calculated and transferred for each fee component during continuous trading. +1. Referrer rewards are correctly calculated and transferred for each fee component during continuous trading. (0029-FEES-025) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` - `maker_fee_referral_reward` -1. Referrer rewards are correctly calculated and transferred for each fee component when exiting an auction. +1. Referrer rewards are correctly calculated and transferred for each fee component when exiting an auction. (0029-FEES-026) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` -1. Volume discount rewards are correctly calculated and transferred for each taker fee component during continuous trading. +1. Volume discount rewards are correctly calculated and transferred for each taker fee component during continuous trading. (0029-FEES-027) - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` - `maker_fee_volume_discount` -1. Volume discount rewards are correctly calculated and transferred for each fee component when exiting an auction. +1. Volume discount rewards are correctly calculated and transferred for each fee component when exiting an auction. (0029-FEES-028) - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` diff --git a/protocol/features.json b/protocol/features.json index 280b8052f..77ac18c69 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -453,7 +453,13 @@ "0084-VDPR-013", "0084-VDPR-014", "0084-VDPR-015", - "0084-VDPR-016" + "0084-VDPR-016", + "0029-FEES-023", + "0029-FEES-024", + "0029-FEES-025", + "0029-FEES-026", + "0029-FEES-027", + "0029-FEES-028" ] }, "Market governance": { From ec66c0bf242505db97a025bae9bb88a4a0e1e66f Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 12 Sep 2023 12:32:42 +0100 Subject: [PATCH 568/649] refactor: move acs to correct section --- protocol/0083-RFPR-on_chain_referral_program.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 2880407be..bda043a94 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -415,6 +415,12 @@ The Estimate Fees API should now calculate the following additional information: - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug (0083-RFPR-011). - Proposal for program B accepted and overrides program A the first epoch after 1st June (0083-RFPR-012). - Program is closed first epoch after 31st Aug, there should be no active proposals (0083-RFPR-013). +1. Updating any of the following network parameters whilst there is an active referral program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future referral program proposals. + - `referralProgram.maxReferralTiers` (0083-RFPR-041) + - `referralProgram.maxReferralRewardFactor` (0083-RFPR-042) + - `referralProgram.maxReferralDiscountFactor` (0083-RFPR-043) + - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` (0083-RFPR-044) + - `referralProgram.minStakedVegaTokens` (0083-RFPR-045) ### Referral set mechanics @@ -430,12 +436,6 @@ The Estimate Fees API should now calculate the following additional information: - all referees should not receive any discount on their taker fees (0083-RFPR-019). 1. If the referrer of a referral set currently not eligible for benefits re-stakes enough tokens, their team will become eligible for benefits from the start of the next epoch (0083-RFPR-020). 1. When creating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory (0083-RFPR-021). -1. Updating any of the following network parameters whilst there is an active referral program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future referral program proposals. - - `referralProgram.maxReferralTiers` (0083-RFPR-041) - - `referralProgram.maxReferralRewardFactor` (0083-RFPR-042) - - `referralProgram.maxReferralDiscountFactor` (0083-RFPR-043) - - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` (0083-RFPR-044) - - `referralProgram.minStakedVegaTokens` (0083-RFPR-045) #### Updating a referral set From d1474f82ae9095ca6db6877350c7566e1b1e1c8d Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 12 Sep 2023 13:40:29 +0100 Subject: [PATCH 569/649] feat: align acs with implementation --- .../0083-RFPR-on_chain_referral_program.md | 30 ++++++++++++------- protocol/features.json | 1 - 2 files changed, 20 insertions(+), 11 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index bda043a94..69250e5db 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -439,19 +439,29 @@ The Estimate Fees API should now calculate the following additional information: #### Updating a referral set -1. If a party is currently a referrer, the party can **update** a referral set by submitting a signed `UpdateReferralSet` transaction (0083-RFPR-022). -1. If a party submits an `UpdateReferralSet` transaction for a referral set they are not the referrer off, the transaction should be rejected (0083-RFPR-023). -1. When updating a referral set a party should be able to designate it as a team. If they do, `team_details` and all nested fields are mandatory (0083-RFPR-024). +1. If a party is currently the referrer of a referral set from which a team **has not** yet been created, the party can **create** a team by submitting a signed `UpdateReferralSet` transaction and setting `is_team=True` (0083-RFPR-022). +1. If a party is currently the referrer of a referral set from which a team **has** already been created, the party can **update** a team by submitting a signed `UpdateReferralSet` transaction specifying the fields they want to update (0083-RFPR-023). +1. If a party submits an `UpdateReferralSet` transaction for a referral set they are not the referrer off, the transaction should be rejected (0083-RFPR-024). #### Applying a referral code -1. If a party **is not** currently a **referee**, the party can immediately become associated with a referral set by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-025). -1. If a party **is** currently a **referee**, the party can become associated with a new referral set (at the start of the next epoch) by submitting a signed `ApplyReferralCode` transaction (0083-RFPR-026). -1. If a party **is** currently a **referee** and submits multiple `ApplyReferralCode` transactions in an epoch, the latest valid `ApplyReferralCode` transaction will be applied (0083-RFPR-027). -1. If a party **is** currently a **referee** and becomes associated with a new referral set, their fees should still be paid out to the referrer of the original referral set they were associated with (0083-RFPR-048). -1. If one or more of the following conditions are not met, any `ApplyReferralCode` transaction should be rejected (0083-RFPR-028). - - a party must not currently be a **referrer** (0083-RFPR-029). - - the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the `team` to closed (0083-RFPR-030). +1. If a party **is not** currently a **referee**, if they submit a signed `ApplyReferralCode` transaction then: (0083-RFPR-025) + + - the party **will** be added to the associated referral set. + - the party **will** be added to the associated team (if one exists and the team is not closed). + +1. If a party **is** currently a **referee** (and the referrer **is** meeting the staking requirement), if they submit a signed `ApplyReferralCode` transaction then: (0083-RFPR-026) + + - the party **will not** be added to the associated referral set. + - the party **will** be added to the associated team (if one exists and the team is not closed). + +1. If a party **is** currently a **referee** (and the referrer **is not** meeting the staking requirement), if they submit a signed `ApplyReferralCode` transaction then: (0083-RFPR-027). + + - the party **will** be added to the associated referral set. + - the party **will** be added to the associated team (if one exists and the team is not closed). + +1. An `ApplyReferralCode` transaction should be rejected if the party is a **referrer** (0083-RFPR-029). +1. An `ApplyReferralCode` transaction should be rejected if the `id` in the `ApplyReferralCode` transaction is for a referral set which is designated as a team and has set the team to be closed (0083-RFPR-030). #### Epoch and running volumes diff --git a/protocol/features.json b/protocol/features.json index 77ac18c69..66ec5c6c7 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -417,7 +417,6 @@ "0083-RFPR-025", "0083-RFPR-026", "0083-RFPR-027", - "0083-RFPR-028", "0083-RFPR-029", "0083-RFPR-030", "0083-RFPR-031", From 2b29633e429b5ad717dc2ba29c5fb384f483b8c4 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 12 Sep 2023 13:47:23 +0100 Subject: [PATCH 570/649] fix: remove legacy ac --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 66ec5c6c7..508d3e663 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -436,7 +436,6 @@ "0083-RFPR-045", "0083-RFPR-046", "0083-RFPR-047", - "0083-RFPR-048", "0084-VDPR-001", "0084-VDPR-002", "0084-VDPR-003", From b4b7160e44ee7164a3e95879e9c27f28f515e8ee Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 12 Sep 2023 13:55:46 +0100 Subject: [PATCH 571/649] chore: move batch transfers out of deployment 2 (#1948) --- protocol/features.json | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 77ac18c69..dff6c151d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -377,16 +377,6 @@ "0042-LIQF-055" ] }, - "Batch change proposals": { - "milestone": "deployment-2", - "acs": [ - "0028-GOVE-145", - "0028-GOVE-146", - "0028-GOVE-147", - "0028-GOVE-148", - "0028-GOVE-149" - ] - }, "Referral program": { "milestone": "deployment-2", "acs": [ @@ -487,6 +477,16 @@ "0028-GOVE-151", "0028-GOVE-152" ] + }, + "Batch change proposals": { + "milestone": "deployment-3", + "acs": [ + "0028-GOVE-145", + "0028-GOVE-146", + "0028-GOVE-147", + "0028-GOVE-148", + "0028-GOVE-149" + ] }, "Spot": { "milestone": "deployment-3", From e105debd584ec35774bb2075ebeaf0590df2f249 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 13 Sep 2023 11:11:42 +0200 Subject: [PATCH 572/649] refactor: amend margin formula --- protocol/0053-PERP-product_builtin_perpetual_future.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index beab7b5fa..13a315ebc 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -175,11 +175,11 @@ If periodic settlement data happens whilst market is in auction of any other typ ### 5. Margin considerations To assure adequate solvency we need to include the estimate of the upcoming funding payment in maintenance margin estimate for the party. Let $t_{k-1}$ be the time of the last funding payment. Let $t$ be current time ($t < t_k$). -Calculate $G_t$ as the [funding payment](#43-periodic-settlement) between $t_{k-1}$ and $t$. +Calculate $G_t$ as the [funding payment](#43-periodic-settlement) between $t_{k-1}$ and $t$, and consider open volume of the party for which the margin is being calculated. For perpetual futures markets set the maintenance margin as: ```math -m^{\text{maint (perps)}}_t = m^{\text{maint}}_t + \text{margin funding factor} \cdot \max(0,G_t), +m^{\text{maint (perps)}}_t = m^{\text{maint}}_t + \text{margin funding factor} \cdot \max(0, \text{open volume}\ cdot G_t), ``` where $m^{\text{maint}}_t$ is the current maintenance margin as per the [margin spec](./0019-MCAL-margin_calculator.md) From 3e49b50d98b1450a7dc4e6303e63142d968159d9 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 13 Sep 2023 10:58:26 +0100 Subject: [PATCH 573/649] feat: add clarification when no indicative price --- protocol/0044-LIME-lp_mechanics.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 0a1412780..20da423f0 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -211,6 +211,12 @@ We calculate the volume of notional that is in the range (1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) <= price levels <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). ``` +If there is no 'indicative uncrossing price' then any price should count, and the price range should be + +```text +-infinity <= price levels <= infinity +``` + If this is greater than or equal to `liquidity_required` then the LP is meeting the committed volume of notional. From 052bf5792b120f428faf040df69288a070b01024 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 13 Sep 2023 11:23:12 +0100 Subject: [PATCH 574/649] fix/enacted doesn't mean leaves opening auction --- protocol/0081-SUCM-successor_markets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index 3e947f838..eb9bc26b5 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -86,7 +86,7 @@ Successor markets can be enacted when the parent market is in opening auction. T A successor market proposal can be enacted when the parent market is in one of the following states: Pending, Suspended, Active, Trading terminated or Settled (settled within the successor time window) (0081-SUCM-010) -When a successor market is enacted (i.e. leaves the opening auction), all other related successor market proposals, in the state "pending" or "proposed", are automatically rejected. Any LP submissions associated with these proposals are cancelled, and the funds are released (0081-SUCM-011) +When a successor market is enacted, all other related successor market proposals, in the state "pending" or "proposed", are automatically rejected. Any LP submissions associated with these proposals are cancelled, and the funds are released (0081-SUCM-011) With two successor markets in opening auction, that have the same parent market, and one additional market in the state "Proposed". Get one of the two markets to leave the opening auction (passage of time, LP commitment, crossing trade). The other market in auction and the proposed market should both be "Rejected" and all LP funds will be released (0081-SUCM-014) From 3559569773bc1c81d30fe5ff781be4d1248bdd37 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Wed, 13 Sep 2023 12:02:53 +0100 Subject: [PATCH 575/649] fix: remove mentions of maturity --- protocol/0001-MKTF-market_framework.md | 3 ++- protocol/0043-MKTL-market_lifecycle.md | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/protocol/0001-MKTF-market_framework.md b/protocol/0001-MKTF-market_framework.md index 03fa15a16..1d0599a5f 100644 --- a/protocol/0001-MKTF-market_framework.md +++ b/protocol/0001-MKTF-market_framework.md @@ -157,7 +157,8 @@ struct InstrumentMetadata { } enum Product { - // maturity should be some sort of DateTime, settlement_asset is however we refer to crypto-assets (collateral) on Vega + // Oracle will include both info on how trading terminates and settlement data + // settlement_asset is asset id Future { oracle: Oracle, settlement_asset: String }, // EuropeanOption {}, // SmartProduct {}, diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 20b01f8fb..7abfffc71 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -26,7 +26,7 @@ A market can progress through a number of statuses through its life. The overall | Rejected | No | No trading | Outcome of governance votes is to reject the market | N/A | Pending | Yes | Opening auction | Governance vote passes/wins | Governance vote (to close) OR enactment date reached | Cancelled | No | No trading | Market triggers cancellation condition | N/A -| Active | Yes | Normal trading | Enactment date reached and usual auction exit checks pass | Governance vote (to close) OR maturity of market +| Active | Yes | Normal trading | Enactment date reached and usual auction exit checks pass | Governance vote (to close) OR trigger for trading terminated for of market | Suspended | Yes | Exceptional auction | Price monitoring or liquidity monitoring trigger, or product lifecycle trigger | Exit conditions met per monitoring spec. that triggered it, no other monitoring triggered or governance vote if allowed (see below) | Closed | No | No trading | Governance vote (to close) | N/A | Trading Terminated | No | No trading | Defined by the product (i.e. from a product parameter, specified in market definition, giving close date/time) | Settlement event commences From 2f933ee8ff14c60fbcb2f7956c0e37f9605aa4d9 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Wed, 13 Sep 2023 13:33:31 +0100 Subject: [PATCH 576/649] Update comsic from master (#1956) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport * feat: update FOK MO reduce-only * fix: Add some more cancel order ACs. * Update protocol/0033-OCAN-cancel_orders.md Co-authored-by: Tom * feat: Add a test for checking performance scores when checkpoint rest… (#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces). * feat: Add a test for checking performance scores when checkpoint rest… (#1637) * feat: Add a test for checking performance scores when checkpoint restart happens in a new epoch. * fix: Typo. * chore: Fix indentation (tabs/spaces). * Update 0069-VCBS-validators_chosen_by_stake.md (#1653) Deleted half an AC as discussed on slack (as the number for the performance score didn't make sense here) * Amend price monitoring ACs (#1660) * refactor: update ACs * chore: tell approbation to leave me alone * chore: try again * refactor: rephrase AC * refactor: clarify * refactor: fix spelling * feat: update datanode spec with functionality to rollback node and functionality to fetch csv files containing network history (#1659) * feat: update datanode spec with functionality to rollback node and functionality to fetch csv files containing network history * fix: spell checker --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * spec: draft for time-based mempool pruning (#1645) * spec: draft for time-based mempool pruning Signed-off-by: Elias Van Ootegem * spec: spelling Signed-off-by: Elias Van Ootegem * Spelling + clarify how block height is determined Signed-off-by: Elias Van Ootegem * spec: add some additional ACs, remove mention of TxV4, clarify that transaction data includes block hash in addition to block height Signed-off-by: Elias Van Ootegem * complete acceptance criteria Signed-off-by: Elias Van Ootegem * fix typo Signed-off-by: Elias Van Ootegem --------- Signed-off-by: Elias Van Ootegem Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * re-word ac * chore: Add decision notes template (#1658) * chore: Add decision notes template Added a decision template based loosely on the [Any Decision Records](https://adr.github.io/madr/) template Also updated some MD linting to allow sibling duplicated header titles and double spacing to make reading easier. * fix: Spelling error * feat: update for distributing remainder of liq fee * fix: correct AC * refactor: address feedback * add spec for current collateral * clarify total margin available * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * Update user-interface/7001-COLL-collateral.md Co-authored-by: Michael * add asset file * Add ACs for asset detail dialog and link up with collateral spec * add suggested sort order per account type * fix: 005 AC code link (#1671) * fix: mempool pruning with PoW only * fix: linting errors * refactor: add liquidation price estimate * refactor: add ACs * refactor: another AC * refactor: cosmetic change * Update 0045-DSRC-data_sourcing.md (#1674) * Update 0045-DSRC-data_sourcing.md * Update 0045-DSRC-data_sourcing.md * Wording of timestamp AC --------- Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Barney Mannerings * add spec for current functionality fo fills data grid * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * Make notional value of feels a could * Update user-interface/7005-FILL-fills.md Co-authored-by: Michael * add clarification on user role for trades during continuos vs auction * fix: typo in ac number * feat: update typo in 0061 * feat: add explaination on ersatz validators * feat: correct typos * feat: typo * Update user-interface/7005-FILL-fills.md * add browser wallet spec as part of approbation set up * chore: fix typo and add browser specs to app.json * chore: add browser wallet to categories, hopefully in the right place * chore: Update 0033-OCAN-cancel_orders.md (#1686) * feat: update BRIE specs (#1654) * feat: update BRIE specs Signed-off-by: Jeremy Letang * chore: update spelling and linting * feat: update BRIE specs Signed-off-by: Jeremy Letang * chore: update spelling and linting * fix: spelling and lint and rebase * fix: spelling --------- Signed-off-by: Jeremy Letang Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * chore: Update cosmic elevator branch from master (#1688) * refactor: let max oi drop during auciton * fix: duplicate AC codes in 0069-VCBS (#1536) (#1537) * Update `cosmicelevator` branch from `master` branch (#1550) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Update cosmicelevator branch from master to keep up-to-date (#1560) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * chore: Update cosmicelevator from master branch (#1564) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * chore: Update cosmicelevator branch from master (#1573) * docs: post only orders (#1562) * docs: Adding specs for post-only orders * Update from master (#1602) * fix: bring market.liquidity.targetstake.triggering.ratio in line with implementation * fix: duplicate AC codes in 0069-VCBS (#1536) * chore: trailing spaces * fix: remove the unused netparam; not liking that * chore: remove untestable AC from 0018 (#1530) * chore: reword 0063-VALK-013 * Update 0035-LIQM-liquidity_monitoring.md (#1539) * Update 0035-LIQM-liquidity_monitoring.md * Update 0035-LIQM-liquidity_monitoring.md * fix AC numbering on 0035-LIQM-liquidity_monitoring.md (#1541) * Update 0011-NP-CLIE-client-interaction-tests.md * feat: allow any key to request multisg signers update bundle * feat: clarify spam status * refactor: let max oi drop during auciton * Wording tweaks for spam protection spec (#1548) * grammar etc fixes to spam protection * fix linting errors * chore: remove brackets * docs: another round of rewording * add related topics section * fix spelling in spam protection spec (#1553) * Update 0069-VCBS-validators_chosen_by_stake.md Added pending validator to VCBS-59 * Update 0069-VCBS-validators_chosen_by_stake.md Clarification on 0059 * Update 0062-SPAM-spam_protection.md * Update 0062-SPAM-spam_protection.md fixed link to defaults.go * Add quality checks to the makefile (#1556) * fix: broken links in the specs (#1557) * fix: remove broken kraken link * refactor: clarify 0042-LIQF-018 * feat: fix non-protocol linting and add makefile (#1563) * feat: fix non-protocol linting and add makefile * fix: remove binary file * fix: remove binary * fix: revert ui changes * fix: remove package files * Update glossaries/distributed-ledger-glossary.md * Update 0069-VCBS-validators_chosen_by_stake.md Added ACs to match the implementation so its codified (i.e., if an Ersatzvalidator drops below ownstake and there's no-one there to replace it, it is not demoted to pending. * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Update acceptance criteria to correctly reflect implementation (#1549) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * fix: update epoch ACs (#1555) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update 0042, LP fee Transfer, Distribution * Add build folder to gitigore The approbation checks in `makefile` use this folder. Make sure it's not checked in. * Update protocol/0042-LIQF-setting_fees_and_rewarding_lps.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Ignore dictionary Spellcheck creates a dictionary file. Ensure it isn't committed. * Un parallelise clone-sources in makefile The makefile tried to be clever and run all the remote-repo clones for Approbation checks in parallel. Due to my limited makefile skills, the check could run before a clone was finished. Run them in series instead. This also improves the output a little * Add specs param to names and codes in makefile The old behaviour (default paths) should have been deprecated ages ago, but hasn't been. This change makes it provide the same paths as the defaults. * feat: update maker fee transfer account * Update 0069-VCBS-validators_chosen_by_stake.md * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update protocol/0029-FEES-fees.md Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> * Update 0048-DSRI-data_source_internal.md * fix: refactor 0069-VCBS-052 (#1570) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> * fix: MD and spelling lint checks * fix: MD and spelling lint errors * fix: update wording for AC 0059-VCBS-016- (#1566) * Update 0062-SPAM-spam_protection.md (#1571) * Update 0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md * Update protocol/0062-SPAM-spam_protection.md --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md (#1542) * Update 0011-NP-CLIE-client-interaction-tests.md Added ACs to test static spam protection (wallet doesn't allow you to get banned) * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update non-protocol-specs/0011-NP-CLIE-client-interaction-tests.md Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * Update 0011-NP-CLIE-client-interaction-tests.md * Update 0011-NP-CLIE-client-interaction-tests.md * chore: fix spelling and MD lint checks --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * Update 0011-NP-CLIE-client-interaction-tests.md (#1579) * refactor: clarify AC * fix: adding bound on slippage part of margin * fix: adding bound on slippage part of margin - ACs * chore: lint * chore: format * chore: add ac codes * chore: lint * feat: make it nonlinear * fix: remove obsolete ac * fix: typo * fix: typo from comments Co-authored-by: Tom * fix: code block in list formatting (#1584) * chore: Remove untestable acceptance criteria * feat: add rate limit spec * Update 0057-TRAN-transfers.md (#1588) * Update 0057-TRAN-transfers.md * Update 0057-TRAN-transfers.md * chore: add AC codes * Update 0057-TRAN-transfers.md (#1590) * Update 0069-VCBS-validators_chosen_by_stake.md Added Acs for IssueSignature * Update 0069-VCBS-validators_chosen_by_stake.md * fix: Expand acceptance criteria to make them clear for 0011-NP-CLIE-client-interaction (#1585) * fix: Expand acceptance criteria to make them clear * chore: Fix formatting * fix: Address review comments --------- Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> * feat: Add new PLUP AC for state-sync in protocol upgrade. * feat: add closeout API * chore: tidy up * chore: remove blank line * chore: by more specific about when a client should be banned * feat: update formula line 140 * fix: Add extra cases for various things that might be affected by validators joining and leaving. * fix: Review comments for new ACs. * fix: Satisfy the linter. * refactor: add slippage to orders * refactor: update examples * chore: fix linter issues * refactor: fix typo * refactor: formlise margin level treatment * refactor: amend/add ACs * Update 0042-LIQF-setting_fees_and_rewarding_lps.md (#1598) * Update 0042-LIQF-setting_fees_and_rewarding_lps.md * fix: linting errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: linting error * fix: MD lint and spelling * Update 0069-VCBS-validators_chosen_by_stake.md (#1604) * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * Update 0069-VCBS-validators_chosen_by_stake.md * fix: MD linting and spelling errors --------- Co-authored-by: gordsport * Update 0069-VCBS-validators_chosen_by_stake.md (#1596) * Update 0069-VCBS-validators_chosen_by_stake.md * fix: spelling errors --------- Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> Co-authored-by: gordsport * fix: More validator join/leave test cases involving checkpoints. (#1601) * fix: More validator join/leave test cases involving checkpoints. * fix: spelling error * fix: Update AC codes to not be duplicates. --------- Co-authored-by: gordsport Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * feat: update make file and add approabtion to CI (#1605) * feat: update make file and add approabtion to CI * chore: add more checks and fix errors * fix: checkout PR branch * fix: get branch * fix: approbation errors --------- Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: Witold Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: Tom Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett * fix: lint errors and duplicate paragraph (#1630) * fix: lint errors and duplicate paragraph * fix: MD lint error * Chore: Update cosmicelevator from master (#1646) * feat: Add new cases, mostly around eth changes during outages. A few extra cases for PUP. * chore: Linting fixes. * fix: More linting issues. * fix: spelling and AC code lint errors * fix: spelling * feat: Clarifying fees paid (or not paid) by post-only orders (#1635) * chore: remove invalid and unimplemented use cases * refactor: floor slippage * User interface: add Post only and Reduce only (#1640) * draft for SORD * add AC for showing rejected reason * typo * execution flags on orders table * add codes to SORD * Update user-interface/7002-SORD-submit_orders.md Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * add link to docs --------- Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> * Clarify rewards if multisig contains a key it should not (#1643) * Clarify rewards if multisig contains a key it should not * fix: MD lint error --------- Co-authored-by: gordsport --------- Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Rado Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> --------- Co-authored-by: Witold Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: RomanLeca Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: Tom Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Edd Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: claudiumilea Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Jake Bennett Co-authored-by: Rado Co-authored-by: Michael * fix: fix prefix for browser wallet * chore: fixed wrong file.. * chore: now undo my formatting for the other file * chore: undo formatting change * add missing AC * add more ac * typoe * chore: add ac for the sprint * add ui specs for finding closed markets * fix number sequence * chore: add acs for market selector * chore: added ACs for transaction log * chore: removed navigation AC * add key pair ac that slipped the net via a ticket going straight to the done column * Add UI ACs for network and nodes (#1700) * Update 0002-WCON-connect_vega_wallet.md Removing all coulds, shoulds and would like tos. These are captured here and will be pulled into tickets as applicable later down the line if / when these features are implemented * Update user-interface/0002-WCON-connect_vega_wallet.md Co-authored-by: Penny Andrews <47143694+pennyandrews@users.noreply.github.com> * add settings ac * Update user-interface/1101-BWAL-browser_wallet.md * remove ac for recovery phrase and add new connection and transaction ac when not onboarded * add ac * add and increment * chore: update readme (#1709) Co-authored-by: peterbarrow <62435083+peterbarrow@users.noreply.github.com> * feat: typo * chore(trading): Add transfer ACs * chore(trading): Add transfer ACs number fix * chore: update proposal acs * fix(trading): Fix transfer specs ID * added all markets and proposal markets ACs * Fix: bring ersatz number in line with core. * increment and add ac * format * rework * chore: withdraw minimal amount * chore: add new market proposal acs * Update 1101-BWAL-browser_wallet.md Removed: - It is visually similar to other transaction types but essentially has less of the human readable detail(s) (design note) (1101-BWAL-057) as it is a design note - When I approve a transaction I can see confirmation that the transaction has been approved (1101-BWAL-045) - separate story in backlog - When I reject a transaction I can see confirmation that the transaction has been rejected (1101-BWAL-049) - separate story in backlog * chore:update todo * amend spec numbers * update acs * update numeration * 6501-ASSE-assets.md * add ac for import wallet * add list connections ac * update acs * A community settlement story. * fix: another AC for changing oracle after trading termination * fix: another AC for changing oracle after trading termination * chore: ACs added to 6002-MDET-market-details * chore: few more details added * Update user-interface/6002-MDET-market-details.md Co-authored-by: daro-maj <119658839+daro-maj@users.noreply.github.com> * chore: info about tooltips added * Update user-interface/6002-MDET-market-details.md Co-authored-by: Ben * liquidity ACs * updated numeration * chore(trading): Add Position ACs (#1733) * chore(trading): Add Position ACs * chore: pr suggestion * remove outdated ac * update * chore: add AC for quantum formatting * chore: fix bold typo * chore: filled ACs in 6003-ORDB * disconnect ac * finger slip * test: market selector acs update * update console space * chore: remove cosmic feature from master (#1766) There has been some confusion when designing FE/UXs as the spec for governance transfers has changed slightly from whats in master. Its also the case that master should now be what is live in mainnet this feature is not one that is live. * chore: 6005-THIS-trade_history filled with ACs * popout windoiw * fix: clarify what's a market and what's a network param. * fix: clarify what's a market and what's a network param. * fix: clarify what's a market and what's a network param. * fix: typo Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> * add browser wallet loading state ACs * chore: add AC for the button always being disabled (#1746) * Update 5002-LIQP-liquidity.md with 5002-LIQP-013 (#1769) * user-interface/ * depth chart ACs * update acs * update numbers * update name of reference * update * re-arrange browser wallet acs to save mainetenance (#1781) * re-arrange ac to save mainetenance * add file extension * onboarding spec tweak * final tweaks and removals * add specs to categories and apps --------- Co-authored-by: Dexter Edwards * chore(trading): 6004-CHAR-chart ACs created (#1775) * chore(trading): fix spec links * chore(trading): add code to apps.json * chore(trading): fix numbering * chore(trading): fix Char having duplicated id * chore(trading): fix id duplication * chore)trading): Fixing missed 0 * feat: use ghcr image to run approbation * feat: fix flags * fix: descriptions * chore(trading):add chart and orderbook ACs * add telemtry ac * update ac description * remove browser wallet * update README * Update 0036-BRIE-event_queue.md Added clarification on event forwarding * stop orders acs (#1859) * Update 6002-MDET-market-details.md Add some market successor specs * feat: fix some specs * Closed market list changes (#1828) * chore: remove spec on showing user pnl in closed market list * chore: add successor market acs * chore: update data display for mark price, liquidation price and pnl * `DATA`. Quantum decimals and accounts (#1512) * add more synonyms * introduce accounts * accounts are displayed as asset balances * introduce quantum * fix links to old DATA file * more detail * typo Co-authored-by: Edd --------- Co-authored-by: Edd * chore: add acs for network upgrade proposal (#1857) * chore: add acs for network upgrade proposal * chore: add acs for proposal enhancements * chore: proposal acs * chore: acs for successor market * Update the GitHub action token add_issue_new_projects.yml * chore: remove user-interface specs (#1877) * fix: add 048-COSMICELEVATOR-009 * fix: reword 0045-DSRC-012 * chore: update cosmic from matster * fix: missed conflict --------- Signed-off-by: Elias Van Ootegem Signed-off-by: Jeremy Letang Co-authored-by: Witold Co-authored-by: Michael Co-authored-by: candida-d <62548908+candida-d@users.noreply.github.com> Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Co-authored-by: Jiajia-Cui Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> Co-authored-by: Jake Bennett Co-authored-by: Tom Co-authored-by: Vegaklaus <62546834+Vegaklaus@users.noreply.github.com> Co-authored-by: Matthew Pendrey Co-authored-by: Elias Van Ootegem Co-authored-by: Charlie Co-authored-by: Charlie <99198652+cdummett@users.noreply.github.com> Co-authored-by: Matthew Russell Co-authored-by: Paul Webb <86229849+vega-paul@users.noreply.github.com> Co-authored-by: AnExsomnis <86832315+AnExsomnis@users.noreply.github.com> Co-authored-by: Barney Mannerings Co-authored-by: daro-maj <119658839+daro-maj@users.noreply.github.com> Co-authored-by: dalebennett1992 Co-authored-by: dalebennett1992 <37066267+dalebennett1992@users.noreply.github.com> Co-authored-by: Jeremy Letang Co-authored-by: wwestgarth Co-authored-by: wwestgarth Co-authored-by: RomanLeca Co-authored-by: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Co-authored-by: Edd Co-authored-by: claudiumilea Co-authored-by: MuthuVega Co-authored-by: Philip Scott Co-authored-by: Philip Scott <94362991+pscott31@users.noreply.github.com> Co-authored-by: Rado Co-authored-by: Penny Andrews <47143694+pennyandrews@users.noreply.github.com> Co-authored-by: Calum Pringle <46783148+ckpringle@users.noreply.github.com> Co-authored-by: peterbarrow <62435083+peterbarrow@users.noreply.github.com> Co-authored-by: Ben Wallace Co-authored-by: Joe Co-authored-by: m.ray <16125548+MadalinaRaicu@users.noreply.github.com> Co-authored-by: Dariusz Majcherczyk Co-authored-by: Zohar Etzioni Co-authored-by: asiaznik Co-authored-by: Art Co-authored-by: Dexter Edwards Co-authored-by: Joe Tsang <30622993+jtsang586@users.noreply.github.com> Co-authored-by: Sam Keen Co-authored-by: Mikołaj Młodzikowski Co-authored-by: Maciek Co-authored-by: AnExsomnis --- .github/workflows/config/markdownlintignore | 1 - .github/workflows/quality_check.yml | 7 + protocol/0019-MCAL-margin_calculator.md | 11 +- protocol/0041-TSTK-target_stake.md | 10 +- ...042-LIQF-setting_fees_and_rewarding_lps.md | 12 +- protocol/0045-DSRC-data_sourcing.md | 2 +- .../0046-DSRM-data_source_signed_message.md | 2 + protocol/0075-PLUP-protocol_upgrades.md | 1 - user-interface/0001-WALL-wallet.md | 125 ----------- .../0002-WCON-connect_vega_wallet.md | 64 ------ .../0003-WTXN-submit_vega_transaction.md | 49 ----- .../0004-EWAL-connect_ethereum_wallet.md | 34 --- .../0005-ETXN-submit_ethereum_transaction.md | 56 ----- user-interface/0006-NETW-network-and-nodes.md | 36 ---- user-interface/1001-DEPO-desposit.md | 39 ---- user-interface/1002-WITH-withdraw.md | 117 ---------- user-interface/1003-TRAN-transfer.md | 59 ----- user-interface/1004-ASSO-associate.md | 71 ------- user-interface/1005-VEST-vesting.md | 80 ------- user-interface/1101-BWAL-browser_wallet.md | 148 ------------- user-interface/2001-STKE-staking.md | 121 ----------- user-interface/2002-SINC-staking-income.md | 32 --- user-interface/3001-VOTE-vote.md | 157 -------------- user-interface/3002-PROP-propose.md | 63 ------ .../3003-PMAN-propose_new_market.md | 8 - .../3004-PMAC-propose_market_change.md | 13 -- user-interface/3005-PASN-propose_new_asset.md | 8 - .../3006-PASC-propose_asset_change.md | 13 -- user-interface/3007-PNEC-propose_network.md | 14 -- user-interface/3008-PFRO-propose_freeform.md | 8 - .../4001-TRES-view_treasury_rewards.md | 1 - .../5001-LIQF-liquidity_opportunities.md | 1 - user-interface/5002-LIQP-provide_liquidity.md | 1 - user-interface/5003-LIQI-liquidity_income.md | 1 - user-interface/6001-MARK-find_markets.md | 40 ---- user-interface/6002-MDET-market-details.md | 1 - user-interface/6003-ORDB-order_book.md | 1 - user-interface/6004-PHIS-price_history.md | 1 - user-interface/6005-THIS-trade_history.md | 1 - user-interface/6501-ASSE-assets.md | 21 -- user-interface/7001-COLL-collateral.md | 28 --- user-interface/7002-SORD-submit_orders.md | 201 ------------------ user-interface/7003-MORD-manage_orders.md | 182 ---------------- user-interface/7004-POSI-positions.md | 1 - user-interface/7005-FILL-fills.md | 19 -- user-interface/7006-FEES-fees.md | 1 - .../8001-BLOX-transaction_and_blocks.md | 1 - user-interface/9001-DATA-data_display.md | 65 ------ user-interface/README.md | 88 -------- user-interface/apps.json | 20 -- user-interface/categories.json | 32 --- user-interface/increment.py | 38 ---- 52 files changed, 27 insertions(+), 2079 deletions(-) delete mode 100644 user-interface/0001-WALL-wallet.md delete mode 100644 user-interface/0002-WCON-connect_vega_wallet.md delete mode 100644 user-interface/0003-WTXN-submit_vega_transaction.md delete mode 100644 user-interface/0004-EWAL-connect_ethereum_wallet.md delete mode 100644 user-interface/0005-ETXN-submit_ethereum_transaction.md delete mode 100644 user-interface/0006-NETW-network-and-nodes.md delete mode 100644 user-interface/1001-DEPO-desposit.md delete mode 100644 user-interface/1002-WITH-withdraw.md delete mode 100644 user-interface/1003-TRAN-transfer.md delete mode 100644 user-interface/1004-ASSO-associate.md delete mode 100644 user-interface/1005-VEST-vesting.md delete mode 100644 user-interface/1101-BWAL-browser_wallet.md delete mode 100644 user-interface/2001-STKE-staking.md delete mode 100644 user-interface/2002-SINC-staking-income.md delete mode 100644 user-interface/3001-VOTE-vote.md delete mode 100644 user-interface/3002-PROP-propose.md delete mode 100644 user-interface/3003-PMAN-propose_new_market.md delete mode 100644 user-interface/3004-PMAC-propose_market_change.md delete mode 100644 user-interface/3005-PASN-propose_new_asset.md delete mode 100644 user-interface/3006-PASC-propose_asset_change.md delete mode 100644 user-interface/3007-PNEC-propose_network.md delete mode 100644 user-interface/3008-PFRO-propose_freeform.md delete mode 100644 user-interface/4001-TRES-view_treasury_rewards.md delete mode 100644 user-interface/5001-LIQF-liquidity_opportunities.md delete mode 100644 user-interface/5002-LIQP-provide_liquidity.md delete mode 100644 user-interface/5003-LIQI-liquidity_income.md delete mode 100644 user-interface/6001-MARK-find_markets.md delete mode 100644 user-interface/6002-MDET-market-details.md delete mode 100644 user-interface/6003-ORDB-order_book.md delete mode 100644 user-interface/6004-PHIS-price_history.md delete mode 100644 user-interface/6005-THIS-trade_history.md delete mode 100644 user-interface/6501-ASSE-assets.md delete mode 100644 user-interface/7001-COLL-collateral.md delete mode 100644 user-interface/7002-SORD-submit_orders.md delete mode 100644 user-interface/7003-MORD-manage_orders.md delete mode 100644 user-interface/7004-POSI-positions.md delete mode 100644 user-interface/7005-FILL-fills.md delete mode 100644 user-interface/7006-FEES-fees.md delete mode 100644 user-interface/8001-BLOX-transaction_and_blocks.md delete mode 100644 user-interface/9001-DATA-data_display.md delete mode 100644 user-interface/README.md delete mode 100644 user-interface/apps.json delete mode 100644 user-interface/categories.json delete mode 100644 user-interface/increment.py diff --git a/.github/workflows/config/markdownlintignore b/.github/workflows/config/markdownlintignore index d7c52fd53..f0c429863 100644 --- a/.github/workflows/config/markdownlintignore +++ b/.github/workflows/config/markdownlintignore @@ -1,2 +1 @@ -user-interface/* LICENSE.md \ No newline at end of file diff --git a/.github/workflows/quality_check.yml b/.github/workflows/quality_check.yml index 1fa8103da..8d04b44ba 100644 --- a/.github/workflows/quality_check.yml +++ b/.github/workflows/quality_check.yml @@ -59,6 +59,13 @@ jobs: - name: "Check out" uses: actions/checkout@v3.5.3 + - name: Log in to the GitHub Container Registry + uses: docker/login-action@v2 + with: + registry: ghcr.io + username: ${{ github.actor }} + password: ${{ secrets.GITHUB_TOKEN }} + - name: "Run Check AC codes" run: | npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" diff --git a/protocol/0019-MCAL-margin_calculator.md b/protocol/0019-MCAL-margin_calculator.md index fbad9aecb..d95fecdef 100644 --- a/protocol/0019-MCAL-margin_calculator.md +++ b/protocol/0019-MCAL-margin_calculator.md @@ -193,9 +193,7 @@ maintenance_margin_short where meanings of terms in Step 1 apply except for: - -`slippage_per_unit = -1 * (Product.value(market_observable) - Product.value(exit_price))` - +`slippage_per_unit = max(0, Product.value(exit_price)-Product.value(market_observable))` ### **Step 3** @@ -275,11 +273,14 @@ riskiest_short = min( open_volume + sell_orders, 0 ) = min( 10 - 8, 0 ) = 0 ## exit price considers what selling the open position (10) on the order book would achieve. -slippage_per_unit = Product.value(market_observable) - Product.value(exit_price) = Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10) = 144 - 110 = 34 +slippage_per_unit = max(0, Product.value(previous_mark_price) - Product.value(exit_price)) = max(0, Product.value($144) - Product.value((1*120 + 4*110 + 5*108)/10)) = max(0, 144 - 110) = 34 + maintenance_margin_long =max(min(riskiest_long * slippage_per_unit, product.value(market_observable) * (riskiest_long * market.maxSlippageFraction[1] + riskiest_long^2 * market.maxSlippageFraction[2])), 0) + max(open_volume, 0 ) * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] + buy_orders * [ quantitative_model.risk_factors_long ] . [ Product.value(market_observable) ] - = max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 + + += max(min(14 * 34, 144*(14 * 0.25 + 14 * 14 * 0.001), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = max(min(476, 532.224), 0) + 10 * 0.1 * 144 + 4 * 0.1 * 144 = 677.6 # Step 2 diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index 40e683d21..987d1cba9 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -12,8 +12,8 @@ The parameter c_1 is a market parameter (with network parameter `market.liquidit ### Definitions / Parameters used - **Open interest**: the volume of all open positions in a given market. -- `market.stake.target.timeWindow` is a market parameter defining the length of window over which we measure open interest (see below). This should be measured in seconds and a typical value is one week i.e. `7 x 24 x 3600` seconds. -- `market.stake.target.scalingFactor` is a market parameter defining scaling between liquidity demand estimate based on open interest and target stake. +- `market.stake.target.timeWindow` is a network parameter providing the default length of window over which we measure open interest (see below). This should be measured in seconds and a typical value is one week i.e. `7 x 24 x 3600` seconds. A market proposal / update can override this by setting `timeWindow` in `liquidityMonitoringParameters.targetStakeParameters`. +- `market.stake.target.scalingFactor` is a network parameter providing the default scaling between liquidity demand estimate based on open interest and target stake. A market proposal / update can override this by setting `scalingFactor` in `liquidityMonitoringParameters.targetStakeParameters`. - `risk_factor_short`, `risk_factor_long` are the market risk factors, see [the Quant Risk Models spec](./0018-RSKM-quant_risk_models.ipynb). - `mark_price`, see [mark price](./0009-MRKP-mark_price.md) spec. - `indicative_uncrossing_price`, see [auction](./0026-AUCT-auctions.md) spec. @@ -21,9 +21,9 @@ The parameter c_1 is a market parameter (with network parameter `market.liquidit #### Current definitions First, `max_oi` is defined maximum (open interest) measured over a time window, -`t_window = [max(t-market.stake.target.timeWindow,t0),t]`. Here `t` is current time with `t0` being the end of market opening auction. Note that `max_oi` should be calculated recorded per transaction, so if there are multiple OI changes withing the same block (which implies the same timestamp), we should pick the max one, NOT the last one that was processed. +`t_window = [max(t-market.liquidityMonitoringParameters.targetStakeParameters.timeWindow,t0),t]`. Here `t` is current time with `t0` being the end of market opening auction. Note that `max_oi` should be calculated recorded per transaction, so if there are multiple OI changes withing the same block (which implies the same timestamp), we should pick the max one, NOT the last one that was processed. -If the market is in auction mode the `max_oi` can only increase while `auction duration` <= `market.stake.target.timeWindow`. Once the market's been in the auction for more than `market.stake.target.timeWindow` the `max_oi` is whatever the current positions and `indicative_uncrossing_volume` imply - specifically, this allows the `target_stake` to drop as a result of trades generated in the auction so that `target_stake` > `supplied_stake` (even in absence of changes to `supplied_stake`) and the market can go back to its default trading mode. +If the market is in auction mode the `max_oi` can only increase while `auction duration` <= `market.stake.target.timeWindow`. Once the market's been in the auction for more than `market.liquidityMonitoringParameters.targetStakeParameters.timeWindow` the `max_oi` is whatever the current positions and `indicative_uncrossing_volume` imply - specifically, this allows the `target_stake` to drop as a result of trades generated in the auction so that `target_stake` > `supplied_stake` (even in absence of changes to `supplied_stake`) and the market can go back to its default trading mode. Example 1: `t_market.stake.target.timeWindow = 1 hour` @@ -47,7 +47,7 @@ Example 2: As above but the market opened at `t_0 = 4:15`. Then `t_window = [4:1 From `max_oi` we calculate -`target_stake = reference_price x max_oi x market.stake.target.scalingFactor x rf`, +`target_stake = reference_price x max_oi x market.liquidityMonitoringParameters.targetStakeParameters.scalingFactor x rf`, where `reference_price` is `mark_price` when market is in continuous trading mode and `indicative_uncrossing_price` during auctions (if it's available, otherwise use `mark_price` which may be 0 in case of an opening auction), and `rf = max(risk_factor_short, risk_factor_long)`. Note that currently we always have that `risk_factor_short >= risk_factor_long` but this could change once we go beyond futures... so safer to take a `max`. Note that the units of `target_stake` are the settlement currency of the market as those are the units of the `reference_price`. diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index 48f2c788d..da1321231 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -395,9 +395,9 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th ### Transfers example Example 1, generated with [supplementary worksheet](https://docs.google.com/spreadsheets/d/1PQC2WYv9qRlyjbvvCYpVWCzO5MzwkcEGOR5aS9rWGEY) [internal only]. Values should match up to rounding used by `core` (0042-LIQF-055): -| LP | penalty fraction | LP-per-market fee accounts balance | 1st transfer amt | 2nd (bonus) transfer amt | -| --- | -------------- | -------------- | -------------- | -------------- | -| LP1 | 0 | 1000 | 1000 | 24673.94095 | -| LP2 | 0.05 | 100 | 95 | 2344.02439 | -| LP3 | 0.6 | 7000 | 2800 | 69087.03466 | -| LP4 | 1 | 91900 | 0 | 0 | +| LP | penalty fraction | LP-per-market fee accounts balance | 1st transfer amt | 2nd (bonus) transfer amt | +| --- | -------------- | -------------- | -------------- | -------------- | +| LP1 | 0 | 1000 | 1000 | 24673.94095 | +| LP2 | 0.05 | 100 | 95 | 2344.02439 | +| LP3 | 0.6 | 7000 | 2800 | 69087.03466 | +| LP4 | 1 | 91900 | 0 | 0 | diff --git a/protocol/0045-DSRC-data_sourcing.md b/protocol/0045-DSRC-data_sourcing.md index 91307c1a2..81001341c 100644 --- a/protocol/0045-DSRC-data_sourcing.md +++ b/protocol/0045-DSRC-data_sourcing.md @@ -236,7 +236,7 @@ Vega should reject any data source tx that is not explicitly required, so this w 1. Data is not applied retrospectively, i.e. if a previous historic data point or data transaction would have matched a newly created data source, it must not be identified and applied to the new data source (and therefore need not be stored by the core), only active data and new events created after the activation of the data source would be considered for the source. (0045-DSRC-009) 1. Two data sources with the same definition that are active at the same time must always select and receive exactly the same data, in the same order. (0045-DSRC-010) 1. Rejection of data sources either before submission/sequencing as transactions or when/if data is filtered/rejected after being sequenced on chain (if this happens - it should be avoided wherever possible to prevent spam attacks and reduce network load) must either result in an event queue message, return an error to the client, or enable the rejection (or not) to be confirmed by querying a core API (e.g. the filter, selector, or type check that failed). (0045-DSRC-011) -1. It's possible to query an API and see all active data sources. (0045-DSRC-012) +1. It's possible to query all active and deactivated data sources for a market via REST, gRPC and GraphQL. (0045-DSRC-012) 1. Party submitting an oracle transaction that gets rejected (e.g. because no data source is listening for transactions from such key) can receive an error message detailing reason for rejection. (0045-DSRC-013) 1. It's possible to listen to events and see all data that is supplied across all data sources or for any specific source. (0045-DSRC-014) 1. Data node carries historic data of at least all valid data that was supplied for each data source. (0045-DSRC-015) diff --git a/protocol/0046-DSRM-data_source_signed_message.md b/protocol/0046-DSRM-data_source_signed_message.md index 239c2cce9..8283308c1 100644 --- a/protocol/0046-DSRM-data_source_signed_message.md +++ b/protocol/0046-DSRM-data_source_signed_message.md @@ -122,6 +122,8 @@ Other acceptance: - Must work with Coinbase oracle (0046-DSRM-012) - Ignore any `SubmitData` tx that is a duplicate (i.e. contains exactly the same data payload and is for the same data source), even if it is signed by a different signer (assuming the source has multiple configured signers) or was submitted by a different Vega key. (0046-DSRM-016) - Messages are accepted that contain the data and the signature (conforming to the Open Oracle specification) Note: do not support (or need to) direct connections to REST APIs, Ethereum smart contracts, etc. conforming to the open oracle spec. (0046-DSRM-017) +- Set up a [builtin product futures](./0016-PFUT-product_builtin_future.md) market with vega (internal) time triggered trading terminated oracle and an settlement oracle with a with key `k1`. Wait for time to pass for the market to move to trading terminated. Now submit a market change proposal to change the oracle to key `k2`. Wait for the vote to pass and enact. Verify that `k1` cannot settle the market. Now settle the market with `k2` and verify it settled at the correct price. (0046-DSRM-018). + ## Notes diff --git a/protocol/0075-PLUP-protocol_upgrades.md b/protocol/0075-PLUP-protocol_upgrades.md index aff401dd5..d3279ccbf 100644 --- a/protocol/0075-PLUP-protocol_upgrades.md +++ b/protocol/0075-PLUP-protocol_upgrades.md @@ -250,4 +250,3 @@ For the purposes of protocol upgrade each validator that participates in consens 1. Shut down the nodes. 1. Start all nodes on the new binary. 1. Expect all transactions that reached blocks prior to upgrade to have taken effect. None of the other transactions did. - diff --git a/user-interface/0001-WALL-wallet.md b/user-interface/0001-WALL-wallet.md deleted file mode 100644 index 5e7eae84b..000000000 --- a/user-interface/0001-WALL-wallet.md +++ /dev/null @@ -1,125 +0,0 @@ -# Wallet -A Vega wallet is required to prepare and submit transaction on Vega (place, cancel, orders etc). See the [wallet docs](https://docs.vega.xyz/docs/mainnet/concepts/vega-wallet) for more on how "crypto" wallets work. - -A wallet can contain many public/private key pairs. The public part of each key pair is known the [Party](../protocol/0017-PART-party.md) sometimes just referred to as a key or public key. - -The primary job(s) of a wallet is to [sign/encrypt transaction](../protocol/0022-AUTH-auth.md) (so the network can be sure they were sent by a given party) and to broadcast these transactions to a node on the network. - -## Set up wallet / Restore wallet -When opening the wallet for the first time, I... - -- if the wallet sends telemetry/analytics: **must** be prompted to opt into (or stay out of) analytics (0001-WALL-003) -- I can restore a wallet from a seed phrase (0001-WALL-004) -- I can create a new wallet (0001-WALL-005) - - I can view the back up phrase (0001-WALL-006) - - I can see the first key without having to "add key". (i.e. The wallet auto generates the first key from the seed phrase) (0001-WALL-008) - -...so I can sign transactions - -## Configure network -When using the wallet on a network, I... - -- I can have Mainnet and Fairground (testnet) pre-configured (with Mainnet being the default network) (0001-WALL-009) -- I can create a new network configuration (0001-WALL-010) -- I can refine the configuration for existing networks (including the ones that come pre-configured) (0001-WALL-011) -- I can remove networks (0001-WALL-013) - -...so I can broadcast transactions to, and read information from a vega network in my wallet - -## Update wallet -When using an older version of a Vega wallet than the current official release, I... - -- I am warned if the version I am using is not compatible with the version of Vega on the selected network, and I am given a link to get latest compatible version on github (0001-WALL-015) - -... so the version of the wallet app I am using works with the network I am using - -## Log in to a wallet -When using a given wallet, I... - -- I can select a wallet and enter the passphrase only once per "session" (0001-WALL-016) - -... so that other users of my machine can not use my wallet, and I am not asked to re-enter frequently - -## Connecting to Dapps -When a dapp requests use of a wallet, I... - -- I am prompted to either select a wallet or dismiss the prompt (0001-WALL-017) - - I can select whole wallet (so that new keys are automatically shared) (0001-WALL-019) -- I can enter wallet passphrase before wallet details are shared (assuming a password has not recently been entered)(0001-WALL-022) -- I can retrospectively revoke Dapp's access to a Wallet (0001-WALL-023) - -... so that I can control what public keys are shared with a dapp and what dapps can prompt me to sign transactions - -## Approving transactions -When a dapp sends a transaction to the wallet for signing and broadcast, I... - -- I am prompted to confirm, reject or ignore the transaction (if auto-confirm is not on) (0001-WALL-024) -- I can see the details of the transaction. See [details of transaction](#transaction-detail). (0001-WALL-025) - -... so I can verify that the transaction being sent is the one I want - -## Transaction log -When thinking about a recent or specific transaction, I ... - -- I can find a single list of all transactions, completed and ongoing, from all keys and wallets, from my current desktop session and network (0001-WALL-034) -- I can see transactions that were confirmed by the wallet user (me) (0001-WALL-035) -- I can see transactions that were rejected by the wallet user (me) (0001-WALL-036) -- If I switch network, transactions list changes to show the transactions for that network (0001-WALL-037) -- I can click a transaction in the list to see the transaction details (0001-WALL-038) -- I can see empty state when there are no transactions for this session (0001-WALL-039) - -... so that I can ensure my wallet is being used appropriately and find transaction I made - -## Transaction details -when looking at a specific transaction... - -- I can see details of specific transactions I opened (0001-WALL-041) -- I can find my way to the transaction on block explorer (0001-WALL-042) -- I can find my way to the complete transaction history for that key on block explorer (0001-WALL-043) - -- I can see [status of broadcasted transactions](0003-WTXN-submit_vega_transaction.md#track-transaction-on-network) - -.. so I can find all the information about what has happened with mined and un-mined transactions - -## Key management -When using a Vega wallet, I... - -- I can create new keys (derived from the source of wallet) (0001-WALL-052) -- I can see full public key or be able to copy it to clipboard (0001-WALL-054) -- I can change key name/alias (0001-WALL-055) - -... so I can manage risk (e.g. isolate margin), mitigate the damage of a key being compromised, or use multiple trading strategies - -## Taint keys -When protecting myself from use of keys that may be compromised, I.. - -- I can select a key I wish to taint (0001-WALL-057) -- I am prompted to enter wallet password to taint key (0001-WALL-058) -- I can see tainted keys flagged as tainted (0001-WALL-060) - -... so that tainted keys must not be used - -When I have accidentally tainted a key I... - -- I can select a key to un-taint and be required to enter wallet password (0001-WALL-061) - -...so that I must use the key again - -## Manually sign a message -When wishing to use my wallet to sign arbitrary messages, I... - -- I can enter content to be signed with key (0001-WALL-062) -- I can submit/sign the content (0001-WALL-065) - - I can [track progress](0003-WTXN-submit_vega_transaction.md#track-transaction-on-network) of broadcast transaction either by being given a hash that I can use in block explorer, or see the transaction status - -.. so I can control of the message being signed, and can use the message elsewhere (for example to prove I own a wallet) - -## Wallet management -When seeking to reduce risk of compromise I... - -- I can create multiple wallets (0001-WALL-066) -- I can switch between wallets (0001-WALL-067) -- I can remove a wallet (0001-WALL-068) -- I can change wallet name (0001-WALL-069) - -... so that I must administrate my wallets diff --git a/user-interface/0002-WCON-connect_vega_wallet.md b/user-interface/0002-WCON-connect_vega_wallet.md deleted file mode 100644 index 455ccb4c6..000000000 --- a/user-interface/0002-WCON-connect_vega_wallet.md +++ /dev/null @@ -1,64 +0,0 @@ -# Connect Vega wallet & select keys - -## Connect wallet - -When looking to use Vega via a user interface e.g. Dapp (Decentralized web App), I... - -- If the app loads and already has a connection it can restore "eagerly" (without the user having to click connect) it **could** do so -- **must** select a connection method / wallet type: (0002-WCON-002) -- if Rest: - - **must** have the option to input a non-default Wallet location (0002-WCON-003) - - **must** submit attempt to connect to wallet (0002-WCON-005) - - - if the dapp DOES already have a permission with the wallet: **must** see that wallet is connected (0002-WCON-007) note: if the user want to connect to a different wallet to the one that they were previously connected with, they will have to hit logout. - - if the app uses one key at a time: **should** show what key is active (re-use the last active key) (0002-WCON-008) - - - if the wallet does NOT have an existing permission with the wallet: **must** prompt user to check wallet app to approve the request to connect wallet: See [Connecting to Dapps](0002-WCON-connect_vega_wallet.md#connect-wallet) for what should happen in wallet app (0002-WCON-009) - - - if new keys are given permission: **must** show the user the keys have been approved (0002-WCON-010) - - if the dapp uses one key at a time: **should** prompt me to select key. See [select/switch keys](#select-and-switch-keys). (0002-WCON-014) - - - if user rejects connection: **must** see a message saying that the request to connect was denied (0002-WCON-015) - - - if the dapp is unable to connect for technical reason (e.g. CORS): **must** see an explanation of the error, and a method of fixing the issue (0002-WCON-016) - - -- ~~Browser wallet~~ `not available yet` - -- Fairground hosted wallet - - **must** only be be shown this option if the dapp is connected to fairground (0002-WCON-039) - - **must** input a wallet name (0002-WCON-017) - - **must** input a password (0002-WCON-018) - - if success: **must** see that the wallet is connected and details of connected key (0002-WCON-019) - - if failure: **must** see reason for failure (0002-WCON-020) - - *note: the fairground hosted wallet is configured to automatically approve connections from dapps so there is no need for key selection.* - -- **must** have the option to select a different method / wallet type if I change my mind (0002-WCON-021) - -... so I can use the interface to read data about my key/party or request my wallet to broadcast transactions to a Vega network. - -## Disconnect wallet - -When wishing to disconnect my wallet, I... - -- **must** see an option to disconnect wallet (0002-WCON-022) -- **must** see confirmation that wallet has been disconnected (0002-WCON-023) - -... so that I can protect my wallet from malicious use or select a different wallet to connect to - - -## Select and switch keys - -when looking to do something with a specific key (or set of keys) from my wallet, I... - -- **must** see what key is currently selected (if any) (0002-WCON-025) -- **must** see a list of keys that are approved from the connected wallet (0002-WCON-026) - -- for each key: - - **must** see the first and last 6 digits of the [public key](DATA-data_display.md#public-keys). (0002-WCON-027) - - **must** be able to copy to clipboard the whole public key (0002-WCON-029) - - **must** see the key name/alias (meta data) (0002-WCON-030) - -- **must** see the option to trigger a re-authenticate so I can use newly created keys (0002-WCON-035) - -...so that I can select the key(s) that I want to use. diff --git a/user-interface/0003-WTXN-submit_vega_transaction.md b/user-interface/0003-WTXN-submit_vega_transaction.md deleted file mode 100644 index dfb0ad4e9..000000000 --- a/user-interface/0003-WTXN-submit_vega_transaction.md +++ /dev/null @@ -1,49 +0,0 @@ -# Submit Vega transaction - -A dapp sends a transaction to a wallet, that wallet then broadcasts the transaction to a network. Therefore the following is broken up into two steps. The transaction could fail at either. Generally: Once the transaction has gone to the network a user can use block explorer to track the transaction, but some tracking in Dapp or wallet will help. - -When submitting a Vega transaction of any kind, I... - -## Track transaction to wallet - -if not connected to a Vega wallet: - -- **must** be told that I am not connected, so can not submit a transaction, and given the [option to connect](0012-WCON-connect_vega_wallet.md). (Note: this may have happened if the wallet has become disconnected without the user knowing) (0003-WTXN-001) - -if transaction not auto approved by wallet: - -- **must** see a prompt to check connected vega wallet to approve transaction (0003-WTXN-002) -- **could** see the transaction details that has been passed to the wallet for broadcast - -if transaction is approved by wallet: - -- **must** see A [transaction hash](DATA-data_display.md#transaction-hash) (0003-WTXN-003) -- **must** see the public key that this transaction was submitted for (0003-WTXN-004) -- **should** see the alias for the key that submitted this transaction -- **could** see a prompt to set this app to [auto approve](0001-WALL-wallet.md#approving-transactions) in wallet app - -if transaction is rejected by wallet: - -- **could** see that the order was rejected by the connected wallet (closing the window automatically may be appropriate) (0003-WTXN-007) - -if the wallet does not respond: - -- **must** not be able prevented from using the app, e.g. you can (0003-WTXN-008) -- **would** like to be able to cancel the transaction from the dapp so that the wallet is no longer in the state where it is asking user to confirm - -if the wallet highlights an issue with the transaction: - -- **must** show that the transaction was marked as invalid by the wallet and not broadcast (aka an error was returned from Wallet) (0003-WTXN-009) -- **should** see the error returned highlighted in context of the form that submitted the transaction in Dapp -- **must** show error returned by wallet (0003-WTXN-011) - -## Track transaction on network - -- **must** see a link to that transaction in a block explorer for the appropriate network (0003-WTXN-012) -- **should** see an indication transaction status -- **should** see the network the transaction was broadcast to -- **should** see the block the transaction was processed in -- **should** show the node the transaction was broadcast to -- **could** see the validator that processed the block the transaction was processed in - -... so I am aware of the transactions status of the transactions my wallet is sending and that are being processed by the network \ No newline at end of file diff --git a/user-interface/0004-EWAL-connect_ethereum_wallet.md b/user-interface/0004-EWAL-connect_ethereum_wallet.md deleted file mode 100644 index 7944a23df..000000000 --- a/user-interface/0004-EWAL-connect_ethereum_wallet.md +++ /dev/null @@ -1,34 +0,0 @@ -# Connect Ethereum wallet - -Dapps can connect to an Ethereum wallet to complete Ethereum transactions such as Deposits and withdraws to/from Vega, Association and more. - -## Connecting wallet - -When wanting or needing to write to Ethereum, I... - -- will have seen a link to connect that opens connection options (this always happens in context so should be covered by WITH, DEPO, ASSO ACS) - -- if first time: - - **must** select a connection method / wallet type: (e.g. wallet connect, injected / metamask) (0004-EWAL-001) - - **must** be prompt to check eth wallet (while the dapp waits for a response) (0004-EWAL-002) - - **must** see an option to cancel the attempted connection (if the wallet fails to respond) (0004-EWAL-003) - - if the app gets multiple keys: the user: - - **should** be shown the keys returned and given a UI to select a key for use (but the pattern is often just to select the first in the array) - - **should** be prompted to select one (in many cases Dapps default to key 0 in the array) -- after first use (if there is a connection to restore): - - **must** prompt wallet to grant access (0004-EWAL-004) - - **should** see previous connection has been recovered - - **should** see a link to trigger a fresh connection / fetch new keys (in in the case where I now want to use a different wallet to the one I was connected with) -- once connected: - - **must** see the connected ethereum wallet Public key (0004-EWAL-005) - -... so I can sign and broadcast Ethereum transactions, use a key address as in input, or read data from ethereum via my connected wallet - -## Disconnecting - -When I'm finished using a connected Ethereum wallet I may wish to disconnect... - -- **must** see a link to disconnect (0004-EWAL-006) - - **must** destroy dapp -> ETH wallet session so that hitting connect again triggers the modal that asks what method you'd like to use to connect to an ETH wallet, (note: it is not possible to invalidate the permission the metamask wallet has granted the app, therefore users will need to know that if they want to connect to a new ETH key they will have to do so from the wallet) (0004-EWAL-007) - -... so that I can use a different wallet, or ensure may wallet can not be used by other apps \ No newline at end of file diff --git a/user-interface/0005-ETXN-submit_ethereum_transaction.md b/user-interface/0005-ETXN-submit_ethereum_transaction.md deleted file mode 100644 index c1d34b163..000000000 --- a/user-interface/0005-ETXN-submit_ethereum_transaction.md +++ /dev/null @@ -1,56 +0,0 @@ -# Submit Ethereum transaction - -## Know what transaction I'm signing -When about to click to prompt Ethereum wallet to sign a transaction, I... - -- **should** see the contract address I am about to interact with -- **should** see the function name I am about to interact with - -...so I know what to expect when my wallet asks me to sign -## Track transactions to wallet - -after clicking to submit an eth transaction to a connected wallet, I... - -- **could** see an estimate for gas prices compared to a recent history -- **could** see an estimated gas price for the function in question -- **must** see prompt to check Ethereum wallet to approve transactions - -... so I know I need to go to my wallet app to approve the transaction - -## ERC20 approval/permit - -> The approval/permit step is part of the [ERC20 standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/). It's intention is to provide additional security when interacting with smart contracts / using Dapps. It sets a maximum amount that the given eth key can send to a given address. It means that before end "spend" of ERC20 tokens I will have need to submit a "approve" transaction to tell the network how much is approved. An attempt to spend more than the approved amount will fail. -> For example: In my approve transaction, I approve 10, I then spend 5. In my next transaction I attempt to spend 6, this will fail as my approve amount was reduced by the first transaction. -> It is common for dapps to have a approve button that simply asks to approve a massive amount and leave it up to the wallet UI (e.g. metamask) to ask the user if they would like to change this. -> Some ERC20 contracts have an additional function that runs both the approve and deposit function in one, but this is not standard. - -If the transaction in question requires an ERC20 approval, I... - -- if the current approved amount is less than the amount being "spent": **must** see be prompt to approve -- **could** see the current approved amount -- **must** be able to set the amount to be approved (in case the connected wallet does not handle this) (0005-ETXN-006) -- **must** send an approve transaction with either a user specified amount or a very large number (0005-ETXN-001) -- **must** see feedback of the state of approve transaction see "tracking ethereum transactions" below. (0005-ETXN-002) - -... so I can control the maximum permitted transfer to the contract in question - -## Tracking Ethereum transactions on network - -After approving a transaction in my wallet app, I... - -- **should** see link to the transaction on etherscan -- **must** see the transactions status (Pending, confirmed, etc) on Ethereum by reading Ethereum (via connected wallet or the back up node specified in the app) (0005-ETXN-003) -- if failed: **must** see why the transaction failed (e.g. didn't pay enough gas) (0005-ETXN-004) -- if success: **should** see how many blocks ago the transaction was confirmed by the eth node being read - -... so I can see the status of the transaction and debug as appropriate -## Tracking Ethereum transactions having their affect on Vega -Note: it is common for inter-blockchain applications to wait a certain amount of blocks before crediting money, as this reduces the risk of double spend in the case of forks or chain roll backs. There is a Vega environment variable the defines how long Vega waits. - -If the ethereum transaction I've just submitted changes the state of the Vega network (e.g. a deposit from eth appearing as credited to my vega key on vega), I... - -- **should** see how many Ethereum blocks Vega needs to wait before changing the state of Vega -- **should** see how many blocks have passed or remain until the required number has been met -- **must** see whether the expect action has taken place on Vega (e.g. credited Vega key) (0005-ETXN-005) - -... so I know vega has been updated as appropriate \ No newline at end of file diff --git a/user-interface/0006-NETW-network-and-nodes.md b/user-interface/0006-NETW-network-and-nodes.md deleted file mode 100644 index e6dc3ec3c..000000000 --- a/user-interface/0006-NETW-network-and-nodes.md +++ /dev/null @@ -1,36 +0,0 @@ -# Select network and nodes - -## Startup - -- **Must** automatically select a node from the environments network config stored in the [networks repo](https://github.com/vegaprotocol/networks) ([0006-NETW-001](#0006-NETW-001)) - -## Network switcher - -- **Must** see current network ([0006-NETW-002](#0006-NETW-002)) -- **Must** be able to change network ([0006-NETW-003](#0006-NETW-003)) - -## Node health - -- **Must** see node status - - Operational if node is less than 3 blocks behind ([0006-NETW-004](#0006-NETW-004)) - - Warning if greater than 3 blocks behind ([0006-NETW-005](#0006-NETW-005)) - - Warning if vega time is 3 seconds behind current time ([0006-NETW-006](#0006-NETW-006)) - - Prominent error if vega time is 10 seconds behind current time ([0006-NETW-007](#0006-NETW-007)) -- **Must** see current connected node ([0006-NETW-008](#0006-NETW-008)) -- **Must** see current block height ([0006-NETW-009](#0006-NETW-009)) -- **Must** see block height progressing ([0006-NETW-010](#0006-NETW-010)) -- **Must** see link to status and incidents site ([0006-NETW-011](#0006-NETW-011)) - -## Node switcher - -- **Must** be able to click on current node to open node switcher dialog ([0006-NETW-012](#0006-NETW-012)) -- In the node dialog - - **Must** must see all nodes provided by the [network config](https://github.com/vegaprotocol/networks) ([0006-NETW-013](#0006-NETW-013)) - - For each node - - **Must** see the response time of the node ([0006-NETW-014](#0006-NETW-014)) - - **Must** see the current block height ([0006-NETW-015](#0006-NETW-015)) - - **Must** see if subscriptions are working for that node ([0006-NETW-016](#0006-NETW-016)) - - **Must** be able to select and connect to any node, regardless of response time, block height or subscription status ([0006-NETW-017](#0006-NETW-017)) - - **Must** be able to select 'other' to input a node address and connect to it ([0006-NETW-018](#0006-NETW-018)) - - **Must** have disabled connect button if 'other' is selected but no url has been entered ([0006-NETW-019](#0006-NETW-019)) - - **Must** have disabled connect button if selected node is the current node ([0006-NETW-020](#0006-NETW-020)) diff --git a/user-interface/1001-DEPO-desposit.md b/user-interface/1001-DEPO-desposit.md deleted file mode 100644 index 86041b1cd..000000000 --- a/user-interface/1001-DEPO-desposit.md +++ /dev/null @@ -1,39 +0,0 @@ -# Deposit - -The Vega network has no native assets. All settlement assets exist on another chain and are "bridged" to Vega in one way or another. - -In the case of [ERC20 tokens](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) there is a smart contract on the Ethereum network that acts as a vault (aka bridge) for the tokens that are deposited to Vega. The Vega network then reads the information from this vault about what Vega key to credit these tokens to. While in the Vault the Vega key that owns them (and consequently the ethereum key) may change. The vault then manages how much each ethereum key is able to withdraw from the vault given then changes in ownership that may have happened on Vega. The keys to this vault and managed by the different nodes that make up the Vega network. They verify the the appropriate amounts can be withdrawn by each Ethereum key. At time of writing only ERC20 tokens have been implemented but the pattern is likely the same for other assets/networks. -## ERC20 deposits - -Note: ERC20 assets require an approval transaction to be finalised before funds can be credited to another key. Read more about approvals [link 1](https://medium.com/ethex-market/erc20-approve-allow-explained-88d6de921ce9), [link 2](https://hackernoon.com/erc20-infinite-approval-a-battle-between-convenience-and-security-lk60350r). - -When making to deposit ERC20 assets to an Vega key, I... - -- **should** be able to follow a link from an asset (e.g. on a market page) to the deposit form pre-populated with the given asset -- **must** see a link to [connect an ethereum wallet](0004-EWAL-connect_ethereum_wallet.md) that I want to deposit from (1001-DEPO-001) -- **must** select the [asset](9001-DATA-data_display.md#asset) that I want to deposit (1001-DEPO-002) - - **should** easily see the assets that I have a non-zero balance for (in the connected eth wallet) - - **should** see the ERC20 token address of the asset - - **should** see the [Vega asset symbol](9001-DATA-data_display.md#asset-symbol) - - **should** see the [Vega asset name](9001-DATA-data_display.md#asset-name) -- **must** select the [amount of the asset](9001-DATA-data_display.md#asset-balances) that I want to deposit (1001-DEPO-003) - - **should** see an ability to populate the input with the full balance in the connected wallet - - **must** be warned if the amount being deposited is greater than the balance of the token in the connected Eth wallet (1001-DEPO-004) -- **must** select the [Vega key](9001-DATA-data_display.md#public-keys) that I wish to deposit to (1001-DEPO-005) - - **should** be able to [connect to a Vega wallet and select a key](0002-WCON-connect_vega_wallet.md#select-and-switch-keys) - - **should** be easily (if not automatically) pre-populated with a [currently connected and active Vega key](0002-WCON-connect_vega_wallet.md#select-and-switch-keys) - - **should** be able to input a Vega key other than one I am connected with (even without being connected) - - if approved amount is less than deposit: - - **must** see that an approval is needed and be prompted to approve more (1001-DEPO-006) - - **should** see the approved [asset amount](9001-DATA-data_display.md#asset-balances) - - **should** be able to input an amount to approve - - **must** [submit eth transaction to approve](0005-ETXN-submit_ethereum_transaction.md) (1001-DEPO-007) - - **must** see feedback for the approve transaction - - if approved amount is more than deposit amount: - - **could** see the approved [asset amount](9001-DATA-data_display.md#asset-balances) - - **could** set a submit a new [eth transaction to approve more or less](0005-ETXN-submit_ethereum_transaction.md) - - **must** submit the Deposit [eth transaction](0005-ETXN-submit_ethereum_transaction.md) (1001-DEPO-008) - - **must** see feedback on the deposit [ETH transaction](0003-WTXN-submit_vega_transaction.md) (1001-DEPO-009) - - **must** see feedback that the deposit has or has not been credited to the Vega key (1001-DEPO-010) - -...so that my Vega key can use these assets on Vega \ No newline at end of file diff --git a/user-interface/1002-WITH-withdraw.md b/user-interface/1002-WITH-withdraw.md deleted file mode 100644 index 8e32188f5..000000000 --- a/user-interface/1002-WITH-withdraw.md +++ /dev/null @@ -1,117 +0,0 @@ -# Withdraw - -Withdrawing funds is a two step process. - -First the Vega network needs to approve that the funds can be released (not required for margin on open positions or in liquidity bond etc). If they are not, a withdraw is prepared and set aside so that it can not be used for positions etc. This also define what ethereum address will be credited the funds in step 2. - -Second the user will need to run an ethereum function on the bridge contract to release the funds (and pay the gas to do so). They do this using a signature supplied by nodes of the Vega network in Step 1. - -Although this is a two step process technically effort should be put into making it feel like one, then handle exceptions (like delays on withdrawals) as required. - -See [Specs for eth bridge](../protocol/0031-ETHB-ethereum_bridge_spec.md) and [docs](https://docs.vega.xyz/docs/mainnet/concepts/vega-protocol#withdrawals) on withdrawals. See also the [specs on delays to withdrawals](../non-protocol-specs/0003-NP-LIMI-limits_aka_training_wheels.md#withdrawal-limits). - -## Prepare an ERC20 withdraw from Vega - -When wishing to withdraw some of an ERC20 asset from Vega, I... - -- **should** be prompted to complete any existing incomplete withdrawals that exist for connected keys (see [complete withdrawal](#complete-erc20-withdraw-from-ethereum-bridge)) - -Note: It is better to encourage the completion of started withdraws as soon as possible after preparing them. This is because the validator set could theoretically change enough to make the node signatures that authorize the withdrawal invalid. - -- **should** be warned that they will need to pay gas on the withdrawal before starting -- **could** show the current gas fees BEFORE preparing the withdrawal (note: shows gas estimate is a general should for all [ethereum transactions](0005-ETXN-submit_ethereum_transaction.md) but this is so a user gets to see the gas costs at step 1 assuming they will do step 2 immediately. ) - -Note: A user may want to delay preparing a withdrawal if gas fees on the network are particularly high at the time - -- **must** select the asset to withdraw (1002-WITH-001) - - - **should not** see option to select assets where I a zero [total balance](9001-DATA-data_display.md#asset-balances) (note this should also avoid `Pending` assets from appearing in the list) - - **must** see the general balance I have for that asset (1002-WITH-002) - - **should** see balances to the full number of decimal places possible for that asset - - **should** see the total balances of the assets I have - - **could** see a breakdown of other accounts I have in this asset and their balances - -- **must** select the [amount](9001-DATA-data_display.md#asset-balances) of the asset I wish to withdraw (1002-WITH-003) - - **should** have an easy option (link/button) to input the full amount in general balance - - **must** be able to specify as many decimal places as the asset supports (1002-WITH-004) -- **must** be warned if the amount is greater than general balance (including if the general balance amount changes while the user is looking at the form) (1002-WITH-005) - -- **must** be warned if the amount is lesser than the minimum allowed, where the minimum amount is the selected asset's quantum multiplied by the value of `spam.protection.minimumWithdrawalQuantumMultiple` network parameter (1002-WITH-026) - -- **should** see a link to a faucet on the selected asset (only if there is one) - -- **must** specify the Ethereum address that can claim the withdrawal (e.g. where you are withdrawing too) (1002-WITH-006) - - - **should** be able to easily select an Ethereum key the app is already connected to - - **should** be able to withdraw to a different Ethereum key to the one the app is connected to - - **should** be warned if the input does not look like an ethereum address (wrong number of characters, not starting with 0x etc) - -- if there is a withdraw delay on the selected asset: - - - **should** see how large a withdrawal (or sum of withdrawals) needs to be to hit the `withdraw delay threshold` - - **should** see what the withdraw delay is in hours and mins (if hit) - - **should** see how much I have withdrawn in the last `withdraw delay period` - - **must** be warned if this withdraw will hit a the delay before hitting withdraw (1002-WITH-007) - -- **must** be warned if there are known reasons that the prepared withdrawal will not work (1002-WITH-008) -- **must** submit a withdraw [vega transaction](0003-WTXN-submit_vega_transaction.md) (1002-WITH-009) - -- if the preparing the withdraw on Vega fails: - - - **must** be directed back to the withdraw form (containing the submitted values) and see an explanation of why the transaction failed, so I can fix and resubmit (1002-WITH-010) - -- if the preparing the withdraw on Vega is successful: - - **must** see that withdraw is prepared (1002-WITH-011) - - if this withdraw will not hit the withdrawal threshold: - - **should** be prompted to complete the transaction on ethereum (see [complete ERC20 withdraw](#complete-erc20-withdraw-from-ethereum-bridge)) - - **could** be directed to a list of incomplete withdrawals - - if this withdraw will hit withdrawal threshold: - - **must** see that the withdraw has been complete and is in the list waiting for the delay to pass (1002-WITH-024) - -...so that I can get the details required to release my funds from the the Ethereum ERC20 bridge. - -## Withdraws list / history - -When looking to either complete a withdraw or view past withdraws, I... - -- **must** be able to navigate to a list prepared withdrawals for the [connected to a vega wallet + key(s)](0002-WCON-connect_vega_wallet.md) - -- for each prepared withdraw: - - **must** see the asset being withdrawn (1002-WITH-012) - - **must** see the [amount](7001-DATA-data_display.md#asset-balances) being withdrawn (1002-WITH-013) - - **must** see the destination of the withdrawal (e.g. Recipient Eth address) (1002-WITH-014) - - **should** see the date with withdraw was prepared - - **could** see the full signature bundle from Vega node (for use on Ethereum) - - for withdraws that are in progress: - - **must** see the status of the withdraw (e.g. pending) (1002-WITH-015) - - for completed withdraws: - - **could** see when it was completed on native chain (e.g. ethereum) - - **must** see a link to the transaction on native block explorer (e.g. etherscan) (1002-WITH-016) - - for withdraws that have not been completed on the external chain, but are not delayed (e.g. Ethereum): - - **must** see a link to complete the withdraw. See [complete ERC20 withdrawal](#complete-erc20-withdraw-from-ethereum-bridge) (1002-WITH-017) - - for withdrawals that have a delay in place before the transaction can be completed: - - **should** see much of the delay remains before it can be completed - - for withdraws that failed to be prepared (e.g. there was not enough in the general account): - - **must** show that the withdraw preparation failed (1002-WITH-025) - -... so I can complete withdrawals or find details of previous ones - -## Complete ERC20 withdraw from Ethereum bridge - -When looking to submit the Ethereum transaction to release funds from the Vega bridge into my Ethereum wallet, I... - -- **must** see a link to [connect an ethereum wallet](0004-EWAL-connect_ethereum_wallet.md) if not already connected (1002-WITH-018) -- **must** see a link to [submit the ethereum transaction to finish withdrawal](0005-ETXN-submit_ethereum_transaction.md) (1002-WITH-019) -- **could** be warned if the connected ethereum wallet is different to the one that the withdraw is going to credit (this is permitted but is a good reminder to the user about what to expect) - -- if successful: - - **must** see asset balances have been updated post withdrawal (1002-WITH-020) - - **must** see the list of withdrawals (with updated status) (1002-WITH-021) - - **could** see prompt to start another transaction or complete another incomplete one -- if failed: - - **must** see a description of why the transaction failed, and advised what to do (e.g. bad signature) (1002-WITH-022) - - **must** be returned to a state where I can correct anything that is wrong, and attempt to submit the transaction again (1002-WITH-023) - - **should** see a link to docs about withdrawals for trouble shooting (e.g. if the signer set has changed significantly since the withdraw was prepared) - - **should** see status of incomplete withdrawals (so I can confirm the withdraw I attempted to complete is incomplete) - -... so the funds I withdrew from Vega are credited to my Ethereum key diff --git a/user-interface/1003-TRAN-transfer.md b/user-interface/1003-TRAN-transfer.md deleted file mode 100644 index 6ffe0b04a..000000000 --- a/user-interface/1003-TRAN-transfer.md +++ /dev/null @@ -1,59 +0,0 @@ -# Transfer - - -## Transfer Window -- **Must** be able to open transfer window through transfer button under key, account history page and collateral options ([1003-TRAN-001](#1003-TRAN-001)) - -- **Must** be able to close the window with the x ([1003-TRAN-002](#1003-TRAN-002)) - -- **Must** display a message showing obfuscated key that funds will be transferred from ([1003-TRAN-003](#1003-TRAN-003)) - -- **Must** each field has their label. Vega key, Asset, Amount ([1003-TRAN-004](#1003-TRAN-004)) - - -## Vega Key - -- **Must** -if the user has multiple keys they must be able to swap between dropdown and manual entry ([1003-TRAN-005](#1003-TRAN-005)) - -- **Must** -if the user has multiple keys they must be able to select from their list of keys([1003-TRAN-006](#1003-TRAN-006)) - -## Asset -- **Must** display a drop down with all assets in the portfolio ([1003-TRAN-007](#1003-TRAN-007)) - -- **Must** the holdings of each asset is displayed ([1003-TRAN-008](#1003-TRAN-008)) - -- **Must** i can select any available assets and selected asset is displayed ([1003-TRAN-009](#1003-TRAN-009)) - -- **Must** selected asset shortname is displayed in the amount field ([1003-TRAN-010](#1003-TRAN-010)) - - -## Validation -- **Must** cannot choose amount over current collateral. Message is displayed ([1003-TRAN-011](#1003-TRAN-011)) - -- **Must** display "required" message on each field if left blank when clicking button "Confirm Transfer" ([1003-TRAN-012](#1003-TRAN-012)) - -- **Must** display "Invalid vega key" message on Vega Key field if entered key doesn't pass validation([1003-TRAN-013](#1003-TRAN-013)) - -- **Must** "Value below minimum" message is shown if amount is lower than minimum([1003-TRAN-014](#1003-TRAN-014)) - - -## Transfer -- **Must** can select include transfer fee ([1003-TRAN-015](#1003-TRAN-015)) - -- **Must** display tooltip for "Include transfer fee" when hovered over.([1003-TRAN-016](#1003-TRAN-016)) - -- **Must** display tooltip for "Transfer fee when hovered over.([1003-TRAN-017](#1003-TRAN-017)) - -- **Must** display tooltip for "Amount to be transferred" when hovered over.([1003-TRAN-018](#1003-TRAN-018)) - -- **Must** display tooltip for "Total amount (with fee)" when hovered over.([1003-TRAN-019](#1003-TRAN-019)) - -- **Must** amount to be transferred and transfer fee update correctly when include transfer fee is selected ([1003-TRAN-020](#1003-TRAN-020)) - -- **Must** total amount with fee is correct with and without "Include transfer fee" selected ([1003-TRAN-021](#1003-TRAN-021)) - -- **Must** i cannot select include transfer fee unless amount is entered ([1003-TRAN-022](#1003-TRAN-022)) - -- **Must** With all fields entered correctly, clicking "confirm transfer" button will start transaction([1003-TRAN-023](#1003-TRAN-023)) \ No newline at end of file diff --git a/user-interface/1004-ASSO-associate.md b/user-interface/1004-ASSO-associate.md deleted file mode 100644 index 354da296f..000000000 --- a/user-interface/1004-ASSO-associate.md +++ /dev/null @@ -1,71 +0,0 @@ -# Associate and disassociate governance tokens with a Vega key - -The Governance token on a Vega network is an ERC20 ethereum token. It has two utilities on Vega, - -- Staking the Proof of stake network, -- Participating in Governance. - -To use the Governance token on a Vega network it first needs to be associated with a Vega key/party. This Vega key can then stake, propose and vote. - -The word "associate" is used in some user interfaces, as apposed the word "stake" in function names. Stake can be avoided to prevent users thinking they would get a return only after the staking step. On Vega `Staking = Association + Nomination`, as in you need to run the "stake " function on Ethereum but then the nominate step on Vega before you get staking income. See [Glossary](../glossaries/staking-and-governance.md). - -Associated tokens also count as vote weight in on-Vega governance (new markets etc), A parties vote weight is backed by the number of Governance tokens associated with that Vega key/party. - -Associating tokens to a Vega key is a little like depositing, except, a deposit can only be released by the Vega network, where as an association can be revoked on ethereum by the the eth key that did the association. - -Governance tokens may be held by a [Vesting contract](1005-VEST-vesting.md). - -## Token discovery - -When looking to acquire governance tokens, I... - -- **must** see the contract address for the governance token of the Vega network 1004-ASSO-001 - -...so I can participate in governance and staking. - -## Associate - -When looking to stake validators or participate in governance, I first need to associate governance tokens with a Vega wallet/key, I... - -- **must** [connect an Ethereum wallet/key](0004-EWAL-connect_ethereum_wallet.md) to see tokens it may have in wallet or attributed to it in the vesting contract 1004-ASSO-002 -- **must** select a Vega key to associate to 1004-ASSO-003 - - **must** be able use a [connected Vega wallet](0002-WCON-connect_vega_wallet.md) as instead of manually inputting a public key 1004-ASSO-004 - - **should** be able to populate field with a string, so I can associate to a wallet I without connecting it -- if the connected ethereum wallet has vesting tokens: **must** be able to select to associate from either the vesting contract or the wallet (The default should be wallet and the option to use vesting tokens should only appear if there are tokens in a tranche (associated or not)) 1004-ASSO-006 -- **must** see the number of associated and un-associated tokens in the selected wallet/vesting contract 1004-ASSO-007 -- **must** select the amount of tokens to associate 1004-ASSO-008 - - **must** be able to populate the input with the amount of un-associated tokens for the selected wallet/vesting contract 1004-ASSO-009 -- **must** be warned if the amount being associated is greater than the amount available in the connected ethereum wallet 1004-ASSO-010 -- **must** submit the association on [Ethereum transaction(s) inc ERC20 approval if required](0005-ETXN-submit_ethereum_transaction.md) 1004-ASSO-011 -- **must** see feedback whether my association has been registered on Ethereum 1004-ASSO-012 -- **must** see feedback that the association has been registered by Vega and that it can be used after the number of Ethereum block confirmations required (typically 50, check network param) 1004-ASSO-013 - - **should** be able to see a balance for the number of tokens associated that are ready for use 1004-ASSO-014 - - **should** be able to see a balance for the number of tokens for each pending association 1004-ASSO-015 -- on completion: **should** be prompted to go on to [nominate](2001-STKE-staking.md) and/or participate in [Governance](1004-GOVE-governance_list.md) -- **must** see the balances of tokens available in Ethereum wallet updated (both associated and un-associated) 1004-ASSO-030 -- **must** see the balances of tokens available in vesting contract updated (both associated and un-associated) 1004-ASSO-032 - -...so I can then use the Vega wallet to use my tokens. - -## Disassociate - -When wanting to remove governance tokens, I... - -- **must** [connect an Ethereum wallet/key](0004-EWAL-connect_ethereum_wallet.md) to see tokens it may have in wallet or attributed to it in the vesting contract 1004-ASSO-018 -- **must** see a list Vega keys that the connected Ethereum wallet has associated too 1004-ASSO-019 - - **must** see an amount associated with each key 1004-ASSO-020 - - **must** see the full Vega public key associated too 1004-ASSO-021 - - **must** see the the origin of the association: wallet or vesting contract 1004-ASSO-022 - - **should** be able to select one row (vega key + amount) to populate disassociate form with the key you want to disassociate from and how much 1004-ASSO-023 -- If some of the tokens for the given Eth key are held by the vesting contract: **must** select to return tokens to Vesting contract 1004-ASSO-024 -- **must** select an amount of tokens to disassociate 1004-ASSO-031 - - **must** be able to populate the input with the amount of associated tokens for the selected Vega wallet/contract 1004-ASSO-025 -- **should** be warned that disassociating will forfeit and rewards for the current epoch and reduce the Vote weigh on any open proposals -- **must** be warned if the inputs on the form will result in an invalid withdraw, before submitting 1004-ASSO-026 -- **must** action the disassociation [Ethereum transaction](0005-ETXN-submit_ethereum_transaction.md) 1004-ASSO-027 -- **must** see feedback on the progress of the disassociation on ethereum 1004-ASSO-028 -- **must** see new associated balances in Vega (theses should be applied instantly, rather than wait for the 50 eth blocks like associate) 1004-ASSO-029 -- on completion (if tokens were returned to vesting contract): **could** be prompted to go on to [redeem](1001-VEST-vesting.md). - -...so that I can transfer them to another Ethereum wallet (e.g. sell them on an exchange). - \ No newline at end of file diff --git a/user-interface/1005-VEST-vesting.md b/user-interface/1005-VEST-vesting.md deleted file mode 100644 index cf9d472da..000000000 --- a/user-interface/1005-VEST-vesting.md +++ /dev/null @@ -1,80 +0,0 @@ -# Vesting - -Some governance tokens may be held by a Vesting contract. This means that can be "owned" by an Ethereum key but not freely transferred until a vesting terms are complete. - -## list of tranches - -When looking to understand to overall vesting schedule for tokens, I... - -- **must** see a list of tranches 1005-VEST-001 -- **should** see a visualization of the vesting schedule with a break down of the type of token holders (e.g. team, investors, community) 1005-VEST-002 - -For each tranche: - -- **must** see a tranche number 1005-VEST-003 -- **could** see any annotation of what this tranche is about (e.g. community schedule A) -- **must** see a sum of tokens in the tranche 1005-VEST-005 - - **must** see how many tokens in the tranche are locked 1005-VEST-006 - - **must** see how how many tokens in the tranche are redeemable 1005-VEST-007 -- **must** see the vesting terms for each tranche (when unlocking stats and ends) 1005-VEST-008 - -... so I can understand how circulating supply could change over time. - -## Details of a tranche - -When looking into a specific tranche, I... - -- **must** see all the same details as the [list of tranches](#details-of-a-tranche) -- **should** see a list of ethereum wallets with tokens in this tranche - -for each ethereum wallet: - -- **should** see the full eth address of the wallet -- **should** see the total tokens this address holds in this tranche - - **should** see how many tokens in the tranche are locked - - **should** see how how many tokens in the tranche are redeemable - -... so I can see the details of how tokens are distributed in this tranche - -## See summary for a given Ethereum key - -When looking to see how many tokens I have in total, and how many I might be able to redeem, I... - -- **must** be able to [Connect and ethereum wallet](0004-EWAL-connect_ethereum_wallet.md) 1005-VEST-018 -- **should** be able input an ethereum address - -for the a given Ethereum wallet/address/key: - -- **must** see a total of tokens across all tranches 1005-VEST-020 - - **must** see how many tokens across all tranches are locked 1005-VEST-021 - - **must** see how many tokens across all tranches are redeemable 1005-VEST-022 -- **must** see a list of tranches this key has tokens in 1005-VEST-023 -- **must** see a total of tokens in each tranche 1005-VEST-024 - - **must** see how many tokens in each tranche are locked 1005-VEST-025 - - **must** see how many tokens in each tranche are redeemable 1005-VEST-026 - - **must** see an option to redeem from tranche 1005-VEST-027 - - **must** be warned if amount that can be redeemed from that tranche is greater than the un-associated balance for that Eth key (because this will cause the redeem function to fail) 1005-VEST-028 - - **should** see how many tokens I'd need to disassociate to be able to run the redeem function (this should be rounded up to avoid the transaction failing due to more tokens having unlocked since the user looked at the form) - - **should** see link to [disassociate](1004-ASSO-associate.md) - -... so I can easily see how many tokens I have, and can redeem. - -## Redeem tokens from a tranche - -Note: it is not possible to choose how many tokens you redeem from a tranche, instead you select a tranche and the smart contract will attempt to redeem all. However, it will fail if some of the amount it attempts to redeem have been associated to a Vega key. Therefore the job of this page is to help the user work out how many tokens to disassociate before they can successfully redeem. - -When looking to redeem tokens, I... - -- **must** [connect the ethereum wallet](0004-EWAL-connect_ethereum_wallet.md) that holds tokens 1005-VEST-029 -- must see see all tranches that you have tokens in (including tranche 0) 1005-VEST-036 -- must see a total of tokens across all tranches (including tranche 0) 1005-VEST-037 -- **must** select a tranche to redeem from 1005-VEST-030 -- **must** see the number of tokens that can be redeemed 1005-VEST-031 -- **must** be warned if the number of tokens you would be attempting to redeem is greater than you have unassociated 1005-VEST-035 - - **should** tell you how many tokens to disassociate for the redeem function to work (should round up to create a buffer for the tokens that may unlock between now and when the user gets to the disassociate form) - - **should** see a link to disassociate -- **must** submit the redeem from tranche [ethereum transaction](0005-ETXN-submit_ethereum_transaction.md) 1005-VEST-032 -- **must** get feedback on the progress of the Ethereum transaction 1005-VEST-033 -- **must** see updated balances (in the trance and my eth wallet) after redemption 1005-VEST-034 - -... so that I can use this tokens more generally on Ethereum (transfer to another key etc) \ No newline at end of file diff --git a/user-interface/1101-BWAL-browser_wallet.md b/user-interface/1101-BWAL-browser_wallet.md deleted file mode 100644 index 4418f6953..000000000 --- a/user-interface/1101-BWAL-browser_wallet.md +++ /dev/null @@ -1,148 +0,0 @@ -# Browser Wallet - -## Create app password - -As a browser wallet user I want to create a password for my browser wallet app So that I can secure my wallets and keys on this device - -- When I haven't submitted my password, I can go back to the previous step (1101-BWAL-001) -- I can see an explanation of what the password is for and that it cannot be used to recover my keys or recover itself (1101-BWAL-002) -- I can enter a password for the browser wallet (1101-BWAL-003) -- I can verify the password I set for my browser wallet (to help ensure I typed it correctly and can replicate it) (1101-BWAL-004) -- I can verify that I understand that Vega doesn't store and therefore can't recover this password if I lose it (1101-BWAL-005) -- I can NOT submit an empty password (1101-BWAL-006) -- I can submit the password I entered (1101-BWAL-007) -- When I have submitted my new password, I am given some feedback that it was set successfully (1101-BWAL-008) -- When I have submitted my new password, I am taken to the next step (1101-BWAL-009) -- When I have submitted my new password, I can NOT go back to the previous step (1101-BWAL-010) -- After setting a password, my wallets are encrypted (1101-BWAL-011) - -## Create or import wallet - -As a browser wallet user I want to decide whether to create a new wallet or import an existing one So that I understand my options and don't waste time creating a new wallet when I already created one elsewhere - -- I can choose to create a wallet (1101-BWAL-012) -- I can choose to import an existing wallet (1101-BWAL-013) - -## Create wallet and key pair - -As a browser wallet user When I am using the browser wallet for the first time I want to create a new wallet (and key pair) So that I can get started using Console / another Vega dapp to trade / take part in governance -- I am provided with a recovery phrase for my new wallet that is initially hidden from view(1101-BWAL-014) -- I can see an explanation of what the recovery phrase is for and that it cannot be recovered itself (1101-BWAL-015) -- I can choose when to reveal/show the recovery phrase (1101-BWAL-016) -- I can copy the recovery phrase into my clipboard (1101-BWAL-017) -- I can verify that I understand that Vega doesn't store and therefore can't recover this recovery phrase if I lose it (1101-BWAL-018) -- I am given feedback that my wallet was successfully created (1101-BWAL-019) -- I am redirected to the next step - opt in to error reporting (1101-BWAL-020) -- The new Wallet name and key pair are auto generated in the background "Wallet" "Vega Key 1" (1101-BWAL-021) -- When I have already created a wallet, I am redirected to the landing page where I can view that wallet (rather than the onboarding flow) (1101-BWAL-022) - -## Confirm recovery phrase - -As a wallet user I want to validate I have "recorded" or saved the recovery phrase accurately So that I feel secure and confident to go ahead - -- I can confirm I have written down / saved my recovery phrase by entering parts of it again in the UI(1101-BWAL-023) -- There is a way to go back to see the full recovery phrase if I have written / saved it incorrectly (1101-BWAL-024) -- I can click to continue to the next step of onboarding once I've successfully entered the relevant parts of the phrase (1101-BWAL-025) -- There is a way to understand if the details I've entered are incorrect e.g. highlight in red (1101-BWAL-026) - -## View network connected to - -As a browser wallet user I want to know which vega network my browser wallet is connected to So that I know if I am on the network I expect to be, and whether I am transacting with real or fake assets - -- The browser wallet defaults to use the Fairground network (1101-BWAL-027) -- I can see which vega network the browser wallet is connected to from the view wallet page(1101-BWAL-028) - -## Create key pairs - -As a wallet user I want to be able to create multiple key pairs in my wallet So that I can use different keys for different - -- I can create a new key pair from the wallet view (1101-BWAL-029) -- New key pairs are assigned a name automatically "Vega Key 1" "Vega Key 2" etc.(1101-BWAL-030) -- New key pairs are listed in order they were created - oldest first(1101-BWAL-031) - -## Remember where I am in the onboarding flow - -As a browser wallet user When I have started onboarding in the browser wallet and I close the extension / browser I want to be able to reopen the extension and it remember where I was in the onboarding flow So that I don't have to start again - -- I can close the extension and when I reopen it it opens on the same page / view (1101-BWAL-032) - -## Connect all key(s) only - -As a wallet user I want to connect my key(s) to a dapp So that I can verify transactions like orders, transfers etc. - -- There is a way to approve or deny a connection request (1101-BWAL-033) -- I can see a visual representation of the dapp requesting access e.g. the favicon (1101-BWAL-034) -- I can see what approving a connection request enables the site / dapp to do (1101-BWAL-035) -- I can see the URL of the site / dapp requesting access(1101-BWAL-036) -- All new connections are for all keys in a wallet and all future keys added to the wallet(1101-BWAL-037) -- There is a way to understand that i.e. this connection request gives access to ALL my keys now and in the future (1101-BWAL-038) -- When I go away from the extension and come back to the connected site, the browser extension remembers the connection and does not ask me to reconnect (1101-BWAL-039) -- There is a visual way to understand that a connection has been successful(1101-BWAL-040) -- If I did not have the browser wallet open when I instigated the connection request, the browser wallet "closes" after approving (connect) or rejecting (deny) the connection request (1101-BWAL-041) -- If the had the browser wallet open when I instigated the connection request, the browser wallet returns your view to where you were before the request came in (1101-BWAL-042) -- When I try to connect to the wallet I've made during onboarding but have not "completed" onboarding, I cannot see the connection request until I've completed onboarding (it is queued in the background) (1101-BWAL-043) - -## Approve transaction request - -As a browser wallet user I want to be able to approve a transaction request So that I can verify and complete the action I am trying to make on the vega dapp I'm using - -- When I view a transaction request I can choose to approve it (1101-BWAL-044) -- When I approve a transaction the transaction gets signed and the approved status gets fed back to the dapp that requested it (1101-BWAL-045) -- When I approve a transaction after I have approved it we revert to the next transaction if there's a queue OR we revert to the key view (the front / homepage) (1101-BWAL-046) - -## Reject transaction request - -As a browser wallet user I want to be able to reject a transaction request So that I can prevent a transaction going through that I don't recognise as mine, or have changed my mind on / identified a mistake etc. - -- When I view a transaction request I can choose to reject it(1101-BWAL-047) -- When I reject a transaction the transaction does not get signed and the rejected status gets fed back to the dapp that requested it (1101-BWAL-048) -- When I reject a transaction after I have rejected it we revert to the next transaction if there's a queue OR we revert to the key view (start / home page) (1101-BWAL-049) - -## View trasaction request (generic) - -As a user I want to recognise transactions that are not orders or withdraw / transfer requests with at least the bear minimum information needed to proceed So that I can continue my task (e.g. governing, staking) - -- When the dapp requests a transaction with a key we don't know about, we don't see a request in the wallet but instead send an error back to the dapp(1101-BWAL-050) -- When the dapp requests a transaction type / or includes transaction details that we don't recognise, we don't present the transaction request in the wallet but provide an error to the dapp that feeds back that the transaction can not be processed (1101-BWAL-051) -- When the user opens the extension (or it has automatically opened) they can immediately see a transaction request (1101-BWAL-052) -- If the browser extension is closed during a transaction request, the request persists (1101-BWAL-053) -- For transactions that are not orders or withdraw / transfers, there is a standard template with the minimum information required i.e. (1101-BWAL-054) - -- [ ] Transaction title - -- [ ] Where it is from e.g. console.vega.xyz with a favicon - -- [ ] The key you are using to sign with a visual identifier - -- [ ] When it was received - -- [ ] Raw JSON details -- I can copy the raw json to my clipboard (1101-BWAL-055) -- When I try to submit a transaction to the wallet I've made during onboarding but have not "completed" onboarding, I cannot see the transaction request until I've completed onboarding (it is queued in the background) (1101-BWAL-056) - -## Log in (next time password expires) - -As a wallet user I want a way to enter my password when my login has expired So that I can continue with my task - -- When I have quit my browser, and then reopened, I am asked to enter my browser extension password(1101-BWAL-057) -- I am informed if I enter my password incorrectly (1101-BWAL-058) -- When entering a correct password decrypts my wallets (1101-BWAL-059) - -## View wallet and key pairs - -As a browser wallet user I want to view my vega wallet (and key pair(s)) So that I can see that I've been successful creating the wallet / see my key ID - -- I can see a list of the keys in my wallet (1101-BWAL-060) -- I can copy the public key ID to my clipboard (1101-BWAL-061) -- I can see information of where to go to deposit and manage my assets (1101-BWAL-062) -- I can see where I am in the app when viewing my wallet and key pair(s) (1101-BWAL-063) - -## Wallet version number (Settings) - -As a wallet user I want to understand the version # I am using So that I can trouble shoot should there be any issues - -- I can see the version # of the browser extension (1101-BWAL-064) -- I can see the feedback link (1101-BWAL-065) -- I can see a lock button and when I press it I am logged out and redirected to the login page (1101-BWAL-066) - -## Coming back to the app after onboarding - -As a user I want to see my wallet / keys immediately when I open my extension (and not onboarding again) So that I don't need to repeat onboarding unnecessarily and continue my task easily... - -- There is a way to determine if user has onboarded (1101-BWAL-067) -- I want to see the previous page I was on or my wallet page by default (1101-BWAL-068) \ No newline at end of file diff --git a/user-interface/2001-STKE-staking.md b/user-interface/2001-STKE-staking.md deleted file mode 100644 index e2f61b840..000000000 --- a/user-interface/2001-STKE-staking.md +++ /dev/null @@ -1,121 +0,0 @@ -# Staking - -Staking is the act of securing a Vega network by nominating good validators with the [governance token](../protocol/0071-STAK-erc20_governance_token_staking.md). Staking is rewarded with a share of trading fees (and [treasury rewards](../0056-REWA-rewards_overview.md)). See the [glossary](../glossaries/staking-and-governance.md) and [these specs](../protocol#delegation-staking-and-rewards) for more on staking. - -When staking a user may be motivated to select validators to maximize the rewards they get for the tokens they hold, this means selecting validator(s) who are less likely to be penalized (e.g. over staked, poor performance). Users may wish to stake more than one validator to diversify. Users will want/need to manage their stake over time to ensure they are getting a good return, e.g. move stake between validators. Staking is also important for facilitating protocol upgrades. - -## Understand staking on Vega - -When considering whether to stake on Vega, I... - -- **should** see information to help inform me what return I might expect from staking (other protocols might show a typical APY) -- **must** see that the governance token is an ethereum ERC20 token and needs to attributed (or associated) to a Vega wallet for use on Vega 1002-STKE-002 -- **must** see detailed documentation on how staking works on Vega 1002-STKE-003 - -...so I can decide if I want to stake on Vega, and how to go about doing it. - -Note: There are many ways that "understanding the return" can be done, and this does not impose a particular solution. Solutions could... - -- look at previous epochs, -- average this over a period, -- select a range of validators or just one, -- could have a calculator that allows the user to enter some values or just show this on the list of validators - -Note: Income may come in a range of different tokens, as markets can settle in different assets, and there may be rewards paid out by the treasury. - -## Associate tokens - -Before I stake, I need to [Associate tokens](./1000-ASSO-associate.md) with a Vega wallet/key... - -- **must** see link[Associate tokens](./1000-ASSO-associate.md) -- **should** see that if no further action is taken, newly associated tokens will be nominated to validators based on existing distribution - -...so that I can nominate validators. - -## Select validator(s) - -When selecting what validators to nominate with my stake, I... - -- **should** be able to select any data that is available on Validators in a table - -- **must** see all validator information without having to connect Vega wallet 1002-STKE-050 -- see "static" information about the validator (these can change, just not frequently) - - **must** see name 1002-STKE-006 - - **must** see Vega public key 1002-STKE-008 - - **should** see a URL where to find more information about the validator (if there is one) - - **must** see Ethereum address1002-STKE-010 -- can see data for the current/next epoch, for each validator - - **must** see the current "status" (consensus, Ersatz, New etc) 1002-STKE-011 - - **must** see a total stake (inc self stake) 1002-STKE-012 - - **must** see self stake 1002-STKE-013 - - **must** see nominated stake 1002-STKE-014 - - **must** see total stake as a % of total staked across all nodes 1002-STKE-051 - - **must** see total stake change next epoch 1002-STKE-015 - - **must** see self stake 1002-STKE-016 - - **must** see nominated stake 1002-STKE-017 - - **must** see total stake as a % change 1002-STKE-052 - - **should** see the version of Vega they are currently running - - **should** see the version of Vega they propose running -- can see data for the previous epoch - - **must** see the overall "score" for a validator for the previous epoch 1002-STKE-020 - - can see all the inputs to that "score" - - **must** see Ranking score 1002-STKE-021 - - **must** see stake score 1002-STKE-022 - - **must** see performance score 1002-STKE-023 - - **must** see voting score 1002-STKE-024 -- can see data for previous epochs - - **should** see the the overall "score" for all previous epochs for each validator 1002-STKE-025 - - can see a breakdown of all the inputs to that "score" for all previous epochs - - **should** see Ranking score - - **should** see stake score - - **should** see performance score - - **should** see voting score - -...so I can select validators that should give me the biggest return. - -## Nominate a validator - -Note: User interfaces may use the term "Nominate", technically the function is called "delegate". Delegating tokens to a validator may imply that you also give that validator your vote on proposals, at time of writing, it does not. It only gives them the potential for more "voting power" in the production of blocks. - -Within a staking epoch (typically 24 hours) a user can change their nominations many times, however the changes are only effective at the end of the epoch. You will only get rewards for a full epoch staked. - -When attributing some (or all of my governance tokens to a given validator), I... - -- **must** select a validator I want to nominate 1002-STKE-031 -- **must** see link to [connect to a Vega wallet/key](0002-WCON-connect_vega_wallet.md) (if not already) that has associated Vega (or Pending association) 1002-STKE-032 -- **must** select an amount of tokens 1002-STKE-033 - - **must** be able to populate this with the amount of governance tokens that will be associated but not nominated at the beginning of the next epoch 1002-STKE-034 - - **must** be warned if the amount I am about to nominate is below a minimum amount (spam protection) 1002-STKE-035 - - **must** be warned if the amount I am about to nominate is more than I have associated + un-nominated at the end of current epoch/beginning of next 1002-STKE-036 -- **must** submit the nomination [Vega transactions](0003-WTXN-submit_vega_transaction.md) 1002-STKE-037 -- **must** see feedback that my nomination has been registered, and will be processed at the next epoch 1002-STKE-038 -- **must** see all my pending nomination changes for the next epoch 1002-STKE-039 - -...so that I am rewarded for a share based on this validators performance. - -## Monitor staking rewards - -When checking if im getting the staking return that I was expecting, I... - -- See [Staking income](2002-SINC-staking-income.md) - -...so that I can make decisions about my staking, e.g. whether to re-distribute my stake. - -## Un-nominate validator - -When removing stake from a validator, I... - -- **must** select a validator I want to un-nominate 1002-STKE-040 -- **must** [connect to a Vega wallet/key](0002-WCON-connect_vega_wallet.md) with nominated stake, if not already 1002-STKE-041 -- - **must** have the option of withdrawing nominated amount at the end of the epoch (and maintain the staking income for the current epoch) 1002-STKE-053 -- **should** have the option of withdrawing nomination amount now immediately (and forfeit the staking income) -- **must** set an amount to remove from a validator 1002-STKE-044 - - **must** be able populate with the total delegated amount at the time where un-nominate will happen 1002-STKE-045 - - **must** be warned if amount is greater than the amount that will be on that validator at the end of the epoch 1002-STKE-046 - 1002-STKE-047 -- **must** submit un-nominate [Vega transaction](0003-WTXN-submit_vega_transaction.md) 1002-STKE-048 -- **must** see feedback that the un-nomination has been registered, and that the un-nominated amount is now available for re-nomination 1002-STKE-049 - -... so that I can use this stake for another validator etc. - -note: if a user just wishes to seel their tokens and not wait for the end of an epoch they could simply [disassociate](1004-ASSO-associate.md#disassociate) (as long as tokens are not held by vesting contract) \ No newline at end of file diff --git a/user-interface/2002-SINC-staking-income.md b/user-interface/2002-SINC-staking-income.md deleted file mode 100644 index 79a1a709a..000000000 --- a/user-interface/2002-SINC-staking-income.md +++ /dev/null @@ -1,32 +0,0 @@ -# Staking income - -## Monitor staking rewards - -When checking the staking rewards, I... - -- must be [connected to a Vega wallet](0002-WCON-connect_vega_wallet.md) - -- **must** see when the current epoch ends 2002-SINC-001 -- **should** see when the current epoch started -- **should** see how much the connected wallet might earn at the end of the epoch (with some assumptions) - - **should** see the balance of all infrastructure fee accounts for the current epoch - - **should** see real time validator score for the current epoch - - **should** see if any validators have had a penalty this epoch -- **must** see the sum of Tokens I have nominated to each validator in the current epoch 2002-SINC-007 -- **should** see what percentage of my Tokens I have nominated to each validator in the current epoch -- **must** see the staking income I have received for each epoch previous 2002-SINC-009 - - **must** see asset name 2002-SINC-010 - - **must** see balance of asset 2002-SINC-011 - - **must** see type (organic or treasury) 2002-SINC-012 -- **should** see the staking income by epoch, broken down by validator -- **should** see the staking income by epoch, broken down by market - -- **should** see all income values expressed in a single currency - -- **must** see current asset balances for connected wallets 2002-SINC-016 -- **must** see link to [withdraw](1002-WITH-withdraw.md) assets 2002-SINC-017 - -- **must** see where I can see where I did not receive full income because the validator suffered penalties 2002-SINC-018 - -...so that I can make decisions about my staking - \ No newline at end of file diff --git a/user-interface/3001-VOTE-vote.md b/user-interface/3001-VOTE-vote.md deleted file mode 100644 index 006fb7416..000000000 --- a/user-interface/3001-VOTE-vote.md +++ /dev/null @@ -1,157 +0,0 @@ -# Vote - -Background: [Governance spec](../protocol/0028-GOVE-governance.md) -and [docs](https://s.vega.xyz/s/mainnet/concepts/vega-protocol#governance). - -There are a few things that can be governed on Vega... - -- Network parameters (variables used by the network) -- Markets (creation and changes to existing) -- Assets (creation on changes to existing) -- "Freeform", which has no affect on the network but can be used to to measure token holders views - -To make proposal: a user will require an amount of the Governance token [associated](1004-ASSO-associate.md) with their key. - -To vote: a user will require [associated](1004-ASSO-associate.md) Governance tokens (or in the case of market change proposals they could have an active liquidity provision). - -Each vote has a weight behind it based on the number of associate tokens or the liquidity provision's equity like share at the point in time that the vote closes. - -Each proposal type will have a majority required (vote weight in favour) and a participation required (the turn out for the vote needs to be sufficient to be valid). - -A proposal has a life cycle and various statuses to track it's progress. proposals that accept votes can have a few different statuses. A short hand is used in these ACs: - -- Open = Accepting votes (includes `waitingForNodeVote`) -- To enact = passed but not yet enacted (`pending) -- Closed = was accepting votes but deadline has passed (e.g. `passed`, `rejected` etc) -- `Failed` = did not get to the point of accepting votes. - -## list of proposals - -When looking for a particular proposal or wanting to see what proposals are open, soon to enact or closed, I... - -- **must** see link to details on how governance works in docs (3001-VOTE-001) -- **must** see link(s) to make proposals (3001-VOTE-002) -- **must** if there are no proposals, see that there have been no proposals since the last chain checkpoint restore (3001-VOTE-003) -- **must** see open proposals (and ones due for enactment) distinct from others (e.g grouped by "open", "to enact" "closed") (note: freeform proposals do not enact so should be shown as "closed" when "passed") (3001-VOTE-004) -- **should** see proposals sorted with the ones closest to enactment first (within each group) -- **must** see a history of all "closed" proposals (3001-VOTE-006) -- can search for a proposal by: - - **should** be able to search by proposal ID - - **should** be able to search by public key of the proposer - - **should** be abel to search by market ID/name/code (ID may be the same as proposal ID) - - **should** be able to search by asset name/symbol - - **should** be able to search by network parameter - - **should** be able to search by content of proposal description - -for each proposal: - -- **must** see the type of proposal (3001-VOTE-007) -- **must** see the proposal title (3001-VOTE-097) -- **should** see a summary of what the type of proposed change is, without looking at details (network, new market etc) - - for network parameters: **should** see what parameter is being changed and new value - - for network parameters: **could** see what the current values are for that parameter - - for network parameters: **could** see if there are other open proposals for the same parameter - - for new markets: **should** see the type of market (e.g. Future) - - for new markets: **could** see the type trading mode of the market (e.g. auction, continuous) - - for new markets: **should** see the name of the new market - - for new markets: **should** see the code of the new market - - for new markets: **should** see the settlement asset of the new market (not just asset ID but asset Symbol) - - for new markets: **could** see a summary of the oracle used for settlement - - for market changes: **should** see the name of the market being changed - - for market changes: **should** see a summary of what parameters are being changed - - for market changes: **should** see a the proposed values for parameters - - for market changes: **should** see a the current values for that parameter - - for market changes: **could** see if there are other open proposals for the same market - - for new assets: **must** see the name of the new asset (3001-VOTE-026) - - for new assets: **must** see the code of the new asset (3001-VOTE-027) - - for new assets: **must** see the source of the new asset (e.g. ERC20) (3001-VOTE-028) - - for new assets (if source is ERC20): **must** see contract address (3001-VOTE-095) - - for new assets (if source is ERC20): **must** see if the Asset has been whitelisted on the bridge (3001-VOTE-096) - - for asset changes: **must** see name of asset being changed (3001-VOTE-029) - - for asset changes: **must** see the parameter(s) being changed (3001-VOTE-030) - - for asset changes; **must** see the new value for the parameters being changed (3001-VOTE-031) - - for asset changes: **could** see if there are other open proposals for the same parameter(s) - - for asset changes: **should** see the current values for these parameters - - for freeform: **must** see a summary of the proposal (suggest the first x characters of the proposal blob) -- **must** see the proposal status e.g. passed, open, waiting for node to vote) (3001-VOTE-035) - - for new asset proposals: **must** see if an asset has not yet been whitelisted on the bridge (3001-VOTE-036) -- for open proposals: **must** see a summary of how the vote count stands and if it looks like proposal will pass or not (note some of these are repeated in more details in the [details section](#details-of-a-proposal)) (3001-VOTE-037) - - if the proposal failed (had the status of "failed", because it was an invalid on submission) they **should not** appear in the list (instead the proposer will see this after submission) - - if the proposal looks like it will fail due to insufficient participation: **should** see "participation not reached" - - else if: proposal looks like it might fail due to insufficient majority (and is not a market change proposal): **should** see "Majority not reached" - - else if (is a market change proposal) and is likely to pass because of liquidity providers vote: **should** see "set to pass by Liquidity provider vote" - - else if: proposal is likely to pass: **should** see "set to pass" - - **must** see when (date/time) voting closes on proposal (3001-VOTE-043) -- for (non-freefrom) proposals that have passed but not enacted: **must** see when they will enact (3001-VOTE-044) -- for (non-freefrom) proposals that have passed but not enacted: **should** see when (date/time) voting closed -- for (non-freeform) proposals that enacted: **must** see when they enacted (3001-VOTE-046) -- for freeform proposals that have passed: **must** see when they passed (3001-VOTE-047) -- for proposals that did not pass due to lack of participation: **must** see "Participation not reached" (3001-VOTE-048) -- for proposals that did not pass due to lack of majority: **must** see "Majority not reached" (3001-VOTE-049) -- for proposals that did not pass due to failure: **must** see "Failed" (3001-VOTE-050) -- for proposals that I ([connected Vega](./0002-WCON-connect_vega_wallet.md) key) have voted on: **should** see my vote (for or against) - -...so I can see select one to view and vote, or view outcome. - -## Details of a proposal - -When looking at a particular proposal, I... - -- see [the same details in the list of proposals](#list-of-proposals) and: -- **must** have option to see raw JSON of proposal (3001-VOTE-052) -- **should** display the proposed change details displayed in a human readable format (e.g. with market id, shown along with that market name) - -- **must** see the rationale title (3001-VOTE-054) -- **must** see the full rationale description if there is one (3001-VOTE-055) -- **must** see rationale description rendered with markdown (3001-VOTE-101) - -For open proposals: - -- **must** show a summary of vote status (base on the current total amount associated tokens, note this could change before the vote ends) (3001-VOTE-057) -- **must** see if the token vote has met a required participation threshold (3001-VOTE-058) -- **must** see the sum of tokens that have voted so far (3001-VOTE-059) -- **should** see sum of tokens that have voted as a percentage of total voted -- **should** see what the participation threshold is for this proposal (note this is set per proposal once the proposal hits the chain based on the current network params, incase a proposal is set to enact that changes threshold) -- **must** see if the Token vote has met the required majority threshold (3001-VOTE-062) -- **must** see the sum of tokens that have voted in favour of the proposal (3001-VOTE-064) -- **should** see sum of tokens that have votes in favour of proposal as percentage of total associated -- **should** see what the majority threshold is for this proposal (note this is see per proposal, incase a proposal is set to enact that changes threshold) - -For open market change proposals, all of the above and: - -- **must** show a summary of vote status (base on the current equality like share, note this could change before the vote ends) (3001-VOTE-067) -- **must** see if the equity like share vote has met the required participation threshold (3001-VOTE-068) -- **must** see the equity like share % that has voted so far (3001-VOTE-069) -- **should** see what the equity like share threshold is for this proposal (note this is see per proposal, incase a proposal is set to enact that changes threshold) -- **must** see if the equity like share vote has met the required majority threshold (3001-VOTE-071) -- **must** see the equity like share as percentage that has voted in favour of the proposal (3001-VOTE-072) -- **must** see what the majority threshold is for this proposal (note this is see per proposal, incase a proposal is set to enact that changes threshold) (3001-VOTE-073) - -For `closed` market change proposals, all of the above and: - -- **must** see all of above but values at time of vote close (3001-VOTE-074) - -... so I can see what I am voting for and the status of the vote. - -## Can vote on an open proposals - -When looking to vote on the proposal, I... - -- **must** see an option to [connect to a Vega wallet/key](./0002-WCON-connect_vega_wallet.md) (3001-VOTE-075) -- **must** be [connected to a Vega wallet/key](./0002-WCON-connect_vega_wallet.md) (3001-VOTE-076) - - **must** see sum of tokens I have [associated](1027-ASSO-associate.md) (3001-VOTE-100) - - **should** see what percentage of the total [associated](1027-ASSO-associate.md) tokens I hold - - **should**, if I have 0 tokens, see link to [associate](1027-ASSO-associate.md) - - **must** see my current vote for, against, or not voted (3001-VOTE-079) - - **must** see option to vote for or against (3001-VOTE-080) - - **must** see option to change my vote (vote again in same or different direction) (3001-VOTE-090) - -For open market change proposals, all of the above and: - - **must** see your equity like share on the market you are voting on (3001-VOTE-092) - -for both: - -- **must** see feedback of my vote [Vega transaction](0003-WTXN-submit_vega_transaction.md) (3001-VOTE-093) - -...so that I can cast my vote and see the impact it might have. - \ No newline at end of file diff --git a/user-interface/3002-PROP-propose.md b/user-interface/3002-PROP-propose.md deleted file mode 100644 index 249c1fa9f..000000000 --- a/user-interface/3002-PROP-propose.md +++ /dev/null @@ -1,63 +0,0 @@ -# Propose - -Background: [Governance spec](../protocol/0028-GOVE-governance.md) -and [docs](https://docs.vega.xyz/docs/mainnet/concepts/vega-protocol#governance). - -## Associate tokens - -When looking to propose something, I... - -- **must** see see a link to detailed explanation of Governance in the docs (3002-PROP-001) -- **must** see that the governance token is an ethereum ERC20 token and needs to attributed (or [associated](1004-ASSO-associate.md)) to a Vega wallet for use on Vega (3002-PROP-002) -- **must** see that I need some associated tokens, and a link to [associate](1004-ASSO-associate.md) (3002-PROP-003) - -... so I have a sufficient vote weight to propose. - -## Select proposal type - -When making a proposal, I... - -- **must** select a proposal type (3002-PROP-005) - -...so I get the appropriate form and information about rules for that type of proposal. e.g. min enactment and vote duration. - -## Populate a proposal form - -When making a proposal, I... - -- **must** input a rationale title and description (3002-PROP-006) -- **must** see the rules (min vote duration and enactment delay) for this proposal type (3002-PROP-008) -- **should** see the minimum required tokens or LP vote required to make a proposal Spam protection and network parameters -- if anything except market change: **must** be warned if the amount I have associated is less the the minimum required to propose for this proposal type (due to Spam protection or network parm, whichever is greater) (3002-PROP-009) -- if market change: **must** be warned if the amount of tokens I have less than the minimum tokens required to propose a change (due to Spam protection or network params) (3002-PROP-020) -- **should** see the balance of associated Governance tokens -- if market change: **must** be warned if the amount equity like share I have is less than the minimum required equity like share to propose a change (due to Spam protection or network params) (3002-PROP-022) -- **should** see my equity like share in that market - -### Detail on specific proposals - -Go to the following for detail on each proposal type: - -- [Propose new Market](./1006-PMARK-propose_new_market.md) -- [Propose change(s) to market](./1007-PMAC-propose_market_change.md) -- [Propose new asset](1008-PASN-propose_new_asset.md) -- [Propose change(s) to asset](1009-PASC-propose_asset_change.md) -- [Propose change to network parameter(s)](1010-PNEC-propose_network.md) -- [Propose something "Freeform"](1011-PFRO-propose_freeform.md) - -### Submit proposal - -- **must** submit the proposal [Vega transaction](0003-WTXN-submit_vega_transaction.md) (3002-PROP-011) -- **must** see the feedback on the [Vega transaction](0003-WTXN-submit_vega_transaction.md) (3002-PROP-012) -- If there is an error on the proposal: - - **must** be shown an error message will all of the error details from the API (3002-PROP-013) - - **must** see the proposal form populated with all the same values just submitted (3002-PROP-014) - - **should** see error messages highlighted on the inputs that require user attention -- If the proposal was successful: - - **must** be shown it was successful (3002-PROP-016) - - **should** be prompted to vote on the proposal - - **should** be prompted to share the proposal detail page to encourage others to vote - - **must** see a link to the proposal detail page (3002-PROP-019) - -...so that the proposal is listed on the chain and I and others can vote for or against it. - \ No newline at end of file diff --git a/user-interface/3003-PMAN-propose_new_market.md b/user-interface/3003-PMAN-propose_new_market.md deleted file mode 100644 index 37b0d5c78..000000000 --- a/user-interface/3003-PMAN-propose_new_market.md +++ /dev/null @@ -1,8 +0,0 @@ -# Propose new Market - -- **must** input the new market definition (3003-PMAN-001) - -## Submit proposal - -back to [Propose](./3002-PROP-propose.md) for details on proposing - \ No newline at end of file diff --git a/user-interface/3004-PMAC-propose_market_change.md b/user-interface/3004-PMAC-propose_market_change.md deleted file mode 100644 index 0cf8144bc..000000000 --- a/user-interface/3004-PMAC-propose_market_change.md +++ /dev/null @@ -1,13 +0,0 @@ -## Propose market change - -- select a market to change - - **must** by market ID (3004-PMAC-001) - - **should** by searching for market name - - **should** by searching for market code -- **must** link to existing details on block explorer (3004-PMAC-004) -- **should** see any open or to be enacted changes on same market - -## Submit proposal - -back to [Propose](./3002-PROP-propose.md) for details on proposing - \ No newline at end of file diff --git a/user-interface/3005-PASN-propose_new_asset.md b/user-interface/3005-PASN-propose_new_asset.md deleted file mode 100644 index b532acc27..000000000 --- a/user-interface/3005-PASN-propose_new_asset.md +++ /dev/null @@ -1,8 +0,0 @@ -# Propose new Asset - -- **must** input the new asset definition (3005-PASN-001) - -## Submit proposal - -back to [Propose](./3002-PROP-propose.md) for details on proposing - \ No newline at end of file diff --git a/user-interface/3006-PASC-propose_asset_change.md b/user-interface/3006-PASC-propose_asset_change.md deleted file mode 100644 index 884bfacf7..000000000 --- a/user-interface/3006-PASC-propose_asset_change.md +++ /dev/null @@ -1,13 +0,0 @@ -## Propose asset change - -- select a asset to change - - **must** by market ID (3006-PASC-001) - - **should** by searching for asset name - - **should** by searching for asset symbol -- **must** see link to existing details on block explorer (3006-PASC-004) -- **should** see any open or to be enacted changes on this asset - -## Submit proposal - -back to [Propose](./3002-PROP-propose.md) for details on proposing - \ No newline at end of file diff --git a/user-interface/3007-PNEC-propose_network.md b/user-interface/3007-PNEC-propose_network.md deleted file mode 100644 index f6548c45b..000000000 --- a/user-interface/3007-PNEC-propose_network.md +++ /dev/null @@ -1,14 +0,0 @@ -# Propose change to network parameter(s) - -When proposing a change to network parameter, I... - -- **should** see any other "open or passed but not enacted" proposals to the same parameter -- **must** input the parameter I want to change (3007-PNEC-002) -- **must** input the proposed value (3007-PNEC-003) - -- **should** see the the current value - -## Submit proposal - -back to [Propose](./3002-PROP-propose.md) for details on proposing - \ No newline at end of file diff --git a/user-interface/3008-PFRO-propose_freeform.md b/user-interface/3008-PFRO-propose_freeform.md deleted file mode 100644 index 6d897b5bc..000000000 --- a/user-interface/3008-PFRO-propose_freeform.md +++ /dev/null @@ -1,8 +0,0 @@ -# Propose freeform - -- **must** not see anything felids enactment (because freeform do not enact) (3008-PFRO-001) - -## Submit proposal - -back to [Propose](./3002-PROP-propose.md) for details on proposing - \ No newline at end of file diff --git a/user-interface/4001-TRES-view_treasury_rewards.md b/user-interface/4001-TRES-view_treasury_rewards.md deleted file mode 100644 index 3a567de14..000000000 --- a/user-interface/4001-TRES-view_treasury_rewards.md +++ /dev/null @@ -1 +0,0 @@ -# View treasury rewards \ No newline at end of file diff --git a/user-interface/5001-LIQF-liquidity_opportunities.md b/user-interface/5001-LIQF-liquidity_opportunities.md deleted file mode 100644 index 0273bd132..000000000 --- a/user-interface/5001-LIQF-liquidity_opportunities.md +++ /dev/null @@ -1 +0,0 @@ -# Find liquidity provision opportunities \ No newline at end of file diff --git a/user-interface/5002-LIQP-provide_liquidity.md b/user-interface/5002-LIQP-provide_liquidity.md deleted file mode 100644 index b802fd92f..000000000 --- a/user-interface/5002-LIQP-provide_liquidity.md +++ /dev/null @@ -1 +0,0 @@ -# Provide liquidity \ No newline at end of file diff --git a/user-interface/5003-LIQI-liquidity_income.md b/user-interface/5003-LIQI-liquidity_income.md deleted file mode 100644 index 0d797b1e5..000000000 --- a/user-interface/5003-LIQI-liquidity_income.md +++ /dev/null @@ -1 +0,0 @@ -# Review liquidity income \ No newline at end of file diff --git a/user-interface/6001-MARK-find_markets.md b/user-interface/6001-MARK-find_markets.md deleted file mode 100644 index ace1dc823..000000000 --- a/user-interface/6001-MARK-find_markets.md +++ /dev/null @@ -1,40 +0,0 @@ -# Find markets - -## Closed Markets - -- **Must** see market's instrument code (6001-MARK-001) -- **Must** see market's instrument name (sometimes labelled 'description') (6001-MARK-002) -- **Must** see status (6001-MARK-003) -- **Must** see the settlement date (6001-MARK-004) - - **Must** use `marketTimestamps.closed` field if market is indeed closed (6001-MARK-005) - - **Must** fallback to using the `settlement-expiry-date:` if market is not fully settled but trading is terminated (6001-MARK-006) - - **Must** indicate if the date shown is 'expected' (metadata value) or if it is the true closed datetime (`marketTimestamps.closed`) (6001-MARK-007) - - **Must** show the date formatted for the user's locale (6001-MARK-008) - - **Must** link to the trading termination oracle spec (6001-MARK-009) - - **Could** show the settlement date as words relative to now (E.G. '2 days ago') (6001-MARK-010) -- **Must** show the last best bid price (6001-MARK-011) -- **Must** show the last best offer price (6001-MARK-012) -- **Must** show the final mark price (6001-MARK-013) -- **Must** show the settlement price (6001-MARK-014) - - **Must** link to the settlement data oracle spec (6001-MARK-015) - - **Must** retrieve settlement data from corresponding oracle spec (6001-MARK-016) -- **Could** show current connected user's PNL for that market (6001-MARK-017) -- **Must** show the settlement asset (6001-MARK-018) - - **Must** be able to view full asset details (6001-MARK-019) -- **Must** provide a way to copy the market ID (6001-MARK-020) - -## Market Selector - -- **Must** see market's instrument code (6001-MARK-021) -- **Must** see market's instrument name (sometimes labelled 'description') (6001-MARK-022) -- **Must** see 24hr price change (6001-MARK-023) -- **Must** see current price (6001-MARK-024) -- **Must** price movements over last 24hr (sparkline) (6001-MARK-025) -- **Must** be linked to all markets page (6001-MARK-026) -- **Must** be able to filter by product type (6001-MARK-027) -- **Must** be able to filter by settlement asset (6001-MARK-028) -- **Must** be able to search by instrument code and instrument name (6001-MARK-029) -- **Must** be able to sort - - by top gaining market (6001-MARK-030) - - by top losing market (6001-MARK-031) - - by newest markets (opening timestamp) (6001-MARK-032) diff --git a/user-interface/6002-MDET-market-details.md b/user-interface/6002-MDET-market-details.md deleted file mode 100644 index 7dc5614fa..000000000 --- a/user-interface/6002-MDET-market-details.md +++ /dev/null @@ -1 +0,0 @@ -# Market details \ No newline at end of file diff --git a/user-interface/6003-ORDB-order_book.md b/user-interface/6003-ORDB-order_book.md deleted file mode 100644 index 411962b16..000000000 --- a/user-interface/6003-ORDB-order_book.md +++ /dev/null @@ -1 +0,0 @@ -# Order book \ No newline at end of file diff --git a/user-interface/6004-PHIS-price_history.md b/user-interface/6004-PHIS-price_history.md deleted file mode 100644 index 9ee7f2edf..000000000 --- a/user-interface/6004-PHIS-price_history.md +++ /dev/null @@ -1 +0,0 @@ -# Price history \ No newline at end of file diff --git a/user-interface/6005-THIS-trade_history.md b/user-interface/6005-THIS-trade_history.md deleted file mode 100644 index f967cb4b5..000000000 --- a/user-interface/6005-THIS-trade_history.md +++ /dev/null @@ -1 +0,0 @@ -# Trade history \ No newline at end of file diff --git a/user-interface/6501-ASSE-assets.md b/user-interface/6501-ASSE-assets.md deleted file mode 100644 index 0f068bedd..000000000 --- a/user-interface/6501-ASSE-assets.md +++ /dev/null @@ -1,21 +0,0 @@ -# Assets - -## Asset detail dialog - -- **Must** see asset ID (6501-ASSE-001) -- **Must** see asset type (only ERC20 for now) (6501-ASSE-002) -- **Must** see full asset name (6501-ASSE-003) -- **Must** see asset symbol (6501-ASSE-004) -- **Must** see asset decimals (6501-ASSE-005) -- **Must** see asset quantum value (6501-ASSE-006) -- **Must** see asset status (Proposed, Rejected, Pending listing, Enabled) (6501-ASSE-007) -- **Must** see withdrawal threshold (6501-ASSE-008) -- **Must** see lifetime withdrawal limit (6501-ASSE-009) -- **Must** see infrastructure fee account balance (6501-ASSE-010) -- **Must** see global reward pool account balance (6501-ASSE-011) -- **Must** be able to close the dialog (6501-ASSE-012) - -### Asset types - -- ERC20 - - **Must** see contract address (6501-ASSE-013) diff --git a/user-interface/7001-COLL-collateral.md b/user-interface/7001-COLL-collateral.md deleted file mode 100644 index d2c688b43..000000000 --- a/user-interface/7001-COLL-collateral.md +++ /dev/null @@ -1,28 +0,0 @@ -# Collateral - -## Collateral Data Grid - -- **Must** be shown grouped by [asset](9001-DATA-data_display.md#asset-balances) (7001-COLL-001) -- For each asset: - - **Must** show used [amount](9001-DATA-data_display.md#asset-balances), which is the total of all Margin and Liquidity bond accounts (7001-COLL-002) - - **Must** show available [amount](9001-DATA-data_display.md#asset-balances), which is the total of your General account (7001-COLL-003) - - **Must** show total [amount](9001-DATA-data_display.md#asset-balances), which is the sum of your General account and all Margin accounts (7001-COLL-004) - - **Must** provide a method for depositing asset (7001-COLL-005) - - **Must** provide a method for withdrawing asset (7001-COLL-006) - - **Must** show the asset symbol (7001-COLL-007) - - **Must** provide a way to see the [full asset details](6501-ASSE-assets.md) (7001-COLL-008) - - **Must** provide a way to see all accounts, their type, and their balance for a single asset (7001-COLL-009) - - **Could** have default sort order (7001-COLL-010) - - General - - Margin - - Bond - - Fees - Maker - - Fees - Liquidity - - Rewards - Maker Paid - - Rewards - Maker Received - - Rewards - Liquidity Provision Received Fees - - Rewards - Market Proposers - -## Deal Ticket - -- **Must** see your current total margin (General balance + Margin balance - Maintenance level) available (7001-COLL-011) diff --git a/user-interface/7002-SORD-submit_orders.md b/user-interface/7002-SORD-submit_orders.md deleted file mode 100644 index 9f3b05214..000000000 --- a/user-interface/7002-SORD-submit_orders.md +++ /dev/null @@ -1,201 +0,0 @@ -# Submit order -As a user I want change my exposure on a market (e.g. open a position, increase or decrease my open volume), I want to submit an order with instructions for how my order should be executed so I have some control over the price that I get, as well as if when/my order should stay on the book. See [specs about orders](../protocol#orders) for more info. - -## Before seeing a "deal ticket" - -When looking at a market, I... - -- **must** see/select the [Market](./7001-DATA-data_display.md#market) I am submitting the order for (7002-SORD-001) -- **must** see the current `status` of the market (7002-SORD-061) - - if the market is in a state of `rejected`, `canceled` or `closed`: - - - **must** see that the market is not accepting orders and never will be (7002-SORD-062) - - if the market is in a state of `tradingTerminated`: - - - **must** see that the market is not accepting orders and never will be (7002-SORD-063) - - **should** see the [price](7001-DATA-data_display.md#quote-price) that was used to settle the market - - **should** see a link to oracle spec and data - - if the market is in a state of `settled`: - - - **must** see that the market is not accepting orders and never will be (7002-SORD-066) - - **should** see the oracle events that terminated the market - - **should** see a link to oracle spec and data - - if the market is in a state of `suspended`: - - - **should** see what suspended the market - - **should** see the conditioned required for the auction to end - - **should** see the current data values that the auction end is measured against (e.g. Supplied stake) - -...so I know if the market is accepting orders. - -The rest of this document only applies if the state of the market is `pending`, `active` or `suspended`: - -## Deal ticket - -When populating a deal ticket I... - -- **must** see the current market trading mode (Continuous, Auction etc) (7002-SORD-002) - -- If I have a 0 total balance of the settlement asset: **must** be warned that I have insufficient collateral (but also allow you to populate ticket because I might want to try before I deposit) (7002-SORD-003) - - **should** have a way to easily deposit the required collateral - -- **must** select a side/direction e.g. long/short (note: some implementations may do this with two different submit buttons long/short rather than a toggle) (7002-SORD-004) - -- **must** be able to select the [order type](../protocol/0014-ORDT-order_types.md) that I wish to submit (7002-SORD-005) - - **must** see limit order (7002-SORD-006) - - **must** see market order (7002-SORD-007) - - **should** see pegged order - - **should** see liquidity provision - -## Order size - -...need to select a size, when selecting a size for my order, I... - -- **must** input an order [size](7001-DATA-data_display.md#size) (aka amount or contracts) (7002-SORD-010) - - **should** have the previous value for the selected market available e.g. pre-populated (last submitted or last changed) - - **should** be able to quickly change the size by the market's min-contract size e.g. hit up/down on the keyboard to increase - - **should** be able to use modifier keys (SHIFT, ALT etc) to increase/decrease in larger increments with arrows - - **would** like to be able to enter a number followed be "k" or "m" or "e2" etc. to make it thousands or millions or hundreds, etc. -- **must** be warned (pre-submit) if input has too many digits after the decimal place for the market's ["position" decimal places](7001-DATA-data_display.md#size) (7002-SORD-016) - -... so I get the size of exposure (open volume) that I want - -## Price - Limit order - -... if wanting to place a limit on the price that I trade at, I... - -- **must** enter a [price](7001-DATA-data_display.md#quote-price). (7002-SORD-017) -- **must** see the price unit (as defined in market) (7002-SORD-018) - - **should** be able quickly pre-populate the price with the current mark price (if there is one, 0 if not) e.g. by focusing the input and hitting up/down - - **should** have the previous value for the selected market pre-populated (last submitted or last changed) - - **should** be able to hit up/down on the keyboard to increase the price by the market's tick size (if set, or smallest increment) - - **should** be able to use modifier keys (SHIFT, ALT etc) to increase/decrease in larger increments with arrows - - **would** like to be able to enter a number followed be "k" or "m" or "e2" etc. to make it thousands or millions or hundreds, etc. -- **must** be warned (pre-submit) if the input price has too many digits after the decimal place for the market ["quote"](7001-DATA-data_display.md#quote-price) (7002-SORD-059) - -... so that my order only trades at up/down to a particular price - -## Market order - -... if wanting to trade regardless of price (or assuming that the market is liquid enough that the current best prices are enough of an indication of the price I'll get)... - -- **must not** see a price input (7002-SORD-019) -- **should** be warning if the market is in auction and the market order may be rejected - -... so I can quickly submit an order without populating the ticket with elements I don't care about - -## Pegged - -... submit an order where the price is offset from a price in system (best bid etc) - -- TODO - -... so my order will move with the market - -## Time in force - -... should to select a time in force, when selecting a time in force, I... - -- **must** select a time in force - - Good till canceled `GTC` - not applicable to Market orders (7002-SORD-023) - - Good till time `GTT` - not applicable to Market orders (7002-SORD-024) - - Fill or kill `FOK` (7002-SORD-025) - - Immediate or cancel `IOC` (7002-SORD-026) - - Good for normal trading only `GFN` - not applicable to Market orders (7002-SORD-027) - - Good for auction only `GFA` - not applicable to Market orders (7002-SORD-028) -- **should** only be warned if the time in force is not applicable to the order type I have selected -- **should** only be warned if the time in force is not applicable to current period's trading mode -- if the user has not set a preference: market orders **must** default to `IOC` (7002-SORD-030) -- if the user has not set a preference: limit orders **must** default to `GTC` (7002-SORD-031) - -... so I can control if and how my order stays on the order book - -## Execution flags - -... could select some execution flags. When selecting execution flags (aka order conditions)... - -- **must** see an option to select "Post only" (7003-SORD-054) - - **should** see explanation of what Post only is/does - - **must** see the post only option is unselected and disabled (can not be checked) if the time in force is set to IOC or FOK (7003-SORD-055) - - **must** see an explanation of why the option is disabled (7003-SORD-056) - -- **must** see an option to select "Reduce only" (7003-SORD-057) - - **should** see explanation of what Reduce only is/does (7003-SORD-058) - -- **must** see that selecting "Post only" or "reduce only" de-select the other (if selected). As is it not possibly to apply them both to an order (7003-SORD-059) - -... so I can control in more detail how my order is executed - -## Auto Populating a deal ticket non-manual methods - -- TODO Populate by selecting a size/price in the order book -- TODO Populate by selecting a size/price in the chart -- TODO Populate by selecting a size/price in the depth chart -- TODO Input price as a % of account, given the current price field -- **should** be able to determine how much leverage I'd like (given general balance, and other inputs) - -## See the potential consequences of an order before it is submit -... based on the current inputs I'd like an indication of the consequences of my order based on my position and the state of the market, I... - -- **could** see my resulting open volume -- **could** see the amount this order might move the market in percentage terms -- **could** see what the new best prices of the market would be after placing this order (assuming my order moves the market) -- **could** see new volume weighted average entry price if not 0 -- **could** see and indication the volume weighted price that this particular order -- **could** see an indication of how much of the order will trade when it hits the book and how much might remain passive -- **could** see a new liquidation level -- **could** see an estimate of the fees that will be paid (if any) -- **could** see my "position leverage" TODO - define this -- **could** see my "account leverage" TODO - define this -- **could** see an amount of realized Profit / Loss -- **could** see any change in margin requirements (if more or less margin will be required) -- **could** see the notional value of my order - -... so that I can adjust my inputs before submitting - -## Submit an order - -... need to submit my order, when submitting my order, I... - -- if not already connected: **must** see a prompt to [connect a Vega wallet](0002-WCON-connect_vega_wallet.md) - -- **must** submit the [Vega submit order transaction](0013-WTXN-submit_vega_transaction.md). (7002-SORD-039) - -- **must** see feedback on my order [status](https://docs.vega.xyz/docs/mainnet/grpc/vega/vega.proto#orderstatus) (not just transaction status above) (7002-SORD-040) - - Active (aka Open) (7002-SORD-041) - - Expired (7002-SORD-042) - - Cancelled. see the txn that cancelled it and a link to the block explorer, if cancelled by a user transaction. (7002-SORD-043) - - Stopped. see an explanation of why stopped (7002-SORD-044) - - Partially filled. **must** see how much of the [size](7001-DATA-data_display.md#size) if filled/remaining (7002-SORD-045) - - Filled. Must be able to see/link to all trades that were created from this order. (7002-SORD-046) - - Rejected: **must** see the reason it was rejected (7002-SORD-047) - - Parked: **must** see an explanation of why parked orders happen (7002-SORD-048) -- All feedback must be a subscription so is updated as the status changes (7002-SORD-053) - - **could** repeat the values that were submitted (order type + all fields) - -... so that I am aware of the status of my order before seeing it in the [orders table](6002-MORD-manage_orders.md). - -... so I get the sort of order, and price, I wish. - -## Manage positions and order -After submitting orders I'll want to [manage orders](7003-MORD-manage_orders.md). If my orders resulted in a position I may wish to [manage positions](7004-POSI-positions.md)). - -_____ - -# Typical order scenarios to design/test for - -Market in continuous trading: -- Limit order, Long, GTC, with a price that is lower than the current price -- Limit order, Short, GFN, that crosses the book but only gets a partial fill when order is processed -- Market order, IOC, that increases open volume (aka size of position) -- a limit order GFA when market is in Auction -- an limit that reduces exposure from something to 0 -- a limit order, FOK, that squares and reverses e.g. I'm long 10, I short 20 to end short 10 - -Market in auction: -- Attempt Market order in Auction mode: should warn order is invalid -- Attempt limit order GFN when market is normally Continuous (but currently in auction), should warn that GFN will not work diff --git a/user-interface/7003-MORD-manage_orders.md b/user-interface/7003-MORD-manage_orders.md deleted file mode 100644 index 7540dfee0..000000000 --- a/user-interface/7003-MORD-manage_orders.md +++ /dev/null @@ -1,182 +0,0 @@ -# Manage orders - -Users place orders to describe the trades they would like to make: buy or sell, at what price, how long it is valid for etc. In many cases they can [amend](#amend-order---price) or [cancel](#cancel-orders) these orders while they are still active, for example: changing price. - -Once a user has placed an order they may wish to confirm it's [status](https://docs.vega.xyz/docs/mainnet/graphql/enums/order-status) in a [list](#orders-list) of other orders. e.g. whether it has been accepted, filled, how close it is to being filled etc. Users may be interested in the price of their orders relative to the price of the market and how much of the order's size has been filled. - -Orders can also be placed on behalf of a user/party via [pegged](#pegged-orders) orders. - -Markets also have [statuses](https://docs.vega.xyz/docs/mainnet/graphql/enums/market-state) that may affect how a user perceives the state of an order, e.g if the order was placed while in "normal" continuous trading, but the market is now in auction. - -## Orders list - -User will have differing needs/preferences in terms of what they want to see about an order and how orders are grouped and listed. It is common for interfaces to allow users to customize how orders are displayed. - -### Field customization - -- **should** have the ability to select what [fields/data](#fields) are shown for each order in the list -- **should** have the ability to change the order of fields (e.g. table columns) -- **should** have the ability to give each column in the list more or less space - -### Fields - -When looking at a list of orders, I... - -- **must** see [status](https://docs.vega.xyz/docs/mainnet/graphql/enums/order-status) of the order (7003-MORD-001), and therefore (nested bullets added for context, ACs are on fields that follow)... - - `Active​` - - How much of the order is filled / remains unfilled - - How close the mark price is to order - - If this order was filled at the limit price what would what effect would it have on realized PnL - - I may want to amend or cancel this order - - `Expired​` - - When did it expire - - How much was filled / remaining - - `Cancelled​` - - What canceled it? When did I cancel it TODO double check that "cancelled" only comes from user action - - `Stopped​` - - What stopped it (e.g. was it because an [FOC](9001-DATA-data_display.md#time-in-force) that was not filled, or because of margin availability) - - `Filled​` - - What was the average fill price I got for this order - - `Rejected​` - - Why was this order rejected (show `rejectedReason`) - - `PartiallyFilled​` - - How much was filled before the order was canceled - - What was the average fill price I got for this order - - `Parked​` - - Why is the market currently in auction - - Link to pegged shape (see below) - -- **must** see any [reason (mainnet docs)](https://docs.vega.xyz/mainnet/api/graphql/enums/order-rejection-reason) that has been supplied by the API along with the order status e.g. "Rejected: Due to insufficient margin", "Stopped: Reduce only, would open new volume" (7003-MORD-018) - -- **must** see what [market](9001-DATA-data_display.md#market) an order is related to (either code, ID or name, preferable name) (7003-MORD-002) - - **should** see what the `status` is of the market (particularly if it is not "normal") -- **must** see the [size](9001-DATA-data_display.md#size) of the order (7003-MORD-003) -- **must** see the [direction/side](9001-DATA-data_display.md#direction--side) (Long or Short) of the order (this can be implied with a + or negative suffix on the size, + for Long, - for short) (7003-MORD-004) -- **must** see [order type](9001-DATA-data_display.md#order-type) (7003-MORD-005) -- if order created by [a pegged order](9001-DATA-data_display.md#order-origin): **should** see order origin - - **could** see it's offset+reference. See [pegged orders](#pegged-order-shapes), - -- **should** see how much of the order's [size](9001-DATA-data_display.md#size) has been filled e.g. if the order was for `50` but so far only 10 have traded I should see Filled = `10`. Note: this is marked as a should because in the case of Rejected order and some other scenarios it isn't relevant. -- **should** see how much of the order's [size](9001-DATA-data_display.md#size) remains. - -- if order type = `Limit`: **must** see the Limit [price](9001-DATA-data_display.md#quote-price) that was set on the order -- if order type = `Market`: **must** not see a price for active or parked orders, a `-`, `Market` or `n/a` is more appropriate (API may return `0`). - -- **must** see the [time in force](9001-DATA-data_display.md#time-in-force) applied to the order (can be abbreviated here) (7003-MORD-006) -- **must** see if any execution flags (aka conditions. e.g. Post only, Reduce only) were applied to the order (7003-MORD-019) -- **should** see "created at" [time](9001-DATA-data_display.md#time) -- **could** see updated at (this is used by the system when an order is amended, or repriced (in pegged and LP) not sure this in needed) - -- **should** see time priority (how many orders are before mine at this price) - -- if the order is `Active` & **not** a pegged order: **must** see an option to [amend](#amend-order---price) the individual order (7003-MORD-007) -- if the order is `Active` & is a pegged order: **must** **not** see an option to amend the resulting active order at the current price (7003-MORD-008) - - **could** see a link to amend the pegged order itself -- if the order is `Active` & **not** a pegged order: **must** see an option to [cancel](#cancel-orders) the individual order -- if the order is `Active` & is a pegged order **must** **not** see an option to cancel the individual order - - **could** see a link to cancel the pegged order - -... so I can understand the state of my orders and decide what to do next -### Filters - -When looking at a list of orders, I... - -- **should** have the ability to see all orders regardless of status in one list -- **should** have the ability to see only active & parked orders -- **should** have the ability to see only non-active & parked order (i.e. all orders that do not have the status of Active & Parked) -- **could** have the ability to filter by any field(s) - - where a field is an enum: **should** be able to select one on or more values for a field that should be included - -... so I can focus on the type of orders statuses etc that I want to at that time - -### Sorting - -When looking at a list of orders, I... - -- **should** be able to sort the list (both directions) by any field in the order list - - **should** be able to add a secondary sort. e.g. by market then by date -- **should** have the default sorted by created time (or updated time if newer), with newest at the top -- **should** retain sorting preferences between switching views / browser reload - -... so the sort order matches my mental model and or makes it easy for me to find the orders I am looking for -### Grouping - -When looking at a list of orders, I... - -- **should** be able to group orders by any field e.g. by market, lp etc -- **should** have default grouping by market - -... so I can make decisions easily on a set of orders -## Cancel orders - -When looking to take order out of the book, I... - -- **must** select whether to cancel an individual order or all orders on a market (7003-MORD-009) -- **could** be able to cancel all orders for markets in a given settlement asset -- **would** like to cancel all orders for all markets -- **must** be able to submit the [Vega transaction](0003-WTXN-submit_vega_transaction.md) to cancel order(s) (7003-MORD-010) - - **could** show the margin requirement reduction/increase that will take place before submitting -- **must** see feedback on order status after the [Vega transaction](0003-WTXN-submit_vega_transaction.md) (7003-MORD-011) - - -... so that the order will not be filled and I don't end up with a change in my position that I was not expecting -## Amend order - price - -Read more about [order amends](../protocol/0004-AMND-amends.md). - -When looking to amend an order, I... - -- **must** be able to amend the price of an order (7003-MORD-012) - - **could** be warned if the price change will, given the current market, fill the order right away - - **must** be warned (pre-submit) if the input price has too many digits after the decimal place for the market ["quote"](DATA-data_display.md#quote-price) (7003-MORD-013) -- **must** submit the Amend order [Vega transaction](0003-WTXN-submit_vega_transaction.md) (7003-MORD-014) -- **must** see the status after the transaction (see [submit order](7002-SORD-submit_orders.md#submit-an-order)) (7003-MORD-015) - -... so the order is more likely to get filled or will be filled at a more competitive price - -## Amend order - other than price - -`TODO` - Acceptance criteria for other types of order amend - -## On a price history chart - -when looking at a price history chart, I... - -- **would** like to see all my active orders shown on the vertical axis -- **would** like to drag orders to change their price - -... so I can see my orders in context of price history -## On a depth chart - -when looking at a depth chart, I... - -- **would** like to see all my active orders shown on the horizontal axis -- **would** like to drag orders to change their price - -... so I can see my orders in context of price history - -## In order book - -when looking at an order book, I... - -- **would** like to see all my active orders shown next to the prices they have - -... so I can see my orders in context of price history - -## Pegged orders - -When looking to understand the state of a pegged order... - -- **must** see the reference, offset and direction for each part pegged order (7003-MORD-016) -- **should** see the current price for each buy/sell -- **should** see the filled/remaining for each part of the order -- when order is not `Active`: **should** show the order status (perhaps instead of price) -- **should** be able to cancel the pegged order -- **would** like to see link to edit the shape of a pegged order -- **would** like to see the date submitted/updated - -... so I can decide if I wish to amend or cancel my pegged order - -## Cancel Pegged order - -`TODO` diff --git a/user-interface/7004-POSI-positions.md b/user-interface/7004-POSI-positions.md deleted file mode 100644 index beaed90c1..000000000 --- a/user-interface/7004-POSI-positions.md +++ /dev/null @@ -1 +0,0 @@ -# View my Position(s) \ No newline at end of file diff --git a/user-interface/7005-FILL-fills.md b/user-interface/7005-FILL-fills.md deleted file mode 100644 index bfdc7768a..000000000 --- a/user-interface/7005-FILL-fills.md +++ /dev/null @@ -1,19 +0,0 @@ -# Fills - -## Fills Data Grid - -- **Must** see the [market](9001-DATA-data_display.md#market) the fill occurred in (7005-FILL-001) -- **Must** see the [size](9001-DATA-data_display.md#size) of the fill (7005-FILL-002) - - **Must** see indication if the current party was the buyer (7005-FILL-003) - - **Must** see indication if the current party was the seller (7005-FILL-004) -- **Must** see the [price](9001-DATA-data_display.md#quote-price) of the fill (7005-FILL-005) -- **Could** see the notional value of the fill (7005-FILL-006) -- **Must** see the [fee](9001-DATA-data_display.md#asset-balances) that applies for current party for the fill (7005-FILL-007) - -### Continuous Trading - -- **Must** see the role of the user (taker, maker or n/a) (7005-FILL-008) - -### Auction - -TBD. Currently any trade made during auction will result in the both parties having the role of 'taker'. This may be incorrect and is being investigated. diff --git a/user-interface/7006-FEES-fees.md b/user-interface/7006-FEES-fees.md deleted file mode 100644 index 569b4e81d..000000000 --- a/user-interface/7006-FEES-fees.md +++ /dev/null @@ -1 +0,0 @@ -# My Trading fees \ No newline at end of file diff --git a/user-interface/8001-BLOX-transaction_and_blocks.md b/user-interface/8001-BLOX-transaction_and_blocks.md deleted file mode 100644 index 2ab883af0..000000000 --- a/user-interface/8001-BLOX-transaction_and_blocks.md +++ /dev/null @@ -1 +0,0 @@ -# Transaction and block content \ No newline at end of file diff --git a/user-interface/9001-DATA-data_display.md b/user-interface/9001-DATA-data_display.md deleted file mode 100644 index 49721b7f3..000000000 --- a/user-interface/9001-DATA-data_display.md +++ /dev/null @@ -1,65 +0,0 @@ -# Data display - -This is a definition of some common data types and the rules about the displaying them. These are referenced in other acceptance criteria to avoid repetition. - -## Size - ->aka contracts, volume, amount. - -This is set per-market and represent the number of contracts that are being brought or sold. - -`Market.positionDecimalPlaces` tells us where to put the decimal when displaying the number. Size can be a whole number if `Market.positionDecimalPlaces` = 0, or a [fractional order](../protocol/0052-FPOS-fractional_orders_positions.md) if > 0. -It **should** always be displayed to the full number of decimal places. however, there may be exceptions, e.g. when visualizing on a depth chart, where the precision is not required. - -## Quote price - -> aka. price, quote, level. - -This is set per-market and represent the "price" of an asset. It can have a 1-1 relationship with the settlement asset but it is also possible that products will have different payoff methods, which is one of the reasons we don't just use settlement asset, another being in the future some markets could have multiple settlement assets, another being that we don't want 18DP quotes. - -`Market.decimalPlaces` tells us where to put the decimal when displaying the number. It can be a whole number if `Market.decimalPlaces` = 0, but will not have more decimal places than the [settlement asset](#asset-balances) of a market. - -`Market...quoteName` is used to tell us what to display next to the quote price. For example the `quoteName` could be `USD` but the settlement asset = `DAI`. The Market framework allows for other types of quote (e.g. %, cm and ETC). When looking at a single market it may not be necessary to show the quote name each time you show the price. - - -## Asset balances - -> aka Collateral, account balance, Profit and loss, PnL fees, transfers. - -The is set per Asset and represents the amount of an asset that is held in the bridge. - -Once deposited assets appear in a `general account`. Other account types are created when opening positions, providing liquidity etc. -Vega does not return a `total balance` that is a sum of all accounts in a currency, but users will expect to see one. See the [Collateral spec](../protocol/0005-COLL-collateral.md) for other account types. - -`Asset.decimals` tells the UIs where to put the decimal place. Ethereum assets often have 18 decimal places, but can have less. Forms where you deposit, withdraw or transfer assets must show all decimal places. It may be appropriate to truncate at a certain number of DP in many cases (e.g. `0.01` instead of `0.012345678912345678` event though `0.001 wBTC` may be worth as much as than `0.01 ETH`). At the moment Vega does not have a source of information that allows conversion of currencies or way of knowing that the significant value of an asset is. - -## Market - -Markets do not have names, technically it is the instrument within a market that has the name. Theoretically the same instrument can be traded in multiple markets. if/when this happens a user needs to be able to disambiguate between markets. Each market does have a unique ID, Note: this is a hash of the definition of the market when it was created. -Instruments have both a Name and Code, see [market framework](../protocol/0001-MKTF-market_framework.md) for how these are used. Generally the Code can save space once a user is familiar with the market. The Name is more descriptive and should be the default when discovering markets. It remains to be seen how the community will use these exactly. -Markets can have several statuses and it may be sensible when listing markets to highlight their status. e.g. if a market is usually in continuous trading mode, but is currently in an auction due to low liquidity. The market name field could be augmented to show the status (add an icon etc). - -## Public keys - -> aka Party - -When looking at a public key it is important that the user can get the full public key but it is often appropriate just to show an abbreviated form. The first 6 and last 6 characters are preferable, with an indication that it is truncated e.g. `56d1e6739deac3c5c1ddc6fee876b3217e504a161b5b00fda96b40ed3e8f89b8` as `56d1e6...8f89b8` or just `8f89b8` if enough of a convention has been established. In cases where the key being shows comes from your connected wallet it should also show the name (aka alias) of the key. -Vega public keys are hexadecimal, but the convention is to display them without the preceding `0x` as this is what the Vega API returns. - -## Transaction hash - -> aka Transaction ID, txn, tx - -The transaction [hash](https://www.investopedia.com/terms/h/hash.asp) acts as an identifier for a transaction network. It is hexadecimal and should be displayed with the preceding `0x`. - -## Asset - -> aka Collateral - -### Asset name - -e.g. United states Dollar. Each asset has a name this should be shown (as well as symbol) in places where the user may need to distinguish one asset from another or if the symbol is ambiguous. Vega assets names aught to match their name on their native chain. - -### Asset symbol - -e.g USD. Symbols are short codes for an asset to be used in places low on space where the user is likely to be familiar with the asset. Often all caps but not always, so it is important to display upper and lower case. Vega assets codes aught to match their name on their native chain. \ No newline at end of file diff --git a/user-interface/README.md b/user-interface/README.md deleted file mode 100644 index 028962890..000000000 --- a/user-interface/README.md +++ /dev/null @@ -1,88 +0,0 @@ -# User interface acceptance criteria - -This folder contains descriptions of things that users do when interacting with Vega. The information they need and why they are doing them. These can be referenced in testing and used as input for building new interfaces. - -The acceptance criteria are organized into files, with each file representing a high level user task. These have been listed with the most "upstream" being first, and grouped into similar tasks. - -Each file contains blocks that relate to a low level user task. The block states what the user is trying to do or the context they are in, has a bullet for each thing they need, then states why they are doing it... - -> When doing a thing, I... -> - **must** be able to see some particular number [0000-CODE-000] -> ...so I can decide if I want to continue. - -Each bullet is worded so that it contains a **must**, **should**, **could**, or **would like to**. This gives app developers some indication of the priority of user needs. At the end of each bullet is a code that can be referenced in tests etc. - -These acceptance criteria are not final or intended to be "the truth" but a useful tool, they will be improved over time as more people feedback on using Vega. - -A user is normally interacting with at least 2 applications when doing tasks on Vega, A **Dapp** or interface designed to help users complete specific tasks and a **Wallet** that is only used to authenticate a user's actions and broadcast them to the network. - -## `0000` Wallets, signing transactions and network selection - -- `0001-WALL` [Get and use a Vega wallet](0001-WALL-wallet.md) (This mostly relates to use of a wallet app, for cryptography and broadcast to network) - -These files contain generic user needs for interacting with wallets that are true for all types of interactions that require a wallet. More specific requirements are mentioned where these are referenced. They describe what the user needs from the dapp not the wallet. - -- `0002-WCON` [Connect Vega wallet to a Dapp & select keys](0002-WCON-connect_vega_wallet.md) -- `0003-WTXN` [Submit Vega transaction](0003-WTXN-submit_vega_transaction.md) -- `0004-EWAL` [Connect Ethereum wallet to a Dapp](0004-EWAL-connect_ethereum_wallet.md) -- `0005-ETXN` [Submit Ethereum transaction](0005-ETXN-submit_ethereum_transaction.md) -- `0006-NETW` [Network and node selection](0006-NETW-network-and-nodes.md) - -## `1000` Bridges, Transfers and Vesting - -- `1001-DEPO` [Deposit](1001-DEPO-desposit.md) -- `1002-WITH` [Withdraw](1002-WITH-withdraw.md) -- `1003-TRAN` [Transfer](1003-TRAN-transfer.md) -- `1004-ASSO` [Associate governance token with a Vega key](1004-ASSO-associate.md) -- `1005-VEST` [View and redeem vested tokens](1005-VEST-vesting.md) - -## `2000` Staking - -- `2001-STKE` [Staking validators](2001-STKE-staking.md) -- `2002-SINC` [Review staking income](2002-SINC-staking-income.md) - -## `3000` Governance - -- `3001-VOTE` [See proposals and Vote on changes](3001-VOTE-vote.md) -- `3002-PROP` [Select proposal type](3002-PROP-propose.md) -- `3003-PMAN` [Propose new Market](3003-PMAN-propose_new_market.md) -- `3004-PMAC` [Propose change(s) to market](3004-PMAC-propose_market_change.md) -- `3005-PASN` [Propose new asset](3005-PASN-propose_new_asset.md) -- `3006-PASC` [Propose change(s) to asset](3006-PASC-propose_asset_change.md) -- `3007-PNEC` [Propose change to network parameter(s)](3007-PNEC-propose_network.md) -- `3008-PFRO` [Propose something "Freeform"](3008-PFRO-propose_freeform.md) - -## `4000` Treasury - -- `4001-TRES` [View treasury rewards](4001-TRES-view_treasury_rewards.md) `TODO` - -## `5000` Liquidity provision - -- `5001-LIQF` [Find and understand liquidity provision opportunities](5001-LIQF-liquidity_opportunities.md) `TODO` -- `5002-LIQP` [Provide liquidity](5002-LIQP-provide_liquidity.md) `TODO` -- `5003-LIQI` [View liquidity provision rewards](5003-LIQI-liquidity_income.md) `TODO` - -## `6000` Markets and analysis - -- `6001-MARK` [Find markets](6001-MARK-find_markets.md) -- `6002-MARD` [View market specification](6002-MDET-market-details.md) `TODO` -- `6003-ORDB` [Analyze Order book](6003-ORDB-order_book.md) `TODO` -- `6004-PHIS` [Analyze price history](6004-PHIS-price_history.md) `TODO` -- `6005-THIS` [Analyze trade history](6005-THIS-trade_history.md) `TODO` - -## `7000` Collateral, Orders, Positions and Fills - -- `7001-COLL` [View my collateral / accounts](7001-COLL-collateral.md) -- `7002-SORD` [Submit an order](7002-SORD-submit_orders.md) -- `7003-MORD` [Manage my orders](7003-MORD-manage_orders.md) -- `7004-POSI` [View my positions](7004-POSI-positions.md) `TODO` -- `7005-FILL` [View my trades/fills](7005-FILL-fills.md) -- `7006-FEES` [View my trading fees](7006-FEES-fees.md) `TODO` - -## `8000` Understand transactions and blocks - -- `8001-BLOX` [Transaction and block content](8001-BLOX-transaction_and_blocks.md) `TODO` -- -## Appendixes - -- [Display display rules](9001-DATA-data_display.md) diff --git a/user-interface/apps.json b/user-interface/apps.json deleted file mode 100644 index e9c09536d..000000000 --- a/user-interface/apps.json +++ /dev/null @@ -1,20 +0,0 @@ -{ - "Desktop-Wallet": { - "specs": ["0001-WALL"] - }, - "Browser-Wallet": { - "specs": ["1101-BWAL"] - }, - "Token": { - "specs": ["9001-DATA", "1002-WITH", "1004-ASSO", "1005-VEST", "2001-STKE", "2002-SINC", "7001-COLL", "3001-VOTE", "3002-PROP", "3003-PMAN", "3004-PMAC", "3005-PASN", "3006-PASC", "3007-PNEC", "3008-PFRO", "0002-WCON", "0003-WTXN", "0004-EWAL", "005-ETXN", "0006-NETW" ] - }, - "Console": { - "specs": ["9001-DATA", "1001-DEPO", "1002-WITH", "1003-TRAN", "6000-COLL", "6001-MARK", "6002-MDET", "6001-MARK", "6002-MDET", "6003-ORDB", "6004-PHIS", "6005-THIS", "7001-COLL", "7002-SORD", "7003-MORD", "7004-POSI", "7005-FILL", "7006-FEES","0002-WCON", "0003-WTXN", "0004-EWAL", "005-ETXN", "0006-NETW"] - }, - "Block-explorer": { - "specs": ["8001-BLOX"] - }, - "Vega.xyz": { - "specs": ["0001-WALL", "4001-TRES", "5001-LIQF"] - } - } \ No newline at end of file diff --git a/user-interface/categories.json b/user-interface/categories.json deleted file mode 100644 index 03ec46461..000000000 --- a/user-interface/categories.json +++ /dev/null @@ -1,32 +0,0 @@ -{ - "Wallets & Signing Transactions & Network Selection": { - "specs": ["0001-WALL", "0002-WCON", "0003-WTXN", "0004-EWAL", "0005-ETXN", "0006-NETW", "1101-BWAL"] - }, - "Bridges & Transfers & Vesting": { - "specs": ["1001-DEPO", "1002-WITH", "1003-TRAN", "1004-ASSO", "1005-VEST"] - }, - "Staking": { - "specs": ["2001-STKE", "2002-SINC"] - }, - "Governance": { - "specs": ["3001-VOTE", "3002-PROP", "3003-PMAN", "3004-PMAC", "3005-PASN", "3006-PASC", "3007-PNEC", "3008-PFRO"] - }, - "Treasury": { - "specs": ["4001-TRES"] - }, - "Liquidity Provision": { - "specs": ["5001-LIQF", "5002-LIQP", "5003-LIQI"] - }, - "Markets & Analysis": { - "specs": ["6001-MARK", "6002-MDET", "6003-ORDB", "6004-PHIS", "6005-THIS"] - }, - "Collateral & Orders & Positions & Fills": { - "specs": ["7001-COLL", "7002-SORD", "7003-MORD", "7004-POSI", "7005-FILL", "7006-FEES"] - }, - "Block Exploring": { - "specs": ["8001-BLOX"] - }, - "Data Display": { - "specs": ["9001-DATA"] - } - } \ No newline at end of file diff --git a/user-interface/increment.py b/user-interface/increment.py deleted file mode 100644 index fa44b9a56..000000000 --- a/user-interface/increment.py +++ /dev/null @@ -1,38 +0,0 @@ -import re - -def increment_spec_numbers(filepath, number): - with open(filepath, 'r+') as file: - content = file.read() - lines = content.splitlines() - - # Find the line containing the given number - for i, line in enumerate(lines): - match = re.search(rf'(\bBWAL-){number}\b', line) - if match: - start_index = match.start() - break - else: - print(f"Number {number} not found in the file.") - return - - # Increment the numbers from the given number onwards - for i in range(i, len(lines)): - line = lines[i] - matches = re.findall(r'(\bBWAL-)(\d{3})\b', line) - for prefix, next_number in matches: - if next_number >= number: - incremented_number = str(int(next_number) + 1).zfill(3) - line = line.replace(f'{prefix}{next_number}', f'{prefix}{incremented_number}') - lines[i] = line - - file.seek(0) - file.write('\n'.join(lines)) - file.truncate() - - print(f"Numbers starting from {number} have been incremented.") - - -# Example usage -filepath = './user-interface/1101-BWAL-browser_wallet.md' -number = '060' -increment_spec_numbers(filepath, number) From 90bab960e23fe24fca06592d4aeffc3241e7711d Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Thu, 14 Sep 2023 11:42:19 +0100 Subject: [PATCH 577/649] fix: small correction --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 20da423f0..73cd1476b 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -211,7 +211,7 @@ We calculate the volume of notional that is in the range (1.0-market.liquidity.priceRange) x min(last trade price, indicative uncrossing price) <= price levels <= (1.0+market.liquidity.priceRange) x max(last trade price, indicative uncrossing price). ``` -If there is no 'indicative uncrossing price' then any price should count, and the price range should be +If there is no 'indicative uncrossing price' then volume placed at any price should count towards the LP's commitment i.e the price range is interpreted as ```text -infinity <= price levels <= infinity From 5e1d661a5e534890573f8a7e0c99fbe7f0ce2f23 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 10:07:29 +0100 Subject: [PATCH 578/649] feat: add vesting acs --- protocol/0085-RVST-rewards_vesting.md | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index eb3073b4c..138c342b8 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -78,4 +78,27 @@ Must expose the following: ## Acceptance Criteria -Too be added +### Network parameters + +1. When `rewards.vesting.baseTransfer` is updated, the new value should be applied to rewards vesting at the end of the current epoch. (0085-RVST-001) +1. When `rewards.vesting.minimumTransfer` is updated, the new value should be applied to rewards vesting at the end of the current epoch. (0085-RVST-002) +1. When `rewards.vesting.rewardPayoutTiers` is updated, the new value should be applied when distributing rewards at the end of the current epoch. (0085-RVST-003) + +### Vesting / vested accounts + +1. A party should have one vesting account per asset. Rewards distributed from reward pools should be transferred to the correct vesting account. (0085-RVST-004) +1. A party should have one vested account per asset. Rewards distributed from vesting accounts should be transferred to the correct vested account. (0085-RVST-005) +1. Funds **cannot** be transferred from a vesting account by a user. (0085-RVST-006) +1. Funds **can** be transferred from a vested account by a user. (0085-RVST-007) +1. Funds **cannot** be transferred to a vested account by a user. (0085-RVST-008) + +### Vesting mechanics + +1. If a party has unlocked rewards in a vesting account (expressed in quantum) strictly greater than the network parameter `rewards.vesting.minimumTransfer`. Rewards should be transferred to the respective vested account for the asset at the end of the epoch as per the formula defined in the specification. (0085-RVST-009) +1. If a party has unlocked rewards in a vesting account (expressed in quantum) less than or equal to the network parameter `rewards.vesting.minimumTransfer`. The entire balance should be transferred to the respective vested account for the asset at the end of the epoch. (0085-RVST-010) +1. Locked rewards in the vesting account should not start vesting un till the lock period has expired. (0085-RVST-011) + +### Rewards bonus multiplier + +1. A parties `reward_distribution_bonus_multiplier` should be set equal to the value in the highest tier where they fulfil the `minimum_quantum_balance` required. (0085-RVST-012) +1. Funds in both the parties vesting account and vested account should contribute to their `minimum_quantum_balance`. (0085-RVST-013) From e6ecabb78d2b898744d02b5286ea70bdeab34beb Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 10:07:49 +0100 Subject: [PATCH 579/649] feat: add activity streak acs --- protocol/0086-ASPR-activity_streak_program.md | 28 +++++++++++++++---- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index 5c7721959..4fda96968 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -21,7 +21,7 @@ The network parameter [`rewards.activityStreak.benefitTiers`](#network-parameter - `minimum_activity_streak`: int greater or equal to `0` defining the minimum activity streak a party must have to access this tier - `reward_multiplier`: float greater or equal to `1` defining the factor to scale a parties [reward shares](./0056-REWA-rewards_overview.md#distributing-rewards-amongst-entities) by -- `vesting_multiplier`: float greater or equal to `1` defining the factor to scale a parties [base vesting rate](./0085-RVST-rewards_vesting.md#vesting-mechanics) by +- `vesting_multiplier`: float greater or equal to `1` defining the factor to scale a parties [base vesting rate](./0086-ASPR-rewards_vesting.md#vesting-mechanics) by *Example:* @@ -96,7 +96,7 @@ The `activity_streak_reward_multiplier` scales the parties [reward share](./0056 #### Applying the activity vesting multiplier -The `activity_streak_vesting_multiplier` scales the parties [vesting rate](./0085-RVST-rewards_vesting.md#vesting-mechanics) of all funds locked in the parties vesting accounts. +The `activity_streak_vesting_multiplier` scales the parties [vesting rate](./0086-ASPR-rewards_vesting.md#vesting-mechanics) of all funds locked in the parties vesting accounts. ## APIs @@ -113,14 +113,30 @@ Must expose the following: ## Acceptance Criteria -### Governance proposals +### Network parameters -Too be added +1. If any of the following network parameters are updated, the new values will be used when distributing or vesting rewards at the end of the current epoch: + + - `rewards.activityStreak.inactivityLimit` (0086-ASPR-001) + - `rewards.activityStreak.minQuantumOpenNotionalVolume` (0086-ASPR-002) + - `rewards.activityStreak.minQuantumTradeVolume` (0086-ASPR-003) ### Setting activity / inactivity streak -Too be added +1. At the end of an epoch, before rewards are distributed, a parties activity steak is incremented if they fulfil **either** of the following conditions: + + - their notional open volume summed across all markets (in quantum) was strictly greater than `rewards.activityStreak.minQuantumOpenNotionalVolume` at any point in the epoch. (0086-ASPR-004) + - their notional trade volume summed across all markets (in quantum) was strictly greater than `rewards.activityStreak.minQuantumTradeVolume` at the end of the epoch. (0086-ASPR-005) + +1. At the end of an epoch, before rewards are distributed, if a party was deemed active, their `inactivity_streak` should be reset to `0`. +1. At the end of an epoch, before rewards are distributed, a parties inactivity streak is incremented if they fulfil **both** of the following conditions: (0086-ASPR-006) + + - their notional open volume summed across all markets (in quantum) was less than `rewards.activityStreak.minQuantumOpenNotionalVolume` at any point in the epoch. + - their notional trade volume summed across all markets (in quantum) was less than `rewards.activityStreak.minQuantumTradeVolume` at the end of the epoch. + +1. At the end of an epoch if a party was deemed inactive, their `activity_streak` should be reset to `0` only if after incrementing their `inactivity_streak` it is greater than `rewards.activityStreak.inactivityLimit`. (0086-ASPR-007) ### Setting activity benefits -Too be added +1. At the end of the epoch, before rewards are distributed, the parties `reward_distribution_activity_multiplier` should be set equal to the value in the highest tier where their activity streak is greater or equal than the `minimum_activity_streak`. (0086-ASPR-008) +1. At the end of the epoch, before rewards are distributed, the parties `reward_vesting_activity_multiplier` should be set equal to the value in the highest tier where their `activity_streak` is greater or equal than the `minimum_activity_streak`. (0086-ASPR-009) From ac96dda02862dd116c0e7d1c9edb53b6a1594c0e Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 10:08:01 +0100 Subject: [PATCH 580/649] feat: update features.json --- protocol/features.json | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 252da6225..1c7c5b0c4 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -450,6 +450,33 @@ "0029-FEES-028" ] }, +"Rewards": { + "milestone": "cosmic-elevator-2", + "acs": [ + "0085-RVST-001", + "0085-RVST-002", + "0085-RVST-003", + "0085-RVST-004", + "0085-RVST-005", + "0085-RVST-006", + "0085-RVST-007", + "0085-RVST-008", + "0085-RVST-009", + "0085-RVST-010", + "0085-RVST-011", + "0085-RVST-012", + "0085-RVST-013", + "0086-ASPR-001", + "0086-ASPR-002", + "0086-ASPR-003", + "0086-ASPR-004", + "0086-ASPR-005", + "0086-ASPR-006", + "0086-ASPR-007", + "0086-ASPR-008", + "0086-ASPR-009" + ] + }, "Market governance": { "milestone": "deployment-2", "acs": [ From b12e1006326ab5e028b9bc6ec2ce324a1c2def6c Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 10:21:13 +0100 Subject: [PATCH 581/649] feat: additional ACs --- protocol/0085-RVST-rewards_vesting.md | 2 ++ protocol/0086-ASPR-activity_streak_program.md | 1 + protocol/features.json | 4 +++- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 138c342b8..0ea2d25bc 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -102,3 +102,5 @@ Must expose the following: 1. A parties `reward_distribution_bonus_multiplier` should be set equal to the value in the highest tier where they fulfil the `minimum_quantum_balance` required. (0085-RVST-012) 1. Funds in both the parties vesting account and vested account should contribute to their `minimum_quantum_balance`. (0085-RVST-013) +1. Assuming all parties perform equally, a party with a greater `reward_distribution_bonus_multiplier` should receive a larger share of a reward pool. (0085-RVST-014) + diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index 4fda96968..ecaa39122 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -140,3 +140,4 @@ Must expose the following: 1. At the end of the epoch, before rewards are distributed, the parties `reward_distribution_activity_multiplier` should be set equal to the value in the highest tier where their activity streak is greater or equal than the `minimum_activity_streak`. (0086-ASPR-008) 1. At the end of the epoch, before rewards are distributed, the parties `reward_vesting_activity_multiplier` should be set equal to the value in the highest tier where their `activity_streak` is greater or equal than the `minimum_activity_streak`. (0086-ASPR-009) +1. Assuming all parties perform equally, a party with a greater `reward_distribution_activity_multiplier` should receive a larger share of a reward pool. (0085-ASPR-010) diff --git a/protocol/features.json b/protocol/features.json index 1c7c5b0c4..bfe13af69 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -466,6 +466,7 @@ "0085-RVST-011", "0085-RVST-012", "0085-RVST-013", + "0085-RVST-014", "0086-ASPR-001", "0086-ASPR-002", "0086-ASPR-003", @@ -474,7 +475,8 @@ "0086-ASPR-006", "0086-ASPR-007", "0086-ASPR-008", - "0086-ASPR-009" + "0086-ASPR-009", + "0086-ASPR-010" ] }, "Market governance": { From bd7cf992e4cc8dca3e8e4748c17bbdb9acfc9ccb Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 10:27:47 +0100 Subject: [PATCH 582/649] fix: correct approbation failures --- protocol/0086-ASPR-activity_streak_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index ecaa39122..a5bbe7879 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -140,4 +140,4 @@ Must expose the following: 1. At the end of the epoch, before rewards are distributed, the parties `reward_distribution_activity_multiplier` should be set equal to the value in the highest tier where their activity streak is greater or equal than the `minimum_activity_streak`. (0086-ASPR-008) 1. At the end of the epoch, before rewards are distributed, the parties `reward_vesting_activity_multiplier` should be set equal to the value in the highest tier where their `activity_streak` is greater or equal than the `minimum_activity_streak`. (0086-ASPR-009) -1. Assuming all parties perform equally, a party with a greater `reward_distribution_activity_multiplier` should receive a larger share of a reward pool. (0085-ASPR-010) +1. Assuming all parties perform equally, a party with a greater `reward_distribution_activity_multiplier` should receive a larger share of a reward pool. (0086-ASPR-010) From 2a0aac1d3280bedd8c51affed3571b455a731cba Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 8 Sep 2023 11:00:48 +0100 Subject: [PATCH 583/649] refactor: improve wording with connectors --- protocol/0085-RVST-rewards_vesting.md | 4 ++-- protocol/0086-ASPR-activity_streak_program.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0085-RVST-rewards_vesting.md b/protocol/0085-RVST-rewards_vesting.md index 0ea2d25bc..c94c4ae84 100644 --- a/protocol/0085-RVST-rewards_vesting.md +++ b/protocol/0085-RVST-rewards_vesting.md @@ -94,8 +94,8 @@ Must expose the following: ### Vesting mechanics -1. If a party has unlocked rewards in a vesting account (expressed in quantum) strictly greater than the network parameter `rewards.vesting.minimumTransfer`. Rewards should be transferred to the respective vested account for the asset at the end of the epoch as per the formula defined in the specification. (0085-RVST-009) -1. If a party has unlocked rewards in a vesting account (expressed in quantum) less than or equal to the network parameter `rewards.vesting.minimumTransfer`. The entire balance should be transferred to the respective vested account for the asset at the end of the epoch. (0085-RVST-010) +1. If a party has unlocked rewards in a vesting account (expressed in quantum) strictly greater than the network parameter `rewards.vesting.minimumTransfer` then rewards should be transferred to the respective vested account for the asset at the end of the epoch as per the formula defined in the specification. (0085-RVST-009) +1. If a party has unlocked rewards in a vesting account (expressed in quantum) less than or equal to the network parameter `rewards.vesting.minimumTransfer` then the entire balance should be transferred to the respective vested account for the asset at the end of the epoch. (0085-RVST-010) 1. Locked rewards in the vesting account should not start vesting un till the lock period has expired. (0085-RVST-011) ### Rewards bonus multiplier diff --git a/protocol/0086-ASPR-activity_streak_program.md b/protocol/0086-ASPR-activity_streak_program.md index a5bbe7879..c3877cebf 100644 --- a/protocol/0086-ASPR-activity_streak_program.md +++ b/protocol/0086-ASPR-activity_streak_program.md @@ -128,13 +128,13 @@ Must expose the following: - their notional open volume summed across all markets (in quantum) was strictly greater than `rewards.activityStreak.minQuantumOpenNotionalVolume` at any point in the epoch. (0086-ASPR-004) - their notional trade volume summed across all markets (in quantum) was strictly greater than `rewards.activityStreak.minQuantumTradeVolume` at the end of the epoch. (0086-ASPR-005) -1. At the end of an epoch, before rewards are distributed, if a party was deemed active, their `inactivity_streak` should be reset to `0`. +1. At the end of an epoch, before rewards are distributed, if a party was deemed active then their `inactivity_streak` should be reset to `0`. 1. At the end of an epoch, before rewards are distributed, a parties inactivity streak is incremented if they fulfil **both** of the following conditions: (0086-ASPR-006) - their notional open volume summed across all markets (in quantum) was less than `rewards.activityStreak.minQuantumOpenNotionalVolume` at any point in the epoch. - their notional trade volume summed across all markets (in quantum) was less than `rewards.activityStreak.minQuantumTradeVolume` at the end of the epoch. -1. At the end of an epoch if a party was deemed inactive, their `activity_streak` should be reset to `0` only if after incrementing their `inactivity_streak` it is greater than `rewards.activityStreak.inactivityLimit`. (0086-ASPR-007) +1. At the end of an epoch if a party was deemed inactive and after incrementing their `inactivity_streak` it is greater than `rewards.activityStreak.inactivityLimit` then their `activity_streak` should be reset to `0`. (0086-ASPR-007) ### Setting activity benefits From b917eef759f7d2ddadc9998f52d7f403bfa54943 Mon Sep 17 00:00:00 2001 From: Karel Moravec Date: Thu, 14 Sep 2023 19:05:29 +0200 Subject: [PATCH 584/649] fix: align with core --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 73cd1476b..5958246c0 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -427,7 +427,7 @@ In the case of spot markets it will be transferred into the network treasury for - Boundary values are respected for the market parameters - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-083) - - `market.liquidity.priceRange` valid values: `>0`, `<=100` (0044-LIME-084) + - `market.liquidity.priceRange` valid values: `>0`, `<=1` (0044-LIME-084) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-085) - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-086) From 4afa6deb145030fb1bbfaa0cda7893ca4a1a57ad Mon Sep 17 00:00:00 2001 From: Karel Moravec Date: Thu, 14 Sep 2023 19:14:08 +0200 Subject: [PATCH 585/649] fix: align with core --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 5958246c0..ecba78228 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -427,7 +427,7 @@ In the case of spot markets it will be transferred into the network treasury for - Boundary values are respected for the market parameters - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-083) - - `market.liquidity.priceRange` valid values: `>0`, `<=1` (0044-LIME-084) + - `market.liquidity.priceRange` valid values: `>0`, `<=20` (0044-LIME-084) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-085) - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-086) From da3edd8689152a0efbc5bb29c15ec3b847c0b4b2 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Fri, 15 Sep 2023 12:22:21 +0100 Subject: [PATCH 586/649] Update 0044-LIME-lp_mechanics.md (#1916) SLA 0044-LIME-006 Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index ecba78228..0841732fa 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -303,7 +303,7 @@ Note: - When a LP commits liquidity on market 1, on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-087) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). - Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) -- Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any LP orders that have already been submitted are unaffected but any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) +- Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) - Check that bond slashing works with non-default asset decimals, market decimals, position decimals. This can be done by following a similar story to [bond slashing feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature). Should test at least three different combinations, each decimal settings different to each other. (0044-LIME-009) - If `market.liquidity.stakeToCcyVolume` is set to `0.0`, there is [target stake](./0041-TSTK-target_stake.md) of `1000` and there are 3 LPs on the market with stake / fee bid submissions of `100, 0.01`, `1000, 0.02` and `200, 0.03` then the liquidity fee is `0.02`. (0044-LIME-012) From ca428d2066d8cd89dae246d803f8242b61b8155b Mon Sep 17 00:00:00 2001 From: Witold Date: Fri, 15 Sep 2023 19:38:51 +0200 Subject: [PATCH 587/649] refactor: add funding payment --- .../0012-NP-LIPE-liquidation-price-estimate.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md index 39ce7906e..0d037d884 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -6,7 +6,7 @@ Provide an estimate of the price range at which the liquidation of a specified p ## Overview -Provide a range of liquidation price, where the lower bound assumes no slippage in the [margin level calculation](../protocol/0019-MCAL-margin_calculator.md) and the upper bound assumes that the slippage cap is applied. +Provide an estimated liquidation price range, where the lower bound assumes no slippage in the [margin level calculation](../protocol/0019-MCAL-margin_calculator.md) and the upper bound assumes that the slippage cap is applied. This amounts to carrying out the same computation twice, once with both linear and quadratic slippage factor set to `0` and once with the actual values used by the market for which the specified position is being considered. @@ -27,13 +27,13 @@ where $V$ is the open volume (negative for a short position) and $S^\text{curren We assume margin is calculated as per continuous trading formula (as there are no closeouts in auctions) and that the slippage cap always applies, therefore we get: $$ -\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}), +\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}) + \text{arbitrary constant}, $$ -where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. Solving for $S^{\text{liquidation}}$ we get: +where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. The $\text{arbitrary constant}$ is an optional arbitrary constant added to the maintenance margin, e.g. the funding payment portion of the margin for [perpetual futures](../protocol/0053-PERP-product_builtin_perpetual_future.md#5-margin-considerations). Solving for $S^{\text{liquidation}}$ we get: $$ -S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V} +S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current} - \text{arbitrary constant}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V} $$ if the denominator in the above expression evaluates to $0$ the liquidation price is undefined and we return an error, otherwise we return the result floored at $0$ (as the negative price is not attainable for any of the currently supported products). From e88afeb0a367767be6fd5c76c14e540799c13fba Mon Sep 17 00:00:00 2001 From: fryd Date: Tue, 19 Sep 2023 16:33:11 +0200 Subject: [PATCH 588/649] Fix example in 0083-RFPR-on_chain_referral_program.md From the same docs: > all `minimum_epochs` values must be an integer strictly greater than 0 --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 69250e5db..ce5222484 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -60,7 +60,7 @@ message UpdateReferralProgram{ benefit_tiers: [ { "minimum_running_notional_taker_volume": 10000, - "minimum_epochs": 0, + "minimum_epochs": 1, "referral_reward_factor": 0.001, "referral_discount_factor": 0.001, }, From f3859a26efc8139bb544cbe855da487fde241cf4 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 20 Sep 2023 09:20:18 +0100 Subject: [PATCH 589/649] Update 0035-LIQM-liquidity_monitoring.md (#1964) * Update 0035-LIQM-liquidity_monitoring.md https://vegaprotocol.slack.com/archives/C9E6XA8GK/p1695151499045989?thread_ts=1695146384.224289&cid=C9E6XA8GK * fix: remove market.liquidity.targetstake.triggering.ratio * fix: linting --- protocol/0035-LIQM-liquidity_monitoring.md | 2 +- protocol/0041-TSTK-target_stake.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0035-LIQM-liquidity_monitoring.md b/protocol/0035-LIQM-liquidity_monitoring.md index 2101c24d9..a2392fc87 100644 --- a/protocol/0035-LIQM-liquidity_monitoring.md +++ b/protocol/0035-LIQM-liquidity_monitoring.md @@ -73,4 +73,4 @@ A liquidity provider amending LP provision order can reduce their stake even if 1. A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) 1. If the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) 1. When the market parameter `triggeringRatio` for an existing market is updated via governance, the next time conditions for entering auction are evaluated, the new triggering ratio is applied. (0035-LIQM-010) -1. When proposing a new market if the triggering_ratio is not supplied then the current value of `market.liquidity.targetstake.triggering.ratio` is used in its place. (0035-LIQM-011) +1. When proposing a market the supplied triggering ratio value must be >= 0 and <= 1 else the proposal is rejected diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index 987d1cba9..0aae865b7 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -6,7 +6,7 @@ This spec outlines how to measure how much stake we want committed to a market r The target stake is a calculated quantity, utilised by various mechanisms in the protocol: - If the LPs total committed stake is less than c_1 x `target_stake` we trigger liquidity auction. See [Liquidity Monitoring](./0035-LIQM-liquidity_monitoring.md). Note that there is a one-to-one correspondence between the amount of stake LPs committed and the supplied liquidity. -The parameter c_1 is a market parameter (with network parameter `market.liquidity.targetstake.triggering.ratio` providing a default value) defined in the [liquidity Monitoring](./0035-LIQM-liquidity_monitoring.md) spec. +The parameter c_1 is a market parameter defined in the [liquidity Monitoring](./0035-LIQM-liquidity_monitoring.md) spec. - It is used to set the fee factor for the LPs: see [Setting fees and rewarding LPs](./0042-LIQF-setting_fees_and_rewarding_lps.md). ### Definitions / Parameters used From f949d26988c357c555ae08d101344c11c9ae7800 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 20 Sep 2023 10:10:41 +0200 Subject: [PATCH 590/649] refactor: add perps AC --- protocol/0053-PERP-product_builtin_perpetual_future.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0053-PERP-product_builtin_perpetual_future.md b/protocol/0053-PERP-product_builtin_perpetual_future.md index 13a315ebc..7323fd116 100644 --- a/protocol/0053-PERP-product_builtin_perpetual_future.md +++ b/protocol/0053-PERP-product_builtin_perpetual_future.md @@ -233,3 +233,4 @@ In both cases the estimates are for a hypothetical position of size 1. 1. A perpetual market which is active and has open orders, continues to function after protocol upgrade, and preserves all market settings and statistics. (0053-PERP-021) 1. A perpetual market which is active and has open orders, after checkpoint restart, is in opening auction. All margin accounts are transferred to general accounts. (0053-PERP-022) 1. A perpetual market which is active and has open orders. Wait for a new network history snapshot to be created. Load a new data node from network history. All market data is preserved. (0053-PERP-023) +1. When the funding payment does not coincide with mark to market settlement time, a party has insufficient funds to fully cover their funding payment such that the shortfall amount if $x$ and the balance of market's insurance pool is $\frac{x}{3}$, then the entire insurance pool balance gets used to cover the shortfall and the remaining missing amount $\frac{2x}{3}$ gets dealt with using loss socialisation. (0053-PERP-024) From f502cb50020818bb8101207a15964db3ad342d24 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 20 Sep 2023 10:20:39 +0200 Subject: [PATCH 591/649] refactor: scale constant with volume --- .../0012-NP-LIPE-liquidation-price-estimate.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md index 0d037d884..b1a0e973f 100644 --- a/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md +++ b/non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md @@ -27,13 +27,13 @@ where $V$ is the open volume (negative for a short position) and $S^\text{curren We assume margin is calculated as per continuous trading formula (as there are no closeouts in auctions) and that the slippage cap always applies, therefore we get: $$ -\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}) + \text{arbitrary constant}, +\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}) + V \cdot \text{constant}, $$ -where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. The $\text{arbitrary constant}$ is an optional arbitrary constant added to the maintenance margin, e.g. the funding payment portion of the margin for [perpetual futures](../protocol/0053-PERP-product_builtin_perpetual_future.md#5-margin-considerations). Solving for $S^{\text{liquidation}}$ we get: +where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. The $\text{constant}$ is an optional arbitrary constant scaling with open volume added to the maintenance margin, e.g. the funding payment portion of the margin for [perpetual futures](../protocol/0053-PERP-product_builtin_perpetual_future.md#5-margin-considerations). Solving for $S^{\text{liquidation}}$ we get: $$ -S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current} - \text{arbitrary constant}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V} +S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current} - V \cdot \text{constant}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V} $$ if the denominator in the above expression evaluates to $0$ the liquidation price is undefined and we return an error, otherwise we return the result floored at $0$ (as the negative price is not attainable for any of the currently supported products). From f3939a5cbdaaded88f4fd023b1bafb164fa6b315 Mon Sep 17 00:00:00 2001 From: Witold Date: Wed, 20 Sep 2023 10:22:16 +0200 Subject: [PATCH 592/649] chore: add ac to feature --- protocol/features.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index bfe13af69..3614dea4e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -235,7 +235,8 @@ "0019-MCAL-020", "0019-MCAL-021", "0019-MCAL-022", - "0019-MCAL-023" + "0019-MCAL-023", + "0053-PERP-024" ] }, "Ethereum Oracles": { From 8229febbd4c39228f0cedd71946ad5e37fac0a01 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 20 Sep 2023 16:33:32 +0100 Subject: [PATCH 593/649] feat: add explanation on market life cycle --- protocol/0043-MKTL-market_lifecycle.md | 1 + 1 file changed, 1 insertion(+) diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 7abfffc71..6d9678d33 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -280,6 +280,7 @@ Any orders that parties submit get rejected. The parties with open position in the immediately preceding step still have open positions. Parties with open positions still have non-zero margin account balances. The market state is `trading terminated`. +1. A final market-to-market happens with the last mark price. 1. The settlement price oracle transaction is sent and it is *not* equal to `p`. Parties that had open positions see settlement cash-flows happen. Margin account balances are transferred to the general account. From 89bfc04b749c042ced50c5892fa58a1a1029f812 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 18 Sep 2023 16:25:37 +0100 Subject: [PATCH 594/649] chore: align ACs with core implementation --- protocol/0083-RFPR-on_chain_referral_program.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index ce5222484..c1d39a3bc 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -465,7 +465,7 @@ The Estimate Fees API should now calculate the following additional information: #### Epoch and running volumes -1. Each trade should increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). +1. Each trade in which a party is the "taker" **should** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). 1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_notional_taker_volume` (0083-RFPR-032). 1. At the end of the epoch, the `referral_set_epoch_notional_taker_volume` should be correctly calculated by summing each team members `party_epoch_notional_taker_volume` (0083-RFPR-033). 1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` to their sets `referral_set_epoch_notional_taker_volume` (0083-RFPR-034). @@ -481,4 +481,4 @@ The Estimate Fees API should now calculate the following additional information: 1. At the start of an epoch, a referees `referral_reward_multiplier` is set equal to the multiplier in the highest staking tier they qualify for (0083-RFPR-046). 1. If when evaluating the tier to set the `referral_reward_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0` (0083-RFPR-039). 1. If when evaluating the tier to set the `referral_discount_factor`, a referee does not qualify for any tier, their `referral_reward_factor` is set to `0` (0083-RFPR-040). -1. If when evaluating the tier to set the `referral_reward_multiplier`, a referee does not qualify for any tier, their `referral_reward_multiplier` is set to `0` (0083-RFPR-047). +1. If when evaluating the tier to set the `referral_reward_multiplier`, a referee does not qualify for any tier, their `referral_reward_multiplier` is set to `1` (0083-RFPR-047). From 1ecc1ccda8dd916610f06b546946cb0c37f8828f Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 18 Sep 2023 16:25:58 +0100 Subject: [PATCH 595/649] feat: add additional referral ACs --- protocol/0029-FEES-fees.md | 3 +++ protocol/0083-RFPR-on_chain_referral_program.md | 3 +++ 2 files changed, 6 insertions(+) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 54b73c193..0d30f60d9 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -173,6 +173,9 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w 1. Referrer rewards are correctly calculated and transferred for each fee component when exiting an auction. (0029-FEES-026) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` +1. If the referral reward due to the referrer is strictly less than `1`, no reward is transferred (0029-FEES-029). +1. If the referral discount due to the referee is strictly less than `1`, no discount is applied (0029-FEES-030). +1. The proportion of fees transferred to the referrer as a reward cannot be greater than the network parameter `referralProgram.maxReferralRewardProportion` (0029-FEES-031). 1. Volume discount rewards are correctly calculated and transferred for each taker fee component during continuous trading. (0029-FEES-027) - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index c1d39a3bc..2cc40dc5d 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -465,10 +465,13 @@ The Estimate Fees API should now calculate the following additional information: #### Epoch and running volumes +1. Each trade in which a party is the "maker" **should not** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-048). 1. Each trade in which a party is the "taker" **should** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). 1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_notional_taker_volume` (0083-RFPR-032). +1. Two trades with an identical price and size, but in separate markets using assets with different quantum values, should increment a parties `party_epoch_notional_taker_volume` by the same amount (0083-RFPR-049). 1. At the end of the epoch, the `referral_set_epoch_notional_taker_volume` should be correctly calculated by summing each team members `party_epoch_notional_taker_volume` (0083-RFPR-033). 1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` to their sets `referral_set_epoch_notional_taker_volume` (0083-RFPR-034). +1. If `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` is updated during an epoch, the new value should be used to cap party contributions to referral sets **at the end o00f the epoch** (i.e. a parties individual `party_epoch_notional_taker_volume` should not be capped during the epoch) (0083-RFPR-050). 1. A referral sets `referral_set_running_notional_taker_volume` is calculated as the sum of all `referral_set_epoch_notional_taker_volumes` over the last `epoch_window` epochs (0083-RFPR-035). ### Benefit Mechanics From 9e8816cd822a2edf5aaa852c433069ce86ac8217 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 18 Sep 2023 16:26:06 +0100 Subject: [PATCH 596/649] feat: update features --- protocol/features.json | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 3614dea4e..b1e3e262d 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -427,6 +427,9 @@ "0083-RFPR-045", "0083-RFPR-046", "0083-RFPR-047", + "0083-RFPR-048", + "0083-RFPR-049", + "0083-RFPR-050", "0084-VDPR-001", "0084-VDPR-002", "0084-VDPR-003", @@ -448,7 +451,10 @@ "0029-FEES-025", "0029-FEES-026", "0029-FEES-027", - "0029-FEES-028" + "0029-FEES-028", + "0029-FEES-029", + "0029-FEES-030", + "0029-FEES-031" ] }, "Rewards": { From 4afce07e11ad3fdee3837576bd8f1fe310959b3c Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 18 Sep 2023 18:02:49 +0100 Subject: [PATCH 597/649] fix: correct approbation --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 2cc40dc5d..4eaae4d48 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -468,7 +468,7 @@ The Estimate Fees API should now calculate the following additional information: 1. Each trade in which a party is the "maker" **should not** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-048). 1. Each trade in which a party is the "taker" **should** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). 1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_notional_taker_volume` (0083-RFPR-032). -1. Two trades with an identical price and size, but in separate markets using assets with different quantum values, should increment a parties `party_epoch_notional_taker_volume` by the same amount (0083-RFPR-049). +1. Two trades with an identical price and size, but in separate markets using assets with different quantum values, should increment a parties `party_epoch_notional_taker_volume` by the same amount (0083-RFPR-049). 1. At the end of the epoch, the `referral_set_epoch_notional_taker_volume` should be correctly calculated by summing each team members `party_epoch_notional_taker_volume` (0083-RFPR-033). 1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` to their sets `referral_set_epoch_notional_taker_volume` (0083-RFPR-034). 1. If `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` is updated during an epoch, the new value should be used to cap party contributions to referral sets **at the end o00f the epoch** (i.e. a parties individual `party_epoch_notional_taker_volume` should not be capped during the epoch) (0083-RFPR-050). From a6c3d029af22fea09ef1704d587bc1fc23e39ed5 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 21 Sep 2023 12:42:16 +0100 Subject: [PATCH 598/649] refactor: clarify 0083-RFPR-049 --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 4eaae4d48..d17d80e4f 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -468,7 +468,7 @@ The Estimate Fees API should now calculate the following additional information: 1. Each trade in which a party is the "maker" **should not** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-048). 1. Each trade in which a party is the "taker" **should** increment the taker parties `party_epoch_notional_taker_volume` by the volume of the trade (expressed in quantum units) (0083-RFPR-031). 1. A trade generated during auction uncrossing should not contribute to either parties `party_epoch_notional_taker_volume` (0083-RFPR-032). -1. Two trades with an identical price and size, but in separate markets using assets with different quantum values, should increment a parties `party_epoch_notional_taker_volume` by the same amount (0083-RFPR-049). +1. A trader is the taker of two prices in separate markets using settlement assets with different quantum values. Each trades value should be scaled correctly by the assets quantum and added to the parties `party_epoch_notional_taker_volume` (0083-RFPR-049). 1. At the end of the epoch, the `referral_set_epoch_notional_taker_volume` should be correctly calculated by summing each team members `party_epoch_notional_taker_volume` (0083-RFPR-033). 1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` to their sets `referral_set_epoch_notional_taker_volume` (0083-RFPR-034). 1. If `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` is updated during an epoch, the new value should be used to cap party contributions to referral sets **at the end o00f the epoch** (i.e. a parties individual `party_epoch_notional_taker_volume` should not be capped during the epoch) (0083-RFPR-050). From 7211b8019d9c75f12afe3f24c16647049cc7bdcc Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Fri, 22 Sep 2023 13:33:21 +0100 Subject: [PATCH 599/649] fix: 0044-LIME-003 effect after epoch end (#1968) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 0841732fa..1e2815f50 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -302,7 +302,7 @@ Note: - REST (0044-LIME-059) - When a LP commits liquidity on market 1, on market 2 this LP has no liquidity commitment when I request for all LP provisions through `ListLiquidityProvisions` api for this party, then only LP provisions for market 1 is returned. (0044-LIME-087) - The [bond slashing](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature) works as the feature test claims. (0044-LIME-002). -- Change of network parameter `market.liquidity.bondPenaltyParameter` will immediately change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) +- Change of network parameter `market.liquidity.bondPenaltyParameter` will, as soon as the current epoch ends, change the amount by which the bond account will be 'slashed' when a liquidity provider has insufficient capital for Vega to make the transfers for their mark to market or other settlement movements, and/or margin requirements arising from their orders and open positions. (0044-LIME-003) - Change of `market.liquidity.maximumLiquidityFeeFactorLevel` will change the maximum liquidity fee factor. Any new submission or amendments must respect the new maximum (those that don't get rejected). (0044-LIME-006) - Check that bond slashing works with non-default asset decimals, market decimals, position decimals. This can be done by following a similar story to [bond slashing feature test](https://github.com/vegaprotocol/vega/blob/develop/core/integration/features/verified/liquidity-provision-bond-account.feature). Should test at least three different combinations, each decimal settings different to each other. (0044-LIME-009) - If `market.liquidity.stakeToCcyVolume` is set to `0.0`, there is [target stake](./0041-TSTK-target_stake.md) of `1000` and there are 3 LPs on the market with stake / fee bid submissions of `100, 0.01`, `1000, 0.02` and `200, 0.03` then the liquidity fee is `0.02`. (0044-LIME-012) From ec6574639a2211c3d0aa7a22ebbbbb974b0e11a9 Mon Sep 17 00:00:00 2001 From: David Siska <62546419+davidsiska-vega@users.noreply.github.com> Date: Mon, 25 Sep 2023 12:59:29 +0100 Subject: [PATCH 600/649] fix: link (#1954) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0013-ACCT-accounts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index 347abb9a7..dcb70b47f 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -75,7 +75,7 @@ If there is a positive balance in an account that is being deleted, that balance ## Bond accounts -Bond accounts are opened when a party opens a [Liquidity Provision order](./0044-LIME-lp_mechanics.mdd). The bond is held by the network to ensure that the Liquidity Provider meets their SLA obligations. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. +Bond accounts are opened when a party opens a [Liquidity Provision order](./0044-LIME-lp_mechanics.md). The bond is held by the network to ensure that the Liquidity Provider meets their SLA obligations. [0044-LIME - LP Mechanics](./0044-LIME-lp_mechanics.md) contains more detail on bond management. ## Market insurance pools From ef47d7fd64f7fafd04ccb424ac8b13c7c3833047 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 25 Sep 2023 14:38:27 +0100 Subject: [PATCH 601/649] chore: align closing_timestamp to end_of_program_timestamp --- protocol/0083-RFPR-on_chain_referral_program.md | 16 ++++++++-------- protocol/0084-VDPR-volume_discount_program.md | 16 ++++++++-------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index d17d80e4f..e5d99334b 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -51,7 +51,7 @@ Enabling or changing the terms of the on-chain referral program can be proposed - `staking_tiers`: a list of dictionaries (with the below fields) defining the multipliers from staking - `minimum_staked_tokens`: the required number of governance tokens ($VEGA) a referrer must be staking to receive the multiplier - `referral_reward_multiplier`: the multiplier applied to the referral_reward_factor when calculating referral rewards due to the referrer. -- `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled +- `end_of_program_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled - `window_length`: the number of epochs over which to evaluate a referral sets running notional taker volume ```protobuf @@ -91,7 +91,7 @@ message UpdateReferralProgram{ "referral_reward_multiplier": 2, } ], - closing_timestamp: 123456789, + end_of_program_timestamp: 123456789, window_length: 7, } } @@ -99,7 +99,7 @@ message UpdateReferralProgram{ When submitting a referral program proposal through governance the following conditions apply: -- a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. +- a proposer cannot set an `end_of_program_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers`. - all `minimum_epochs` values must be an integer strictly greater than 0 - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. @@ -120,7 +120,7 @@ After a referral program [proposal](#governance-proposals) is validated and acce | `STATUS_INACTIVE` | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | | `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | | `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | -| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | +| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `end_of_program_timestamp` | ## Referral set mechanics @@ -401,18 +401,18 @@ The Estimate Fees API should now calculate the following additional information: ### Governance Proposals 1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - - the `closing_timestamp` must be less than or equal to the proposals `enactment_time` (0083-RFPR-001). + - the `end_of_program_timestamp` must be less than or equal to the proposals `enactment_time` (0083-RFPR-001). - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers` (0083-RFPR-002). - all `minimum_epochs_in_team` values must be an integer strictly greater than 0 (0083-RFPR-003). - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` (0083-RFPR-004). - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor` (0083-RFPR-005). - the `window_length` must be an integer strictly greater than zero (0083-RFPR-006). 1. A referral program should be started the first epoch change after the `enactment_datetime` is reached (0083-RFPR-007). -1. A referral program should be closed the first epoch change after the `closing_timestamp` is reached (0083-RFPR-008). +1. A referral program should be closed the first epoch change after the `end_of_program_timestamp` is reached (0083-RFPR-008). 1. If a referral program is already active and a proposal `enactment_datetime` is reached, the referral program is updated at the next epoch change. - - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec (0083-RFPR-009). + - Propose program A with `enactment_timestamp` 1st Jan and `end_of_program_timestamp` 31st Dec (0083-RFPR-009). - Proposal for program A accepted and begins first epoch after 1st Jan (0083-RFPR-010). - - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug (0083-RFPR-011). + - Propose program B with `enactment_timestamp` 1st June and `end_of_program_timestamp` 31st Aug (0083-RFPR-011). - Proposal for program B accepted and overrides program A the first epoch after 1st June (0083-RFPR-012). - Program is closed first epoch after 31st Aug, there should be no active proposals (0083-RFPR-013). 1. Updating any of the following network parameters whilst there is an active referral program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future referral program proposals. diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index a1d004666..fd3dfd3d6 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -18,7 +18,7 @@ Enabling or changing the terms of the volume discount program can be proposed vi - `benefit_tiers`: a list of dictionaries with the following fields - `minimum_party_running_notional_taker_volume`: the required `party_running_notional_taker_volume` in quantum units for a party to access this tier - `volume_discount_factor`: the proportion of the referees taker fees to be rewarded to the referrer -- `closing_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled. If this field is empty, the program runs indefinitely. +- `end_of_program_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled. If this field is empty, the program runs indefinitely. - `window_length`: the number of epochs over which to evaluate a parties notional running volume ```protobuf @@ -38,7 +38,7 @@ message UpdateVolumeDiscountProgram{ "volume_discount_factor": 0.003, }, ], - closing_timestamp: 123456789, + end_of_program_timestamp: 123456789, window_length: 7, } } @@ -46,7 +46,7 @@ message UpdateVolumeDiscountProgram{ When submitting a volume discount program proposal through governance the following conditions apply: -- a proposer cannot set an `closing_timestamp` less than the proposals `enactment_time`. +- a proposer cannot set an `end_of_program_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers`. - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor`. - `window_length` must be an integer strictly greater than zero. @@ -62,7 +62,7 @@ After a volume discount program [proposal](#governance-proposals) is validated a | `STATUS_INACTIVE` | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | | `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | | `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | -| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `closing_timestamp` | +| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `end_of_program_timestamp` | ## Benefit Mechanics @@ -123,16 +123,16 @@ The Trades API should now also expose the following additional information for e ### Governance Proposals 1. If an `UpdateVolumeDiscount` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - - the `closing_timestamp` must be less than or equal to the proposals `enactment_time` (0084-VDPR-001). + - the `end_of_program_timestamp` must be less than or equal to the proposals `enactment_time` (0084-VDPR-001). - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers` (0084-VDPR-002). - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxReferralRewardFactor` (0084-VDPR-003). - the `window_length` must be an integer strictly greater than zero (0084-VDPR-004). 1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached (0084-VDPR-005). -1. A volume discount program should be closed the first epoch change after the `closing_timestamp` is reached (0084-VDPR-006). +1. A volume discount program should be closed the first epoch change after the `end_of_program_timestamp` is reached (0084-VDPR-006). 1. If a volume discount program is already active and a proposal `enactment_datetime` is reached, the volume discount program is updated at the next epoch change. - - Propose program A with `enactment_timestamp` 1st Jan and `closing_timestamp` 31st Dec (0084-VDPR-007). + - Propose program A with `enactment_timestamp` 1st Jan and `end_of_program_timestamp` 31st Dec (0084-VDPR-007). - Proposal for program A accepted and begins first epoch after 1st Jan (0084-VDPR-008). - - Propose program B with `enactment_timestamp` 1st June and `closing_timestamp` 31st Aug (0084-VDPR-009). + - Propose program B with `enactment_timestamp` 1st June and `end_of_program_timestamp` 31st Aug (0084-VDPR-009). - Proposal for program B accepted and overrides program A the first epoch after 1st June (0084-VDPR-010). - Program is closed first epoch after 31st Aug, there should be no active proposals (0084-VDPR-011). 1. Updating any of the following network parameters whilst there is an active volume discount program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future volume discount program proposals. From 5b3bbb9a114971a9211aca26993361878b9fcce2 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 25 Sep 2023 14:59:03 +0100 Subject: [PATCH 602/649] chore: update GOVE-140 to clarify reward account types update AC GOVE-140 to clarify reward account types and exclude metric based rewards from the referral feature --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index ce85431a8..370d9ce1c 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -654,7 +654,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo ##### One Off Delivery transfers If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. (0028-GOVE-129) -It is possible to submit a one off governance transfer proposal from network treasury into any reward account (including staking rewards). (0028-GOVE-140) +It is possible to submit a one off governance transfer proposal from network treasury into any non-metric based reward account (including staking rewards). (0028-GOVE-140) It is possible to submit a one off governance transfer proposal from market's insurance pool into any reward account (including staking rewards). (0028-GOVE-141) It is NOT possible to submit a governance proposal where the source account is the reward account. (0028-GOVE-144) From 04d772cb3dbbbcc4bda2c4416ddb62b2b230c5b7 Mon Sep 17 00:00:00 2001 From: Matthew Pendrey Date: Mon, 25 Sep 2023 17:05:41 +0100 Subject: [PATCH 603/649] fix: update gov spec 141 (#1974) --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 370d9ce1c..ee95c5f21 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -655,7 +655,7 @@ Below `*` stands for any of `asset, market, updateMarket, updateNetParam, freeFo If the proposal is one off it can define a time for delivery. Whenever the block time is after the delivery time, the transfer will execute. If there is no delivery time the one off transfer will execute immediately. (0028-GOVE-129) It is possible to submit a one off governance transfer proposal from network treasury into any non-metric based reward account (including staking rewards). (0028-GOVE-140) -It is possible to submit a one off governance transfer proposal from market's insurance pool into any reward account (including staking rewards). (0028-GOVE-141) +It is possible to submit a one off governance transfer proposal from market's insurance pool into any non-metric based reward account (including staking rewards). (0028-GOVE-141) It is NOT possible to submit a governance proposal where the source account is the reward account. (0028-GOVE-144) ##### Recurring governance initiated transfers From 41824f167b77de8b6c231bacf95a3e8ae7f4c89d Mon Sep 17 00:00:00 2001 From: MuthuVega <91467655+MuthuVega@users.noreply.github.com> Date: Tue, 26 Sep 2023 10:30:53 +0100 Subject: [PATCH 604/649] chore: Update acceptance criteria to match implementation (#1967) --- protocol/0082-ETHD-ethereum-data-source.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0082-ETHD-ethereum-data-source.md b/protocol/0082-ETHD-ethereum-data-source.md index b60fac93f..4cb4bb620 100644 --- a/protocol/0082-ETHD-ethereum-data-source.md +++ b/protocol/0082-ETHD-ethereum-data-source.md @@ -143,7 +143,7 @@ Select { 6. Ethereum oracle data sources should only forward data after a configurable number of confirmations (0082-ETHD-020) 7. Create 2 markets to use the same ethereum oracle for termination say DS-T1 but two different ethereum oracles for settlement DS-S1 and DS-S2. Now trigger the termination ethereum oracle data source. Both markets should be terminated and the data source DS-T1 is set to DEACTIVATED and the data sources DS-S1 and DS-S2 are still ACTIVE. Now settle market1. DS-S1 is set to DEACTIVATED and DS-S2 is still active. (0082-ETHD-021) 8. Create a market to use an ethereum oracle for termination configured such that - it expects a boolean value True for termination and the contract supplying the termination value is polled every 5 seconds. Set the contract to return False for termination. The market is not terminated. The data source is still ACTIVE and no BUS_EVENT_TYPE_ORACLE_DATA events for that ethereum oracle spec are emitted. Then set the contract to return True for termination. The market is terminated and an event for BUS_EVENT_TYPE_ORACLE_DATA for the ethereum oracle data spec is received and the ethereum oracle is set to DEACTIVATED. (0082-ETHD-022) -9. Only one oracle data event is emitted for data that matches multiple data sources - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 300. One single event BUS_EVENT_TYPE_ORACLE_DATA for the settlement data is emitted with both matching ethereum oracle data sources listed within the event. Both markets are settled and both the data sources are DEACTIVATED. (0082-ETHD-023) +9. One oracle data event is emitted for data that matches each data source - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 300. One single event BUS_EVENT_TYPE_ORACLE_DATA for the settlement data is emitted for each matching ethereum oracle data sources i.e. in this case, two oracle data events will be emitted - one for each settlement data source. Both markets are settled and both the data sources are DEACTIVATED. (0082-ETHD-023) 10. Different oracle data events for multiple spec id's with non matching filter values - Create 2 markets with ethereum oracle settlement specs that use the same settlement key such that - the first settlement spec expects settlement data to be greater than 100 and the second expects greater than 200. Now send it a settlement data of 50. NO data events for BUS_EVENT_TYPE_ORACLE_DATA. Send settlement data of 150. One single event BUS_EVENT_TYPE_ORACLE_DATA emitted for the settlement data is emitted with matching ethereum oracle data spec for Market1, market1 is settled and the data source is set to DEACTIVATED. Send settlement data of 250. One single event BUS_EVENT_TYPE_ORACLE_DATA emitted for the settlement data is emitted with matching ethereum oracle data spec for Market2, Market2 is settled and the data source is set to DEACTIVATED. (0082-ETHD-024) 11. Network wide contract error should be reported via oracle data events (0082-ETHD-025) 12. Different contracts on different markets - Create 2 markets with ethereum oracle settlement data sources containing different contract addresses and with *different* settlement keys, but with all conditions and filters the same. Confirm that sending settlement value that passes the market spec filter only settles one market. (0082-ETHD-050) From dfd5bafac23a9ce18fe3ce60d6aa8c345470072b Mon Sep 17 00:00:00 2001 From: Tom Date: Tue, 26 Sep 2023 13:09:18 +0100 Subject: [PATCH 605/649] feat: Remove mention of market value proxy (#1975) --- protocol/0042-LIQF-setting_fees_and_rewarding_lps.md | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md index da1321231..0d66ef6d8 100644 --- a/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md +++ b/protocol/0042-LIQF-setting_fees_and_rewarding_lps.md @@ -299,7 +299,6 @@ Each LP further gets a performance bonus: $b_i \times B$ with a transfer type th - Each liquidity provider's equity-like share - Each liquidity provider's average entry valuation -- The `market-value-proxy` ## Acceptance Criteria From 44b5a0a646b9d8efb353398202cde1dca45a05cf Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Tue, 26 Sep 2023 13:54:45 +0100 Subject: [PATCH 606/649] Update 0044-LIME-lp_mechanics.md (#1976) min value for market.liquidity.performanceHysteresisEpochs valid is 0 --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 1e2815f50..8ddae48ef 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -429,5 +429,5 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidity.commitmentMinTimeFraction` valid values: `>=0`, `<=1` (0044-LIME-083) - `market.liquidity.priceRange` valid values: `>0`, `<=20` (0044-LIME-084) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-085) - - `market.liquidity.performanceHysteresisEpochs` valid values: `>=1`, `<=366` (0044-LIME-086) + - `market.liquidity.performanceHysteresisEpochs` valid values: `>=0`, `<=366` (0044-LIME-086) From acf8191b616b8e0c0d49b839e5c8c89d0ffceb2c Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 26 Sep 2023 16:03:10 +0100 Subject: [PATCH 607/649] chore: correct typos --- protocol/0084-VDPR-volume_discount_program.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index fd3dfd3d6..b9710c3b4 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -23,7 +23,7 @@ Enabling or changing the terms of the volume discount program can be proposed vi ```protobuf message UpdateVolumeDiscountProgram{ - changes: UpdateReferralProgramConfiguration{ + changes: UpdateVolumeDiscountProgramConfiguration{ benefit_tiers: [ { "minimum_party_running_notional_taker_volume": 1000, @@ -125,7 +125,7 @@ The Trades API should now also expose the following additional information for e 1. If an `UpdateVolumeDiscount` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - the `end_of_program_timestamp` must be less than or equal to the proposals `enactment_time` (0084-VDPR-001). - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers` (0084-VDPR-002). - - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxReferralRewardFactor` (0084-VDPR-003). + - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor` (0084-VDPR-003). - the `window_length` must be an integer strictly greater than zero (0084-VDPR-004). 1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached (0084-VDPR-005). 1. A volume discount program should be closed the first epoch change after the `end_of_program_timestamp` is reached (0084-VDPR-006). From a769af296d362db9616175c15dfc0d584e918ba0 Mon Sep 17 00:00:00 2001 From: Charlie Date: Tue, 26 Sep 2023 16:06:31 +0100 Subject: [PATCH 608/649] chore: align protos with core implementation --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- protocol/0084-VDPR-volume_discount_program.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index e5d99334b..3147e659b 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -56,7 +56,7 @@ Enabling or changing the terms of the on-chain referral program can be proposed ```protobuf message UpdateReferralProgram{ - changes: UpdateReferralProgramConfiguration{ + changes: ReferralProgram{ benefit_tiers: [ { "minimum_running_notional_taker_volume": 10000, diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index b9710c3b4..fb7c357aa 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -23,7 +23,7 @@ Enabling or changing the terms of the volume discount program can be proposed vi ```protobuf message UpdateVolumeDiscountProgram{ - changes: UpdateVolumeDiscountProgramConfiguration{ + changes: VolumeDiscountProgram{ benefit_tiers: [ { "minimum_party_running_notional_taker_volume": 1000, From d177237cecdbb1df82ff90b02b1a8fe4b735a0c2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 27 Sep 2023 09:24:58 +0100 Subject: [PATCH 609/649] feat: remove legacy ac --- protocol/0083-RFPR-on_chain_referral_program.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 3147e659b..4a9bafe95 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -419,8 +419,6 @@ The Estimate Fees API should now calculate the following additional information: - `referralProgram.maxReferralTiers` (0083-RFPR-041) - `referralProgram.maxReferralRewardFactor` (0083-RFPR-042) - `referralProgram.maxReferralDiscountFactor` (0083-RFPR-043) - - `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` (0083-RFPR-044) - - `referralProgram.minStakedVegaTokens` (0083-RFPR-045) ### Referral set mechanics @@ -471,7 +469,7 @@ The Estimate Fees API should now calculate the following additional information: 1. A trader is the taker of two prices in separate markets using settlement assets with different quantum values. Each trades value should be scaled correctly by the assets quantum and added to the parties `party_epoch_notional_taker_volume` (0083-RFPR-049). 1. At the end of the epoch, the `referral_set_epoch_notional_taker_volume` should be correctly calculated by summing each team members `party_epoch_notional_taker_volume` (0083-RFPR-033). 1. A party cannot contribute more than the current network parameter `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` to their sets `referral_set_epoch_notional_taker_volume` (0083-RFPR-034). -1. If `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` is updated during an epoch, the new value should be used to cap party contributions to referral sets **at the end o00f the epoch** (i.e. a parties individual `party_epoch_notional_taker_volume` should not be capped during the epoch) (0083-RFPR-050). +1. If `referralProgram.maxPartyNotionalVolumeByQuantumPerEpoch` is updated during an epoch, the new value should be used to cap party contributions to referral sets **at the end of the epoch** (i.e. a parties individual `party_epoch_notional_taker_volume` should not be capped during the epoch) (0083-RFPR-050). 1. A referral sets `referral_set_running_notional_taker_volume` is calculated as the sum of all `referral_set_epoch_notional_taker_volumes` over the last `epoch_window` epochs (0083-RFPR-035). ### Benefit Mechanics From ca85780b061d099caa506a8ba3d9f7f55a096d2e Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 27 Sep 2023 09:29:22 +0100 Subject: [PATCH 610/649] fix: update features --- protocol/features.json | 2 -- 1 file changed, 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index b1e3e262d..9f7d6e4ef 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -423,8 +423,6 @@ "0083-RFPR-041", "0083-RFPR-042", "0083-RFPR-043", - "0083-RFPR-044", - "0083-RFPR-045", "0083-RFPR-046", "0083-RFPR-047", "0083-RFPR-048", From d88affe3d08b8f7e8963bea381014dddc3135ef3 Mon Sep 17 00:00:00 2001 From: Sohill-Patel <85170301+Sohill-Patel@users.noreply.github.com> Date: Wed, 27 Sep 2023 12:51:31 +0100 Subject: [PATCH 611/649] chore: add staking tiers --- protocol/0083-RFPR-on_chain_referral_program.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 4a9bafe95..2b1ec2713 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -28,7 +28,7 @@ Note, if a referee wants to compete as a member of a different team, they are ab ## Network Parameters -- `referralProgram.maxReferralTiers` - limits the maximum number of [benefit tiers](#governance-proposals) which can be specified as part of a referral program +- `referralProgram.maxReferralTiers` - limits the maximum number of [benefit tiers](#governance-proposals) and [staking tiers](#governance-proposals) which can be specified as part of a referral program - `referralProgram.maxReferralRewardFactor` - limits the maximum reward factor which can be specified as part of a referral program - `referralProgram.maxReferralDiscountFactor` - limits the maximum discount factor which can be specified as part of a referral program governance proposal - `referralProgram.maxReferralRewardProportion` - limits the proportion (`referee_reward_factor` * `referee_reward_multiplier`) of referee taker fees which can be given to the referrer. From c5429357a2c94712d128d7d2648e3b22ba724f81 Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Thu, 28 Sep 2023 13:21:05 +0100 Subject: [PATCH 612/649] Update features.json to align milestone names (#1982) Updates features.json to align milestone names and report out correctly --- protocol/features.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 9f7d6e4ef..8c952866e 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -456,7 +456,7 @@ ] }, "Rewards": { - "milestone": "cosmic-elevator-2", + "milestone": "deployment-2", "acs": [ "0085-RVST-001", "0085-RVST-002", @@ -869,4 +869,4 @@ "milestone": "unknown", "acs": [] } -} \ No newline at end of file +} From 25edc5d67ad2c50ffb6dcf97cd5711acbc92f41b Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Sep 2023 15:31:06 +0100 Subject: [PATCH 613/649] chore: align spec with core implementation --- protocol/0056-REWA-rewards_overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 1972db3d0..d66cd5796 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -111,13 +111,13 @@ $$m_{rr} = \max(\frac{\sum_{i}^{n}{r_{i}}}{N}, 0)$$ The return volatility metric, $m_{rv}$, measures the volatility of a parties returns across a number of epochs. -At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the window length specified in the recurring transfer), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the standard deviation of the set of each parties returns over the last $N$ epochs. +At the end of an epoch, if a party has had net returns less than or equal to `0` over the last $N$ epochs (where $N$ is the window length specified in the recurring transfer), their reward metric $m_{rv}$ is set to `0`. Otherwise, the network should calculate the variance of the set of each parties returns over the last $N$ epochs. Given the set: $$R = \{r_i \mid i = 1, 2, \ldots, N\}$$ -The reward metric $m_{rv}$ is the standard deviation of the set $R$. +The reward metric $m_{rv}$ is the variance of the set $R$. ### Validator ranking metric From 401621b227144c3b3e4f8053f2f88f1f0a96fbad Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Sep 2023 16:08:33 +0100 Subject: [PATCH 614/649] feat: add AC to cover october reward features --- protocol/0056-REWA-rewards_overview.md | 37 ++++++++++++++++++++++++++ protocol/features.json | 21 ++++++++++++++- 2 files changed, 57 insertions(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index d66cd5796..393a45090 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -966,3 +966,40 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - The general account balance of the `ETHUSDT` creator should be 10000. - The reward pool balance should be 0. + +### Reward Eligibility + +- If a parties staked governance tokens ($VEGA) is strictly less than the `staking_requirement` specified in the recurring transfer funding the reward pool, then their reward metric should be `0` and they should receive no rewards (0056-REWA-076). +- If a parties time-weighted average position (across all in scope-markets) is strictly less than the `notional_time_weighted_average_position_requirement` specified in the recurring transfer funding the reward pool, then their reward metric should be `0` and they should receive no rewards (0056-REWA-077). + +### Average Position + +- If an eligible party opens a position at the beginning of the epoch, their average position reward metric should be equal to the size of the position at the end of the epoch (0056-REWA-078). +- If an eligible party held an open position at the start of the epoch, their average position reward metric should be equal to the size of the position at the end of the epoch (0056-REWA-079). +- If an eligible party opens a position half way through the epoch, their average position reward metric should be half the size of the position at the end of the epoch (0056-REWA-080). +- If an eligible party held an open position at the start of the epoch and closes it half-way through the epoch, their average position reward metric should be equal to the size of that position at the end of the epoch (0056-REWA-081). +- If an eligible party held positions in multiple in-scope markets, their average position reward metric should be the sum of the size of their time-weighted-average-position in each market (0056-REWA-082). +- If a `window_length>1` is specified in the recurring transfer, an eligible parties average position reward metric should be the average of their reward metrics over the last `window_length` epochs (0056-REWA-083). + +### Relative returns + +- If an eligible party has negative net returns, their relative returns reward metric should be zero (0056-REWA-084). +- If an eligible party has positive net returns, their relative returns reward metric should be equal to the size of their returns divided by their time-weighted average position (0056-REWA-085). +- If an eligible party has positive net returns in multiple in-scope markets, their relative returns reward metric should be the sum of their relative returns in each market (0056-REWA-086). +- If a `window_length>1` is specified in the recurring transfer, an eligible parties relative returns reward metric should be the average of their reward metrics over the last `window_length` epochs (0056-REWA-087). + +### Returns volatility + +- If an eligible party has net relative returns less than or equal to `0` over the last `window_length` epochs, their returns volatility reward metric should be zero (0056-REWA-088). +- If an eligible party has net relative returns strictly greater than `0` over the last `window_length` epochs, their returns volatility reward metric should equal the variance of their relative returns over the last `window_length` epochs (0056-REWA-089). +- If an eligible party has net relative returns strictly greater than `0` over the last `window_length` epochs in multiple in-scope markets, their relative returns reward metric should be the variance of their relative returns in each market (0056-REWA-090). + +### Validator ranking metric + +- If a party is a consensus or standby validator their validator ranking reward metric should be set to their ranking score (0056-REWA-091). +- If a party is not a consensus or standby validator their validator ranking reward metric should be set to `0` (0056-REWA-092). + +### Distribution Strategy + +- If the pro-rata distribution strategy was specified in the recurring transfer, each eligible parties share of the rewards pool should be equal to their reward metric (assuming no other multipliers) (0056-REWA-093). +- If the rank distribution strategy was specified in the recurring transfer, each eligible parties share of the reward pool should be equal to the `share_ratio` defined by their position in the `rank_table` (assuming no other multipliers) (0056-REWA-094). diff --git a/protocol/features.json b/protocol/features.json index 8c952866e..80050c43b 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -481,7 +481,26 @@ "0086-ASPR-007", "0086-ASPR-008", "0086-ASPR-009", - "0086-ASPR-010" + "0086-ASPR-010", + "0056-REWA-076", + "0056-REWA-077", + "0056-REWA-078", + "0056-REWA-079", + "0056-REWA-080", + "0056-REWA-081", + "0056-REWA-082", + "0056-REWA-083", + "0056-REWA-084", + "0056-REWA-085", + "0056-REWA-086", + "0056-REWA-087", + "0056-REWA-088", + "0056-REWA-089", + "0056-REWA-090", + "0056-REWA-091", + "0056-REWA-092", + "0056-REWA-093", + "0056-REWA-094" ] }, "Market governance": { From e1a009f333696532754695f8834874b0c6396017 Mon Sep 17 00:00:00 2001 From: Charlie Date: Fri, 22 Sep 2023 16:39:57 +0100 Subject: [PATCH 615/649] fix: correct for markdownlint --- protocol/0056-REWA-rewards_overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 393a45090..56229cf19 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -981,7 +981,7 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If an eligible party held positions in multiple in-scope markets, their average position reward metric should be the sum of the size of their time-weighted-average-position in each market (0056-REWA-082). - If a `window_length>1` is specified in the recurring transfer, an eligible parties average position reward metric should be the average of their reward metrics over the last `window_length` epochs (0056-REWA-083). -### Relative returns +### Relative returns - If an eligible party has negative net returns, their relative returns reward metric should be zero (0056-REWA-084). - If an eligible party has positive net returns, their relative returns reward metric should be equal to the size of their returns divided by their time-weighted average position (0056-REWA-085). From 1d9b60c9f825e7d239d2bb3b3dead61435d05861 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 25 Sep 2023 15:23:12 +0100 Subject: [PATCH 616/649] refactor: correct AC behaviour --- protocol/0056-REWA-rewards_overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 56229cf19..b12794462 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -985,7 +985,7 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If an eligible party has negative net returns, their relative returns reward metric should be zero (0056-REWA-084). - If an eligible party has positive net returns, their relative returns reward metric should be equal to the size of their returns divided by their time-weighted average position (0056-REWA-085). -- If an eligible party has positive net returns in multiple in-scope markets, their relative returns reward metric should be the sum of their relative returns in each market (0056-REWA-086). +- If an eligible party is participating in multiple in-scope markets, their relative returns reward metric should be the sum of their relative returns from each market (0056-REWA-086). - If a `window_length>1` is specified in the recurring transfer, an eligible parties relative returns reward metric should be the average of their reward metrics over the last `window_length` epochs (0056-REWA-087). ### Returns volatility From 9b2d3a434d2c2fde99a915970362e7307408613e Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 28 Sep 2023 09:39:31 +0100 Subject: [PATCH 617/649] chore: correct typo --- protocol/0056-REWA-rewards_overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index b12794462..180a31680 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -992,7 +992,7 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If an eligible party has net relative returns less than or equal to `0` over the last `window_length` epochs, their returns volatility reward metric should be zero (0056-REWA-088). - If an eligible party has net relative returns strictly greater than `0` over the last `window_length` epochs, their returns volatility reward metric should equal the variance of their relative returns over the last `window_length` epochs (0056-REWA-089). -- If an eligible party has net relative returns strictly greater than `0` over the last `window_length` epochs in multiple in-scope markets, their relative returns reward metric should be the variance of their relative returns in each market (0056-REWA-090). +- If an eligible party has net relative returns strictly greater than `0` over the last `window_length` epochs in multiple in-scope markets, their return volatility reward metric should be the variance of their relative returns in each market (0056-REWA-090). ### Validator ranking metric From cb701a836fd6d111c3b6d5b8c939f42bcd9b090e Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 27 Sep 2023 09:10:56 +0100 Subject: [PATCH 618/649] feat: add spam rules for referral program --- protocol/0062-SPAM-spam_protection.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 58f775b1b..da170a395 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -80,6 +80,20 @@ The minimum allowed withdrawal amount is `spam.protection.minimumWithdrawalQuant Any withdrawal request for a smaller amount is immediately rejected. +### Referral spam + +The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds three transaction types which can be submitted with no cost/risk to the party: + +- `CreateReferralSet` +- `UpdateReferralSet` +- `ApplyReferralCode` + +To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a party must meet the staked governance tokens ($VEGA) threshold set by the network parameter `referralProgram.minStakedVegaTokens`. A party who does not meet this requirement should have any transactions of the aforementioned types pre-block rejected. + +To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. + +Further, all referral transactions are limited to `n` submissions per epoch per party where n is controlled by the network parameter `spam.protection.max.referrals`. Any party who submits more then `n` of a single referral transaction type should have their transactions pre-block rejected. + ### Related topics - [Spam protection: Proof of work](https://github.com/vegaprotocol/specs/blob/master/protocol/0072-SPPW-spam-protection-PoW.md) @@ -117,5 +131,11 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) - Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) - Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-PALAZZO-001) +- A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). +- A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). +- A party who has less then `spam.protection.applyReferral.min.funds` deposited across all their accounts. Should have any `ApplyReferralCode` transactions pre-block rejected (0062-SPAM-028). +- A party who has submitted strictly more than `spam.protection.max.referrals` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). +- A party who has submitted strictly more than `spam.protection.max.referrals` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). +- A party who has submitted strictly more than `spam.protection.max.referrals` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-021). > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. From 3e17dde5043d153f5571282be38a55f556124548 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 27 Sep 2023 09:40:04 +0100 Subject: [PATCH 619/649] chore: clarify all assets count towards deposit requirement --- protocol/0062-SPAM-spam_protection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index da170a395..44e00c3fe 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -90,7 +90,7 @@ The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds t To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a party must meet the staked governance tokens ($VEGA) threshold set by the network parameter `referralProgram.minStakedVegaTokens`. A party who does not meet this requirement should have any transactions of the aforementioned types pre-block rejected. -To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. +To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. Further, all referral transactions are limited to `n` submissions per epoch per party where n is controlled by the network parameter `spam.protection.max.referrals`. Any party who submits more then `n` of a single referral transaction type should have their transactions pre-block rejected. @@ -133,7 +133,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-PALAZZO-001) - A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). - A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). -- A party who has less then `spam.protection.applyReferral.min.funds` deposited across all their accounts. Should have any `ApplyReferralCode` transactions pre-block rejected (0062-SPAM-028). +- A party who has less then `spam.protection.applyReferral.min.funds` deposited. Should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). - A party who has submitted strictly more than `spam.protection.max.referrals` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). - A party who has submitted strictly more than `spam.protection.max.referrals` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). - A party who has submitted strictly more than `spam.protection.max.referrals` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-021). From 328d5dfecf3dba1fa9291eb7a9d5770519726e4f Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 27 Sep 2023 09:40:32 +0100 Subject: [PATCH 620/649] feat: add separate netparams for each transaction type --- protocol/0062-SPAM-spam_protection.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 44e00c3fe..4eeea0b2d 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -92,7 +92,7 @@ To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. -Further, all referral transactions are limited to `n` submissions per epoch per party where n is controlled by the network parameter `spam.protection.max.referrals`. Any party who submits more then `n` of a single referral transaction type should have their transactions pre-block rejected. +Further, each referral transactions is limited to `n` submissions per epoch per party where `n` is controlled by the respective network parameter for the transaction (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). Any party who submits more then `n` of a single referral transaction type should have their transactions pre-block rejected. ### Related topics @@ -134,8 +134,8 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). - A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). - A party who has less then `spam.protection.applyReferral.min.funds` deposited. Should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). -- A party who has submitted strictly more than `spam.protection.max.referrals` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). -- A party who has submitted strictly more than `spam.protection.max.referrals` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). -- A party who has submitted strictly more than `spam.protection.max.referrals` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-021). +- A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). +- A party who has submitted strictly more than `spam.protection.max.UpdateReferralSet` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). +- A party who has submitted strictly more than `spam.protection.max.ApplyReferralCode` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-021). > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. From 1b42b3d04a94e1f18de91be63cf311282e649462 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Wed, 27 Sep 2023 09:59:02 +0100 Subject: [PATCH 621/649] refactor: apply suggestion correcting typo Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0062-SPAM-spam_protection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 4eeea0b2d..6570e2f2a 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -136,6 +136,6 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - A party who has less then `spam.protection.applyReferral.min.funds` deposited. Should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). - A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). - A party who has submitted strictly more than `spam.protection.max.UpdateReferralSet` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). -- A party who has submitted strictly more than `spam.protection.max.ApplyReferralCode` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-021). +- A party who has submitted strictly more than `spam.protection.max.ApplyReferralCode` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-031). > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. From 3854ff742288e3af1af99ecc89ad49b86ee3ebfd Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 28 Sep 2023 09:56:14 +0100 Subject: [PATCH 622/649] feat: add snapshot network parameter --- protocol/0062-SPAM-spam_protection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 6570e2f2a..1ce237b14 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -90,7 +90,7 @@ The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds t To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a party must meet the staked governance tokens ($VEGA) threshold set by the network parameter `referralProgram.minStakedVegaTokens`. A party who does not meet this requirement should have any transactions of the aforementioned types pre-block rejected. -To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. +To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. This requirement will be checked against snapshots of account balances taken at a frequency determined by the network parameter `spam.protection.balanceSnapshotFrequency`. This network parameter is a duration (e.g. `5s`, `1m5s`). Further, each referral transactions is limited to `n` submissions per epoch per party where `n` is controlled by the respective network parameter for the transaction (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). Any party who submits more then `n` of a single referral transaction type should have their transactions pre-block rejected. @@ -133,7 +133,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-PALAZZO-001) - A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). - A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). -- A party who has less then `spam.protection.applyReferral.min.funds` deposited. Should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). +- Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.applyReferral.min.funds` in their accounts should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). - A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). - A party who has submitted strictly more than `spam.protection.max.UpdateReferralSet` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). - A party who has submitted strictly more than `spam.protection.max.ApplyReferralCode` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-031). From 292d067d01e4526886cfe882fadcaf29c910bb37 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 2 Oct 2023 18:03:54 +0100 Subject: [PATCH 623/649] feat: update spec with banning mechanics --- protocol/0062-SPAM-spam_protection.md | 17 +++++++++++++---- protocol/features.json | 14 +++++++++++++- 2 files changed, 26 insertions(+), 5 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 1ce237b14..1f336bcc7 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -92,7 +92,9 @@ To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. This requirement will be checked against snapshots of account balances taken at a frequency determined by the network parameter `spam.protection.balanceSnapshotFrequency`. This network parameter is a duration (e.g. `5s`, `1m5s`). -Further, each referral transactions is limited to `n` submissions per epoch per party where `n` is controlled by the respective network parameter for the transaction (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). Any party who submits more then `n` of a single referral transaction type should have their transactions pre-block rejected. +Further, each referral transactions is limited to `n` submissions per epoch per party where `n` is controlled by the respective network parameter for the transaction (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). + +Any party who submits more than `n` transactions of a single referral transaction type in a single epoch will have all future for should have their transactions pre-block rejected.Any party who manages to fit more then `n` of a single referral transaction type into a single block will be banned for 1/48th of an epoch, or un till the end of the current epoch, whichever comes first. ### Related topics @@ -134,8 +136,15 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). - A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). - Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.applyReferral.min.funds` in their accounts should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). -- A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-029). -- A party who has submitted strictly more than `spam.protection.max.UpdateReferralSet` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch pre-block rejected (0062-SPAM-030). -- A party who has submitted strictly more than `spam.protection.max.ApplyReferralCode` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch pre-block rejected (0062-SPAM-031). +- A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-029). +- A party who has submitted more than `spam.protection.max.CreateReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-032). +- A party who has more than 50% of their `CreateReferralSet` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `CreateReferralSet` transactions should be pre-block rejected (0062-SPAM-033). +- A party who has submitted strictly more than `spam.protection.max.updateReferralSet` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-030). +- A party who has submitted more than `spam.protection.max.updateReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-034). +- A party who has more than 50% of their `UpdateReferralSet` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `UpdateReferralSet` transactions should be pre-block rejected (0062-SPAM-035). +- A party who has submitted strictly more than `spam.protection.max.applyReferralSet` `ApplyReferralSet` transactions in an epoch should have any future `ApplyReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-031). +- A party who has submitted more than `spam.protection.max.applyReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-036). +- A party who has more than 50% of their `ApplyReferralSet` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `ApplyReferralSet` transactions should be pre-block rejected (0062-SPAM-037). + > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. diff --git a/protocol/features.json b/protocol/features.json index 80050c43b..195043ab5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -452,7 +452,19 @@ "0029-FEES-028", "0029-FEES-029", "0029-FEES-030", - "0029-FEES-031" + "0029-FEES-031", + "0062-SPAM-026", + "0062-SPAM-027", + "0062-SPAM-028", + "0062-SPAM-029", + "0062-SPAM-030", + "0062-SPAM-031", + "0062-SPAM-032", + "0062-SPAM-033", + "0062-SPAM-034", + "0062-SPAM-035", + "0062-SPAM-036", + "0062-SPAM-037" ] }, "Rewards": { From e6ec9c0b4080ee13a79592eb797465b0bce3ddf1 Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 2 Oct 2023 18:05:51 +0100 Subject: [PATCH 624/649] chore: correct applyReferralCode typo --- protocol/0062-SPAM-spam_protection.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 1f336bcc7..a6583948d 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -142,9 +142,9 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - A party who has submitted strictly more than `spam.protection.max.updateReferralSet` `UpdateReferralSet` transactions in an epoch should have any future `UpdateReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-030). - A party who has submitted more than `spam.protection.max.updateReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-034). - A party who has more than 50% of their `UpdateReferralSet` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `UpdateReferralSet` transactions should be pre-block rejected (0062-SPAM-035). -- A party who has submitted strictly more than `spam.protection.max.applyReferralSet` `ApplyReferralSet` transactions in an epoch should have any future `ApplyReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-031). -- A party who has submitted more than `spam.protection.max.applyReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-036). -- A party who has more than 50% of their `ApplyReferralSet` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `ApplyReferralSet` transactions should be pre-block rejected (0062-SPAM-037). +- A party who has submitted strictly more than `spam.protection.max.applyReferralCode` `ApplyReferralCode` transactions in an epoch should have any future `ApplyReferralCode` transactions in that epoch **pre-block** rejected (0062-SPAM-031). +- A party who has submitted more than `spam.protection.max.applyReferralCode` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-036). +- A party who has more than 50% of their `ApplyReferralCode` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `ApplyReferralCode` transactions should be pre-block rejected (0062-SPAM-037). > **Note**: If other governance functionality (beyond delegation-changes, votes, and proposals) are added, the spec and its acceptance criteria need to be augmented accordingly. This issue will be fixed in a follow up version. From f6cff55b746887e4a7c5916077d9095053fc3ddb Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 2 Oct 2023 18:41:01 +0100 Subject: [PATCH 625/649] feat: clarify rejection and banning mechanisms --- protocol/0062-SPAM-spam_protection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index a6583948d..896a85206 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -92,9 +92,9 @@ To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. This requirement will be checked against snapshots of account balances taken at a frequency determined by the network parameter `spam.protection.balanceSnapshotFrequency`. This network parameter is a duration (e.g. `5s`, `1m5s`). -Further, each referral transactions is limited to `n` submissions per epoch per party where `n` is controlled by the respective network parameter for the transaction (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). +Further, each party is allowed to submit up to `n` transactions per epoch where `n` is controlled by the respective network parameter for that transaction type (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). Any party who submits more than `n` transactions of a single referral transaction type in a single epoch will have all future transactions of that type pre-block rejected. -Any party who submits more than `n` transactions of a single referral transaction type in a single epoch will have all future for should have their transactions pre-block rejected.Any party who manages to fit more then `n` of a single referral transaction type into a single block will be banned for 1/48th of an epoch, or un till the end of the current epoch, whichever comes first. +Any party who manages to fit more then `n` transactions of a single type into a single block will have their excess transactions post-block rejected. A party who has more than 50% of their transactions post-block rejected will be banned for 1/48th of an epoch, or un till the end of the current epoch, whichever comes first. ### Related topics From 1ee1a0a74b958aa014e487bc8b28de8ac10e801b Mon Sep 17 00:00:00 2001 From: Charlie Date: Mon, 2 Oct 2023 18:48:10 +0100 Subject: [PATCH 626/649] feat: remove non-vega restriction --- protocol/0062-SPAM-spam_protection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index 896a85206..f28393472 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -90,7 +90,7 @@ The [on-chain referral program](./0083-RFPR-on_chain_referral_program.md) adds t To avoid spamming of `CreateReferralSet` and `UpdateReferralSet` transactions, a party must meet the staked governance tokens ($VEGA) threshold set by the network parameter `referralProgram.minStakedVegaTokens`. A party who does not meet this requirement should have any transactions of the aforementioned types pre-block rejected. -To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. This requirement will be checked against snapshots of account balances taken at a frequency determined by the network parameter `spam.protection.balanceSnapshotFrequency`. This network parameter is a duration (e.g. `5s`, `1m5s`). +To avoid spamming of `ApplyReferralCode`, a party must meet the deposited funds threshold set by the network parameter `spam.protection.applyReferral.min.funds`. All assets count towards this threshold and balances should be scaled appropriately by the assets quantum. A party who does not meet this requirement should have any transactions of the aforementioned type pre-block rejected. This requirement will be checked against snapshots of account balances taken at a frequency determined by the network parameter `spam.protection.balanceSnapshotFrequency`. This network parameter is a duration (e.g. `5s`, `1m5s`). Further, each party is allowed to submit up to `n` transactions per epoch where `n` is controlled by the respective network parameter for that transaction type (`spam.protection.max.CreateReferralSet`, `spam.protection.max.UpdateReferralSet`, `spam.protection.max.ApplyReferralCode`). Any party who submits more than `n` transactions of a single referral transaction type in a single epoch will have all future transactions of that type pre-block rejected. @@ -135,7 +135,7 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-PALAZZO-001) - A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). - A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). -- Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.applyReferral.min.funds` in their accounts should have any `ApplyReferralCode` transactions pre-block rejected. All non-VEGA assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). +- Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.applyReferral.min.funds` in their accounts should have any `ApplyReferralCode` transactions pre-block rejected. All assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). - A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-029). - A party who has submitted more than `spam.protection.max.CreateReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-032). - A party who has more than 50% of their `CreateReferralSet` transactions post-block rejected should be banned for 1/48th of an epoch or un till the end of the current epoch (whichever comes first). When banned for the above reason, `CreateReferralSet` transactions should be pre-block rejected (0062-SPAM-033). From 0ff709e1fe74776429035f01c8f8c664b677f2cc Mon Sep 17 00:00:00 2001 From: Gordsport <83510148+gordsport@users.noreply.github.com> Date: Tue, 3 Oct 2023 14:43:19 +0100 Subject: [PATCH 627/649] chore: update 0070-MKTD-018 and 19 and add a new AC for exact precision (#1985) * chore: update 0070-MKTD-018 and 19 and add a new AC for exact presision * fix: dupe AC code * chore: make ACs 18 and 19 more valuable * fix: make wording more clear * Update protocol/0070-MKTD-market-decimal-places.md Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --------- Co-authored-by: Jiajia-Cui <92106936+Jiajia-Cui@users.noreply.github.com> --- protocol/0070-MKTD-market-decimal-places.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 2ef3b4f8b..4e1c9e5f6 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -72,9 +72,10 @@ Trades of course result in transfers. The amounts transferred (for the trade as - As a user, I can propose a market with a different precision than its settlement asset - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001). For product spot: (0070-MKTD-016) - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002). For product spot: (0070-MKTD-009) -- As a user, I can propose a perpetual market with a different periodic settlement precision than its settlement asset - - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-018) - - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-019) +- Assert that the settlement calculation can be correctly calculated when: + - settlement data precision is > than the settlement asset precision (i.e. settlement data has more precision (decimal places) than the settlement asset and precision will be lost) (0070-MKTD-018) + - settlement data precision is < than the settlement asset precision (i.e. settlement data has less precision (decimal places) than the settlement asset and no precision will be lost) (0070-MKTD-019) + - settlement data precision is equal to the settlement asset precision (i.e. settlement data has less precision (decimal places) than the settlement asset and no precision will be lost) (0070-MKTD-020) - As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003). For product spot: (0070-MKTD-010) - As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). For product spot: (0070-MKTD-011) - As a user I should see the market data prices using market precision. (0070-MKTD-005). For product spot: (0070-MKTD-012) From a8cf3c6f27dea8b965b8161a44fc6ceb12fa1e96 Mon Sep 17 00:00:00 2001 From: Karel Moravec Date: Tue, 3 Oct 2023 15:53:22 +0200 Subject: [PATCH 628/649] fix: remove specific time from the ACs (#1983) * fix: remove specific time from the ACs * fix: update --- protocol/0084-VDPR-volume_discount_program.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index fb7c357aa..2940718ea 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -130,11 +130,11 @@ The Trades API should now also expose the following additional information for e 1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached (0084-VDPR-005). 1. A volume discount program should be closed the first epoch change after the `end_of_program_timestamp` is reached (0084-VDPR-006). 1. If a volume discount program is already active and a proposal `enactment_datetime` is reached, the volume discount program is updated at the next epoch change. - - Propose program A with `enactment_timestamp` 1st Jan and `end_of_program_timestamp` 31st Dec (0084-VDPR-007). - - Proposal for program A accepted and begins first epoch after 1st Jan (0084-VDPR-008). - - Propose program B with `enactment_timestamp` 1st June and `end_of_program_timestamp` 31st Aug (0084-VDPR-009). - - Proposal for program B accepted and overrides program A the first epoch after 1st June (0084-VDPR-010). - - Program is closed first epoch after 31st Aug, there should be no active proposals (0084-VDPR-011). + - Propose program A with `enactment_timestamp` ET1 and `end_of_program_timestamp` CT1 (0084-VDPR-007). + - Proposal for program A accepted and begins first epoch after ET1 (0084-VDPR-008). + - Propose program B with `enactment_timestamp` ET2 (ET2 > ET1 && ET2 < CT1) and `end_of_program_timestamp` CT1 (CT1 < CT2) (0084-VDPR-009). + - Proposal for program B accepted and overrides program A the first epoch after ET2 (0084-VDPR-010). + - Program is closed first epoch after CT2, there should be no active proposals (0084-VDPR-011). 1. Updating any of the following network parameters whilst there is an active volume discount program will not modify or cancel the active program in any way. The updated parameters will however be used to validate future volume discount program proposals. - `volumeDiscountProgram.maxBenefitTiers` (0084-VDPR-015). - `volumeDiscountProgram.maxVolumeDiscountFactor` (0084-VDPR-016). From 2322c457a09752d14be9ea200190b3ff38a69847 Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 3 Oct 2023 16:29:49 +0100 Subject: [PATCH 629/649] feat: add SLA edge case --- protocol/0044-LIME-lp_mechanics.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 8ddae48ef..9de669e45 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -248,6 +248,9 @@ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, w For spot markets, the transfer is to go into the network treasury account for the asset. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). +In the case of if a liquidity provider has `fraction_of_time_on_book` = `0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then $ +f = \max\left[0,\min\left(m, p\right)\right]\$ + In the case of spot markets the transfer goes into the network treasury account for the asset. ### Penalty for not supporting open positions From 280873f52246387699d66f35d839728dc7ddf19c Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 3 Oct 2023 16:33:21 +0100 Subject: [PATCH 630/649] feat: update format --- protocol/0044-LIME-lp_mechanics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 9de669e45..85e952379 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -248,8 +248,8 @@ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, w For spot markets, the transfer is to go into the network treasury account for the asset. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). -In the case of if a liquidity provider has `fraction_of_time_on_book` = `0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then $ -f = \max\left[0,\min\left(m, p\right)\right]\$ +In the case of if a liquidity provider has `fraction_of_time_on_book` = `0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then +`f = max[0,min(m,p)]` In the case of spot markets the transfer goes into the network treasury account for the asset. From 299ac6cc24e2aa68e7cbfa06597a258f6e6ba8bc Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Tue, 3 Oct 2023 16:34:56 +0100 Subject: [PATCH 631/649] chore: format --- protocol/0044-LIME-lp_mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 85e952379..49d2bdf48 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -248,7 +248,7 @@ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, w For spot markets, the transfer is to go into the network treasury account for the asset. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). -In the case of if a liquidity provider has `fraction_of_time_on_book` = `0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then +In the case of if a liquidity provider has `fraction_of_time_on_book = 0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then `f = max[0,min(m,p)]` In the case of spot markets the transfer goes into the network treasury account for the asset. From 8256f60967486c366a113efbdd1ddd8fe26a508a Mon Sep 17 00:00:00 2001 From: Jiajia-Cui Date: Wed, 4 Oct 2023 08:58:32 +0100 Subject: [PATCH 632/649] chore: remove empty space --- protocol/0044-LIME-lp_mechanics.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 49d2bdf48..291174d44 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -248,8 +248,7 @@ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, w For spot markets, the transfer is to go into the network treasury account for the asset. Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). -In the case of if a liquidity provider has `fraction_of_time_on_book = 0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then -`f = max[0,min(m,p)]` +In the case of if a liquidity provider has `fraction_of_time_on_book = 0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then `f = max[0,min(m,p)]` In the case of spot markets the transfer goes into the network treasury account for the asset. From 669664aebf5656a27ab8bbecf2bf4e7db78a5ee7 Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Wed, 4 Oct 2023 12:05:14 +0100 Subject: [PATCH 633/649] Update 0062-SPAM-spam_protection.md (#1988) param names --- protocol/0062-SPAM-spam_protection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0062-SPAM-spam_protection.md b/protocol/0062-SPAM-spam_protection.md index f28393472..57a715b82 100644 --- a/protocol/0062-SPAM-spam_protection.md +++ b/protocol/0062-SPAM-spam_protection.md @@ -133,8 +133,8 @@ More than 360 delegation changes in one epoch (or, respectively, the value of `s - Increase `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been valid according to the former parameter value is rejected with the new one. (0062-SPAM-023) - Decrease `spam.protection.minimumWithdrawalQuantumMultiple` and verify that a withdrawal transaction that would have been invalid with the old parameter and is valid with the new value and is accepted.(0062-SPAM-024) - Issue a valid withdrawal bundle. Increase `spam.protection.minimumWithdrawalQuantumMultiple` to a value that would no longer allow the creation of the bundle. Ask for the bundle to be re-issued and verify that it's not rejected. (0062-PALAZZO-001) -- A party staking less than `referralProgram.minStakedTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). -- A party staking less than `referralProgram.minStakedTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). +- A party staking less than `referralProgram.minStakedVegaTokens` should have any `CreateReferralSet` transactions pre-block rejected (0062-SPAM-026). +- A party staking less than `referralProgram.minStakedVegaTokens` should have any `UpdateReferral` transactions pre-block rejected (0062-SPAM-027). - Given longer than `spam.protection.balanceSnapshotFrequency` has elapsed since a party deposited or transferred funds, a party who has less then `spam.protection.applyReferral.min.funds` in their accounts should have any `ApplyReferralCode` transactions pre-block rejected. All assets count towards this threshold and balances should be scaled appropriately by the assets quantum. (0062-SPAM-028). - A party who has submitted strictly more than `spam.protection.max.CreateReferralSet` `CreateReferralSet` transactions in an epoch should have any future `CreateReferralSet` transactions in that epoch **pre-block** rejected (0062-SPAM-029). - A party who has submitted more than `spam.protection.max.CreateReferralSet` transactions in the current epoch plus in the current block, should have their transactions submitted in the current block **post-block** rejected (0062-SPAM-032). From 34617486d785abe4b3702961752939f2fe7223e2 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 4 Oct 2023 10:50:10 +0100 Subject: [PATCH 634/649] feat: add entitiy scope acs --- protocol/0056-REWA-rewards_overview.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 180a31680..9236ce7c0 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -1003,3 +1003,26 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If the pro-rata distribution strategy was specified in the recurring transfer, each eligible parties share of the rewards pool should be equal to their reward metric (assuming no other multipliers) (0056-REWA-093). - If the rank distribution strategy was specified in the recurring transfer, each eligible parties share of the reward pool should be equal to the `share_ratio` defined by their position in the `rank_table` (assuming no other multipliers) (0056-REWA-094). + + +### Entity Scope + +#### Individuals + +- If the entity scope is `ENTITY_SCOPE_INDIVIDUALS`, transfers setting the `teams_scope` field should be rejected as invalid (0056-REWA-095). +- If the entity scope is `ENTITY_SCOPE_INDIVIDUALS`, transfers not setting the `individual_scope` field should be rejected as invalid (0056-REWA-096). +- If the entity scope is `ENTITY_SCOPE_INDIVIDUALS` and the individual scope is `INDIVIDUAL_SCOPE_ALL`, all individual parties should be eligible for rewards providing they meet all other eligibility conditions (0056-REWA-097). +- If the entity scope is `ENTITY_SCOPE_INDIVIDUALS` and the individual scope is `INDIVIDUAL_SCOPE_IN_A_TEAM`, only individual parties who are in a team should be eligible for rewards providing they meet all other eligibility conditions (0056-REWA-098). +- If the entity scope is `ENTITY_SCOPE_INDIVIDUALS` and the individual scope is `INDIVIDUAL_SCOPE_NOT_IN_A_TEAM`, only individual parties not in a team should be eligible for rewards providing they meet all other eligibility conditions (0056-REWA-099). +- If the entity scope is `ENTITY_SCOPE_INDIVIDUALS`, rewards should be distributed among eligible individual parties according to each parties reward metric value (0056-REWA-100). + +#### Teams + +- If the entity scope is `ENTITY_SCOPE_TEAMS`, transfers setting the `individual_scope` field should be rejected as invalid (0056-REWA-101). +- If the entity scope is `ENTITY_SCOPE_TEAMS` transfers not setting the `n_top_performers` field should be rejected as invalid (0056-REWA-102). +- If the entity scope is `ENTITY_SCOPE_TEAMS` and the teams scope is not-set, then all teams are eligible for rewards (0056-REWA-103). +- If the entity scope is `ENTITY_SCOPE_TEAMS` and the teams scope is set, then only the teams specified in the teams scope are eligible for rewards (0056-REWA-104). +- If the entity scope is `ENTITY_SCOPE_TEAMS`, then rewards should be allocated to teams according to each teams reward metric value (0056-REWA-105). +- Each team’s reward metric should be the weighted average metric of the top `n_top_performers` % of team members, e.g. for a team of 100 parties with `n_top_performers=0.1`, the 10 members with the highest metric (0056-REWA-106). +- If a team member has a non-zero reward metric, they should receive a share of the rewards proportional to their individual payout multipliers (0056-REWA-107). +- If a team member has a zero reward metric, they should receive no share of the rewards allocated to the team (0056-REWA-108). From d916d5682c2fee62056e01b687580ca2dced9881 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 4 Oct 2023 10:52:21 +0100 Subject: [PATCH 635/649] feat: update features.json --- protocol/features.json | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/protocol/features.json b/protocol/features.json index 195043ab5..a6cdb59e5 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -515,6 +515,25 @@ "0056-REWA-094" ] }, + "Team rewards": { + "milestone": "deployment-3", + "acs": [ + "0056-REWA-095", + "0056-REWA-096", + "0056-REWA-097", + "0056-REWA-098", + "0056-REWA-099", + "0056-REWA-100", + "0056-REWA-101", + "0056-REWA-102", + "0056-REWA-103", + "0056-REWA-104", + "0056-REWA-105", + "0056-REWA-106", + "0056-REWA-107", + "0056-REWA-108" + ] + }, "Market governance": { "milestone": "deployment-2", "acs": [ From 589bc78cd9acd3e13068bdce967df3316d062561 Mon Sep 17 00:00:00 2001 From: Charlie Date: Wed, 4 Oct 2023 15:48:39 +0100 Subject: [PATCH 636/649] chore: clarify ac by removing weighted --- protocol/0056-REWA-rewards_overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 9236ce7c0..8121309d7 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -176,7 +176,7 @@ Note this reward metric **is not** available for team rewards. All metrics (except [market creation](#market-creation-reward-metrics)) can be used to define the distribution of both individual rewards and team rewards. -A team’s reward metric is the weighted average metric score of the top performing `n` % of team members by number where `n` is specified when creating the recurring transfer (i.e. for a team of 100 parties with `n=0.1`, the 10 members with the highest metric score). +A team’s reward metric is the average metric score of the top performing `n` % of team members by number where `n` is specified when creating the recurring transfer (i.e. for a team of 100 parties with `n=0.1`, the 10 members with the highest metric score). ## Reward accounts @@ -1023,6 +1023,6 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT` - If the entity scope is `ENTITY_SCOPE_TEAMS` and the teams scope is not-set, then all teams are eligible for rewards (0056-REWA-103). - If the entity scope is `ENTITY_SCOPE_TEAMS` and the teams scope is set, then only the teams specified in the teams scope are eligible for rewards (0056-REWA-104). - If the entity scope is `ENTITY_SCOPE_TEAMS`, then rewards should be allocated to teams according to each teams reward metric value (0056-REWA-105). -- Each team’s reward metric should be the weighted average metric of the top `n_top_performers` % of team members, e.g. for a team of 100 parties with `n_top_performers=0.1`, the 10 members with the highest metric (0056-REWA-106). +- Each team’s reward metric should be the average metric of the top `n_top_performers` % of team members, e.g. for a team of 100 parties with `n_top_performers=0.1`, the 10 members with the highest metric (0056-REWA-106). - If a team member has a non-zero reward metric, they should receive a share of the rewards proportional to their individual payout multipliers (0056-REWA-107). - If a team member has a zero reward metric, they should receive no share of the rewards allocated to the team (0056-REWA-108). From 35ec0356769e33f7b120d806d08118630ae1918d Mon Sep 17 00:00:00 2001 From: Paul Webb <86229849+vega-paul@users.noreply.github.com> Date: Thu, 19 Oct 2023 12:31:16 +0100 Subject: [PATCH 637/649] Update 0028-GOVE-governance.md (#1992) * Update 0028-GOVE-governance.md auction termination AC changes 0028-GOVE-135 * Update 0028-GOVE-governance.md --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index ee95c5f21..c2b5483c0 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -544,7 +544,7 @@ APIs should also exist for clients to: - A market suspended by the governance vote does not allow trade generation of margin account balance reduction. (0028-GOVE-116) - Verify that a party with 0 balance of the governance token, but with sufficient ELS can submit a market change proposal successfully. (0028-GOVE-117) - Verify that a party with 0 balance of the governance token and insufficient ELS sees their market change proposal rejected after submission. (0028-GOVE-118) -- Enacting a market closure governance proposal on a market which is in opening auction closes it immediately without generating any trades. (0028-GOVE-135) +- Enacting a market closure governance proposal on a market which is in opening auction cancels it immediately without generating any trades. The market moves to a cancelled state and any open orders are also cancelled. (0028-GOVE-135) - Enacting a market closure governance proposal on a market which is in auction (of any type except the opening auction) uncrosses that auction at the current uncrossing price, generates the trades and then proceeds to close it using the final price (if applicable to the market type). (0028-GOVE-136) - Enacting a market closure governance proposal on a market that is in a settled state has no effect. (0028-GOVE-137) - Enacting a market closure governance proposal on a market that is not in a settled state always uses the price supplied with the proposal for final settlement, even when the oracle settlement price is available at that time. (0028-GOVE-138) From 53dd33d75f7f46eeb15213e0bb01e97d8f3b9946 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Thu, 19 Oct 2023 12:49:10 +0100 Subject: [PATCH 638/649] Make referrals spec line up with implementation (#2009) * chore: spelling errors * feat: add validation for running volume values * chore: remove mention of program states * fix: correct validation * fix: corrrect ac code * fix: correct AC code to match implementation and tests --------- Co-authored-by: Charlie Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- .../0083-RFPR-on_chain_referral_program.md | 54 ++++++++++--------- protocol/0084-VDPR-volume_discount_program.md | 14 ++--- protocol/features.json | 2 + 3 files changed, 38 insertions(+), 32 deletions(-) diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 2b1ec2713..918c7a6e1 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -4,7 +4,7 @@ The aim of the on-chain referral program is to allow users of the protocol to incentivise users and community members to refer new traders by voting to provide benefits for referrers and/or referees. -A party will be able to [create a referral code](#creating-a-referral-set) and share this code with referees. Referees who [apply the code](#applying-a-referral-code) will be added to the referrers "referral set". +A party will be able to [create a referral code](#creating-a-referral-set) and share this code with referees. Referees who [apply the code](#applying-a-referral-code) will be added to the referrer's "referral set". Whilst a referral program is active, the following benefits may be available to members of a referral set: @@ -46,13 +46,13 @@ Enabling or changing the terms of the on-chain referral program can be proposed - `benefit_tiers`: a list of dictionaries (with the below fields) defining the reward and discount factors from referrals - `minimum_running_notional_taker_volume`: the required [`referral_set_running_notional_taker_volume`](#referral-set-volumes) in quantum units for parties to access this tier - `minimum_epochs`: the required number of epochs a referee must have been in a referral set to access this tier - - `referral_reward_factor`: the proportion of the referees taker fees to be rewarded to the referrer - - `referral_discount_factor`: the proportion of the referees taker fees to be discounted + - `referral_reward_factor`: the proportion of the referee's taker fees to be rewarded to the referrer + - `referral_discount_factor`: the proportion of the referee's taker fees to be discounted - `staking_tiers`: a list of dictionaries (with the below fields) defining the multipliers from staking - `minimum_staked_tokens`: the required number of governance tokens ($VEGA) a referrer must be staking to receive the multiplier - `referral_reward_multiplier`: the multiplier applied to the referral_reward_factor when calculating referral rewards due to the referrer. -- `end_of_program_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled -- `window_length`: the number of epochs over which to evaluate a referral sets running notional taker volume +- `end_of_program_timestamp`: the timestamp after which when the current epoch ends, the program will be closed and benefits will be disabled +- `window_length`: the number of epochs over which to evaluate a referral set's running notional taker volume ```protobuf message UpdateReferralProgram{ @@ -101,10 +101,11 @@ When submitting a referral program proposal through governance the following con - a proposer cannot set an `end_of_program_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers`. +- all `minimum_running_notional_taker_volume` values must be an integer value strictly greater than `0`. - all `minimum_epochs` values must be an integer strictly greater than 0 - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor`. - the number of tiers in `staking_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers`. -- all `minimum_staked_tokens` values must be an integer value greater than or equal to `0`. +- all `minimum_staked_tokens` values must be an integer value strictly greater than `0`. - all `referral_reward_multiplier` values must be a float value greater than or equal to `1`. - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor`. - `window_length` must be an integer strictly greater than zero. @@ -113,14 +114,14 @@ The referral program will start the epoch after the `enactment_timestamp` is rea ## Referral program lifecycle -After a referral program [proposal](#governance-proposals) is validated and accepted by the network, the network referral program is created / updated and can be one of the following states. The current state of the network referral program should be exposed via an API. +After a referral program [proposal](#governance-proposals) is validated and accepted by the network, the network referral program is created / updated and can be one of the following states. -| Status | Benefits Enabled | Condition for entry | Condition for exit | +| State | Benefits Enabled | Condition for entry | Condition for exit | | -------------------- | ---------------- | --------------------------------------------------------- | ----------------------------------------------------------------- | -| `STATUS_INACTIVE` | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | -| `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | -| `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | -| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `end_of_program_timestamp` | +| Inactive | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | +| Proposed | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | +| Pending | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | +| Active | Yes | Previously `pending` | End of epoch after network reaches proposal `end_of_program_timestamp` | ## Referral set mechanics @@ -219,7 +220,7 @@ message ApplyReferralCode{ } ``` -If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors and reward multipliers updated](#setting-benefit-factors-and-reward-multipliers) accordingly. Their key must then become associated with the referrers key. All referral rewards will be transferred to this referrers key, regardless of whether the party reapplies a new referral code. +If a party is not currently a referee, they must immediately be added to the referral set and [benefit factors and reward multipliers updated](#setting-benefit-factors-and-reward-multipliers) accordingly. Their key must then become associated with the referrer's key. All referral rewards will be transferred to this referrer's key, regardless of whether the party reapplies a new referral code. If a party is already a referee, and submits another `ApplyReferralCode` transaction, they will not be transferred to the new referral set but they will be added to the associated team at the start of the next epoch (providing a team exists). Note, if the referee has submitted multiple transactions in an epoch, the referee will be added to the new team specified in the latest valid transaction. @@ -243,23 +244,23 @@ referral_set_epoch_notional_taker_volume = sum[min(party_epoch_notional_taker_vo After the values are calculated, the `referral_set_epoch_notional_taker_volume` is stored by the network. -The network can then calculate the sets `referral_set_running_notional_taker_volume` by summing the sets `referral_set_epoch_notional_taker_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). +The network can then calculate the set's `referral_set_running_notional_taker_volume` by summing the set's `referral_set_epoch_notional_taker_volume` values over the last n epochs where n is the `window_length` set in the [governance proposal](#governance-proposals). ## Benefit mechanics ### Setting benefit factors and reward multipliers -Whilst a referral program is `STATUS_ACTIVE`, at the start of an epoch (after pending `ApplyReferralCode` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. +Whilst a referral program is active, at the start of an epoch (after pending `ApplyReferralCode` transactions have been processed) the network must set the `referral_reward_factor` and `referral_discount_factor` for each referee. -Note, when setting a referees benefit factors we compare a sets `referral_set_running_notional_taker_volume` to a `minimum_running_notional_taker_volume` value. To prevent parties self-referring and moving teams, this `referral_set_running_notional_taker_volume` is always the value of the referees original referral set. +Note, when setting a referee's benefit factors we compare a sets `referral_set_running_notional_taker_volume` to a `minimum_running_notional_taker_volume` value. To prevent parties self-referring and moving teams, this `referral_set_running_notional_taker_volume` is always the value of the referee's original referral set. #### Setting the referral reward factor The `referral_reward_factor` should be set by identifying the "highest" benefit tier where the following conditions are fulfilled. -- `referral_set_running_notional_taker_volume` of the referee's **original** referral set is greater than or equal to the tiers `minimum_running_notional_taker_volume`. +- `referral_set_running_notional_taker_volume` of the referee's **original** referral set is greater than or equal to the tier's `minimum_running_notional_taker_volume`. -The referees `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. +The referee's `referral_reward_factor` is then set to the `referral_reward_factor` defined in the selected benefit tier. Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. @@ -267,10 +268,10 @@ Note the **original** referrer is defined as the team of the referrer associated The `referral_discount_factor` should be set by identifying the "highest" benefit tier where **BOTH** the following conditions are fulfilled. -- `referral_set_running_notional_taker_volume` of the referee's **original** referral set is greater than or equal to the tiers `minimum_running_notional_taker_volume`. -- the referee has been a associated with the referral set for at least the tiers `minimum_epochs`. +- `referral_set_running_notional_taker_volume` of the referee's **original** referral set is greater than or equal to the tier's `minimum_running_notional_taker_volume`. +- the referee has been a associated with the referral set for at least the tier's `minimum_epochs`. -The referees `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. +The referee's `referral_discount_factor` is then set to the `referral_discount_factor` defined in the selected benefit tier. Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. @@ -278,9 +279,9 @@ Note the **original** referrer is defined as the team of the referrer associated The `referral_reward_multiplier` should be set by identifying the "highest" staking tier where the following conditions are fulfilled. -- the referees **original** referrer is staking greater than or equal to the tiers `minimum_staked_tokens`. +- the referee's **original** referrer is staking greater than or equal to the tier's `minimum_staked_tokens`. -The referees `referral_reward_multiplier` is then set to the `referral_reward_multiplier` defined in the selected benefit tier. +The referee's `referral_reward_multiplier` is then set to the `referral_reward_multiplier` defined in the selected benefit tier. Note the **original** referrer is defined as the team of the referrer associated with the referee. See section [applying a referral code](#applying-a-referral-code) for more detail. @@ -356,8 +357,8 @@ The Parties API should now return a list of all **parties** (which can be filter The ReferralSet API should now expose a list of all **referral sets** (which can be filtered by referral set `id`) with the following information: -- the sets founding **referrer** -- the sets **referees** +- the set's founding **referrer** +- the set's **referees** - current `referral_set_running_notional_taker_volume` - current `referral_reward_factor` applied to referee taker fees - current **maximum possible** `referral_discount_factor` applied to referee taker fees @@ -401,8 +402,9 @@ The Estimate Fees API should now calculate the following additional information: ### Governance Proposals 1. If an `UpdateReferralProgram` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - - the `end_of_program_timestamp` must be less than or equal to the proposals `enactment_time` (0083-RFPR-001). + - the `end_of_program_timestamp` must be greater than or equal to the proposal's `enactment_time` (0083-RFPR-001). - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `referralProgram.maxReferralTiers` (0083-RFPR-002). + - all `minimum_running_notional_taker_volume` values must be an integer strictly greater than 0 (0083-RFPR-051). - all `minimum_epochs_in_team` values must be an integer strictly greater than 0 (0083-RFPR-003). - all `referral_reward_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `referralProgram.maxReferralRewardFactor` (0083-RFPR-004). - all `referral_discount_factor` values must be greater than or equal to `0` and be less than or equal to the network parameter `referralProgram.maxReferralDiscountFactor` (0083-RFPR-005). diff --git a/protocol/0084-VDPR-volume_discount_program.md b/protocol/0084-VDPR-volume_discount_program.md index 2940718ea..efbd1ef26 100644 --- a/protocol/0084-VDPR-volume_discount_program.md +++ b/protocol/0084-VDPR-volume_discount_program.md @@ -18,7 +18,7 @@ Enabling or changing the terms of the volume discount program can be proposed vi - `benefit_tiers`: a list of dictionaries with the following fields - `minimum_party_running_notional_taker_volume`: the required `party_running_notional_taker_volume` in quantum units for a party to access this tier - `volume_discount_factor`: the proportion of the referees taker fees to be rewarded to the referrer -- `end_of_program_timestamp`: the timestamp after which when the current epoch ends, the programs status will become `STATE_CLOSED` and benefits will be disabled. If this field is empty, the program runs indefinitely. +- `end_of_program_timestamp`: the timestamp after which when the current epoch ends, the program will become inactive and benefits will be disabled. If this field is empty, the program runs indefinitely. - `window_length`: the number of epochs over which to evaluate a parties notional running volume ```protobuf @@ -48,6 +48,7 @@ When submitting a volume discount program proposal through governance the follow - a proposer cannot set an `end_of_program_timestamp` less than the proposals `enactment_time`. - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers`. +- all `minimum_party_running_notional_taker_volume` values must be an integer value strictly greater than `0`. - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor`. - `window_length` must be an integer strictly greater than zero. @@ -55,14 +56,14 @@ The volume discount program will start the epoch after the `enactment_timestamp` ## Volume discount program lifecycle -After a volume discount program [proposal](#governance-proposals) is validated and accepted by the network, the network volume discount program is created / updated and can be one of the following states. The current state of the network volume discount program should be exposed via an API. +After a volume discount program [proposal](#governance-proposals) is validated and accepted by the network, the network volume discount program is created / updated and can be one of the following states. | Status | Benefits Enabled | Condition for entry | Condition for exit | | -------------------- | ---------------- | --------------------------------------------------------- | ----------------------------------------------------------------- | -| `STATUS_INACTIVE` | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | -| `STATUS_PROPOSED` | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | -| `STATUS_PENDING` | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | -| `STATUS_ACTIVE` | Yes | Previously `STATUS_PENDING` | End of epoch after network reaches proposal `end_of_program_timestamp` | +| Inactive | No | No proposal ever submitted, or previous proposal ended | New governance proposal submitted to the network | +| Proposed | No | Governance proposal valid and accepted | Governance proposal voting period ends (or proposal is invalid) | +| Pending | No | Governance vote passes | End of epoch after network reaches proposal `enactment_timestamp` | +| Active | Yes | Previously Pending | End of epoch after network reaches proposal `end_of_program_timestamp` | ## Benefit Mechanics @@ -125,6 +126,7 @@ The Trades API should now also expose the following additional information for e 1. If an `UpdateVolumeDiscount` proposal does not fulfil one or more of the following conditions, the proposal should be `STATUS_REJECTED`: - the `end_of_program_timestamp` must be less than or equal to the proposals `enactment_time` (0084-VDPR-001). - the number of tiers in `benefit_tiers` must be less than or equal to the network parameter `volumeDiscountProgram.maxBenefitTiers` (0084-VDPR-002). + - all `minimum_party_running_notional_taker_volume` values must be an integer strictly greater than 0 (0084-VDPR-017). - all `volume_discount_factor` values must be greater than or equal to `0` and less than or equal to the network parameter `volumeDiscountProgram.maxVolumeDiscountFactor` (0084-VDPR-003). - the `window_length` must be an integer strictly greater than zero (0084-VDPR-004). 1. A volume discount program should be started the first epoch change after the `enactment_datetime` is reached (0084-VDPR-005). diff --git a/protocol/features.json b/protocol/features.json index a6cdb59e5..429a63096 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -428,6 +428,7 @@ "0083-RFPR-048", "0083-RFPR-049", "0083-RFPR-050", + "0083-RFPR-051", "0084-VDPR-001", "0084-VDPR-002", "0084-VDPR-003", @@ -444,6 +445,7 @@ "0084-VDPR-014", "0084-VDPR-015", "0084-VDPR-016", + "0084-VDPR-017", "0029-FEES-023", "0029-FEES-024", "0029-FEES-025", From 0edd7497bd72c7164546de4728219ad98c39dd1d Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 19 Oct 2023 12:56:54 +0100 Subject: [PATCH 639/649] chore: align spec with implementation (#2002) Co-authored-by: Gordsport <83510148+gordsport@users.noreply.github.com> --- protocol/0056-REWA-rewards_overview.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 8121309d7..169ff1743 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -131,16 +131,6 @@ If a party **is not** a consensus or standby validator, their reward metric is s $$m_v = 0$$ -A specialised global rewards account type is used for these rewards. - -The share of the reward attributed to the given validator gets further split between the validator itself and its delegators as outlined in [PoS rewards spec](./0061-REWP-pos_rewards.md) - -#### Maximum payout per participant - -For validator ranking metric based rewards the payments are subject to `reward.staking.delegation.maxPayoutPerParticipant`. -The maximum per participant is the maximum a single party (public key) on Vega can receive as a staking and delegation reward for one epoch. Each participant receives their due, capped by the max. The unpaid amount remain in the treasury. -Setting this to `0` means no cap. - ### Market creation reward metrics There will be a single market creation reward metric and reward type. From ae25744fb098d2987f6161dfc18813cd169828d8 Mon Sep 17 00:00:00 2001 From: candida-d <62548908+candida-d@users.noreply.github.com> Date: Fri, 20 Oct 2023 13:39:55 +0100 Subject: [PATCH 640/649] update gov-transfer max amount (#2014) --- protocol/0028-GOVE-governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index c2b5483c0..9686b198a 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -343,7 +343,7 @@ The amount is calculated by Where: -- `NETWORK_MAX_AMOUNT` is a network parameter specifying the maximum absolute amount that can be transferred by governance for the source account type +- `NETWORK_MAX_AMOUNT` is a network parameter specifying the maximum amount that can be transferred by governance for the source account type, as a multiplier for the transfer asset's quantum - `NETWORK_MAX_FRACTION` is a network parameter specifying the maximum fraction of the balance that can be transferred by governance for the source account type (must be <= 1) If `type` is "all or nothing" then the transfer will only proceed if: From 86f437c7943b6486e80e95e32f69befd2063de61 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 26 Oct 2023 12:13:53 +0100 Subject: [PATCH 641/649] chore: align spec with implementation --- protocol/0029-FEES-fees.md | 44 ++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 18 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 0d30f60d9..8af099713 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -25,46 +25,54 @@ Note that maker_fee = 0 if there is no maker, taker relationship between the tra Before fees are transferred, if there is an [active referral program](./0083-RFPR-on_chain_referral_program.md) or [volume discount program](./0085-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. -Note, it is important discounts are calculated and applied **before** rewards are calculated and applied. +Note, discounts are calculated and applied one after the after and **before** rewards are calculated. 1. Calculate any referral discounts due to the party. ```pseudo - infrastructure_fee_referral_discount = floor(infrastructure_fee * referral_discount_factor) - liquidity_fee_referral_discount = floor(liquidity_fee * referral_discount_factor) - maker_fee_referral_discount = floor(maker_fee * referral_discount_factor) + infrastructure_fee_referral_discount = floor(original_infrastructure_fee * referral_discount_factor) + liquidity_fee_referral_discount = floor(original_liquidity_fee * referral_discount_factor) + maker_fee_referral_discount = floor(original_maker_fee * referral_discount_factor) + ``` + +1. Apply referral discounts to the original fee. + + ```pseudo + infrastructure_fee_after_referral_discount = original_infrastructure_fee - infrastructure_fee_referral_discount + liquidity_fee_after_referral_discount = original_infrastructure_fee - liquidity_fee_referral_discount + maker_fee_after_referral_discount = original_infrastructure_fee - maker_fee_referral_discount ``` 1. Calculate any volume discounts due to the party. ```pseudo - infrastructure_fee_volume_discount = floor(infrastructure_fee * volume_discount_factor) - liquidity_fee_volume_discount = floor(liquidity_fee * volume_discount_factor) - maker_fee_volume_discount = floor(maker_fee * volume_discount_factor) + infrastructure_fee_volume_discount = floor(infrastructure_fee_after_referral_discount * volume_discount_factor) + liquidity_fee_volume_discount = floor(liquidity_fee_after_referral_discount * volume_discount_factor) + maker_fee_volume_discount = floor(maker_fee_after_referral_discount * volume_discount_factor) ``` -1. Update the fee components by applying the discounts. +1. Apply any volume discounts to the fee after referral discounts. ```pseudo - infrastructure_fee = infrastructure_fee - infrastructure_fee_referral_discount - infrastructure_fee_volume_discount - liquidity_fee = liquidity_fee - liquidity_fee_referral_discount - liquidity_fee_volume_discount - maker_fee = maker_fee - maker_fee_referral_discount - maker_fee_volume_discount + infrastructure_fee_after_volume_discount = infrastructure_fee_after_referral_discount - infrastructure_fee_volume_discount + liquidity_fee_after_volume_discount = liquidity_fee_after_referral_discount - liquidity_fee_volume_discount + maker_fee_after_volume_discount = maker_fee_after_referral_discount - maker_fee_volume_discount ``` -1. Calculate any referral rewards due to the parties referrer (Note we are using the updated fee components from step 3 and the `referralProgram.maxReferralRewardProportion` is the network parameter described in the [referral program spec](./0083-RFPR-on_chain_referral_program.md#network-parameters)) +1. Calculate any referral rewards due to the parties referrer (Note we are using the updated fee components from step 4 and the `referralProgram.maxReferralRewardProportion` is the network parameter described in the [referral program spec](./0083-RFPR-on_chain_referral_program.md#network-parameters)) ```pseudo - infrastructure_fee_referral_reward = floor(infrastructure_fee * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) - liquidity_fee_referral_reward = floor(liquidity_fee * min(referral_reward_factor * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) - maker_fee_referral_reward = floor(maker_fee * min(referral_reward_factor * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) + infrastructure_fee_referral_reward = floor(infrastructure_fee_after_volume_discount * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) + liquidity_fee_referral_reward = floor(liquidity_fee * min(liquidity_fee_after_volume_discount * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) + maker_fee_referral_reward = floor(maker_fee * min(maker_fee_after_volume_discount * min(referral_reward_factor * referral_reward_multiplier, referralProgram.maxReferralRewardProportion)) ``` 1. Finally, update the fee components by applying the rewards. ```pseudo - infrastructure_fee = infrastructure_fee - infrastructure_fee_referral_reward - liquidity_fee = liquidity_fee - liquidity_fee_referral_reward - maker_fee = maker_fee - maker_fee_referral_reward + final_infrastructure_fee = maker_fee_after_volume_discount - infrastructure_fee_referral_reward + final_liquidity_fee = maker_fee_after_volume_discount - liquidity_fee_referral_reward + final_maker_fee = maker_fee_after_volume_discount - maker_fee_referral_reward ``` (Note the rewards and discounts are floored rather than raised to ensure the final fees cannot be negative.) From f817a5761d9c13b33e7322374be21bbc1e7497f7 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 26 Oct 2023 12:16:20 +0100 Subject: [PATCH 642/649] chore: clarify acs to match existing tests --- protocol/0029-FEES-fees.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 8af099713..16a28a16c 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -167,27 +167,27 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ### Applying benefit factors -1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading. (0029-FEES-023) +1. Referee discounts are correctly calculated and applied for each taker fee component during continuous trading (assuming no volume discounts due to party) (0029-FEES-023) - `infrastructure_referral_fee_discount` - `liquidity_fee_referral_discount` - `maker_fee_referral_discount` -1. Referee discounts are correctly calculated and applied for each fee component when exiting an auction. (0029-FEES-024) +1. Referee discounts are correctly calculated and applied for each fee component when exiting an auction (assuming no volume discounts due to party) (0029-FEES-024) - `infrastructure_fee_referral_discount` - `liquidity_fee_referral_discount` -1. Referrer rewards are correctly calculated and transferred for each fee component during continuous trading. (0029-FEES-025) +1. Referrer rewards are correctly calculated and transferred for each fee component during continuous trading (assuming no volume discounts due to party) (0029-FEES-025) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` - `maker_fee_referral_reward` -1. Referrer rewards are correctly calculated and transferred for each fee component when exiting an auction. (0029-FEES-026) +1. Referrer rewards are correctly calculated and transferred for each fee component when exiting an auction (assuming no volume discounts due to party) (0029-FEES-026) - `infrastructure_fee_referral_reward` - `liquidity_fee_referral_reward` 1. If the referral reward due to the referrer is strictly less than `1`, no reward is transferred (0029-FEES-029). 1. If the referral discount due to the referee is strictly less than `1`, no discount is applied (0029-FEES-030). 1. The proportion of fees transferred to the referrer as a reward cannot be greater than the network parameter `referralProgram.maxReferralRewardProportion` (0029-FEES-031). -1. Volume discount rewards are correctly calculated and transferred for each taker fee component during continuous trading. (0029-FEES-027) +1. Volume discount rewards are correctly calculated and transferred for each taker fee component during continuous trading (assuming no referral discounts due to party) (0029-FEES-027) - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` - `maker_fee_volume_discount` -1. Volume discount rewards are correctly calculated and transferred for each fee component when exiting an auction. (0029-FEES-028) +1. Volume discount rewards are correctly calculated and transferred for each fee component when exiting an auction (assuming no referral discounts due to party) (0029-FEES-028) - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` From 272e470f624f8e5a747f824758a0ee57be3f641b Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 26 Oct 2023 12:26:09 +0100 Subject: [PATCH 643/649] feat: add acs to cover multiple discount sources --- protocol/0029-FEES-fees.md | 2 ++ protocol/features.json | 2 ++ 2 files changed, 4 insertions(+) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 16a28a16c..d02d97209 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -191,3 +191,5 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w 1. Volume discount rewards are correctly calculated and transferred for each fee component when exiting an auction (assuming no referral discounts due to party) (0029-FEES-028) - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` +1. During continuous trading, discounts from multiple sources are correctly calculated and applied one after the other, each time using the resulting fee component after the previous discount was applied. (0029-FEES-032). +1. When exiting an auction, discounts from multiple sources are correctly calculated and applied one after the other, each time using the resulting fee component after the previous discount was applied. (0029-FEES-033). \ No newline at end of file diff --git a/protocol/features.json b/protocol/features.json index 429a63096..69a6f74f6 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -455,6 +455,8 @@ "0029-FEES-029", "0029-FEES-030", "0029-FEES-031", + "0029-FEES-032", + "0029-FEES-033", "0062-SPAM-026", "0062-SPAM-027", "0062-SPAM-028", From 175c5b72073d1389b1ca738bcd4fa46c9d6a3d07 Mon Sep 17 00:00:00 2001 From: Charlie Date: Thu, 26 Oct 2023 12:40:36 +0100 Subject: [PATCH 644/649] fix: markdownlint failing --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index d02d97209..20ad8337a 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -192,4 +192,4 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w - `infrastructure_fee_volume_discount` - `liquidity_fee_volume_discount` 1. During continuous trading, discounts from multiple sources are correctly calculated and applied one after the other, each time using the resulting fee component after the previous discount was applied. (0029-FEES-032). -1. When exiting an auction, discounts from multiple sources are correctly calculated and applied one after the other, each time using the resulting fee component after the previous discount was applied. (0029-FEES-033). \ No newline at end of file +1. When exiting an auction, discounts from multiple sources are correctly calculated and applied one after the other, each time using the resulting fee component after the previous discount was applied. (0029-FEES-033). From acf83bc1fce5f93348700bb2b622385385fb5173 Mon Sep 17 00:00:00 2001 From: Charlie <99198652+cdummett@users.noreply.github.com> Date: Thu, 26 Oct 2023 14:40:31 +0100 Subject: [PATCH 645/649] refactor: commit suggestion MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Valentin Trinqué --- protocol/0029-FEES-fees.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 20ad8337a..6573baea3 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -25,7 +25,7 @@ Note that maker_fee = 0 if there is no maker, taker relationship between the tra Before fees are transferred, if there is an [active referral program](./0083-RFPR-on_chain_referral_program.md) or [volume discount program](./0085-VDPR-volume_discount_program.md), each parties fee components must be modified as follows. -Note, discounts are calculated and applied one after the after and **before** rewards are calculated. +Note, discounts are calculated and applied one after the other and **before** rewards are calculated. 1. Calculate any referral discounts due to the party. From 823db77e0695bfc50d01645da1186fdf172b5a1e Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 16 Oct 2023 22:41:43 +0100 Subject: [PATCH 646/649] chore: removed descoped features from cosmic branch --- .../0001-NP-LIQB-liquidity_providing_bots.md | 2 +- protocol/0004-AMND-amends.md | 52 ++++--- protocol/0008-TRAD-trading_workflow.md | 2 +- protocol/0013-ACCT-accounts.md | 4 +- protocol/0014-ORDT-order_types.md | 73 +++++---- protocol/0021-MDAT-market_data_spec.md | 16 +- protocol/0024-OSTA-order_status.md | 34 ++--- protocol/0025-OCRE-order_submission.md | 2 +- protocol/0026-AUCT-auctions.md | 20 +-- protocol/0028-GOVE-governance.md | 24 +-- protocol/0029-FEES-fees.md | 16 +- protocol/0032-PRIM-price_monitoring.md | 34 ++--- protocol/0033-OCAN-cancel_orders.md | 14 +- ...PROB-prob_weighted_liquidity_measure.ipynb | 6 +- protocol/0037-OPEG-pegged_orders.md | 2 +- .../0039-MKTD-market_depth_calculation.md | 28 ++-- protocol/0041-TSTK-target_stake.md | 26 ---- protocol/0043-MKTL-market_lifecycle.md | 1 - protocol/0044-LIME-lp_mechanics.md | 42 ++---- ...-TVAL-validate_transaction_preconsensus.md | 6 - protocol/0051-PROD-product.md | 6 +- .../0052-FPOS-fractional_orders_positions.md | 4 +- protocol/0054-NETP-network_parameters.md | 10 +- protocol/0056-REWA-rewards_overview.md | 35 ----- protocol/0057-TRAN-transfers.md | 1 - .../0065-FTCO-floating_point_consensus.md | 8 +- protocol/0068-MATC-matching_engine.md | 66 ++++----- protocol/0070-MKTD-market-decimal-places.md | 16 +- protocol/0073-LIMN-limited_network_life.md | 42 ++---- .../0074-BTCH-batch-market-instructions.md | 8 +- .../0079-TGAP-transaction_gas_and_priority.md | 3 - protocol/0080-SPOT-product_builtin_spot.md | 138 ------------------ protocol/0081-SUCM-successor_markets.md | 5 - .../0083-RFPR-on_chain_referral_program.md | 2 +- 34 files changed, 242 insertions(+), 506 deletions(-) delete mode 100644 protocol/0080-SPOT-product_builtin_spot.md diff --git a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md index fa468e16b..db5c04387 100644 --- a/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md +++ b/non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md @@ -7,7 +7,7 @@ At the moment bots on Vega run on certain markets to make them look "real". For that purpose they: 1. Are given large amounts of collateral via faucets. -1. Keep track of current spot or futures price on another exchange (at e.g. 30s, 5 min intervals) +1. Keep track of current futures price on another exchange (at e.g. 30s, 5 min intervals) 1. Post GTC limit orders randomly on both sides of the order book at random volumes using the above reference price as mid. This achieves the following: the price on the market looks "real" and there is volume for participants to trade. diff --git a/protocol/0004-AMND-amends.md b/protocol/0004-AMND-amends.md index 73848c678..6259abe41 100644 --- a/protocol/0004-AMND-amends.md +++ b/protocol/0004-AMND-amends.md @@ -2,38 +2,36 @@ ## Acceptance Criteria -- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001). For product spot: (0004-AMND-030) -- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002). For product spot: (0004-AMND-031) -- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003). For product spot: (0004-AMND-032) -- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004). For product spot: (0004-AMND-055) -- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005). For product spot: (0004-AMND-033) -- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006). For product spot: (0004-AMND-034) -- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007). For product spot: (0004-AMND-035) -- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008). For product spot: (0004-AMND-036) -- The `orderID` remains the same after an amend (0004-AMND-009). For product spot: (0004-AMND-037) -- Amends can occur in continuous trading or in an auction (0004-AMND-010). For product spot: (0004-AMND-038) -- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011). For product spot: (0004-AMND-039) -- All amendable fields can be amended in the same amend message (0004-AMND-012). For product spot: (0004-AMND-040) -- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013). For product spot: (0004-AMND-041) -- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014). For product spot: (0004-AMND-042) -- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015). For product spot: (0004-AMND-043) -- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016). For product spot: (0004-AMND-044) -- A parked pegged order can be amended. (0037-OPEG-014). For product spot: (0037-OPEG-019) -- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017). For product spot: (0004-AMND-045) -- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018). For product spot: (0004-AMND-046) -- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019). For product spot: (0004-AMND-047) -- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029). For product spot: (0004-AMND-048) +- Only LIMIT or PEGGED orders can be amended. Any attempt to amend a MARKET order is rejected (0004-AMND-001). +- Price change amends remove the order from the book and insert the order at the back of the queue at the new price level (0004-AMND-002). +- Reducing the quantity leaves the order in its current spot but reduces the remaining amount accordingly (0004-AMND-003). +- Quantity after amendment must be a multiple of the smallest increment possible given the `Position Decimal Places` (PDP) specified in the [Market Framework](./0001-MKTF-market_framework.md), i.e. is PDP = 2 then quantity must be a whole multiple of 0.01. (0004-AMND-004). +- Increasing the quantity causes the order to be removed from the book and inserted at the back of the price level queue with the updated quantity (0004-AMND-005). +- Changing the `TIF` can only occur between `GTC` and `GTT`. Any attempt to amend to another `TIF` flag is rejected. A `GTT` must have an `expiresAt` value but a `GTC` must not have one. (0004-AMND-006). +- Any attempt to amend to or from the `TIF` values `GFA` and `GFN` will result in a rejected amend. (0004-AMND-007). +- All updates to an existing order update the `UpdatedAt` time stamp field in the order (0004-AMND-008). +- The `orderID` remains the same after an amend (0004-AMND-009). +- Amends can occur in continuous trading or in an auction (0004-AMND-010). +- All historic alteration to an order can be viewed from the order storage system (0004-AMND-011). +- All amendable fields can be amended in the same amend message (0004-AMND-012). +- Fields left with default values (0) are not handled as part of the amend action (0004-AMND-013). +- An amend with only the same values as the order still cause the `UpdateAt` field to update but nothing else (0004-AMND-014). +- Amending a pegged orders offset or reference will force a reprice (0004-AMND-015). +- Attempting to alter pegged details on a non pegged or will cause the amend to be rejected (0004-AMND-016). +- A parked pegged order can be amended. (0037-OPEG-014). +- Attempting to alter details on a filled order will cause the amend to be rejected (0004-AMND-017). +- Attempting to alter details on a cancelled order will cause the amend to be rejected (0004-AMND-018). +- Attempting to alter details on an expired order will cause the amend to be rejected (0004-AMND-019). +- Amending expiry time of an active GTT order to a past time whilst also simultaneously amending the price of the order will cause the order to immediately expire with the order details updated to reflect the order details requiring amendment (0004-AMND-029). For a party with no position on a given market: - Amending an order in a way that increases the volume sufficiently leads to margin account balance increasing (0004-AMND-021) -- In Spot market amending an order in a way that increases the volume sufficiently leads to holding account balance increasing (0004-AMND-049) - Amending an order in a way that decreases the volume sufficiently leads to margin account balance decreasing (0004-AMND-022) -- In Spot market amending an order in a way that decreases the volume sufficiently leads to holding account balance decreasing (0004-AMND-050) -- It is possible to amend a fractional size order (0004-AMND-025). For product spot: (0004-AMND-051) -- It is possible to amend a partially filled limit order (0004-AMND-026). For product spot: (0004-AMND-052) -- It is possible to amend a versioned order (already amended several times) (0004-AMND-027). For product spot: (0004-AMND-053) -- Attempts to amend order fields not in scope are rejected (0004-AMND-028). For product spot: (0004-AMND-054) +- It is possible to amend a fractional size order (0004-AMND-025). +- It is possible to amend a partially filled limit order (0004-AMND-026). +- It is possible to amend a versioned order (already amended several times) (0004-AMND-027). +- Attempts to amend order fields not in scope are rejected (0004-AMND-028). ## Summary diff --git a/protocol/0008-TRAD-trading_workflow.md b/protocol/0008-TRAD-trading_workflow.md index 16c4b2232..61ae1f8e4 100644 --- a/protocol/0008-TRAD-trading_workflow.md +++ b/protocol/0008-TRAD-trading_workflow.md @@ -10,7 +10,7 @@ The order of processing of transactions happens in the order defined in the diag 1. Before a valid order is processed in any other way by Vega, the [party](./0017-PART-party.md)'s [margin levels](./0011-MARA-check_order_allocate_margin.md) are checked as though they had the order in their position, and any transfers that are needed to support that order occur. (0008-TRAD-001) 1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there will be changes in positions for one or more traders. (0008-TRAD-002) -1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003). For product spot: (0008-TRAD-008) +1. Following all of the matching of trades resulting from a single order or the acceptance of an order onto the order book, there may be a change to the Mark Price. (0008-TRAD-003). 1. Following the above 3 actions, a [mark to market settlement](./0003-MTMK-mark_to_market_settlement.md) is run for all parties against their most recently updated positions and Mark Price. This will result in a set of transfers between the parties' accounts and possibly may result in loss socialisation occurring if a party has insufficient collateral to cover the move. (0008-TRAD-004) 1. Following the mark to market settlement, the margin liabilities for traders are evaluated against their collateral balances. Any traders that do not have sufficient collateral to support their positions (after collateral searches have been done to their main account) will undergo position resolution. (0008-TRAD-005) 1. After position resolution has occurred, margins are recalculated and evaluated against balances for any traders that gained positions as a result of supplying liquidity on the order book to the network during position resolution. (0008-TRAD-006) diff --git a/protocol/0013-ACCT-accounts.md b/protocol/0013-ACCT-accounts.md index dcb70b47f..1c4243b41 100644 --- a/protocol/0013-ACCT-accounts.md +++ b/protocol/0013-ACCT-accounts.md @@ -126,8 +126,8 @@ Additional accounts associated with [distribution](./0056-REWA-rewards_overview. ### All ordinary accounts -- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001). For product spot: (0013-ACCT-024) -- Only transfer requests move money between accounts. (0013-ACCT-002). For product spot: (0013-ACCT-025) +- Double entry accounting is maintained at all points i.e. every transfer event has a source account and destination account and the balance of the source account before the transfer equals to the balance of source account minus the transfer amount after the transfer and balance of the destination account before the transfer plus the transfer amount equals to the balance of the destination account after the transfer. (0013-ACCT-001). +- Only transfer requests move money between accounts. (0013-ACCT-002). ### Party asset accounts diff --git a/protocol/0014-ORDT-order_types.md b/protocol/0014-ORDT-order_types.md index 9b83d992d..b9190402a 100644 --- a/protocol/0014-ORDT-order_types.md +++ b/protocol/0014-ORDT-order_types.md @@ -255,47 +255,46 @@ Network orders are used during [position resolution](./0012-POSR-position_resolu ## Acceptance Criteria - Immediate orders, continuous trading: - - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001). For product spot: (0014-ORDT-081) - - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002). For product spot: (0014-ORDT-082) - - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003). For product spot: (0014-ORDT-083) - - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004). For product spot: (0014-ORDT-084) - - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005). For product spot: (0014-ORDT-085) -- No party can submit a [network order type](#network-orders) (0014-ORDT-006). For product spot: (0014-ORDT-086) -- A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039) + - An aggressive persistent (GTT, GTC) limit order that is not crossed with the order book is included on the order book at limit order price at the back of the queue of orders at that price. No trades are generated. (0014-ORDT-001). + - An aggressive persistent (GTT, GTC) limit order that crosses with trades >= to its volume is filled completely and does not appear on the order book or in the order book volume. Trades are atomically generated for the full volume. (0014-ORDT-002). + - An aggressive persistent (GTT, GTC) limit order that is partially filled generates trades commensurate with the filled volume. The remaining volume is placed on the order book at the limit order price, at the back of the queue of orders at that price. (0014-ORDT-003). + - Any GTT limit order that [still] resides on the order book at its expiry time is cancelled and removed from the book before any events are processed that rely on its being present on the book, including any calculation that incorporates its volume and/or price level. (0014-ORDT-004). + - A GTT order submitted at a time >= its expiry time is rejected. (0014-ORDT-005). +- No party can submit a [network order type](#network-orders) (0014-ORDT-006). +- A pegged order (including iceberg pegged orders) never has its price updated during the execution of an incoming aggressive order (even as price levels get consumed so that its reference price changes after the execution). (0014-ORDT-039). ### Iceberg Orders AC's #### Iceberg Order Submission -1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007). For product spot: (0014-ORDT-087) -2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008). For product spot: (0014-ORDT-088) -3. An iceberg post only order can be submitted (0014-ORDT-009). For product spot: (0014-ORDT-089) -4. An iceberg reduce only order is rejected (0014-ORDT-010). For product spot: (0014-ORDT-090) +1. A persistent (GTC, GTT, GFA, GFN) iceberg order that is not crossed with the order book is included in the order book with order book volume == initial peak size. No trades are generated (0014-ORDT-007). +2. An iceberg order with either an ordinary or pegged limit price can be submitted (0014-ORDT-008). +3. An iceberg post only order can be submitted (0014-ORDT-009). +4. An iceberg reduce only order is rejected (0014-ORDT-010). 5. For an iceberg order that is submitted with total size x and display size y the margin taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-011) In Spot market, for an iceberg order that is submitted with total size x and display size y the holding asset taken should be identical to a regular order of size `x` rather than one of size `y` (0014-ORDT-091) -6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012). For product spot: (0014-ORDT-092) +6. For an iceberg order, the orders are refreshed immediately after producing a trade. Every time volume is taken from the displayed quantity , the order is refreshed if display quantity < minimum peak size (0014-ORDT-012). - If the order is successfully refreshed , then the order loses its time priority and is pushed to the back of the queue -7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013). For product spot: (0014-ORDT-093) +7. For an iceberg order that's submitted when the market is in auction, iceberg orders trade according to their behaviour if they were already on the book (trading first the visible size, then additional if the full visible price level is exhausted in the uncrossing) (0014-ORDT-013). #### Iceberg Order Batch Submission 1. For multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, margin calculations , order status are all correct (0014-ORDT-014) -In Spot market, for multiple iceberg orders submitted as a batch of orders with a mix of ordinary limit orders and market orders, the iceberg orders are processed atomically and the order book volume and price, holding calculations , order status are all correct. (0014-ORDT-094) -2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015). For product spot: (0014-ORDT-095) +2. For an iceberg order submitted in a batch that trades against multiple other orders sitting on the book, the iceberg order refreshes between each order in the batch (0014-ORDT-015). #### Iceberg Order Submission - Negative tests -1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016). For product spot: (0014-ORDT-096) -2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017). For product spot: (0014-ORDT-097) -3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018). For product spot: (0014-ORDT-098) -4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020). For product spot: (0014-ORDT-099) -5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021). For product spot: (0014-ORDT-100) -6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022). For product spot: (0014-ORDT-119) +1. An iceberg order with a non persistent TIF (IOC, FOK) is rejected with a valid error message (0014-ORDT-016). +2. An iceberg market order with any TIF is rejected with a valid error message (0014-ORDT-017). +3. A reduce-only iceberg order with any TIF is rejected with a valid error message (0014-ORDT-018). +4. An iceberg order with initial peak size greater than the total order size is rejected with a valid error message (0014-ORDT-020). +5. An iceberg order with minimum peak size less than 0 is rejected with a valid error message (0014-ORDT-021). +6. An iceberg order with minimum peak size greater than initial peak size is rejected with a valid error message (0014-ORDT-022). #### Iceberg Order Amendment -1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023). For product spot: (0014-ORDT-101) -2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024). For product spot: (0014-ORDT-102) +1. Amending an iceberg order to increase size will increase the total and remaining quantities of the order and time priority of the order is not lost (0014-ORDT-023). +2. Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority of the order is not lost (0014-ORDT-024). 3. Amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost (0014-ORDT-025) 4. In Spot market, amend an iceberg order to decrease size so that the displayed quantity is decreased. Total, displayed and remaining quantity is decreased, margin is recalculated and released and time priority is not lost. (0014-ORDT-103) @@ -306,27 +305,27 @@ In Spot market, for multiple iceberg orders submitted as a batch of orders with #### Iceberg Order Execution -1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027). For product spot: (0014-ORDT-105) -2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028). For product spot: (0014-ORDT-106) -3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029). For product spot: (0014-ORDT-107) -4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030). For product spot: (0014-ORDT-108) -5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031). For product spot: (0014-ORDT-109) -6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032). For product spot: (0014-ORDT-110) -7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033). For product spot: (0014-ORDT-111) -8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034). For product spot: ( 0014-ORDT-118) +1. An aggressive iceberg order that crosses with an order where volume > iceberg volume, the iceberg order gets fully filled on entry, the iceberg order status is filled, the remaining quantity = 0. Atomic trades are generated if matched against multiple orders (0014-ORDT-027). +2. An aggressive iceberg order that crosses with an order where volume < iceberg volume. The initial display quantity is filled and the remaining volume is unfilled. Status of iceberg order is active , the volume remaining = (quantity - initial volume) and the remaining volume sits on the book. When additional orders are submitted which consume the remaining volume on the iceberg order , the volume of the iceberg order is refreshed as and when the volume dips below the minimum peak size (0014-ORDT-028). +3. A passive iceberg order (the only order at a particular price level) when crossed with another order that comes in which consumes the full volume of the iceberg order is fully filled. Status of iceberg order is filled and the remaining = 0. Atomic trades are produced (0014-ORDT-029). +4. A passive iceberg order with a couple of order that sit behind the iceberg order at the same price that crosses with an order where volume > display quantity of iceberg order. After the first trade is produced , the iceberg order is pushed to the back of the queue and gets filled only when the other orders in front get fully filled (0014-ORDT-030). +5. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 30,40,50. Ensure the orders are matched and filled in time priority of the orders and any remaining volume on the orders is correctly left behind. (0014-ORDT-031). +6. Submit an aggressive iceberg order for size 100. There are multiple matching orders of size 20,30. Ensure the orders are matched and filled in time priority of the orders. Ensure remaining volume on the iceberg order is (100 - (20+30)) (0014-ORDT-032). +7. When a non iceberg order sitting on the book is amended such that it trades with with an iceberg order, then the iceberg order is refreshed (0014-ORDT-033). +8. Wash trading is not permitted for iceberg orders. The same party has one iceberg order that sits at the back of the queue, another normal order in opposite direction, when the iceberg at the back comes in front the normal order should be stopped. ( 0014-ORDT-034). 9. For a price level with multiple iceberg orders, if an aggressive order hits this price level, any volume greater than the displayed volume at a level is split proportionally between the hidden components of iceberg orders at that price level - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037). For product spot: (0014-ORDT-112) - 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038). For product spot: (0014-ORDT-113) + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 300 lots would be split 150 to the first order and 75 to the two 100 lot orders. (0014-ORDT-037). + 1. If there are three iceberg orders with remaining volume 200 lots, 100 lots and 100 lots, an order for 600 lots would be split 200 to the first order and 100 to the two 100 lot orders, with 200 lots then taking farther price levels. (0014-ORDT-038). ### Snapshots -1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035). For product spot: (0014-ORDT-114) +1. All data pertaining to iceberg orders is saved and can be restored using the snapshot (0014-ORDT-035). ### API -1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036). For product spot: (0014-ORDT-115) -2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069). For product spot: (0014-ORDT-116) -3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070). For product spot: (0014-ORDT-117) +1. API end points should be available to query initial peak size, minimum peak size, quantity, displayed quantity and remaining (0014-ORDT-036). +2. The additional fields relating to iceberg orders should be available in the streaming api end points (0014-ORDT-069). +3. API end points showing market-depth or price-level volume should include the full volume of iceberg orders (0014-ORDT-070). ### Stop orders diff --git a/protocol/0021-MDAT-market_data_spec.md b/protocol/0021-MDAT-market_data_spec.md index 4938d78df..2ceede050 100644 --- a/protocol/0021-MDAT-market_data_spec.md +++ b/protocol/0021-MDAT-market_data_spec.md @@ -2,18 +2,18 @@ ## Acceptance Criteria -- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001). For product spot: (0021-MDAT-013) -- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002). For product spot: (0021-MDAT-014) -- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003). For product spot: (0021-MDAT-015) -- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004). For product spot: (0021-MDAT-016) -- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005). For product spot: (0021-MDAT-017) -- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006). For product spot: (0021-MDAT-018) -- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007). For product spot: (0021-MDAT-019) +- If there are no buy orders on the order book, the best bid price is empty / nothing. (0021-MDAT-001). +- If there are no sell orders on the order book, the best offer price is empty / nothing. (0021-MDAT-002). +- If there are multiple buy orders on the order book with a price equal to the best bid price, the best bid volume equals the sum of the sizes of these orders. (0021-MDAT-003). +- If there are multiple sell orders on the order book with a price equal to the best bid price, the best offer volume equals the sum of the sizes of these orders. (0021-MDAT-004). +- The mid price is empty / nothing if there is either no buy order or no sell orders. (0021-MDAT-005). +- The mid price is the arithmetic average of the best bid price and best offer price. (0021-MDAT-006). +- The mark price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the mark price has not yet been set (for example market in opening auction that's not seen any trades yet). (0021-MDAT-007). - The Open interest returns the sum of the size for all open positions where positions size is greater than 0. (0021-MDAT-008) - The Open interest returns 0 if there are no positions on the market (0021-MDAT-009) - Pegged orders are excluded from the best static price and best static volume calculations. (0021-MDAT-010) - Dynamic orders should be ignored when calculating the static values (0021-MDAT-011) -- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012). For product spot: (0021-MDAT-020) +- The auction uncrossing price, if it has been set in the market, is available on APIs returning market data. The returned object makes clear if the auction uncrossing price has not been set (for example in continuous trading or auction with no bids / offers). (0021-MDAT-012). ## Summary diff --git a/protocol/0024-OSTA-order_status.md b/protocol/0024-OSTA-order_status.md index f2c31d0c4..bc0fc3436 100644 --- a/protocol/0024-OSTA-order_status.md +++ b/protocol/0024-OSTA-order_status.md @@ -45,7 +45,6 @@ Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. ### Fill or Or Kill (0024-OSTA-001) -For product spot: (0024-OSTA-030) | Time In Force | Filled | Resulting status | |---------------|--------|------------------| @@ -54,7 +53,6 @@ For product spot: (0024-OSTA-0300024-OSTA-002) -For product spot: (0024-OSTA-031) | Time In Force | Filled | Resulting status | |---------------|---------|------------------| @@ -64,7 +62,6 @@ For product spot: (0024-OSTA-0310024-OSTA-003) -For product spot: (0024-OSTA-032) | Time In Force | Filled | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|-------------------|-------------------|------------------| @@ -78,7 +75,6 @@ For product spot: (0024-OSTA-0320024-OSTA-004) -For product spot: (0024-OSTA-033) | Time In Force | Filled | Expired | Cancelled by user | Stopped by system | Resulting status | |---------------|---------|---------|-------------------|-------------------|------------------| @@ -97,10 +93,10 @@ Note: The last row in the table above is added for clarity. If the order was fil ### Wash trading Acceptance Criteria -- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-OSTA-005). For product spot: (0024-OSTA-034) -- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006). For product spot: (0024-OSTA-035) -- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007). For product spot: (0024-OSTA-036) -- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008). For product spot: (0024-OSTA-037) +- If, during continuous trading, an order would be filled or partially filled with an existing order from the same [party](./0017-PART-party.md) aka "wash" trade, the order is rejected. The reason for rejection should be clear on the order status: "rejected to prevent a wash trade". (0024-OSTA-005). +- Any existing fills that happen before the wash trade is identified will be kept. The order should be market both "partially filled" and "rejected to prevent wash trade" (0024-OSTA-006). +- FOK rules still apply for wash trading so if a wash trade is identified before the full amount of the order is complete, the order will be stopped and nothing filled. (0024-OSTA-007). +- Wash trading is allowed on [auction](0026-AUCT-auctions.md) uncrossing. (0024-OSTA-008). ### Impact of order types on settlement @@ -110,20 +106,20 @@ Note: The last row in the table above is added for clarity. If the order was fil - Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` is given if a position is closed out because they do now have enough margin to cover the position (0024-OSTA-010) - Order reason of `ORDER_ERROR_MARGIN_CHECK_FAILED` is given if a new order is placed and the user does not have enough collateral to cover the initial margin requirements (0024-OSTA-011) -- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012). For product spot: (0024-OSTA-038) -- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013). For product spot: (0024-OSTA-039) -- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014).. For product spot: (0024-OSTA-040) -- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015). For product spot: (0024-OSTA-041) -- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016). For product spot: (0024-OSTA-042) -- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017). For product spot: (0024-OSTA-043) -- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018). For product spot: (0024-OSTA-044) -- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019). For product spot: (0024-OSTA-045) -- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020). For product spot: (0024-OSTA-046) +- Order reason of `ORDER_ERROR_NON_PERSISTENT_ORDER_OUT_OF_PRICE_BOUNDS` when a non persistent order would cause the price to move outside of the price bounds (0024-OSTA-012). +- Order reason of `ORDER_ERROR_GFN_ORDER_DURING_AN_AUCTION` when the market is in auction and a GFN order is sent in (0024-OSTA-013). +- Order reason of `ORDER_ERROR_CANNOT_SEND_IOC_ORDER_DURING_AUCTION` when trying to send an IOC order during auction (0024-OSTA-014). +- Order reason of `ORDER_ERROR_CANNOT_SEND_FOK_ORDER_DURING_AUCTION` when trying to send a FOK order during auction (0024-OSTA-015). +- Order reason of `ORDER_ERROR_GFA_ORDER_DURING_CONTINUOUS_TRADING` when trying to send a GFA order during normal trading (0024-OSTA-016). +- Order reason of `ORDER_ERROR_INVALID_EXPIRATION_DATETIME` when sending a GTT with the expiry is before the creation time (0024-OSTA-017). +- Order reason of `ORDER_ERROR_MARKET_CLOSED` when trying to send an order when the market is closed (0024-OSTA-018). +- Order reason of `ORDER_ERROR_INVALID_TYPE` when trying to send an order with a non valid order type (0024-OSTA-019). +- Order reason of `ORDER_ERROR_INVALID_MARKET_ID` when sending an order with an invalid market ID (0024-OSTA-020). - Order reason of `ORDER_ERROR_MUST_BE_LIMIT_ORDER` when sending a pegged order that is not a LIMIT order (0024-OSTA-021) - Order reason of `ORDER_ERROR_MUST_BE_GTT_OR_GTC` pegged order must be either GTC or GTT (0024-OSTA-022) - Order reason of `ORDER_ERROR_WITHOUT_REFERENCE_PRICE` pegged order must have a reference field (0024-OSTA-023) - Order reason of `ORDER_ERROR_BUY_CANNOT_REFERENCE_BEST_ASK_PRICE` buy pegged order cannot reference the ask price (0024-OSTA-024) - Order reason of `ORDER_ERROR_OFFSET_MUST_BE_GREATER_THAN_ZERO` pegged order offset must be > 0 when referencing `MID` price (0024-OSTA-025) - Order reason of `ORDER_ERROR_SELL_CANNOT_REFERENCE_BEST_BID_PRICE` sell pegged order cannot reference the bid price (0024-OSTA-026) -- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027). For product spot: (0024-OSTA-047) -- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029). For product spot: (0024-OSTA-048) +- Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all (0024-OSTA-027). +- Order reason of `ORDER_ERROR_SELF_TRADING` when the order would match with one from the same user while not in auction (0024-OSTA-029). diff --git a/protocol/0025-OCRE-order_submission.md b/protocol/0025-OCRE-order_submission.md index f163e500f..14be7ce9b 100644 --- a/protocol/0025-OCRE-order_submission.md +++ b/protocol/0025-OCRE-order_submission.md @@ -37,7 +37,7 @@ Self-trading / "wash" trading is allowed on auction uncrossing (i.e. to leave an ## Acceptance Criteria -- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001). For product spot: (0025-OCRE-004) +- An order's size must be valid according to the [Fractional Order Size spec](./0052-FPOS-fractional_orders_positions.md) (0025-OCRE-001). - Margin will taken before the order is entered into the book (0025-OCRE-002) - If sufficient margin cannot be reserved, the order will have a status of `REJECTED` (0025-OCRE-003) - Fees are charged as per [0029-FEES](./0029-FEES-fees.md). diff --git a/protocol/0026-AUCT-auctions.md b/protocol/0026-AUCT-auctions.md index a358bc1bf..dc190b537 100644 --- a/protocol/0026-AUCT-auctions.md +++ b/protocol/0026-AUCT-auctions.md @@ -157,18 +157,18 @@ message Market { ## Acceptance Criteria -- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). For product spot: (0026-AUCT-023) -- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). For product spot: (0026-AUCT-024) -- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). For product spot: (0068-MATC-060) -- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). For product spot:(0026-AUCT-025) -- As a user, I can get information through the API about a market in auction mode: indicative uncrossing price, indicative uncrossing volume. (0026-AUCT-006). For product spot: (0026-AUCT-026) -- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). For product spot: (0026-AUCT-027) -- As an API user, I can identify: (0026-AUCT-008). For product spot: (0026-AUCT-028) +- The duration of the auction period (time between close of voting and enactment time) at market creation cannot be below the minimum auction period defined within the network (0026-AUCT-003). +- As the Vega network, in auction mode, all orders are placed in the book but never uncross until the end of the auction period. (0026-AUCT-004). +- As a user, I can cancel an order that it either live on the order book or parked. (0068-MATC-033). +- As a user, I can get information about the trading mode of the market (through the [market framework](./0001-MKTF-market_framework.md)) (0026-AUCT-005). +- As a user, I can get information through the API about a market in auction mode: indicative uncrossing price, indicative uncrossing volume. (0026-AUCT-006). +- As a user, the market depth API provides the same data that would be sent during continuous trading (0026-AUCT-007). +- As an API user, I can identify: (0026-AUCT-008). - If a market is temporarily in an auction period - Why it is in that period (e.g. Auction at open, liquidity sourcing, price monitoring) - When the auction will next attempt to uncross or if the auction period ended and the auction cannot be resolved for whatever reason then this should come blank or otherwise indicating that the system doesn't know when the auction ought to end. - A market with default trading mode "continuous trading" will start with an opening auction. The opening auction will run from the close of voting on the market proposal (assumed to pass successfully) until: - 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017). For product spot, the enactment time assuming there are orders crossing on the book, there is no need for the supplied liquidity to exceed a threshold to exit an auction: (0026-AUCT-029) + 1. the enactment time assuming there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (0026-AUCT-017). 2. past the enactment time if there is no [liquidity supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). The auction won't end until sufficient liquidity is committed. (0026-AUCT-018) 3. past the enactment time if [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but the uncrossing volume will create open interest that is larger than what the [supplied stake can support](./0041-TSTK-target_stake.md). It will only end if - more liquidity is committed (0026-AUCT-019) @@ -176,5 +176,5 @@ message Market { 4. past the enactment time if there are orders crossing on the book and [liquidity is supplied](./0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) but after the auction uncrossing we will not have - best bid; it will still open. (0026-AUCT-021) - or best ask; it will still open. (0026-AUCT-022) -- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015). For product spot: (0026-AUCT-031) -- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016). For product spot: (0026-AUCT-032) +- When entering an auction, all GFN orders will be cancelled. (0026-AUCT-015). +- When leaving an auction, all GFA orders will be cancelled. (0026-AUCT-016). diff --git a/protocol/0028-GOVE-governance.md b/protocol/0028-GOVE-governance.md index 9686b198a..d1afeadfc 100644 --- a/protocol/0028-GOVE-governance.md +++ b/protocol/0028-GOVE-governance.md @@ -387,7 +387,7 @@ Any type of market (either fixed expiry market or perpetual) can be closed via a A proposal to close a market contains: -1. final settlement price (not required for spot markets) formatted accounting for market's decimal places +1. final settlement price formatted accounting for market's decimal places Once market is closed the process cannot be reversed. Note that this implies that once a governance proposal to close the market has been voted in the market will definitely close at the enactment time of that vote at the latest. While the market is still open it's still possible to submit additional governance votes to close the market, however they'll only have any effect if their enactment date is prior to that of the market closure proposal which has already passed. @@ -453,14 +453,6 @@ Notes: - The categorisation of parameters is liable to change and be added to as the protocol evolves. - As these are themselves network parameters, a set of parameters will control these parameters for the actions that update these parameters (including being self-referential), i.e. the parameter `Governance.UpdateNetwork.GovernanceProposalValidation.MinimumRequiredParticipation` would control the amount of voting participation needed to change these parameters. See the Network Parameters spec. -## Batch Proposals - -A `BatchProposalSubmission` is a top-level proposal type (living at the same level in a `Transaction` object as a standard `ProposalSubmission` ) which allows grouping of several related changes into a single proposal, ensuring that all changes will pass or fail governance voting together. The batch proposal is a wrapper containing the same `reference` and `rationale` fields as a standard `ProposalSubmission` alongside a repeated list of `ProposalSubmission`s. - -Validation should be applied by the protocol when accepting such a transaction that all proposals within the batch are of the same category for the purposes of ensuring voting thresholds and minimum voting periods can be uniquely determined. Additionally, the closing time of each proposal's voting period must be identical to ensure that a single voting period can be run to determine the result of all. The enactment timestamp, however, should be customisable and can be different for each proposal within the batch. - -Once submitted, a single voting period should be run in which participants may place a single vote to approve/disapprove of the entire batch. It should not be possible to vote for components in the batch separately. If the batch fails to pass the vote, the entire batch should be discarded as with any other proposal. If the batch passes, each of the component proposals should be enacted at their enactment timestamp exactly as if each had been proposed and passed individually. The enactment order of two proposals in the batch with the same enactment timestamp does not need to be defined and should be considered indeterminate from a user's point-of-view. - ## APIs The core should expose via core APIs: @@ -536,7 +528,7 @@ APIs should also exist for clients to: - A market change proposal that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the proposed modification is enacted. (0028-GOVE-070) - In particular a market change proposal that's to modify the parent market on a market in `pending` state (i.e. voting has successfully completed and the market is in the opening auction) will be accepted and if it's the enactment time happens to be before the opening auction ends then the parent is used (assuming the proposed parent doesn't already have a successor). (0028-GOVE-071) - A market change that's to modify any parameters on a market in `pending` state (i.e. voting has successfully completed on the market creation and the market is in the opening auction) will run voting rules the same as market creation proposals i.e. LPs don't get a vote. (0028-GOVE-072) -- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it (non-spot). (0028-GOVE-108) +- A governance proposal to close a market which doesn't specify the final settlement price gets rejected by the markets which require it. (0028-GOVE-108) - When there's already been a market closure governance proposal successfully voted in for a given market, but not yet enacted it is still possible to submit additional market closure governance proposals for that market. If another market closure governance proposal gets voted it and it has an earlier enactment time then it's the final settlement price of that proposal which gets used. (0028-GOVE-110) - Governance vote to suspend a market that's currently in continuous trading mode puts it into auction mode at vote enactment time. The only way to put the market back into continuous trading mode is with a successful governance vote to resume the market. (0028-GOVE-113) - Governance vote to suspend a market that's currently in auction trading mode keeps it in auction mode at vote enactment time. Even if the trigger that originally put the market into auction mode is no longer violated the market must remain in auction. (0028-GOVE-114) @@ -677,18 +669,6 @@ It is NOT possible to submit a governance proposal where the source account is t - Using a governance proposal to cancel, attempts to cancel an using an invalid transfer ID will result in a proposal rejection which states the transfer does not exist (0028-GOVE-125) - When a transfer is cancelled vega will produce an event conveying the cancellation to datanode. This will contain a cancellation status and zero transfer amount. No ledger events will be produced.(0028-GOVE-126) - -##### Batch Proposals - -- A batch proposal containing one or more component submissions for each type of proposal term can be submitted and is accepted as a valid proposal. (0028-GOVE-146) - -- A batch proposal containing component submissions with different categories will be rejected with an informative error message. (0028-GOVE-147) - -- A batch proposal submitted with component submissions having the same category but different closing timestamps will be rejected with an informative error message. (0028-GOVE-148) - -- A batch proposal submitted with component submissions having the same category and the same closing timestamps but different enactment timestamps will be accepted and move to voting. (0028-GOVE-149) - 1. If this proposal is accepted, each of the components will be enacted at the time of their differing enactment timestamps. (0028-GOVE-145) - ##### Network History - A datanode restored from network history will contain any recurring and one-off transfers created prior to the restore and these can be retrieved via APIs on the new datanode.(0028-GOVE-127) diff --git a/protocol/0029-FEES-fees.md b/protocol/0029-FEES-fees.md index 6573baea3..cbce1dbed 100644 --- a/protocol/0029-FEES-fees.md +++ b/protocol/0029-FEES-fees.md @@ -150,20 +150,20 @@ For example, Ether is 18 decimals (wei). The smallest unit, non divisible is 1 w ## Acceptance Criteria -- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001). For product spot: (0029-FEES-015) +- Fees are collected during continuous trading and auction modes and distributed to the appropriate accounts, as described above. (0029-FEES-001). - Fees are debited from the general (+ margin if needed) account on any market orders that during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and infrastructure (staking) pool. (0029-FEES-002) - Fees are debited from the general (+ margin if needed) account on the volume that resulted in a trade on any "aggressive / price taking" limit order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-003) - Fees are debited from the general (+ margin if needed) account on any "aggressive / price taking" pegged order that executed during continuous trading, the price maker gets the appropriate fee credited to their general account and the remainder is split between the market making pool and staking pool. (0029-FEES-004) -- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005). For product spot: (0029-FEES-016) +- Fees are collected in one case of amends: you amend the price so far that it causes an immediate trade. (0029-FEES-005). - During auctions, each side of a trade is debited 1/2 (infrastructure_fee + liquidity_fee) from their general (+ margin if needed) account. The infrastructure_fee fee is credited to the staking pool, the liquidity_fee is credited to the market making pool. (0029-FEES-006) - During continuous trading, if a trade is matched and the aggressor / price taker has insufficient balance in their general (+ margin if needed) account, then the trade doesn't execute if maintenance level of trade is not met. (0029-FEES-007) - During auctions, if either of the two sides has insufficient balance in their general (+ margin if needed) account, the trade still goes ahead only if the margin account should have enough left after paying the fees to cover maintenance level of margin for the orders and then converted trades. (0029-FEES-008) -- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009). For product spot: (0029-FEES-017) -- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010). For product spot: (0029-FEES-018) -- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011). For product spot: (0029-FEES-019) -- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012). For product spot: (0029-FEES-020) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013). For product spot: (0029-FEES-021) -- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014). For product spot: (0029-FEES-022) +- Changing parameters (via governance votes) does change the fees being collected appropriately even if the market is already running. (0029-FEES-009). +- A "buyer_fee" and "seller_fee" are exposed in APIs for every trade, split into the three components (after the trade definitely happened) (0029-FEES-010). +- Users should be able to understand the breakdown of the fee to the three components (by querying for fee payment transfers by trade ID, this requires enough metadata in the transfer API to see the transfer type and the associated trade.) (0029-FEES-011). +- The three component fee rates (fee_factor[infrastructure], fee_factor[maker], fee_factor[liquidity]) are available via an API such as the market data API or market framework. (0029-FEES-012). +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to 2. A market order of size 1.23 is placed which is filled at VWAP of 100. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `1.23 x 100 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-013). +- A market is set with [Position Decimal Places" (PDP)](0052-FPOS-fractional_orders_positions.md) set to -2. A market order of size 12300 is placed which is filled at VWAP of 0.01. We have fee_factor[infrastructure] = 0.001, fee_factor[maker] = 0.002, fee_factor[liquidity] = 0.05. The total fee charged to the party that placed this order is `12300 x 0.01 x (0.001 + 0.002 + 0.05) = 6.519` and is correctly transferred to the appropriate accounts / pools. (0029-FEES-014). ### Applying benefit factors diff --git a/protocol/0032-PRIM-price_monitoring.md b/protocol/0032-PRIM-price_monitoring.md index 3de366ae7..582e68a6b 100644 --- a/protocol/0032-PRIM-price_monitoring.md +++ b/protocol/0032-PRIM-price_monitoring.md @@ -109,23 +109,23 @@ to the risk model and obtains the range of valid up/down price moves per each of ## Acceptance Criteria -- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001). For product spot: (0032-PRIM-022) +- Market's price monitoring parameters and triggers (horizon, confidence level, auction extension triplet) can be queried via APIs. (0032-PRIM-001). - Non-persistent order does not result in an auction (1 out of 2 triggers breached), order gets cancelled (never makes it to the order book) -(0032-PRIM-003). For product spot: (0032-PRIM-023) -- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005). For product spot: (0032-PRIM-024) -- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006). For product spot: (0032-PRIM-025) -- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007). For product spot: (0032-PRIM-026) -- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008). For product spot: (0032-PRIM-027) -- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009). For product spot: (0032-PRIM-028) -- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010). For product spot: (0032-PRIM-029) -- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011). For product spot: (0032-PRIM-030) -- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012). For product spot: (0032-PRIM-031) -- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013). For product spot: (0032-PRIM-032) -- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014). For product spot: (0032-PRIM-033) -- Specifying a non-positive horizon results in an error. (0032-PRIM-015). For product spot: (0032-PRIM-034) -- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016). For product spot: (0032-PRIM-035) -- Specifying a non-positive auction extension results in an error. (0032-PRIM-017). For product spot: (0032-PRIM-036) +(0032-PRIM-003). +- The market continues in regular fashion once price protection auction period ends and price monitoring bounds get reset based on last traded price (which may come from the auction itself if it resulted in trades) (0032-PRIM-005). +- Persistent order results in an auction (one trigger breached), no orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-006). +- A maximum of `5` price monitoring triggers can be added per market (0032-PRIM-007). +- Persistent order results in an auction (1 out of 2 triggers breached), orders placed during auction result in trade with indicative price outside the price monitoring bounds of the 2nd trigger, hence auction get extended (by extension period specified for the 2nd trigger), additional orders resulting in more trades (indicative price still outside the 2nd trigger bounds) placed, auction concludes. (0032-PRIM-008). +- If the cumulative extensions period of various chained auctions is more than the "time horizon" in a given triplet then there is no relevant reference price and this triplet is ignored. (0032-PRIM-009). +- Change of `market.monitor.price.defaultParameters` will change the default market parameters used in price monitoring when a new market is proposed and market parameters don't get explicitly specified. (0032-PRIM-010). +- When market is in its default trading mode, change of `priceMonitoringParameters` results in price monitoring bounds being reset immediately. (0032-PRIM-011). +- When market is in its default trading mode, change of a risk model or any of its parameters results in price monitoring bounds being reset immediately. (0032-PRIM-012). +- When market is in price monitoring auction, change of `priceMonitoringParameters` doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-013). +- When market is in price monitoring auction, change of a risk model or any of its parameters doesn't affect the previously calculated auction end time, any remaining price monitoring bounds cannot extend the auction further. Upon uncrossing price monitoring bounds get reset using the updated parameter values. (0032-PRIM-014). +- Specifying a non-positive horizon results in an error. (0032-PRIM-015). +- Specifying a probability outside the range (0.9,1) results in an error. (0032-PRIM-016). +- Specifying a non-positive auction extension results in an error. (0032-PRIM-017). - Settlement price outside the current price monitoring bounds does not trigger an auction (0032-PRIM-018) - A network trade (during closeout) with a price outside price monitoring bounds does not trigger an auction. (0032-PRIM-019) -- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020). For product spot: (0032-PRIM-037) -- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021). For product spot: (0032-PRIM-038) +- Persistent order causing trade with the price outwith both bands triggers an auction. Initial auction duration is equal to the extension period of the first trigger. Once the initial period ends the auction gets extended by the extension period of the second trigger. No other orders placed during auction, auction terminates with a trade from order that originally triggered the auction. (0032-PRIM-020). +- Same as above, but more matching orders get placed during the auction extension. The volume of the trades generated by the later orders is larger than that of the original pair which triggered the auction. Hence the auction concludes generating the trades from the later orders. The overall auction duration is equal to the sum of the extension periods of the two triggers. (0032-PRIM-021). diff --git a/protocol/0033-OCAN-cancel_orders.md b/protocol/0033-OCAN-cancel_orders.md index 228d66663..7a48caf0b 100644 --- a/protocol/0033-OCAN-cancel_orders.md +++ b/protocol/0033-OCAN-cancel_orders.md @@ -2,15 +2,15 @@ ## Acceptance Criteria -- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001). For product spot: (0033-OCAN-011) -- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002). For product spot: (0033-OCAN-012) -- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003). For product spot: (0033-OCAN-013) -- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004). For product spot: (0033-OCAN-014) -- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005). For product spot: (0033-OCAN-015) +- An order cancelled by `orderID+marketID+partyID` will be removed from the order book and an order update message will be emitted (0033-OCAN-001). +- All orders for a given `partyID` will be removed from a single market if a cancel all party orders per market message is sent (0033-OCAN-002). +- All orders for a given party across all markets will be removed from the vega system when a cancel all orders message is sent (0033-OCAN-003). +- Orders which are not currently on the orderbook but are `parked` due to being in auction should also be affected by cancels. (0033-OCAN-004). +- A cancellation for a party that does not match the party on the order will be rejected (0033-OCAN-005). - Margins must be recalculated after a cancel event (0033-OCAN-007) - An order which is partially traded (has remaining volume), but still active, can be cancelled. (0033-OCAN-008) -- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009). For product spot: (0033-OCAN-016) -- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010). For product spot: (0033-OCAN-017) +- Cancelling an order for a party leaves its other orders on the current market unaffected. (0033-OCAN-009). +- Cancelling all orders on a market for a party by the "cancel all party orders per market message" leaves orders on other markets unaffected. (0033-OCAN-010). ## Summary diff --git a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb index 69ad2b8db..990e3f6ed 100644 --- a/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb +++ b/protocol/0034-PROB-prob_weighted_liquidity_measure.ipynb @@ -88,11 +88,11 @@ "\n", "Volume implied by the liquidity provision order is that given by [0034-PROB-liquidity_measure.feature](https://github.com/vegaprotocol/vega/blob/develop/integration/features/verified/0034-PROB-liquidity_measure.feature) The feature test has covered following scenarios:\n", "\n", - "1. Orders are correctly cumulated in order book's total size(0034-PROB-002). For product spot: (0034-PROB-003);\n", + "1. Orders are correctly cumulated in order book's total size(0034-PROB-002).;\n", "\n", - "2. Probability of trading decreases away from the mid-price (0034-PROB-005). For product spot: (0034-PROB-008).\n", + "2. Probability of trading decreases away from the mid-price (0034-PROB-005).\n", "\n", - "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter, hence will change the probability of trading used for comparing quality of committed liquidity. (0034-PROB-004). For product spot: (0034-PROB-010).\n", + "3. Change of `market.liquidity.probabilityOfTrading.tau.scaling` will immediately change the scaling parameter, hence will change the probability of trading used for comparing quality of committed liquidity. (0034-PROB-004).\n", "\n", "\n", "\n" diff --git a/protocol/0037-OPEG-pegged_orders.md b/protocol/0037-OPEG-pegged_orders.md index c3edc288f..dd254901f 100644 --- a/protocol/0037-OPEG-pegged_orders.md +++ b/protocol/0037-OPEG-pegged_orders.md @@ -15,7 +15,7 @@ - If the midprice is calculated to be a fraction (e.g. 102.5), it should be rounded up for a buy and rounded down for a sell. (0037-OPEG-011) - The order version is not updated during a repricing (0037-OPEG-012) - Pegged orders are included in the calculation of the BEST_BID, BEST_ASK and MID prices but excluded from BEST_STATIC_BID, BEST_STATIC_ASK and STATIC_MID (0037-OPEG-013) -- A parked pegged order can be amended. (0037-OPEG-014). For product spot: (0037-OPEG-019) +- A parked pegged order can be amended. (0037-OPEG-014). - A pegged order with an offset which would cause it to be priced <= 0 is parked. (0037-OPEG-017) - An active pegged order can be amended. (0037-OPEG-016) - A transaction submitting a pegged order with negative offset fails with an error explaining the cause was negative offset. (0037-OPEG-018) diff --git a/protocol/0039-MKTD-market_depth_calculation.md b/protocol/0039-MKTD-market_depth_calculation.md index 0a9203919..6af94f276 100644 --- a/protocol/0039-MKTD-market_depth_calculation.md +++ b/protocol/0039-MKTD-market_depth_calculation.md @@ -2,21 +2,21 @@ ## Acceptance Criteria -- The market depth builder must be able to handle all available order types (0039-MKTD-001). For product spot: (0039-MKTD-020) -- Entering and leaving auctions must be handled correctly (0039-MKTD-003). For product spot: (0039-MKTD-021) -- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004). For product spot: (0039-MKTD-022) -- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005) . For product spot: (0039-MKTD-023) -- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006). For product spot: (0039-MKTD-024) -- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007). For product spot: (0039-MKTD-025) -- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008). For product spot: (0039-MKTD-026) -- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009). For product spot: (0039-MKTD-027) -- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010). For product spot: (0039-MKTD-028) -- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012). For product spot: (0039-MKTD-029) -- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013). For product spot: (0039-MKTD-030) -- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014). For product spot: (0039-MKTD-033) +- The market depth builder must be able to handle all available order types (0039-MKTD-001). +- Entering and leaving auctions must be handled correctly (0039-MKTD-003). +- All subscribed clients must receive all the data necessary to build their own view of the market depth (0039-MKTD-004). +- Adding a new limit order to the book updates the market depth at the corresponding price and volume (0039-MKTD-005). +- Cancelling an existing order reduces the volume in the market depth view and removes the price level if the volume reaches zero (0039-MKTD-006). +- Fully or partially filling an order will reduce the market depth volume at that given price level (0039-MKTD-007). +- A GTT order that expires will cause the volume at its price to be reduced in the market depth view (0039-MKTD-008). +- Amending an order in place (price stays the same but the volume is reduced) will cause the volume at the given price to be reduced in the market depth view (0039-MKTD-009). +- Amending an order such that a cancel replace is performed will cause the volume in the market depth to be updated correctly (0039-MKTD-010). +- Entering an auction will cause any GFN orders to be removed from the market depth volume view (0039-MKTD-012). +- Market depth will show a crossed book if the market is in auction and the book is crossed (0039-MKTD-013). +- Leaving an auction will cause any GFA orders to be removed from the market depth view (0039-MKTD-014). - Pegged orders are part of the market depth view and should update the view when their orders are repriced (0039-MKTD-015) -- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018). For product spot: (0039-MKTD-031) -- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019). For product spot: (0039-MKTD-032) +- Each delta update will have the new sequence number along with the previous sequence number which will match the previous delta update (0039-MKTD-018). +- The sequence number received as part of the market depth snapshot will match the sequence number of a delta update (0039-MKTD-019). ## Summary diff --git a/protocol/0041-TSTK-target_stake.md b/protocol/0041-TSTK-target_stake.md index 0aae865b7..40a7cd340 100644 --- a/protocol/0041-TSTK-target_stake.md +++ b/protocol/0041-TSTK-target_stake.md @@ -68,32 +68,6 @@ Example 3: if `market.stake.target.scalingFactor = 10`, `rf = 0.004` and `max_oi - Change of `market.stake.target.scalingFactor` will immediately change the scaling between liquidity demand estimate based on open interest and target stake, hence immediately change the target stake. (0041-TSTK-004) - Change of `market.stake.target.timeWindow` will immediately change the length of time window over which open interest is measured, hence will immediately change the value of `max_oi`. (0041-TSTK-005) -## Target stake for spot markets - -See [spot market spec](0080-SPOT-product_builtin_spot.md).3600s - -The target stake of a market is calculated as a fraction of the maximum `total_stake` over a rolling time window. The fraction is controlled by the parameter `scaling_factor` and the length of the window is controlled by the parameter `time_window`. - -```pseudo -e.g. - -Given: the following total_stake values - - [time, total_stake] = [[17:59, 12000], [18:01, 11000], [18:30, 9000], [18:59, 10000]] - -If: the time value and market parameters are - - current_time = 19:00 - - time_window = 3600s - target_stake_factor = 0.25 - -Then: the target stake value is - - target_stake = 0.25 * 11000 = 2750 DAI -``` - -The above design ensures the `target_stake` of a market is unable to fluctuate dramatically over the window. Controlling the `target_stake` impacts the `total_stake` as reducing the commitment beyond `maximum_reduction_amount` means the LPs will be charged a penalty for doing so. ### Acceptance criteria diff --git a/protocol/0043-MKTL-market_lifecycle.md b/protocol/0043-MKTL-market_lifecycle.md index 6d9678d33..4fd63f259 100644 --- a/protocol/0043-MKTL-market_lifecycle.md +++ b/protocol/0043-MKTL-market_lifecycle.md @@ -244,7 +244,6 @@ After `market.liquidity.successorLaunchWindowLength` has elapsed since the settl ### Market is proposed but rejected (0043-MKTL-001) -For product spot: (0043-MKTL-005) 1. Market `m1` is proposed with an internal trading terminated oracle set for some time in the future. Price monitoring is configured (e.g. like `2668-price-monitoring.feature`). Market state is `proposed`. diff --git a/protocol/0044-LIME-lp_mechanics.md b/protocol/0044-LIME-lp_mechanics.md index 291174d44..8ee5da6df 100644 --- a/protocol/0044-LIME-lp_mechanics.md +++ b/protocol/0044-LIME-lp_mechanics.md @@ -92,7 +92,7 @@ Liquidity provider bond account: - A liquidity provider can only prompt a transfer of funds to or from this account by (re)submitting the LP commitment transaction: a valid transaction to create, increase, or decrease their commitment to the market. - Transfers to/from this account also occur when it is used for settlement or margin shortfall, when penalties are applied, and if the account is under-collateralised because of these uses and is subsequently topped up to the commitment amount during collateral search (see below) - Collateral withdrawn from this account may only be transferred to either: - - The insurance pool of the market for markets trading on margin or the network treasury for the asset (for spot markets) (in event of penalties/slashing) + - The insurance pool of the market for markets trading on margin (in event of penalties/slashing) - The liquidity provider's margin account or the network's settlement account/other participant's margin accounts (during a margin search and mark to market settlement) in the event that they have zero balance in their general account. - The liquidity provider's general account (in event of liquidity provider reducing their commitment) @@ -157,7 +157,6 @@ $$ Transfer $\text{maximum-penalty-free-reduction-amount}_i$ to their general account. Now transfer $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ to their general account and transfer $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ to the market insurance pool. -Note that in the case of spot market or any market that isn't running an insurance pool the transfer should go into the network treasury for the asset. Finally update the ELS as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md) using the entire $\text{commitment-variation}_i$ as the `delta`. @@ -245,12 +244,11 @@ f = \max\left[0,\min\left(m, p \cdot (1 - \frac{t}{s})\right)\right]\,. $$ Once you have $f$ transfer $f \times B$ into the insurance pool of the market, where $B$ is the LP bond account balance. -For spot markets, the transfer is to go into the network treasury account for the asset. + Moreover, as this reduced the LP stake, update the ELS as per [Calculating liquidity provider equity-like share section in 0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). In the case of if a liquidity provider has `fraction_of_time_on_book = 0`, and `market.liquidity.commitmentMinTimeFraction = 0`, then `f = max[0,min(m,p)]` -In the case of spot markets the transfer goes into the network treasury account for the asset. ### Penalty for not supporting open positions @@ -311,13 +309,10 @@ Note: - If a liquidity provider has `fraction_of_time_on_book` >= `market.liquidity.commitmentMinTimeFraction`, no penalty will be taken from their bond account (0044-LIME-013) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `35%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-014) -and in the case of spot markets into the network treasury for the asset (0044-LIME-048) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.3` is enacted during the epoch then at the end of the current epoch LP will have their bond slashed. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch, they are meeting their commitment and will not forfeit any of their bond stake. (0044-LIME-088) - If a liquidity provider has `fraction_of_time_on_book` = `0.3`, `market.liquidity.commitmentMinTimeFraction = 0.0`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6`and the market parameter change `market.liquidity.commitmentMinTimeFraction = 0.6` is enacted during the epoch then at the end of the current epoch LP will not forfeit any of their bond stake. If the LP has `fraction_of_time_on_book` = `0.3` at the end of the next epoch at the end of the next epoch, the LP will have their bond slashed. (0044-LIME-089) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.7`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `60%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-015) -and in the case of spot markets into the network treasury for the asset (0044-LIME-046) - If a liquidity provider has `fraction_of_time_on_book` = `0`, `market.liquidity.commitmentMinTimeFraction = 0.6`, `market.liquidity.sla.nonPerformanceBondPenaltySlope = 0.2`, `market.liquidity.sla.nonPerformanceBondPenaltyMax = 0.6` at the end of an epoch then they will forfeit `20%` of their bond stake, which will be transferred into the market's insurance pool (0044-LIME-016) -and in the case of spot markets into the network treasury for the asset (0044-LIME-047) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. (0044-LIME-018) - If a liquidity provider with an active liquidity provision at the start of an epoch reduces their liquidity provision staked commitment during the epoch the initial committed level at the start of the epoch will remain in effect until the end of the epoch, at which point the protocol will attempt to reduce the bond to the new level. If the reduced level has been changed several times during an epoch, only the latest value will take effect (0044-LIME-019) @@ -330,14 +325,10 @@ and in the case of spot markets into the network treasury for the asset (0044-LIME-022) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `target stake > total stake` already, a liquidity provider who reduces their commitment by `100` will only receive `75` back into their general account with `25` transferred into the market's insurance account. (0044-LIME-023) -In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-045) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 40` already, a liquidity provider who reduces their commitment by `100` will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-024) -- In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-044) - For a market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if one liquidity provider places a transaction to reduce their stake by `100` followed by a second liquidity provider who reduces their commitment by `100`, the first liquidity provider will receive a full `100` stake back whilst the second will receive a total of `85` back into their general account with `15` transferred into the market's insurance account (`40` received without penalty, then the remaining `60` receiving a `25%` penalty). (0044-LIME-025) -In the case of spot markets it will be transferred into the network treasury for the asset (0044-LIME-043) - - For a futures market with `market.liquidity.earlyExitPenalty = 0.25` and `total stake = target stake + 140` already, if the following transactions occur: @@ -350,8 +341,8 @@ In the case of spot markets it will be transferred into the network treasury for - When a LP increases their commitment then: - It takes effect immediately for the purposes of LP stake supplied to the market - In terms of the liquidity they are expected to supply: this only takes effect from the start of the next epoch - (0044-LIME-050). For spot (0044-LIME-054) - - LP can decrease or cancel their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). For spot (0044-LIME-055) + (0044-LIME-050) + - LP can decrease or cancel their commitment and it will take effect immediately without incurring penalties (0044-LIME-051). - If target stake is 0 then any LP can cancel their commitment without incurring penalties (0044-LIME-053) - Consider a market in liquidity auction, when a LP increases their commitment it will take effect immediate for the purposes of LP stake supplied to the market. Where LP `supplied stake > target stake` the market will leave liquidity auction when the liquidity auction ends @@ -359,7 +350,7 @@ In the case of spot markets it will be transferred into the network treasury for (0044-LIME-102) - For a market that is in continuous trading and a single LP has committed liquidity: - - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060). For spot (0044-LIME-056) + - The LP can cancel their commitment at any time (though this may involve incurring a penalty) (0044-LIME-060). - During continuous trading an LP can submit a transaction to decrease commitment but it will only happen at the end of current epoch. (0044-LIME-101) - For a market that is in continuous trading and LP has committed liquidity @@ -382,21 +373,21 @@ In the case of spot markets it will be transferred into the network treasury for - Consider a market, where `market.liquidity.priceRange = 0.05`, and which is in monitoring auction with `last trade price` set to `5` and we do not have `indicative uncrossing price`. There is a LP who's committed to provide liquidity. They place a buy orders at price `4.75` and sell order at price `5.25`. At the end of the epoch, the LP is meeting their committed volume of notional rendering them exempt from a bond penalty. (0044-LIME-092) -- When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063). For spot (0044-LIME-064) -- When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065). For spot (0044-LIME-066) -- When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067). For spot $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into the network treasury for the asset (0044-LIME-068) -- When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069). For spot (0044-LIME-070) -- When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071). For spot (0044-LIME-072) -- A distressed LP (when `bond account == 0 && general account == 0 && margin account < maintenance margin`) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073). For spot (0044-LIME-074) -- If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075). For spot (0044-LIME-076) +- When the LP increases its commitment and the increment is higher than its general account balance, the increments are rejected, and the old provision persists. (0044-LIME-063). +- When LP decreases its commitment so that $\text{commitment-variation}_i <= \text{maximum-penalty-free-reduction-amount}_i$, then the entire amount by which they decreased their commitment is transferred to their general account, their ELS got updated as per the [ELS calculation](0042-LIQF-setting_fees_and_rewarding_lps.md)(0044-LIME-065). +- When LP decreases its commitment so that $\text{commitment-variation}_i > \text{maximum-penalty-free-reduction-amount}_i$ , $(1-\text{market.liquidity.earlyExitPenalty}) \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into its general account and $\text{market.liquidity.earlyExitPenalty} \cdot \text{penalty-incurring-reduction-amount}_i$ should be transferred into market insurance pool (0044-LIME-067). +- When an LP creates a new provision with zero commitment, it should be rejected with an error message stating that the commitment amount is zero. (0044-LIME-069). +- When an LP amends the Fee Factor to a value greater than `market.liquidity.maximumLiquidityFeeFactorLevel`, the amendments are rejected (0044-LIME-071). +- A distressed LP (when `bond account == 0 && general account == 0 && margin account < maintenance margin`) will have their orders cancelled. If the LP remains distressed, the network takes over any positions the LP may hold and zeroes them out (closes them out) (0044-LIME-073). +- If a party submits LP provisions in multiple markets then multiple bond accounts are created and managed by Vega.(0044-LIME-075). ### Qualifying Order Types -- Once liquidity is committed, LPs can meet their commitment by placing limit orders, pegged limit orders, and iceberg orders. For iceberg orders, all the volume (including displayed and remaining volume) counts towards the commitment. (0044-LIME-028). For spot (0044-LIME-029) -- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077). For spot (0044-LIME-078) -- GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079). For spot (0044-LIME-080) -- GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081). For spot (0044-LIME-082) +- Once liquidity is committed, LPs can meet their commitment by placing limit orders, pegged limit orders, and iceberg orders. For iceberg orders, all the volume (including displayed and remaining volume) counts towards the commitment. (0044-LIME-028). +- Parked pegged limit orders and stop-loss orders do not count towards an LPs liquidity commitment. (0044-LIME-077). +- GFA orders during auction from LP count towards LPs liquidity commitment (0044-LIME-079). +- GFA orders during continuous trading mode from LP do not count towards the LP's liquidity commitment (0044-LIME-081). ### Snapshot @@ -432,4 +423,3 @@ In the case of spot markets it will be transferred into the network treasury for - `market.liquidity.priceRange` valid values: `>0`, `<=20` (0044-LIME-084) - `market.liquidity.slaCompetitionFactor` valid values: `>=0`, `<=1` (0044-LIME-085) - `market.liquidity.performanceHysteresisEpochs` valid values: `>=0`, `<=366` (0044-LIME-086) - diff --git a/protocol/0049-TVAL-validate_transaction_preconsensus.md b/protocol/0049-TVAL-validate_transaction_preconsensus.md index 608c065a2..251d67517 100644 --- a/protocol/0049-TVAL-validate_transaction_preconsensus.md +++ b/protocol/0049-TVAL-validate_transaction_preconsensus.md @@ -29,14 +29,8 @@ Future enhancements: for each root transaction message type (e.g. `SubmitOrder`, Note that separate pre-consensus validation is carried out as part of PoW anti-spam checks, see the acceptance criteria in [PoW spec](./0072-SPPW-spam-protection-PoW.md). 1. Transaction is included in the block if signed with a non-validator's key, includes [correct PoW data](./0072-SPPW-spam-protection-PoW.md) and is not a governance transaction. (0049-TVAL-001) - 1. for product spot: (0049-TVAL-007) 1. Transaction is with wrong / missing key is rejected. (0049-TVAL-002) - 1. for product spot: (0049-TVAL-008) 1. Transaction is rejected (never included in a block) if it is a transfer and is from a party with less than the [quantum](./0041-TSTK-target_stake.md) balance of the source asset (0049-TVAL-003) - 1. for product spot: (0049-TVAL-009) 1. Transaction is rejected (never included in a block) if a party has strictly less than the [quantum](./0041-TSTK-target_stake.md) balance in the settlement asset of the market and it is submitting any kind of orders (limit, market, LP provision) (0049-TVAL-004) - 1. for product spot: (0049-TVAL-010) 1. Transaction interacting in a market is included in a block if signed with a key from a non-validator party with a balance >= [quantum](./0041-TSTK-target_stake.md) of the settlement asset for the market, where an identical (apart from PoW proof and block data details) transaction was rejected from a previous block when the party had relevant balance < less than relevant [quantum](./0041-TSTK-target_stake.md) (0049-TVAL-005) - 1. for product spot: (0049-TVAL-011) 1. Transaction sent to a non-validator node is propagated to validator and included in a block. (0049-TVAL-006) - 1. for product spot: (0049-TVAL-012) diff --git a/protocol/0051-PROD-product.md b/protocol/0051-PROD-product.md index ce2142f19..4d186b9aa 100644 --- a/protocol/0051-PROD-product.md +++ b/protocol/0051-PROD-product.md @@ -119,12 +119,12 @@ APIS should be available to: Settlement assets: -- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001). For product spot: (0051-PROD-004). For product perpetual: (0051-PROD-007) -- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002). For product spot: (0051-PROD-005). For product perpetual: (0051-PROD-008) +- A product of any type cannot be created without specifying at least one settlement asset (0051-PROD-001). For product perpetual: (0051-PROD-007) +- The settlement asset or assets must exist at the time when the product is created (0051-PROD-002). For product perpetual: (0051-PROD-008) Product updates via governance: -- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003). For product spot: (0051-PROD-006). F for product perpetual: (0051-PROD-009) +- The settlement asset / settlement assets cannot be changed on a product via governance (0051-PROD-003). F for product perpetual: (0051-PROD-009) ## See also diff --git a/protocol/0052-FPOS-fractional_orders_positions.md b/protocol/0052-FPOS-fractional_orders_positions.md index 202c3726b..3699a4fd3 100644 --- a/protocol/0052-FPOS-fractional_orders_positions.md +++ b/protocol/0052-FPOS-fractional_orders_positions.md @@ -19,8 +19,8 @@ Specs affected by this change (Note: in many cases the implementation may not ch ## Acceptance Criteria -- All proposed markets will have a decimal places property available via the API (0052-FPOS-001). For product spot: (0052-FPOS-003) -- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002). For product spot: (0052-FPOS-004) +- All proposed markets will have a decimal places property available via the API (0052-FPOS-001). +- An order created on the client with a price of `1` results in an order being created with a price of `1 * 10^[Market.DecimalPlaces]` (0052-FPOS-002). - Fees are calculated as per ([0029-FEES-013](./0029-FEES-fees.md#0029-FEES-013)) - Mark-to-market settlement happens correctly with PDP > 0 ([0003-MTMK-0015](./0003-MTMK-mark_to_market_settlement.md#0003-MTMK-015)) - Margins are correctly calculated for markets with PDP > 0 ([0019-MCAL-008](./0019-MCAL-margin_calculator.md#0019-MCAL-008)). diff --git a/protocol/0054-NETP-network_parameters.md b/protocol/0054-NETP-network_parameters.md index baecaf000..8d6da001d 100644 --- a/protocol/0054-NETP-network_parameters.md +++ b/protocol/0054-NETP-network_parameters.md @@ -91,9 +91,9 @@ The current network parameters are specified in the code specifiying the min and ## Acceptance criteria -- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001). For product spot: (0054-NETP-007) -- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002). For product spot: (0054-NETP-008) +- All network parameter set in `genesis.json` can be queried and the values returned are the correct ones (unless overridden by [LNL checkpoint](./0073-LIMN-limited_network_life.md) value). (0054-NETP-001). +- For `blockchains.ethereumConfig` set in `genesis.json` a governance proposal to change this parameter will be rejected with a rejection error `network parameter update disabled for blockchains.ethereumConfig`. (0054-NETP-002). - For `market.margin.scalingFactors` set in `genesis.json` or in a governance proposal we validate the format and the fact that "1.0 <= search <= initial <= release"; if these are invalid a useful error is returned. (0054-NETP-003) -- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004). For product spot: (0054-NETP-009) -- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005). For product spot: (0054-NETP-010) -- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006). For product spot: (0054-NETP-011) +- For `market.monitor.price.defaultParameters` set in `genesis.json` or in a governance proposal we validate the format; if these are invalid a useful error is returned. (0054-NETP-004). +- For each of the remaining parameter whether set in `genesis.json` or in a governance proposal we validate the data type, reject invalid and validate the range of allowable values; if these are invalid a useful error is returned. (0054-NETP-005). +- All network parameter ranges, as specified in the [defaults](https://github.com/vegaprotocol/vega/blob/develop/core/netparams/defaults.go) file, are not able to be set less or greater than the range bondaries. (0054-NETP-006). diff --git a/protocol/0056-REWA-rewards_overview.md b/protocol/0056-REWA-rewards_overview.md index 169ff1743..5f2ede06f 100644 --- a/protocol/0056-REWA-rewards_overview.md +++ b/protocol/0056-REWA-rewards_overview.md @@ -282,8 +282,6 @@ $$s_{i} = \frac{d_{i}}{\sum_{i=1}^{n}d_{i}}$$ ### Funding reward accounts (0056-REWA-001) -for product spot: (0056-REWA-062) - Trading reward accounts are defined by a pair: [`payout_asset, dispatch_strategy`]. There are two assets configured on the Vega chain: $VEGA and USDT. @@ -296,8 +294,6 @@ Run for another epoch with no fee generated. Expect no transfer to be made to th ### Funding reward accounts - with markets in scope (0056-REWA-002) -for product spot: (0056-REWA-061) - There are two assets configured on the Vega chain: $VEGA and USDT. Setup a recurring transfer of 1000 $VEGA with the following dispatch strategy: asset=`USDT`, metric=`DISPATCH_METRIC_TAKER_FEES_PAID`, markets=[`market1`, `market2`]. @@ -308,8 +304,6 @@ Run for another epoch with no fee generated. Expect no transfer to be made to th ### Distributing fees paid rewards (0056-REWA-010) -for product spot: (0056-REWA-060) - #### Rationale 1 A market has 2 reward accounts for the metric, one paying in $VEGA and the other paying in USDC. @@ -357,8 +351,6 @@ At the end of epoch 2: ### Distributing fees paid rewards - unfunded account (0056-REWA-011) -for product spot: (0056-REWA-059) - #### Rationale 2 This is identical to [acceptance code `REWA 010`](https://github.com/vegaprotocol/specs/blob/master/protocol/0056-REWA-rewards_overview.md#distributing-fees-paid-rewards-0056-rewa-010) just without funding the corresponding reward account. @@ -377,8 +369,6 @@ At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, n ### Distributing fees paid rewards - funded account - no trading activity (0056-REWA-012) -for product spot: (0056-REWA-058) - #### Rationale 3 After having an epoch with trading activity, fund the reward account, but have no trading activity and assert that no payout is made. @@ -403,8 +393,6 @@ Looking only at epoch 3 - as no trading activity was done, we expect the reward ### Distributing fees paid rewards - multiple markets (0056-REWA-013) -for product spot: (0056-REWA-057) - #### Rationale 4 There are multiple markets, each paying its own reward where due. @@ -444,8 +432,6 @@ The calculation of eligibility is identical to [acceptance code `REWA 010`](http ### Distributing maker fees received rewards (0056-REWA-020) -for product spot: (0056-REWA-056) - #### Rationale 5 A market has 2 reward accounts for the metric, one paying in $VEGA and the other paying in USDC. @@ -491,8 +477,6 @@ At the end of epoch `2` `party_0` is paid `120 x 2.8 / (2.79+2.8)` USDC from the ### Distributing maker fees received rewards - unfunded account (0056-REWA-021) -for product spot: (0056-REWA-055) - #### Rationale 6 This is identical to [acceptance code `REWA 020`](https://github.com/vegaprotocol/specs/blob/master/protocol/0056-REWA-rewards_overview.md#distributing-maker-fees-received-rewards-0056-rewa-020) just without funding the corresponding reward account. @@ -511,7 +495,6 @@ At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, n ### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-022) -for product spot: (0056-REWA-054) #### Rationale 7 @@ -537,7 +520,6 @@ Looking only at epoch 3 - as no trading activity was done, we expect the reward ### Distributing maker fees received rewards - multiple markets (0056-REWA-023) -for product spot: (0056-REWA-053) #### Rationale 8 @@ -578,7 +560,6 @@ The calculation of eligibility is identical to [acceptance code `REWA 020`](http ### Distributing LP fees received rewards (0056-REWA-030) -for product spot: (0056-REWA-052) #### Rationale 9 @@ -605,8 +586,6 @@ At the end of epoch `2` `party_0` is paid `120` `USDC` from the reward account i ### Distributing LP fees received rewards - unfunded account (0056-REWA-031) -for product spot: -(0056-REWA-051) #### Rationale 10 @@ -626,7 +605,6 @@ At the end of epoch 2 although there was trading in the market `ETHUSD-MAR22`, n ### Distributing maker fees received rewards - funded account - no trading activity (0056-REWA-032) -for product spot: (0056-REWA-063) #### Rationale 11 @@ -652,7 +630,6 @@ Looking only at epoch 3 - as no trading activity was done, we expect the reward ### Distributing LP fees received - multiple markets (0056-REWA-033) -for product spot: (0056-REWA-064) #### Rationale 12 @@ -679,7 +656,6 @@ The calculation of eligibility is identical to [acceptance code `REWA-030`](http ### Distributing market creation rewards - no eligibility (0056-REWA-040) -for product spot: (0056-REWA-065) #### Rationale 13 @@ -700,7 +676,6 @@ At the end of the epoch no payout has been made for the market `ETHUSDT` and the ### Distributing market creation rewards - eligible are paid no more than once (0056-REWA-041) -for product spot: (0056-REWA-066) #### Rationale 14 @@ -724,7 +699,6 @@ At the end of epoch 3 make sure that no transfer is made to the reward account a ### Distributing market creation rewards - account funded after reaching requirement (0056-REWA-042) -for product spot: (0056-REWA-067) #### Rationale 15 @@ -747,7 +721,6 @@ The reward pool balance should be 0. ### Distributing market creation rewards - multiple asset rewards (0056-REWA-043) -for product spot: (0056-REWA-068) #### Rationale 16 @@ -771,7 +744,6 @@ The reward pool balance should be 0. ### Distributing market creation rewards - multiple asset rewards simultaneous payout (0056-REWA-045) -for product spot: (0056-REWA-069) #### Rationale 17 @@ -796,7 +768,6 @@ The reward pool balance should be 0. ### Distributing market creation rewards - Same asset multiple party rewards (0056-REWA-044) -for product spot: (0056-REWA-070) #### Rationale 18 @@ -826,7 +797,6 @@ The reward account balance should still be empty, as there were no eligible mark ### Distributing market creation rewards - Multiple markets eligible, one already paid (0056-REWA-046) -for product spot: (0056-REWA-071) #### Rationale 19 @@ -860,7 +830,6 @@ At the end of epoch 3, 10000 VEGA should be split between the `BTCDAI` creator a ### Reward accounts cannot be topped up with a one-off transfer (0056-REWA-049) -for product spot: (0056-REWA-072) The following account types require metric-based distribution. As a one-off transfer cannot specify how it is rewarded, one-off transfers to metric-based reward pools must be **rejected**. A one-off transfer from a user to any of the following account types is rejected. No assets are transferred: @@ -872,7 +841,6 @@ A one-off transfer from a user to any of the following account types is rejected ### Distributing market creation rewards - Market ineligible through metric asset (0056-REWA-048) -for product spot: (0056-REWA-073) #### Rationale 20 @@ -898,7 +866,6 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to only the `ETH ### Distributing market creation rewards - Multiple markets eligible, one already paid, specified asset (0056-REWA-047) -for product spot: (0056-REWA-074) #### Rationale 21 @@ -934,8 +901,6 @@ At the end of epoch 3, 10000 VEGA should be distributed split between the `BTCUS ### Updating the network parameter `rewards.marketCreationQuantumMultiple` (0056-REWA-050) -for product spot: (0056-REWA-075) - #### Rationale 22 When the network parameter `rewards.marketCreationQuantumMultiple` is changed via governance, the change should take affect diff --git a/protocol/0057-TRAN-transfers.md b/protocol/0057-TRAN-transfers.md index 2082e4b2c..146d2402e 100644 --- a/protocol/0057-TRAN-transfers.md +++ b/protocol/0057-TRAN-transfers.md @@ -229,7 +229,6 @@ message CancelTransfer { - As a user I cannot transfer funds from accounts that I do not control. (0057-TRAN-005) - As a user I cannot transfer funds from accounts I own but from the type is not supported: - for accounts created in a futures market, bond and margin (0057-TRAN-006) - - for accounts created in a spot market, bond and holding (0057-TRAN-063) - As a user I can do a transfer from any of the valid accounts (I control them and they're a valid source), and fees are taken from the source account when the transfer is executed. (0057-TRAN-007) - The fee cost is correctly calculated using the network parameter - If I have enough funds to pay transfer and fees, the transfer happens. diff --git a/protocol/0065-FTCO-floating_point_consensus.md b/protocol/0065-FTCO-floating_point_consensus.md index f6309d68c..f9f88609e 100644 --- a/protocol/0065-FTCO-floating_point_consensus.md +++ b/protocol/0065-FTCO-floating_point_consensus.md @@ -84,7 +84,7 @@ This section outlines floating-point quantities `vega` currently relies on: ## Acceptance criteria -1. Floating-point values get initialised and updated correctly (0065-FTCO-001). For product spot: (0065-FTCO-005) +1. Floating-point values get initialised and updated correctly (0065-FTCO-001). - A market is proposed and initially it has the following default values: - Risk factors: - Short: 1.0 @@ -100,12 +100,12 @@ This section outlines floating-point quantities `vega` currently relies on: - When the time-based trigger elapses price monitoring bounds and probability of trading get recalculated. - When the market goes into liquidity monitoring auction the state variables stay the same as prior to its' start, when that auction concludes (choose a price that's not been traded at before) price monitoring bounds and probability of trading get recalculated again and the time-based trigger countdown gets reset. -1. Event announcing diverging values gets emitted (0065-FTCO-004). For product spot: (0065-FTCO-006) +1. Event announcing diverging values gets emitted (0065-FTCO-004). - For all the state variables nodes submit candidate values that differ by up to half the tolerance. - The event announcing the fact that at least one of the values differed gets emitted. - Since differences are within tolerance the consensus successfully chooses a consensus value and systems keeps running as expected (market goes into continuous trading mode accepts orders and generates trades). -1. Consensus failure event gets emitted (0065-FTCO-002). For product spot: (0065-FTCO-007) +1. Consensus failure event gets emitted (0065-FTCO-002). - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get submitted by nodes, one of the nodes submits a value that is higher than tolerance. - An appropriate event is sent to signal that at least one of the values differed. @@ -115,7 +115,7 @@ This section outlines floating-point quantities `vega` currently relies on: - Situation continues for 2 more risk factor update attempts (can be time-based or auction). - Market still runs with previously calculated risk factors, but an event informing that the market is using stale values gets emitted. -1. Market cannot leave opening auction with default values (0065-FTCO-003). For product spot: (0065-FTCO-008) +1. Market cannot leave opening auction with default values (0065-FTCO-003). - A market is proposed and initially has default values specified in the scenario above. - Upon market enactment risk factors get calculated (their values change from defaults). - When the opening auction sees uncrossing price for the first time (there are two overlapping orders from buy and sell side on the order book) price monitoring bounds get calculated, but probability of trading get doesn't pass consensus (all nodes submit conflicting values) diff --git a/protocol/0068-MATC-matching_engine.md b/protocol/0068-MATC-matching_engine.md index a1b61a174..faf8fd03a 100644 --- a/protocol/0068-MATC-matching_engine.md +++ b/protocol/0068-MATC-matching_engine.md @@ -8,13 +8,13 @@ The matching engine co-ordinates the trading of incoming orders with existing or An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001). For product spot: (0068-MATC-061) - - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002). For product spot: (0068-MATC-062) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003). For product spot: (0068-MATC-063) - - If there is no match the order will be cancelled. (0068-MATC-004). For product spot: (0068-MATC-064) - - If there is a partial match then the remaining will be cancelled. (0068-MATC-005). For product spot: (0068-MATC-065) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book (0068-MATC-001). + - If not enough volume is available to **fully** fill the order, the remaining will be cancelled (0068-MATC-002). +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will be matched against the opposite side of the book, (0068-MATC-003). + - If there is no match the order will be cancelled. (0068-MATC-004). + - If there is a partial match then the remaining will be cancelled. (0068-MATC-005). - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-006) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057). For product spot: (0068-MATC-066) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-057). - For Reduce-Only = True orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-056) @@ -27,12 +27,12 @@ An [Immediate or Cancel (IOC)](./0014-ORDT-order_types.md#time-in-force--validit A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008). For product spot: (0068-MATC-067) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) MARKET orders will be matched fully if the volume is available, otherwise the order is cancelled. (0068-MATC-008). - Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders will either be: - - Fully matched if possible to the other side of the book (0068-MATC-009). For product spot: (0068-MATC-068) - - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010). For product spot: (0068-MATC-069) + - Fully matched if possible to the other side of the book (0068-MATC-009). + - if a complete fill is not possible the order is stopped without trading at all. (0068-MATC-010). - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-011) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039). For product spot: (0068-MATC-070) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be rejected by the wallet as they are not valid. (0068-MATC-039). - For Reduce-Only = TRUE orders: - Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders which reduce the trader's absolute position will be matched against the opposite side of the book (0068-MATC-047) @@ -45,48 +45,48 @@ A [Fill or KILL (FOK)](./0014-ORDT-order_types.md#time-in-force--validity) order For [Good 'Til Time (GTT) / Good 'Till Cancelled (GTC) / Good For Normal (GFN)](./0014-ORDT-order_types.md#time-in-force--validity) orders: -- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013). For product spot: (0068-MATC-071) -- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014). For product spot: (0068-MATC-072) +- Incoming [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected by the wallet validation layer. (0068-MATC-013). +- Incoming [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders match if possible, any remaining is placed on the book. (0068-MATC-014). - Incoming [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced and placed on the book if the price is valid, except GFN which are rejected by the wallet validation layer. (0068-MATC-015) - otherwise they are parked. (0068-MATC-016) -- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040). For product spot: (0068-MATC-073) - - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041). For product spot: (0068-MATC-074) - - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042). For product spot: (0068-MATC-075) +- Incoming [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders will be placed fully on the book if no orders currently cross. (0068-MATC-040). + - An order which totally crosses with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-041). + - An order partially crossing with an existing order on the book will be STOPPED in full with none executed. (0068-MATC-042). - A market will enter auction if the volume on either side of the book is empty. (0068-MATC-017) -- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018). For product spot: (0068-MATC-076) -- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019). For product spot: (0068-MATC-077) +- A market will enter auction if the mark price moves by a larger amount than the price monitoring settings allow. (0068-MATC-018). +- All attempts to [self trade](./0024-OSTA-order_status.md#wash-trading) are prevented and the aggressive side is STOPPED even if partially filled. The passive side is left untouched. (0068-MATC-019). - All orders with Reduce-Only set to TRUE are rejected as invalid. (0068-MATC-054) In a market that is currently in [Auction Trading](./0026-AUCT-auctions.md): - [IOC/FOK/GFN](./0014-ORDT-order_types.md#time-in-force--validity) - - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021). For product spot: (0068-MATC-078) + - Incoming orders have their status set to REJECTED and are not processed further. (0068-MATC-021). - [GTC/GTT/GFA](./0014-ORDT-order_types.md#time-in-force--validity) - - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022). For product spot: (0068-MATC-079) - - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023). For product spot: (0068-MATC-080) - - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055). For product spot: (0068-MATC-081) - - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024). For product spot: (0068-MATC-082) + - All [MARKET](./0014-ORDT-order_types.md#order-pricing-methods) orders are rejected. (0068-MATC-022). + - [LIMIT](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-023). + - [LIMIT: POST-ONLY TRUE](./0014-ORDT-order_types.md#order-pricing-methods) orders are placed into the book and no matching takes place. (0068-MATC-055). + - The indicative price and volume values are updated after every change to the order book. (0068-MATC-024). - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are parked (and have their status set to PARKED). (0068-MATC-025) - - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038). For product spot: (0068-MATC-083) + - It is possible to [self trade](./0024-OSTA-order_status.md#wash-trading) to uncross an auction. (0068-MATC-038). When a [market moves into an auction](./0026-AUCT-auctions.md#upon-entering-auction-mode): - All [PEGGED](./0014-ORDT-order_types.md#auction) orders are parked (and have their status set to PARKED). (0068-MATC-026) -- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027). For product spot: (0068-MATC-084) -- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028). For product spot: (0068-MATC-085) +- All [GFN](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-027). +- All [GTC/GTT](./0014-ORDT-order_types.md#time-in-force---validity) orders remain on the book untouched. (0068-MATC-028). When a market [market exits an auction](./0026-AUCT-auctions.md#upon-exiting-auction-mode): -- The book is uncrossed. (0068-MATC-029). For product spot: (0068-MATC-086) - - Self trading is allowed during uncrossing. (0068-MATC-030). For product spot: (0068-MATC-087) -- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031). For product spot: (0068-MATC-088) +- The book is uncrossed. (0068-MATC-029). + - Self trading is allowed during uncrossing. (0068-MATC-030). +- All [GFA](./0014-ORDT-order_types.md#time-in-force---validity) orders are cancelled. (0068-MATC-031). - [PEGGED](./0014-ORDT-order_types.md#order-pricing-methods) orders are repriced where possible. (0068-MATC-032) -- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033). For product spot: (0068-MATC-060) -- The price of any persistent order can be updated (0068-MATC-034). For product spot: (0068-MATC-089) -- The size of any persistent order can be updated (0068-MATC-035). For product spot: (0068-MATC-090) -- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036). For product spot: (0068-MATC-092) -- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037). For product spot: (0068-MATC-091) +- Any persistent order that is currently [ACTIVE or PARKED](./0024-OSTA-order_status.md) can be [cancelled](./0033-OCAN-cancel_orders.md). (0068-MATC-033). +- The price of any persistent order can be updated (0068-MATC-034). +- The size of any persistent order can be updated (0068-MATC-035). +- The TIF of any persistent order can be updated to and from GTC and GTT only. Expiry time is required if amending to GTT and must not be given if amending to GTC. (0068-MATC-036). +- An update to an order that is not [ACTIVE or PARKED](./0024-OSTA-order_status.md) (Stopped, Cancelled, Expired, Filled) will be rejected (0068-MATC-037). ## Summary diff --git a/protocol/0070-MKTD-market-decimal-places.md b/protocol/0070-MKTD-market-decimal-places.md index 4e1c9e5f6..b072fc15b 100644 --- a/protocol/0070-MKTD-market-decimal-places.md +++ b/protocol/0070-MKTD-market-decimal-places.md @@ -70,16 +70,16 @@ Trades of course result in transfers. The amounts transferred (for the trade as ## Acceptance criteria - As a user, I can propose a market with a different precision than its settlement asset - - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001). For product spot: (0070-MKTD-016) - - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002). For product spot: (0070-MKTD-009) + - This proposal is valid if the precision is NOT greater than the settlement asset (0070-MKTD-001). + - This proposal is NOT valid if the precision is greater than the settlement asset (0070-MKTD-002). - Assert that the settlement calculation can be correctly calculated when: - settlement data precision is > than the settlement asset precision (i.e. settlement data has more precision (decimal places) than the settlement asset and precision will be lost) (0070-MKTD-018) - settlement data precision is < than the settlement asset precision (i.e. settlement data has less precision (decimal places) than the settlement asset and no precision will be lost) (0070-MKTD-019) - settlement data precision is equal to the settlement asset precision (i.e. settlement data has less precision (decimal places) than the settlement asset and no precision will be lost) (0070-MKTD-020) -- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003). For product spot: (0070-MKTD-010) -- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). For product spot: (0070-MKTD-011) -- As a user I should see the market data prices using market precision. (0070-MKTD-005). For product spot: (0070-MKTD-012) -- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006). For product spot: (0070-MKTD-013) -- As a user, offsets specified in pegged orders represent the smallest incremental value to tick away from the pegged price of a pegged order according to the market precision (0070-MKTD-007). For product spot: (0070-MKTD-014) -- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008). For product spot: ( 0070-MKTD-015) +- As a user all orders placed (either directly or through LP) are shown in events with prices in market precision (0070-MKTD-003). +- As a user all transfers (margin top-up, release, MTM settlement) are calculated and communicated (via events) in asset precision (0070-MKTD-004). +- As a user I should see the market data prices using market precision. (0070-MKTD-005). +- Price bounds are calculated in asset precision, but enforced rounded to the closest value in market precision in range (0070-MKTD-006). +- As a user, offsets specified in pegged orders represent the smallest incremental value to tick away from the pegged price of a pegged order according to the market precision (0070-MKTD-007). +- Trades prices, like orders, are shown in market precision. The transfers and margin requirements are in asset precision. ( 0070-MKTD-008). - Settlement data received during trading on a perpetuals market is correctly handled according to the specified precision (0070-MKTD-017) diff --git a/protocol/0073-LIMN-limited_network_life.md b/protocol/0073-LIMN-limited_network_life.md index 9756a7031..45991078f 100644 --- a/protocol/0073-LIMN-limited_network_life.md +++ b/protocol/0073-LIMN-limited_network_life.md @@ -110,8 +110,6 @@ If for `network.checkpoint.timeElapsedBetweenCheckpoints` the value is set to `0 ### Test case 1: Withdrawal status is correctly tracked across resets (0073-LIMN-007) -for product spot: (0073-LIMN-101) - 1. A party has general account balance of 100 USD. 1. The party submits a withdrawal transaction for 100 USD. A checkpoint is immediately created. 1. The network is shut down. @@ -198,7 +196,6 @@ for product spot: (0073-LIMN-1010073-LIMN-010) -for product spot: (0073-LIMN-103) for product perpetuals: (0073-LIMN-106) 1. There is an asset USD and no asset proposals. @@ -215,8 +212,6 @@ for product perpetuals: (0073-LIMN #### Test case 3.3: Market is proposed, voting has closed, market rejected, proposal not restored (0073-LIMN-011) -for product spot:(0073-LIMN-104) - for product perpetuals:(0073-LIMN-107) 1. There is an asset USD and no asset proposals. @@ -234,7 +229,6 @@ for product perpetuals:(0073-LIMN- #### Test case 3.4: Recovery from proposed Markets with no votes, voting is open, proposal not restored (0073-LIMN-012) -for product spot: (0073-LIMN-077) for product perpetuals:(0073-LIMN-108) @@ -251,8 +245,6 @@ for product perpetuals:(0073-LIMN- #### Test case 3.5: Recovery from proposed Markets with votes, voting is open, proposal not restored (0073-LIMN-013) -for product spot: (0073-LIMN-078) - for product perpetuals:(0073-LIMN-109) @@ -270,8 +262,6 @@ for product perpetuals:(0073-LIMN- #### Test case 3.6: Market proposals ignored when restoring twice from same checkpoint (0073-LIMN-014) -for product spot: (0073-LIMN-079) - for product perpetuals:(0073-LIMN-110) @@ -345,7 +335,7 @@ for product perpetuals:(0073-LIMN- 1. Enacted, listed ERC-20 asset is remembered in checkpoint (0073-LIMN-023) 1. An ERC-20 asset loaded from checkpoint can be used in a market loaded from a checkpoint (0073-LIMN-024) 1. An ERC-20 asset loaded from checkpoint can be updated (0073-LIMN-025) -1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026). For product spot: (0073-LIMN-081) +1. An ERC-20 asset loaded from checkpoint can be used in newly proposed markets (0073-LIMN-026). 1. Can deposit and withdraw funds to/from ERC-20 asset loaded from checkpoint (0073-LIMN-027) 1. Propose a valid ERC-20 asset. @@ -360,7 +350,6 @@ for product perpetuals:(0073-LIMN- ### Test case 13: A market with future enactment date can become enacted after being restored from checkpoint (0073-LIMN-028) -for product spot: (0073-LIMN-082) 1. There is an asset USD and no asset proposals. 1. There are no markets and no market proposals. @@ -385,25 +374,25 @@ for product spot: (0073-LIMN-082 0, submit trading terminated. 1. System saves LNL checkpoint at a time when undistributed LP fees for the market are > 0. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029). For product spot: (0073-LIMN-083) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-029). 1. If the market exists in the data node it is marked as settled with no settlement price info (0073-LIMN-030) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-031) 1. In Spot market, for parties that had holdings in the holding account on the market this is now in their general account for the asset. (0073-LIMN-084) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032). For product spot: (0073-LIMN-085) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-032). 1. The insurance pool balance has been redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. (0073-LIMN-112) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034). For product spot: (0073-LIMN-086) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-034). ### Test case 15: Market with trading terminated that settled is not restored, collateral moved correctly 1. Propose, enact, trade in the market, submit trading terminated and settlement data, observe final settlement cashflows for at least 2 parties. 1. System saves LNL checkpoint. 1. Restart Vega, load LNL checkpoint. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040). For product spot: (0073-LIMN-087) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-040). 1. If the market exists in the data node it is marked as settled with correct settlement data. (0073-LIMN-041) 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-042) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-088) 1. The insurance pool balance has been redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. (0073-LIMN-113) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044). For product spot: (0073-LIMN-089) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-044). ### Test case 16: Markets can be settled and terminated after restore as proposed @@ -412,21 +401,20 @@ for product spot: (0073-LIMN-0820073-LIMN-050) -1. In Spot market, market can be closed after a restore. (0073-LIMN-090) -1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051). For product spot: (0073-LIMN-091) +1. It's not possible to submit orders or LP provisions to this market. (0073-LIMN-051). ### Test case 17: Markets with internal time trigger for trading terminated that fires between shutdown and restore 1. Propose, enact a market with some trading terminated given by internal time trigger. Trade in the market creating positions for at least 2 parties. 1. System saves LNL checkpoint before the trading terminated trigger is set off. 1. Restart Vega, load LNL checkpoint at a time which is after trading terminated trigger should have rung. -1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060). For product spot: (0073-LIMN-092); if it exists it in `cancelled` state. -1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061). For product spot: (0073-LIMN-093) +1. The market is not restored (it doesn't exist in core i.e. it's not possible to submit orders or LP provisions to this market) (0073-LIMN-060). +1. If the market exists in the data node it is labelled as `cancelled` (0073-LIMN-061). 1. For parties that had margin balance position on the market this is now in their general account for the asset. (0073-LIMN-062) 1. In Spot market, for parties that had holdings in their holding accounts on the market this is now in their general account for the asset. (0073-LIMN-094) -1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063). For product spot: (0073-LIMN-095) +1. The LP fees that were not distributed have been transferred to the Vega treasury for the asset. (0073-LIMN-063). 1. The insurance pool balance has been redistributed equally between the global insurance pool and the insurance pools of the remaining active markets using the same settlement asset. (0073-LIMN-114) -1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065). For product spot: (0073-LIMN-096) +1. The LP bond account balance has been transferred to the party's general account for the asset. (0073-LIMN-065). ### Test case 18: market definition is the same pre and post LNL restore @@ -434,9 +422,9 @@ for product spot: (0073-LIMN-0820073-LIMN-070). For product spot: (0073-LIMN-097) - - price monitoring bounds (0073-LIMN-071). For product spot: (0073-LIMN-098) - - oracle settings (0073-LIMN-072). For product spot: (0073-LIMN-099) + - risk model and parameters (0073-LIMN-070). + - price monitoring bounds (0073-LIMN-071). + - oracle settings (0073-LIMN-072). - margin scaling factors (0073-LIMN-073) ### Test case 19: Deposit tokens during checkpoint restore @@ -446,7 +434,7 @@ for product spot: (0073-LIMN-0820073-LIMN-074). For product spot: (0073-LIMN-100) +1. There party's newly deposited assets are available. (0073-LIMN-074). ### Test case 20: Multisig updates during checkpoint restart diff --git a/protocol/0074-BTCH-batch-market-instructions.md b/protocol/0074-BTCH-batch-market-instructions.md index 3bc322faf..3deffde49 100644 --- a/protocol/0074-BTCH-batch-market-instructions.md +++ b/protocol/0074-BTCH-batch-market-instructions.md @@ -48,15 +48,15 @@ After entering or exiting an auction mid-batch, the full batch must be processed ## Acceptance criteria -- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001). For product spot: (0074-BTCH-012) +- Given a market with a party having two orders, A and B, a batch transaction to cancel A, amend B to B' and place a limit order which does not immediately execute C should result in a market with orders B' and C. (0074-BTCH-001). - Any batch transaction containing more than one amend to the same order ID should attempt to execute the first as normal but all further amends should error without being executed. (0074-BTCH-002) - An error in any instruction should be logged and returned to the caller but later instructions should still be attempted. (0074-BTCH-003) -- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005). For product spot: (0074-BTCH-015) -- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006). For product spot: (0074-BTCH-016) In particular: +- If an instruction causes the market to enter a Price Monitoring Auction the market should enter the auction immediately before continuing with later instructions. (0074-BTCH-005). +- An instruction which is valid at the start of the batch execution but becomes invalid before it is executed should fail. (0074-BTCH-006). In particular: - A batch consisting of two limit order placements C1 and C2 where the party has enough balance to place either of them individually but not both should place C1 but reject C2. - A batch transaction containing aggressive limit order C1 which moves the market into price monitoring auction and a C2 which is marked `GFN` (good for normal) should execute C1 but reject C2. - A batch transaction with more instructions than `network.spam_protection.max_batch_size` should fail. (0074-BTCH-007) - Instructions in the batch should be executed in the order Cancellations -> Amendments -> Creations. (0074-BTCH-008) -- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009). For product spot: (0074-BTCH-019) +- Funds released by cancellations or amendments within the batch should be immediately available for later instructions (0074-BTCH-009). - If an instruction within a batch causes another party to become distressed, position resolution should be attempted before further instructions within the batch are executed (0074-BTCH-010) - Instructions within the same category within a batch should be executed in the order they are received. For example, if two Cancellations instructions are submitted in a batch: [C1, C2], then C1 should be executed before C2. (0074-BTCH-011) diff --git a/protocol/0079-TGAP-transaction_gas_and_priority.md b/protocol/0079-TGAP-transaction_gas_and_priority.md index 843992ed8..6e8e6c579 100644 --- a/protocol/0079-TGAP-transaction_gas_and_priority.md +++ b/protocol/0079-TGAP-transaction_gas_and_priority.md @@ -104,8 +104,6 @@ There are three priority categories: ### Test max with a market (0079-TGAP-004) -for product spot: (0079-TGAP-006) - 1. Set `network.transactions.maxgasperblock = 100` and `network.transaction.defaultgas = 1`. 1. Create a market with 1 LP 1. Place 2 matching orders, 1 buy order below the matching price and 1 sell order above the matching price. Uncross the opening auction. @@ -115,7 +113,6 @@ for product spot: (0079-TGAP-0060079-TGAP-005) -for product spot: (0079-TGAP-007) 1. Set `network.transactions.maxgasperblock = 500` and `network.transaction.defaultgas = 1`. 1. Place 2 matching orders, 1 buy order below the matching price and 1 sell order above the matching price. Uncross the opening auction. diff --git a/protocol/0080-SPOT-product_builtin_spot.md b/protocol/0080-SPOT-product_builtin_spot.md deleted file mode 100644 index 9a1b82d45..000000000 --- a/protocol/0080-SPOT-product_builtin_spot.md +++ /dev/null @@ -1,138 +0,0 @@ -# Built-in [Product](./0051-PROD-product.md): Spot - -This built-in product provides spot contracts which allow the buying and selling of a "base" asset with a "quote" asset for immediate delivery. - -When trading Spot products, parties can only use assets they own - there is no leverage or margin. - -## 1. Product parameters - -1. `base_asset (Asset)`: this is used to specify the asset to be purchased or sold on the market. -1. `quote_asset (Asset)`: this is used to specify the asset which can be exchanged for the base asset. - -## 2. Network Parameter - -1. `limits.markets.proposeSpotEnabled`: parameter defines whether markets using Spot products are enabled on the network. - -## 3. Target Stake parameters - -1. `time_window`: length of rolling window (in seconds) over which the maximum `total_stake` is measured. -1. `scaling_factor`: fraction of `total_stake` to be selected as the `target_stake`. - -## 4. Market parameters - -1. `market_decimal_places` should be used to specify the number of decimal places of the `quote_asset` when specifying order price. - - The Cash Settled Futures spec could rename `market_decimal_places` to something more general, e.g. `price_decimal_places`. - -1. `position_decimal_places` should be used to specify the number of decimal places of the `base_asset` asset when specifying order size. - - The Cash Settled Futures spec could rename `position_decimal_places` to something more general, e.g. `size_decimal_places`. - -## 5. Liquidity Commitments - -### Submissions - -Liquidity commitments to a Spot market are made as detailed in [0044-LIME](./0044-LIME-lp_mechanics.md). - -A liquidity provision submitted to a `Spot` market specifies a single commitment amount in the `quote` asset. - -```psuedo -Example `LiquidityProvisionSubmission` command to an ETH/DAI market: - -submission = { - "liquidityProvisionSubmission": - { - marketId: "abcdefghiklkmnopqrstuvwxyz", - fee: "0.01", - commitmentAmount: 15000 (DAI) - reference: "example_liquidity_provision_submission" - } -} -``` - -To receive rewards for this commitment, An LP is then obligated to provide orders with a total value equalling their commitment amount on both the `buy` and `sell` sides of the market. As orders on a Spot market have their price expressed in the `quote` asset and their size expressed in the `base` asset, a trades value will be expressed in the `quote` asset. - -### Amendments and Cancellations - -A liquidity amendment or a cancellation is determined as valid following spec [0044-LIME](./0044-LIME-lp_mechanics.md) with the following exceptions: - -- the `maximum_reduction_amount` should be `INF` in the case where the liquidity `time_window=Os` (Note: this is not strictly necessary but an LP is effectively able to reduce their commitment to zero anyway in this case through multiple commitment amendments) - -As the target stake (and therefore `maximum_reduction_amount`) is some factor of the total stake (see [Target Stake](./0080-SPOT-product_builtin_spot.md#market-target-stake)), a single LP will never be able to reduce their commitment to `0` if they are the only LP in a market. They can either keep reducing to a sufficiently small amount they're willing to ignore, or they can submit a governance vote to cancel the market, see the [governance spec](./0028-GOVE-governance.md). - -For market cancellation proposal a sole LP in the market holds all the voting power (unless governance token holders override them). - -## 6. Spot Liquidity Mechanisms - -### Market Total Stake - -The `total_stake` for a `Spot` market is calculated simply as the sum of each LPs `physical_stake` and therefore should be expressed in the `quote_asset` of the market. - -### Market Target Stake - -See spec [0041-TSTK](./0041-TSTK-target_stake.md). - -### Market Liquidity Fees - -The market liquidity fee is calculated using the same mechanism defined in [0042-LIQF](./0042-LIQF-setting_fees_and_rewarding_lps.md). - -The liquidity fee is re-calculated at the start of a fee distribution epoch and is fixed for that epoch. -Note: 1. this may later be applied universally to all products. 2. this "fee distribution epoch" is unrelated to blockchain staking and delegation epochs. - -## 7. Trading - -Both buy and sell orders on a `Spot` market define a size (amount of the `base_asset`) to buy or sell at a given price (amount of the `quote_asset`). An orders "value for fee purposes" is always expressed in the `quote_asset`. - -### Sell Orders - -For a "sell" order to be considered valid, the party must have a sufficient amount of the `base_asset` in the relevant `general_account` to fulfil the size of the order. There is no need to consider trading fees when determining if a "sell" order is valid. - -If a "sell" order does not trade immediately (or only trades in part), an amount of the `base_asset` to cover the remaining size of the order should be transferred to a `holding_account` for the `base_asset`. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. - -If a "sell" order incurs fees through trading (i.e. is the aggressor or trades in an auction), the necessary amount of the `quote_asset` to cover the fees incurred will be deducted from the amount of the `quote_asset` due to the party as a result of the sell of the `base_asset`. - -### Buy Orders - -As "buy" orders require a party to hold a sufficient amount of the `quote_asset` to cover possible fees, the individual cases where fees can be incurred must be considered. - -#### Continuous Trading - -For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor). - -If a "buy" order does not trade immediately (or only trades in part), the necessary amount of the `quote_asset` to cover only the remaining size of the order should be transferred to a `holding_account` for the `quote_asset`. As the order can no longer be the aggressor during continuous trading there is no requirement to hold funds to cover fees. If the order is cancelled or the size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`. - -#### Entering an Auction - -When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties `general_account` to the parties `holding_account` to cover any possible fees incurred as a result of the order trading in the auction. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled. -For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the `quote_asset` to cover the size of the order as well as any possible fees occurred as a result of the order trading in the auction. - -If the fee rates change for whatever reason within an auction, the amount required to cover fees must be recalculated and the necessary amount transferred to or released from the `holding_account`. - -#### Exiting an Auction - -When exiting an auction, for any orders which are still open, the funds held in the parties `holding_account` to cover the possible fees can be released to the parties `general_account` so the only amount remaining in the `holding_account` is enough to cover the value of the order. - -## 8. Auctions - -As there is no margin or leverage when dealing with `Spot` products, there is no need for the supplied liquidity to exceed a threshold to exit an auction. There is therefore no need for liquidity auctions. - -Price-monitoring auctions are still required and should be implemented following the [price-monitoring](./0032-PRIM-price_monitoring.md) spec. - -## 9. Acceptance Criteria - -1. Create a `Spot` for any `quote_asset` / `base_asset` pair that are configured in Vega (0080-SPOT-001) -1. It is not possible to change the `quote_asset` via governance (0080-SPOT-002) -1. It is not possible to change the `base_asset` via governance (0080-SPOT-003) -1. A `Spot` market can be closed through governance (0080-SPOT-004) -1. Parties are unable to submit liquidity commitments they do not have the necessary funds for (0080-SPOT-006) -1. If a "sell" order does not trade immediately (or only trades in part), an amount of the base_asset should be transferred to a holding_account to cover the remaining size of the order for the base_asset.(0080-SPOT-009) -1. If a "sell" order incurs fees through trading, the required amount of the quote_asset to cover the fees will be deducted from the total quote_asset resulting from the sale of the base_asset.(0080-SPOT-010) -1. For a "buy" order to be considered valid during continuous trading, the party must have a sufficient amount of the `quote_asset` in the `general_account` to cover the value of the trade as well as any possible fees incurred as a result of the order trading immediately (the aggressor).(0080-SPOT-012) -1. If a "buy" order does not trade immediately (or only trades in part), only the necessary amount of the quote_asset to cover the remaining size of the order should be transferred to a holding_account for the quote_asset.(0080-SPOT-013). -1. If the order is cancelled, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-007) -1. If the order's size is reduced through an order amendment, funds should be released from the `holding_account` and returned to the `general_account`.(0080-SPOT-015) -1. When entering an auction, for any open "buy" orders, the network must transfer additional funds from the parties' general_account to their respective holding_account to cover any potential fees resulting from the order trading in the auction.(0080-SPOT-016). -1. If the party does not have sufficient funds in their `general` account to cover this transfer, the order should be cancelled(0080-SPOT-017). -1. For a "buy" order to be considered valid during an auction, the party must have a sufficient amount of the quote_asset to cover the order size, as well as any potential fees that may be incurred due to the order trading in the auction.(0080-SPOT-018). -1. If the fee rates change for any reason within an auction, the amount required to cover fees must be recalculated, and the necessary amount should be transferred to or released from the holding_account.(0080-SPOT-019). -1. When exiting an auction, for any orders that are still open, the funds held in the parties' holding_account to cover potential fees can be released to their respective general_account, so that the remaining amount in the holding_account is only sufficient to cover the value of the order.(0080-SPOT-020). diff --git a/protocol/0081-SUCM-successor_markets.md b/protocol/0081-SUCM-successor_markets.md index eb9bc26b5..417e417e5 100644 --- a/protocol/0081-SUCM-successor_markets.md +++ b/protocol/0081-SUCM-successor_markets.md @@ -23,7 +23,6 @@ Moreover, part of the insurance pool of a parent market can be earmarked for tra A market [governance] proposal for a successor market must contain all the information of a full proposal with additionally specified `parent market Id` and `insurancePoolFraction`. The product type, settlement asset, and margin asset must match but all other inputs can be different (e.g. position and price decimal places, risk model, price monitoring, termination and settlement oracles etc.). -For [spot markets](./0080-SPOT-product_builtin_spot.md) base and quote assets must match. The parent market must be either: a) in one of `proposed`, `pending`, `active`, `suspended` or `trading terminated` or b) `settled` state but with time since settlement less than or equal `market.liquidity.successorLaunchWindowLength` @@ -64,12 +63,8 @@ Market proposal may specify parent market ID. If it does then: - It must also specify insurance pool fraction (0081-SUCM-001) - The product type, settlement asset and margin asset must match between parent and successor; if not proposal is rejected: - futures to perpetuals (0081-SUCM-002) - - perpetuals to spot (0081-SUCM-033) - - spot to futures (0081-SUCM-034) - It is possible for the successor to specify different trading termination and settlement oracle data (0081-SUCM-003). -It is possibly to cancel a [spot market](./0080-SPOT-product_builtin_spot.md) via governance and propose a new spot market as a successor with different `market_decimal_places` and `position_decimal_places` (aka `size_decimal_places` for spot); the LPs virtual stakes are carried over (0081-SUCM-004). - It is possibly to cancel a [perpetual futures](./0053-PERP-product_builtin_perpetual_future.md) market via governance and propose a new perpetual futures market as a successor of the aforementioned cancelled / to be cancelled with different `market_decimal_places` and `position_decimal_places`; the LPs virtual stakes are carried over (0081-SUCM-015). Two proposals that name the same parent can be submitted. Both can be approved by governance. The proposed market that clears the opening auction first gets a share of the insurance pool, and the virtual stakes get carried over. Once the first market clears the opening auction, the other market is "Rejected," and all assets committed into LP bond accounts will be immediately released. Orders placed into the opening auction will be cancelled, and the assets held to support any party's orders will be released. (0081-SUCM-005). diff --git a/protocol/0083-RFPR-on_chain_referral_program.md b/protocol/0083-RFPR-on_chain_referral_program.md index 918c7a6e1..8b9b9d7b9 100644 --- a/protocol/0083-RFPR-on_chain_referral_program.md +++ b/protocol/0083-RFPR-on_chain_referral_program.md @@ -226,7 +226,7 @@ If a party is already a referee, and submits another `ApplyReferralCode` transac ### Party volumes -The network must now track the cumulative notional volume of taker trades for each party in an epoch, call this value `party_epoch_notional_taker_volume`. Note, trades generated by auction uncrossing are not counted. Each time a eligible trade is generated, the network should increment a parties `party_epoch_notional_taker_volume` by the quantum notional volume of the trade. For a spot market, the quantum is the quantum of the asset used to express the price (i.e. the [quote_asset](./0080-SPOT-product_builtin_spot.md/#1-product-parameters)). +The network must now track the cumulative notional volume of taker trades for each party in an epoch, call this value `party_epoch_notional_taker_volume`. Note, trades generated by auction uncrossing are not counted. Each time a eligible trade is generated, the network should increment a parties `party_epoch_notional_taker_volume` by the quantum notional volume of the trade. ```pseudo party_epoch_notional_taker_volume = party_epoch_notional_taker_volume + (trade_price * trade_size / settlement_asset_quantum) From 2a64e56185ca6344699303cc56eb893a56407d35 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 16 Oct 2023 22:44:07 +0100 Subject: [PATCH 647/649] chore: remove spot from cosmic approbation --- protocol/features.json | 345 ----------------------------------------- 1 file changed, 345 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index 69a6f74f6..c983b795f 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -574,351 +574,6 @@ "0028-GOVE-149" ] }, - "Spot": { - "milestone": "deployment-3", - "acs": [ - "0080-SPOT-001", - "0080-SPOT-002", - "0080-SPOT-003", - "0080-SPOT-004", - "0080-SPOT-006", - "0080-SPOT-007", - "0080-SPOT-009", - "0080-SPOT-010", - "0080-SPOT-012", - "0080-SPOT-013", - "0080-SPOT-015", - "0080-SPOT-016", - "0080-SPOT-017", - "0080-SPOT-018", - "0080-SPOT-019", - "0080-SPOT-020", - "0081-SUCM-004", - "0044-LIME-043", - "0044-LIME-044", - "0044-LIME-045", - "0044-LIME-046", - "0044-LIME-047", - "0044-LIME-048", - "0044-LIME-054", - "0044-LIME-055", - "0044-LIME-056", - "0044-LIME-064", - "0044-LIME-066", - "0044-LIME-068", - "0044-LIME-070", - "0044-LIME-072", - "0044-LIME-074", - "0044-LIME-076", - "0044-LIME-078", - "0044-LIME-080", - "0044-LIME-082", - "0056-REWA-051", - "0056-REWA-052", - "0056-REWA-053", - "0056-REWA-054", - "0056-REWA-055", - "0056-REWA-056", - "0056-REWA-057", - "0056-REWA-058", - "0056-REWA-059", - "0056-REWA-060", - "0056-REWA-061", - "0056-REWA-062", - "0056-REWA-063", - "0056-REWA-064", - "0056-REWA-065", - "0056-REWA-066", - "0056-REWA-067", - "0056-REWA-068", - "0056-REWA-069", - "0056-REWA-070", - "0056-REWA-071", - "0056-REWA-072", - "0056-REWA-073", - "0056-REWA-074", - "0056-REWA-075", - "0073-LIMN-077", - "0073-LIMN-078", - "0073-LIMN-079", - "0073-LIMN-080", - "0073-LIMN-081", - "0073-LIMN-082", - "0073-LIMN-083", - "0073-LIMN-084", - "0073-LIMN-085", - "0073-LIMN-086", - "0073-LIMN-088", - "0073-LIMN-089", - "0037-OPEG-019", - "0008-TRAD-008", - "0004-AMND-030", - "0004-AMND-031", - "0004-AMND-032", - "0004-AMND-033", - "0004-AMND-034", - "0004-AMND-035", - "0004-AMND-036", - "0004-AMND-037", - "0004-AMND-038", - "0004-AMND-039", - "0004-AMND-040", - "0004-AMND-041", - "0004-AMND-042", - "0004-AMND-043", - "0004-AMND-044", - "0004-AMND-045", - "0004-AMND-046", - "0004-AMND-047", - "0004-AMND-048", - "0004-AMND-049", - "0004-AMND-050", - "0004-AMND-051", - "0004-AMND-052", - "0004-AMND-053", - "0004-AMND-054", - "0004-AMND-055", - "0011-MARA-018", - "0011-MARA-019", - "0011-MARA-020", - "0011-MARA-021", - "0011-MARA-022", - "0011-MARA-023", - "0011-MARA-024", - "0011-MARA-025", - "0011-MARA-026", - "0011-MARA-027", - "0011-MARA-028", - "0011-MARA-029", - "0011-MARA-030", - "0011-MARA-031", - "0011-MARA-032", - "0013-ACCT-024", - "0013-ACCT-025", - "0013-ACCT-030", - "0013-ACCT-031", - "0014-ORDT-081", - "0014-ORDT-082", - "0014-ORDT-083", - "0014-ORDT-084", - "0014-ORDT-085", - "0014-ORDT-086", - "0014-ORDT-087", - "0014-ORDT-088", - "0014-ORDT-089", - "0014-ORDT-090", - "0014-ORDT-091", - "0014-ORDT-092", - "0014-ORDT-093", - "0014-ORDT-094", - "0014-ORDT-095", - "0014-ORDT-096", - "0014-ORDT-097", - "0014-ORDT-098", - "0014-ORDT-099", - "0014-ORDT-100", - "0014-ORDT-101", - "0014-ORDT-102", - "0014-ORDT-103", - "0014-ORDT-104", - "0014-ORDT-105", - "0014-ORDT-106", - "0014-ORDT-107", - "0014-ORDT-108", - "0014-ORDT-109", - "0014-ORDT-110", - "0014-ORDT-111", - "0014-ORDT-112", - "0014-ORDT-113", - "0014-ORDT-114", - "0014-ORDT-115", - "0014-ORDT-116", - "0014-ORDT-117", - "0014-ORDT-118", - "0014-ORDT-119", - "0021-MDAT-013", - "0021-MDAT-014", - "0021-MDAT-015", - "0021-MDAT-016", - "0021-MDAT-017", - "0021-MDAT-018", - "0021-MDAT-019", - "0021-MDAT-020", - "0024-OSTA-030", - "0024-OSTA-031", - "0024-OSTA-032", - "0024-OSTA-033", - "0024-OSTA-034", - "0024-OSTA-035", - "0024-OSTA-036", - "0024-OSTA-037", - "0024-OSTA-038", - "0024-OSTA-039", - "0024-OSTA-040", - "0024-OSTA-041", - "0024-OSTA-042", - "0024-OSTA-043", - "0024-OSTA-044", - "0024-OSTA-045", - "0024-OSTA-046", - "0024-OSTA-047", - "0024-OSTA-048", - "0025-OCRE-004", - "0025-OCRE-005", - "0025-OCRE-006", - "0026-AUCT-023", - "0026-AUCT-024", - "0026-AUCT-025", - "0026-AUCT-026", - "0026-AUCT-027", - "0026-AUCT-028", - "0026-AUCT-029", - "0026-AUCT-031", - "0026-AUCT-032", - "0029-FEES-015", - "0029-FEES-016", - "0029-FEES-017", - "0029-FEES-018", - "0029-FEES-019", - "0029-FEES-020", - "0029-FEES-021", - "0029-FEES-022", - "0032-PRIM-022", - "0032-PRIM-023", - "0032-PRIM-024", - "0032-PRIM-025", - "0032-PRIM-026", - "0032-PRIM-027", - "0032-PRIM-028", - "0032-PRIM-029", - "0032-PRIM-030", - "0032-PRIM-031", - "0032-PRIM-032", - "0032-PRIM-033", - "0032-PRIM-034", - "0032-PRIM-035", - "0032-PRIM-036", - "0032-PRIM-037", - "0032-PRIM-038", - "0033-OCAN-011", - "0033-OCAN-012", - "0033-OCAN-013", - "0033-OCAN-014", - "0033-OCAN-015", - "0033-OCAN-016", - "0033-OCAN-017", - "0034-PROB-003", - "0034-PROB-008", - "0034-PROB-010", - "0039-MKTD-020", - "0039-MKTD-021", - "0039-MKTD-022", - "0039-MKTD-023", - "0039-MKTD-024", - "0039-MKTD-025", - "0039-MKTD-026", - "0039-MKTD-027", - "0039-MKTD-028", - "0039-MKTD-029", - "0039-MKTD-030", - "0039-MKTD-031", - "0039-MKTD-032", - "0039-MKTD-033", - "0043-MKTL-005", - "0043-MKTL-006", - "0043-MKTL-007", - "0043-MKTL-008", - "0049-TVAL-007", - "0049-TVAL-008", - "0049-TVAL-009", - "0049-TVAL-010", - "0049-TVAL-011", - "0049-TVAL-012", - "0051-PROD-004", - "0051-PROD-005", - "0051-PROD-006", - "0052-FPOS-003", - "0052-FPOS-004", - "0054-NETP-007", - "0054-NETP-008", - "0054-NETP-009", - "0054-NETP-010", - "0054-NETP-011", - "0057-TRAN-063", - "0065-FTCO-005", - "0065-FTCO-006", - "0065-FTCO-007", - "0065-FTCO-008", - "0066-VALW-004", - "0066-VALW-005", - "0068-MATC-060", - "0068-MATC-061", - "0068-MATC-062", - "0068-MATC-063", - "0068-MATC-064", - "0068-MATC-065", - "0068-MATC-066", - "0068-MATC-067", - "0068-MATC-068", - "0068-MATC-069", - "0068-MATC-070", - "0068-MATC-071", - "0068-MATC-072", - "0068-MATC-073", - "0068-MATC-074", - "0068-MATC-075", - "0068-MATC-076", - "0068-MATC-077", - "0068-MATC-078", - "0068-MATC-079", - "0068-MATC-080", - "0068-MATC-081", - "0068-MATC-082", - "0068-MATC-083", - "0068-MATC-084", - "0068-MATC-085", - "0068-MATC-086", - "0068-MATC-087", - "0068-MATC-088", - "0068-MATC-089", - "0068-MATC-090", - "0068-MATC-091", - "0068-MATC-092", - "0070-MKTD-008", - "0070-MKTD-009", - "0070-MKTD-010", - "0070-MKTD-011", - "0070-MKTD-012", - "0070-MKTD-013", - "0070-MKTD-014", - "0070-MKTD-015", - "0073-LIMN-087", - "0073-LIMN-090", - "0073-LIMN-091", - "0073-LIMN-092", - "0073-LIMN-093", - "0073-LIMN-094", - "0073-LIMN-095", - "0073-LIMN-096", - "0073-LIMN-097", - "0073-LIMN-098", - "0073-LIMN-099", - "0073-LIMN-100", - "0073-LIMN-101", - "0073-LIMN-102", - "0073-LIMN-103", - "0073-LIMN-104", - "0074-BTCH-011", - "0074-BTCH-012", - "0074-BTCH-015", - "0074-BTCH-016", - "0074-BTCH-019", - "0079-TGAP-006", - "0079-TGAP-007", - "0081-SUCM-033", - "0081-SUCM-034" - ] - }, "Unknown": { "milestone": "unknown", "acs": [] From b5938d144034a316da95e8c3e5d7b0032bf64c29 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 16 Oct 2023 22:47:30 +0100 Subject: [PATCH 648/649] chore: remove Batch change proposals from cosmic --- protocol/features.json | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/protocol/features.json b/protocol/features.json index c983b795f..1e56d0616 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -563,16 +563,6 @@ "0028-GOVE-151", "0028-GOVE-152" ] - }, - "Batch change proposals": { - "milestone": "deployment-3", - "acs": [ - "0028-GOVE-145", - "0028-GOVE-146", - "0028-GOVE-147", - "0028-GOVE-148", - "0028-GOVE-149" - ] }, "Unknown": { "milestone": "unknown", From 83cd8aa837c0ceffe85aa0784b300773f7fe8f05 Mon Sep 17 00:00:00 2001 From: gordsport Date: Mon, 16 Oct 2023 22:54:31 +0100 Subject: [PATCH 649/649] chore: remove AC from wrong feature Its been put into spot for palazzo or later in chore: - https://github.com/vegaprotocol/specs/pull/2004 --- protocol/features.json | 1 - 1 file changed, 1 deletion(-) diff --git a/protocol/features.json b/protocol/features.json index 1e56d0616..94910d269 100644 --- a/protocol/features.json +++ b/protocol/features.json @@ -331,7 +331,6 @@ "0044-LIME-053", "0044-LIME-060", "0044-LIME-028", - "0044-LIME-029", "0044-LIME-032", "0044-LIME-033", "0044-LIME-034",